test(rest): the meta read-scope stub honours the where and the limit on both sys_metadata_history seams

[claude]

Fixes#13764

The stub engine in packages/rest/src/rest-server-meta-read-org-scope.test.ts discarded
opts.where on bothsys_metadata_history seams — findOne answered null
unconditionally and find handed back every history row unfiltered — and was also
limit-blind, one of the 168 doubles check:objectql-double-limit grandfathers. Both
seams are repaired on one edit, plus the matcher's silent-combinator hole.

There was no live defect and no vacuous claim in the file as it stood: it drove only
PUT /meta/:type/:name, GET /meta/:type/:name and GET /meta/:type, and every
assertion it made its stub genuinely kept. What is repaired is a trap — the file whose
name reads like the obvious home for a /history org-scoping assertion was the one file
where that assertion could not be tested.

The deliverable is the discrimination control, not the green gate

SysMetadataRepository.history() and diffMetaItem filter organization_id by strict
equality and post-filter nothing, so over an unfiltered stub the org predicate is a no-op.
The control mutates the /history door to not forward the organization — the exact
line ...(historyOrganizationId ? ...) inside GET /meta/:type/:name/history — and reads
one assertion, serves the org-scoped change log of an item the active org authored, in
all four cells.

stub	org at the door	that assertion
old, unfiltered	forwarded	PASS
old, unfiltered	dropped	PASS — the vacuity, measured directly
new, partitioned	forwarded	PASS
new, partitioned	dropped	FAIL — expected +0 to be 2

Verbatim, cell 2 (old stub, org dropped):

 ✓ … #13764 the history seams of this harness honour the org partition >
serves the org-scoped change log of an item the active org authored 4ms

and cell 4 (new stub, org dropped):

 × … serves the org-scoped change log of an item the active org authored 11ms
→ the door answered an empty change log for an item whose org partition holds
two events: expected +0 to be 2

Green in both states before, red in exactly one state after. That is the discriminating
power the card is about.

⛔ rest-server.ts is held hard-serial by #13280 and nothing lands in it here. It was
mutated transiently for the measurement only, with the blob hash equal to its HEAD blob
before and after, the removed and injected text counted in both directions, and an empty
git diff HEAD on the restore leg.

The second axis of the control

The two cross-tenant cases were not writable at all against the old stub — they were
red over it with the org forwarded and with it dropped, because an unfiltered read hands
org B org A's rows whatever the door does. They are green over the new stub in both
states. That makes does not serve org A history to org B the assertion that holds the
stub partitioned: the positive case stays green if anyone un-partitions the stub again,
and only the cross-tenant one reddens.

Was findOne's unconditional null load-bearing? Measured: no

Predicted before running, from the production call sites — the only callers of findOne
on that table are getByHash, restoreVersion and resolveMetaItemOrgScope, none of
which a PUT reaches; the write path reads history through find, in nextEventSeq and
nextItemVersion. The sibling harness landed in #13756 implements this exact seam and
drives the same PUT path green, which is the positive control for the prediction.

Confirmed: with the seam honouring the where, all 15 pre-existing assertions stay
green and the file runs 18/18. So the implement form was safe and the refusal form was not
needed on this seam.

Which form on each axis, and why

• where on find — implemented, not refused. Refusal was not available: an
  org-scoping assertion has to be able to read the partition, and a seam that throws on
  every predicate is red in both states rather than discriminating.
• where on findOne — implemented, matching the sibling, once the null was
  measured not load-bearing.
• limit — applied after the filter and by presence, typeof opts?.limit === 'number',
  on both table branches, which is check:objectql-double-limit's shape rule. Every call
  this fixture makes passes no bound, so every existing assertion keeps its meaning.
• unknown WHERE combinators — refused loudly rather than read as a column name. This
  is the one place refusal is right: a double that answers $and by looking for a column
  literally called $and returns a well-formed wrong answer, which is the same silent
  class one level down.

The door's own ?limit= contract and the /diff and non-overridable controls are pinned
by rest-server-meta-history-diff-org-scope.test.ts and are deliberately not copied
here — the gate's own probes exercise the shape rules of the double itself, and
duplicating the sibling's door pins would be redundant coverage rather than new
information.

Baseline ratchet

scripts/objectql-double-limit.baseline.json loses its rest-server-meta-read-org-scope
entry. Not a new baseline row — a ratchet down, which the gate requires in the same
PR; it reconciles in both directions and errored with
baselined file is clean or gone -- ratchet DOWN until the entry was deleted.

Verification

Union derived with scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack after
merging origin/main and after the last edit, harvested with --commands. Everything
below ran at aab1254550, tree clean.

union named 33, ran 33, unreconciled 0

by exact comm -23 of the sorted union against the sorted ran-list — no prefix or fuzzy
matching, and no arithmetic on a hand-kept counter. comm -13 is empty too.

One non-zero exit, and it is NOT MEASURED rather than a finding, in the gate's own
words:

