test(packages): gate that a package door's field allowlist cannot silently drop a stamped or declared key

[os-trump]

Fixes#14642

A gate that goes red when a /packages door's field allowlist drops a key the
producer stamps or the record declares. Both sides of the comparison are derived
by running real code; the only hand-kept artifacts are two annotated registers,
both compared loudly.

Session: https://claude.ai/code/session_016yfqQh2dBgPAymYd7xipza

File face

Two files, both new, both tests:

• packages/rest/src/package-door-producer-key-carry.test.ts
• packages/runtime/src/domains/package-door-producer-key-carry.test.ts

No production file is modified. In particular packages/rest/src/error-response.ts
is not touched — PR #14713 is in flight on it and the gate's honest landing
site was never that file. No CI job added, no CI filter root widened.

Base refreshed by mergingorigin/main (not rebasing, no force-push) at
47181632f2. That merge matters: PR #14785 landed packages/runtime/tsconfig.test.json
while this branch was open, so the runtime pin is now compiled by a real tsc
program. See Verification.

Is the near-miss still reachable on today's main?

• For writable itself: no. Both doors carry it now, by two different
  mechanisms, and both are pinned by name (package-list-writable-carry.test.ts,
  packages-serializable-response.test.ts).
• For the general case: yes, fully reachable. Nothing generalised past that
  one field. The ablation below reintroduces the drop four different ways and
  every one of them shipped a 200 with a field silently absent before this PR.

So the card's premise stands, with the triage comment's sharpening: the gap is
the next stamped or declared key, not writable.

The two doors do not share an invariant, and the gate does not pretend they do

	REST door	runtime door
producer	getMetaItems({type:'package'})	registry.getAllPackages()
where writable comes from	stamped upstream, listed in the allowlist	computed at the door, deliberately not in the allowlist
invariant	the allowlist contains every stamped key	the stamp runs after the projection

Asserting "the allowlist contains every stamped key" at the runtime door would
red on a correct door. So the runtime pin measures the stamp set as
served − record — never a list — and compares it for set equality against
an annotated register. A reorder empties that measured set and reds; a new stamp
grows it and reds until the decision is written down. That register is hand-kept
on purpose: swapping a silent list for a loud one is the mechanism this card
asked for.

Both gate readings

Four ablation legs, each mutating one production line, each restored and proven
restored. The mutation is proven on disk by an anchor count before/after, never
by the editor's exit code. Re-run in full after the merge; every number below
is identical before and after, so the merge moved nothing.

leg	mutation	gate	reading
1	drop 'writable' from REGISTRY_PACKAGE_RESPONSE_FIELDS	REST	RED — list/detail PKG: writable, 6 drops across 3 packages
2	drop 'installedVersion' from the same allowlist	REST	RED — list/detail PKG: installedVersion, 6 drops
3	reorder to toPackageResponse(withWritableVerdict(...))	runtime	RED — stamp set for com.example.showcase: expected [] to deeply equal [ 'writable' ]
4	drop 'installedVersion' from INSTALLED_PACKAGE_RESPONSE_FIELDS	runtime	RED — list/detail PKG: installedVersion, 6 drops
control	tree restored	both	GREEN — REST 4/4, runtime 5/5

Leg 1 is the exact near-miss the card is about. Leg 3 is the exact regression the
runtime door's ordering comment warns about. Legs 2 and 4 are the generality
claim: a plain declared field, with no field-specific pin anywhere.

No rebuild leg is involved and none is owed. Both mutated files are resolved
by vitest as local source — the REST pin imports ./package-routes.js, the
runtime pin reaches ./domains/packages.js through ../http-dispatcher.js — so
dist/ is not on the resolution path for either subject and there is nothing to
preflight. The restore leg is proven by git diff HEAD being empty for both
doors after every leg, not by the restore command's exit code.

Two findings the ablation produced, both now fixed in this PR

Recording these because in both cases the first version of the gate was green
for a bad reason, and a reviewer should see that the readings above are not the
first ones taken.

1. Object.keys was the wrong instrument.installPackage seats settings
   as an own property holding undefined. Both doors omit undefined-valued
   fields deliberately, and JSON.stringify drops them anyway, so the first run
   reported six false drops for a key no consumer could ever have observed. The
   detector now measures defined-valued keys.

2. The fixture could not see two thirds of the record. Deleting
   installedVersion from either allowlist left both gates green on the
   first ablation: installPackage writes only the fields an install can know,
   so six of the twelve declared fields are simply absent from a freshly
   installed record. seatDeclaredFields now seats every field the record
   schema declares, and a control assertion fails if any declared slot becomes
   unobservable again.

On packages/spec

The card rules out deriving the production allowlist from packages/spec,
and this PR does not: both allowlists stay hand-written and are untouched. What
finding 2 derives from the schema is the test's expectation, which is the
card's own wording for the detector — "the projected key set ⊇ the producer's
stamped/declared key set minus an explicit, annotated exclusion list".
Deriving the expectation is precisely what turns a newly declared field into an
explicit decision at each door instead of a silent omission. It adds no import
edge either: @objectstack/spec is already a runtime dependency of both
packages. The rationale is spelled out at DECLARED_RECORD_KEYS in both files so
it cannot be mistaken for the rejected design.

Why two pins rather than one detector

Measured, not assumed. A single file would have to reach the other package's
door:

• From packages/runtime, @objectstack/rest resolves to its dist/ (no
  vitest alias maps it to source), which would make the gate's verdict a function
  of build state. It would also growKNOWN_UNALIASED_TEST_IMPORTS in
  scripts/check-test-source-alias.mjs, a shrink-only registry that lists no
  @objectstack/rest entry for that package today.
• @objectstack/rest cannot import @objectstack/runtime at all — the
  dependency runs the other way.

So: two pins, one shape. Each imports its own door as source, which is also
what lets a reviewer ablate one allowlist and watch exactly one gate go red.

What I did NOT do, and why

• Did not change either allowlist. Both are correct today; the card asked for
  the detector, not an edit to the lists.
