Standards own the linter config; define PowerShell formatting; sharpen negated-boolean rule

Author: MariusStorhaug

src/docs/Coding-Standards/Code-Layout.md

@@ -9,10 +9,11 @@ How code is structured on the page and across files. Layout is not cosmetic —
 
 ## Formatting is automated
 
-Formatting is a solved problem — hand it to a tool. Every repository runs a formatter and a linter, and they run in the editor, on commit, and in CI.
+The standard owns the formatting rules; the tooling enforces them automatically — in the editor, on commit, and in CI. A repository's formatter and linter configuration is **derived from these standards**, so the machine applies what is written here rather than defining it.
 
-- **Do not argue about formatting in review.** If the formatter accepts it, it is correct. Disagreements are settled by changing the formatter config, in its own PR.
-- **The formatter config lives in the repository**, in version control, so humans and agents apply the same rules.
+- **Do not argue about formatting in review.** The standard has already decided; if the formatter accepts it, it matches the standard.
+- **Change a rule by changing the standard, not the config.** Adjust it here first, in its own PR; the derived tool config follows.
+- **The config lives in the repository**, in version control and traceable to this standard, so humans and agents apply the same rules.
 - This frees review attention for what actually matters: correctness, design, and clarity.
 
 See [Shift Left → pre-commit hooks](../Ways-of-Working/Principles/Engineering-Practices.md#pre-commit-hooks) for where these gates run.

src/docs/Coding-Standards/Naming.md

@@ -42,5 +42,5 @@ Name length should track scope. A loop index living for three lines can be `i`.
 
 - Encoding type into the name (`strName`, `arrUsers`) — the type system already knows.
 - Numbered suffixes (`user1`, `user2`, `dataNew`) — they signal a missing concept.
-- Negated booleans (`isNotReady`) — double negatives read badly in conditionals.
+- Negated booleans (`isNotReady`, `notReady`) — a negative name forces a double negative at every use, and a value turns it into a riddle: does `notReady = false` mean it *is* ready? Name the positive (`isReady`) and negate at the point of use.
 - Names that lie — a `getUser` that also writes to a cache is a name that lies. Rename or split.

src/docs/Coding-Standards/PowerShell/index.md

@@ -26,10 +26,20 @@ These hold for all PowerShell, whatever the construct:
 - **`Verb-Noun` naming** with an approved verb (`Get-Verb`) and a singular noun: `Get-RepositorySecret`, not `Fetch-Secrets`.
 - **`PascalCase`** for functions, parameters, public variables, and class members; `camelCase` for local variables.
 - **Full cmdlet names, never aliases** (`Where-Object`, not `?`; `ForEach-Object`, not `%`).
-- **One True Brace Style (OTBS)** — opening brace on the statement line, closing brace on its own line; always brace control blocks, even single statements.
 - **Set `$ErrorActionPreference = 'Stop'`** at the top of every script and module so errors are terminating, not silently swallowed.
 - **Emit objects, not formatted text.** Return rich objects and let the caller format; reserve `Write-Host` for genuine console UX, and use `Write-Verbose` / `Write-Information` for progress narration.
 
+## Formatting
+
+These rules define the layout; [PSScriptAnalyzer](#toolchain) enforces them (its settings are derived from this standard, not the reverse), so author to them and let the formatter apply them:
+
+- **One True Brace Style (OTBS).** Opening brace on the statement line, closing brace on its own line; always brace control blocks, even a single statement. No blank line straight after `{` or before `}`, and `else` / `elseif` / `catch` / `finally` sit on the line with the preceding closing brace.
+- **Indent with four spaces, never tabs**, and indent comment-based help to align with the function it documents.
+- **One space around operators and after commas** (`$a -eq $b`, `@(1, 2, 3)`), and **one space between a type and the name** — `[string] $Name`, not `[string]$Name`.
+- **`elseif` is one word**, not `else if`.
+- **Blank lines separate logical blocks.** No trailing whitespace, and end every file with a single newline.
+- **Keep code lines readable — aim for roughly 120 columns.** When a call grows long, prefer [splatting](#idioms-and-pitfalls) over backtick line-continuations.
+
 ## Idioms and pitfalls
 
 Beyond the basics, these language-specific habits keep PowerShell correct and fast:
@@ -43,7 +53,7 @@ Beyond the basics, these language-specific habits keep PowerShell correct and fa
 
 ## Toolchain
 
-The toolchain is the enforcement mechanism, and it runs in CI:
+The toolchain enforces this standard in CI — it does not define it. The rules above are the source of truth; each tool's configuration is derived from them:
 
-- **[PSScriptAnalyzer](https://github.com/PowerShell/PSScriptAnalyzer)** is the linter and formatter; code must pass it cleanly. The shared settings file is the source of truth for formatting — do not hand-format.
+- **[PSScriptAnalyzer](https://github.com/PowerShell/PSScriptAnalyzer)** is the linter and formatter; its settings are derived from this standard, so passing it cleanly means matching the standard. Let it format — do not hand-format.
 - **[Pester](https://pester.dev/)** is the test framework; test files are named `*.Tests.ps1`. See the [Testing baseline](../Testing.md).

src/docs/Coding-Standards/index.md

@@ -7,7 +7,7 @@ description: The shared baseline every repository inherits, and the per-language
 
 Standards for code written anywhere in the MSX ecosystem, in two tiers. The **baseline** encodes the [Principles](../Ways-of-Working/Principles/index.md) at the level of day-to-day code — how it is named, laid out, documented, tested, and secured — and applies in every language. The **per-language standards** add the idioms of one language or tool on top, and never contradict the baseline.
 
-These standards are prescriptive: a change is expected to follow them, and the relevant linter or formatter is the enforcement mechanism wherever one exists.
+These standards are prescriptive, and they are the source of truth: the relevant linter or formatter is the enforcement mechanism, and its configuration is derived from the standard — never the other way around. Wherever a rule can be checked mechanically, a linter derived from the standard enforces it in CI.
 
 ## Contents