chore(spec): register the #4001 unknown-key strictness wave as one v17 ADR-0087 entry (#7630) - #7927
Conversation
…7 ADR-0087 entry (#7630) PR #7624's stock reconciliation judged eleven declared-breaking v17 changesets owed an ADR-0087 ledger entry and deliberately did not write one: the grouping was the open question, and the registries are consumed as a SET, so a wrong grouping produces no error anywhere. The maintainer ruled on #7630 (2026-08-12) for one entry per major, mirroring the registry's only two precedents of this shape (`ui-schemas-strict-unknown-keys` at 15, `dashboard-widget-strict-unknown-keys` at 16), against the alternatives of eleven entries or a per-surface grouping. The eleven batches fold into a single D3 semantic migration, `authoring-schemas-strict-unknown-keys`, with the per-batch provenance written inside the entry so an archaeologist can still walk it batch by batch while an upgrader reads one prescription covering the whole wave. Each of the eleven stock changesets carries its `<!-- adr-0087: registered ... -->` disposition marker, so the judgement is recorded where the next auditor reads. `registry.ts`'s generated region, `spec-changes.json` and `docs/protocol-upgrade-guide.md` are regenerated, never hand-edited. The two adjacent seams recorded on #7630 are deliberately untouched: the 45 `~` rows and the 7 borderline candidates PR #7624 judged not-owed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MPerimH1rzBZRsQvk4VvBD
…-0087-v17-strictness-entry
|
The latest updates on your projects. Learn more about Vercel for GitHub. 1 Skipped Deployment
|
📓 Docs Drift CheckThis PR changes 1 package(s): 106 hand-written doc(s) reference the affected code and may need an implementation-accuracy re-verification:
⛔ 7 release-owned page(s) also reference the affected code. These are read-only:
|
Fixes #7630
What the ruling asked for
The maintainer ruled on #7630 (2026-08-12): direction A — one ADR-0087 entry per major. The eleven declared-breaking v17 changesets PR #7624 judged owed fold into a single entry, with per-batch provenance written inside it; an upgrader reads one prescription covering the whole wave, an archaeologist still walks it batch by batch. The two adjacent seams (45
~rows, 7 borderline candidates) stay exactly as recorded and are not touched.target:*stays with the triage seat.That is what this PR does, and nothing else.
The entry
packages/spec/src/migrations/entries/semantic/17.authoring-schemas-strict-unknown-keys.ts— oneSemanticMigration, shaped after the registry's only two precedents of this class (ui-schemas-strict-unknown-keysat major 15,dashboard-widget-strict-unknown-keysat major 16), and named by their convention. Registered the #7297 way: one new file underentries/semantic/, thengen:migration-registry. Nothing was typed between the<os-generated …>markers.Provenance lives in two places on purpose, because the two readers read different artifacts:
//comment block — the eleven batches with what each one closed, carried by the generator intoregistry.tsdirectly above the entry, for whoever reads the ledger;reasonfield — the eleven changeset names in one sentence, so the trace also reachesspec-changes.jsonanddocs/protocol-upgrade-guide.md, which is where an upgrader actually looks. A leading comment does not reach the projections; that was measured, not assumed.The eleven, re-enumerated against the live tree (all present, none renamed):
unknown-key-strictness-tier-asecurity/permission.zod.ts;automation/flow.zod.ts's four outer shapesunknown-key-strictness-step2security/rls.zod.ts,security/sharing.zod.ts,identity/position.zod.tsstrict-automation-control-flow-state-machinecontrol-flow+ sixstate-machineshapesunknown-key-strictness-automation-batch11unknown-key-strictness-ui-batch13ui/responsive.zod.tsunknown-key-strictness-ui-batch15ui/theme.zod.ts14/14,ui/chart.zod.ts5/7unknown-key-strictness-ui-batch16AriaPropsSchema, carried on ~30 live shapes under six metadata rootsview-subblock-strictness-batch18ui/view.zod.tssub-blocksrare-jars-shaveViewItemSchemasplit into a strict authoring gate + a.strip()wire variantuser-filters-allow-add-tab-promote-and-closeuserFilterspromoted then closed; the three page-only keysview-union-identity-preconditionviewwrite-path union stops matching every objectEach of the eleven stock changesets now carries its
<!-- adr-0087: registered authoring-schemas-strict-unknown-keys -->disposition marker — +2 lines each, the same shape PR #7624 used — so the judgement is recorded where the next auditor reads rather than only in a PR body.Acceptance evidence
check-adr-0087-registration.mjs --audit-stock, run on a full history (this container clones shallow, and the mode refuses the ledger-touch signal on a shallow clone rather than approximating it —git fetch --unshallow --filter=blob:nonefirst, or every row reads?). Measured on the commit before and the commit after:!)~)52 → 41 is exactly the eleven, and
~holding at 45 is the positive check that the adjacent seam was not touched. The baseline reproduces the card's own numbers (answered 39 → 48, residue 106 → 97, flagged 61 → 52after PR #7624).Both directions of the id are wired:
ledgerAt('HEAD')carriesauthoring-schemas-strict-unknown-keys(145 ids), and so doesprojectedMigrationIds(spec-changes.json)(71 ids) — so theregistered <id>markers resolve against a real entry, not a name.Gates
pnpm run check:adr-0087-registrationpnpm --filter @objectstack/spec run typechecktsc --noEmit, scripts, test-layer; debt file unchanged)pnpm --filter @objectstack/spec run testpnpm --filter @objectstack/spec run check:generatedcheck:migration-registry,check:spec-changes,check:upgrade-guide.check:api-surfacereads the builtdist, so the package was built first and then the gate re-run; it is green.registry.tsanswersParsing error: Maximum call stack size exceeded— pre-existing: the identical error reproduces on theorigin/maincopy of the same file with none of my changes in it. Not introduced here, and not fixed here.origin/mainwas merged (569611f94) and the three generators re-run after the merge — zero further diff, so no spec-lane regeneration is racing this tree.git check-attr mergeon the touched paths:spec-changes.jsonanddocs/protocol-upgrade-guide.mdaremerge=os-regen(positive control:.gitattributeslists them);registry.ts, the entry file and the changesets areunspecified, as.gitattributesdocuments for the mixed registry.Scope held
packages/spec/src/**/*.zod.ts— no schema changes, no runtime behaviour change. This is the ledger half of breaks that already shipped..counts.mdproduct.~rows and 7 borderline candidates are untouched (and measured unchanged above).target:*label actions.content/docs/releases/**untouched.docs/adr/**is NOT touched — the measured shape did not require it, so this PR does not flip to the ⛔ Discipline: ADRs are confirmed and merged by the maintainer only — no AI seat may merge, queue, or auto-merge adocs/adr/**PR #6741 human-merge channel.Changeset
@objectstack/spec: minor, mirroring the precedent this PR's shape copies: PR #7624's ledger-only backfill usedminor, and both precedent entries landed alongside a@objectstack/spec: minorchangeset (8fc1208c7,524696a3e). It carries noadr-0087disposition marker of its own — also per #7624, whose backfill changeset carries none.