standards: express mechanically-enforceable C# rules as an .editorconfig instead of prose

Goal

Ship an .editorconfig (and the naming/analyzer rules to go with it) alongside standards/CLAUDE.md, so the team rules that a compiler can enforce are enforced at build time rather than re-derived by an LLM during review.

Background

Most of the C# rules in standards/CLAUDE.md are deterministic and mechanically checkable, but today they exist only as prose. Consequences:

• They are enforced only when someone remembers to run /deep-review, and every run spends opus tokens re-deriving them from the diff.
• An LLM estimating file:line for a style nit is strictly worse than an analyzer that emits the exact location.
• Developers get no feedback in-editor or at build — the earliest signal is code review, which is the most expensive place to catch a brace.

There is currently no .editorconfig anywhere in this repo.

Rules that map to existing analyzers

Rules that do NOT map cleanly (keep as prose / review concerns)

• string.Empty instead of "" — no stock analyzer. Options: a custom Roslyn analyzer, a grep-based check, or leave to review. Decide during implementation; do not invent an analyzer ID that does not exist.
• Use x for simple lambda variables — not mechanically checkable. Stays prose.
• Do not use type aliases unless necessary, prefer using over fully-qualified names — partially checkable (IDE0001/IDE0005 family); verify before claiming.

Proposed change

• Add an .editorconfig under standards/ covering the mapped rules above, with severities the team agrees on (warning vs error).
• Decide how it reaches consuming repos — the sync scripts (setup-env.sh / setup-env.ps1) already sync standards/CLAUDE.md → ~/.claude/CLAUDE.md and standards/settings.json → ~/.claude/settings.json, but .editorconfig is per-repo, not per-user, so it cannot follow the same path. It likely needs to be copied into each consuming repo's root. Resolve this before implementing.
• Once enforced mechanically, trim the corresponding prose from standards/CLAUDE.md (or mark it "enforced by .editorconfig") so the rules have exactly one source of truth.
• Verify each analyzer ID actually exists and produces the intended diagnostic before shipping — do not ship rules on assumption.

Acceptance criteria

• A C# file violating any mapped rule produces a build/editor diagnostic without an LLM in the loop.
• standards/CLAUDE.md no longer states rules that the .editorconfig enforces, or explicitly defers to it.
• The distribution mechanism for .editorconfig is documented in CLAUDE.md alongside the existing sync-script docs.

Notes

This is worth doing independently of any deep-review change — the value is build-time enforcement for every developer in every editor, not review-token savings. The token savings are a side effect.

Related

• #181 — deep-review pre-flight deterministic scan (would consume these diagnostics rather than re-derive them).
• #166 — grooming standards/CLAUDE.md to shrink its always-on footprint. Directly served by this issue: rules enforced by .editorconfig can leave the prose entirely, which is content removed rather than merely relocated to a skill.
• Pending-rule cluster — this issue should set the pattern for incoming rules, not just migrate existing ones. Several open "add a C# rule to standards" issues are analyzer-expressible and would otherwise land as prose:
  • #150 wrap long C# lines → max_line_length
  • #147 use primary constructors → IDE0290
  • #174 no C# keywords as variable names, #151 no multiple assignments per line, #148 discourage params, #153 FirstOrDefault without OrderBy, #144 razor section newlines — verify analyzer support case by case; do not assume an ID exists.
  • #152 avoid the word "slice" — naming taste, not mechanically checkable; stays prose.

Start with standards/CLAUDE.md and inspect setup-env.sh and setup-env.ps1 to understand the existing standards distribution. Verify each proposed analyzer and naming rule against real C# diagnostics, decide how a per-repository .editorconfig reaches consuming repos, and document the chosen mechanism. Done means mapped rules produce diagnostics, duplicated prose is removed or deferred, and distribution is documented.