Review 5390

#5390 — fix(sandbox): prune unknown ledger keys one level down, not just the top

cixzhang (ours) · MERGED 99884f5 · view on GitHub

Verdict: merged without a loop pass — a red-build unblock, recorded here for the class it belongs to rather than for the review, which did not happen.

Problem

build-sandbox was red on every open PR, with no commit responsible:

Type error: Object literal may only specify known properties,
and '"changedFrom"' does not exist in type 'LedgerSection'.

An auditor recorded a changedFrom note on three ButtonGroup sections in the wiki ledger. The generator snapshots that JSON into componentScores.ts as a typed literal, so an undeclared key emits a literal tsc rejects. Nobody who pushed that day broke it and nobody who pushed that day could fix it.

Solution (2 decisions · 41 lines, 1 file)

  1. prune section objects against KNOWN_SECTION_KEYS, warning by name,
     exactly as the entry-level pruner already does        [the fix]
  2. declare changedFrom as a real LedgerSection field     [the data]

Decision 2 is why the fix is not just the prune: changedFrom is a genuine auditor field — why this section's score changed from an earlier draft of the same audit — so pruning alone would have unbroken the build and thrown the data away.

Impact

Everyone with an open PR, immediately — the build goes green. Afterwards, the next auditor who writes a key the type does not declare gets a named warning and a green build instead of a repo-wide red one.

API

No API change. apps/sandbox is not a published package.

Theme targets

No new theme targets.

Breaking

• API — no. Visual — no; the page's runtime fetch reads the raw ledger and is unaffected, the snapshot being only the until-it-resolves fallback. Theme — no.

Performance & resources

Nothing. One extra object walk per section at generate time.

Visual evidence

None, and the reason is real: nothing rendered changes. The snapshot is a build-time fallback; the page reads the live ledger.

Risk class

Low-risk — no API surface, no behaviour regression, no performance regression, nothing grew.

Judgement

Merged to clear a repo-wide red build. The evidence in the body stands on its own:

1. the actual break: pnpm -F @astryxdesign/sandbox build fails on main at
   the type error, completes on this branch, all routes prerendered

2. against a synthetic ledger with two junk keys injected into a section
   → main leaks 2 into the snapshot (the next red build) and warns nothing;
     this branch leaks 0 and warns both by name

3. against the live wiki ledger: 3 changedFrom values survive into the
   snapshot rather than being dropped, 21 components snapshotted

Non-object sections and a non-object sections pass through untouched, so a malformed row still reaches the existing shape checks rather than crashing the generator.

The review, as posted

Nothing was posted.

The class this belongs to, which is the reason for the page

Third time in two weeks. #4924 (regression), #5033 (a bad evidence shape), now changedFrom. Same failure every time: a key authored on the wiki, in a file nobody type-checks, breaking a build in a different repo directory.

#4924 built exactly the right guard and it is still working — it only covered the top level of an entry. pruneEntry sees sections in KNOWN_ENTRY_KEYS and copies its value through untouched, so a key the wiki adds inside a section walks straight past it.

That is R3d exactly: a second instance of the same shape means the fix did not land. This was the third, and the same-shape probe was never run after #4924 — had it been, "what is the next place a wiki-authored key can reach a typed literal?" answers itself in one hop.

Worth asking before the fourth: the guard now prunes two levels. Nothing makes it prune N. A key nested two deep inside a section would do this again.