fix(runtime): tell an action handler when its caller-scope record load was refused

[claude]

Closes#14143

An action handler could not tell "the caller cannot read this row" from "this action legitimately has no record". This PR gives it a signal that can, additively, and writes it into the action-authoring docs — half the defect was that none of it was written down.

⛔ Not an exploitation claim. No exploitability work was done and none is claimed. This is a predicate defect: the platform's most natural authorization predicate for an action handler was structurally always-true. The isSystem: true elevation is settled design (#3914) and is untouched.

The mechanism, re-derived on the current tree

Anchors were taken by triage on 20b79bea; re-derived here on 66ecc50a and they have not drifted — packages/runtime/src/action-execution.ts still carries :1117 (the elevation), :1282/:1283 (the caller-scope load), :1284 (the swallow), :1285 (the comment) and :1288 (the stamp) at those exact lines.

:1282constgot: any=awaitcallData('get',{object: objectName,id: recordId},driver,envId,ec);
:1283if(got?.record)record=got.record;
:1284}catch{
:1285/* new-record / record-less actions pass an empty record */
:1288if(record&&(recordasany).id==null&&recordId)(recordasany).id=recordId;

A refused or empty load leaves record as {}, so record.id is exactly null — which is the stamp's own condition. The stamp condition and the load-failure condition coincide. The body then runs elevated, so authorization has to be re-established inside the handler, and:

if(!ctx.record?.id)returnrefuse();// always false — never refused anything

⛔ The stamp is not deleted. Record-less / new-record actions legitimately depend on it, and that dependency is pinned in this PR in both directions.

Measured first: can the caught error already tell refusal from absence?

No — and the collapse is deliberate, not an oversight. Traced end to end:

• callData('get', ...) prefers protocol.getData, which calls engine.findOne under the caller's context and, when nothing comes back, throws recordNotFoundError (packages/metadata-protocol/src/protocol.ts);
• its ObjectQL fallback throws the identical error, imported from the same producer for exactly that reason (packages/core/src/utils/record-not-found.ts: code: 'RECORD_NOT_FOUND', status: 404);
• so a row filtered out by row-level security and an id that names nothing arrive at :1284 as the same error object shape. The call site's own comment already says it: "engages the same permission path as get_record — an unseen record reads as not-found". That is existence non-disclosure working as designed.

⇒ The repair is not smaller than the card assumed, and it deliberately is not an inspection of the caught error: there is nothing there to inspect. It is a separate channel. Consequences for the design, both taken:

• the flag reports "the row did not resolve for this caller", not "the platform caught an authorization error";
• it carries no code and no status, so nobody is invited to branch on a distinction the read path fuses. For an authorization decision the two are one answer: this caller has not demonstrated read access to that row.

What was built — direction 1 (additive), as ruled

ctx.recordLoadDenied — true exactly when a caller-scope load was attempted and did not deliver the row; absent, never false, otherwise. Same absence semantics as the referentialFieldClear marker already on this seam, so a handler reads ctx.recordLoadDenied === true.

if(ctx.recordLoadDenied){throwObject.assign(newError('Record not available'),{code: 'RECORD_NOT_FOUND'});}

Nothing that reaches a handler today stops reaching it. No existing key changes value. Direction 2 (pre-dispatch refusal) was not taken and no published accept set is narrowed.

Files, and why each one is required rather than scope creep

File	Why
packages/runtime/src/action-execution.ts	The card's named site. New loadActionSubjectRecord — one producer for the load and its verdict — plus the signal on the MCP run_action context.
packages/runtime/src/domains/actions.ts	The REST /actions door carries the identical defect, byte-for-byte: git grep for the stamp returns exactly two hits, this one and the above. A documented guard that only one of two doors sets is an authorization guard silently inert on the other — the same defect one door over. Converted to call the same producer; no other behaviour changed.
packages/runtime/src/sandbox/script-runner.ts, body-runner.ts, quickjs-runner.ts	The sandbox ctx is a fixed key set — a key the dispatcher sets but the sandbox never marshals reads as undefined inside every inline body. Without these three edits the documented guard would be false on the surface an AI author writes most. Declared on ScriptContext, projected in buildActionSandboxContext, installed true-only in installCtx — the exact shape referentialFieldClear already uses two lines above.
content/docs/ui/actions.mdx, content/docs/automation/hook-bodies.mdx	Binding requirement of the dispatch order, and the reporter's actual complaint. New "Authorization inside an action" section with the wrong guard, the right guard, and a three-row table; cross-referenced from the trusted-elevation callout and from the action-ctx paragraph in the hook-bodies reference.
packages/runtime/src/action-record-load-denied.test.ts, .changeset/action-record-load-denied-signal.md	Verification and release note.

packages/spec is not in the diff — the Clause ② path limb does not fire (the engine contract types executeAction's ctx as any, and no ActionContext schema exists in spec).

Verification

Everything below was run on 603d1236, this branch's head — the tree was clean and unchanged from that commit for the whole measurement.

Whole affected package, green:

pnpm --filter @objectstack/runtime test
Test Files 206 passed (206) Tests 3053 passed (3053)

Tests — packages/runtime/src/action-record-load-denied.test.ts, 13 cases. The engine double is row-scoped on the one point that matters: find honours options.context.userId, so the row is returned to its owner and is invisible to anyone else — which is how row-level security actually manifests to callData('get', ...). The MCP leg is wired to the realcallData, so the real recordNotFoundError is what the dispatcher catches; nothing about the refused/absent collapse is mocked away.

pnpm --filter @objectstack/runtime exec vitest run --maxWorkers=2 \
src/action-record-load-denied.test.ts src/action-ctx-user-shape.test.ts \
src/action-body-identity.test.ts src/http-dispatcher.actions-global-key.test.ts \
src/action-execution-calldata-not-found.test.ts
Test Files 5 passed (5) Tests 89 passed (89)

Both directions pinned, on both doors:

• a caller who cannot read the row reaches the handler with recordLoadDenied === true — and ctx.record.id is still there, which is the prohibited regression, asserted rather than assumed;
• the row owner reaches the handler with the real row and the key absent ('recordLoadDenied' in ctx === false);
• an object-less action invoked with a recordId attempts no load and still gets the stamp;
• a new-record invocation (no recordId) attempts no load, gets no flag, and no subject-row read is issued at all.

Every absence assertion has a firing positive control on the same rig: the identical expectation shape reports true for the unauthorized caller.

Reverse verification — three ablations, each on the committed tree, each proving the mutation landed on disk by occurrence counts (not by an editor's exit code) and each restoring under a trap whose success is proven by comparing git hash-object against the HEAD blob:

Ablation	Result
actionRecordLoadSignal returns {} (kills the signal at both doors)	3 failed / 10 passed — both door tests and the producer test red; every stamp-regression and body test stayed green
the recordLoadDenied projection removed from buildActionSandboxContext	1 failed / 12 passed — only the body-face test
vm.setProp(ctxObj, 'recordLoadDenied', ...) removed from installCtx	1 failed / 12 passed — only the body-face test

No rebuild is needed for these: the test imports its subjects by relative specifier (./action-execution.js, ./sandbox/body-runner.js), which vite resolves to packages/runtime/src/*.ts — the package's dist is never on the path, and packages/runtime/vitest.config.ts declares no alias that touches a relative import.

Typecheck — pnpm --filter @objectstack/runtime typecheck green, and measured rather than assumed: tsc --listFiles reports 5 of 5 edited source files inside that program. That config excludes **/*.test.ts, so the new test file was type-checked separately against the same compiler options with the exclusion lifted — also green.

Gates run locally (the farm runs in CI; these are the ones this diff implicates): check:nul-bytes · check:doc-anchors (295 fragment links resolve, including the two added here) · check:docs-single-h1 · check-system-context-census (109 elevation read sites, all anchored — this gate reads both edited dispatcher files by exact path) · check:route-envelope · check:doc-authoring · check:cross-package-test-inputs · check:test-source-alias · check-doc-frontmatter · check-doc-route-spelling · check-docs-section-name · check-keyed-text-bounds · check-comment-mask-adoption · check-undeclared-dep-imports · check:type-source-resolution · check:objectql-double-limit · check:where-matcher · check-empty-changeset · check-adr-0087-registration · check-changeset-no-major · check:changeset-gate-self-tests · check:objectui-changeset · check:docs-audit-scope · check:corpus-claim-drift · check:doc-security-posture · check:role-word · docs-audit/check-affected-docs · pm/check-half-states · check:published-files · check-ci-filter-parity — all green.

check-test-completeness exits 3 (PREREQUISITE NOT MET) with no argument: it grades a saved turbo run test log that only CI produces. Recorded as NOT MEASURED, per that script's own instruction.

Stop conditions checked

• Only direction 2 works? No. Direction 1 is viable and is what shipped. No fork.
• Does the repair reach The by-id write pre-image gate resolves the row under the caller's own read scope, so an app-authored widener is still dead on private even once checkAuthoredRowWrite admits it #7401's site? No. That card is the write-by-id pre-image door in packages/metadata-protocol; this diff does not touch that package. Same pattern (a row resolved in the caller's scope), opposite direction, different site.
• Has another open PR claimed action-execution.ts? No. Checked at dispatch and again before pushing: none of the 9 open PRs touches action-execution.ts, domains/actions.ts, sandbox/, or content/docs/ui/actions.mdx.
• packages/spec in the diff? No.

Out of scope, filed rather than fixed

The flow branch of the same two doors hands the same stamped record stub to AutomationContext, and the flow face has no counterpart signal. It is a narrower and conditional claim (a flow action is not system-elevated by default — the flow engine honours runAs, ADR-0049), and ruling it is a design question this card does not own. Filed unassigned as #14244.

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/runtime, touching 10 documentable anchor(s).

1 hand-written doc(s) NAME something this change touched and may need an implementation-accuracy re-verification:

• content/docs/automation/hook-bodies.mdx(via ScriptContext (symbol, a top-level interface))

What this run could not see

• the SDK route bridge reached 47 of 219 client-bound route-ledger rows — the other 172 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 172: 14 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 56 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 102 are undecided (no in-repo declaration, on a ledger that has other in-repo registrars — absence and an unreadable spelling are not distinguishable here). The rows themselves: node scripts/docs-audit/affected-docs.mjs --bridge-coverage
• 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 — 23 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 b360cc7d5ca2e9cdb60a12018af20cbc3470cafa → packageMentionDocs.

Which tree this was computed on

This run read content/docs from ea206df91049f4659826d26335bbe91463109f9c — the merge of head 603d12366c73f04ba6b38174be6e9a8b18291786 into base b360cc7d5ca2e9cdb60a12018af20cbc3470cafa, 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 ea206df91049f4659826d26335bbe91463109f9c && git checkout ea206df91049f4659826d26335bbe91463109f9c
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin b360cc7d5ca2e9cdb60a12018af20cbc3470cafa 603d12366c73f04ba6b38174be6e9a8b18291786 && git checkout -B drift-repro b360cc7d5ca2e9cdb60a12018af20cbc3470cafa && git merge --no-ff 603d12366c73f04ba6b38174be6e9a8b18291786
node scripts/docs-audit/affected-docs.mjs --json b360cc7d5ca2e9cdb60a12018af20cbc3470cafa

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

Advisory only, and a precision-first one (#9192): a page is listed because it names a
symbol, wire route or SDK method this diff touched — not because it mentions a changed
package. Each row says which anchor put it there, so a wrong row is reportable rather than
merely annoying. To re-verify, run the docs-accuracy-audit workflow scoped to these files:
node scripts/docs-audit/affected-docs.mjs b360cc7d5ca2e9cdb60a12018af20cbc3470cafa → pass the list as
args.docs, on the commit named under Which tree this was computed on.

[claude]

Closes#14143

An action handler could not tell "the caller cannot read this row" from "this action legitimately has no record". This PR gives it a signal that can, additively, and writes it into the action-authoring docs — half the defect was that none of it was written down.

⛔ Not an exploitation claim. No exploitability work was done and none is claimed. This is a predicate defect: the platform's most natural authorization predicate for an action handler was structurally always-true. The isSystem: true elevation is settled design (#3914) and is untouched.

The mechanism, re-derived on the current tree

Anchors were taken by triage on 20b79bea; re-derived here on 66ecc50a and they have not drifted — packages/runtime/src/action-execution.ts still carries :1117 (the elevation), :1282/:1283 (the caller-scope load), :1284 (the swallow), :1285 (the comment) and :1288 (the stamp) at those exact lines.

:1282constgot: any=awaitcallData('get',{object: objectName,id: recordId},driver,envId,ec);
:1283if(got?.record)record=got.record;
:1284}catch{
:1285/* new-record / record-less actions pass an empty record */
:1288if(record&&(recordasany).id==null&&recordId)(recordasany).id=recordId;

A refused or empty load leaves record as {}, so record.id is exactly null — which is the stamp's own condition. The stamp condition and the load-failure condition coincide. The body then runs elevated, so authorization has to be re-established inside the handler, and:

if(!ctx.record?.id)returnrefuse();// always false — never refused anything

⛔ The stamp is not deleted. Record-less / new-record actions legitimately depend on it, and that dependency is pinned in this PR in both directions.

Measured first: can the caught error already tell refusal from absence?

No — and the collapse is deliberate, not an oversight. Traced end to end:

• callData('get', ...) prefers protocol.getData, which calls engine.findOne under the caller's context and, when nothing comes back, throws recordNotFoundError (packages/metadata-protocol/src/protocol.ts);
• its ObjectQL fallback throws the identical error, imported from the same producer for exactly that reason (packages/core/src/utils/record-not-found.ts: code: 'RECORD_NOT_FOUND', status: 404);
• so a row filtered out by row-level security and an id that names nothing arrive at :1284 as the same error object shape. The call site's own comment already says it: "engages the same permission path as get_record — an unseen record reads as not-found". That is existence non-disclosure working as designed.

⇒ The repair is not smaller than the card assumed, and it deliberately is not an inspection of the caught error: there is nothing there to inspect. It is a separate channel. Consequences for the design, both taken:

• the flag reports "the row did not resolve for this caller", not "the platform caught an authorization error";
• it carries no code and no status, so nobody is invited to branch on a distinction the read path fuses. For an authorization decision the two are one answer: this caller has not demonstrated read access to that row.

What was built — direction 1 (additive), as ruled

ctx.recordLoadDenied — true exactly when a caller-scope load was attempted and did not deliver the row; absent, never false, otherwise. Same absence semantics as the referentialFieldClear marker already on this seam, so a handler reads ctx.recordLoadDenied === true.

if(ctx.recordLoadDenied){throwObject.assign(newError('Record not available'),{code: 'RECORD_NOT_FOUND'});}

Nothing that reaches a handler today stops reaching it. No existing key changes value. Direction 2 (pre-dispatch refusal) was not taken and no published accept set is narrowed.

Files, and why each one is required rather than scope creep

File	Why
packages/runtime/src/action-execution.ts	The card's named site. New loadActionSubjectRecord — one producer for the load and its verdict — plus the signal on the MCP run_action context.
packages/runtime/src/domains/actions.ts	The REST /actions door carries the identical defect, byte-for-byte: git grep for the stamp returns exactly two hits, this one and the above. A documented guard that only one of two doors sets is an authorization guard silently inert on the other — the same defect one door over. Converted to call the same producer; no other behaviour changed.
packages/runtime/src/sandbox/script-runner.ts, body-runner.ts, quickjs-runner.ts	The sandbox ctx is a fixed key set — a key the dispatcher sets but the sandbox never marshals reads as undefined inside every inline body. Without these three edits the documented guard would be false on the surface an AI author writes most. Declared on ScriptContext, projected in buildActionSandboxContext, installed true-only in installCtx — the exact shape referentialFieldClear already uses two lines above.
content/docs/ui/actions.mdx, content/docs/automation/hook-bodies.mdx	Binding requirement of the dispatch order, and the reporter's actual complaint. New "Authorization inside an action" section with the wrong guard, the right guard, and a three-row table; cross-referenced from the trusted-elevation callout and from the action-ctx paragraph in the hook-bodies reference.
packages/runtime/src/action-record-load-denied.test.ts, .changeset/action-record-load-denied-signal.md	Verification and release note.

packages/spec is not in the diff — the Clause ② path limb does not fire (the engine contract types executeAction's ctx as any, and no ActionContext schema exists in spec).

Verification

Everything below was run on 603d1236, this branch's head — the tree was clean and unchanged from that commit for the whole measurement.

Whole affected package, green:

pnpm --filter @objectstack/runtime test
Test Files 206 passed (206) Tests 3053 passed (3053)

Tests — packages/runtime/src/action-record-load-denied.test.ts, 13 cases. The engine double is row-scoped on the one point that matters: find honours options.context.userId, so the row is returned to its owner and is invisible to anyone else — which is how row-level security actually manifests to callData('get', ...). The MCP leg is wired to the realcallData, so the real recordNotFoundError is what the dispatcher catches; nothing about the refused/absent collapse is mocked away.

pnpm --filter @objectstack/runtime exec vitest run --maxWorkers=2 \
src/action-record-load-denied.test.ts src/action-ctx-user-shape.test.ts \
src/action-body-identity.test.ts src/http-dispatcher.actions-global-key.test.ts \
src/action-execution-calldata-not-found.test.ts
Test Files 5 passed (5) Tests 89 passed (89)

Both directions pinned, on both doors:

• a caller who cannot read the row reaches the handler with recordLoadDenied === true — and ctx.record.id is still there, which is the prohibited regression, asserted rather than assumed;
• the row owner reaches the handler with the real row and the key absent ('recordLoadDenied' in ctx === false);
• an object-less action invoked with a recordId attempts no load and still gets the stamp;
• a new-record invocation (no recordId) attempts no load, gets no flag, and no subject-row read is issued at all.

Every absence assertion has a firing positive control on the same rig: the identical expectation shape reports true for the unauthorized caller.

Reverse verification — three ablations, each on the committed tree, each proving the mutation landed on disk by occurrence counts (not by an editor's exit code) and each restoring under a trap whose success is proven by comparing git hash-object against the HEAD blob:

Ablation	Result
actionRecordLoadSignal returns {} (kills the signal at both doors)	3 failed / 10 passed — both door tests and the producer test red; every stamp-regression and body test stayed green
the recordLoadDenied projection removed from buildActionSandboxContext	1 failed / 12 passed — only the body-face test
vm.setProp(ctxObj, 'recordLoadDenied', ...) removed from installCtx	1 failed / 12 passed — only the body-face test

No rebuild is needed for these: the test imports its subjects by relative specifier (./action-execution.js, ./sandbox/body-runner.js), which vite resolves to packages/runtime/src/*.ts — the package's dist is never on the path, and packages/runtime/vitest.config.ts declares no alias that touches a relative import.

Typecheck — pnpm --filter @objectstack/runtime typecheck green, and measured rather than assumed: tsc --listFiles reports 5 of 5 edited source files inside that program. That config excludes **/*.test.ts, so the new test file was type-checked separately against the same compiler options with the exclusion lifted — also green.

Gates run locally (the farm runs in CI; these are the ones this diff implicates): check:nul-bytes · check:doc-anchors (295 fragment links resolve, including the two added here) · check:docs-single-h1 · check-system-context-census (109 elevation read sites, all anchored — this gate reads both edited dispatcher files by exact path) · check:route-envelope · check:doc-authoring · check:cross-package-test-inputs · check:test-source-alias · check-doc-frontmatter · check-doc-route-spelling · check-docs-section-name · check-keyed-text-bounds · check-comment-mask-adoption · check-undeclared-dep-imports · check:type-source-resolution · check:objectql-double-limit · check:where-matcher · check-empty-changeset · check-adr-0087-registration · check-changeset-no-major · check:changeset-gate-self-tests · check:objectui-changeset · check:docs-audit-scope · check:corpus-claim-drift · check:doc-security-posture · check:role-word · docs-audit/check-affected-docs · pm/check-half-states · check:published-files · check-ci-filter-parity — all green.

check-test-completeness exits 3 (PREREQUISITE NOT MET) with no argument: it grades a saved turbo run test log that only CI produces. Recorded as NOT MEASURED, per that script's own instruction.

Stop conditions checked

• Only direction 2 works? No. Direction 1 is viable and is what shipped. No fork.
• Does the repair reach The by-id write pre-image gate resolves the row under the caller's own read scope, so an app-authored widener is still dead on private even once checkAuthoredRowWrite admits it #7401's site? No. That card is the write-by-id pre-image door in packages/metadata-protocol; this diff does not touch that package. Same pattern (a row resolved in the caller's scope), opposite direction, different site.
• Has another open PR claimed action-execution.ts? No. Checked at dispatch and again before pushing: none of the 9 open PRs touches action-execution.ts, domains/actions.ts, sandbox/, or content/docs/ui/actions.mdx.
• packages/spec in the diff? No.

Out of scope, filed rather than fixed

The flow branch of the same two doors hands the same stamped record stub to AutomationContext, and the flow face has no counterpart signal. It is a narrower and conditional claim (a flow action is not system-elevated by default — the flow engine honours runAs, ADR-0049), and ruling it is a design question this card does not own. Filed unassigned as #14244.

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/runtime, touching 10 documentable anchor(s).

1 hand-written doc(s) NAME something this change touched and may need an implementation-accuracy re-verification:

• content/docs/automation/hook-bodies.mdx(via ScriptContext (symbol, a top-level interface))

What this run could not see

• the SDK route bridge reached 47 of 219 client-bound route-ledger rows — the other 172 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 172: 14 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 56 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 102 are undecided (no in-repo declaration, on a ledger that has other in-repo registrars — absence and an unreadable spelling are not distinguishable here). The rows themselves: node scripts/docs-audit/affected-docs.mjs --bridge-coverage
• 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 — 23 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 b360cc7d5ca2e9cdb60a12018af20cbc3470cafa → packageMentionDocs.

Which tree this was computed on

This run read content/docs from ea206df91049f4659826d26335bbe91463109f9c — the merge of head 603d12366c73f04ba6b38174be6e9a8b18291786 into base b360cc7d5ca2e9cdb60a12018af20cbc3470cafa, 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 ea206df91049f4659826d26335bbe91463109f9c && git checkout ea206df91049f4659826d26335bbe91463109f9c
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin b360cc7d5ca2e9cdb60a12018af20cbc3470cafa 603d12366c73f04ba6b38174be6e9a8b18291786 && git checkout -B drift-repro b360cc7d5ca2e9cdb60a12018af20cbc3470cafa && git merge --no-ff 603d12366c73f04ba6b38174be6e9a8b18291786
node scripts/docs-audit/affected-docs.mjs --json b360cc7d5ca2e9cdb60a12018af20cbc3470cafa

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

Advisory only, and a precision-first one (#9192): a page is listed because it names a
symbol, wire route or SDK method this diff touched — not because it mentions a changed
package. Each row says which anchor put it there, so a wrong row is reportable rather than
merely annoying. To re-verify, run the docs-accuracy-audit workflow scoped to these files:
node scripts/docs-audit/affected-docs.mjs b360cc7d5ca2e9cdb60a12018af20cbc3470cafa → pass the list as
args.docs, on the commit named under Which tree this was computed on.

[claude]

Closes#14143

An action handler could not tell "the caller cannot read this row" from "this action legitimately has no record". This PR gives it a signal that can, additively, and writes it into the action-authoring docs — half the defect was that none of it was written down.

⛔ Not an exploitation claim. No exploitability work was done and none is claimed. This is a predicate defect: the platform's most natural authorization predicate for an action handler was structurally always-true. The isSystem: true elevation is settled design (#3914) and is untouched.

The mechanism, re-derived on the current tree

Anchors were taken by triage on 20b79bea; re-derived here on 66ecc50a and they have not drifted — packages/runtime/src/action-execution.ts still carries :1117 (the elevation), :1282/:1283 (the caller-scope load), :1284 (the swallow), :1285 (the comment) and :1288 (the stamp) at those exact lines.

:1282constgot: any=awaitcallData('get',{object: objectName,id: recordId},driver,envId,ec);
:1283if(got?.record)record=got.record;
:1284}catch{
:1285/* new-record / record-less actions pass an empty record */
:1288if(record&&(recordasany).id==null&&recordId)(recordasany).id=recordId;

A refused or empty load leaves record as {}, so record.id is exactly null — which is the stamp's own condition. The stamp condition and the load-failure condition coincide. The body then runs elevated, so authorization has to be re-established inside the handler, and:

if(!ctx.record?.id)returnrefuse();// always false — never refused anything

⛔ The stamp is not deleted. Record-less / new-record actions legitimately depend on it, and that dependency is pinned in this PR in both directions.

Measured first: can the caught error already tell refusal from absence?

No — and the collapse is deliberate, not an oversight. Traced end to end:

• callData('get', ...) prefers protocol.getData, which calls engine.findOne under the caller's context and, when nothing comes back, throws recordNotFoundError (packages/metadata-protocol/src/protocol.ts);
• its ObjectQL fallback throws the identical error, imported from the same producer for exactly that reason (packages/core/src/utils/record-not-found.ts: code: 'RECORD_NOT_FOUND', status: 404);
• so a row filtered out by row-level security and an id that names nothing arrive at :1284 as the same error object shape. The call site's own comment already says it: "engages the same permission path as get_record — an unseen record reads as not-found". That is existence non-disclosure working as designed.

⇒ The repair is not smaller than the card assumed, and it deliberately is not an inspection of the caught error: there is nothing there to inspect. It is a separate channel. Consequences for the design, both taken:

• the flag reports "the row did not resolve for this caller", not "the platform caught an authorization error";
• it carries no code and no status, so nobody is invited to branch on a distinction the read path fuses. For an authorization decision the two are one answer: this caller has not demonstrated read access to that row.

What was built — direction 1 (additive), as ruled

ctx.recordLoadDenied — true exactly when a caller-scope load was attempted and did not deliver the row; absent, never false, otherwise. Same absence semantics as the referentialFieldClear marker already on this seam, so a handler reads ctx.recordLoadDenied === true.

if(ctx.recordLoadDenied){throwObject.assign(newError('Record not available'),{code: 'RECORD_NOT_FOUND'});}

Nothing that reaches a handler today stops reaching it. No existing key changes value. Direction 2 (pre-dispatch refusal) was not taken and no published accept set is narrowed.

Files, and why each one is required rather than scope creep

File	Why
packages/runtime/src/action-execution.ts	The card's named site. New loadActionSubjectRecord — one producer for the load and its verdict — plus the signal on the MCP run_action context.
packages/runtime/src/domains/actions.ts	The REST /actions door carries the identical defect, byte-for-byte: git grep for the stamp returns exactly two hits, this one and the above. A documented guard that only one of two doors sets is an authorization guard silently inert on the other — the same defect one door over. Converted to call the same producer; no other behaviour changed.
packages/runtime/src/sandbox/script-runner.ts, body-runner.ts, quickjs-runner.ts	The sandbox ctx is a fixed key set — a key the dispatcher sets but the sandbox never marshals reads as undefined inside every inline body. Without these three edits the documented guard would be false on the surface an AI author writes most. Declared on ScriptContext, projected in buildActionSandboxContext, installed true-only in installCtx — the exact shape referentialFieldClear already uses two lines above.
content/docs/ui/actions.mdx, content/docs/automation/hook-bodies.mdx	Binding requirement of the dispatch order, and the reporter's actual complaint. New "Authorization inside an action" section with the wrong guard, the right guard, and a three-row table; cross-referenced from the trusted-elevation callout and from the action-ctx paragraph in the hook-bodies reference.
packages/runtime/src/action-record-load-denied.test.ts, .changeset/action-record-load-denied-signal.md	Verification and release note.

packages/spec is not in the diff — the Clause ② path limb does not fire (the engine contract types executeAction's ctx as any, and no ActionContext schema exists in spec).

Verification

Everything below was run on 603d1236, this branch's head — the tree was clean and unchanged from that commit for the whole measurement.

Whole affected package, green:

pnpm --filter @objectstack/runtime test
Test Files 206 passed (206) Tests 3053 passed (3053)

Tests — packages/runtime/src/action-record-load-denied.test.ts, 13 cases. The engine double is row-scoped on the one point that matters: find honours options.context.userId, so the row is returned to its owner and is invisible to anyone else — which is how row-level security actually manifests to callData('get', ...). The MCP leg is wired to the realcallData, so the real recordNotFoundError is what the dispatcher catches; nothing about the refused/absent collapse is mocked away.

pnpm --filter @objectstack/runtime exec vitest run --maxWorkers=2 \
src/action-record-load-denied.test.ts src/action-ctx-user-shape.test.ts \
src/action-body-identity.test.ts src/http-dispatcher.actions-global-key.test.ts \
src/action-execution-calldata-not-found.test.ts
Test Files 5 passed (5) Tests 89 passed (89)

Both directions pinned, on both doors:

• a caller who cannot read the row reaches the handler with recordLoadDenied === true — and ctx.record.id is still there, which is the prohibited regression, asserted rather than assumed;
• the row owner reaches the handler with the real row and the key absent ('recordLoadDenied' in ctx === false);
• an object-less action invoked with a recordId attempts no load and still gets the stamp;
• a new-record invocation (no recordId) attempts no load, gets no flag, and no subject-row read is issued at all.

Every absence assertion has a firing positive control on the same rig: the identical expectation shape reports true for the unauthorized caller.

Reverse verification — three ablations, each on the committed tree, each proving the mutation landed on disk by occurrence counts (not by an editor's exit code) and each restoring under a trap whose success is proven by comparing git hash-object against the HEAD blob:

Ablation	Result
actionRecordLoadSignal returns {} (kills the signal at both doors)	3 failed / 10 passed — both door tests and the producer test red; every stamp-regression and body test stayed green
the recordLoadDenied projection removed from buildActionSandboxContext	1 failed / 12 passed — only the body-face test
vm.setProp(ctxObj, 'recordLoadDenied', ...) removed from installCtx	1 failed / 12 passed — only the body-face test

No rebuild is needed for these: the test imports its subjects by relative specifier (./action-execution.js, ./sandbox/body-runner.js), which vite resolves to packages/runtime/src/*.ts — the package's dist is never on the path, and packages/runtime/vitest.config.ts declares no alias that touches a relative import.

Typecheck — pnpm --filter @objectstack/runtime typecheck green, and measured rather than assumed: tsc --listFiles reports 5 of 5 edited source files inside that program. That config excludes **/*.test.ts, so the new test file was type-checked separately against the same compiler options with the exclusion lifted — also green.

Gates run locally (the farm runs in CI; these are the ones this diff implicates): check:nul-bytes · check:doc-anchors (295 fragment links resolve, including the two added here) · check:docs-single-h1 · check-system-context-census (109 elevation read sites, all anchored — this gate reads both edited dispatcher files by exact path) · check:route-envelope · check:doc-authoring · check:cross-package-test-inputs · check:test-source-alias · check-doc-frontmatter · check-doc-route-spelling · check-docs-section-name · check-keyed-text-bounds · check-comment-mask-adoption · check-undeclared-dep-imports · check:type-source-resolution · check:objectql-double-limit · check:where-matcher · check-empty-changeset · check-adr-0087-registration · check-changeset-no-major · check:changeset-gate-self-tests · check:objectui-changeset · check:docs-audit-scope · check:corpus-claim-drift · check:doc-security-posture · check:role-word · docs-audit/check-affected-docs · pm/check-half-states · check:published-files · check-ci-filter-parity — all green.

check-test-completeness exits 3 (PREREQUISITE NOT MET) with no argument: it grades a saved turbo run test log that only CI produces. Recorded as NOT MEASURED, per that script's own instruction.

Stop conditions checked

• Only direction 2 works? No. Direction 1 is viable and is what shipped. No fork.
• Does the repair reach The by-id write pre-image gate resolves the row under the caller's own read scope, so an app-authored widener is still dead on private even once checkAuthoredRowWrite admits it #7401's site? No. That card is the write-by-id pre-image door in packages/metadata-protocol; this diff does not touch that package. Same pattern (a row resolved in the caller's scope), opposite direction, different site.
• Has another open PR claimed action-execution.ts? No. Checked at dispatch and again before pushing: none of the 9 open PRs touches action-execution.ts, domains/actions.ts, sandbox/, or content/docs/ui/actions.mdx.
• packages/spec in the diff? No.

Out of scope, filed rather than fixed

The flow branch of the same two doors hands the same stamped record stub to AutomationContext, and the flow face has no counterpart signal. It is a narrower and conditional claim (a flow action is not system-elevated by default — the flow engine honours runAs, ADR-0049), and ruling it is a design question this card does not own. Filed unassigned as #14244.

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/runtime, touching 10 documentable anchor(s).

1 hand-written doc(s) NAME something this change touched and may need an implementation-accuracy re-verification:

• content/docs/automation/hook-bodies.mdx(via ScriptContext (symbol, a top-level interface))

What this run could not see

• the SDK route bridge reached 47 of 219 client-bound route-ledger rows — the other 172 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 172: 14 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 56 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 102 are undecided (no in-repo declaration, on a ledger that has other in-repo registrars — absence and an unreadable spelling are not distinguishable here). The rows themselves: node scripts/docs-audit/affected-docs.mjs --bridge-coverage
• 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 — 23 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 b360cc7d5ca2e9cdb60a12018af20cbc3470cafa → packageMentionDocs.

Which tree this was computed on

This run read content/docs from ea206df91049f4659826d26335bbe91463109f9c — the merge of head 603d12366c73f04ba6b38174be6e9a8b18291786 into base b360cc7d5ca2e9cdb60a12018af20cbc3470cafa, 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 ea206df91049f4659826d26335bbe91463109f9c && git checkout ea206df91049f4659826d26335bbe91463109f9c
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin b360cc7d5ca2e9cdb60a12018af20cbc3470cafa 603d12366c73f04ba6b38174be6e9a8b18291786 && git checkout -B drift-repro b360cc7d5ca2e9cdb60a12018af20cbc3470cafa && git merge --no-ff 603d12366c73f04ba6b38174be6e9a8b18291786
node scripts/docs-audit/affected-docs.mjs --json b360cc7d5ca2e9cdb60a12018af20cbc3470cafa

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

Advisory only, and a precision-first one (#9192): a page is listed because it names a
symbol, wire route or SDK method this diff touched — not because it mentions a changed
package. Each row says which anchor put it there, so a wrong row is reportable rather than
merely annoying. To re-verify, run the docs-accuracy-audit workflow scoped to these files:
node scripts/docs-audit/affected-docs.mjs b360cc7d5ca2e9cdb60a12018af20cbc3470cafa → pass the list as
args.docs, on the commit named under Which tree this was computed on.

[claude]

Closes#14143

An action handler could not tell "the caller cannot read this row" from "this action legitimately has no record". This PR gives it a signal that can, additively, and writes it into the action-authoring docs — half the defect was that none of it was written down.

⛔ Not an exploitation claim. No exploitability work was done and none is claimed. This is a predicate defect: the platform's most natural authorization predicate for an action handler was structurally always-true. The isSystem: true elevation is settled design (#3914) and is untouched.

The mechanism, re-derived on the current tree

Anchors were taken by triage on 20b79bea; re-derived here on 66ecc50a and they have not drifted — packages/runtime/src/action-execution.ts still carries :1117 (the elevation), :1282/:1283 (the caller-scope load), :1284 (the swallow), :1285 (the comment) and :1288 (the stamp) at those exact lines.

:1282constgot: any=awaitcallData('get',{object: objectName,id: recordId},driver,envId,ec);
:1283if(got?.record)record=got.record;
:1284}catch{
:1285/* new-record / record-less actions pass an empty record */
:1288if(record&&(recordasany).id==null&&recordId)(recordasany).id=recordId;

A refused or empty load leaves record as {}, so record.id is exactly null — which is the stamp's own condition. The stamp condition and the load-failure condition coincide. The body then runs elevated, so authorization has to be re-established inside the handler, and:

if(!ctx.record?.id)returnrefuse();// always false — never refused anything

⛔ The stamp is not deleted. Record-less / new-record actions legitimately depend on it, and that dependency is pinned in this PR in both directions.

Measured first: can the caught error already tell refusal from absence?

No — and the collapse is deliberate, not an oversight. Traced end to end:

• callData('get', ...) prefers protocol.getData, which calls engine.findOne under the caller's context and, when nothing comes back, throws recordNotFoundError (packages/metadata-protocol/src/protocol.ts);
• its ObjectQL fallback throws the identical error, imported from the same producer for exactly that reason (packages/core/src/utils/record-not-found.ts: code: 'RECORD_NOT_FOUND', status: 404);
• so a row filtered out by row-level security and an id that names nothing arrive at :1284 as the same error object shape. The call site's own comment already says it: "engages the same permission path as get_record — an unseen record reads as not-found". That is existence non-disclosure working as designed.

⇒ The repair is not smaller than the card assumed, and it deliberately is not an inspection of the caught error: there is nothing there to inspect. It is a separate channel. Consequences for the design, both taken:

• the flag reports "the row did not resolve for this caller", not "the platform caught an authorization error";
• it carries no code and no status, so nobody is invited to branch on a distinction the read path fuses. For an authorization decision the two are one answer: this caller has not demonstrated read access to that row.

What was built — direction 1 (additive), as ruled

ctx.recordLoadDenied — true exactly when a caller-scope load was attempted and did not deliver the row; absent, never false, otherwise. Same absence semantics as the referentialFieldClear marker already on this seam, so a handler reads ctx.recordLoadDenied === true.

if(ctx.recordLoadDenied){throwObject.assign(newError('Record not available'),{code: 'RECORD_NOT_FOUND'});}

Nothing that reaches a handler today stops reaching it. No existing key changes value. Direction 2 (pre-dispatch refusal) was not taken and no published accept set is narrowed.

Files, and why each one is required rather than scope creep

File	Why
packages/runtime/src/action-execution.ts	The card's named site. New loadActionSubjectRecord — one producer for the load and its verdict — plus the signal on the MCP run_action context.
packages/runtime/src/domains/actions.ts	The REST /actions door carries the identical defect, byte-for-byte: git grep for the stamp returns exactly two hits, this one and the above. A documented guard that only one of two doors sets is an authorization guard silently inert on the other — the same defect one door over. Converted to call the same producer; no other behaviour changed.
packages/runtime/src/sandbox/script-runner.ts, body-runner.ts, quickjs-runner.ts	The sandbox ctx is a fixed key set — a key the dispatcher sets but the sandbox never marshals reads as undefined inside every inline body. Without these three edits the documented guard would be false on the surface an AI author writes most. Declared on ScriptContext, projected in buildActionSandboxContext, installed true-only in installCtx — the exact shape referentialFieldClear already uses two lines above.
content/docs/ui/actions.mdx, content/docs/automation/hook-bodies.mdx	Binding requirement of the dispatch order, and the reporter's actual complaint. New "Authorization inside an action" section with the wrong guard, the right guard, and a three-row table; cross-referenced from the trusted-elevation callout and from the action-ctx paragraph in the hook-bodies reference.
packages/runtime/src/action-record-load-denied.test.ts, .changeset/action-record-load-denied-signal.md	Verification and release note.

packages/spec is not in the diff — the Clause ② path limb does not fire (the engine contract types executeAction's ctx as any, and no ActionContext schema exists in spec).

Verification

Everything below was run on 603d1236, this branch's head — the tree was clean and unchanged from that commit for the whole measurement.

Whole affected package, green:

pnpm --filter @objectstack/runtime test
Test Files 206 passed (206) Tests 3053 passed (3053)

Tests — packages/runtime/src/action-record-load-denied.test.ts, 13 cases. The engine double is row-scoped on the one point that matters: find honours options.context.userId, so the row is returned to its owner and is invisible to anyone else — which is how row-level security actually manifests to callData('get', ...). The MCP leg is wired to the realcallData, so the real recordNotFoundError is what the dispatcher catches; nothing about the refused/absent collapse is mocked away.

pnpm --filter @objectstack/runtime exec vitest run --maxWorkers=2 \
src/action-record-load-denied.test.ts src/action-ctx-user-shape.test.ts \
src/action-body-identity.test.ts src/http-dispatcher.actions-global-key.test.ts \
src/action-execution-calldata-not-found.test.ts
Test Files 5 passed (5) Tests 89 passed (89)

Both directions pinned, on both doors:

• a caller who cannot read the row reaches the handler with recordLoadDenied === true — and ctx.record.id is still there, which is the prohibited regression, asserted rather than assumed;
• the row owner reaches the handler with the real row and the key absent ('recordLoadDenied' in ctx === false);
• an object-less action invoked with a recordId attempts no load and still gets the stamp;
• a new-record invocation (no recordId) attempts no load, gets no flag, and no subject-row read is issued at all.

Every absence assertion has a firing positive control on the same rig: the identical expectation shape reports true for the unauthorized caller.

Reverse verification — three ablations, each on the committed tree, each proving the mutation landed on disk by occurrence counts (not by an editor's exit code) and each restoring under a trap whose success is proven by comparing git hash-object against the HEAD blob:

Ablation	Result
actionRecordLoadSignal returns {} (kills the signal at both doors)	3 failed / 10 passed — both door tests and the producer test red; every stamp-regression and body test stayed green
the recordLoadDenied projection removed from buildActionSandboxContext	1 failed / 12 passed — only the body-face test
vm.setProp(ctxObj, 'recordLoadDenied', ...) removed from installCtx	1 failed / 12 passed — only the body-face test

No rebuild is needed for these: the test imports its subjects by relative specifier (./action-execution.js, ./sandbox/body-runner.js), which vite resolves to packages/runtime/src/*.ts — the package's dist is never on the path, and packages/runtime/vitest.config.ts declares no alias that touches a relative import.

Typecheck — pnpm --filter @objectstack/runtime typecheck green, and measured rather than assumed: tsc --listFiles reports 5 of 5 edited source files inside that program. That config excludes **/*.test.ts, so the new test file was type-checked separately against the same compiler options with the exclusion lifted — also green.

Gates run locally (the farm runs in CI; these are the ones this diff implicates): check:nul-bytes · check:doc-anchors (295 fragment links resolve, including the two added here) · check:docs-single-h1 · check-system-context-census (109 elevation read sites, all anchored — this gate reads both edited dispatcher files by exact path) · check:route-envelope · check:doc-authoring · check:cross-package-test-inputs · check:test-source-alias · check-doc-frontmatter · check-doc-route-spelling · check-docs-section-name · check-keyed-text-bounds · check-comment-mask-adoption · check-undeclared-dep-imports · check:type-source-resolution · check:objectql-double-limit · check:where-matcher · check-empty-changeset · check-adr-0087-registration · check-changeset-no-major · check:changeset-gate-self-tests · check:objectui-changeset · check:docs-audit-scope · check:corpus-claim-drift · check:doc-security-posture · check:role-word · docs-audit/check-affected-docs · pm/check-half-states · check:published-files · check-ci-filter-parity — all green.

check-test-completeness exits 3 (PREREQUISITE NOT MET) with no argument: it grades a saved turbo run test log that only CI produces. Recorded as NOT MEASURED, per that script's own instruction.

Stop conditions checked

• Only direction 2 works? No. Direction 1 is viable and is what shipped. No fork.
• Does the repair reach The by-id write pre-image gate resolves the row under the caller's own read scope, so an app-authored widener is still dead on private even once checkAuthoredRowWrite admits it #7401's site? No. That card is the write-by-id pre-image door in packages/metadata-protocol; this diff does not touch that package. Same pattern (a row resolved in the caller's scope), opposite direction, different site.
• Has another open PR claimed action-execution.ts? No. Checked at dispatch and again before pushing: none of the 9 open PRs touches action-execution.ts, domains/actions.ts, sandbox/, or content/docs/ui/actions.mdx.
• packages/spec in the diff? No.

Out of scope, filed rather than fixed

The flow branch of the same two doors hands the same stamped record stub to AutomationContext, and the flow face has no counterpart signal. It is a narrower and conditional claim (a flow action is not system-elevated by default — the flow engine honours runAs, ADR-0049), and ruling it is a design question this card does not own. Filed unassigned as #14244.

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/runtime, touching 10 documentable anchor(s).

1 hand-written doc(s) NAME something this change touched and may need an implementation-accuracy re-verification:

• content/docs/automation/hook-bodies.mdx(via ScriptContext (symbol, a top-level interface))

What this run could not see

• the SDK route bridge reached 47 of 219 client-bound route-ledger rows — the other 172 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 172: 14 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 56 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 102 are undecided (no in-repo declaration, on a ledger that has other in-repo registrars — absence and an unreadable spelling are not distinguishable here). The rows themselves: node scripts/docs-audit/affected-docs.mjs --bridge-coverage
• 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 — 23 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 b360cc7d5ca2e9cdb60a12018af20cbc3470cafa → packageMentionDocs.

Which tree this was computed on

This run read content/docs from ea206df91049f4659826d26335bbe91463109f9c — the merge of head 603d12366c73f04ba6b38174be6e9a8b18291786 into base b360cc7d5ca2e9cdb60a12018af20cbc3470cafa, 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 ea206df91049f4659826d26335bbe91463109f9c && git checkout ea206df91049f4659826d26335bbe91463109f9c
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin b360cc7d5ca2e9cdb60a12018af20cbc3470cafa 603d12366c73f04ba6b38174be6e9a8b18291786 && git checkout -B drift-repro b360cc7d5ca2e9cdb60a12018af20cbc3470cafa && git merge --no-ff 603d12366c73f04ba6b38174be6e9a8b18291786
node scripts/docs-audit/affected-docs.mjs --json b360cc7d5ca2e9cdb60a12018af20cbc3470cafa

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

Advisory only, and a precision-first one (#9192): a page is listed because it names a
symbol, wire route or SDK method this diff touched — not because it mentions a changed
package. Each row says which anchor put it there, so a wrong row is reportable rather than
merely annoying. To re-verify, run the docs-accuracy-audit workflow scoped to these files:
node scripts/docs-audit/affected-docs.mjs b360cc7d5ca2e9cdb60a12018af20cbc3470cafa → pass the list as
args.docs, on the commit named under Which tree this was computed on.

[claude]

Closes#14143

An action handler could not tell "the caller cannot read this row" from "this action legitimately has no record". This PR gives it a signal that can, additively, and writes it into the action-authoring docs — half the defect was that none of it was written down.

⛔ Not an exploitation claim. No exploitability work was done and none is claimed. This is a predicate defect: the platform's most natural authorization predicate for an action handler was structurally always-true. The isSystem: true elevation is settled design (#3914) and is untouched.

The mechanism, re-derived on the current tree

Anchors were taken by triage on 20b79bea; re-derived here on 66ecc50a and they have not drifted — packages/runtime/src/action-execution.ts still carries :1117 (the elevation), :1282/:1283 (the caller-scope load), :1284 (the swallow), :1285 (the comment) and :1288 (the stamp) at those exact lines.

:1282constgot: any=awaitcallData('get',{object: objectName,id: recordId},driver,envId,ec);
:1283if(got?.record)record=got.record;
:1284}catch{
:1285/* new-record / record-less actions pass an empty record */
:1288if(record&&(recordasany).id==null&&recordId)(recordasany).id=recordId;

A refused or empty load leaves record as {}, so record.id is exactly null — which is the stamp's own condition. The stamp condition and the load-failure condition coincide. The body then runs elevated, so authorization has to be re-established inside the handler, and:

if(!ctx.record?.id)returnrefuse();// always false — never refused anything

⛔ The stamp is not deleted. Record-less / new-record actions legitimately depend on it, and that dependency is pinned in this PR in both directions.

Measured first: can the caught error already tell refusal from absence?

No — and the collapse is deliberate, not an oversight. Traced end to end:

• callData('get', ...) prefers protocol.getData, which calls engine.findOne under the caller's context and, when nothing comes back, throws recordNotFoundError (packages/metadata-protocol/src/protocol.ts);
• its ObjectQL fallback throws the identical error, imported from the same producer for exactly that reason (packages/core/src/utils/record-not-found.ts: code: 'RECORD_NOT_FOUND', status: 404);
• so a row filtered out by row-level security and an id that names nothing arrive at :1284 as the same error object shape. The call site's own comment already says it: "engages the same permission path as get_record — an unseen record reads as not-found". That is existence non-disclosure working as designed.

⇒ The repair is not smaller than the card assumed, and it deliberately is not an inspection of the caught error: there is nothing there to inspect. It is a separate channel. Consequences for the design, both taken:

• the flag reports "the row did not resolve for this caller", not "the platform caught an authorization error";
• it carries no code and no status, so nobody is invited to branch on a distinction the read path fuses. For an authorization decision the two are one answer: this caller has not demonstrated read access to that row.

What was built — direction 1 (additive), as ruled

ctx.recordLoadDenied — true exactly when a caller-scope load was attempted and did not deliver the row; absent, never false, otherwise. Same absence semantics as the referentialFieldClear marker already on this seam, so a handler reads ctx.recordLoadDenied === true.

if(ctx.recordLoadDenied){throwObject.assign(newError('Record not available'),{code: 'RECORD_NOT_FOUND'});}

Nothing that reaches a handler today stops reaching it. No existing key changes value. Direction 2 (pre-dispatch refusal) was not taken and no published accept set is narrowed.

Files, and why each one is required rather than scope creep

File	Why
packages/runtime/src/action-execution.ts	The card's named site. New loadActionSubjectRecord — one producer for the load and its verdict — plus the signal on the MCP run_action context.
packages/runtime/src/domains/actions.ts	The REST /actions door carries the identical defect, byte-for-byte: git grep for the stamp returns exactly two hits, this one and the above. A documented guard that only one of two doors sets is an authorization guard silently inert on the other — the same defect one door over. Converted to call the same producer; no other behaviour changed.
packages/runtime/src/sandbox/script-runner.ts, body-runner.ts, quickjs-runner.ts	The sandbox ctx is a fixed key set — a key the dispatcher sets but the sandbox never marshals reads as undefined inside every inline body. Without these three edits the documented guard would be false on the surface an AI author writes most. Declared on ScriptContext, projected in buildActionSandboxContext, installed true-only in installCtx — the exact shape referentialFieldClear already uses two lines above.
content/docs/ui/actions.mdx, content/docs/automation/hook-bodies.mdx	Binding requirement of the dispatch order, and the reporter's actual complaint. New "Authorization inside an action" section with the wrong guard, the right guard, and a three-row table; cross-referenced from the trusted-elevation callout and from the action-ctx paragraph in the hook-bodies reference.
packages/runtime/src/action-record-load-denied.test.ts, .changeset/action-record-load-denied-signal.md	Verification and release note.

packages/spec is not in the diff — the Clause ② path limb does not fire (the engine contract types executeAction's ctx as any, and no ActionContext schema exists in spec).

Verification

Everything below was run on 603d1236, this branch's head — the tree was clean and unchanged from that commit for the whole measurement.

Whole affected package, green:

pnpm --filter @objectstack/runtime test
Test Files 206 passed (206) Tests 3053 passed (3053)

Tests — packages/runtime/src/action-record-load-denied.test.ts, 13 cases. The engine double is row-scoped on the one point that matters: find honours options.context.userId, so the row is returned to its owner and is invisible to anyone else — which is how row-level security actually manifests to callData('get', ...). The MCP leg is wired to the realcallData, so the real recordNotFoundError is what the dispatcher catches; nothing about the refused/absent collapse is mocked away.

pnpm --filter @objectstack/runtime exec vitest run --maxWorkers=2 \
src/action-record-load-denied.test.ts src/action-ctx-user-shape.test.ts \
src/action-body-identity.test.ts src/http-dispatcher.actions-global-key.test.ts \
src/action-execution-calldata-not-found.test.ts
Test Files 5 passed (5) Tests 89 passed (89)

Both directions pinned, on both doors:

• a caller who cannot read the row reaches the handler with recordLoadDenied === true — and ctx.record.id is still there, which is the prohibited regression, asserted rather than assumed;
• the row owner reaches the handler with the real row and the key absent ('recordLoadDenied' in ctx === false);
• an object-less action invoked with a recordId attempts no load and still gets the stamp;
• a new-record invocation (no recordId) attempts no load, gets no flag, and no subject-row read is issued at all.

Every absence assertion has a firing positive control on the same rig: the identical expectation shape reports true for the unauthorized caller.

Reverse verification — three ablations, each on the committed tree, each proving the mutation landed on disk by occurrence counts (not by an editor's exit code) and each restoring under a trap whose success is proven by comparing git hash-object against the HEAD blob:

Ablation	Result
actionRecordLoadSignal returns {} (kills the signal at both doors)	3 failed / 10 passed — both door tests and the producer test red; every stamp-regression and body test stayed green
the recordLoadDenied projection removed from buildActionSandboxContext	1 failed / 12 passed — only the body-face test
vm.setProp(ctxObj, 'recordLoadDenied', ...) removed from installCtx	1 failed / 12 passed — only the body-face test

No rebuild is needed for these: the test imports its subjects by relative specifier (./action-execution.js, ./sandbox/body-runner.js), which vite resolves to packages/runtime/src/*.ts — the package's dist is never on the path, and packages/runtime/vitest.config.ts declares no alias that touches a relative import.

Typecheck — pnpm --filter @objectstack/runtime typecheck green, and measured rather than assumed: tsc --listFiles reports 5 of 5 edited source files inside that program. That config excludes **/*.test.ts, so the new test file was type-checked separately against the same compiler options with the exclusion lifted — also green.

Gates run locally (the farm runs in CI; these are the ones this diff implicates): check:nul-bytes · check:doc-anchors (295 fragment links resolve, including the two added here) · check:docs-single-h1 · check-system-context-census (109 elevation read sites, all anchored — this gate reads both edited dispatcher files by exact path) · check:route-envelope · check:doc-authoring · check:cross-package-test-inputs · check:test-source-alias · check-doc-frontmatter · check-doc-route-spelling · check-docs-section-name · check-keyed-text-bounds · check-comment-mask-adoption · check-undeclared-dep-imports · check:type-source-resolution · check:objectql-double-limit · check:where-matcher · check-empty-changeset · check-adr-0087-registration · check-changeset-no-major · check:changeset-gate-self-tests · check:objectui-changeset · check:docs-audit-scope · check:corpus-claim-drift · check:doc-security-posture · check:role-word · docs-audit/check-affected-docs · pm/check-half-states · check:published-files · check-ci-filter-parity — all green.

check-test-completeness exits 3 (PREREQUISITE NOT MET) with no argument: it grades a saved turbo run test log that only CI produces. Recorded as NOT MEASURED, per that script's own instruction.

Stop conditions checked

• Only direction 2 works? No. Direction 1 is viable and is what shipped. No fork.
• Does the repair reach The by-id write pre-image gate resolves the row under the caller's own read scope, so an app-authored widener is still dead on private even once checkAuthoredRowWrite admits it #7401's site? No. That card is the write-by-id pre-image door in packages/metadata-protocol; this diff does not touch that package. Same pattern (a row resolved in the caller's scope), opposite direction, different site.
• Has another open PR claimed action-execution.ts? No. Checked at dispatch and again before pushing: none of the 9 open PRs touches action-execution.ts, domains/actions.ts, sandbox/, or content/docs/ui/actions.mdx.
• packages/spec in the diff? No.

Out of scope, filed rather than fixed

The flow branch of the same two doors hands the same stamped record stub to AutomationContext, and the flow face has no counterpart signal. It is a narrower and conditional claim (a flow action is not system-elevated by default — the flow engine honours runAs, ADR-0049), and ruling it is a design question this card does not own. Filed unassigned as #14244.

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/runtime, touching 10 documentable anchor(s).

1 hand-written doc(s) NAME something this change touched and may need an implementation-accuracy re-verification:

• content/docs/automation/hook-bodies.mdx(via ScriptContext (symbol, a top-level interface))

What this run could not see

• the SDK route bridge reached 47 of 219 client-bound route-ledger rows — the other 172 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 172: 14 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 56 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 102 are undecided (no in-repo declaration, on a ledger that has other in-repo registrars — absence and an unreadable spelling are not distinguishable here). The rows themselves: node scripts/docs-audit/affected-docs.mjs --bridge-coverage
• 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 — 23 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 b360cc7d5ca2e9cdb60a12018af20cbc3470cafa → packageMentionDocs.

Which tree this was computed on

This run read content/docs from ea206df91049f4659826d26335bbe91463109f9c — the merge of head 603d12366c73f04ba6b38174be6e9a8b18291786 into base b360cc7d5ca2e9cdb60a12018af20cbc3470cafa, 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 ea206df91049f4659826d26335bbe91463109f9c && git checkout ea206df91049f4659826d26335bbe91463109f9c
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin b360cc7d5ca2e9cdb60a12018af20cbc3470cafa 603d12366c73f04ba6b38174be6e9a8b18291786 && git checkout -B drift-repro b360cc7d5ca2e9cdb60a12018af20cbc3470cafa && git merge --no-ff 603d12366c73f04ba6b38174be6e9a8b18291786
node scripts/docs-audit/affected-docs.mjs --json b360cc7d5ca2e9cdb60a12018af20cbc3470cafa

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

Advisory only, and a precision-first one (#9192): a page is listed because it names a
symbol, wire route or SDK method this diff touched — not because it mentions a changed
package. Each row says which anchor put it there, so a wrong row is reportable rather than
merely annoying. To re-verify, run the docs-accuracy-audit workflow scoped to these files:
node scripts/docs-audit/affected-docs.mjs b360cc7d5ca2e9cdb60a12018af20cbc3470cafa → pass the list as
args.docs, on the commit named under Which tree this was computed on.

[claude]

Closes#14143

An action handler could not tell "the caller cannot read this row" from "this action legitimately has no record". This PR gives it a signal that can, additively, and writes it into the action-authoring docs — half the defect was that none of it was written down.

⛔ Not an exploitation claim. No exploitability work was done and none is claimed. This is a predicate defect: the platform's most natural authorization predicate for an action handler was structurally always-true. The isSystem: true elevation is settled design (#3914) and is untouched.

The mechanism, re-derived on the current tree

Anchors were taken by triage on 20b79bea; re-derived here on 66ecc50a and they have not drifted — packages/runtime/src/action-execution.ts still carries :1117 (the elevation), :1282/:1283 (the caller-scope load), :1284 (the swallow), :1285 (the comment) and :1288 (the stamp) at those exact lines.

:1282constgot: any=awaitcallData('get',{object: objectName,id: recordId},driver,envId,ec);
:1283if(got?.record)record=got.record;
:1284}catch{
:1285/* new-record / record-less actions pass an empty record */
:1288if(record&&(recordasany).id==null&&recordId)(recordasany).id=recordId;

A refused or empty load leaves record as {}, so record.id is exactly null — which is the stamp's own condition. The stamp condition and the load-failure condition coincide. The body then runs elevated, so authorization has to be re-established inside the handler, and:

if(!ctx.record?.id)returnrefuse();// always false — never refused anything

⛔ The stamp is not deleted. Record-less / new-record actions legitimately depend on it, and that dependency is pinned in this PR in both directions.

Measured first: can the caught error already tell refusal from absence?

No — and the collapse is deliberate, not an oversight. Traced end to end:

• callData('get', ...) prefers protocol.getData, which calls engine.findOne under the caller's context and, when nothing comes back, throws recordNotFoundError (packages/metadata-protocol/src/protocol.ts);
• its ObjectQL fallback throws the identical error, imported from the same producer for exactly that reason (packages/core/src/utils/record-not-found.ts: code: 'RECORD_NOT_FOUND', status: 404);
• so a row filtered out by row-level security and an id that names nothing arrive at :1284 as the same error object shape. The call site's own comment already says it: "engages the same permission path as get_record — an unseen record reads as not-found". That is existence non-disclosure working as designed.

⇒ The repair is not smaller than the card assumed, and it deliberately is not an inspection of the caught error: there is nothing there to inspect. It is a separate channel. Consequences for the design, both taken:

• the flag reports "the row did not resolve for this caller", not "the platform caught an authorization error";
• it carries no code and no status, so nobody is invited to branch on a distinction the read path fuses. For an authorization decision the two are one answer: this caller has not demonstrated read access to that row.

What was built — direction 1 (additive), as ruled

ctx.recordLoadDenied — true exactly when a caller-scope load was attempted and did not deliver the row; absent, never false, otherwise. Same absence semantics as the referentialFieldClear marker already on this seam, so a handler reads ctx.recordLoadDenied === true.

if(ctx.recordLoadDenied){throwObject.assign(newError('Record not available'),{code: 'RECORD_NOT_FOUND'});}

Nothing that reaches a handler today stops reaching it. No existing key changes value. Direction 2 (pre-dispatch refusal) was not taken and no published accept set is narrowed.

Files, and why each one is required rather than scope creep

File	Why
packages/runtime/src/action-execution.ts	The card's named site. New loadActionSubjectRecord — one producer for the load and its verdict — plus the signal on the MCP run_action context.
packages/runtime/src/domains/actions.ts	The REST /actions door carries the identical defect, byte-for-byte: git grep for the stamp returns exactly two hits, this one and the above. A documented guard that only one of two doors sets is an authorization guard silently inert on the other — the same defect one door over. Converted to call the same producer; no other behaviour changed.
packages/runtime/src/sandbox/script-runner.ts, body-runner.ts, quickjs-runner.ts	The sandbox ctx is a fixed key set — a key the dispatcher sets but the sandbox never marshals reads as undefined inside every inline body. Without these three edits the documented guard would be false on the surface an AI author writes most. Declared on ScriptContext, projected in buildActionSandboxContext, installed true-only in installCtx — the exact shape referentialFieldClear already uses two lines above.
content/docs/ui/actions.mdx, content/docs/automation/hook-bodies.mdx	Binding requirement of the dispatch order, and the reporter's actual complaint. New "Authorization inside an action" section with the wrong guard, the right guard, and a three-row table; cross-referenced from the trusted-elevation callout and from the action-ctx paragraph in the hook-bodies reference.
packages/runtime/src/action-record-load-denied.test.ts, .changeset/action-record-load-denied-signal.md	Verification and release note.

packages/spec is not in the diff — the Clause ② path limb does not fire (the engine contract types executeAction's ctx as any, and no ActionContext schema exists in spec).

Verification

Everything below was run on 603d1236, this branch's head — the tree was clean and unchanged from that commit for the whole measurement.

Whole affected package, green:

pnpm --filter @objectstack/runtime test
Test Files 206 passed (206) Tests 3053 passed (3053)

Tests — packages/runtime/src/action-record-load-denied.test.ts, 13 cases. The engine double is row-scoped on the one point that matters: find honours options.context.userId, so the row is returned to its owner and is invisible to anyone else — which is how row-level security actually manifests to callData('get', ...). The MCP leg is wired to the realcallData, so the real recordNotFoundError is what the dispatcher catches; nothing about the refused/absent collapse is mocked away.

pnpm --filter @objectstack/runtime exec vitest run --maxWorkers=2 \
src/action-record-load-denied.test.ts src/action-ctx-user-shape.test.ts \
src/action-body-identity.test.ts src/http-dispatcher.actions-global-key.test.ts \
src/action-execution-calldata-not-found.test.ts
Test Files 5 passed (5) Tests 89 passed (89)

Both directions pinned, on both doors:

• a caller who cannot read the row reaches the handler with recordLoadDenied === true — and ctx.record.id is still there, which is the prohibited regression, asserted rather than assumed;
• the row owner reaches the handler with the real row and the key absent ('recordLoadDenied' in ctx === false);
• an object-less action invoked with a recordId attempts no load and still gets the stamp;
• a new-record invocation (no recordId) attempts no load, gets no flag, and no subject-row read is issued at all.

Every absence assertion has a firing positive control on the same rig: the identical expectation shape reports true for the unauthorized caller.

Reverse verification — three ablations, each on the committed tree, each proving the mutation landed on disk by occurrence counts (not by an editor's exit code) and each restoring under a trap whose success is proven by comparing git hash-object against the HEAD blob:

Ablation	Result
actionRecordLoadSignal returns {} (kills the signal at both doors)	3 failed / 10 passed — both door tests and the producer test red; every stamp-regression and body test stayed green
the recordLoadDenied projection removed from buildActionSandboxContext	1 failed / 12 passed — only the body-face test
vm.setProp(ctxObj, 'recordLoadDenied', ...) removed from installCtx	1 failed / 12 passed — only the body-face test

No rebuild is needed for these: the test imports its subjects by relative specifier (./action-execution.js, ./sandbox/body-runner.js), which vite resolves to packages/runtime/src/*.ts — the package's dist is never on the path, and packages/runtime/vitest.config.ts declares no alias that touches a relative import.

Typecheck — pnpm --filter @objectstack/runtime typecheck green, and measured rather than assumed: tsc --listFiles reports 5 of 5 edited source files inside that program. That config excludes **/*.test.ts, so the new test file was type-checked separately against the same compiler options with the exclusion lifted — also green.

Gates run locally (the farm runs in CI; these are the ones this diff implicates): check:nul-bytes · check:doc-anchors (295 fragment links resolve, including the two added here) · check:docs-single-h1 · check-system-context-census (109 elevation read sites, all anchored — this gate reads both edited dispatcher files by exact path) · check:route-envelope · check:doc-authoring · check:cross-package-test-inputs · check:test-source-alias · check-doc-frontmatter · check-doc-route-spelling · check-docs-section-name · check-keyed-text-bounds · check-comment-mask-adoption · check-undeclared-dep-imports · check:type-source-resolution · check:objectql-double-limit · check:where-matcher · check-empty-changeset · check-adr-0087-registration · check-changeset-no-major · check:changeset-gate-self-tests · check:objectui-changeset · check:docs-audit-scope · check:corpus-claim-drift · check:doc-security-posture · check:role-word · docs-audit/check-affected-docs · pm/check-half-states · check:published-files · check-ci-filter-parity — all green.

check-test-completeness exits 3 (PREREQUISITE NOT MET) with no argument: it grades a saved turbo run test log that only CI produces. Recorded as NOT MEASURED, per that script's own instruction.

Stop conditions checked

• Only direction 2 works? No. Direction 1 is viable and is what shipped. No fork.
• Does the repair reach The by-id write pre-image gate resolves the row under the caller's own read scope, so an app-authored widener is still dead on private even once checkAuthoredRowWrite admits it #7401's site? No. That card is the write-by-id pre-image door in packages/metadata-protocol; this diff does not touch that package. Same pattern (a row resolved in the caller's scope), opposite direction, different site.
• Has another open PR claimed action-execution.ts? No. Checked at dispatch and again before pushing: none of the 9 open PRs touches action-execution.ts, domains/actions.ts, sandbox/, or content/docs/ui/actions.mdx.
• packages/spec in the diff? No.

Out of scope, filed rather than fixed

The flow branch of the same two doors hands the same stamped record stub to AutomationContext, and the flow face has no counterpart signal. It is a narrower and conditional claim (a flow action is not system-elevated by default — the flow engine honours runAs, ADR-0049), and ruling it is a design question this card does not own. Filed unassigned as #14244.

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/runtime, touching 10 documentable anchor(s).

1 hand-written doc(s) NAME something this change touched and may need an implementation-accuracy re-verification:

• content/docs/automation/hook-bodies.mdx(via ScriptContext (symbol, a top-level interface))

What this run could not see

• the SDK route bridge reached 47 of 219 client-bound route-ledger rows — the other 172 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 172: 14 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 56 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 102 are undecided (no in-repo declaration, on a ledger that has other in-repo registrars — absence and an unreadable spelling are not distinguishable here). The rows themselves: node scripts/docs-audit/affected-docs.mjs --bridge-coverage
• 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 — 23 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 b360cc7d5ca2e9cdb60a12018af20cbc3470cafa → packageMentionDocs.

Which tree this was computed on

This run read content/docs from ea206df91049f4659826d26335bbe91463109f9c — the merge of head 603d12366c73f04ba6b38174be6e9a8b18291786 into base b360cc7d5ca2e9cdb60a12018af20cbc3470cafa, 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 ea206df91049f4659826d26335bbe91463109f9c && git checkout ea206df91049f4659826d26335bbe91463109f9c
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin b360cc7d5ca2e9cdb60a12018af20cbc3470cafa 603d12366c73f04ba6b38174be6e9a8b18291786 && git checkout -B drift-repro b360cc7d5ca2e9cdb60a12018af20cbc3470cafa && git merge --no-ff 603d12366c73f04ba6b38174be6e9a8b18291786
node scripts/docs-audit/affected-docs.mjs --json b360cc7d5ca2e9cdb60a12018af20cbc3470cafa

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

Advisory only, and a precision-first one (#9192): a page is listed because it names a
symbol, wire route or SDK method this diff touched — not because it mentions a changed
package. Each row says which anchor put it there, so a wrong row is reportable rather than
merely annoying. To re-verify, run the docs-accuracy-audit workflow scoped to these files:
node scripts/docs-audit/affected-docs.mjs b360cc7d5ca2e9cdb60a12018af20cbc3470cafa → pass the list as
args.docs, on the commit named under Which tree this was computed on.

[claude]

Closes#14143

An action handler could not tell "the caller cannot read this row" from "this action legitimately has no record". This PR gives it a signal that can, additively, and writes it into the action-authoring docs — half the defect was that none of it was written down.

⛔ Not an exploitation claim. No exploitability work was done and none is claimed. This is a predicate defect: the platform's most natural authorization predicate for an action handler was structurally always-true. The isSystem: true elevation is settled design (#3914) and is untouched.

The mechanism, re-derived on the current tree

Anchors were taken by triage on 20b79bea; re-derived here on 66ecc50a and they have not drifted — packages/runtime/src/action-execution.ts still carries :1117 (the elevation), :1282/:1283 (the caller-scope load), :1284 (the swallow), :1285 (the comment) and :1288 (the stamp) at those exact lines.

:1282constgot: any=awaitcallData('get',{object: objectName,id: recordId},driver,envId,ec);
:1283if(got?.record)record=got.record;
:1284}catch{
:1285/* new-record / record-less actions pass an empty record */
:1288if(record&&(recordasany).id==null&&recordId)(recordasany).id=recordId;

A refused or empty load leaves record as {}, so record.id is exactly null — which is the stamp's own condition. The stamp condition and the load-failure condition coincide. The body then runs elevated, so authorization has to be re-established inside the handler, and:

if(!ctx.record?.id)returnrefuse();// always false — never refused anything

⛔ The stamp is not deleted. Record-less / new-record actions legitimately depend on it, and that dependency is pinned in this PR in both directions.

Measured first: can the caught error already tell refusal from absence?

No — and the collapse is deliberate, not an oversight. Traced end to end:

• callData('get', ...) prefers protocol.getData, which calls engine.findOne under the caller's context and, when nothing comes back, throws recordNotFoundError (packages/metadata-protocol/src/protocol.ts);
• its ObjectQL fallback throws the identical error, imported from the same producer for exactly that reason (packages/core/src/utils/record-not-found.ts: code: 'RECORD_NOT_FOUND', status: 404);
• so a row filtered out by row-level security and an id that names nothing arrive at :1284 as the same error object shape. The call site's own comment already says it: "engages the same permission path as get_record — an unseen record reads as not-found". That is existence non-disclosure working as designed.

⇒ The repair is not smaller than the card assumed, and it deliberately is not an inspection of the caught error: there is nothing there to inspect. It is a separate channel. Consequences for the design, both taken:

• the flag reports "the row did not resolve for this caller", not "the platform caught an authorization error";
• it carries no code and no status, so nobody is invited to branch on a distinction the read path fuses. For an authorization decision the two are one answer: this caller has not demonstrated read access to that row.

What was built — direction 1 (additive), as ruled

ctx.recordLoadDenied — true exactly when a caller-scope load was attempted and did not deliver the row; absent, never false, otherwise. Same absence semantics as the referentialFieldClear marker already on this seam, so a handler reads ctx.recordLoadDenied === true.

if(ctx.recordLoadDenied){throwObject.assign(newError('Record not available'),{code: 'RECORD_NOT_FOUND'});}

Nothing that reaches a handler today stops reaching it. No existing key changes value. Direction 2 (pre-dispatch refusal) was not taken and no published accept set is narrowed.

Files, and why each one is required rather than scope creep

File	Why
packages/runtime/src/action-execution.ts	The card's named site. New loadActionSubjectRecord — one producer for the load and its verdict — plus the signal on the MCP run_action context.
packages/runtime/src/domains/actions.ts	The REST /actions door carries the identical defect, byte-for-byte: git grep for the stamp returns exactly two hits, this one and the above. A documented guard that only one of two doors sets is an authorization guard silently inert on the other — the same defect one door over. Converted to call the same producer; no other behaviour changed.
packages/runtime/src/sandbox/script-runner.ts, body-runner.ts, quickjs-runner.ts	The sandbox ctx is a fixed key set — a key the dispatcher sets but the sandbox never marshals reads as undefined inside every inline body. Without these three edits the documented guard would be false on the surface an AI author writes most. Declared on ScriptContext, projected in buildActionSandboxContext, installed true-only in installCtx — the exact shape referentialFieldClear already uses two lines above.
content/docs/ui/actions.mdx, content/docs/automation/hook-bodies.mdx	Binding requirement of the dispatch order, and the reporter's actual complaint. New "Authorization inside an action" section with the wrong guard, the right guard, and a three-row table; cross-referenced from the trusted-elevation callout and from the action-ctx paragraph in the hook-bodies reference.
packages/runtime/src/action-record-load-denied.test.ts, .changeset/action-record-load-denied-signal.md	Verification and release note.

packages/spec is not in the diff — the Clause ② path limb does not fire (the engine contract types executeAction's ctx as any, and no ActionContext schema exists in spec).

Verification

Everything below was run on 603d1236, this branch's head — the tree was clean and unchanged from that commit for the whole measurement.

Whole affected package, green:

pnpm --filter @objectstack/runtime test
Test Files 206 passed (206) Tests 3053 passed (3053)

Tests — packages/runtime/src/action-record-load-denied.test.ts, 13 cases. The engine double is row-scoped on the one point that matters: find honours options.context.userId, so the row is returned to its owner and is invisible to anyone else — which is how row-level security actually manifests to callData('get', ...). The MCP leg is wired to the realcallData, so the real recordNotFoundError is what the dispatcher catches; nothing about the refused/absent collapse is mocked away.

pnpm --filter @objectstack/runtime exec vitest run --maxWorkers=2 \
src/action-record-load-denied.test.ts src/action-ctx-user-shape.test.ts \
src/action-body-identity.test.ts src/http-dispatcher.actions-global-key.test.ts \
src/action-execution-calldata-not-found.test.ts
Test Files 5 passed (5) Tests 89 passed (89)

Both directions pinned, on both doors:

• a caller who cannot read the row reaches the handler with recordLoadDenied === true — and ctx.record.id is still there, which is the prohibited regression, asserted rather than assumed;
• the row owner reaches the handler with the real row and the key absent ('recordLoadDenied' in ctx === false);
• an object-less action invoked with a recordId attempts no load and still gets the stamp;
• a new-record invocation (no recordId) attempts no load, gets no flag, and no subject-row read is issued at all.

Every absence assertion has a firing positive control on the same rig: the identical expectation shape reports true for the unauthorized caller.

Reverse verification — three ablations, each on the committed tree, each proving the mutation landed on disk by occurrence counts (not by an editor's exit code) and each restoring under a trap whose success is proven by comparing git hash-object against the HEAD blob:

Ablation	Result
actionRecordLoadSignal returns {} (kills the signal at both doors)	3 failed / 10 passed — both door tests and the producer test red; every stamp-regression and body test stayed green
the recordLoadDenied projection removed from buildActionSandboxContext	1 failed / 12 passed — only the body-face test
vm.setProp(ctxObj, 'recordLoadDenied', ...) removed from installCtx	1 failed / 12 passed — only the body-face test

No rebuild is needed for these: the test imports its subjects by relative specifier (./action-execution.js, ./sandbox/body-runner.js), which vite resolves to packages/runtime/src/*.ts — the package's dist is never on the path, and packages/runtime/vitest.config.ts declares no alias that touches a relative import.

Typecheck — pnpm --filter @objectstack/runtime typecheck green, and measured rather than assumed: tsc --listFiles reports 5 of 5 edited source files inside that program. That config excludes **/*.test.ts, so the new test file was type-checked separately against the same compiler options with the exclusion lifted — also green.

Gates run locally (the farm runs in CI; these are the ones this diff implicates): check:nul-bytes · check:doc-anchors (295 fragment links resolve, including the two added here) · check:docs-single-h1 · check-system-context-census (109 elevation read sites, all anchored — this gate reads both edited dispatcher files by exact path) · check:route-envelope · check:doc-authoring · check:cross-package-test-inputs · check:test-source-alias · check-doc-frontmatter · check-doc-route-spelling · check-docs-section-name · check-keyed-text-bounds · check-comment-mask-adoption · check-undeclared-dep-imports · check:type-source-resolution · check:objectql-double-limit · check:where-matcher · check-empty-changeset · check-adr-0087-registration · check-changeset-no-major · check:changeset-gate-self-tests · check:objectui-changeset · check:docs-audit-scope · check:corpus-claim-drift · check:doc-security-posture · check:role-word · docs-audit/check-affected-docs · pm/check-half-states · check:published-files · check-ci-filter-parity — all green.

check-test-completeness exits 3 (PREREQUISITE NOT MET) with no argument: it grades a saved turbo run test log that only CI produces. Recorded as NOT MEASURED, per that script's own instruction.

Stop conditions checked

• Only direction 2 works? No. Direction 1 is viable and is what shipped. No fork.
• Does the repair reach The by-id write pre-image gate resolves the row under the caller's own read scope, so an app-authored widener is still dead on private even once checkAuthoredRowWrite admits it #7401's site? No. That card is the write-by-id pre-image door in packages/metadata-protocol; this diff does not touch that package. Same pattern (a row resolved in the caller's scope), opposite direction, different site.
• Has another open PR claimed action-execution.ts? No. Checked at dispatch and again before pushing: none of the 9 open PRs touches action-execution.ts, domains/actions.ts, sandbox/, or content/docs/ui/actions.mdx.
• packages/spec in the diff? No.

Out of scope, filed rather than fixed

The flow branch of the same two doors hands the same stamped record stub to AutomationContext, and the flow face has no counterpart signal. It is a narrower and conditional claim (a flow action is not system-elevated by default — the flow engine honours runAs, ADR-0049), and ruling it is a design question this card does not own. Filed unassigned as #14244.

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/runtime, touching 10 documentable anchor(s).

1 hand-written doc(s) NAME something this change touched and may need an implementation-accuracy re-verification:

• content/docs/automation/hook-bodies.mdx(via ScriptContext (symbol, a top-level interface))

What this run could not see

• the SDK route bridge reached 47 of 219 client-bound route-ledger rows — the other 172 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 172: 14 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 56 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 102 are undecided (no in-repo declaration, on a ledger that has other in-repo registrars — absence and an unreadable spelling are not distinguishable here). The rows themselves: node scripts/docs-audit/affected-docs.mjs --bridge-coverage
• 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 — 23 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 b360cc7d5ca2e9cdb60a12018af20cbc3470cafa → packageMentionDocs.

Which tree this was computed on

This run read content/docs from ea206df91049f4659826d26335bbe91463109f9c — the merge of head 603d12366c73f04ba6b38174be6e9a8b18291786 into base b360cc7d5ca2e9cdb60a12018af20cbc3470cafa, 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 ea206df91049f4659826d26335bbe91463109f9c && git checkout ea206df91049f4659826d26335bbe91463109f9c
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin b360cc7d5ca2e9cdb60a12018af20cbc3470cafa 603d12366c73f04ba6b38174be6e9a8b18291786 && git checkout -B drift-repro b360cc7d5ca2e9cdb60a12018af20cbc3470cafa && git merge --no-ff 603d12366c73f04ba6b38174be6e9a8b18291786
node scripts/docs-audit/affected-docs.mjs --json b360cc7d5ca2e9cdb60a12018af20cbc3470cafa

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

Advisory only, and a precision-first one (#9192): a page is listed because it names a
symbol, wire route or SDK method this diff touched — not because it mentions a changed
package. Each row says which anchor put it there, so a wrong row is reportable rather than
merely annoying. To re-verify, run the docs-accuracy-audit workflow scoped to these files:
node scripts/docs-audit/affected-docs.mjs b360cc7d5ca2e9cdb60a12018af20cbc3470cafa → pass the list as
args.docs, on the commit named under Which tree this was computed on.

[claude]

Closes#14143

An action handler could not tell "the caller cannot read this row" from "this action legitimately has no record". This PR gives it a signal that can, additively, and writes it into the action-authoring docs — half the defect was that none of it was written down.

⛔ Not an exploitation claim. No exploitability work was done and none is claimed. This is a predicate defect: the platform's most natural authorization predicate for an action handler was structurally always-true. The isSystem: true elevation is settled design (#3914) and is untouched.

The mechanism, re-derived on the current tree

Anchors were taken by triage on 20b79bea; re-derived here on 66ecc50a and they have not drifted — packages/runtime/src/action-execution.ts still carries :1117 (the elevation), :1282/:1283 (the caller-scope load), :1284 (the swallow), :1285 (the comment) and :1288 (the stamp) at those exact lines.

:1282constgot: any=awaitcallData('get',{object: objectName,id: recordId},driver,envId,ec);
:1283if(got?.record)record=got.record;
:1284}catch{
:1285/* new-record / record-less actions pass an empty record */
:1288if(record&&(recordasany).id==null&&recordId)(recordasany).id=recordId;

A refused or empty load leaves record as {}, so record.id is exactly null — which is the stamp's own condition. The stamp condition and the load-failure condition coincide. The body then runs elevated, so authorization has to be re-established inside the handler, and:

if(!ctx.record?.id)returnrefuse();// always false — never refused anything

⛔ The stamp is not deleted. Record-less / new-record actions legitimately depend on it, and that dependency is pinned in this PR in both directions.

Measured first: can the caught error already tell refusal from absence?

No — and the collapse is deliberate, not an oversight. Traced end to end:

• callData('get', ...) prefers protocol.getData, which calls engine.findOne under the caller's context and, when nothing comes back, throws recordNotFoundError (packages/metadata-protocol/src/protocol.ts);
• its ObjectQL fallback throws the identical error, imported from the same producer for exactly that reason (packages/core/src/utils/record-not-found.ts: code: 'RECORD_NOT_FOUND', status: 404);
• so a row filtered out by row-level security and an id that names nothing arrive at :1284 as the same error object shape. The call site's own comment already says it: "engages the same permission path as get_record — an unseen record reads as not-found". That is existence non-disclosure working as designed.

⇒ The repair is not smaller than the card assumed, and it deliberately is not an inspection of the caught error: there is nothing there to inspect. It is a separate channel. Consequences for the design, both taken:

• the flag reports "the row did not resolve for this caller", not "the platform caught an authorization error";
• it carries no code and no status, so nobody is invited to branch on a distinction the read path fuses. For an authorization decision the two are one answer: this caller has not demonstrated read access to that row.

What was built — direction 1 (additive), as ruled

ctx.recordLoadDenied — true exactly when a caller-scope load was attempted and did not deliver the row; absent, never false, otherwise. Same absence semantics as the referentialFieldClear marker already on this seam, so a handler reads ctx.recordLoadDenied === true.

if(ctx.recordLoadDenied){throwObject.assign(newError('Record not available'),{code: 'RECORD_NOT_FOUND'});}

Nothing that reaches a handler today stops reaching it. No existing key changes value. Direction 2 (pre-dispatch refusal) was not taken and no published accept set is narrowed.

Files, and why each one is required rather than scope creep

File	Why
packages/runtime/src/action-execution.ts	The card's named site. New loadActionSubjectRecord — one producer for the load and its verdict — plus the signal on the MCP run_action context.
packages/runtime/src/domains/actions.ts	The REST /actions door carries the identical defect, byte-for-byte: git grep for the stamp returns exactly two hits, this one and the above. A documented guard that only one of two doors sets is an authorization guard silently inert on the other — the same defect one door over. Converted to call the same producer; no other behaviour changed.
packages/runtime/src/sandbox/script-runner.ts, body-runner.ts, quickjs-runner.ts	The sandbox ctx is a fixed key set — a key the dispatcher sets but the sandbox never marshals reads as undefined inside every inline body. Without these three edits the documented guard would be false on the surface an AI author writes most. Declared on ScriptContext, projected in buildActionSandboxContext, installed true-only in installCtx — the exact shape referentialFieldClear already uses two lines above.
content/docs/ui/actions.mdx, content/docs/automation/hook-bodies.mdx	Binding requirement of the dispatch order, and the reporter's actual complaint. New "Authorization inside an action" section with the wrong guard, the right guard, and a three-row table; cross-referenced from the trusted-elevation callout and from the action-ctx paragraph in the hook-bodies reference.
packages/runtime/src/action-record-load-denied.test.ts, .changeset/action-record-load-denied-signal.md	Verification and release note.

packages/spec is not in the diff — the Clause ② path limb does not fire (the engine contract types executeAction's ctx as any, and no ActionContext schema exists in spec).

Verification

Everything below was run on 603d1236, this branch's head — the tree was clean and unchanged from that commit for the whole measurement.

Whole affected package, green:

pnpm --filter @objectstack/runtime test
Test Files 206 passed (206) Tests 3053 passed (3053)

Tests — packages/runtime/src/action-record-load-denied.test.ts, 13 cases. The engine double is row-scoped on the one point that matters: find honours options.context.userId, so the row is returned to its owner and is invisible to anyone else — which is how row-level security actually manifests to callData('get', ...). The MCP leg is wired to the realcallData, so the real recordNotFoundError is what the dispatcher catches; nothing about the refused/absent collapse is mocked away.

pnpm --filter @objectstack/runtime exec vitest run --maxWorkers=2 \
src/action-record-load-denied.test.ts src/action-ctx-user-shape.test.ts \
src/action-body-identity.test.ts src/http-dispatcher.actions-global-key.test.ts \
src/action-execution-calldata-not-found.test.ts
Test Files 5 passed (5) Tests 89 passed (89)

Both directions pinned, on both doors:

• a caller who cannot read the row reaches the handler with recordLoadDenied === true — and ctx.record.id is still there, which is the prohibited regression, asserted rather than assumed;
• the row owner reaches the handler with the real row and the key absent ('recordLoadDenied' in ctx === false);
• an object-less action invoked with a recordId attempts no load and still gets the stamp;
• a new-record invocation (no recordId) attempts no load, gets no flag, and no subject-row read is issued at all.

Every absence assertion has a firing positive control on the same rig: the identical expectation shape reports true for the unauthorized caller.

Reverse verification — three ablations, each on the committed tree, each proving the mutation landed on disk by occurrence counts (not by an editor's exit code) and each restoring under a trap whose success is proven by comparing git hash-object against the HEAD blob:

Ablation	Result
actionRecordLoadSignal returns {} (kills the signal at both doors)	3 failed / 10 passed — both door tests and the producer test red; every stamp-regression and body test stayed green
the recordLoadDenied projection removed from buildActionSandboxContext	1 failed / 12 passed — only the body-face test
vm.setProp(ctxObj, 'recordLoadDenied', ...) removed from installCtx	1 failed / 12 passed — only the body-face test

No rebuild is needed for these: the test imports its subjects by relative specifier (./action-execution.js, ./sandbox/body-runner.js), which vite resolves to packages/runtime/src/*.ts — the package's dist is never on the path, and packages/runtime/vitest.config.ts declares no alias that touches a relative import.

Typecheck — pnpm --filter @objectstack/runtime typecheck green, and measured rather than assumed: tsc --listFiles reports 5 of 5 edited source files inside that program. That config excludes **/*.test.ts, so the new test file was type-checked separately against the same compiler options with the exclusion lifted — also green.

Gates run locally (the farm runs in CI; these are the ones this diff implicates): check:nul-bytes · check:doc-anchors (295 fragment links resolve, including the two added here) · check:docs-single-h1 · check-system-context-census (109 elevation read sites, all anchored — this gate reads both edited dispatcher files by exact path) · check:route-envelope · check:doc-authoring · check:cross-package-test-inputs · check:test-source-alias · check-doc-frontmatter · check-doc-route-spelling · check-docs-section-name · check-keyed-text-bounds · check-comment-mask-adoption · check-undeclared-dep-imports · check:type-source-resolution · check:objectql-double-limit · check:where-matcher · check-empty-changeset · check-adr-0087-registration · check-changeset-no-major · check:changeset-gate-self-tests · check:objectui-changeset · check:docs-audit-scope · check:corpus-claim-drift · check:doc-security-posture · check:role-word · docs-audit/check-affected-docs · pm/check-half-states · check:published-files · check-ci-filter-parity — all green.

check-test-completeness exits 3 (PREREQUISITE NOT MET) with no argument: it grades a saved turbo run test log that only CI produces. Recorded as NOT MEASURED, per that script's own instruction.

Stop conditions checked

• Only direction 2 works? No. Direction 1 is viable and is what shipped. No fork.
• Does the repair reach The by-id write pre-image gate resolves the row under the caller's own read scope, so an app-authored widener is still dead on private even once checkAuthoredRowWrite admits it #7401's site? No. That card is the write-by-id pre-image door in packages/metadata-protocol; this diff does not touch that package. Same pattern (a row resolved in the caller's scope), opposite direction, different site.
• Has another open PR claimed action-execution.ts? No. Checked at dispatch and again before pushing: none of the 9 open PRs touches action-execution.ts, domains/actions.ts, sandbox/, or content/docs/ui/actions.mdx.
• packages/spec in the diff? No.

Out of scope, filed rather than fixed

The flow branch of the same two doors hands the same stamped record stub to AutomationContext, and the flow face has no counterpart signal. It is a narrower and conditional claim (a flow action is not system-elevated by default — the flow engine honours runAs, ADR-0049), and ruling it is a design question this card does not own. Filed unassigned as #14244.

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/runtime, touching 10 documentable anchor(s).

1 hand-written doc(s) NAME something this change touched and may need an implementation-accuracy re-verification:

• content/docs/automation/hook-bodies.mdx(via ScriptContext (symbol, a top-level interface))

What this run could not see

• the SDK route bridge reached 47 of 219 client-bound route-ledger rows — the other 172 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 172: 14 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 56 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 102 are undecided (no in-repo declaration, on a ledger that has other in-repo registrars — absence and an unreadable spelling are not distinguishable here). The rows themselves: node scripts/docs-audit/affected-docs.mjs --bridge-coverage
• 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 — 23 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 b360cc7d5ca2e9cdb60a12018af20cbc3470cafa → packageMentionDocs.

Which tree this was computed on

This run read content/docs from ea206df91049f4659826d26335bbe91463109f9c — the merge of head 603d12366c73f04ba6b38174be6e9a8b18291786 into base b360cc7d5ca2e9cdb60a12018af20cbc3470cafa, 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 ea206df91049f4659826d26335bbe91463109f9c && git checkout ea206df91049f4659826d26335bbe91463109f9c
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin b360cc7d5ca2e9cdb60a12018af20cbc3470cafa 603d12366c73f04ba6b38174be6e9a8b18291786 && git checkout -B drift-repro b360cc7d5ca2e9cdb60a12018af20cbc3470cafa && git merge --no-ff 603d12366c73f04ba6b38174be6e9a8b18291786
node scripts/docs-audit/affected-docs.mjs --json b360cc7d5ca2e9cdb60a12018af20cbc3470cafa

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

Advisory only, and a precision-first one (#9192): a page is listed because it names a
symbol, wire route or SDK method this diff touched — not because it mentions a changed
package. Each row says which anchor put it there, so a wrong row is reportable rather than
merely annoying. To re-verify, run the docs-accuracy-audit workflow scoped to these files:
node scripts/docs-audit/affected-docs.mjs b360cc7d5ca2e9cdb60a12018af20cbc3470cafa → pass the list as
args.docs, on the commit named under Which tree this was computed on.