• Did not touch packages/rest/src/error-response.ts (hot file, PR fix(rest): consult the bespoke structured arms before the declared-status passthrough, so both error doors answer one refusal with one body #14713).
• Did not add a changeset. The diff is two test files and nothing else. No
  package publishes a test file, so nothing user-visible ships. skip-changeset
  applied.
• Did not widen a CI filter root or add a CI job.
• Did not add anything to packages/runtime/test-typecheck-debt.json, and did
  not need to — see Verification. That ledger is byte-identical to origin/main
  in this branch.
• Did not silence anything to reach green. No any, @ts-expect-error, or
  eslint-disable was added anywhere, and no assertion was weakened. The
  load-bearing comparison — set equality on the stamp set — runs over
  Set(string) and string[], not any.

Verification

All readings from 47181632f2, the merge commit at the head of this branch.
The dependency closure was built first (pnpm --filter '@objectstack/runtime^...' build),
because an unbuilt closure turns every workspace import into TS2307 and makes a
typecheck verdict a statement about a different world.

The runtime test-layer typecheck, which the merge newly applies to this PR

pnpm --filter @objectstack/runtime typecheck — EXIT=0. It now chains
check:test-typecheck, whose own verdict line is:

check:test-typecheck: OK — @objectstack/runtime's test layer compiles under
packages/runtime/tsconfig.test.json; 27 file(s) / 191 error(s) / 69 pinned
signature(s) held in test-typecheck-debt.json (shrink-only and identity-pinned)

Three separate confirmations that the new runtime pin is genuinely covered and
carries no debt:

• tsc --noEmit --project tsconfig.test.json --listFiles shows 1 hit for
  src/domains/package-door-producer-key-carry.test.ts — it is in the program.
  (This replaces the pre-merge reading of 0 hits, which was true on the old base
  and is now false.)
• Error lines naming that file in the same run: 0. The 191 errors are exactly
  the ledgered ones in the other 27 files.
• packages/runtime/test-typecheck-debt.json is byte-identical to
  origin/main's copy — nothing added, no number moved.

Other green

• packages/rest gate — 4/4; packages/runtime gate — 5/5.
• Sibling door pins re-run beside them after the merge:
  package-registry-item-projection, package-list-writable-carry,
  packages-serializable-response, packages-writable-verdict — 3 files /
  14 tests and 3 files / 23 tests, both EXIT=0.
• pnpm --filter @objectstack/rest typecheck — EXIT=0, with --listFiles
  confirming 1 hit for the new REST test file.
• 25 of the 28 gate families derived by scripts/pm/dispatch-gates.mjs --commands
  — exit 0, re-derived and re-run on the merged head (the family list is
  unchanged, and the change set is still exactly these two files).
  check:engine-double-contract was RED early on (my fixture's findOne double)
  and is green after removing that verb, which the producer path never calls.

Not measured, with the reason

• check:dual-build-cjs-loads and check:type-check-debt --re-measure — exit
  3, "PREREQUISITE NOT MET": both need the whole workspace built
  (turbo run build --filter='./packages/*' --filter='./packages/*/*'), not just
  one closure. Exit 3 is neither a pass nor a finding. The sub-measurement that
  this diff could actually have moved — the runtime test-layer debt — is answered
  directly above by check:test-typecheck at EXIT=0 with the ledger unchanged.
  And check:dual-build-cjs-loads reads built output, which a diff adding only
  *.test.ts files cannot reach.
• check-test-completeness — exit 3; it needs a saved turbo run test log,
  and its own failure text says to record it NOT MEASURED when run locally.

Narrowed, declared

The two packages' FULL suites were not run. Nine attempts on the shared verify
lock across this branch never got a long enough turn — holders included one run
at 917s and another at 1704s — and @objectstack/runtime's whole suite exceeds
what fits inside the container's foreground cap on a shared box. Narrowed to the
two new files plus the four sibling pins on the same two doors, all green above.
The diff modifies no production file, no config, and no turbo/vitest setting, so
the only way a sibling test's verdict could move is cross-file interference
inside a vitest worker; CI runs the full sharded suite on this PR regardless.

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

Nothing in this diff resolved to a documentable surface (no symbol, route or SDK anchor derived from 0 changed package(s)), so this run has no opinion about the docs.

What this run could not see

• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.

Coarse fallback — 0 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json f116b8f8d1b43ec2bfd64fbf0ebb0cf3c301b1c8 → packageMentionDocs.

[os-trump]

Fixes#14642

A gate that goes red when a /packages door's field allowlist drops a key the
producer stamps or the record declares. Both sides of the comparison are derived
by running real code; the only hand-kept artifacts are two annotated registers,
both compared loudly.

Session: https://claude.ai/code/session_016yfqQh2dBgPAymYd7xipza

File face

Two files, both new, both tests:

• packages/rest/src/package-door-producer-key-carry.test.ts
• packages/runtime/src/domains/package-door-producer-key-carry.test.ts

No production file is modified. In particular packages/rest/src/error-response.ts
is not touched — PR #14713 is in flight on it and the gate's honest landing
site was never that file. No CI job added, no CI filter root widened.

Base refreshed by mergingorigin/main (not rebasing, no force-push) at
47181632f2. That merge matters: PR #14785 landed packages/runtime/tsconfig.test.json
while this branch was open, so the runtime pin is now compiled by a real tsc
program. See Verification.

Is the near-miss still reachable on today's main?

• For writable itself: no. Both doors carry it now, by two different
  mechanisms, and both are pinned by name (package-list-writable-carry.test.ts,
  packages-serializable-response.test.ts).
• For the general case: yes, fully reachable. Nothing generalised past that
  one field. The ablation below reintroduces the drop four different ways and
  every one of them shipped a 200 with a field silently absent before this PR.

So the card's premise stands, with the triage comment's sharpening: the gap is
the next stamped or declared key, not writable.

The two doors do not share an invariant, and the gate does not pretend they do

	REST door	runtime door
producer	getMetaItems({type:'package'})	registry.getAllPackages()
where writable comes from	stamped upstream, listed in the allowlist	computed at the door, deliberately not in the allowlist
invariant	the allowlist contains every stamped key	the stamp runs after the projection

Asserting "the allowlist contains every stamped key" at the runtime door would
red on a correct door. So the runtime pin measures the stamp set as
served − record — never a list — and compares it for set equality against
an annotated register. A reorder empties that measured set and reds; a new stamp
grows it and reds until the decision is written down. That register is hand-kept
on purpose: swapping a silent list for a loud one is the mechanism this card
asked for.

Both gate readings

Four ablation legs, each mutating one production line, each restored and proven
restored. The mutation is proven on disk by an anchor count before/after, never
by the editor's exit code. Re-run in full after the merge; every number below
is identical before and after, so the merge moved nothing.

leg	mutation	gate	reading
1	drop 'writable' from REGISTRY_PACKAGE_RESPONSE_FIELDS	REST	RED — list/detail PKG: writable, 6 drops across 3 packages
2	drop 'installedVersion' from the same allowlist	REST	RED — list/detail PKG: installedVersion, 6 drops
3	reorder to toPackageResponse(withWritableVerdict(...))	runtime	RED — stamp set for com.example.showcase: expected [] to deeply equal [ 'writable' ]
4	drop 'installedVersion' from INSTALLED_PACKAGE_RESPONSE_FIELDS	runtime	RED — list/detail PKG: installedVersion, 6 drops
control	tree restored	both	GREEN — REST 4/4, runtime 5/5

Leg 1 is the exact near-miss the card is about. Leg 3 is the exact regression the
runtime door's ordering comment warns about. Legs 2 and 4 are the generality
claim: a plain declared field, with no field-specific pin anywhere.

No rebuild leg is involved and none is owed. Both mutated files are resolved
by vitest as local source — the REST pin imports ./package-routes.js, the
runtime pin reaches ./domains/packages.js through ../http-dispatcher.js — so
dist/ is not on the resolution path for either subject and there is nothing to
preflight. The restore leg is proven by git diff HEAD being empty for both
doors after every leg, not by the restore command's exit code.

Two findings the ablation produced, both now fixed in this PR

Recording these because in both cases the first version of the gate was green
for a bad reason, and a reviewer should see that the readings above are not the
first ones taken.

1. Object.keys was the wrong instrument.installPackage seats settings
   as an own property holding undefined. Both doors omit undefined-valued
   fields deliberately, and JSON.stringify drops them anyway, so the first run
   reported six false drops for a key no consumer could ever have observed. The
   detector now measures defined-valued keys.

2. The fixture could not see two thirds of the record. Deleting
   installedVersion from either allowlist left both gates green on the
   first ablation: installPackage writes only the fields an install can know,
   so six of the twelve declared fields are simply absent from a freshly
   installed record. seatDeclaredFields now seats every field the record
   schema declares, and a control assertion fails if any declared slot becomes
   unobservable again.

On packages/spec

The card rules out deriving the production allowlist from packages/spec,
and this PR does not: both allowlists stay hand-written and are untouched. What
finding 2 derives from the schema is the test's expectation, which is the
card's own wording for the detector — "the projected key set ⊇ the producer's
stamped/declared key set minus an explicit, annotated exclusion list".
Deriving the expectation is precisely what turns a newly declared field into an
explicit decision at each door instead of a silent omission. It adds no import
edge either: @objectstack/spec is already a runtime dependency of both
packages. The rationale is spelled out at DECLARED_RECORD_KEYS in both files so
it cannot be mistaken for the rejected design.

Why two pins rather than one detector

Measured, not assumed. A single file would have to reach the other package's
door:

• From packages/runtime, @objectstack/rest resolves to its dist/ (no
  vitest alias maps it to source), which would make the gate's verdict a function
  of build state. It would also growKNOWN_UNALIASED_TEST_IMPORTS in
  scripts/check-test-source-alias.mjs, a shrink-only registry that lists no
  @objectstack/rest entry for that package today.
• @objectstack/rest cannot import @objectstack/runtime at all — the
  dependency runs the other way.

So: two pins, one shape. Each imports its own door as source, which is also
what lets a reviewer ablate one allowlist and watch exactly one gate go red.

What I did NOT do, and why

• Did not change either allowlist. Both are correct today; the card asked for
  the detector, not an edit to the lists.
• Did not touch packages/rest/src/error-response.ts (hot file, PR fix(rest): consult the bespoke structured arms before the declared-status passthrough, so both error doors answer one refusal with one body #14713).
• Did not add a changeset. The diff is two test files and nothing else. No
  package publishes a test file, so nothing user-visible ships. skip-changeset
  applied.
• Did not widen a CI filter root or add a CI job.
• Did not add anything to packages/runtime/test-typecheck-debt.json, and did
  not need to — see Verification. That ledger is byte-identical to origin/main
  in this branch.
• Did not silence anything to reach green. No any, @ts-expect-error, or
  eslint-disable was added anywhere, and no assertion was weakened. The
  load-bearing comparison — set equality on the stamp set — runs over
  Set(string) and string[], not any.

Verification

All readings from 47181632f2, the merge commit at the head of this branch.
The dependency closure was built first (pnpm --filter '@objectstack/runtime^...' build),
because an unbuilt closure turns every workspace import into TS2307 and makes a
typecheck verdict a statement about a different world.

The runtime test-layer typecheck, which the merge newly applies to this PR

pnpm --filter @objectstack/runtime typecheck — EXIT=0. It now chains
check:test-typecheck, whose own verdict line is:

check:test-typecheck: OK — @objectstack/runtime's test layer compiles under
packages/runtime/tsconfig.test.json; 27 file(s) / 191 error(s) / 69 pinned
signature(s) held in test-typecheck-debt.json (shrink-only and identity-pinned)

Three separate confirmations that the new runtime pin is genuinely covered and
carries no debt:

• tsc --noEmit --project tsconfig.test.json --listFiles shows 1 hit for
  src/domains/package-door-producer-key-carry.test.ts — it is in the program.
  (This replaces the pre-merge reading of 0 hits, which was true on the old base
  and is now false.)
• Error lines naming that file in the same run: 0. The 191 errors are exactly
  the ledgered ones in the other 27 files.
• packages/runtime/test-typecheck-debt.json is byte-identical to
  origin/main's copy — nothing added, no number moved.

Other green

• packages/rest gate — 4/4; packages/runtime gate — 5/5.
• Sibling door pins re-run beside them after the merge:
  package-registry-item-projection, package-list-writable-carry,
  packages-serializable-response, packages-writable-verdict — 3 files /
  14 tests and 3 files / 23 tests, both EXIT=0.
• pnpm --filter @objectstack/rest typecheck — EXIT=0, with --listFiles
  confirming 1 hit for the new REST test file.
• 25 of the 28 gate families derived by scripts/pm/dispatch-gates.mjs --commands
  — exit 0, re-derived and re-run on the merged head (the family list is
  unchanged, and the change set is still exactly these two files).
  check:engine-double-contract was RED early on (my fixture's findOne double)
  and is green after removing that verb, which the producer path never calls.

Not measured, with the reason

• check:dual-build-cjs-loads and check:type-check-debt --re-measure — exit
  3, "PREREQUISITE NOT MET": both need the whole workspace built
  (turbo run build --filter='./packages/*' --filter='./packages/*/*'), not just
  one closure. Exit 3 is neither a pass nor a finding. The sub-measurement that
  this diff could actually have moved — the runtime test-layer debt — is answered
  directly above by check:test-typecheck at EXIT=0 with the ledger unchanged.
  And check:dual-build-cjs-loads reads built output, which a diff adding only
  *.test.ts files cannot reach.
• check-test-completeness — exit 3; it needs a saved turbo run test log,
  and its own failure text says to record it NOT MEASURED when run locally.

Narrowed, declared

The two packages' FULL suites were not run. Nine attempts on the shared verify
lock across this branch never got a long enough turn — holders included one run
at 917s and another at 1704s — and @objectstack/runtime's whole suite exceeds
what fits inside the container's foreground cap on a shared box. Narrowed to the
two new files plus the four sibling pins on the same two doors, all green above.
The diff modifies no production file, no config, and no turbo/vitest setting, so
the only way a sibling test's verdict could move is cross-file interference
inside a vitest worker; CI runs the full sharded suite on this PR regardless.

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

Nothing in this diff resolved to a documentable surface (no symbol, route or SDK anchor derived from 0 changed package(s)), so this run has no opinion about the docs.

What this run could not see

• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.

Coarse fallback — 0 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json f116b8f8d1b43ec2bfd64fbf0ebb0cf3c301b1c8 → packageMentionDocs.

[os-trump]

Fixes#14642

A gate that goes red when a /packages door's field allowlist drops a key the
producer stamps or the record declares. Both sides of the comparison are derived
by running real code; the only hand-kept artifacts are two annotated registers,
both compared loudly.

Session: https://claude.ai/code/session_016yfqQh2dBgPAymYd7xipza

File face

Two files, both new, both tests:

• packages/rest/src/package-door-producer-key-carry.test.ts
• packages/runtime/src/domains/package-door-producer-key-carry.test.ts

No production file is modified. In particular packages/rest/src/error-response.ts
is not touched — PR #14713 is in flight on it and the gate's honest landing
site was never that file. No CI job added, no CI filter root widened.

Base refreshed by mergingorigin/main (not rebasing, no force-push) at
47181632f2. That merge matters: PR #14785 landed packages/runtime/tsconfig.test.json
while this branch was open, so the runtime pin is now compiled by a real tsc
program. See Verification.

Is the near-miss still reachable on today's main?

• For writable itself: no. Both doors carry it now, by two different
  mechanisms, and both are pinned by name (package-list-writable-carry.test.ts,
  packages-serializable-response.test.ts).
• For the general case: yes, fully reachable. Nothing generalised past that
  one field. The ablation below reintroduces the drop four different ways and
  every one of them shipped a 200 with a field silently absent before this PR.

So the card's premise stands, with the triage comment's sharpening: the gap is
the next stamped or declared key, not writable.

The two doors do not share an invariant, and the gate does not pretend they do

	REST door	runtime door
producer	getMetaItems({type:'package'})	registry.getAllPackages()
where writable comes from	stamped upstream, listed in the allowlist	computed at the door, deliberately not in the allowlist
invariant	the allowlist contains every stamped key	the stamp runs after the projection

Asserting "the allowlist contains every stamped key" at the runtime door would
red on a correct door. So the runtime pin measures the stamp set as
served − record — never a list — and compares it for set equality against
an annotated register. A reorder empties that measured set and reds; a new stamp
grows it and reds until the decision is written down. That register is hand-kept
on purpose: swapping a silent list for a loud one is the mechanism this card
asked for.

Both gate readings

Four ablation legs, each mutating one production line, each restored and proven
restored. The mutation is proven on disk by an anchor count before/after, never
by the editor's exit code. Re-run in full after the merge; every number below
is identical before and after, so the merge moved nothing.

leg	mutation	gate	reading
1	drop 'writable' from REGISTRY_PACKAGE_RESPONSE_FIELDS	REST	RED — list/detail PKG: writable, 6 drops across 3 packages
2	drop 'installedVersion' from the same allowlist	REST	RED — list/detail PKG: installedVersion, 6 drops
3	reorder to toPackageResponse(withWritableVerdict(...))	runtime	RED — stamp set for com.example.showcase: expected [] to deeply equal [ 'writable' ]
4	drop 'installedVersion' from INSTALLED_PACKAGE_RESPONSE_FIELDS	runtime	RED — list/detail PKG: installedVersion, 6 drops
control	tree restored	both	GREEN — REST 4/4, runtime 5/5

Leg 1 is the exact near-miss the card is about. Leg 3 is the exact regression the
runtime door's ordering comment warns about. Legs 2 and 4 are the generality
claim: a plain declared field, with no field-specific pin anywhere.

No rebuild leg is involved and none is owed. Both mutated files are resolved
by vitest as local source — the REST pin imports ./package-routes.js, the
runtime pin reaches ./domains/packages.js through ../http-dispatcher.js — so
dist/ is not on the resolution path for either subject and there is nothing to
preflight. The restore leg is proven by git diff HEAD being empty for both
doors after every leg, not by the restore command's exit code.

Two findings the ablation produced, both now fixed in this PR

Recording these because in both cases the first version of the gate was green
for a bad reason, and a reviewer should see that the readings above are not the
first ones taken.

1. Object.keys was the wrong instrument.installPackage seats settings
   as an own property holding undefined. Both doors omit undefined-valued
   fields deliberately, and JSON.stringify drops them anyway, so the first run
   reported six false drops for a key no consumer could ever have observed. The
   detector now measures defined-valued keys.

2. The fixture could not see two thirds of the record. Deleting
   installedVersion from either allowlist left both gates green on the
   first ablation: installPackage writes only the fields an install can know,
   so six of the twelve declared fields are simply absent from a freshly
   installed record. seatDeclaredFields now seats every field the record
   schema declares, and a control assertion fails if any declared slot becomes
   unobservable again.

On packages/spec

The card rules out deriving the production allowlist from packages/spec,
and this PR does not: both allowlists stay hand-written and are untouched. What
finding 2 derives from the schema is the test's expectation, which is the
card's own wording for the detector — "the projected key set ⊇ the producer's
stamped/declared key set minus an explicit, annotated exclusion list".
Deriving the expectation is precisely what turns a newly declared field into an
explicit decision at each door instead of a silent omission. It adds no import
edge either: @objectstack/spec is already a runtime dependency of both
packages. The rationale is spelled out at DECLARED_RECORD_KEYS in both files so
it cannot be mistaken for the rejected design.

Why two pins rather than one detector

Measured, not assumed. A single file would have to reach the other package's
door:

• From packages/runtime, @objectstack/rest resolves to its dist/ (no
  vitest alias maps it to source), which would make the gate's verdict a function
  of build state. It would also growKNOWN_UNALIASED_TEST_IMPORTS in
  scripts/check-test-source-alias.mjs, a shrink-only registry that lists no
  @objectstack/rest entry for that package today.
• @objectstack/rest cannot import @objectstack/runtime at all — the
  dependency runs the other way.

So: two pins, one shape. Each imports its own door as source, which is also
what lets a reviewer ablate one allowlist and watch exactly one gate go red.

What I did NOT do, and why

• Did not change either allowlist. Both are correct today; the card asked for
  the detector, not an edit to the lists.
• Did not touch packages/rest/src/error-response.ts (hot file, PR fix(rest): consult the bespoke structured arms before the declared-status passthrough, so both error doors answer one refusal with one body #14713).
• Did not add a changeset. The diff is two test files and nothing else. No
  package publishes a test file, so nothing user-visible ships. skip-changeset
  applied.
• Did not widen a CI filter root or add a CI job.
• Did not add anything to packages/runtime/test-typecheck-debt.json, and did
  not need to — see Verification. That ledger is byte-identical to origin/main
  in this branch.
• Did not silence anything to reach green. No any, @ts-expect-error, or
  eslint-disable was added anywhere, and no assertion was weakened. The
  load-bearing comparison — set equality on the stamp set — runs over
  Set(string) and string[], not any.

Verification

All readings from 47181632f2, the merge commit at the head of this branch.
The dependency closure was built first (pnpm --filter '@objectstack/runtime^...' build),
because an unbuilt closure turns every workspace import into TS2307 and makes a
typecheck verdict a statement about a different world.

The runtime test-layer typecheck, which the merge newly applies to this PR

pnpm --filter @objectstack/runtime typecheck — EXIT=0. It now chains
check:test-typecheck, whose own verdict line is:

check:test-typecheck: OK — @objectstack/runtime's test layer compiles under
packages/runtime/tsconfig.test.json; 27 file(s) / 191 error(s) / 69 pinned
signature(s) held in test-typecheck-debt.json (shrink-only and identity-pinned)

Three separate confirmations that the new runtime pin is genuinely covered and
carries no debt:

• tsc --noEmit --project tsconfig.test.json --listFiles shows 1 hit for
  src/domains/package-door-producer-key-carry.test.ts — it is in the program.
  (This replaces the pre-merge reading of 0 hits, which was true on the old base
  and is now false.)
• Error lines naming that file in the same run: 0. The 191 errors are exactly
  the ledgered ones in the other 27 files.
• packages/runtime/test-typecheck-debt.json is byte-identical to
  origin/main's copy — nothing added, no number moved.

Other green

• packages/rest gate — 4/4; packages/runtime gate — 5/5.
• Sibling door pins re-run beside them after the merge:
  package-registry-item-projection, package-list-writable-carry,
  packages-serializable-response, packages-writable-verdict — 3 files /
  14 tests and 3 files / 23 tests, both EXIT=0.
• pnpm --filter @objectstack/rest typecheck — EXIT=0, with --listFiles
  confirming 1 hit for the new REST test file.
• 25 of the 28 gate families derived by scripts/pm/dispatch-gates.mjs --commands
  — exit 0, re-derived and re-run on the merged head (the family list is
  unchanged, and the change set is still exactly these two files).
  check:engine-double-contract was RED early on (my fixture's findOne double)
  and is green after removing that verb, which the producer path never calls.

Not measured, with the reason

• check:dual-build-cjs-loads and check:type-check-debt --re-measure — exit
  3, "PREREQUISITE NOT MET": both need the whole workspace built
  (turbo run build --filter='./packages/*' --filter='./packages/*/*'), not just
  one closure. Exit 3 is neither a pass nor a finding. The sub-measurement that
  this diff could actually have moved — the runtime test-layer debt — is answered
  directly above by check:test-typecheck at EXIT=0 with the ledger unchanged.
  And check:dual-build-cjs-loads reads built output, which a diff adding only
  *.test.ts files cannot reach.
• check-test-completeness — exit 3; it needs a saved turbo run test log,
  and its own failure text says to record it NOT MEASURED when run locally.

Narrowed, declared

The two packages' FULL suites were not run. Nine attempts on the shared verify
lock across this branch never got a long enough turn — holders included one run
at 917s and another at 1704s — and @objectstack/runtime's whole suite exceeds
what fits inside the container's foreground cap on a shared box. Narrowed to the
two new files plus the four sibling pins on the same two doors, all green above.
The diff modifies no production file, no config, and no turbo/vitest setting, so
the only way a sibling test's verdict could move is cross-file interference
inside a vitest worker; CI runs the full sharded suite on this PR regardless.

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

Nothing in this diff resolved to a documentable surface (no symbol, route or SDK anchor derived from 0 changed package(s)), so this run has no opinion about the docs.

What this run could not see

• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.

Coarse fallback — 0 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json f116b8f8d1b43ec2bfd64fbf0ebb0cf3c301b1c8 → packageMentionDocs.

[os-trump]

Fixes#14642

A gate that goes red when a /packages door's field allowlist drops a key the
producer stamps or the record declares. Both sides of the comparison are derived
by running real code; the only hand-kept artifacts are two annotated registers,
both compared loudly.

Session: https://claude.ai/code/session_016yfqQh2dBgPAymYd7xipza

File face

Two files, both new, both tests:

• packages/rest/src/package-door-producer-key-carry.test.ts
• packages/runtime/src/domains/package-door-producer-key-carry.test.ts

No production file is modified. In particular packages/rest/src/error-response.ts
is not touched — PR #14713 is in flight on it and the gate's honest landing
site was never that file. No CI job added, no CI filter root widened.

Base refreshed by mergingorigin/main (not rebasing, no force-push) at
47181632f2. That merge matters: PR #14785 landed packages/runtime/tsconfig.test.json
while this branch was open, so the runtime pin is now compiled by a real tsc
program. See Verification.

Is the near-miss still reachable on today's main?

• For writable itself: no. Both doors carry it now, by two different
  mechanisms, and both are pinned by name (package-list-writable-carry.test.ts,
  packages-serializable-response.test.ts).
• For the general case: yes, fully reachable. Nothing generalised past that
  one field. The ablation below reintroduces the drop four different ways and
  every one of them shipped a 200 with a field silently absent before this PR.

So the card's premise stands, with the triage comment's sharpening: the gap is
the next stamped or declared key, not writable.

The two doors do not share an invariant, and the gate does not pretend they do

	REST door	runtime door
producer	getMetaItems({type:'package'})	registry.getAllPackages()
where writable comes from	stamped upstream, listed in the allowlist	computed at the door, deliberately not in the allowlist
invariant	the allowlist contains every stamped key	the stamp runs after the projection

Asserting "the allowlist contains every stamped key" at the runtime door would
red on a correct door. So the runtime pin measures the stamp set as
served − record — never a list — and compares it for set equality against
an annotated register. A reorder empties that measured set and reds; a new stamp
grows it and reds until the decision is written down. That register is hand-kept
on purpose: swapping a silent list for a loud one is the mechanism this card
asked for.

Both gate readings

Four ablation legs, each mutating one production line, each restored and proven
restored. The mutation is proven on disk by an anchor count before/after, never
by the editor's exit code. Re-run in full after the merge; every number below
is identical before and after, so the merge moved nothing.

leg	mutation	gate	reading
1	drop 'writable' from REGISTRY_PACKAGE_RESPONSE_FIELDS	REST	RED — list/detail PKG: writable, 6 drops across 3 packages
2	drop 'installedVersion' from the same allowlist	REST	RED — list/detail PKG: installedVersion, 6 drops
3	reorder to toPackageResponse(withWritableVerdict(...))	runtime	RED — stamp set for com.example.showcase: expected [] to deeply equal [ 'writable' ]
4	drop 'installedVersion' from INSTALLED_PACKAGE_RESPONSE_FIELDS	runtime	RED — list/detail PKG: installedVersion, 6 drops
control	tree restored	both	GREEN — REST 4/4, runtime 5/5

Leg 1 is the exact near-miss the card is about. Leg 3 is the exact regression the
runtime door's ordering comment warns about. Legs 2 and 4 are the generality
claim: a plain declared field, with no field-specific pin anywhere.

No rebuild leg is involved and none is owed. Both mutated files are resolved
by vitest as local source — the REST pin imports ./package-routes.js, the
runtime pin reaches ./domains/packages.js through ../http-dispatcher.js — so
dist/ is not on the resolution path for either subject and there is nothing to
preflight. The restore leg is proven by git diff HEAD being empty for both
doors after every leg, not by the restore command's exit code.

Two findings the ablation produced, both now fixed in this PR

Recording these because in both cases the first version of the gate was green
for a bad reason, and a reviewer should see that the readings above are not the
first ones taken.

1. Object.keys was the wrong instrument.installPackage seats settings
   as an own property holding undefined. Both doors omit undefined-valued
   fields deliberately, and JSON.stringify drops them anyway, so the first run
   reported six false drops for a key no consumer could ever have observed. The
   detector now measures defined-valued keys.

2. The fixture could not see two thirds of the record. Deleting
   installedVersion from either allowlist left both gates green on the
   first ablation: installPackage writes only the fields an install can know,
   so six of the twelve declared fields are simply absent from a freshly
   installed record. seatDeclaredFields now seats every field the record
   schema declares, and a control assertion fails if any declared slot becomes
   unobservable again.

On packages/spec

The card rules out deriving the production allowlist from packages/spec,
and this PR does not: both allowlists stay hand-written and are untouched. What
finding 2 derives from the schema is the test's expectation, which is the
card's own wording for the detector — "the projected key set ⊇ the producer's
stamped/declared key set minus an explicit, annotated exclusion list".
Deriving the expectation is precisely what turns a newly declared field into an
explicit decision at each door instead of a silent omission. It adds no import
edge either: @objectstack/spec is already a runtime dependency of both
packages. The rationale is spelled out at DECLARED_RECORD_KEYS in both files so
it cannot be mistaken for the rejected design.

Why two pins rather than one detector

Measured, not assumed. A single file would have to reach the other package's
door:

• From packages/runtime, @objectstack/rest resolves to its dist/ (no
  vitest alias maps it to source), which would make the gate's verdict a function
  of build state. It would also growKNOWN_UNALIASED_TEST_IMPORTS in
  scripts/check-test-source-alias.mjs, a shrink-only registry that lists no
  @objectstack/rest entry for that package today.
• @objectstack/rest cannot import @objectstack/runtime at all — the
  dependency runs the other way.

So: two pins, one shape. Each imports its own door as source, which is also
what lets a reviewer ablate one allowlist and watch exactly one gate go red.

What I did NOT do, and why

• Did not change either allowlist. Both are correct today; the card asked for
  the detector, not an edit to the lists.
• Did not touch packages/rest/src/error-response.ts (hot file, PR fix(rest): consult the bespoke structured arms before the declared-status passthrough, so both error doors answer one refusal with one body #14713).
• Did not add a changeset. The diff is two test files and nothing else. No
  package publishes a test file, so nothing user-visible ships. skip-changeset
  applied.
• Did not widen a CI filter root or add a CI job.
• Did not add anything to packages/runtime/test-typecheck-debt.json, and did
  not need to — see Verification. That ledger is byte-identical to origin/main
  in this branch.
• Did not silence anything to reach green. No any, @ts-expect-error, or
  eslint-disable was added anywhere, and no assertion was weakened. The
  load-bearing comparison — set equality on the stamp set — runs over
  Set(string) and string[], not any.

Verification

All readings from 47181632f2, the merge commit at the head of this branch.
The dependency closure was built first (pnpm --filter '@objectstack/runtime^...' build),
because an unbuilt closure turns every workspace import into TS2307 and makes a
typecheck verdict a statement about a different world.

The runtime test-layer typecheck, which the merge newly applies to this PR

pnpm --filter @objectstack/runtime typecheck — EXIT=0. It now chains
check:test-typecheck, whose own verdict line is:

check:test-typecheck: OK — @objectstack/runtime's test layer compiles under
packages/runtime/tsconfig.test.json; 27 file(s) / 191 error(s) / 69 pinned
signature(s) held in test-typecheck-debt.json (shrink-only and identity-pinned)

Three separate confirmations that the new runtime pin is genuinely covered and
carries no debt:

• tsc --noEmit --project tsconfig.test.json --listFiles shows 1 hit for
  src/domains/package-door-producer-key-carry.test.ts — it is in the program.
  (This replaces the pre-merge reading of 0 hits, which was true on the old base
  and is now false.)
• Error lines naming that file in the same run: 0. The 191 errors are exactly
  the ledgered ones in the other 27 files.
• packages/runtime/test-typecheck-debt.json is byte-identical to
  origin/main's copy — nothing added, no number moved.

Other green

• packages/rest gate — 4/4; packages/runtime gate — 5/5.
• Sibling door pins re-run beside them after the merge:
  package-registry-item-projection, package-list-writable-carry,
  packages-serializable-response, packages-writable-verdict — 3 files /
  14 tests and 3 files / 23 tests, both EXIT=0.
• pnpm --filter @objectstack/rest typecheck — EXIT=0, with --listFiles
  confirming 1 hit for the new REST test file.
• 25 of the 28 gate families derived by scripts/pm/dispatch-gates.mjs --commands
  — exit 0, re-derived and re-run on the merged head (the family list is
  unchanged, and the change set is still exactly these two files).
  check:engine-double-contract was RED early on (my fixture's findOne double)
  and is green after removing that verb, which the producer path never calls.

Not measured, with the reason

• check:dual-build-cjs-loads and check:type-check-debt --re-measure — exit
  3, "PREREQUISITE NOT MET": both need the whole workspace built
  (turbo run build --filter='./packages/*' --filter='./packages/*/*'), not just
  one closure. Exit 3 is neither a pass nor a finding. The sub-measurement that
  this diff could actually have moved — the runtime test-layer debt — is answered
  directly above by check:test-typecheck at EXIT=0 with the ledger unchanged.
  And check:dual-build-cjs-loads reads built output, which a diff adding only
  *.test.ts files cannot reach.
• check-test-completeness — exit 3; it needs a saved turbo run test log,
  and its own failure text says to record it NOT MEASURED when run locally.

Narrowed, declared

The two packages' FULL suites were not run. Nine attempts on the shared verify
lock across this branch never got a long enough turn — holders included one run
at 917s and another at 1704s — and @objectstack/runtime's whole suite exceeds
what fits inside the container's foreground cap on a shared box. Narrowed to the
two new files plus the four sibling pins on the same two doors, all green above.
The diff modifies no production file, no config, and no turbo/vitest setting, so
the only way a sibling test's verdict could move is cross-file interference
inside a vitest worker; CI runs the full sharded suite on this PR regardless.

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

Nothing in this diff resolved to a documentable surface (no symbol, route or SDK anchor derived from 0 changed package(s)), so this run has no opinion about the docs.

What this run could not see

• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.

Coarse fallback — 0 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json f116b8f8d1b43ec2bfd64fbf0ebb0cf3c301b1c8 → packageMentionDocs.

[os-trump]

Fixes#14642

A gate that goes red when a /packages door's field allowlist drops a key the
producer stamps or the record declares. Both sides of the comparison are derived
by running real code; the only hand-kept artifacts are two annotated registers,
both compared loudly.

Session: https://claude.ai/code/session_016yfqQh2dBgPAymYd7xipza

File face

Two files, both new, both tests:

• packages/rest/src/package-door-producer-key-carry.test.ts
• packages/runtime/src/domains/package-door-producer-key-carry.test.ts

No production file is modified. In particular packages/rest/src/error-response.ts
is not touched — PR #14713 is in flight on it and the gate's honest landing
site was never that file. No CI job added, no CI filter root widened.

Base refreshed by mergingorigin/main (not rebasing, no force-push) at
47181632f2. That merge matters: PR #14785 landed packages/runtime/tsconfig.test.json
while this branch was open, so the runtime pin is now compiled by a real tsc
program. See Verification.

Is the near-miss still reachable on today's main?

• For writable itself: no. Both doors carry it now, by two different
  mechanisms, and both are pinned by name (package-list-writable-carry.test.ts,
  packages-serializable-response.test.ts).
• For the general case: yes, fully reachable. Nothing generalised past that
  one field. The ablation below reintroduces the drop four different ways and
  every one of them shipped a 200 with a field silently absent before this PR.

So the card's premise stands, with the triage comment's sharpening: the gap is
the next stamped or declared key, not writable.

The two doors do not share an invariant, and the gate does not pretend they do

	REST door	runtime door
producer	getMetaItems({type:'package'})	registry.getAllPackages()
where writable comes from	stamped upstream, listed in the allowlist	computed at the door, deliberately not in the allowlist
invariant	the allowlist contains every stamped key	the stamp runs after the projection

Asserting "the allowlist contains every stamped key" at the runtime door would
red on a correct door. So the runtime pin measures the stamp set as
served − record — never a list — and compares it for set equality against
an annotated register. A reorder empties that measured set and reds; a new stamp
grows it and reds until the decision is written down. That register is hand-kept
on purpose: swapping a silent list for a loud one is the mechanism this card
asked for.

Both gate readings

Four ablation legs, each mutating one production line, each restored and proven
restored. The mutation is proven on disk by an anchor count before/after, never
by the editor's exit code. Re-run in full after the merge; every number below
is identical before and after, so the merge moved nothing.

leg	mutation	gate	reading
1	drop 'writable' from REGISTRY_PACKAGE_RESPONSE_FIELDS	REST	RED — list/detail PKG: writable, 6 drops across 3 packages
2	drop 'installedVersion' from the same allowlist	REST	RED — list/detail PKG: installedVersion, 6 drops
3	reorder to toPackageResponse(withWritableVerdict(...))	runtime	RED — stamp set for com.example.showcase: expected [] to deeply equal [ 'writable' ]
4	drop 'installedVersion' from INSTALLED_PACKAGE_RESPONSE_FIELDS	runtime	RED — list/detail PKG: installedVersion, 6 drops
control	tree restored	both	GREEN — REST 4/4, runtime 5/5

Leg 1 is the exact near-miss the card is about. Leg 3 is the exact regression the
runtime door's ordering comment warns about. Legs 2 and 4 are the generality
claim: a plain declared field, with no field-specific pin anywhere.

No rebuild leg is involved and none is owed. Both mutated files are resolved
by vitest as local source — the REST pin imports ./package-routes.js, the
runtime pin reaches ./domains/packages.js through ../http-dispatcher.js — so
dist/ is not on the resolution path for either subject and there is nothing to
preflight. The restore leg is proven by git diff HEAD being empty for both
doors after every leg, not by the restore command's exit code.

Two findings the ablation produced, both now fixed in this PR

Recording these because in both cases the first version of the gate was green
for a bad reason, and a reviewer should see that the readings above are not the
first ones taken.

1. Object.keys was the wrong instrument.installPackage seats settings
   as an own property holding undefined. Both doors omit undefined-valued
   fields deliberately, and JSON.stringify drops them anyway, so the first run
   reported six false drops for a key no consumer could ever have observed. The
   detector now measures defined-valued keys.

2. The fixture could not see two thirds of the record. Deleting
   installedVersion from either allowlist left both gates green on the
   first ablation: installPackage writes only the fields an install can know,
   so six of the twelve declared fields are simply absent from a freshly
   installed record. seatDeclaredFields now seats every field the record
   schema declares, and a control assertion fails if any declared slot becomes
   unobservable again.

On packages/spec

The card rules out deriving the production allowlist from packages/spec,
and this PR does not: both allowlists stay hand-written and are untouched. What
finding 2 derives from the schema is the test's expectation, which is the
card's own wording for the detector — "the projected key set ⊇ the producer's
stamped/declared key set minus an explicit, annotated exclusion list".
Deriving the expectation is precisely what turns a newly declared field into an
explicit decision at each door instead of a silent omission. It adds no import
edge either: @objectstack/spec is already a runtime dependency of both
packages. The rationale is spelled out at DECLARED_RECORD_KEYS in both files so
it cannot be mistaken for the rejected design.

Why two pins rather than one detector

Measured, not assumed. A single file would have to reach the other package's
door:

• From packages/runtime, @objectstack/rest resolves to its dist/ (no
  vitest alias maps it to source), which would make the gate's verdict a function
  of build state. It would also growKNOWN_UNALIASED_TEST_IMPORTS in
  scripts/check-test-source-alias.mjs, a shrink-only registry that lists no
  @objectstack/rest entry for that package today.
• @objectstack/rest cannot import @objectstack/runtime at all — the
  dependency runs the other way.

So: two pins, one shape. Each imports its own door as source, which is also
what lets a reviewer ablate one allowlist and watch exactly one gate go red.

What I did NOT do, and why

• Did not change either allowlist. Both are correct today; the card asked for
  the detector, not an edit to the lists.
• Did not touch packages/rest/src/error-response.ts (hot file, PR fix(rest): consult the bespoke structured arms before the declared-status passthrough, so both error doors answer one refusal with one body #14713).
• Did not add a changeset. The diff is two test files and nothing else. No
  package publishes a test file, so nothing user-visible ships. skip-changeset
  applied.
• Did not widen a CI filter root or add a CI job.
• Did not add anything to packages/runtime/test-typecheck-debt.json, and did
  not need to — see Verification. That ledger is byte-identical to origin/main
  in this branch.
• Did not silence anything to reach green. No any, @ts-expect-error, or
  eslint-disable was added anywhere, and no assertion was weakened. The
  load-bearing comparison — set equality on the stamp set — runs over
  Set(string) and string[], not any.

Verification

All readings from 47181632f2, the merge commit at the head of this branch.
The dependency closure was built first (pnpm --filter '@objectstack/runtime^...' build),
because an unbuilt closure turns every workspace import into TS2307 and makes a
typecheck verdict a statement about a different world.

The runtime test-layer typecheck, which the merge newly applies to this PR

pnpm --filter @objectstack/runtime typecheck — EXIT=0. It now chains
check:test-typecheck, whose own verdict line is:

check:test-typecheck: OK — @objectstack/runtime's test layer compiles under
packages/runtime/tsconfig.test.json; 27 file(s) / 191 error(s) / 69 pinned
signature(s) held in test-typecheck-debt.json (shrink-only and identity-pinned)

Three separate confirmations that the new runtime pin is genuinely covered and
carries no debt:

• tsc --noEmit --project tsconfig.test.json --listFiles shows 1 hit for
  src/domains/package-door-producer-key-carry.test.ts — it is in the program.
  (This replaces the pre-merge reading of 0 hits, which was true on the old base
  and is now false.)
• Error lines naming that file in the same run: 0. The 191 errors are exactly
  the ledgered ones in the other 27 files.
• packages/runtime/test-typecheck-debt.json is byte-identical to
  origin/main's copy — nothing added, no number moved.

Other green

• packages/rest gate — 4/4; packages/runtime gate — 5/5.
• Sibling door pins re-run beside them after the merge:
  package-registry-item-projection, package-list-writable-carry,
  packages-serializable-response, packages-writable-verdict — 3 files /
  14 tests and 3 files / 23 tests, both EXIT=0.
• pnpm --filter @objectstack/rest typecheck — EXIT=0, with --listFiles
  confirming 1 hit for the new REST test file.
• 25 of the 28 gate families derived by scripts/pm/dispatch-gates.mjs --commands
  — exit 0, re-derived and re-run on the merged head (the family list is
  unchanged, and the change set is still exactly these two files).
  check:engine-double-contract was RED early on (my fixture's findOne double)
  and is green after removing that verb, which the producer path never calls.

Not measured, with the reason

• check:dual-build-cjs-loads and check:type-check-debt --re-measure — exit
  3, "PREREQUISITE NOT MET": both need the whole workspace built
  (turbo run build --filter='./packages/*' --filter='./packages/*/*'), not just
  one closure. Exit 3 is neither a pass nor a finding. The sub-measurement that
  this diff could actually have moved — the runtime test-layer debt — is answered
  directly above by check:test-typecheck at EXIT=0 with the ledger unchanged.
  And check:dual-build-cjs-loads reads built output, which a diff adding only
  *.test.ts files cannot reach.
• check-test-completeness — exit 3; it needs a saved turbo run test log,
  and its own failure text says to record it NOT MEASURED when run locally.

Narrowed, declared

The two packages' FULL suites were not run. Nine attempts on the shared verify
lock across this branch never got a long enough turn — holders included one run
at 917s and another at 1704s — and @objectstack/runtime's whole suite exceeds
what fits inside the container's foreground cap on a shared box. Narrowed to the
two new files plus the four sibling pins on the same two doors, all green above.
The diff modifies no production file, no config, and no turbo/vitest setting, so
the only way a sibling test's verdict could move is cross-file interference
inside a vitest worker; CI runs the full sharded suite on this PR regardless.

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

Nothing in this diff resolved to a documentable surface (no symbol, route or SDK anchor derived from 0 changed package(s)), so this run has no opinion about the docs.

What this run could not see

• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.

Coarse fallback — 0 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json f116b8f8d1b43ec2bfd64fbf0ebb0cf3c301b1c8 → packageMentionDocs.

[os-trump]

Fixes#14642

A gate that goes red when a /packages door's field allowlist drops a key the
producer stamps or the record declares. Both sides of the comparison are derived
by running real code; the only hand-kept artifacts are two annotated registers,
both compared loudly.

Session: https://claude.ai/code/session_016yfqQh2dBgPAymYd7xipza

File face

Two files, both new, both tests:

• packages/rest/src/package-door-producer-key-carry.test.ts
• packages/runtime/src/domains/package-door-producer-key-carry.test.ts

No production file is modified. In particular packages/rest/src/error-response.ts
is not touched — PR #14713 is in flight on it and the gate's honest landing
site was never that file. No CI job added, no CI filter root widened.

Base refreshed by mergingorigin/main (not rebasing, no force-push) at
47181632f2. That merge matters: PR #14785 landed packages/runtime/tsconfig.test.json
while this branch was open, so the runtime pin is now compiled by a real tsc
program. See Verification.

Is the near-miss still reachable on today's main?

• For writable itself: no. Both doors carry it now, by two different
  mechanisms, and both are pinned by name (package-list-writable-carry.test.ts,
  packages-serializable-response.test.ts).
• For the general case: yes, fully reachable. Nothing generalised past that
  one field. The ablation below reintroduces the drop four different ways and
  every one of them shipped a 200 with a field silently absent before this PR.

So the card's premise stands, with the triage comment's sharpening: the gap is
the next stamped or declared key, not writable.

The two doors do not share an invariant, and the gate does not pretend they do

	REST door	runtime door
producer	getMetaItems({type:'package'})	registry.getAllPackages()
where writable comes from	stamped upstream, listed in the allowlist	computed at the door, deliberately not in the allowlist
invariant	the allowlist contains every stamped key	the stamp runs after the projection

Asserting "the allowlist contains every stamped key" at the runtime door would
red on a correct door. So the runtime pin measures the stamp set as
served − record — never a list — and compares it for set equality against
an annotated register. A reorder empties that measured set and reds; a new stamp
grows it and reds until the decision is written down. That register is hand-kept
on purpose: swapping a silent list for a loud one is the mechanism this card
asked for.

Both gate readings

Four ablation legs, each mutating one production line, each restored and proven
restored. The mutation is proven on disk by an anchor count before/after, never
by the editor's exit code. Re-run in full after the merge; every number below
is identical before and after, so the merge moved nothing.

leg	mutation	gate	reading
1	drop 'writable' from REGISTRY_PACKAGE_RESPONSE_FIELDS	REST	RED — list/detail PKG: writable, 6 drops across 3 packages
2	drop 'installedVersion' from the same allowlist	REST	RED — list/detail PKG: installedVersion, 6 drops
3	reorder to toPackageResponse(withWritableVerdict(...))	runtime	RED — stamp set for com.example.showcase: expected [] to deeply equal [ 'writable' ]
4	drop 'installedVersion' from INSTALLED_PACKAGE_RESPONSE_FIELDS	runtime	RED — list/detail PKG: installedVersion, 6 drops
control	tree restored	both	GREEN — REST 4/4, runtime 5/5

Leg 1 is the exact near-miss the card is about. Leg 3 is the exact regression the
runtime door's ordering comment warns about. Legs 2 and 4 are the generality
claim: a plain declared field, with no field-specific pin anywhere.

No rebuild leg is involved and none is owed. Both mutated files are resolved
by vitest as local source — the REST pin imports ./package-routes.js, the
runtime pin reaches ./domains/packages.js through ../http-dispatcher.js — so
dist/ is not on the resolution path for either subject and there is nothing to
preflight. The restore leg is proven by git diff HEAD being empty for both
doors after every leg, not by the restore command's exit code.

Two findings the ablation produced, both now fixed in this PR

Recording these because in both cases the first version of the gate was green
for a bad reason, and a reviewer should see that the readings above are not the
first ones taken.

1. Object.keys was the wrong instrument.installPackage seats settings
   as an own property holding undefined. Both doors omit undefined-valued
   fields deliberately, and JSON.stringify drops them anyway, so the first run
   reported six false drops for a key no consumer could ever have observed. The
   detector now measures defined-valued keys.

2. The fixture could not see two thirds of the record. Deleting
   installedVersion from either allowlist left both gates green on the
   first ablation: installPackage writes only the fields an install can know,
   so six of the twelve declared fields are simply absent from a freshly
   installed record. seatDeclaredFields now seats every field the record
   schema declares, and a control assertion fails if any declared slot becomes
   unobservable again.

On packages/spec

The card rules out deriving the production allowlist from packages/spec,
and this PR does not: both allowlists stay hand-written and are untouched. What
finding 2 derives from the schema is the test's expectation, which is the
card's own wording for the detector — "the projected key set ⊇ the producer's
stamped/declared key set minus an explicit, annotated exclusion list".
Deriving the expectation is precisely what turns a newly declared field into an
explicit decision at each door instead of a silent omission. It adds no import
edge either: @objectstack/spec is already a runtime dependency of both
packages. The rationale is spelled out at DECLARED_RECORD_KEYS in both files so
it cannot be mistaken for the rejected design.

Why two pins rather than one detector

Measured, not assumed. A single file would have to reach the other package's
door:

• From packages/runtime, @objectstack/rest resolves to its dist/ (no
  vitest alias maps it to source), which would make the gate's verdict a function
  of build state. It would also growKNOWN_UNALIASED_TEST_IMPORTS in
  scripts/check-test-source-alias.mjs, a shrink-only registry that lists no
  @objectstack/rest entry for that package today.
• @objectstack/rest cannot import @objectstack/runtime at all — the
  dependency runs the other way.

So: two pins, one shape. Each imports its own door as source, which is also
what lets a reviewer ablate one allowlist and watch exactly one gate go red.

What I did NOT do, and why

• Did not change either allowlist. Both are correct today; the card asked for
  the detector, not an edit to the lists.
• Did not touch packages/rest/src/error-response.ts (hot file, PR fix(rest): consult the bespoke structured arms before the declared-status passthrough, so both error doors answer one refusal with one body #14713).
• Did not add a changeset. The diff is two test files and nothing else. No
  package publishes a test file, so nothing user-visible ships. skip-changeset
  applied.
• Did not widen a CI filter root or add a CI job.
• Did not add anything to packages/runtime/test-typecheck-debt.json, and did
  not need to — see Verification. That ledger is byte-identical to origin/main
  in this branch.
• Did not silence anything to reach green. No any, @ts-expect-error, or
  eslint-disable was added anywhere, and no assertion was weakened. The
  load-bearing comparison — set equality on the stamp set — runs over
  Set(string) and string[], not any.

Verification

All readings from 47181632f2, the merge commit at the head of this branch.
The dependency closure was built first (pnpm --filter '@objectstack/runtime^...' build),
because an unbuilt closure turns every workspace import into TS2307 and makes a
typecheck verdict a statement about a different world.

The runtime test-layer typecheck, which the merge newly applies to this PR

pnpm --filter @objectstack/runtime typecheck — EXIT=0. It now chains
check:test-typecheck, whose own verdict line is:

check:test-typecheck: OK — @objectstack/runtime's test layer compiles under
packages/runtime/tsconfig.test.json; 27 file(s) / 191 error(s) / 69 pinned
signature(s) held in test-typecheck-debt.json (shrink-only and identity-pinned)

Three separate confirmations that the new runtime pin is genuinely covered and
carries no debt:

• tsc --noEmit --project tsconfig.test.json --listFiles shows 1 hit for
  src/domains/package-door-producer-key-carry.test.ts — it is in the program.
  (This replaces the pre-merge reading of 0 hits, which was true on the old base
  and is now false.)
• Error lines naming that file in the same run: 0. The 191 errors are exactly
  the ledgered ones in the other 27 files.
• packages/runtime/test-typecheck-debt.json is byte-identical to
  origin/main's copy — nothing added, no number moved.

Other green

• packages/rest gate — 4/4; packages/runtime gate — 5/5.
• Sibling door pins re-run beside them after the merge:
  package-registry-item-projection, package-list-writable-carry,
  packages-serializable-response, packages-writable-verdict — 3 files /
  14 tests and 3 files / 23 tests, both EXIT=0.
• pnpm --filter @objectstack/rest typecheck — EXIT=0, with --listFiles
  confirming 1 hit for the new REST test file.
• 25 of the 28 gate families derived by scripts/pm/dispatch-gates.mjs --commands
  — exit 0, re-derived and re-run on the merged head (the family list is
  unchanged, and the change set is still exactly these two files).
  check:engine-double-contract was RED early on (my fixture's findOne double)
  and is green after removing that verb, which the producer path never calls.

Not measured, with the reason

• check:dual-build-cjs-loads and check:type-check-debt --re-measure — exit
  3, "PREREQUISITE NOT MET": both need the whole workspace built
  (turbo run build --filter='./packages/*' --filter='./packages/*/*'), not just
  one closure. Exit 3 is neither a pass nor a finding. The sub-measurement that
  this diff could actually have moved — the runtime test-layer debt — is answered
  directly above by check:test-typecheck at EXIT=0 with the ledger unchanged.
  And check:dual-build-cjs-loads reads built output, which a diff adding only
  *.test.ts files cannot reach.
• check-test-completeness — exit 3; it needs a saved turbo run test log,
  and its own failure text says to record it NOT MEASURED when run locally.

Narrowed, declared

The two packages' FULL suites were not run. Nine attempts on the shared verify
lock across this branch never got a long enough turn — holders included one run
at 917s and another at 1704s — and @objectstack/runtime's whole suite exceeds
what fits inside the container's foreground cap on a shared box. Narrowed to the
two new files plus the four sibling pins on the same two doors, all green above.
The diff modifies no production file, no config, and no turbo/vitest setting, so
the only way a sibling test's verdict could move is cross-file interference
inside a vitest worker; CI runs the full sharded suite on this PR regardless.

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

Nothing in this diff resolved to a documentable surface (no symbol, route or SDK anchor derived from 0 changed package(s)), so this run has no opinion about the docs.

What this run could not see

• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.

Coarse fallback — 0 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json f116b8f8d1b43ec2bfd64fbf0ebb0cf3c301b1c8 → packageMentionDocs.

[os-trump]

Fixes#14642

A gate that goes red when a /packages door's field allowlist drops a key the
producer stamps or the record declares. Both sides of the comparison are derived
by running real code; the only hand-kept artifacts are two annotated registers,
both compared loudly.

Session: https://claude.ai/code/session_016yfqQh2dBgPAymYd7xipza

File face

Two files, both new, both tests:

• packages/rest/src/package-door-producer-key-carry.test.ts
• packages/runtime/src/domains/package-door-producer-key-carry.test.ts

No production file is modified. In particular packages/rest/src/error-response.ts
is not touched — PR #14713 is in flight on it and the gate's honest landing
site was never that file. No CI job added, no CI filter root widened.

Base refreshed by mergingorigin/main (not rebasing, no force-push) at
47181632f2. That merge matters: PR #14785 landed packages/runtime/tsconfig.test.json
while this branch was open, so the runtime pin is now compiled by a real tsc
program. See Verification.

Is the near-miss still reachable on today's main?

• For writable itself: no. Both doors carry it now, by two different
  mechanisms, and both are pinned by name (package-list-writable-carry.test.ts,
  packages-serializable-response.test.ts).
• For the general case: yes, fully reachable. Nothing generalised past that
  one field. The ablation below reintroduces the drop four different ways and
  every one of them shipped a 200 with a field silently absent before this PR.

So the card's premise stands, with the triage comment's sharpening: the gap is
the next stamped or declared key, not writable.

The two doors do not share an invariant, and the gate does not pretend they do

	REST door	runtime door
producer	getMetaItems({type:'package'})	registry.getAllPackages()
where writable comes from	stamped upstream, listed in the allowlist	computed at the door, deliberately not in the allowlist
invariant	the allowlist contains every stamped key	the stamp runs after the projection

Asserting "the allowlist contains every stamped key" at the runtime door would
red on a correct door. So the runtime pin measures the stamp set as
served − record — never a list — and compares it for set equality against
an annotated register. A reorder empties that measured set and reds; a new stamp
grows it and reds until the decision is written down. That register is hand-kept
on purpose: swapping a silent list for a loud one is the mechanism this card
asked for.

Both gate readings

Four ablation legs, each mutating one production line, each restored and proven
restored. The mutation is proven on disk by an anchor count before/after, never
by the editor's exit code. Re-run in full after the merge; every number below
is identical before and after, so the merge moved nothing.

leg	mutation	gate	reading
1	drop 'writable' from REGISTRY_PACKAGE_RESPONSE_FIELDS	REST	RED — list/detail PKG: writable, 6 drops across 3 packages
2	drop 'installedVersion' from the same allowlist	REST	RED — list/detail PKG: installedVersion, 6 drops
3	reorder to toPackageResponse(withWritableVerdict(...))	runtime	RED — stamp set for com.example.showcase: expected [] to deeply equal [ 'writable' ]
4	drop 'installedVersion' from INSTALLED_PACKAGE_RESPONSE_FIELDS	runtime	RED — list/detail PKG: installedVersion, 6 drops
control	tree restored	both	GREEN — REST 4/4, runtime 5/5

Leg 1 is the exact near-miss the card is about. Leg 3 is the exact regression the
runtime door's ordering comment warns about. Legs 2 and 4 are the generality
claim: a plain declared field, with no field-specific pin anywhere.

No rebuild leg is involved and none is owed. Both mutated files are resolved
by vitest as local source — the REST pin imports ./package-routes.js, the
runtime pin reaches ./domains/packages.js through ../http-dispatcher.js — so
dist/ is not on the resolution path for either subject and there is nothing to
preflight. The restore leg is proven by git diff HEAD being empty for both
doors after every leg, not by the restore command's exit code.

Two findings the ablation produced, both now fixed in this PR

Recording these because in both cases the first version of the gate was green
for a bad reason, and a reviewer should see that the readings above are not the
first ones taken.

1. Object.keys was the wrong instrument.installPackage seats settings
   as an own property holding undefined. Both doors omit undefined-valued
   fields deliberately, and JSON.stringify drops them anyway, so the first run
   reported six false drops for a key no consumer could ever have observed. The
   detector now measures defined-valued keys.

2. The fixture could not see two thirds of the record. Deleting
   installedVersion from either allowlist left both gates green on the
   first ablation: installPackage writes only the fields an install can know,
   so six of the twelve declared fields are simply absent from a freshly
   installed record. seatDeclaredFields now seats every field the record
   schema declares, and a control assertion fails if any declared slot becomes
   unobservable again.

On packages/spec

The card rules out deriving the production allowlist from packages/spec,
and this PR does not: both allowlists stay hand-written and are untouched. What
finding 2 derives from the schema is the test's expectation, which is the
card's own wording for the detector — "the projected key set ⊇ the producer's
stamped/declared key set minus an explicit, annotated exclusion list".
Deriving the expectation is precisely what turns a newly declared field into an
explicit decision at each door instead of a silent omission. It adds no import
edge either: @objectstack/spec is already a runtime dependency of both
packages. The rationale is spelled out at DECLARED_RECORD_KEYS in both files so
it cannot be mistaken for the rejected design.

Why two pins rather than one detector

Measured, not assumed. A single file would have to reach the other package's
door:

• From packages/runtime, @objectstack/rest resolves to its dist/ (no
  vitest alias maps it to source), which would make the gate's verdict a function
  of build state. It would also growKNOWN_UNALIASED_TEST_IMPORTS in
  scripts/check-test-source-alias.mjs, a shrink-only registry that lists no
  @objectstack/rest entry for that package today.
• @objectstack/rest cannot import @objectstack/runtime at all — the
  dependency runs the other way.

So: two pins, one shape. Each imports its own door as source, which is also
what lets a reviewer ablate one allowlist and watch exactly one gate go red.

What I did NOT do, and why

• Did not change either allowlist. Both are correct today; the card asked for
  the detector, not an edit to the lists.
• Did not touch packages/rest/src/error-response.ts (hot file, PR fix(rest): consult the bespoke structured arms before the declared-status passthrough, so both error doors answer one refusal with one body #14713).
• Did not add a changeset. The diff is two test files and nothing else. No
  package publishes a test file, so nothing user-visible ships. skip-changeset
  applied.
• Did not widen a CI filter root or add a CI job.
• Did not add anything to packages/runtime/test-typecheck-debt.json, and did
  not need to — see Verification. That ledger is byte-identical to origin/main
  in this branch.
• Did not silence anything to reach green. No any, @ts-expect-error, or
  eslint-disable was added anywhere, and no assertion was weakened. The
  load-bearing comparison — set equality on the stamp set — runs over
  Set(string) and string[], not any.

Verification

All readings from 47181632f2, the merge commit at the head of this branch.
The dependency closure was built first (pnpm --filter '@objectstack/runtime^...' build),
because an unbuilt closure turns every workspace import into TS2307 and makes a
typecheck verdict a statement about a different world.

The runtime test-layer typecheck, which the merge newly applies to this PR

pnpm --filter @objectstack/runtime typecheck — EXIT=0. It now chains
check:test-typecheck, whose own verdict line is:

check:test-typecheck: OK — @objectstack/runtime's test layer compiles under
packages/runtime/tsconfig.test.json; 27 file(s) / 191 error(s) / 69 pinned
signature(s) held in test-typecheck-debt.json (shrink-only and identity-pinned)

Three separate confirmations that the new runtime pin is genuinely covered and
carries no debt:

• tsc --noEmit --project tsconfig.test.json --listFiles shows 1 hit for
  src/domains/package-door-producer-key-carry.test.ts — it is in the program.
  (This replaces the pre-merge reading of 0 hits, which was true on the old base
  and is now false.)
• Error lines naming that file in the same run: 0. The 191 errors are exactly
  the ledgered ones in the other 27 files.
• packages/runtime/test-typecheck-debt.json is byte-identical to
  origin/main's copy — nothing added, no number moved.

Other green

• packages/rest gate — 4/4; packages/runtime gate — 5/5.
• Sibling door pins re-run beside them after the merge:
  package-registry-item-projection, package-list-writable-carry,
  packages-serializable-response, packages-writable-verdict — 3 files /
  14 tests and 3 files / 23 tests, both EXIT=0.
• pnpm --filter @objectstack/rest typecheck — EXIT=0, with --listFiles
  confirming 1 hit for the new REST test file.
• 25 of the 28 gate families derived by scripts/pm/dispatch-gates.mjs --commands
  — exit 0, re-derived and re-run on the merged head (the family list is
  unchanged, and the change set is still exactly these two files).
  check:engine-double-contract was RED early on (my fixture's findOne double)
  and is green after removing that verb, which the producer path never calls.

Not measured, with the reason

• check:dual-build-cjs-loads and check:type-check-debt --re-measure — exit
  3, "PREREQUISITE NOT MET": both need the whole workspace built
  (turbo run build --filter='./packages/*' --filter='./packages/*/*'), not just
  one closure. Exit 3 is neither a pass nor a finding. The sub-measurement that
  this diff could actually have moved — the runtime test-layer debt — is answered
  directly above by check:test-typecheck at EXIT=0 with the ledger unchanged.
  And check:dual-build-cjs-loads reads built output, which a diff adding only
  *.test.ts files cannot reach.
• check-test-completeness — exit 3; it needs a saved turbo run test log,
  and its own failure text says to record it NOT MEASURED when run locally.

Narrowed, declared

The two packages' FULL suites were not run. Nine attempts on the shared verify
lock across this branch never got a long enough turn — holders included one run
at 917s and another at 1704s — and @objectstack/runtime's whole suite exceeds
what fits inside the container's foreground cap on a shared box. Narrowed to the
two new files plus the four sibling pins on the same two doors, all green above.
The diff modifies no production file, no config, and no turbo/vitest setting, so
the only way a sibling test's verdict could move is cross-file interference
inside a vitest worker; CI runs the full sharded suite on this PR regardless.

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

Nothing in this diff resolved to a documentable surface (no symbol, route or SDK anchor derived from 0 changed package(s)), so this run has no opinion about the docs.

What this run could not see

• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.

Coarse fallback — 0 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json f116b8f8d1b43ec2bfd64fbf0ebb0cf3c301b1c8 → packageMentionDocs.

[os-trump]

Fixes#14642

A gate that goes red when a /packages door's field allowlist drops a key the
producer stamps or the record declares. Both sides of the comparison are derived
by running real code; the only hand-kept artifacts are two annotated registers,
both compared loudly.

Session: https://claude.ai/code/session_016yfqQh2dBgPAymYd7xipza

File face

Two files, both new, both tests:

• packages/rest/src/package-door-producer-key-carry.test.ts
• packages/runtime/src/domains/package-door-producer-key-carry.test.ts

No production file is modified. In particular packages/rest/src/error-response.ts
is not touched — PR #14713 is in flight on it and the gate's honest landing
site was never that file. No CI job added, no CI filter root widened.

Base refreshed by mergingorigin/main (not rebasing, no force-push) at
47181632f2. That merge matters: PR #14785 landed packages/runtime/tsconfig.test.json
while this branch was open, so the runtime pin is now compiled by a real tsc
program. See Verification.

Is the near-miss still reachable on today's main?

• For writable itself: no. Both doors carry it now, by two different
  mechanisms, and both are pinned by name (package-list-writable-carry.test.ts,
  packages-serializable-response.test.ts).
• For the general case: yes, fully reachable. Nothing generalised past that
  one field. The ablation below reintroduces the drop four different ways and
  every one of them shipped a 200 with a field silently absent before this PR.

So the card's premise stands, with the triage comment's sharpening: the gap is
the next stamped or declared key, not writable.

The two doors do not share an invariant, and the gate does not pretend they do

	REST door	runtime door
producer	getMetaItems({type:'package'})	registry.getAllPackages()
where writable comes from	stamped upstream, listed in the allowlist	computed at the door, deliberately not in the allowlist
invariant	the allowlist contains every stamped key	the stamp runs after the projection

Asserting "the allowlist contains every stamped key" at the runtime door would
red on a correct door. So the runtime pin measures the stamp set as
served − record — never a list — and compares it for set equality against
an annotated register. A reorder empties that measured set and reds; a new stamp
grows it and reds until the decision is written down. That register is hand-kept
on purpose: swapping a silent list for a loud one is the mechanism this card
asked for.

Both gate readings

Four ablation legs, each mutating one production line, each restored and proven
restored. The mutation is proven on disk by an anchor count before/after, never
by the editor's exit code. Re-run in full after the merge; every number below
is identical before and after, so the merge moved nothing.

leg	mutation	gate	reading
1	drop 'writable' from REGISTRY_PACKAGE_RESPONSE_FIELDS	REST	RED — list/detail PKG: writable, 6 drops across 3 packages
2	drop 'installedVersion' from the same allowlist	REST	RED — list/detail PKG: installedVersion, 6 drops
3	reorder to toPackageResponse(withWritableVerdict(...))	runtime	RED — stamp set for com.example.showcase: expected [] to deeply equal [ 'writable' ]
4	drop 'installedVersion' from INSTALLED_PACKAGE_RESPONSE_FIELDS	runtime	RED — list/detail PKG: installedVersion, 6 drops
control	tree restored	both	GREEN — REST 4/4, runtime 5/5

Leg 1 is the exact near-miss the card is about. Leg 3 is the exact regression the
runtime door's ordering comment warns about. Legs 2 and 4 are the generality
claim: a plain declared field, with no field-specific pin anywhere.

No rebuild leg is involved and none is owed. Both mutated files are resolved
by vitest as local source — the REST pin imports ./package-routes.js, the
runtime pin reaches ./domains/packages.js through ../http-dispatcher.js — so
dist/ is not on the resolution path for either subject and there is nothing to
preflight. The restore leg is proven by git diff HEAD being empty for both
doors after every leg, not by the restore command's exit code.

Two findings the ablation produced, both now fixed in this PR

Recording these because in both cases the first version of the gate was green
for a bad reason, and a reviewer should see that the readings above are not the
first ones taken.

1. Object.keys was the wrong instrument.installPackage seats settings
   as an own property holding undefined. Both doors omit undefined-valued
   fields deliberately, and JSON.stringify drops them anyway, so the first run
   reported six false drops for a key no consumer could ever have observed. The
   detector now measures defined-valued keys.

2. The fixture could not see two thirds of the record. Deleting
   installedVersion from either allowlist left both gates green on the
   first ablation: installPackage writes only the fields an install can know,
   so six of the twelve declared fields are simply absent from a freshly
   installed record. seatDeclaredFields now seats every field the record
   schema declares, and a control assertion fails if any declared slot becomes
   unobservable again.

On packages/spec

The card rules out deriving the production allowlist from packages/spec,
and this PR does not: both allowlists stay hand-written and are untouched. What
finding 2 derives from the schema is the test's expectation, which is the
card's own wording for the detector — "the projected key set ⊇ the producer's
stamped/declared key set minus an explicit, annotated exclusion list".
Deriving the expectation is precisely what turns a newly declared field into an
explicit decision at each door instead of a silent omission. It adds no import
edge either: @objectstack/spec is already a runtime dependency of both
packages. The rationale is spelled out at DECLARED_RECORD_KEYS in both files so
it cannot be mistaken for the rejected design.

Why two pins rather than one detector

Measured, not assumed. A single file would have to reach the other package's
door:

• From packages/runtime, @objectstack/rest resolves to its dist/ (no
  vitest alias maps it to source), which would make the gate's verdict a function
  of build state. It would also growKNOWN_UNALIASED_TEST_IMPORTS in
  scripts/check-test-source-alias.mjs, a shrink-only registry that lists no
  @objectstack/rest entry for that package today.
• @objectstack/rest cannot import @objectstack/runtime at all — the
  dependency runs the other way.

So: two pins, one shape. Each imports its own door as source, which is also
what lets a reviewer ablate one allowlist and watch exactly one gate go red.

What I did NOT do, and why

• Did not change either allowlist. Both are correct today; the card asked for
  the detector, not an edit to the lists.
• Did not touch packages/rest/src/error-response.ts (hot file, PR fix(rest): consult the bespoke structured arms before the declared-status passthrough, so both error doors answer one refusal with one body #14713).
• Did not add a changeset. The diff is two test files and nothing else. No
  package publishes a test file, so nothing user-visible ships. skip-changeset
  applied.
• Did not widen a CI filter root or add a CI job.
• Did not add anything to packages/runtime/test-typecheck-debt.json, and did
  not need to — see Verification. That ledger is byte-identical to origin/main
  in this branch.
• Did not silence anything to reach green. No any, @ts-expect-error, or
  eslint-disable was added anywhere, and no assertion was weakened. The
  load-bearing comparison — set equality on the stamp set — runs over
  Set(string) and string[], not any.

Verification

All readings from 47181632f2, the merge commit at the head of this branch.
The dependency closure was built first (pnpm --filter '@objectstack/runtime^...' build),
because an unbuilt closure turns every workspace import into TS2307 and makes a
typecheck verdict a statement about a different world.

The runtime test-layer typecheck, which the merge newly applies to this PR

pnpm --filter @objectstack/runtime typecheck — EXIT=0. It now chains
check:test-typecheck, whose own verdict line is:

check:test-typecheck: OK — @objectstack/runtime's test layer compiles under
packages/runtime/tsconfig.test.json; 27 file(s) / 191 error(s) / 69 pinned
signature(s) held in test-typecheck-debt.json (shrink-only and identity-pinned)

Three separate confirmations that the new runtime pin is genuinely covered and
carries no debt:

• tsc --noEmit --project tsconfig.test.json --listFiles shows 1 hit for
  src/domains/package-door-producer-key-carry.test.ts — it is in the program.
  (This replaces the pre-merge reading of 0 hits, which was true on the old base
  and is now false.)
• Error lines naming that file in the same run: 0. The 191 errors are exactly
  the ledgered ones in the other 27 files.
• packages/runtime/test-typecheck-debt.json is byte-identical to
  origin/main's copy — nothing added, no number moved.

Other green

• packages/rest gate — 4/4; packages/runtime gate — 5/5.
• Sibling door pins re-run beside them after the merge:
  package-registry-item-projection, package-list-writable-carry,
  packages-serializable-response, packages-writable-verdict — 3 files /
  14 tests and 3 files / 23 tests, both EXIT=0.
• pnpm --filter @objectstack/rest typecheck — EXIT=0, with --listFiles
  confirming 1 hit for the new REST test file.
• 25 of the 28 gate families derived by scripts/pm/dispatch-gates.mjs --commands
  — exit 0, re-derived and re-run on the merged head (the family list is
  unchanged, and the change set is still exactly these two files).
  check:engine-double-contract was RED early on (my fixture's findOne double)
  and is green after removing that verb, which the producer path never calls.

Not measured, with the reason

• check:dual-build-cjs-loads and check:type-check-debt --re-measure — exit
  3, "PREREQUISITE NOT MET": both need the whole workspace built
  (turbo run build --filter='./packages/*' --filter='./packages/*/*'), not just
  one closure. Exit 3 is neither a pass nor a finding. The sub-measurement that
  this diff could actually have moved — the runtime test-layer debt — is answered
  directly above by check:test-typecheck at EXIT=0 with the ledger unchanged.
  And check:dual-build-cjs-loads reads built output, which a diff adding only
  *.test.ts files cannot reach.
• check-test-completeness — exit 3; it needs a saved turbo run test log,
  and its own failure text says to record it NOT MEASURED when run locally.

Narrowed, declared

The two packages' FULL suites were not run. Nine attempts on the shared verify
lock across this branch never got a long enough turn — holders included one run
at 917s and another at 1704s — and @objectstack/runtime's whole suite exceeds
what fits inside the container's foreground cap on a shared box. Narrowed to the
two new files plus the four sibling pins on the same two doors, all green above.
The diff modifies no production file, no config, and no turbo/vitest setting, so
the only way a sibling test's verdict could move is cross-file interference
inside a vitest worker; CI runs the full sharded suite on this PR regardless.

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

Nothing in this diff resolved to a documentable surface (no symbol, route or SDK anchor derived from 0 changed package(s)), so this run has no opinion about the docs.

What this run could not see

• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.

Coarse fallback — 0 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json f116b8f8d1b43ec2bfd64fbf0ebb0cf3c301b1c8 → packageMentionDocs.