Skip to content

Code Health: raise all files to 9.5 #294

Open

Description

@woksin

Follow-up from the .NET 10/11 retargeting (#293). Raise the repository's Code Health to at least 9.5 for every file, make it pass the whole-solution format check and clean up workflow lint, without changing behavior.

Known gaps

  • dotnet format --verify-no-changes over the whole solution exits with code 2. These are existing issues, not ones the retargeting introduced.
  • actionlint reports queue: max at .github/workflows/publish.yml line 9. The line predates the retargeting.
  • No per-file Code Health baseline has been taken yet. The files the retargeting changed score 10.

Acceptance criteria

  • A CodeScene baseline lists every file below 9.5, and each of those files is raised to at least 9.5.
  • dotnet format --verify-no-changes passes for the whole solution.
  • actionlint passes for every workflow, or the queue key is confirmed to be valid and the lint is configured to accept it.
  • Specs pass on net10.0 and net11.0, and the Release build has zero warnings.
  • No behavior change.

Status

State: Paused — PR #309 (split engine code into focused steps) merged. The unpushed follow-up branch scene-294-pr2b (spec coverage for the template chain and applicability branches in both engines) was dropped in the drain, because the Code Health sweeps are stopped. Remaining files can be picked up from main when
Branch: dotnet11 (#302, #309)
Scope: Lane D4: Code Health >= 9.5, whole-solution dotnet format, actionlint queue key; no behavior change.
Plan: Characterization-first extract-and-name refactors in worst-first batches pairing each C# file with its TypeScript twin over the shared fixtures; refactors with no measurable gain are reverted and named as exceptions. Whole-solution dotnet format fixed first; actionlint accepts the valid concurrency queue key. Plan reviewed for behaviour preservation (Opus) and by the other provider (Sol), both approved with changes that were adopted.
Delivered: Nothing yet.
Remaining: To be confirmed.
Follow-ups: None.

Activity

  1. woksin commented on Nov 10, 2026

    @woksin
    ContributorAuthor

    Decision for this issue: a Code Health score alone is not a reason to refactor. Before implementing, write a short design note covering the current behavior, a measured baseline, at least two alternative approaches with sources, the chosen approach and what could break. Have that plan reviewed from two perspectives: behavior preservation plus a reviewer on the other model provider. Keep specs green on main and on the branch, and bisect any failure before calling it pre-existing. Never move ambient state (AsyncLocal, scopes, transactions, principal, tenant) into async helpers. Drop any refactor that does not measurably improve the code or that makes it harder to understand.

  2. self-assigned this
    on Nov 11, 2026
  3. woksin commented on Nov 11, 2026

    @woksin
    ContributorAuthor

    Design note

    Current behavior. The engine exists twice, in C# (Source/DotNET/Engine) and TypeScript (Source/JavaScript/engine), and both sides are held to the same shared conformance fixtures at the repository root. The frontend packages (blueprint.default, react, primereact, components) are TypeScript only.

    Baseline. We scored every source file of 80 lines or more under Source/ with CodeScene: 525 files. We also scored a sample of 45 smaller files, and none of them were below 9.5.

    • 167 files score below 9.5, and about 71 of those below 9.0.
    • By area: 58 in the TypeScript engine, 42 in the C# engine, 28 in blueprint.default, 12 in react, 8 in primereact, 3 in components, and one shared spec helper in each blueprint package.
    • Worst: validateSlotShape.ts 6.11, SlotShapeValidator.cs 6.34, ScenePreviewHost.tsx 6.46, navigationEdits.ts 6.48, GuardConditionText.cs 6.68, validateValue.ts 6.72, NavigationEdits.cs 6.82.
    • The smells are mostly Complex Method, Bumpy Road, Complex Conditional, Large Method and Excess Arguments.

    Alternatives.

    1. Extract and name per smell, characterization first. Pin current behavior with specs, then extract focused steps (Fowler, Refactoring, Extract Function / Decompose Conditional; Feathers, Working Effectively with Legacy Code, characterization tests; CodeScene's refactoring guidance).
    2. Table-driven rewrites. Replace branching with lookup tables or strategy objects. This often scores better but changes evaluation order and makes the C#/TypeScript pairs harder to keep identical.
    3. Suppress or tune thresholds. Cheapest, but it improves nothing.

    Chosen approach. Alternative 1.

    • The work runs in worst-first batches. Each batch pairs a C# file with its TypeScript twin over the shared fixtures.
    • Characterization specs are committed and run green before each refactor. They pin full, ordered diagnostic output and raw serialized JSON, and they check that inputs are not mutated.
    • If a new fixture row shows the two sides already disagree, that is reported as a separate bug rather than resolved by picking one side.
    • A refactor that does not measurably improve the code, or that makes it harder to read, is reverted. The file is then listed as a named exception with its score and the reason.
    • The format check is fixed first (IDE0370, IDE0001/IDE0002, JSON002, SA1114, whitespace). actionlint now accepts the valid concurrency.queue key.

    What could break.

    • The C# and TypeScript sides could drift apart; the shared fixtures guard against this.
    • Diagnostic text, order and locations could change; full-output goldens guard against this.
    • JSON key order could change; raw serialized assertions guard against this.
    • Rendering could change; browser specs, Storybook and blueprint verification guard against this.
    • On net10.0, removed null-forgiving operators could turn into nullable warnings; both target frameworks are built.

    Delivery. About four pull requests that land in sequence, each "part of #294":

    1. Format fixes, plus slot shapes, navigation edits and diagnostics, guard conditions, and outlets/legacy navigation.
    2. The rest of the engine.
    3. The frontend.
    4. The remaining items, a complete re-scan of every eligible file, and the exception list.

    The plan was reviewed for behavior preservation and by a reviewer on the other model provider. Both approved with changes, and those changes are adopted above.

  4. woksin commented on Nov 14, 2026

    @woksin
    ContributorAuthor

    Two files touched by #315 are still below 9.5 and need an uplift pass:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions