docs(objectql): disclose the security middleware's total isSystem bypass on repo.execute()

[os-musk]

Part of #13866 — disclosure-completeness follow-up to #15051 (merged as a548550)

Why this exists

#15051 elevated ObjectRepository.execute()'s ctx.api to { ...callerContext, isSystem: true }, closing the third executeAction caller per #13866. Independent contract review returned exactly one finding on that PR, after it had already been merged by the maintainer: its "what widens" statement named only the static readonly strip, and that is true but materially incomplete. isSystem: true is a flag, not a behaviour — it is read by ObjectQL's registered security middleware as a total bypass, not a readonly-only one.

⛔ No implementation, census, ablation, gate, or changeset-level change. The elevation, the pins, the 5-case ablation and the patch level all stood on review — this PR only corrects the disclosure text in the three places that repeated the incomplete framing:

1. .changeset/repo-execute-elevated-context.md
2. the execute() docstring in packages/objectql/src/engine.ts
3. this comment thread + a body edit on fix(objectql): elevate ObjectRepository.execute() to REST/MCP's trusted posture #15051 itself (a merged PR's body can still be edited for the historical record — done in the same round as this PR)

A fourth file changed for mechanical reasons only: content/docs/permissions/system-context.mdx — the docstring insertion shifted every later line in engine.ts by 26, rotting one anchor (check-system-context-census.mjs's own --fix, pure line rot, no population/classification change: still 106 elevation-read sites in 20 packages across 45 files, all anchored).

The corrected "what widens" statement

ctx.api inside a repo.execute()-dispatched action handler carries isSystem: true, and ObjectQL's registered security middleware reads that as a total, unconditional bypass — plugin-security/src/security-plugin.ts:1614-1616, "System operations bypass security" / return next() ahead of every other gate in that middleware. Every find/insert/update/delete the handler drives through this ctx.api therefore also skips, in the same stroke as the readonly strip:

Behaviour	Anchor	Confirmed
Security middleware total short-circuit (the gate itself)	security-plugin.ts:1614-1616	✅
RLS read scoping (getReadFilter)	security-plugin.ts:4344	✅
Field-level security	security-plugin.ts:4495	✅
CRUD permission checks (same middleware)	security-plugin.ts:1616	✅
Export permission (canExport)	security-plugin.ts:4573	✅
ADR-0103 engine-owned/append-only write guard	system-write-guard.ts:96,120, called at security-plugin.ts:1736	✅
package-managed / system-row / curated-capability / audience-anchor write gates	security-plugin.ts:1690-1724	✅
Static readonly strip — UPDATE, single row	engine.ts:11290	✅
Static readonly strip — UPDATE, bulk	engine.ts:11473	✅
Static readonly/runtime-owned strip — INSERT (stripRuntimeOwnedFields, covers autonumber AND readonly together)	engine.ts:10025	✅
Referential-integrity check (assertReferencesResolve)	engine.ts:5892	✅
Tenant-audit mute	engine.ts:3773	✅
Hook-session isSystem propagation (carries the flag onward, not a gate)	engine.ts:3543 (buildSession)	✅
Audit attribution label ('system' vs 'anonymous', not a gate)	engine.ts:12014	✅

Every row re-derived independently by reading the cited line on this branch (not copied from the review) — see the terminal report for the full method.

Bounded on two sides, also re-verified independently:

• Metadata-plane schema masking (metadata-core/object-schema-fls.ts:228) is a separate REST/GraphQL schema-serving dispatch path (GET /meta/object/:name and friends) that this ctx.api surface (find/insert/update/delete/count/aggregate/execute) never calls into — confirmed by reading the file's own header (@objectstack/metadata-core depends on spec+zod only; its two consumers are @objectstack/rest and @objectstack/runtime's schema-serving exits, not the engine's registered middleware chain). isSystemdoes bypass this elsewhere in the platform (content/docs/permissions/system-context.mdx row 7) — just not reachable from this PR's widening.
• plugin-sharing/rule-hooks.ts's insert/update materialisation skip was already retired by the maintainer's 2026-08-31 ruling on 审批回写（系统身份）不触发共享规则物化，「批准后团队看不见」——平台只记一条日志、无补偿、无声明式手段 #13533 — confirmed by reading the file: the skip and its announcing INFO notice are both deleted, and the surviving isSystem check at rule-hooks.ts:292 is a different skip (delete-side revocation timing, delegated to record-share-cascade.ts, not a silencer) per the file's own comment. System and user writes materialise sharing grants identically today.
• Zero measured blast radius today: independently re-ran the chained-accessor grep (.object(x).execute() across packages/, examples/, apps/ — zero hits outside this PR's own pin test (engine-repo-execute-elevation.test.ts), against a firing positive control (.object(x).update( → 195 hits, .insert( → 49 hits) confirming the grep methodology isn't blind. So the widening is total in kind, empty in practice, today.

This matches the platform's own documented posture — content/docs/permissions/system-context.mdx: "Elevation is total, and it is not granular." — and REST /actions / MCP run_action already carry the identical exposure, so #15051 extends an existing bypass to a third dispatch path rather than introducing a new one.

Gates

node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack --commands (no paths — merge-base derivation against origin/main), re-derived after the anchor-fix commit: 73 commands on the final 3-file diff. All passed except two, both pre-existing "build the whole monorepo first" prerequisites unrelated to this diff (same shape #15051 itself reported):

• check:dual-build-cjs-loads → exit 3 PREREQUISITE NOT MET (needs every workspace package's dist/)
• @objectstack/spec check:skill-examples → needs @objectstack/client-react built (unrelated to packages/objectql/docs)

node scripts/pm/check-governed-merges.mjs --test .changeset/repo-execute-elevated-context.md content/docs/permissions/system-context.mdx packages/objectql/src/engine.ts → NOT governed (0 of 3 paths hit GOVERNED_SURFACES).

The PR's own 5 pins (packages/objectql/src/engine-repo-execute-elevation.test.ts) and the package typecheck were re-run on this branch to confirm the text-only edit disturbed neither: 5 passed (5), typecheck clean, both on final head ba771e706.

Scope note

No code behaviour changes here — only prose (a changeset paragraph, a docstring, one doc anchor). Left as draft; not enqueued, not auto-merge-armed. needs:contract-review was already cleared on #15051 when it merged — flagging in the report that this seat could not mechanically re-apply a label from here (no label-write tool available) and leaving that call to the PM/reviewing seat.

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

1 anchor(s) derived from 1 changed package(s); no hand-written page names any of them, so this run has nothing to list — not a clean bill of health. This check sees only pages that NAME a derived anchor: one that documents this change in prose, or enumerates it in an authoring dialect, names none and stays invisible to it on every run.

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 — 16 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 2cc4610304c58c3de05a36efbb7cd1710b9d440e → packageMentionDocs.

Which tree this was computed on

This run read content/docs from 491493b45069b9ae845b2634d29a8e876933a643 — the merge of head ba771e706b8ae3a001a7b4b6f56db7fc747fefed into base 2cc4610304c58c3de05a36efbb7cd1710b9d440e, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin 491493b45069b9ae845b2634d29a8e876933a643 && git checkout 491493b45069b9ae845b2634d29a8e876933a643
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 2cc4610304c58c3de05a36efbb7cd1710b9d440e ba771e706b8ae3a001a7b4b6f56db7fc747fefed && git checkout -B drift-repro 2cc4610304c58c3de05a36efbb7cd1710b9d440e && git merge --no-ff ba771e706b8ae3a001a7b4b6f56db7fc747fefed
node scripts/docs-audit/affected-docs.mjs --json 2cc4610304c58c3de05a36efbb7cd1710b9d440e

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

[os-musk]

PM: Check Changeset resolved, and the one remaining action is not mine to take

The red gate, read rather than guessed.Check Changeset was failure (run 100890560827). Its own job log names exactly two routes: apply skip-changeset if the PR releases nothing, otherwise run pnpm changeset and name the packages — and states that an empty-frontmatter changeset is not a third option.

Route taken: skip-changeset. This PR modifies.changeset/repo-execute-elevated-context.md; it does not add one. The release it corrects is already declared on main by #15051, and this PR adds no package bump of its own — it changes what that release's note says, not what it releases. Adding a second changeset would declare a release that does not exist.

Label write — read-modify-write with compare read-back, per protocol:

• before: documentation, size/s, tooling
• written: the same three plus skip-changeset
• read back live: documentation, size/s, tooling, skip-changeset — matches the union exactly, nothing stripped by a concurrent writer.

The label event re-fired the workflow: new Check Changeset run 100892547790 → skipped (02:43:32Z). The earlier failure run remains visible in the check-run list as a superseded run; the latest run per check name is what branch protection reads.

One claim in this PR independently re-verified, not taken from the report. The only non-prose edit here is the shifted census anchor. Reading packages/objectql/src/engine.ts at head ba771e706 line 14523: get isSystem() { return this.executionContext.isSystem; } — the ScopedContext.isSystem getter, exactly what the table row claims. The --fix re-derivation is correct. (Note for the record: the PR body's prose says the docstring shifted later lines "by 26"; the actual shift is 27, 14496 → 14523. The anchor written to the doc is right; only the prose describing the offset is off by one.)

State now: 35 of 37 check runs green or skipped; Test Core (1/6) and Lint & Repo Gates still in progress at the time of writing. Not governed (check-governed-merges.mjs --test → 0 of 3 paths). Clause-② no — prose only: no new exported symbol, no new key on a published payload.

⛔ What this seat cannot do, stated plainly rather than left as silence. The PR is still a draft. GitHub exposes draft→ready only as the GraphQL mutation markPullRequestReadyForReview; REST PATCH on a pull request has no draft field, and the MCP update tool performs a GraphQL lookup before its REST write. This account's GraphQL quota is exhausted right now (REST calls continue to succeed — the split is REST vs GraphQL, not read vs write), so the flip is structurally unavailable from here, not merely worth retrying. Enabling auto-merge is blocked by the same two facts: it is a GraphQL mutation, and it refuses a draft PR regardless.

So one human action remains — mark this PR ready for review. After that the ordinary queue path applies; no other gate is outstanding. Flagging it here rather than reporting the PR as landed, because it is not.

---

Generated by Claude Code

[os-musk]

Superseded: the handoff above is no longer needed

The previous comment ended by asking a human to mark this PR ready for review, because the GraphQL bucket was exhausted and markPullRequestReadyForReview is the only door to that flip. The quota recovered a few minutes later and this seat did it itself — so ignore that ask; nothing is waiting on a person here.

Sequence, so the record is not just an assertion:

1. Check Changeset re-fired on the skip-changeset label event → run 100892547790, skipped.
2. All 39 check runs now read completed, zero in progress. Every conclusion is success or skipped. The one failure in the list is the superseded Check Changeset run 100890560827 from 02:33, whose successor is the skipped run above — branch protection reads the latest run per check name, and the last two stragglers went green at 02:46:59 (Test Core (1/6)) and 02:50:11 (Lint & Repo Gates).
3. Draft → ready: done.
4. Auto-merge: armed.

One caveat stated rather than dressed up as certainty. The auto-merge receipt came back in the empty form, (method: , enabled at ). That form carries no established meaning — both the filled and the empty form have preceded successful landings here, and an earlier claim in this seat's notes that the empty form meant "already queued" was measured false and withdrawn. There is a reliable positive reading (a merge_group workflow run on a gh-readonly-queue/main/pr-15131-… branch) but no cheap negative one, so arming is not proof of landing. At the time of writing this PR had not yet appeared in the queue; five other entries were ahead of it.

That matters because of how the last one failed: #15008 sat armed for seven hours without landing, because it had gone mergeable_state: "dirty" and auto-merge does not fire on a conflicted PR and emits no event. If this PR is still open some hours from now, that is the first thing to check — absence of an event is not evidence of progress.

---

Generated by Claude Code

[os-musk]

Part of #13866 — disclosure-completeness follow-up to #15051 (merged as a548550)

Why this exists

#15051 elevated ObjectRepository.execute()'s ctx.api to { ...callerContext, isSystem: true }, closing the third executeAction caller per #13866. Independent contract review returned exactly one finding on that PR, after it had already been merged by the maintainer: its "what widens" statement named only the static readonly strip, and that is true but materially incomplete. isSystem: true is a flag, not a behaviour — it is read by ObjectQL's registered security middleware as a total bypass, not a readonly-only one.

⛔ No implementation, census, ablation, gate, or changeset-level change. The elevation, the pins, the 5-case ablation and the patch level all stood on review — this PR only corrects the disclosure text in the three places that repeated the incomplete framing:

1. .changeset/repo-execute-elevated-context.md
2. the execute() docstring in packages/objectql/src/engine.ts
3. this comment thread + a body edit on fix(objectql): elevate ObjectRepository.execute() to REST/MCP's trusted posture #15051 itself (a merged PR's body can still be edited for the historical record — done in the same round as this PR)

A fourth file changed for mechanical reasons only: content/docs/permissions/system-context.mdx — the docstring insertion shifted every later line in engine.ts by 26, rotting one anchor (check-system-context-census.mjs's own --fix, pure line rot, no population/classification change: still 106 elevation-read sites in 20 packages across 45 files, all anchored).

The corrected "what widens" statement

ctx.api inside a repo.execute()-dispatched action handler carries isSystem: true, and ObjectQL's registered security middleware reads that as a total, unconditional bypass — plugin-security/src/security-plugin.ts:1614-1616, "System operations bypass security" / return next() ahead of every other gate in that middleware. Every find/insert/update/delete the handler drives through this ctx.api therefore also skips, in the same stroke as the readonly strip:

Behaviour	Anchor	Confirmed
Security middleware total short-circuit (the gate itself)	security-plugin.ts:1614-1616	✅
RLS read scoping (getReadFilter)	security-plugin.ts:4344	✅
Field-level security	security-plugin.ts:4495	✅
CRUD permission checks (same middleware)	security-plugin.ts:1616	✅
Export permission (canExport)	security-plugin.ts:4573	✅
ADR-0103 engine-owned/append-only write guard	system-write-guard.ts:96,120, called at security-plugin.ts:1736	✅
package-managed / system-row / curated-capability / audience-anchor write gates	security-plugin.ts:1690-1724	✅
Static readonly strip — UPDATE, single row	engine.ts:11290	✅
Static readonly strip — UPDATE, bulk	engine.ts:11473	✅
Static readonly/runtime-owned strip — INSERT (stripRuntimeOwnedFields, covers autonumber AND readonly together)	engine.ts:10025	✅
Referential-integrity check (assertReferencesResolve)	engine.ts:5892	✅
Tenant-audit mute	engine.ts:3773	✅
Hook-session isSystem propagation (carries the flag onward, not a gate)	engine.ts:3543 (buildSession)	✅
Audit attribution label ('system' vs 'anonymous', not a gate)	engine.ts:12014	✅

Every row re-derived independently by reading the cited line on this branch (not copied from the review) — see the terminal report for the full method.

Bounded on two sides, also re-verified independently:

• Metadata-plane schema masking (metadata-core/object-schema-fls.ts:228) is a separate REST/GraphQL schema-serving dispatch path (GET /meta/object/:name and friends) that this ctx.api surface (find/insert/update/delete/count/aggregate/execute) never calls into — confirmed by reading the file's own header (@objectstack/metadata-core depends on spec+zod only; its two consumers are @objectstack/rest and @objectstack/runtime's schema-serving exits, not the engine's registered middleware chain). isSystemdoes bypass this elsewhere in the platform (content/docs/permissions/system-context.mdx row 7) — just not reachable from this PR's widening.
• plugin-sharing/rule-hooks.ts's insert/update materialisation skip was already retired by the maintainer's 2026-08-31 ruling on 审批回写（系统身份）不触发共享规则物化，「批准后团队看不见」——平台只记一条日志、无补偿、无声明式手段 #13533 — confirmed by reading the file: the skip and its announcing INFO notice are both deleted, and the surviving isSystem check at rule-hooks.ts:292 is a different skip (delete-side revocation timing, delegated to record-share-cascade.ts, not a silencer) per the file's own comment. System and user writes materialise sharing grants identically today.
• Zero measured blast radius today: independently re-ran the chained-accessor grep (.object(x).execute() across packages/, examples/, apps/ — zero hits outside this PR's own pin test (engine-repo-execute-elevation.test.ts), against a firing positive control (.object(x).update( → 195 hits, .insert( → 49 hits) confirming the grep methodology isn't blind. So the widening is total in kind, empty in practice, today.

This matches the platform's own documented posture — content/docs/permissions/system-context.mdx: "Elevation is total, and it is not granular." — and REST /actions / MCP run_action already carry the identical exposure, so #15051 extends an existing bypass to a third dispatch path rather than introducing a new one.

Gates

node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack --commands (no paths — merge-base derivation against origin/main), re-derived after the anchor-fix commit: 73 commands on the final 3-file diff. All passed except two, both pre-existing "build the whole monorepo first" prerequisites unrelated to this diff (same shape #15051 itself reported):

• check:dual-build-cjs-loads → exit 3 PREREQUISITE NOT MET (needs every workspace package's dist/)
• @objectstack/spec check:skill-examples → needs @objectstack/client-react built (unrelated to packages/objectql/docs)

node scripts/pm/check-governed-merges.mjs --test .changeset/repo-execute-elevated-context.md content/docs/permissions/system-context.mdx packages/objectql/src/engine.ts → NOT governed (0 of 3 paths hit GOVERNED_SURFACES).

The PR's own 5 pins (packages/objectql/src/engine-repo-execute-elevation.test.ts) and the package typecheck were re-run on this branch to confirm the text-only edit disturbed neither: 5 passed (5), typecheck clean, both on final head ba771e706.

Scope note

No code behaviour changes here — only prose (a changeset paragraph, a docstring, one doc anchor). Left as draft; not enqueued, not auto-merge-armed. needs:contract-review was already cleared on #15051 when it merged — flagging in the report that this seat could not mechanically re-apply a label from here (no label-write tool available) and leaving that call to the PM/reviewing seat.

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

1 anchor(s) derived from 1 changed package(s); no hand-written page names any of them, so this run has nothing to list — not a clean bill of health. This check sees only pages that NAME a derived anchor: one that documents this change in prose, or enumerates it in an authoring dialect, names none and stays invisible to it on every run.

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 — 16 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 2cc4610304c58c3de05a36efbb7cd1710b9d440e → packageMentionDocs.

Which tree this was computed on

This run read content/docs from 491493b45069b9ae845b2634d29a8e876933a643 — the merge of head ba771e706b8ae3a001a7b4b6f56db7fc747fefed into base 2cc4610304c58c3de05a36efbb7cd1710b9d440e, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin 491493b45069b9ae845b2634d29a8e876933a643 && git checkout 491493b45069b9ae845b2634d29a8e876933a643
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 2cc4610304c58c3de05a36efbb7cd1710b9d440e ba771e706b8ae3a001a7b4b6f56db7fc747fefed && git checkout -B drift-repro 2cc4610304c58c3de05a36efbb7cd1710b9d440e && git merge --no-ff ba771e706b8ae3a001a7b4b6f56db7fc747fefed
node scripts/docs-audit/affected-docs.mjs --json 2cc4610304c58c3de05a36efbb7cd1710b9d440e

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

[os-musk]

PM: Check Changeset resolved, and the one remaining action is not mine to take

The red gate, read rather than guessed.Check Changeset was failure (run 100890560827). Its own job log names exactly two routes: apply skip-changeset if the PR releases nothing, otherwise run pnpm changeset and name the packages — and states that an empty-frontmatter changeset is not a third option.

Route taken: skip-changeset. This PR modifies.changeset/repo-execute-elevated-context.md; it does not add one. The release it corrects is already declared on main by #15051, and this PR adds no package bump of its own — it changes what that release's note says, not what it releases. Adding a second changeset would declare a release that does not exist.

Label write — read-modify-write with compare read-back, per protocol:

• before: documentation, size/s, tooling
• written: the same three plus skip-changeset
• read back live: documentation, size/s, tooling, skip-changeset — matches the union exactly, nothing stripped by a concurrent writer.

The label event re-fired the workflow: new Check Changeset run 100892547790 → skipped (02:43:32Z). The earlier failure run remains visible in the check-run list as a superseded run; the latest run per check name is what branch protection reads.

One claim in this PR independently re-verified, not taken from the report. The only non-prose edit here is the shifted census anchor. Reading packages/objectql/src/engine.ts at head ba771e706 line 14523: get isSystem() { return this.executionContext.isSystem; } — the ScopedContext.isSystem getter, exactly what the table row claims. The --fix re-derivation is correct. (Note for the record: the PR body's prose says the docstring shifted later lines "by 26"; the actual shift is 27, 14496 → 14523. The anchor written to the doc is right; only the prose describing the offset is off by one.)

State now: 35 of 37 check runs green or skipped; Test Core (1/6) and Lint & Repo Gates still in progress at the time of writing. Not governed (check-governed-merges.mjs --test → 0 of 3 paths). Clause-② no — prose only: no new exported symbol, no new key on a published payload.

⛔ What this seat cannot do, stated plainly rather than left as silence. The PR is still a draft. GitHub exposes draft→ready only as the GraphQL mutation markPullRequestReadyForReview; REST PATCH on a pull request has no draft field, and the MCP update tool performs a GraphQL lookup before its REST write. This account's GraphQL quota is exhausted right now (REST calls continue to succeed — the split is REST vs GraphQL, not read vs write), so the flip is structurally unavailable from here, not merely worth retrying. Enabling auto-merge is blocked by the same two facts: it is a GraphQL mutation, and it refuses a draft PR regardless.

So one human action remains — mark this PR ready for review. After that the ordinary queue path applies; no other gate is outstanding. Flagging it here rather than reporting the PR as landed, because it is not.

---

Generated by Claude Code

[os-musk]

Superseded: the handoff above is no longer needed

The previous comment ended by asking a human to mark this PR ready for review, because the GraphQL bucket was exhausted and markPullRequestReadyForReview is the only door to that flip. The quota recovered a few minutes later and this seat did it itself — so ignore that ask; nothing is waiting on a person here.

Sequence, so the record is not just an assertion:

1. Check Changeset re-fired on the skip-changeset label event → run 100892547790, skipped.
2. All 39 check runs now read completed, zero in progress. Every conclusion is success or skipped. The one failure in the list is the superseded Check Changeset run 100890560827 from 02:33, whose successor is the skipped run above — branch protection reads the latest run per check name, and the last two stragglers went green at 02:46:59 (Test Core (1/6)) and 02:50:11 (Lint & Repo Gates).
3. Draft → ready: done.
4. Auto-merge: armed.

One caveat stated rather than dressed up as certainty. The auto-merge receipt came back in the empty form, (method: , enabled at ). That form carries no established meaning — both the filled and the empty form have preceded successful landings here, and an earlier claim in this seat's notes that the empty form meant "already queued" was measured false and withdrawn. There is a reliable positive reading (a merge_group workflow run on a gh-readonly-queue/main/pr-15131-… branch) but no cheap negative one, so arming is not proof of landing. At the time of writing this PR had not yet appeared in the queue; five other entries were ahead of it.

That matters because of how the last one failed: #15008 sat armed for seven hours without landing, because it had gone mergeable_state: "dirty" and auto-merge does not fire on a conflicted PR and emits no event. If this PR is still open some hours from now, that is the first thing to check — absence of an event is not evidence of progress.

---

Generated by Claude Code

[os-musk]

Part of #13866 — disclosure-completeness follow-up to #15051 (merged as a548550)

Why this exists

#15051 elevated ObjectRepository.execute()'s ctx.api to { ...callerContext, isSystem: true }, closing the third executeAction caller per #13866. Independent contract review returned exactly one finding on that PR, after it had already been merged by the maintainer: its "what widens" statement named only the static readonly strip, and that is true but materially incomplete. isSystem: true is a flag, not a behaviour — it is read by ObjectQL's registered security middleware as a total bypass, not a readonly-only one.

⛔ No implementation, census, ablation, gate, or changeset-level change. The elevation, the pins, the 5-case ablation and the patch level all stood on review — this PR only corrects the disclosure text in the three places that repeated the incomplete framing:

1. .changeset/repo-execute-elevated-context.md
2. the execute() docstring in packages/objectql/src/engine.ts
3. this comment thread + a body edit on fix(objectql): elevate ObjectRepository.execute() to REST/MCP's trusted posture #15051 itself (a merged PR's body can still be edited for the historical record — done in the same round as this PR)

A fourth file changed for mechanical reasons only: content/docs/permissions/system-context.mdx — the docstring insertion shifted every later line in engine.ts by 26, rotting one anchor (check-system-context-census.mjs's own --fix, pure line rot, no population/classification change: still 106 elevation-read sites in 20 packages across 45 files, all anchored).

The corrected "what widens" statement

ctx.api inside a repo.execute()-dispatched action handler carries isSystem: true, and ObjectQL's registered security middleware reads that as a total, unconditional bypass — plugin-security/src/security-plugin.ts:1614-1616, "System operations bypass security" / return next() ahead of every other gate in that middleware. Every find/insert/update/delete the handler drives through this ctx.api therefore also skips, in the same stroke as the readonly strip:

Behaviour	Anchor	Confirmed
Security middleware total short-circuit (the gate itself)	security-plugin.ts:1614-1616	✅
RLS read scoping (getReadFilter)	security-plugin.ts:4344	✅
Field-level security	security-plugin.ts:4495	✅
CRUD permission checks (same middleware)	security-plugin.ts:1616	✅
Export permission (canExport)	security-plugin.ts:4573	✅
ADR-0103 engine-owned/append-only write guard	system-write-guard.ts:96,120, called at security-plugin.ts:1736	✅
package-managed / system-row / curated-capability / audience-anchor write gates	security-plugin.ts:1690-1724	✅
Static readonly strip — UPDATE, single row	engine.ts:11290	✅
Static readonly strip — UPDATE, bulk	engine.ts:11473	✅
Static readonly/runtime-owned strip — INSERT (stripRuntimeOwnedFields, covers autonumber AND readonly together)	engine.ts:10025	✅
Referential-integrity check (assertReferencesResolve)	engine.ts:5892	✅
Tenant-audit mute	engine.ts:3773	✅
Hook-session isSystem propagation (carries the flag onward, not a gate)	engine.ts:3543 (buildSession)	✅
Audit attribution label ('system' vs 'anonymous', not a gate)	engine.ts:12014	✅

Every row re-derived independently by reading the cited line on this branch (not copied from the review) — see the terminal report for the full method.

Bounded on two sides, also re-verified independently:

• Metadata-plane schema masking (metadata-core/object-schema-fls.ts:228) is a separate REST/GraphQL schema-serving dispatch path (GET /meta/object/:name and friends) that this ctx.api surface (find/insert/update/delete/count/aggregate/execute) never calls into — confirmed by reading the file's own header (@objectstack/metadata-core depends on spec+zod only; its two consumers are @objectstack/rest and @objectstack/runtime's schema-serving exits, not the engine's registered middleware chain). isSystemdoes bypass this elsewhere in the platform (content/docs/permissions/system-context.mdx row 7) — just not reachable from this PR's widening.
• plugin-sharing/rule-hooks.ts's insert/update materialisation skip was already retired by the maintainer's 2026-08-31 ruling on 审批回写（系统身份）不触发共享规则物化，「批准后团队看不见」——平台只记一条日志、无补偿、无声明式手段 #13533 — confirmed by reading the file: the skip and its announcing INFO notice are both deleted, and the surviving isSystem check at rule-hooks.ts:292 is a different skip (delete-side revocation timing, delegated to record-share-cascade.ts, not a silencer) per the file's own comment. System and user writes materialise sharing grants identically today.
• Zero measured blast radius today: independently re-ran the chained-accessor grep (.object(x).execute() across packages/, examples/, apps/ — zero hits outside this PR's own pin test (engine-repo-execute-elevation.test.ts), against a firing positive control (.object(x).update( → 195 hits, .insert( → 49 hits) confirming the grep methodology isn't blind. So the widening is total in kind, empty in practice, today.

This matches the platform's own documented posture — content/docs/permissions/system-context.mdx: "Elevation is total, and it is not granular." — and REST /actions / MCP run_action already carry the identical exposure, so #15051 extends an existing bypass to a third dispatch path rather than introducing a new one.

Gates

node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack --commands (no paths — merge-base derivation against origin/main), re-derived after the anchor-fix commit: 73 commands on the final 3-file diff. All passed except two, both pre-existing "build the whole monorepo first" prerequisites unrelated to this diff (same shape #15051 itself reported):

• check:dual-build-cjs-loads → exit 3 PREREQUISITE NOT MET (needs every workspace package's dist/)
• @objectstack/spec check:skill-examples → needs @objectstack/client-react built (unrelated to packages/objectql/docs)

node scripts/pm/check-governed-merges.mjs --test .changeset/repo-execute-elevated-context.md content/docs/permissions/system-context.mdx packages/objectql/src/engine.ts → NOT governed (0 of 3 paths hit GOVERNED_SURFACES).

The PR's own 5 pins (packages/objectql/src/engine-repo-execute-elevation.test.ts) and the package typecheck were re-run on this branch to confirm the text-only edit disturbed neither: 5 passed (5), typecheck clean, both on final head ba771e706.

Scope note

No code behaviour changes here — only prose (a changeset paragraph, a docstring, one doc anchor). Left as draft; not enqueued, not auto-merge-armed. needs:contract-review was already cleared on #15051 when it merged — flagging in the report that this seat could not mechanically re-apply a label from here (no label-write tool available) and leaving that call to the PM/reviewing seat.

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

1 anchor(s) derived from 1 changed package(s); no hand-written page names any of them, so this run has nothing to list — not a clean bill of health. This check sees only pages that NAME a derived anchor: one that documents this change in prose, or enumerates it in an authoring dialect, names none and stays invisible to it on every run.

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 — 16 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 2cc4610304c58c3de05a36efbb7cd1710b9d440e → packageMentionDocs.

Which tree this was computed on

This run read content/docs from 491493b45069b9ae845b2634d29a8e876933a643 — the merge of head ba771e706b8ae3a001a7b4b6f56db7fc747fefed into base 2cc4610304c58c3de05a36efbb7cd1710b9d440e, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin 491493b45069b9ae845b2634d29a8e876933a643 && git checkout 491493b45069b9ae845b2634d29a8e876933a643
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 2cc4610304c58c3de05a36efbb7cd1710b9d440e ba771e706b8ae3a001a7b4b6f56db7fc747fefed && git checkout -B drift-repro 2cc4610304c58c3de05a36efbb7cd1710b9d440e && git merge --no-ff ba771e706b8ae3a001a7b4b6f56db7fc747fefed
node scripts/docs-audit/affected-docs.mjs --json 2cc4610304c58c3de05a36efbb7cd1710b9d440e

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

[os-musk]

PM: Check Changeset resolved, and the one remaining action is not mine to take

The red gate, read rather than guessed.Check Changeset was failure (run 100890560827). Its own job log names exactly two routes: apply skip-changeset if the PR releases nothing, otherwise run pnpm changeset and name the packages — and states that an empty-frontmatter changeset is not a third option.

Route taken: skip-changeset. This PR modifies.changeset/repo-execute-elevated-context.md; it does not add one. The release it corrects is already declared on main by #15051, and this PR adds no package bump of its own — it changes what that release's note says, not what it releases. Adding a second changeset would declare a release that does not exist.

Label write — read-modify-write with compare read-back, per protocol:

• before: documentation, size/s, tooling
• written: the same three plus skip-changeset
• read back live: documentation, size/s, tooling, skip-changeset — matches the union exactly, nothing stripped by a concurrent writer.

The label event re-fired the workflow: new Check Changeset run 100892547790 → skipped (02:43:32Z). The earlier failure run remains visible in the check-run list as a superseded run; the latest run per check name is what branch protection reads.

One claim in this PR independently re-verified, not taken from the report. The only non-prose edit here is the shifted census anchor. Reading packages/objectql/src/engine.ts at head ba771e706 line 14523: get isSystem() { return this.executionContext.isSystem; } — the ScopedContext.isSystem getter, exactly what the table row claims. The --fix re-derivation is correct. (Note for the record: the PR body's prose says the docstring shifted later lines "by 26"; the actual shift is 27, 14496 → 14523. The anchor written to the doc is right; only the prose describing the offset is off by one.)

State now: 35 of 37 check runs green or skipped; Test Core (1/6) and Lint & Repo Gates still in progress at the time of writing. Not governed (check-governed-merges.mjs --test → 0 of 3 paths). Clause-② no — prose only: no new exported symbol, no new key on a published payload.

⛔ What this seat cannot do, stated plainly rather than left as silence. The PR is still a draft. GitHub exposes draft→ready only as the GraphQL mutation markPullRequestReadyForReview; REST PATCH on a pull request has no draft field, and the MCP update tool performs a GraphQL lookup before its REST write. This account's GraphQL quota is exhausted right now (REST calls continue to succeed — the split is REST vs GraphQL, not read vs write), so the flip is structurally unavailable from here, not merely worth retrying. Enabling auto-merge is blocked by the same two facts: it is a GraphQL mutation, and it refuses a draft PR regardless.

So one human action remains — mark this PR ready for review. After that the ordinary queue path applies; no other gate is outstanding. Flagging it here rather than reporting the PR as landed, because it is not.

---

Generated by Claude Code

[os-musk]

Superseded: the handoff above is no longer needed

The previous comment ended by asking a human to mark this PR ready for review, because the GraphQL bucket was exhausted and markPullRequestReadyForReview is the only door to that flip. The quota recovered a few minutes later and this seat did it itself — so ignore that ask; nothing is waiting on a person here.

Sequence, so the record is not just an assertion:

1. Check Changeset re-fired on the skip-changeset label event → run 100892547790, skipped.
2. All 39 check runs now read completed, zero in progress. Every conclusion is success or skipped. The one failure in the list is the superseded Check Changeset run 100890560827 from 02:33, whose successor is the skipped run above — branch protection reads the latest run per check name, and the last two stragglers went green at 02:46:59 (Test Core (1/6)) and 02:50:11 (Lint & Repo Gates).
3. Draft → ready: done.
4. Auto-merge: armed.

One caveat stated rather than dressed up as certainty. The auto-merge receipt came back in the empty form, (method: , enabled at ). That form carries no established meaning — both the filled and the empty form have preceded successful landings here, and an earlier claim in this seat's notes that the empty form meant "already queued" was measured false and withdrawn. There is a reliable positive reading (a merge_group workflow run on a gh-readonly-queue/main/pr-15131-… branch) but no cheap negative one, so arming is not proof of landing. At the time of writing this PR had not yet appeared in the queue; five other entries were ahead of it.

That matters because of how the last one failed: #15008 sat armed for seven hours without landing, because it had gone mergeable_state: "dirty" and auto-merge does not fire on a conflicted PR and emits no event. If this PR is still open some hours from now, that is the first thing to check — absence of an event is not evidence of progress.

---

Generated by Claude Code

[os-musk]

Part of #13866 — disclosure-completeness follow-up to #15051 (merged as a548550)

Why this exists

#15051 elevated ObjectRepository.execute()'s ctx.api to { ...callerContext, isSystem: true }, closing the third executeAction caller per #13866. Independent contract review returned exactly one finding on that PR, after it had already been merged by the maintainer: its "what widens" statement named only the static readonly strip, and that is true but materially incomplete. isSystem: true is a flag, not a behaviour — it is read by ObjectQL's registered security middleware as a total bypass, not a readonly-only one.

⛔ No implementation, census, ablation, gate, or changeset-level change. The elevation, the pins, the 5-case ablation and the patch level all stood on review — this PR only corrects the disclosure text in the three places that repeated the incomplete framing:

1. .changeset/repo-execute-elevated-context.md
2. the execute() docstring in packages/objectql/src/engine.ts
3. this comment thread + a body edit on fix(objectql): elevate ObjectRepository.execute() to REST/MCP's trusted posture #15051 itself (a merged PR's body can still be edited for the historical record — done in the same round as this PR)

A fourth file changed for mechanical reasons only: content/docs/permissions/system-context.mdx — the docstring insertion shifted every later line in engine.ts by 26, rotting one anchor (check-system-context-census.mjs's own --fix, pure line rot, no population/classification change: still 106 elevation-read sites in 20 packages across 45 files, all anchored).

The corrected "what widens" statement

ctx.api inside a repo.execute()-dispatched action handler carries isSystem: true, and ObjectQL's registered security middleware reads that as a total, unconditional bypass — plugin-security/src/security-plugin.ts:1614-1616, "System operations bypass security" / return next() ahead of every other gate in that middleware. Every find/insert/update/delete the handler drives through this ctx.api therefore also skips, in the same stroke as the readonly strip:

Behaviour	Anchor	Confirmed
Security middleware total short-circuit (the gate itself)	security-plugin.ts:1614-1616	✅
RLS read scoping (getReadFilter)	security-plugin.ts:4344	✅
Field-level security	security-plugin.ts:4495	✅
CRUD permission checks (same middleware)	security-plugin.ts:1616	✅
Export permission (canExport)	security-plugin.ts:4573	✅
ADR-0103 engine-owned/append-only write guard	system-write-guard.ts:96,120, called at security-plugin.ts:1736	✅
package-managed / system-row / curated-capability / audience-anchor write gates	security-plugin.ts:1690-1724	✅
Static readonly strip — UPDATE, single row	engine.ts:11290	✅
Static readonly strip — UPDATE, bulk	engine.ts:11473	✅
Static readonly/runtime-owned strip — INSERT (stripRuntimeOwnedFields, covers autonumber AND readonly together)	engine.ts:10025	✅
Referential-integrity check (assertReferencesResolve)	engine.ts:5892	✅
Tenant-audit mute	engine.ts:3773	✅
Hook-session isSystem propagation (carries the flag onward, not a gate)	engine.ts:3543 (buildSession)	✅
Audit attribution label ('system' vs 'anonymous', not a gate)	engine.ts:12014	✅

Every row re-derived independently by reading the cited line on this branch (not copied from the review) — see the terminal report for the full method.

Bounded on two sides, also re-verified independently:

• Metadata-plane schema masking (metadata-core/object-schema-fls.ts:228) is a separate REST/GraphQL schema-serving dispatch path (GET /meta/object/:name and friends) that this ctx.api surface (find/insert/update/delete/count/aggregate/execute) never calls into — confirmed by reading the file's own header (@objectstack/metadata-core depends on spec+zod only; its two consumers are @objectstack/rest and @objectstack/runtime's schema-serving exits, not the engine's registered middleware chain). isSystemdoes bypass this elsewhere in the platform (content/docs/permissions/system-context.mdx row 7) — just not reachable from this PR's widening.
• plugin-sharing/rule-hooks.ts's insert/update materialisation skip was already retired by the maintainer's 2026-08-31 ruling on 审批回写（系统身份）不触发共享规则物化，「批准后团队看不见」——平台只记一条日志、无补偿、无声明式手段 #13533 — confirmed by reading the file: the skip and its announcing INFO notice are both deleted, and the surviving isSystem check at rule-hooks.ts:292 is a different skip (delete-side revocation timing, delegated to record-share-cascade.ts, not a silencer) per the file's own comment. System and user writes materialise sharing grants identically today.
• Zero measured blast radius today: independently re-ran the chained-accessor grep (.object(x).execute() across packages/, examples/, apps/ — zero hits outside this PR's own pin test (engine-repo-execute-elevation.test.ts), against a firing positive control (.object(x).update( → 195 hits, .insert( → 49 hits) confirming the grep methodology isn't blind. So the widening is total in kind, empty in practice, today.

This matches the platform's own documented posture — content/docs/permissions/system-context.mdx: "Elevation is total, and it is not granular." — and REST /actions / MCP run_action already carry the identical exposure, so #15051 extends an existing bypass to a third dispatch path rather than introducing a new one.

Gates

node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack --commands (no paths — merge-base derivation against origin/main), re-derived after the anchor-fix commit: 73 commands on the final 3-file diff. All passed except two, both pre-existing "build the whole monorepo first" prerequisites unrelated to this diff (same shape #15051 itself reported):

• check:dual-build-cjs-loads → exit 3 PREREQUISITE NOT MET (needs every workspace package's dist/)
• @objectstack/spec check:skill-examples → needs @objectstack/client-react built (unrelated to packages/objectql/docs)

node scripts/pm/check-governed-merges.mjs --test .changeset/repo-execute-elevated-context.md content/docs/permissions/system-context.mdx packages/objectql/src/engine.ts → NOT governed (0 of 3 paths hit GOVERNED_SURFACES).

The PR's own 5 pins (packages/objectql/src/engine-repo-execute-elevation.test.ts) and the package typecheck were re-run on this branch to confirm the text-only edit disturbed neither: 5 passed (5), typecheck clean, both on final head ba771e706.

Scope note

No code behaviour changes here — only prose (a changeset paragraph, a docstring, one doc anchor). Left as draft; not enqueued, not auto-merge-armed. needs:contract-review was already cleared on #15051 when it merged — flagging in the report that this seat could not mechanically re-apply a label from here (no label-write tool available) and leaving that call to the PM/reviewing seat.

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

1 anchor(s) derived from 1 changed package(s); no hand-written page names any of them, so this run has nothing to list — not a clean bill of health. This check sees only pages that NAME a derived anchor: one that documents this change in prose, or enumerates it in an authoring dialect, names none and stays invisible to it on every run.

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 — 16 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 2cc4610304c58c3de05a36efbb7cd1710b9d440e → packageMentionDocs.

Which tree this was computed on

This run read content/docs from 491493b45069b9ae845b2634d29a8e876933a643 — the merge of head ba771e706b8ae3a001a7b4b6f56db7fc747fefed into base 2cc4610304c58c3de05a36efbb7cd1710b9d440e, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin 491493b45069b9ae845b2634d29a8e876933a643 && git checkout 491493b45069b9ae845b2634d29a8e876933a643
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 2cc4610304c58c3de05a36efbb7cd1710b9d440e ba771e706b8ae3a001a7b4b6f56db7fc747fefed && git checkout -B drift-repro 2cc4610304c58c3de05a36efbb7cd1710b9d440e && git merge --no-ff ba771e706b8ae3a001a7b4b6f56db7fc747fefed
node scripts/docs-audit/affected-docs.mjs --json 2cc4610304c58c3de05a36efbb7cd1710b9d440e

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

[os-musk]

PM: Check Changeset resolved, and the one remaining action is not mine to take

The red gate, read rather than guessed.Check Changeset was failure (run 100890560827). Its own job log names exactly two routes: apply skip-changeset if the PR releases nothing, otherwise run pnpm changeset and name the packages — and states that an empty-frontmatter changeset is not a third option.

Route taken: skip-changeset. This PR modifies.changeset/repo-execute-elevated-context.md; it does not add one. The release it corrects is already declared on main by #15051, and this PR adds no package bump of its own — it changes what that release's note says, not what it releases. Adding a second changeset would declare a release that does not exist.

Label write — read-modify-write with compare read-back, per protocol:

• before: documentation, size/s, tooling
• written: the same three plus skip-changeset
• read back live: documentation, size/s, tooling, skip-changeset — matches the union exactly, nothing stripped by a concurrent writer.

The label event re-fired the workflow: new Check Changeset run 100892547790 → skipped (02:43:32Z). The earlier failure run remains visible in the check-run list as a superseded run; the latest run per check name is what branch protection reads.

One claim in this PR independently re-verified, not taken from the report. The only non-prose edit here is the shifted census anchor. Reading packages/objectql/src/engine.ts at head ba771e706 line 14523: get isSystem() { return this.executionContext.isSystem; } — the ScopedContext.isSystem getter, exactly what the table row claims. The --fix re-derivation is correct. (Note for the record: the PR body's prose says the docstring shifted later lines "by 26"; the actual shift is 27, 14496 → 14523. The anchor written to the doc is right; only the prose describing the offset is off by one.)

State now: 35 of 37 check runs green or skipped; Test Core (1/6) and Lint & Repo Gates still in progress at the time of writing. Not governed (check-governed-merges.mjs --test → 0 of 3 paths). Clause-② no — prose only: no new exported symbol, no new key on a published payload.

⛔ What this seat cannot do, stated plainly rather than left as silence. The PR is still a draft. GitHub exposes draft→ready only as the GraphQL mutation markPullRequestReadyForReview; REST PATCH on a pull request has no draft field, and the MCP update tool performs a GraphQL lookup before its REST write. This account's GraphQL quota is exhausted right now (REST calls continue to succeed — the split is REST vs GraphQL, not read vs write), so the flip is structurally unavailable from here, not merely worth retrying. Enabling auto-merge is blocked by the same two facts: it is a GraphQL mutation, and it refuses a draft PR regardless.

So one human action remains — mark this PR ready for review. After that the ordinary queue path applies; no other gate is outstanding. Flagging it here rather than reporting the PR as landed, because it is not.

---

Generated by Claude Code

[os-musk]

Superseded: the handoff above is no longer needed

The previous comment ended by asking a human to mark this PR ready for review, because the GraphQL bucket was exhausted and markPullRequestReadyForReview is the only door to that flip. The quota recovered a few minutes later and this seat did it itself — so ignore that ask; nothing is waiting on a person here.

Sequence, so the record is not just an assertion:

1. Check Changeset re-fired on the skip-changeset label event → run 100892547790, skipped.
2. All 39 check runs now read completed, zero in progress. Every conclusion is success or skipped. The one failure in the list is the superseded Check Changeset run 100890560827 from 02:33, whose successor is the skipped run above — branch protection reads the latest run per check name, and the last two stragglers went green at 02:46:59 (Test Core (1/6)) and 02:50:11 (Lint & Repo Gates).
3. Draft → ready: done.
4. Auto-merge: armed.

One caveat stated rather than dressed up as certainty. The auto-merge receipt came back in the empty form, (method: , enabled at ). That form carries no established meaning — both the filled and the empty form have preceded successful landings here, and an earlier claim in this seat's notes that the empty form meant "already queued" was measured false and withdrawn. There is a reliable positive reading (a merge_group workflow run on a gh-readonly-queue/main/pr-15131-… branch) but no cheap negative one, so arming is not proof of landing. At the time of writing this PR had not yet appeared in the queue; five other entries were ahead of it.

That matters because of how the last one failed: #15008 sat armed for seven hours without landing, because it had gone mergeable_state: "dirty" and auto-merge does not fire on a conflicted PR and emits no event. If this PR is still open some hours from now, that is the first thing to check — absence of an event is not evidence of progress.

---

Generated by Claude Code

[os-musk]

Part of #13866 — disclosure-completeness follow-up to #15051 (merged as a548550)

Why this exists

#15051 elevated ObjectRepository.execute()'s ctx.api to { ...callerContext, isSystem: true }, closing the third executeAction caller per #13866. Independent contract review returned exactly one finding on that PR, after it had already been merged by the maintainer: its "what widens" statement named only the static readonly strip, and that is true but materially incomplete. isSystem: true is a flag, not a behaviour — it is read by ObjectQL's registered security middleware as a total bypass, not a readonly-only one.

⛔ No implementation, census, ablation, gate, or changeset-level change. The elevation, the pins, the 5-case ablation and the patch level all stood on review — this PR only corrects the disclosure text in the three places that repeated the incomplete framing:

1. .changeset/repo-execute-elevated-context.md
2. the execute() docstring in packages/objectql/src/engine.ts
3. this comment thread + a body edit on fix(objectql): elevate ObjectRepository.execute() to REST/MCP's trusted posture #15051 itself (a merged PR's body can still be edited for the historical record — done in the same round as this PR)

A fourth file changed for mechanical reasons only: content/docs/permissions/system-context.mdx — the docstring insertion shifted every later line in engine.ts by 26, rotting one anchor (check-system-context-census.mjs's own --fix, pure line rot, no population/classification change: still 106 elevation-read sites in 20 packages across 45 files, all anchored).

The corrected "what widens" statement

ctx.api inside a repo.execute()-dispatched action handler carries isSystem: true, and ObjectQL's registered security middleware reads that as a total, unconditional bypass — plugin-security/src/security-plugin.ts:1614-1616, "System operations bypass security" / return next() ahead of every other gate in that middleware. Every find/insert/update/delete the handler drives through this ctx.api therefore also skips, in the same stroke as the readonly strip:

Behaviour	Anchor	Confirmed
Security middleware total short-circuit (the gate itself)	security-plugin.ts:1614-1616	✅
RLS read scoping (getReadFilter)	security-plugin.ts:4344	✅
Field-level security	security-plugin.ts:4495	✅
CRUD permission checks (same middleware)	security-plugin.ts:1616	✅
Export permission (canExport)	security-plugin.ts:4573	✅
ADR-0103 engine-owned/append-only write guard	system-write-guard.ts:96,120, called at security-plugin.ts:1736	✅
package-managed / system-row / curated-capability / audience-anchor write gates	security-plugin.ts:1690-1724	✅
Static readonly strip — UPDATE, single row	engine.ts:11290	✅
Static readonly strip — UPDATE, bulk	engine.ts:11473	✅
Static readonly/runtime-owned strip — INSERT (stripRuntimeOwnedFields, covers autonumber AND readonly together)	engine.ts:10025	✅
Referential-integrity check (assertReferencesResolve)	engine.ts:5892	✅
Tenant-audit mute	engine.ts:3773	✅
Hook-session isSystem propagation (carries the flag onward, not a gate)	engine.ts:3543 (buildSession)	✅
Audit attribution label ('system' vs 'anonymous', not a gate)	engine.ts:12014	✅

Every row re-derived independently by reading the cited line on this branch (not copied from the review) — see the terminal report for the full method.

Bounded on two sides, also re-verified independently:

• Metadata-plane schema masking (metadata-core/object-schema-fls.ts:228) is a separate REST/GraphQL schema-serving dispatch path (GET /meta/object/:name and friends) that this ctx.api surface (find/insert/update/delete/count/aggregate/execute) never calls into — confirmed by reading the file's own header (@objectstack/metadata-core depends on spec+zod only; its two consumers are @objectstack/rest and @objectstack/runtime's schema-serving exits, not the engine's registered middleware chain). isSystemdoes bypass this elsewhere in the platform (content/docs/permissions/system-context.mdx row 7) — just not reachable from this PR's widening.
• plugin-sharing/rule-hooks.ts's insert/update materialisation skip was already retired by the maintainer's 2026-08-31 ruling on 审批回写（系统身份）不触发共享规则物化，「批准后团队看不见」——平台只记一条日志、无补偿、无声明式手段 #13533 — confirmed by reading the file: the skip and its announcing INFO notice are both deleted, and the surviving isSystem check at rule-hooks.ts:292 is a different skip (delete-side revocation timing, delegated to record-share-cascade.ts, not a silencer) per the file's own comment. System and user writes materialise sharing grants identically today.
• Zero measured blast radius today: independently re-ran the chained-accessor grep (.object(x).execute() across packages/, examples/, apps/ — zero hits outside this PR's own pin test (engine-repo-execute-elevation.test.ts), against a firing positive control (.object(x).update( → 195 hits, .insert( → 49 hits) confirming the grep methodology isn't blind. So the widening is total in kind, empty in practice, today.

This matches the platform's own documented posture — content/docs/permissions/system-context.mdx: "Elevation is total, and it is not granular." — and REST /actions / MCP run_action already carry the identical exposure, so #15051 extends an existing bypass to a third dispatch path rather than introducing a new one.

Gates

node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack --commands (no paths — merge-base derivation against origin/main), re-derived after the anchor-fix commit: 73 commands on the final 3-file diff. All passed except two, both pre-existing "build the whole monorepo first" prerequisites unrelated to this diff (same shape #15051 itself reported):

• check:dual-build-cjs-loads → exit 3 PREREQUISITE NOT MET (needs every workspace package's dist/)
• @objectstack/spec check:skill-examples → needs @objectstack/client-react built (unrelated to packages/objectql/docs)

node scripts/pm/check-governed-merges.mjs --test .changeset/repo-execute-elevated-context.md content/docs/permissions/system-context.mdx packages/objectql/src/engine.ts → NOT governed (0 of 3 paths hit GOVERNED_SURFACES).

The PR's own 5 pins (packages/objectql/src/engine-repo-execute-elevation.test.ts) and the package typecheck were re-run on this branch to confirm the text-only edit disturbed neither: 5 passed (5), typecheck clean, both on final head ba771e706.

Scope note

No code behaviour changes here — only prose (a changeset paragraph, a docstring, one doc anchor). Left as draft; not enqueued, not auto-merge-armed. needs:contract-review was already cleared on #15051 when it merged — flagging in the report that this seat could not mechanically re-apply a label from here (no label-write tool available) and leaving that call to the PM/reviewing seat.

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

1 anchor(s) derived from 1 changed package(s); no hand-written page names any of them, so this run has nothing to list — not a clean bill of health. This check sees only pages that NAME a derived anchor: one that documents this change in prose, or enumerates it in an authoring dialect, names none and stays invisible to it on every run.

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 — 16 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 2cc4610304c58c3de05a36efbb7cd1710b9d440e → packageMentionDocs.

Which tree this was computed on

This run read content/docs from 491493b45069b9ae845b2634d29a8e876933a643 — the merge of head ba771e706b8ae3a001a7b4b6f56db7fc747fefed into base 2cc4610304c58c3de05a36efbb7cd1710b9d440e, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin 491493b45069b9ae845b2634d29a8e876933a643 && git checkout 491493b45069b9ae845b2634d29a8e876933a643
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 2cc4610304c58c3de05a36efbb7cd1710b9d440e ba771e706b8ae3a001a7b4b6f56db7fc747fefed && git checkout -B drift-repro 2cc4610304c58c3de05a36efbb7cd1710b9d440e && git merge --no-ff ba771e706b8ae3a001a7b4b6f56db7fc747fefed
node scripts/docs-audit/affected-docs.mjs --json 2cc4610304c58c3de05a36efbb7cd1710b9d440e

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

[os-musk]

PM: Check Changeset resolved, and the one remaining action is not mine to take

The red gate, read rather than guessed.Check Changeset was failure (run 100890560827). Its own job log names exactly two routes: apply skip-changeset if the PR releases nothing, otherwise run pnpm changeset and name the packages — and states that an empty-frontmatter changeset is not a third option.

Route taken: skip-changeset. This PR modifies.changeset/repo-execute-elevated-context.md; it does not add one. The release it corrects is already declared on main by #15051, and this PR adds no package bump of its own — it changes what that release's note says, not what it releases. Adding a second changeset would declare a release that does not exist.

Label write — read-modify-write with compare read-back, per protocol:

• before: documentation, size/s, tooling
• written: the same three plus skip-changeset
• read back live: documentation, size/s, tooling, skip-changeset — matches the union exactly, nothing stripped by a concurrent writer.

The label event re-fired the workflow: new Check Changeset run 100892547790 → skipped (02:43:32Z). The earlier failure run remains visible in the check-run list as a superseded run; the latest run per check name is what branch protection reads.

One claim in this PR independently re-verified, not taken from the report. The only non-prose edit here is the shifted census anchor. Reading packages/objectql/src/engine.ts at head ba771e706 line 14523: get isSystem() { return this.executionContext.isSystem; } — the ScopedContext.isSystem getter, exactly what the table row claims. The --fix re-derivation is correct. (Note for the record: the PR body's prose says the docstring shifted later lines "by 26"; the actual shift is 27, 14496 → 14523. The anchor written to the doc is right; only the prose describing the offset is off by one.)

State now: 35 of 37 check runs green or skipped; Test Core (1/6) and Lint & Repo Gates still in progress at the time of writing. Not governed (check-governed-merges.mjs --test → 0 of 3 paths). Clause-② no — prose only: no new exported symbol, no new key on a published payload.

⛔ What this seat cannot do, stated plainly rather than left as silence. The PR is still a draft. GitHub exposes draft→ready only as the GraphQL mutation markPullRequestReadyForReview; REST PATCH on a pull request has no draft field, and the MCP update tool performs a GraphQL lookup before its REST write. This account's GraphQL quota is exhausted right now (REST calls continue to succeed — the split is REST vs GraphQL, not read vs write), so the flip is structurally unavailable from here, not merely worth retrying. Enabling auto-merge is blocked by the same two facts: it is a GraphQL mutation, and it refuses a draft PR regardless.

So one human action remains — mark this PR ready for review. After that the ordinary queue path applies; no other gate is outstanding. Flagging it here rather than reporting the PR as landed, because it is not.

---

Generated by Claude Code

[os-musk]

Superseded: the handoff above is no longer needed

The previous comment ended by asking a human to mark this PR ready for review, because the GraphQL bucket was exhausted and markPullRequestReadyForReview is the only door to that flip. The quota recovered a few minutes later and this seat did it itself — so ignore that ask; nothing is waiting on a person here.

Sequence, so the record is not just an assertion:

1. Check Changeset re-fired on the skip-changeset label event → run 100892547790, skipped.
2. All 39 check runs now read completed, zero in progress. Every conclusion is success or skipped. The one failure in the list is the superseded Check Changeset run 100890560827 from 02:33, whose successor is the skipped run above — branch protection reads the latest run per check name, and the last two stragglers went green at 02:46:59 (Test Core (1/6)) and 02:50:11 (Lint & Repo Gates).
3. Draft → ready: done.
4. Auto-merge: armed.

One caveat stated rather than dressed up as certainty. The auto-merge receipt came back in the empty form, (method: , enabled at ). That form carries no established meaning — both the filled and the empty form have preceded successful landings here, and an earlier claim in this seat's notes that the empty form meant "already queued" was measured false and withdrawn. There is a reliable positive reading (a merge_group workflow run on a gh-readonly-queue/main/pr-15131-… branch) but no cheap negative one, so arming is not proof of landing. At the time of writing this PR had not yet appeared in the queue; five other entries were ahead of it.

That matters because of how the last one failed: #15008 sat armed for seven hours without landing, because it had gone mergeable_state: "dirty" and auto-merge does not fire on a conflicted PR and emits no event. If this PR is still open some hours from now, that is the first thing to check — absence of an event is not evidence of progress.

---

Generated by Claude Code

[os-musk]

Part of #13866 — disclosure-completeness follow-up to #15051 (merged as a548550)

Why this exists

#15051 elevated ObjectRepository.execute()'s ctx.api to { ...callerContext, isSystem: true }, closing the third executeAction caller per #13866. Independent contract review returned exactly one finding on that PR, after it had already been merged by the maintainer: its "what widens" statement named only the static readonly strip, and that is true but materially incomplete. isSystem: true is a flag, not a behaviour — it is read by ObjectQL's registered security middleware as a total bypass, not a readonly-only one.

⛔ No implementation, census, ablation, gate, or changeset-level change. The elevation, the pins, the 5-case ablation and the patch level all stood on review — this PR only corrects the disclosure text in the three places that repeated the incomplete framing:

1. .changeset/repo-execute-elevated-context.md
2. the execute() docstring in packages/objectql/src/engine.ts
3. this comment thread + a body edit on fix(objectql): elevate ObjectRepository.execute() to REST/MCP's trusted posture #15051 itself (a merged PR's body can still be edited for the historical record — done in the same round as this PR)

A fourth file changed for mechanical reasons only: content/docs/permissions/system-context.mdx — the docstring insertion shifted every later line in engine.ts by 26, rotting one anchor (check-system-context-census.mjs's own --fix, pure line rot, no population/classification change: still 106 elevation-read sites in 20 packages across 45 files, all anchored).

The corrected "what widens" statement

ctx.api inside a repo.execute()-dispatched action handler carries isSystem: true, and ObjectQL's registered security middleware reads that as a total, unconditional bypass — plugin-security/src/security-plugin.ts:1614-1616, "System operations bypass security" / return next() ahead of every other gate in that middleware. Every find/insert/update/delete the handler drives through this ctx.api therefore also skips, in the same stroke as the readonly strip:

Behaviour	Anchor	Confirmed
Security middleware total short-circuit (the gate itself)	security-plugin.ts:1614-1616	✅
RLS read scoping (getReadFilter)	security-plugin.ts:4344	✅
Field-level security	security-plugin.ts:4495	✅
CRUD permission checks (same middleware)	security-plugin.ts:1616	✅
Export permission (canExport)	security-plugin.ts:4573	✅
ADR-0103 engine-owned/append-only write guard	system-write-guard.ts:96,120, called at security-plugin.ts:1736	✅
package-managed / system-row / curated-capability / audience-anchor write gates	security-plugin.ts:1690-1724	✅
Static readonly strip — UPDATE, single row	engine.ts:11290	✅
Static readonly strip — UPDATE, bulk	engine.ts:11473	✅
Static readonly/runtime-owned strip — INSERT (stripRuntimeOwnedFields, covers autonumber AND readonly together)	engine.ts:10025	✅
Referential-integrity check (assertReferencesResolve)	engine.ts:5892	✅
Tenant-audit mute	engine.ts:3773	✅
Hook-session isSystem propagation (carries the flag onward, not a gate)	engine.ts:3543 (buildSession)	✅
Audit attribution label ('system' vs 'anonymous', not a gate)	engine.ts:12014	✅

Every row re-derived independently by reading the cited line on this branch (not copied from the review) — see the terminal report for the full method.

Bounded on two sides, also re-verified independently:

• Metadata-plane schema masking (metadata-core/object-schema-fls.ts:228) is a separate REST/GraphQL schema-serving dispatch path (GET /meta/object/:name and friends) that this ctx.api surface (find/insert/update/delete/count/aggregate/execute) never calls into — confirmed by reading the file's own header (@objectstack/metadata-core depends on spec+zod only; its two consumers are @objectstack/rest and @objectstack/runtime's schema-serving exits, not the engine's registered middleware chain). isSystemdoes bypass this elsewhere in the platform (content/docs/permissions/system-context.mdx row 7) — just not reachable from this PR's widening.
• plugin-sharing/rule-hooks.ts's insert/update materialisation skip was already retired by the maintainer's 2026-08-31 ruling on 审批回写（系统身份）不触发共享规则物化，「批准后团队看不见」——平台只记一条日志、无补偿、无声明式手段 #13533 — confirmed by reading the file: the skip and its announcing INFO notice are both deleted, and the surviving isSystem check at rule-hooks.ts:292 is a different skip (delete-side revocation timing, delegated to record-share-cascade.ts, not a silencer) per the file's own comment. System and user writes materialise sharing grants identically today.
• Zero measured blast radius today: independently re-ran the chained-accessor grep (.object(x).execute() across packages/, examples/, apps/ — zero hits outside this PR's own pin test (engine-repo-execute-elevation.test.ts), against a firing positive control (.object(x).update( → 195 hits, .insert( → 49 hits) confirming the grep methodology isn't blind. So the widening is total in kind, empty in practice, today.

This matches the platform's own documented posture — content/docs/permissions/system-context.mdx: "Elevation is total, and it is not granular." — and REST /actions / MCP run_action already carry the identical exposure, so #15051 extends an existing bypass to a third dispatch path rather than introducing a new one.

Gates

node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack --commands (no paths — merge-base derivation against origin/main), re-derived after the anchor-fix commit: 73 commands on the final 3-file diff. All passed except two, both pre-existing "build the whole monorepo first" prerequisites unrelated to this diff (same shape #15051 itself reported):

• check:dual-build-cjs-loads → exit 3 PREREQUISITE NOT MET (needs every workspace package's dist/)
• @objectstack/spec check:skill-examples → needs @objectstack/client-react built (unrelated to packages/objectql/docs)

node scripts/pm/check-governed-merges.mjs --test .changeset/repo-execute-elevated-context.md content/docs/permissions/system-context.mdx packages/objectql/src/engine.ts → NOT governed (0 of 3 paths hit GOVERNED_SURFACES).

The PR's own 5 pins (packages/objectql/src/engine-repo-execute-elevation.test.ts) and the package typecheck were re-run on this branch to confirm the text-only edit disturbed neither: 5 passed (5), typecheck clean, both on final head ba771e706.

Scope note

No code behaviour changes here — only prose (a changeset paragraph, a docstring, one doc anchor). Left as draft; not enqueued, not auto-merge-armed. needs:contract-review was already cleared on #15051 when it merged — flagging in the report that this seat could not mechanically re-apply a label from here (no label-write tool available) and leaving that call to the PM/reviewing seat.

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

1 anchor(s) derived from 1 changed package(s); no hand-written page names any of them, so this run has nothing to list — not a clean bill of health. This check sees only pages that NAME a derived anchor: one that documents this change in prose, or enumerates it in an authoring dialect, names none and stays invisible to it on every run.

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 — 16 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 2cc4610304c58c3de05a36efbb7cd1710b9d440e → packageMentionDocs.

Which tree this was computed on

This run read content/docs from 491493b45069b9ae845b2634d29a8e876933a643 — the merge of head ba771e706b8ae3a001a7b4b6f56db7fc747fefed into base 2cc4610304c58c3de05a36efbb7cd1710b9d440e, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin 491493b45069b9ae845b2634d29a8e876933a643 && git checkout 491493b45069b9ae845b2634d29a8e876933a643
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 2cc4610304c58c3de05a36efbb7cd1710b9d440e ba771e706b8ae3a001a7b4b6f56db7fc747fefed && git checkout -B drift-repro 2cc4610304c58c3de05a36efbb7cd1710b9d440e && git merge --no-ff ba771e706b8ae3a001a7b4b6f56db7fc747fefed
node scripts/docs-audit/affected-docs.mjs --json 2cc4610304c58c3de05a36efbb7cd1710b9d440e

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

[os-musk]

PM: Check Changeset resolved, and the one remaining action is not mine to take

The red gate, read rather than guessed.Check Changeset was failure (run 100890560827). Its own job log names exactly two routes: apply skip-changeset if the PR releases nothing, otherwise run pnpm changeset and name the packages — and states that an empty-frontmatter changeset is not a third option.

Route taken: skip-changeset. This PR modifies.changeset/repo-execute-elevated-context.md; it does not add one. The release it corrects is already declared on main by #15051, and this PR adds no package bump of its own — it changes what that release's note says, not what it releases. Adding a second changeset would declare a release that does not exist.

Label write — read-modify-write with compare read-back, per protocol:

• before: documentation, size/s, tooling
• written: the same three plus skip-changeset
• read back live: documentation, size/s, tooling, skip-changeset — matches the union exactly, nothing stripped by a concurrent writer.

The label event re-fired the workflow: new Check Changeset run 100892547790 → skipped (02:43:32Z). The earlier failure run remains visible in the check-run list as a superseded run; the latest run per check name is what branch protection reads.

One claim in this PR independently re-verified, not taken from the report. The only non-prose edit here is the shifted census anchor. Reading packages/objectql/src/engine.ts at head ba771e706 line 14523: get isSystem() { return this.executionContext.isSystem; } — the ScopedContext.isSystem getter, exactly what the table row claims. The --fix re-derivation is correct. (Note for the record: the PR body's prose says the docstring shifted later lines "by 26"; the actual shift is 27, 14496 → 14523. The anchor written to the doc is right; only the prose describing the offset is off by one.)

State now: 35 of 37 check runs green or skipped; Test Core (1/6) and Lint & Repo Gates still in progress at the time of writing. Not governed (check-governed-merges.mjs --test → 0 of 3 paths). Clause-② no — prose only: no new exported symbol, no new key on a published payload.

⛔ What this seat cannot do, stated plainly rather than left as silence. The PR is still a draft. GitHub exposes draft→ready only as the GraphQL mutation markPullRequestReadyForReview; REST PATCH on a pull request has no draft field, and the MCP update tool performs a GraphQL lookup before its REST write. This account's GraphQL quota is exhausted right now (REST calls continue to succeed — the split is REST vs GraphQL, not read vs write), so the flip is structurally unavailable from here, not merely worth retrying. Enabling auto-merge is blocked by the same two facts: it is a GraphQL mutation, and it refuses a draft PR regardless.

So one human action remains — mark this PR ready for review. After that the ordinary queue path applies; no other gate is outstanding. Flagging it here rather than reporting the PR as landed, because it is not.

---

Generated by Claude Code

[os-musk]

Superseded: the handoff above is no longer needed

The previous comment ended by asking a human to mark this PR ready for review, because the GraphQL bucket was exhausted and markPullRequestReadyForReview is the only door to that flip. The quota recovered a few minutes later and this seat did it itself — so ignore that ask; nothing is waiting on a person here.

Sequence, so the record is not just an assertion:

1. Check Changeset re-fired on the skip-changeset label event → run 100892547790, skipped.
2. All 39 check runs now read completed, zero in progress. Every conclusion is success or skipped. The one failure in the list is the superseded Check Changeset run 100890560827 from 02:33, whose successor is the skipped run above — branch protection reads the latest run per check name, and the last two stragglers went green at 02:46:59 (Test Core (1/6)) and 02:50:11 (Lint & Repo Gates).
3. Draft → ready: done.
4. Auto-merge: armed.

One caveat stated rather than dressed up as certainty. The auto-merge receipt came back in the empty form, (method: , enabled at ). That form carries no established meaning — both the filled and the empty form have preceded successful landings here, and an earlier claim in this seat's notes that the empty form meant "already queued" was measured false and withdrawn. There is a reliable positive reading (a merge_group workflow run on a gh-readonly-queue/main/pr-15131-… branch) but no cheap negative one, so arming is not proof of landing. At the time of writing this PR had not yet appeared in the queue; five other entries were ahead of it.

That matters because of how the last one failed: #15008 sat armed for seven hours without landing, because it had gone mergeable_state: "dirty" and auto-merge does not fire on a conflicted PR and emits no event. If this PR is still open some hours from now, that is the first thing to check — absence of an event is not evidence of progress.

---

Generated by Claude Code

[os-musk]

Part of #13866 — disclosure-completeness follow-up to #15051 (merged as a548550)

Why this exists

#15051 elevated ObjectRepository.execute()'s ctx.api to { ...callerContext, isSystem: true }, closing the third executeAction caller per #13866. Independent contract review returned exactly one finding on that PR, after it had already been merged by the maintainer: its "what widens" statement named only the static readonly strip, and that is true but materially incomplete. isSystem: true is a flag, not a behaviour — it is read by ObjectQL's registered security middleware as a total bypass, not a readonly-only one.

⛔ No implementation, census, ablation, gate, or changeset-level change. The elevation, the pins, the 5-case ablation and the patch level all stood on review — this PR only corrects the disclosure text in the three places that repeated the incomplete framing:

1. .changeset/repo-execute-elevated-context.md
2. the execute() docstring in packages/objectql/src/engine.ts
3. this comment thread + a body edit on fix(objectql): elevate ObjectRepository.execute() to REST/MCP's trusted posture #15051 itself (a merged PR's body can still be edited for the historical record — done in the same round as this PR)

A fourth file changed for mechanical reasons only: content/docs/permissions/system-context.mdx — the docstring insertion shifted every later line in engine.ts by 26, rotting one anchor (check-system-context-census.mjs's own --fix, pure line rot, no population/classification change: still 106 elevation-read sites in 20 packages across 45 files, all anchored).

The corrected "what widens" statement

ctx.api inside a repo.execute()-dispatched action handler carries isSystem: true, and ObjectQL's registered security middleware reads that as a total, unconditional bypass — plugin-security/src/security-plugin.ts:1614-1616, "System operations bypass security" / return next() ahead of every other gate in that middleware. Every find/insert/update/delete the handler drives through this ctx.api therefore also skips, in the same stroke as the readonly strip:

Behaviour	Anchor	Confirmed
Security middleware total short-circuit (the gate itself)	security-plugin.ts:1614-1616	✅
RLS read scoping (getReadFilter)	security-plugin.ts:4344	✅
Field-level security	security-plugin.ts:4495	✅
CRUD permission checks (same middleware)	security-plugin.ts:1616	✅
Export permission (canExport)	security-plugin.ts:4573	✅
ADR-0103 engine-owned/append-only write guard	system-write-guard.ts:96,120, called at security-plugin.ts:1736	✅
package-managed / system-row / curated-capability / audience-anchor write gates	security-plugin.ts:1690-1724	✅
Static readonly strip — UPDATE, single row	engine.ts:11290	✅
Static readonly strip — UPDATE, bulk	engine.ts:11473	✅
Static readonly/runtime-owned strip — INSERT (stripRuntimeOwnedFields, covers autonumber AND readonly together)	engine.ts:10025	✅
Referential-integrity check (assertReferencesResolve)	engine.ts:5892	✅
Tenant-audit mute	engine.ts:3773	✅
Hook-session isSystem propagation (carries the flag onward, not a gate)	engine.ts:3543 (buildSession)	✅
Audit attribution label ('system' vs 'anonymous', not a gate)	engine.ts:12014	✅

Every row re-derived independently by reading the cited line on this branch (not copied from the review) — see the terminal report for the full method.

Bounded on two sides, also re-verified independently:

• Metadata-plane schema masking (metadata-core/object-schema-fls.ts:228) is a separate REST/GraphQL schema-serving dispatch path (GET /meta/object/:name and friends) that this ctx.api surface (find/insert/update/delete/count/aggregate/execute) never calls into — confirmed by reading the file's own header (@objectstack/metadata-core depends on spec+zod only; its two consumers are @objectstack/rest and @objectstack/runtime's schema-serving exits, not the engine's registered middleware chain). isSystemdoes bypass this elsewhere in the platform (content/docs/permissions/system-context.mdx row 7) — just not reachable from this PR's widening.
• plugin-sharing/rule-hooks.ts's insert/update materialisation skip was already retired by the maintainer's 2026-08-31 ruling on 审批回写（系统身份）不触发共享规则物化，「批准后团队看不见」——平台只记一条日志、无补偿、无声明式手段 #13533 — confirmed by reading the file: the skip and its announcing INFO notice are both deleted, and the surviving isSystem check at rule-hooks.ts:292 is a different skip (delete-side revocation timing, delegated to record-share-cascade.ts, not a silencer) per the file's own comment. System and user writes materialise sharing grants identically today.
• Zero measured blast radius today: independently re-ran the chained-accessor grep (.object(x).execute() across packages/, examples/, apps/ — zero hits outside this PR's own pin test (engine-repo-execute-elevation.test.ts), against a firing positive control (.object(x).update( → 195 hits, .insert( → 49 hits) confirming the grep methodology isn't blind. So the widening is total in kind, empty in practice, today.

This matches the platform's own documented posture — content/docs/permissions/system-context.mdx: "Elevation is total, and it is not granular." — and REST /actions / MCP run_action already carry the identical exposure, so #15051 extends an existing bypass to a third dispatch path rather than introducing a new one.

Gates

node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack --commands (no paths — merge-base derivation against origin/main), re-derived after the anchor-fix commit: 73 commands on the final 3-file diff. All passed except two, both pre-existing "build the whole monorepo first" prerequisites unrelated to this diff (same shape #15051 itself reported):

• check:dual-build-cjs-loads → exit 3 PREREQUISITE NOT MET (needs every workspace package's dist/)
• @objectstack/spec check:skill-examples → needs @objectstack/client-react built (unrelated to packages/objectql/docs)

node scripts/pm/check-governed-merges.mjs --test .changeset/repo-execute-elevated-context.md content/docs/permissions/system-context.mdx packages/objectql/src/engine.ts → NOT governed (0 of 3 paths hit GOVERNED_SURFACES).

The PR's own 5 pins (packages/objectql/src/engine-repo-execute-elevation.test.ts) and the package typecheck were re-run on this branch to confirm the text-only edit disturbed neither: 5 passed (5), typecheck clean, both on final head ba771e706.

Scope note

No code behaviour changes here — only prose (a changeset paragraph, a docstring, one doc anchor). Left as draft; not enqueued, not auto-merge-armed. needs:contract-review was already cleared on #15051 when it merged — flagging in the report that this seat could not mechanically re-apply a label from here (no label-write tool available) and leaving that call to the PM/reviewing seat.

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

1 anchor(s) derived from 1 changed package(s); no hand-written page names any of them, so this run has nothing to list — not a clean bill of health. This check sees only pages that NAME a derived anchor: one that documents this change in prose, or enumerates it in an authoring dialect, names none and stays invisible to it on every run.

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 — 16 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 2cc4610304c58c3de05a36efbb7cd1710b9d440e → packageMentionDocs.

Which tree this was computed on

This run read content/docs from 491493b45069b9ae845b2634d29a8e876933a643 — the merge of head ba771e706b8ae3a001a7b4b6f56db7fc747fefed into base 2cc4610304c58c3de05a36efbb7cd1710b9d440e, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin 491493b45069b9ae845b2634d29a8e876933a643 && git checkout 491493b45069b9ae845b2634d29a8e876933a643
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 2cc4610304c58c3de05a36efbb7cd1710b9d440e ba771e706b8ae3a001a7b4b6f56db7fc747fefed && git checkout -B drift-repro 2cc4610304c58c3de05a36efbb7cd1710b9d440e && git merge --no-ff ba771e706b8ae3a001a7b4b6f56db7fc747fefed
node scripts/docs-audit/affected-docs.mjs --json 2cc4610304c58c3de05a36efbb7cd1710b9d440e

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

[os-musk]

PM: Check Changeset resolved, and the one remaining action is not mine to take

The red gate, read rather than guessed.Check Changeset was failure (run 100890560827). Its own job log names exactly two routes: apply skip-changeset if the PR releases nothing, otherwise run pnpm changeset and name the packages — and states that an empty-frontmatter changeset is not a third option.

Route taken: skip-changeset. This PR modifies.changeset/repo-execute-elevated-context.md; it does not add one. The release it corrects is already declared on main by #15051, and this PR adds no package bump of its own — it changes what that release's note says, not what it releases. Adding a second changeset would declare a release that does not exist.

Label write — read-modify-write with compare read-back, per protocol:

• before: documentation, size/s, tooling
• written: the same three plus skip-changeset
• read back live: documentation, size/s, tooling, skip-changeset — matches the union exactly, nothing stripped by a concurrent writer.

The label event re-fired the workflow: new Check Changeset run 100892547790 → skipped (02:43:32Z). The earlier failure run remains visible in the check-run list as a superseded run; the latest run per check name is what branch protection reads.

One claim in this PR independently re-verified, not taken from the report. The only non-prose edit here is the shifted census anchor. Reading packages/objectql/src/engine.ts at head ba771e706 line 14523: get isSystem() { return this.executionContext.isSystem; } — the ScopedContext.isSystem getter, exactly what the table row claims. The --fix re-derivation is correct. (Note for the record: the PR body's prose says the docstring shifted later lines "by 26"; the actual shift is 27, 14496 → 14523. The anchor written to the doc is right; only the prose describing the offset is off by one.)

State now: 35 of 37 check runs green or skipped; Test Core (1/6) and Lint & Repo Gates still in progress at the time of writing. Not governed (check-governed-merges.mjs --test → 0 of 3 paths). Clause-② no — prose only: no new exported symbol, no new key on a published payload.

⛔ What this seat cannot do, stated plainly rather than left as silence. The PR is still a draft. GitHub exposes draft→ready only as the GraphQL mutation markPullRequestReadyForReview; REST PATCH on a pull request has no draft field, and the MCP update tool performs a GraphQL lookup before its REST write. This account's GraphQL quota is exhausted right now (REST calls continue to succeed — the split is REST vs GraphQL, not read vs write), so the flip is structurally unavailable from here, not merely worth retrying. Enabling auto-merge is blocked by the same two facts: it is a GraphQL mutation, and it refuses a draft PR regardless.

So one human action remains — mark this PR ready for review. After that the ordinary queue path applies; no other gate is outstanding. Flagging it here rather than reporting the PR as landed, because it is not.

---

Generated by Claude Code

[os-musk]

Superseded: the handoff above is no longer needed

The previous comment ended by asking a human to mark this PR ready for review, because the GraphQL bucket was exhausted and markPullRequestReadyForReview is the only door to that flip. The quota recovered a few minutes later and this seat did it itself — so ignore that ask; nothing is waiting on a person here.

Sequence, so the record is not just an assertion:

1. Check Changeset re-fired on the skip-changeset label event → run 100892547790, skipped.
2. All 39 check runs now read completed, zero in progress. Every conclusion is success or skipped. The one failure in the list is the superseded Check Changeset run 100890560827 from 02:33, whose successor is the skipped run above — branch protection reads the latest run per check name, and the last two stragglers went green at 02:46:59 (Test Core (1/6)) and 02:50:11 (Lint & Repo Gates).
3. Draft → ready: done.
4. Auto-merge: armed.

One caveat stated rather than dressed up as certainty. The auto-merge receipt came back in the empty form, (method: , enabled at ). That form carries no established meaning — both the filled and the empty form have preceded successful landings here, and an earlier claim in this seat's notes that the empty form meant "already queued" was measured false and withdrawn. There is a reliable positive reading (a merge_group workflow run on a gh-readonly-queue/main/pr-15131-… branch) but no cheap negative one, so arming is not proof of landing. At the time of writing this PR had not yet appeared in the queue; five other entries were ahead of it.

That matters because of how the last one failed: #15008 sat armed for seven hours without landing, because it had gone mergeable_state: "dirty" and auto-merge does not fire on a conflicted PR and emits no event. If this PR is still open some hours from now, that is the first thing to check — absence of an event is not evidence of progress.

---

Generated by Claude Code

[os-musk]

Part of #13866 — disclosure-completeness follow-up to #15051 (merged as a548550)

Why this exists

#15051 elevated ObjectRepository.execute()'s ctx.api to { ...callerContext, isSystem: true }, closing the third executeAction caller per #13866. Independent contract review returned exactly one finding on that PR, after it had already been merged by the maintainer: its "what widens" statement named only the static readonly strip, and that is true but materially incomplete. isSystem: true is a flag, not a behaviour — it is read by ObjectQL's registered security middleware as a total bypass, not a readonly-only one.

⛔ No implementation, census, ablation, gate, or changeset-level change. The elevation, the pins, the 5-case ablation and the patch level all stood on review — this PR only corrects the disclosure text in the three places that repeated the incomplete framing:

1. .changeset/repo-execute-elevated-context.md
2. the execute() docstring in packages/objectql/src/engine.ts
3. this comment thread + a body edit on fix(objectql): elevate ObjectRepository.execute() to REST/MCP's trusted posture #15051 itself (a merged PR's body can still be edited for the historical record — done in the same round as this PR)

A fourth file changed for mechanical reasons only: content/docs/permissions/system-context.mdx — the docstring insertion shifted every later line in engine.ts by 26, rotting one anchor (check-system-context-census.mjs's own --fix, pure line rot, no population/classification change: still 106 elevation-read sites in 20 packages across 45 files, all anchored).

The corrected "what widens" statement

ctx.api inside a repo.execute()-dispatched action handler carries isSystem: true, and ObjectQL's registered security middleware reads that as a total, unconditional bypass — plugin-security/src/security-plugin.ts:1614-1616, "System operations bypass security" / return next() ahead of every other gate in that middleware. Every find/insert/update/delete the handler drives through this ctx.api therefore also skips, in the same stroke as the readonly strip:

Behaviour	Anchor	Confirmed
Security middleware total short-circuit (the gate itself)	security-plugin.ts:1614-1616	✅
RLS read scoping (getReadFilter)	security-plugin.ts:4344	✅
Field-level security	security-plugin.ts:4495	✅
CRUD permission checks (same middleware)	security-plugin.ts:1616	✅
Export permission (canExport)	security-plugin.ts:4573	✅
ADR-0103 engine-owned/append-only write guard	system-write-guard.ts:96,120, called at security-plugin.ts:1736	✅
package-managed / system-row / curated-capability / audience-anchor write gates	security-plugin.ts:1690-1724	✅
Static readonly strip — UPDATE, single row	engine.ts:11290	✅
Static readonly strip — UPDATE, bulk	engine.ts:11473	✅
Static readonly/runtime-owned strip — INSERT (stripRuntimeOwnedFields, covers autonumber AND readonly together)	engine.ts:10025	✅
Referential-integrity check (assertReferencesResolve)	engine.ts:5892	✅
Tenant-audit mute	engine.ts:3773	✅
Hook-session isSystem propagation (carries the flag onward, not a gate)	engine.ts:3543 (buildSession)	✅
Audit attribution label ('system' vs 'anonymous', not a gate)	engine.ts:12014	✅

Every row re-derived independently by reading the cited line on this branch (not copied from the review) — see the terminal report for the full method.

Bounded on two sides, also re-verified independently:

• Metadata-plane schema masking (metadata-core/object-schema-fls.ts:228) is a separate REST/GraphQL schema-serving dispatch path (GET /meta/object/:name and friends) that this ctx.api surface (find/insert/update/delete/count/aggregate/execute) never calls into — confirmed by reading the file's own header (@objectstack/metadata-core depends on spec+zod only; its two consumers are @objectstack/rest and @objectstack/runtime's schema-serving exits, not the engine's registered middleware chain). isSystemdoes bypass this elsewhere in the platform (content/docs/permissions/system-context.mdx row 7) — just not reachable from this PR's widening.
• plugin-sharing/rule-hooks.ts's insert/update materialisation skip was already retired by the maintainer's 2026-08-31 ruling on 审批回写（系统身份）不触发共享规则物化，「批准后团队看不见」——平台只记一条日志、无补偿、无声明式手段 #13533 — confirmed by reading the file: the skip and its announcing INFO notice are both deleted, and the surviving isSystem check at rule-hooks.ts:292 is a different skip (delete-side revocation timing, delegated to record-share-cascade.ts, not a silencer) per the file's own comment. System and user writes materialise sharing grants identically today.
• Zero measured blast radius today: independently re-ran the chained-accessor grep (.object(x).execute() across packages/, examples/, apps/ — zero hits outside this PR's own pin test (engine-repo-execute-elevation.test.ts), against a firing positive control (.object(x).update( → 195 hits, .insert( → 49 hits) confirming the grep methodology isn't blind. So the widening is total in kind, empty in practice, today.

This matches the platform's own documented posture — content/docs/permissions/system-context.mdx: "Elevation is total, and it is not granular." — and REST /actions / MCP run_action already carry the identical exposure, so #15051 extends an existing bypass to a third dispatch path rather than introducing a new one.

Gates

node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack --commands (no paths — merge-base derivation against origin/main), re-derived after the anchor-fix commit: 73 commands on the final 3-file diff. All passed except two, both pre-existing "build the whole monorepo first" prerequisites unrelated to this diff (same shape #15051 itself reported):

• check:dual-build-cjs-loads → exit 3 PREREQUISITE NOT MET (needs every workspace package's dist/)
• @objectstack/spec check:skill-examples → needs @objectstack/client-react built (unrelated to packages/objectql/docs)

node scripts/pm/check-governed-merges.mjs --test .changeset/repo-execute-elevated-context.md content/docs/permissions/system-context.mdx packages/objectql/src/engine.ts → NOT governed (0 of 3 paths hit GOVERNED_SURFACES).

The PR's own 5 pins (packages/objectql/src/engine-repo-execute-elevation.test.ts) and the package typecheck were re-run on this branch to confirm the text-only edit disturbed neither: 5 passed (5), typecheck clean, both on final head ba771e706.

Scope note

No code behaviour changes here — only prose (a changeset paragraph, a docstring, one doc anchor). Left as draft; not enqueued, not auto-merge-armed. needs:contract-review was already cleared on #15051 when it merged — flagging in the report that this seat could not mechanically re-apply a label from here (no label-write tool available) and leaving that call to the PM/reviewing seat.

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

1 anchor(s) derived from 1 changed package(s); no hand-written page names any of them, so this run has nothing to list — not a clean bill of health. This check sees only pages that NAME a derived anchor: one that documents this change in prose, or enumerates it in an authoring dialect, names none and stays invisible to it on every run.

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 — 16 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 2cc4610304c58c3de05a36efbb7cd1710b9d440e → packageMentionDocs.

Which tree this was computed on

This run read content/docs from 491493b45069b9ae845b2634d29a8e876933a643 — the merge of head ba771e706b8ae3a001a7b4b6f56db7fc747fefed into base 2cc4610304c58c3de05a36efbb7cd1710b9d440e, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin 491493b45069b9ae845b2634d29a8e876933a643 && git checkout 491493b45069b9ae845b2634d29a8e876933a643
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 2cc4610304c58c3de05a36efbb7cd1710b9d440e ba771e706b8ae3a001a7b4b6f56db7fc747fefed && git checkout -B drift-repro 2cc4610304c58c3de05a36efbb7cd1710b9d440e && git merge --no-ff ba771e706b8ae3a001a7b4b6f56db7fc747fefed
node scripts/docs-audit/affected-docs.mjs --json 2cc4610304c58c3de05a36efbb7cd1710b9d440e

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

[os-musk]

PM: Check Changeset resolved, and the one remaining action is not mine to take

The red gate, read rather than guessed.Check Changeset was failure (run 100890560827). Its own job log names exactly two routes: apply skip-changeset if the PR releases nothing, otherwise run pnpm changeset and name the packages — and states that an empty-frontmatter changeset is not a third option.

Route taken: skip-changeset. This PR modifies.changeset/repo-execute-elevated-context.md; it does not add one. The release it corrects is already declared on main by #15051, and this PR adds no package bump of its own — it changes what that release's note says, not what it releases. Adding a second changeset would declare a release that does not exist.

Label write — read-modify-write with compare read-back, per protocol:

• before: documentation, size/s, tooling
• written: the same three plus skip-changeset
• read back live: documentation, size/s, tooling, skip-changeset — matches the union exactly, nothing stripped by a concurrent writer.

The label event re-fired the workflow: new Check Changeset run 100892547790 → skipped (02:43:32Z). The earlier failure run remains visible in the check-run list as a superseded run; the latest run per check name is what branch protection reads.

One claim in this PR independently re-verified, not taken from the report. The only non-prose edit here is the shifted census anchor. Reading packages/objectql/src/engine.ts at head ba771e706 line 14523: get isSystem() { return this.executionContext.isSystem; } — the ScopedContext.isSystem getter, exactly what the table row claims. The --fix re-derivation is correct. (Note for the record: the PR body's prose says the docstring shifted later lines "by 26"; the actual shift is 27, 14496 → 14523. The anchor written to the doc is right; only the prose describing the offset is off by one.)

State now: 35 of 37 check runs green or skipped; Test Core (1/6) and Lint & Repo Gates still in progress at the time of writing. Not governed (check-governed-merges.mjs --test → 0 of 3 paths). Clause-② no — prose only: no new exported symbol, no new key on a published payload.

⛔ What this seat cannot do, stated plainly rather than left as silence. The PR is still a draft. GitHub exposes draft→ready only as the GraphQL mutation markPullRequestReadyForReview; REST PATCH on a pull request has no draft field, and the MCP update tool performs a GraphQL lookup before its REST write. This account's GraphQL quota is exhausted right now (REST calls continue to succeed — the split is REST vs GraphQL, not read vs write), so the flip is structurally unavailable from here, not merely worth retrying. Enabling auto-merge is blocked by the same two facts: it is a GraphQL mutation, and it refuses a draft PR regardless.

So one human action remains — mark this PR ready for review. After that the ordinary queue path applies; no other gate is outstanding. Flagging it here rather than reporting the PR as landed, because it is not.

---

Generated by Claude Code

[os-musk]

Superseded: the handoff above is no longer needed

The previous comment ended by asking a human to mark this PR ready for review, because the GraphQL bucket was exhausted and markPullRequestReadyForReview is the only door to that flip. The quota recovered a few minutes later and this seat did it itself — so ignore that ask; nothing is waiting on a person here.

Sequence, so the record is not just an assertion:

1. Check Changeset re-fired on the skip-changeset label event → run 100892547790, skipped.
2. All 39 check runs now read completed, zero in progress. Every conclusion is success or skipped. The one failure in the list is the superseded Check Changeset run 100890560827 from 02:33, whose successor is the skipped run above — branch protection reads the latest run per check name, and the last two stragglers went green at 02:46:59 (Test Core (1/6)) and 02:50:11 (Lint & Repo Gates).
3. Draft → ready: done.
4. Auto-merge: armed.

One caveat stated rather than dressed up as certainty. The auto-merge receipt came back in the empty form, (method: , enabled at ). That form carries no established meaning — both the filled and the empty form have preceded successful landings here, and an earlier claim in this seat's notes that the empty form meant "already queued" was measured false and withdrawn. There is a reliable positive reading (a merge_group workflow run on a gh-readonly-queue/main/pr-15131-… branch) but no cheap negative one, so arming is not proof of landing. At the time of writing this PR had not yet appeared in the queue; five other entries were ahead of it.

That matters because of how the last one failed: #15008 sat armed for seven hours without landing, because it had gone mergeable_state: "dirty" and auto-merge does not fire on a conflicted PR and emits no event. If this PR is still open some hours from now, that is the first thing to check — absence of an event is not evidence of progress.

---

Generated by Claude Code