check-test-completeness: PREREQUISITE NOT MET — this gate grades a saved `turbo run test`
log, and no log was named. … the local reading for this gate is NOT MEASURED.
⛔ It is not a red, and there is nothing here to fix. (exit 3, distinct from a finding's 1)

The two gates this change is really answerable to, quoting their own verdict lines:

OK ObjectQL double `limit` conformance holds: 296 double(s) graded, 97 apply the
caller's bound or refuse it loudly.
167 limit-blind, 32 shape-breaking and 55 unjudged double(s) in 252 grandfathered
file(s); none new.
baseline key set verified against 16c3601: no files added.
✓ where-matcher conformance holds: 321 matcher(s) discovered, 321 answer the combinator
battery correctly or refuse it loudly (202 refuse).

Also run, all exit 0:

• pnpm --filter @objectstack/rest test — 164 files, 2764 tests, all passed
• pnpm --filter @objectstack/rest typecheck — check:test-typecheck: OK. The edited
  file was confirmed present in that program by tsc --listFiles (1 hit, with the sibling
  harness as the positive control), so the green really covers it. The 2 remaining tsc
  errors are the pre-existing pinned src/rest.test.ts debt held by The 2 remaining ledgered TS2345 in packages/rest are hand-built IHttpResponse literals — they were masked by the request literals, not absent #13454; zero come
  from this diff.
• pnpm lint — the whole repo, eslint . --no-inline-config, exit 0 in 85s. No
  narrowing claimed and none needed.
• pnpm check:nul-bytes — OK (scanned 7598 text file(s) … no raw ASCII control bytes),
  plus a direct control-byte scan over both edited files.

Changeset

Proposed: the skip-changeset label, and this is a reading rather than a preference.
packages/rest's manifest declares files: ["dist", "README.md", "CHANGELOG.md"], and
npm pack --dry-run reports an 8-file tarball that does not contain the edited test
file, with dist/index.js present as the control that the reading is real. The other file
is a CI-internal gate ledger. So the change publishes nothing from any package.

The seat rule says to prefer release noise over a silent gate bypass when the two readings
conflict — here they do not, and the bypass surface was measured rather than assumed:
Check Changeset runs exactly three substantive steps, and this diff adds no changeset at
all (so there is no empty-frontmatter file to reject) and declares no breaking change (so
no ADR-0087 disposition is owed). The one thing that stretches the closed list is that the
baseline ledger sits in scripts/ rather than scripts/pm/; it is the gate's mandatory
same-PR companion to the test edit and cannot be split out.

Generated by Claude Code

---

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 86e765a7704eff4de2eb070330ff66a0e211c3aa → packageMentionDocs.

[claude]

Fixes#13764

The stub engine in packages/rest/src/rest-server-meta-read-org-scope.test.ts discarded
opts.where on bothsys_metadata_history seams — findOne answered null
unconditionally and find handed back every history row unfiltered — and was also
limit-blind, one of the 168 doubles check:objectql-double-limit grandfathers. Both
seams are repaired on one edit, plus the matcher's silent-combinator hole.

There was no live defect and no vacuous claim in the file as it stood: it drove only
PUT /meta/:type/:name, GET /meta/:type/:name and GET /meta/:type, and every
assertion it made its stub genuinely kept. What is repaired is a trap — the file whose
name reads like the obvious home for a /history org-scoping assertion was the one file
where that assertion could not be tested.

The deliverable is the discrimination control, not the green gate

SysMetadataRepository.history() and diffMetaItem filter organization_id by strict
equality and post-filter nothing, so over an unfiltered stub the org predicate is a no-op.
The control mutates the /history door to not forward the organization — the exact
line ...(historyOrganizationId ? ...) inside GET /meta/:type/:name/history — and reads
one assertion, serves the org-scoped change log of an item the active org authored, in
all four cells.

stub	org at the door	that assertion
old, unfiltered	forwarded	PASS
old, unfiltered	dropped	PASS — the vacuity, measured directly
new, partitioned	forwarded	PASS
new, partitioned	dropped	FAIL — expected +0 to be 2

Verbatim, cell 2 (old stub, org dropped):

 ✓ … #13764 the history seams of this harness honour the org partition >
serves the org-scoped change log of an item the active org authored 4ms

and cell 4 (new stub, org dropped):

 × … serves the org-scoped change log of an item the active org authored 11ms
→ the door answered an empty change log for an item whose org partition holds
two events: expected +0 to be 2

Green in both states before, red in exactly one state after. That is the discriminating
power the card is about.

⛔ rest-server.ts is held hard-serial by #13280 and nothing lands in it here. It was
mutated transiently for the measurement only, with the blob hash equal to its HEAD blob
before and after, the removed and injected text counted in both directions, and an empty
git diff HEAD on the restore leg.

The second axis of the control

The two cross-tenant cases were not writable at all against the old stub — they were
red over it with the org forwarded and with it dropped, because an unfiltered read hands
org B org A's rows whatever the door does. They are green over the new stub in both
states. That makes does not serve org A history to org B the assertion that holds the
stub partitioned: the positive case stays green if anyone un-partitions the stub again,
and only the cross-tenant one reddens.

Was findOne's unconditional null load-bearing? Measured: no

Predicted before running, from the production call sites — the only callers of findOne
on that table are getByHash, restoreVersion and resolveMetaItemOrgScope, none of
which a PUT reaches; the write path reads history through find, in nextEventSeq and
nextItemVersion. The sibling harness landed in #13756 implements this exact seam and
drives the same PUT path green, which is the positive control for the prediction.

Confirmed: with the seam honouring the where, all 15 pre-existing assertions stay
green and the file runs 18/18. So the implement form was safe and the refusal form was not
needed on this seam.

Which form on each axis, and why

• where on find — implemented, not refused. Refusal was not available: an
  org-scoping assertion has to be able to read the partition, and a seam that throws on
  every predicate is red in both states rather than discriminating.
• where on findOne — implemented, matching the sibling, once the null was
  measured not load-bearing.
• limit — applied after the filter and by presence, typeof opts?.limit === 'number',
  on both table branches, which is check:objectql-double-limit's shape rule. Every call
  this fixture makes passes no bound, so every existing assertion keeps its meaning.
• unknown WHERE combinators — refused loudly rather than read as a column name. This
  is the one place refusal is right: a double that answers $and by looking for a column
  literally called $and returns a well-formed wrong answer, which is the same silent
  class one level down.

The door's own ?limit= contract and the /diff and non-overridable controls are pinned
by rest-server-meta-history-diff-org-scope.test.ts and are deliberately not copied
here — the gate's own probes exercise the shape rules of the double itself, and
duplicating the sibling's door pins would be redundant coverage rather than new
information.

Baseline ratchet

scripts/objectql-double-limit.baseline.json loses its rest-server-meta-read-org-scope
entry. Not a new baseline row — a ratchet down, which the gate requires in the same
PR; it reconciles in both directions and errored with
baselined file is clean or gone -- ratchet DOWN until the entry was deleted.

Verification

Union derived with scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack after
merging origin/main and after the last edit, harvested with --commands. Everything
below ran at aab1254550, tree clean.

union named 33, ran 33, unreconciled 0

by exact comm -23 of the sorted union against the sorted ran-list — no prefix or fuzzy
matching, and no arithmetic on a hand-kept counter. comm -13 is empty too.

One non-zero exit, and it is NOT MEASURED rather than a finding, in the gate's own
words:

check-test-completeness: PREREQUISITE NOT MET — this gate grades a saved `turbo run test`
log, and no log was named. … the local reading for this gate is NOT MEASURED.
⛔ It is not a red, and there is nothing here to fix. (exit 3, distinct from a finding's 1)

The two gates this change is really answerable to, quoting their own verdict lines:

OK ObjectQL double `limit` conformance holds: 296 double(s) graded, 97 apply the
caller's bound or refuse it loudly.
167 limit-blind, 32 shape-breaking and 55 unjudged double(s) in 252 grandfathered
file(s); none new.
baseline key set verified against 16c3601: no files added.
✓ where-matcher conformance holds: 321 matcher(s) discovered, 321 answer the combinator
battery correctly or refuse it loudly (202 refuse).

Also run, all exit 0:

• pnpm --filter @objectstack/rest test — 164 files, 2764 tests, all passed
• pnpm --filter @objectstack/rest typecheck — check:test-typecheck: OK. The edited
  file was confirmed present in that program by tsc --listFiles (1 hit, with the sibling
  harness as the positive control), so the green really covers it. The 2 remaining tsc
  errors are the pre-existing pinned src/rest.test.ts debt held by The 2 remaining ledgered TS2345 in packages/rest are hand-built IHttpResponse literals — they were masked by the request literals, not absent #13454; zero come
  from this diff.
• pnpm lint — the whole repo, eslint . --no-inline-config, exit 0 in 85s. No
  narrowing claimed and none needed.
• pnpm check:nul-bytes — OK (scanned 7598 text file(s) … no raw ASCII control bytes),
  plus a direct control-byte scan over both edited files.

Changeset

Proposed: the skip-changeset label, and this is a reading rather than a preference.
packages/rest's manifest declares files: ["dist", "README.md", "CHANGELOG.md"], and
npm pack --dry-run reports an 8-file tarball that does not contain the edited test
file, with dist/index.js present as the control that the reading is real. The other file
is a CI-internal gate ledger. So the change publishes nothing from any package.

The seat rule says to prefer release noise over a silent gate bypass when the two readings
conflict — here they do not, and the bypass surface was measured rather than assumed:
Check Changeset runs exactly three substantive steps, and this diff adds no changeset at
all (so there is no empty-frontmatter file to reject) and declares no breaking change (so
no ADR-0087 disposition is owed). The one thing that stretches the closed list is that the
baseline ledger sits in scripts/ rather than scripts/pm/; it is the gate's mandatory
same-PR companion to the test edit and cannot be split out.

Generated by Claude Code

---

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 86e765a7704eff4de2eb070330ff66a0e211c3aa → packageMentionDocs.

[claude]

Fixes#13764

The stub engine in packages/rest/src/rest-server-meta-read-org-scope.test.ts discarded
opts.where on bothsys_metadata_history seams — findOne answered null
unconditionally and find handed back every history row unfiltered — and was also
limit-blind, one of the 168 doubles check:objectql-double-limit grandfathers. Both
seams are repaired on one edit, plus the matcher's silent-combinator hole.

There was no live defect and no vacuous claim in the file as it stood: it drove only
PUT /meta/:type/:name, GET /meta/:type/:name and GET /meta/:type, and every
assertion it made its stub genuinely kept. What is repaired is a trap — the file whose
name reads like the obvious home for a /history org-scoping assertion was the one file
where that assertion could not be tested.

The deliverable is the discrimination control, not the green gate

SysMetadataRepository.history() and diffMetaItem filter organization_id by strict
equality and post-filter nothing, so over an unfiltered stub the org predicate is a no-op.
The control mutates the /history door to not forward the organization — the exact
line ...(historyOrganizationId ? ...) inside GET /meta/:type/:name/history — and reads
one assertion, serves the org-scoped change log of an item the active org authored, in
all four cells.

stub	org at the door	that assertion
old, unfiltered	forwarded	PASS
old, unfiltered	dropped	PASS — the vacuity, measured directly
new, partitioned	forwarded	PASS
new, partitioned	dropped	FAIL — expected +0 to be 2

Verbatim, cell 2 (old stub, org dropped):

 ✓ … #13764 the history seams of this harness honour the org partition >
serves the org-scoped change log of an item the active org authored 4ms

and cell 4 (new stub, org dropped):

 × … serves the org-scoped change log of an item the active org authored 11ms
→ the door answered an empty change log for an item whose org partition holds
two events: expected +0 to be 2

Green in both states before, red in exactly one state after. That is the discriminating
power the card is about.

⛔ rest-server.ts is held hard-serial by #13280 and nothing lands in it here. It was
mutated transiently for the measurement only, with the blob hash equal to its HEAD blob
before and after, the removed and injected text counted in both directions, and an empty
git diff HEAD on the restore leg.

The second axis of the control

The two cross-tenant cases were not writable at all against the old stub — they were
red over it with the org forwarded and with it dropped, because an unfiltered read hands
org B org A's rows whatever the door does. They are green over the new stub in both
states. That makes does not serve org A history to org B the assertion that holds the
stub partitioned: the positive case stays green if anyone un-partitions the stub again,
and only the cross-tenant one reddens.

Was findOne's unconditional null load-bearing? Measured: no

Predicted before running, from the production call sites — the only callers of findOne
on that table are getByHash, restoreVersion and resolveMetaItemOrgScope, none of
which a PUT reaches; the write path reads history through find, in nextEventSeq and
nextItemVersion. The sibling harness landed in #13756 implements this exact seam and
drives the same PUT path green, which is the positive control for the prediction.

Confirmed: with the seam honouring the where, all 15 pre-existing assertions stay
green and the file runs 18/18. So the implement form was safe and the refusal form was not
needed on this seam.

Which form on each axis, and why

• where on find — implemented, not refused. Refusal was not available: an
  org-scoping assertion has to be able to read the partition, and a seam that throws on
  every predicate is red in both states rather than discriminating.
• where on findOne — implemented, matching the sibling, once the null was
  measured not load-bearing.
• limit — applied after the filter and by presence, typeof opts?.limit === 'number',
  on both table branches, which is check:objectql-double-limit's shape rule. Every call
  this fixture makes passes no bound, so every existing assertion keeps its meaning.
• unknown WHERE combinators — refused loudly rather than read as a column name. This
  is the one place refusal is right: a double that answers $and by looking for a column
  literally called $and returns a well-formed wrong answer, which is the same silent
  class one level down.

The door's own ?limit= contract and the /diff and non-overridable controls are pinned
by rest-server-meta-history-diff-org-scope.test.ts and are deliberately not copied
here — the gate's own probes exercise the shape rules of the double itself, and
duplicating the sibling's door pins would be redundant coverage rather than new
information.

Baseline ratchet

scripts/objectql-double-limit.baseline.json loses its rest-server-meta-read-org-scope
entry. Not a new baseline row — a ratchet down, which the gate requires in the same
PR; it reconciles in both directions and errored with
baselined file is clean or gone -- ratchet DOWN until the entry was deleted.

Verification

Union derived with scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack after
merging origin/main and after the last edit, harvested with --commands. Everything
below ran at aab1254550, tree clean.

union named 33, ran 33, unreconciled 0

by exact comm -23 of the sorted union against the sorted ran-list — no prefix or fuzzy
matching, and no arithmetic on a hand-kept counter. comm -13 is empty too.

One non-zero exit, and it is NOT MEASURED rather than a finding, in the gate's own
words:

check-test-completeness: PREREQUISITE NOT MET — this gate grades a saved `turbo run test`
log, and no log was named. … the local reading for this gate is NOT MEASURED.
⛔ It is not a red, and there is nothing here to fix. (exit 3, distinct from a finding's 1)

The two gates this change is really answerable to, quoting their own verdict lines:

OK ObjectQL double `limit` conformance holds: 296 double(s) graded, 97 apply the
caller's bound or refuse it loudly.
167 limit-blind, 32 shape-breaking and 55 unjudged double(s) in 252 grandfathered
file(s); none new.
baseline key set verified against 16c3601: no files added.
✓ where-matcher conformance holds: 321 matcher(s) discovered, 321 answer the combinator
battery correctly or refuse it loudly (202 refuse).

Also run, all exit 0:

• pnpm --filter @objectstack/rest test — 164 files, 2764 tests, all passed
• pnpm --filter @objectstack/rest typecheck — check:test-typecheck: OK. The edited
  file was confirmed present in that program by tsc --listFiles (1 hit, with the sibling
  harness as the positive control), so the green really covers it. The 2 remaining tsc
  errors are the pre-existing pinned src/rest.test.ts debt held by The 2 remaining ledgered TS2345 in packages/rest are hand-built IHttpResponse literals — they were masked by the request literals, not absent #13454; zero come
  from this diff.
• pnpm lint — the whole repo, eslint . --no-inline-config, exit 0 in 85s. No
  narrowing claimed and none needed.
• pnpm check:nul-bytes — OK (scanned 7598 text file(s) … no raw ASCII control bytes),
  plus a direct control-byte scan over both edited files.

Changeset

Proposed: the skip-changeset label, and this is a reading rather than a preference.
packages/rest's manifest declares files: ["dist", "README.md", "CHANGELOG.md"], and
npm pack --dry-run reports an 8-file tarball that does not contain the edited test
file, with dist/index.js present as the control that the reading is real. The other file
is a CI-internal gate ledger. So the change publishes nothing from any package.

The seat rule says to prefer release noise over a silent gate bypass when the two readings
conflict — here they do not, and the bypass surface was measured rather than assumed:
Check Changeset runs exactly three substantive steps, and this diff adds no changeset at
all (so there is no empty-frontmatter file to reject) and declares no breaking change (so
no ADR-0087 disposition is owed). The one thing that stretches the closed list is that the
baseline ledger sits in scripts/ rather than scripts/pm/; it is the gate's mandatory
same-PR companion to the test edit and cannot be split out.

Generated by Claude Code

---

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 86e765a7704eff4de2eb070330ff66a0e211c3aa → packageMentionDocs.

[claude]

Fixes#13764

The stub engine in packages/rest/src/rest-server-meta-read-org-scope.test.ts discarded
opts.where on bothsys_metadata_history seams — findOne answered null
unconditionally and find handed back every history row unfiltered — and was also
limit-blind, one of the 168 doubles check:objectql-double-limit grandfathers. Both
seams are repaired on one edit, plus the matcher's silent-combinator hole.

There was no live defect and no vacuous claim in the file as it stood: it drove only
PUT /meta/:type/:name, GET /meta/:type/:name and GET /meta/:type, and every
assertion it made its stub genuinely kept. What is repaired is a trap — the file whose
name reads like the obvious home for a /history org-scoping assertion was the one file
where that assertion could not be tested.

The deliverable is the discrimination control, not the green gate

SysMetadataRepository.history() and diffMetaItem filter organization_id by strict
equality and post-filter nothing, so over an unfiltered stub the org predicate is a no-op.
The control mutates the /history door to not forward the organization — the exact
line ...(historyOrganizationId ? ...) inside GET /meta/:type/:name/history — and reads
one assertion, serves the org-scoped change log of an item the active org authored, in
all four cells.

stub	org at the door	that assertion
old, unfiltered	forwarded	PASS
old, unfiltered	dropped	PASS — the vacuity, measured directly
new, partitioned	forwarded	PASS
new, partitioned	dropped	FAIL — expected +0 to be 2

Verbatim, cell 2 (old stub, org dropped):

 ✓ … #13764 the history seams of this harness honour the org partition >
serves the org-scoped change log of an item the active org authored 4ms

and cell 4 (new stub, org dropped):

 × … serves the org-scoped change log of an item the active org authored 11ms
→ the door answered an empty change log for an item whose org partition holds
two events: expected +0 to be 2

Green in both states before, red in exactly one state after. That is the discriminating
power the card is about.

⛔ rest-server.ts is held hard-serial by #13280 and nothing lands in it here. It was
mutated transiently for the measurement only, with the blob hash equal to its HEAD blob
before and after, the removed and injected text counted in both directions, and an empty
git diff HEAD on the restore leg.

The second axis of the control

The two cross-tenant cases were not writable at all against the old stub — they were
red over it with the org forwarded and with it dropped, because an unfiltered read hands
org B org A's rows whatever the door does. They are green over the new stub in both
states. That makes does not serve org A history to org B the assertion that holds the
stub partitioned: the positive case stays green if anyone un-partitions the stub again,
and only the cross-tenant one reddens.

Was findOne's unconditional null load-bearing? Measured: no

Predicted before running, from the production call sites — the only callers of findOne
on that table are getByHash, restoreVersion and resolveMetaItemOrgScope, none of
which a PUT reaches; the write path reads history through find, in nextEventSeq and
nextItemVersion. The sibling harness landed in #13756 implements this exact seam and
drives the same PUT path green, which is the positive control for the prediction.

Confirmed: with the seam honouring the where, all 15 pre-existing assertions stay
green and the file runs 18/18. So the implement form was safe and the refusal form was not
needed on this seam.

Which form on each axis, and why

• where on find — implemented, not refused. Refusal was not available: an
  org-scoping assertion has to be able to read the partition, and a seam that throws on
  every predicate is red in both states rather than discriminating.
• where on findOne — implemented, matching the sibling, once the null was
  measured not load-bearing.
• limit — applied after the filter and by presence, typeof opts?.limit === 'number',
  on both table branches, which is check:objectql-double-limit's shape rule. Every call
  this fixture makes passes no bound, so every existing assertion keeps its meaning.
• unknown WHERE combinators — refused loudly rather than read as a column name. This
  is the one place refusal is right: a double that answers $and by looking for a column
  literally called $and returns a well-formed wrong answer, which is the same silent
  class one level down.

The door's own ?limit= contract and the /diff and non-overridable controls are pinned
by rest-server-meta-history-diff-org-scope.test.ts and are deliberately not copied
here — the gate's own probes exercise the shape rules of the double itself, and
duplicating the sibling's door pins would be redundant coverage rather than new
information.

Baseline ratchet

scripts/objectql-double-limit.baseline.json loses its rest-server-meta-read-org-scope
entry. Not a new baseline row — a ratchet down, which the gate requires in the same
PR; it reconciles in both directions and errored with
baselined file is clean or gone -- ratchet DOWN until the entry was deleted.

Verification

Union derived with scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack after
merging origin/main and after the last edit, harvested with --commands. Everything
below ran at aab1254550, tree clean.

union named 33, ran 33, unreconciled 0

by exact comm -23 of the sorted union against the sorted ran-list — no prefix or fuzzy
matching, and no arithmetic on a hand-kept counter. comm -13 is empty too.

One non-zero exit, and it is NOT MEASURED rather than a finding, in the gate's own
words:

check-test-completeness: PREREQUISITE NOT MET — this gate grades a saved `turbo run test`
log, and no log was named. … the local reading for this gate is NOT MEASURED.
⛔ It is not a red, and there is nothing here to fix. (exit 3, distinct from a finding's 1)

The two gates this change is really answerable to, quoting their own verdict lines:

OK ObjectQL double `limit` conformance holds: 296 double(s) graded, 97 apply the
caller's bound or refuse it loudly.
167 limit-blind, 32 shape-breaking and 55 unjudged double(s) in 252 grandfathered
file(s); none new.
baseline key set verified against 16c3601: no files added.
✓ where-matcher conformance holds: 321 matcher(s) discovered, 321 answer the combinator
battery correctly or refuse it loudly (202 refuse).

Also run, all exit 0:

• pnpm --filter @objectstack/rest test — 164 files, 2764 tests, all passed
• pnpm --filter @objectstack/rest typecheck — check:test-typecheck: OK. The edited
  file was confirmed present in that program by tsc --listFiles (1 hit, with the sibling
  harness as the positive control), so the green really covers it. The 2 remaining tsc
  errors are the pre-existing pinned src/rest.test.ts debt held by The 2 remaining ledgered TS2345 in packages/rest are hand-built IHttpResponse literals — they were masked by the request literals, not absent #13454; zero come
  from this diff.
• pnpm lint — the whole repo, eslint . --no-inline-config, exit 0 in 85s. No
  narrowing claimed and none needed.
• pnpm check:nul-bytes — OK (scanned 7598 text file(s) … no raw ASCII control bytes),
  plus a direct control-byte scan over both edited files.

Changeset

Proposed: the skip-changeset label, and this is a reading rather than a preference.
packages/rest's manifest declares files: ["dist", "README.md", "CHANGELOG.md"], and
npm pack --dry-run reports an 8-file tarball that does not contain the edited test
file, with dist/index.js present as the control that the reading is real. The other file
is a CI-internal gate ledger. So the change publishes nothing from any package.

The seat rule says to prefer release noise over a silent gate bypass when the two readings
conflict — here they do not, and the bypass surface was measured rather than assumed:
Check Changeset runs exactly three substantive steps, and this diff adds no changeset at
all (so there is no empty-frontmatter file to reject) and declares no breaking change (so
no ADR-0087 disposition is owed). The one thing that stretches the closed list is that the
baseline ledger sits in scripts/ rather than scripts/pm/; it is the gate's mandatory
same-PR companion to the test edit and cannot be split out.

Generated by Claude Code

---

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 86e765a7704eff4de2eb070330ff66a0e211c3aa → packageMentionDocs.

[claude]

Fixes#13764

The stub engine in packages/rest/src/rest-server-meta-read-org-scope.test.ts discarded
opts.where on bothsys_metadata_history seams — findOne answered null
unconditionally and find handed back every history row unfiltered — and was also
limit-blind, one of the 168 doubles check:objectql-double-limit grandfathers. Both
seams are repaired on one edit, plus the matcher's silent-combinator hole.

There was no live defect and no vacuous claim in the file as it stood: it drove only
PUT /meta/:type/:name, GET /meta/:type/:name and GET /meta/:type, and every
assertion it made its stub genuinely kept. What is repaired is a trap — the file whose
name reads like the obvious home for a /history org-scoping assertion was the one file
where that assertion could not be tested.

The deliverable is the discrimination control, not the green gate

SysMetadataRepository.history() and diffMetaItem filter organization_id by strict
equality and post-filter nothing, so over an unfiltered stub the org predicate is a no-op.
The control mutates the /history door to not forward the organization — the exact
line ...(historyOrganizationId ? ...) inside GET /meta/:type/:name/history — and reads
one assertion, serves the org-scoped change log of an item the active org authored, in
all four cells.

stub	org at the door	that assertion
old, unfiltered	forwarded	PASS
old, unfiltered	dropped	PASS — the vacuity, measured directly
new, partitioned	forwarded	PASS
new, partitioned	dropped	FAIL — expected +0 to be 2

Verbatim, cell 2 (old stub, org dropped):

 ✓ … #13764 the history seams of this harness honour the org partition >
serves the org-scoped change log of an item the active org authored 4ms

and cell 4 (new stub, org dropped):

 × … serves the org-scoped change log of an item the active org authored 11ms
→ the door answered an empty change log for an item whose org partition holds
two events: expected +0 to be 2

Green in both states before, red in exactly one state after. That is the discriminating
power the card is about.

⛔ rest-server.ts is held hard-serial by #13280 and nothing lands in it here. It was
mutated transiently for the measurement only, with the blob hash equal to its HEAD blob
before and after, the removed and injected text counted in both directions, and an empty
git diff HEAD on the restore leg.

The second axis of the control

The two cross-tenant cases were not writable at all against the old stub — they were
red over it with the org forwarded and with it dropped, because an unfiltered read hands
org B org A's rows whatever the door does. They are green over the new stub in both
states. That makes does not serve org A history to org B the assertion that holds the
stub partitioned: the positive case stays green if anyone un-partitions the stub again,
and only the cross-tenant one reddens.

Was findOne's unconditional null load-bearing? Measured: no

Predicted before running, from the production call sites — the only callers of findOne
on that table are getByHash, restoreVersion and resolveMetaItemOrgScope, none of
which a PUT reaches; the write path reads history through find, in nextEventSeq and
nextItemVersion. The sibling harness landed in #13756 implements this exact seam and
drives the same PUT path green, which is the positive control for the prediction.

Confirmed: with the seam honouring the where, all 15 pre-existing assertions stay
green and the file runs 18/18. So the implement form was safe and the refusal form was not
needed on this seam.

Which form on each axis, and why

• where on find — implemented, not refused. Refusal was not available: an
  org-scoping assertion has to be able to read the partition, and a seam that throws on
  every predicate is red in both states rather than discriminating.
• where on findOne — implemented, matching the sibling, once the null was
  measured not load-bearing.
• limit — applied after the filter and by presence, typeof opts?.limit === 'number',
  on both table branches, which is check:objectql-double-limit's shape rule. Every call
  this fixture makes passes no bound, so every existing assertion keeps its meaning.
• unknown WHERE combinators — refused loudly rather than read as a column name. This
  is the one place refusal is right: a double that answers $and by looking for a column
  literally called $and returns a well-formed wrong answer, which is the same silent
  class one level down.

The door's own ?limit= contract and the /diff and non-overridable controls are pinned
by rest-server-meta-history-diff-org-scope.test.ts and are deliberately not copied
here — the gate's own probes exercise the shape rules of the double itself, and
duplicating the sibling's door pins would be redundant coverage rather than new
information.

Baseline ratchet

scripts/objectql-double-limit.baseline.json loses its rest-server-meta-read-org-scope
entry. Not a new baseline row — a ratchet down, which the gate requires in the same
PR; it reconciles in both directions and errored with
baselined file is clean or gone -- ratchet DOWN until the entry was deleted.

Verification

Union derived with scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack after
merging origin/main and after the last edit, harvested with --commands. Everything
below ran at aab1254550, tree clean.

union named 33, ran 33, unreconciled 0

by exact comm -23 of the sorted union against the sorted ran-list — no prefix or fuzzy
matching, and no arithmetic on a hand-kept counter. comm -13 is empty too.

One non-zero exit, and it is NOT MEASURED rather than a finding, in the gate's own
words:

check-test-completeness: PREREQUISITE NOT MET — this gate grades a saved `turbo run test`
log, and no log was named. … the local reading for this gate is NOT MEASURED.
⛔ It is not a red, and there is nothing here to fix. (exit 3, distinct from a finding's 1)

The two gates this change is really answerable to, quoting their own verdict lines:

OK ObjectQL double `limit` conformance holds: 296 double(s) graded, 97 apply the
caller's bound or refuse it loudly.
167 limit-blind, 32 shape-breaking and 55 unjudged double(s) in 252 grandfathered
file(s); none new.
baseline key set verified against 16c3601: no files added.
✓ where-matcher conformance holds: 321 matcher(s) discovered, 321 answer the combinator
battery correctly or refuse it loudly (202 refuse).

Also run, all exit 0:

• pnpm --filter @objectstack/rest test — 164 files, 2764 tests, all passed
• pnpm --filter @objectstack/rest typecheck — check:test-typecheck: OK. The edited
  file was confirmed present in that program by tsc --listFiles (1 hit, with the sibling
  harness as the positive control), so the green really covers it. The 2 remaining tsc
  errors are the pre-existing pinned src/rest.test.ts debt held by The 2 remaining ledgered TS2345 in packages/rest are hand-built IHttpResponse literals — they were masked by the request literals, not absent #13454; zero come
  from this diff.
• pnpm lint — the whole repo, eslint . --no-inline-config, exit 0 in 85s. No
  narrowing claimed and none needed.
• pnpm check:nul-bytes — OK (scanned 7598 text file(s) … no raw ASCII control bytes),
  plus a direct control-byte scan over both edited files.

Changeset

Proposed: the skip-changeset label, and this is a reading rather than a preference.
packages/rest's manifest declares files: ["dist", "README.md", "CHANGELOG.md"], and
npm pack --dry-run reports an 8-file tarball that does not contain the edited test
file, with dist/index.js present as the control that the reading is real. The other file
is a CI-internal gate ledger. So the change publishes nothing from any package.

The seat rule says to prefer release noise over a silent gate bypass when the two readings
conflict — here they do not, and the bypass surface was measured rather than assumed:
Check Changeset runs exactly three substantive steps, and this diff adds no changeset at
all (so there is no empty-frontmatter file to reject) and declares no breaking change (so
no ADR-0087 disposition is owed). The one thing that stretches the closed list is that the
baseline ledger sits in scripts/ rather than scripts/pm/; it is the gate's mandatory
same-PR companion to the test edit and cannot be split out.

Generated by Claude Code

---

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 86e765a7704eff4de2eb070330ff66a0e211c3aa → packageMentionDocs.

[claude]

Fixes#13764

The stub engine in packages/rest/src/rest-server-meta-read-org-scope.test.ts discarded
opts.where on bothsys_metadata_history seams — findOne answered null
unconditionally and find handed back every history row unfiltered — and was also
limit-blind, one of the 168 doubles check:objectql-double-limit grandfathers. Both
seams are repaired on one edit, plus the matcher's silent-combinator hole.

There was no live defect and no vacuous claim in the file as it stood: it drove only
PUT /meta/:type/:name, GET /meta/:type/:name and GET /meta/:type, and every
assertion it made its stub genuinely kept. What is repaired is a trap — the file whose
name reads like the obvious home for a /history org-scoping assertion was the one file
where that assertion could not be tested.

The deliverable is the discrimination control, not the green gate

SysMetadataRepository.history() and diffMetaItem filter organization_id by strict
equality and post-filter nothing, so over an unfiltered stub the org predicate is a no-op.
The control mutates the /history door to not forward the organization — the exact
line ...(historyOrganizationId ? ...) inside GET /meta/:type/:name/history — and reads
one assertion, serves the org-scoped change log of an item the active org authored, in
all four cells.

stub	org at the door	that assertion
old, unfiltered	forwarded	PASS
old, unfiltered	dropped	PASS — the vacuity, measured directly
new, partitioned	forwarded	PASS
new, partitioned	dropped	FAIL — expected +0 to be 2

Verbatim, cell 2 (old stub, org dropped):

 ✓ … #13764 the history seams of this harness honour the org partition >
serves the org-scoped change log of an item the active org authored 4ms

and cell 4 (new stub, org dropped):

 × … serves the org-scoped change log of an item the active org authored 11ms
→ the door answered an empty change log for an item whose org partition holds
two events: expected +0 to be 2

Green in both states before, red in exactly one state after. That is the discriminating
power the card is about.

⛔ rest-server.ts is held hard-serial by #13280 and nothing lands in it here. It was
mutated transiently for the measurement only, with the blob hash equal to its HEAD blob
before and after, the removed and injected text counted in both directions, and an empty
git diff HEAD on the restore leg.

The second axis of the control

The two cross-tenant cases were not writable at all against the old stub — they were
red over it with the org forwarded and with it dropped, because an unfiltered read hands
org B org A's rows whatever the door does. They are green over the new stub in both
states. That makes does not serve org A history to org B the assertion that holds the
stub partitioned: the positive case stays green if anyone un-partitions the stub again,
and only the cross-tenant one reddens.

Was findOne's unconditional null load-bearing? Measured: no

Predicted before running, from the production call sites — the only callers of findOne
on that table are getByHash, restoreVersion and resolveMetaItemOrgScope, none of
which a PUT reaches; the write path reads history through find, in nextEventSeq and
nextItemVersion. The sibling harness landed in #13756 implements this exact seam and
drives the same PUT path green, which is the positive control for the prediction.

Confirmed: with the seam honouring the where, all 15 pre-existing assertions stay
green and the file runs 18/18. So the implement form was safe and the refusal form was not
needed on this seam.

Which form on each axis, and why

• where on find — implemented, not refused. Refusal was not available: an
  org-scoping assertion has to be able to read the partition, and a seam that throws on
  every predicate is red in both states rather than discriminating.
• where on findOne — implemented, matching the sibling, once the null was
  measured not load-bearing.
• limit — applied after the filter and by presence, typeof opts?.limit === 'number',
  on both table branches, which is check:objectql-double-limit's shape rule. Every call
  this fixture makes passes no bound, so every existing assertion keeps its meaning.
• unknown WHERE combinators — refused loudly rather than read as a column name. This
  is the one place refusal is right: a double that answers $and by looking for a column
  literally called $and returns a well-formed wrong answer, which is the same silent
  class one level down.

The door's own ?limit= contract and the /diff and non-overridable controls are pinned
by rest-server-meta-history-diff-org-scope.test.ts and are deliberately not copied
here — the gate's own probes exercise the shape rules of the double itself, and
duplicating the sibling's door pins would be redundant coverage rather than new
information.

Baseline ratchet

scripts/objectql-double-limit.baseline.json loses its rest-server-meta-read-org-scope
entry. Not a new baseline row — a ratchet down, which the gate requires in the same
PR; it reconciles in both directions and errored with
baselined file is clean or gone -- ratchet DOWN until the entry was deleted.

Verification

Union derived with scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack after
merging origin/main and after the last edit, harvested with --commands. Everything
below ran at aab1254550, tree clean.

union named 33, ran 33, unreconciled 0

by exact comm -23 of the sorted union against the sorted ran-list — no prefix or fuzzy
matching, and no arithmetic on a hand-kept counter. comm -13 is empty too.

One non-zero exit, and it is NOT MEASURED rather than a finding, in the gate's own
words:

check-test-completeness: PREREQUISITE NOT MET — this gate grades a saved `turbo run test`
log, and no log was named. … the local reading for this gate is NOT MEASURED.
⛔ It is not a red, and there is nothing here to fix. (exit 3, distinct from a finding's 1)

The two gates this change is really answerable to, quoting their own verdict lines:

OK ObjectQL double `limit` conformance holds: 296 double(s) graded, 97 apply the
caller's bound or refuse it loudly.
167 limit-blind, 32 shape-breaking and 55 unjudged double(s) in 252 grandfathered
file(s); none new.
baseline key set verified against 16c3601: no files added.
✓ where-matcher conformance holds: 321 matcher(s) discovered, 321 answer the combinator
battery correctly or refuse it loudly (202 refuse).

Also run, all exit 0:

• pnpm --filter @objectstack/rest test — 164 files, 2764 tests, all passed
• pnpm --filter @objectstack/rest typecheck — check:test-typecheck: OK. The edited
  file was confirmed present in that program by tsc --listFiles (1 hit, with the sibling
  harness as the positive control), so the green really covers it. The 2 remaining tsc
  errors are the pre-existing pinned src/rest.test.ts debt held by The 2 remaining ledgered TS2345 in packages/rest are hand-built IHttpResponse literals — they were masked by the request literals, not absent #13454; zero come
  from this diff.
• pnpm lint — the whole repo, eslint . --no-inline-config, exit 0 in 85s. No
  narrowing claimed and none needed.
• pnpm check:nul-bytes — OK (scanned 7598 text file(s) … no raw ASCII control bytes),
  plus a direct control-byte scan over both edited files.

Changeset

Proposed: the skip-changeset label, and this is a reading rather than a preference.
packages/rest's manifest declares files: ["dist", "README.md", "CHANGELOG.md"], and
npm pack --dry-run reports an 8-file tarball that does not contain the edited test
file, with dist/index.js present as the control that the reading is real. The other file
is a CI-internal gate ledger. So the change publishes nothing from any package.

The seat rule says to prefer release noise over a silent gate bypass when the two readings
conflict — here they do not, and the bypass surface was measured rather than assumed:
Check Changeset runs exactly three substantive steps, and this diff adds no changeset at
all (so there is no empty-frontmatter file to reject) and declares no breaking change (so
no ADR-0087 disposition is owed). The one thing that stretches the closed list is that the
baseline ledger sits in scripts/ rather than scripts/pm/; it is the gate's mandatory
same-PR companion to the test edit and cannot be split out.

Generated by Claude Code

---

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 86e765a7704eff4de2eb070330ff66a0e211c3aa → packageMentionDocs.

[claude]

Fixes#13764

The stub engine in packages/rest/src/rest-server-meta-read-org-scope.test.ts discarded
opts.where on bothsys_metadata_history seams — findOne answered null
unconditionally and find handed back every history row unfiltered — and was also
limit-blind, one of the 168 doubles check:objectql-double-limit grandfathers. Both
seams are repaired on one edit, plus the matcher's silent-combinator hole.

There was no live defect and no vacuous claim in the file as it stood: it drove only
PUT /meta/:type/:name, GET /meta/:type/:name and GET /meta/:type, and every
assertion it made its stub genuinely kept. What is repaired is a trap — the file whose
name reads like the obvious home for a /history org-scoping assertion was the one file
where that assertion could not be tested.

The deliverable is the discrimination control, not the green gate

SysMetadataRepository.history() and diffMetaItem filter organization_id by strict
equality and post-filter nothing, so over an unfiltered stub the org predicate is a no-op.
The control mutates the /history door to not forward the organization — the exact
line ...(historyOrganizationId ? ...) inside GET /meta/:type/:name/history — and reads
one assertion, serves the org-scoped change log of an item the active org authored, in
all four cells.

stub	org at the door	that assertion
old, unfiltered	forwarded	PASS
old, unfiltered	dropped	PASS — the vacuity, measured directly
new, partitioned	forwarded	PASS
new, partitioned	dropped	FAIL — expected +0 to be 2

Verbatim, cell 2 (old stub, org dropped):

 ✓ … #13764 the history seams of this harness honour the org partition >
serves the org-scoped change log of an item the active org authored 4ms

and cell 4 (new stub, org dropped):

 × … serves the org-scoped change log of an item the active org authored 11ms
→ the door answered an empty change log for an item whose org partition holds
two events: expected +0 to be 2

Green in both states before, red in exactly one state after. That is the discriminating
power the card is about.

⛔ rest-server.ts is held hard-serial by #13280 and nothing lands in it here. It was
mutated transiently for the measurement only, with the blob hash equal to its HEAD blob
before and after, the removed and injected text counted in both directions, and an empty
git diff HEAD on the restore leg.

The second axis of the control

The two cross-tenant cases were not writable at all against the old stub — they were
red over it with the org forwarded and with it dropped, because an unfiltered read hands
org B org A's rows whatever the door does. They are green over the new stub in both
states. That makes does not serve org A history to org B the assertion that holds the
stub partitioned: the positive case stays green if anyone un-partitions the stub again,
and only the cross-tenant one reddens.

Was findOne's unconditional null load-bearing? Measured: no

Predicted before running, from the production call sites — the only callers of findOne
on that table are getByHash, restoreVersion and resolveMetaItemOrgScope, none of
which a PUT reaches; the write path reads history through find, in nextEventSeq and
nextItemVersion. The sibling harness landed in #13756 implements this exact seam and
drives the same PUT path green, which is the positive control for the prediction.

Confirmed: with the seam honouring the where, all 15 pre-existing assertions stay
green and the file runs 18/18. So the implement form was safe and the refusal form was not
needed on this seam.

Which form on each axis, and why

• where on find — implemented, not refused. Refusal was not available: an
  org-scoping assertion has to be able to read the partition, and a seam that throws on
  every predicate is red in both states rather than discriminating.
• where on findOne — implemented, matching the sibling, once the null was
  measured not load-bearing.
• limit — applied after the filter and by presence, typeof opts?.limit === 'number',
  on both table branches, which is check:objectql-double-limit's shape rule. Every call
  this fixture makes passes no bound, so every existing assertion keeps its meaning.
• unknown WHERE combinators — refused loudly rather than read as a column name. This
  is the one place refusal is right: a double that answers $and by looking for a column
  literally called $and returns a well-formed wrong answer, which is the same silent
  class one level down.

The door's own ?limit= contract and the /diff and non-overridable controls are pinned
by rest-server-meta-history-diff-org-scope.test.ts and are deliberately not copied
here — the gate's own probes exercise the shape rules of the double itself, and
duplicating the sibling's door pins would be redundant coverage rather than new
information.

Baseline ratchet

scripts/objectql-double-limit.baseline.json loses its rest-server-meta-read-org-scope
entry. Not a new baseline row — a ratchet down, which the gate requires in the same
PR; it reconciles in both directions and errored with
baselined file is clean or gone -- ratchet DOWN until the entry was deleted.

Verification

Union derived with scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack after
merging origin/main and after the last edit, harvested with --commands. Everything
below ran at aab1254550, tree clean.

union named 33, ran 33, unreconciled 0

by exact comm -23 of the sorted union against the sorted ran-list — no prefix or fuzzy
matching, and no arithmetic on a hand-kept counter. comm -13 is empty too.

One non-zero exit, and it is NOT MEASURED rather than a finding, in the gate's own
words:

check-test-completeness: PREREQUISITE NOT MET — this gate grades a saved `turbo run test`
log, and no log was named. … the local reading for this gate is NOT MEASURED.
⛔ It is not a red, and there is nothing here to fix. (exit 3, distinct from a finding's 1)

The two gates this change is really answerable to, quoting their own verdict lines:

OK ObjectQL double `limit` conformance holds: 296 double(s) graded, 97 apply the
caller's bound or refuse it loudly.
167 limit-blind, 32 shape-breaking and 55 unjudged double(s) in 252 grandfathered
file(s); none new.
baseline key set verified against 16c3601: no files added.
✓ where-matcher conformance holds: 321 matcher(s) discovered, 321 answer the combinator
battery correctly or refuse it loudly (202 refuse).

Also run, all exit 0:

• pnpm --filter @objectstack/rest test — 164 files, 2764 tests, all passed
• pnpm --filter @objectstack/rest typecheck — check:test-typecheck: OK. The edited
  file was confirmed present in that program by tsc --listFiles (1 hit, with the sibling
  harness as the positive control), so the green really covers it. The 2 remaining tsc
  errors are the pre-existing pinned src/rest.test.ts debt held by The 2 remaining ledgered TS2345 in packages/rest are hand-built IHttpResponse literals — they were masked by the request literals, not absent #13454; zero come
  from this diff.
• pnpm lint — the whole repo, eslint . --no-inline-config, exit 0 in 85s. No
  narrowing claimed and none needed.
• pnpm check:nul-bytes — OK (scanned 7598 text file(s) … no raw ASCII control bytes),
  plus a direct control-byte scan over both edited files.

Changeset

Proposed: the skip-changeset label, and this is a reading rather than a preference.
packages/rest's manifest declares files: ["dist", "README.md", "CHANGELOG.md"], and
npm pack --dry-run reports an 8-file tarball that does not contain the edited test
file, with dist/index.js present as the control that the reading is real. The other file
is a CI-internal gate ledger. So the change publishes nothing from any package.

The seat rule says to prefer release noise over a silent gate bypass when the two readings
conflict — here they do not, and the bypass surface was measured rather than assumed:
Check Changeset runs exactly three substantive steps, and this diff adds no changeset at
all (so there is no empty-frontmatter file to reject) and declares no breaking change (so
no ADR-0087 disposition is owed). The one thing that stretches the closed list is that the
baseline ledger sits in scripts/ rather than scripts/pm/; it is the gate's mandatory
same-PR companion to the test edit and cannot be split out.

Generated by Claude Code

---

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 86e765a7704eff4de2eb070330ff66a0e211c3aa → packageMentionDocs.