[objectstack-fleet]

Fixes #24614

Clause-②: no (narrowing). A runAs:'user' hook fired by a user-triggered runAs:'system' flow's write now runs on that user's own grants instead of the member baseline. For a user whose grants sit below the baseline, as triage's "both directions" names, the hook's reads narrow. #24519's ruling 6271152775 item 1 declares no arm for its own producer. This seat takes the stricter, narrowing arm until the dev's measurement says whether any principal's grants can sit below the baseline. If none can, the seat re-grades and drops the arm.

What changes

resolveRunDataContext's runAs:'system' arm (packages/services/service-automation/src/runtime-identity.ts) no longer carries positions: [] / permissions: [] beside a named user. This applies ruling 6271152775 (on #24519) to this producer: a context that names a user carries no empty arrays, so the hook seed from PR #24518 resolves that user's own grants in the run's organisation.

• Named-user system run: { isSystem: true, actor, userId, tenantId?, flowRunId? }. A runAs:'user' hook one of its writes fires de-elevates to this context, finds no permissions, and resolves the user's positions, permission sets and peers through the request path's resolver.
• Post-decision system segment: after an approval decision the run's user is the decider (ruling 6267719791 Q1 A), so the hooks the post-decision writes fire now run on the decider's grants.
• Unchanged: isSystem, actor, userId and tenantId exactly as before; the run's own authority (the security middleware's isSystem bypass is its first gate, and nothing ahead of it reads the arrays); a user-less system run (a schedule) keeps positions: [] and permissions: [], and a runAs:'user' hook it fires is still refused for want of a user; the runAs:'user' arm.
• Published type: RunIdentityContext / RunDataContext declare positions and permissions optional, because the named-user system envelope no longer carries them. The changeset names it.

The engine.ts docblock on the decision segment, which leaned on "a system run's data context carries none", is rewritten to say what the hook now resolves.

Measurement (real stack)

runas-system-user-hook-grants.integration.test.ts, beside runas-user-hook-org-peers.integration.test.ts: ObjectKernel, ObjectQLPlugin, driver-sql on better-sqlite3 :memory:, the identity objects, the real SecurityPlugin and the real AutomationEngine with its CRUD nodes. A runAs:'system' flow triggered by a user writes, and a runAs:'user' hook on the written object reads.

• Above the baseline: a user holding a set the baseline does not grant. The hook now reads what the user's own request reads; under the old envelope it was refused (PERMISSION_DENIED, 403).
• Below the baseline: the direction exists and is pinned: a principal whose own grants read fewer rows than the baseline does. The hook now reads exactly what that user's own request reads. The grant detail is in the report to the seat, not here.
• Decider: a runAs:'system' flow pauses at a service-resumable gate and is resumed with a decider. The submit write's hook runs on the submitter's grants and the post-decision write's hook on the decider's.
• CONTROL, user-less: a schedule-shaped run keeps positions: [], permissions: [] and no userId, and the hook is refused with HOOK_UNSCOPED_DATA_ACCESS (403).
• CONTROL, the baseline: the old envelope fired by hand answers the baseline, the point each direction moved from.

The existing pins of the old shape moved with it: crud-runas.test.ts, the system case in runas-grant-resolution.integration.test.ts (its "resolver not consulted" proof is now no grant-table read and no authz fact filled), the two system-envelope assertions in resume-decider-identity.integration.test.ts, and the two runAs:'system' expectations in plugin-approvals' restored-approval-continuation.test.ts (the parked() helper's and the post-decision one), which now expect { userId, isSystem: true } with no permissions key.

Ablation (one run, on committed 59575b2c4)

node scripts/ablation-replace.mjs restored the empty arrays in the system arm (anchor 1 to 0, blob 4817a333 to bc398da1) and ran the new file plus crud-runas.test.ts: 5 failed, 39 passed. The three flow-driven real-stack pins went red: the below-baseline hook read the baseline's rows instead of the user's, the decider test's submit-write hook did the same, and the above-baseline pin failed on its envelope assertion (the write carried permissions). The two named-user shape pins in crud-runas.test.ts went red too. GUARD, the user-less CONTROL and the user-less unit pin stayed green, as predicted. Restored: blob back to 4817a333 (HEAD), git diff HEAD empty, git status --porcelain empty.

Tests and gates (head 0f452e832, after merging origin/main f89d29e38 with os-regen-merge.sh)

• @objectstack/service-automation: vitest run, 194 files / 2587 tests passed at 0f452e832; typecheck (tsc plus check:test-typecheck) exit 0.
• @objectstack/plugin-approvals: vitest run against this tree's built service-automation, 83 files / 1132 tests passed, 0 failed (every file loads; an earlier count of 1120 left out two mirror files that could not load before trigger-record-change was built); typecheck exit 0, its test-layer debt ledger holding.
• Other importers of the changed export, at bf00bb57c: @objectstack/trigger-record-change 114/114, @objectstack/trigger-schedule 174/174, @objectstack/verify's six system-run files 70/70.
• Derived gate families (dispatch-gates.mjs --commands on the final diff, 70 commands, check:i18n and check:i18n-stale-fill added by the plugin-approvals path): all exit 0, and --ran answered 70 derived, 70 run, 0 NOT-MEASURED, 0 UNRUN at 0f452e832.

Round 1 (seat rework record 6277856952): the claim's surface took plugin-approvals' restored-approval-continuation.test.ts for its two runAs:'system' expectations only; both now expect no permissions beside the user, and the package's suite passes in full.

Acceptance notes

• The objectql hook seed resolves positions, permission sets and peers but no email, so a row policy on current_user.email in the user's own sets drops out in such a hook until the email twin lands (code-read, not measured here); objectql: a runAs:'user' hook fired from a hand-built system context gets no email, so every current_user.email row policy hides rows its user can read (the email twin of #24497) #24639 carries it.

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/service-automation, touching 3 documentable anchor(s).

⛔ 3 release-owned page(s) name something this change touched. These are read-only:

• content/docs/releases/v16.mdx (via AutomationEngine (symbol, a top-level class))
• content/docs/releases/v17/17-0.mdx (via AutomationEngine (symbol, a top-level class))
• content/docs/releases/v17/17-6.mdx (via AutomationEngine (symbol, a top-level class))

content/docs/releases/ is RELEASE-OWNED (AGENTS.md "Documentation Guardrails"): release
notes are written centrally at release time, and a code PR that edits them is the exact PR
that guardrail exists to stop. They are still audited — read-only. If one of them is actually
wrong, file an issue or open a dedicated docs-only PR; do not edit it here.

What this run could not see

• 2 name(s) were too generic to anchor anything (single lowercase words)
• the SDK route bridge reached 54 of 206 client-bound route-ledger rows — the other 152 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 152: 0 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 55 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 97 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.
• a key NAME is not a key, so the hand re-read the line above prescribes can land on the wrong schema. The same spelling is authorable on one governed type and a [REMOVED] tombstone on another for each of active, aria, joins, objects, template, tools and version (censused on [finding] tools is a key on BOTH AgentSchema (tombstoned, dead) and SkillSchema (live, cloud-attested), so a name-based search attributes skill examples to the agent key — it produced a false stop-the-line alarm on PR #19059 #19093 over the liveness ledger's governed types, top-level keys); nothing in a search result distinguishes the two, so a grep hit on a LIVE example reads as evidence about the DEAD key. Measured on fix(spec): the agent.tools liveness row says dead — it claimed live on a key the schema tombstoned #19059: content/docs/ai/agents.mdx was reported as contradicting the agent.tools tombstone over its tools: example at :161, which is inside the defineSkill({ block opened at :155 — the page was already correct. Settle ownership by PARSING the value against both schemas, never by the name: that literal PASSES SkillSchema, and as an AgentSchema it FAILS at tools with the tombstone prescription. ⛔ These names are not the whole class — a key retired through a .strict() guidance map leaves no tombstone in the walked shape and none of them here (tool.category, live as AIToolDefinition.category).

Coarse fallback — 6 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 f89d29e382e7d50cfe1b2a98742ac1c3d436cd26 → packageMentionDocs.

Which tree this was computed on

This run read content/docs from aeedf724114461043e103fac43bcb4f24439ea43 — the merge of head 0f452e832bc477f7991713d0d21b4a0b91d4a434 into base f89d29e382e7d50cfe1b2a98742ac1c3d436cd26, 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 aeedf724114461043e103fac43bcb4f24439ea43 && git checkout aeedf724114461043e103fac43bcb4f24439ea43
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin f89d29e382e7d50cfe1b2a98742ac1c3d436cd26 0f452e832bc477f7991713d0d21b4a0b91d4a434 && git checkout -B drift-repro f89d29e382e7d50cfe1b2a98742ac1c3d436cd26 && git merge --no-ff 0f452e832bc477f7991713d0d21b4a0b91d4a434

node scripts/docs-audit/affected-docs.mjs --json f89d29e382e7d50cfe1b2a98742ac1c3d436cd26

⚠️ 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 f89d29e382e7d50cfe1b2a98742ac1c3d436cd26 → pass the list as
args.docs, on the commit named under Which tree this was computed on.

[objectstack-fleet]

REWORK · patch round 1 · domain:services seat 1 (#6021) · marchtian · session_01Nk17Z26X5DB59iQztDBADH · 2026-10-19T21:33Z · head bf00bb57c

This answers the dev's blocked report (6277772125 on #24614). The seat extends the claim's surface (6276277748) by one test file, for two assertions only:

• packages/plugins/plugin-approvals/src/restored-approval-continuation.test.ts: two assertions pin the system arm's old shape, which this PR moves. They are the parked() helper's runAs:'system' expectation, { userId: 'submitter', permissions: [], isSystem: true }, and the post-decision expectation of the runAs:'system' approve/reject it.each, { userId: 'u1', permissions: [], isSystem: true }. Both now expect { userId, isSystem: true } with no permissions key. ⛔ Nothing else in plugin-approvals changes.
• Why the claim's exclusion no longer applies: it held plugin-approvals for plugin-approvals: the hand-built contexts its writes run under don't fully carry the deciding user's context, so a runAs:'user' hook they fire gets neither the user's organisation peers nor the user's own grants (the producer half of #24497) #24519 (seat 2), and plugin-approvals: the hand-built contexts its writes run under don't fully carry the deciding user's context, so a runAs:'user' hook they fire gets neither the user's organisation peers nor the user's own grants (the producer half of #24497) #24519 has landed. No open PR touches this file (a file scan of the open PRs at this record). This is a test assertion that this PR's change makes false: the plugin-auth: seven refusals and one outage thrown from better-auth hooks carry no ADR-0112 code, the same gap #23945 closes for the invitation role cap #24243 / fix(service-storage)!: the family gate and the route judge the same credential #24388 precedent, applied to a pin.

After the edit, run plugin-approvals' suite (the dev measured 2 failed / 1118 passed on these two cases) and the derived list again on the new head (--ran: 0 NOT-MEASURED, 0 UNRUN). The seat then runs the CONTRACT_REVIEW_TIER review of record on that head, since the change is declared a narrowing.

---

Generated by Claude Code

[objectstack-fleet]

Contract review

Served-tier: CONTRACT_REVIEW_TIER
Head-sha: 0f452e832bc477f7991713d0d21b4a0b91d4a434
Local-runs: none
Scope: packages/services/service-automation/src/runtime-identity.ts, packages/services/service-automation/src/engine.ts, packages/services/service-automation/src/builtin/crud-runas.test.ts, packages/services/service-automation/src/runas-grant-resolution.integration.test.ts, packages/services/service-automation/src/resume-decider-identity.integration.test.ts, packages/services/service-automation/src/runas-system-user-hook-grants.integration.test.ts, packages/plugins/plugin-approvals/src/restored-approval-continuation.test.ts, .changeset/24614-system-run-user-grants.md + packages/objectql/src/engine.ts (ScopedContext.withRunAs, the SEED_USER_GRANTS seed, buildSession, roles), packages/objectql/src/hook-run-as.ts, packages/plugins/plugin-security/src/security-plugin.ts (the isSystem bypass, isPrincipalLessContext, getReadFilter, every collectRLSPolicies caller, stageRlsMembership), packages/plugins/plugin-security/src/rls-compiler.ts, packages/core/src/security/resolve-authz-context.ts (resolveUserAuthzGrants, grantAppliesInTenant), packages/services/service-automation/src/plugin.ts, packages/services/service-automation/src/index.ts, packages/plugins/plugin-approvals/src/approval-service.ts, packages/triggers/trigger-record-change/src/record-change-trigger.ts, packages/runtime/src/domains/automation.ts, packages/runtime/src/sandbox/body-runner.ts, packages/plugins/plugin-audit/src/comment-access-hooks.ts, packages/spec/src/data/hook.zod.ts, packages/spec/src/contracts/automation-service.ts, packages/spec/src/kernel/execution-context.zod.ts

Read at 2026-10-19T22:33Z, read-only: the net diff against merge base f89d29e38 (8 files, +410 −25), card #24614 with every comment (triage 6272519127, serial note 6272864997, claim 6276277748, dev reports 6277772125 and 6278565512), ruling 6271152775 and the analysis 6270492286 it answers, ruling 6267719791 Q1 A, the disclosure ruling 5323310017, PR #24658's body, comments (rework record 6277856952) and file list, card #24639 with its ordering note 6277888374, and the head's check-runs. Every cited file was read at this head.

① Derived judgments

1. The system arm's envelope — right. resolveRunDataContext's runAs:'system' arm now spreads positions: [] / permissions: [] only when context.userId is absent. A named-user run hands ObjectQL { isSystem: true, actor, userId, tenantId?, flowRunId? }; a user-less run (a schedule) keeps today's envelope byte for byte. The isSystem, actor, userId and tenantId lines of the arm are untouched by the diff. Pinned by key absence, not toEqual alone (crud-runas.test.ts, three cases: the named user, the named user whose trigger forwarded arrays, the user-less control).

2. No reader of a system context's arrays loses authority — right, traced. The security middleware's isSystem bypass (security-plugin.ts if (opCtx.context?.isSystem) return next()) is the first statement after the write-epoch bump, which reads no arrays; getReadFilter answers undefined on isSystem; the three capability evaluators short-circuit on isSystem before reading. Every other array read in the plugin spells ?? [] or Array.isArray (isPrincipalLessContext, the CRUD gate, every collectRLSPolicies caller, resolvePermissionSets, the explain engine), so absent reads as []; stageRlsMembership runs only on the de-elevated hook context, after the seed filled it. ObjectQL's buildSession now yields session.positions undefined where it yielded [] on such a write: HookContextSchema.session.positions is optional, and both readers guard (body-runner.ts Array.isArray; comment-access-hooks.ts callerContext prefers the operation's own system context and hands positions to helpers that ?? []). ScopedContext.roles likewise answers undefined; nothing reads .roles off an api. runUserOf guards with Array.isArray, so the flow's current_user.positions is [] as before; seedRunGrants skips runAs:'system'; stampSystemInsertOwner reads only isSystem; the runtime door forwards arrays only when non-empty. The one reader whose answer changes is the one meant to: ScopedContext[SEED_USER_GRANTS]'s needsGrants = !Array.isArray(ctx.permissions).

3. The runAs:'user' hook resolves the user's own grants — right, and the narrowing is real. withRunAs('user') copies the write context with isSystem: false; the seed finds no permissions and resolves the named user's positions, sets and peers through resolveUserAuthzGrants in the run's tenantId, the resolver the request path uses. Wider for a user holding a set the baseline does not grant (the hook now reads an object it was refused on); narrower where a held set's row policy now applies to the hook's read, which the baseline never applied. Both directions are pinned on the real stack against the user's own request as the oracle, with a GUARD that the two users differ from the baseline in opposite directions and a hand-fired baseline control. The concrete grant detail stays in the seat copy, as ruling 5323310017 requires; this record keeps the same discipline. Two edges, read and judged right: (a) a named-user system run whose trigger carried no tenantId (the record-change door forwards session.organizationId only when present, the runtime door ec.tenantId only when present) resolves the user's organisation-less envelope. grantAppliesInTenant admits only global grant rows there, there is no "every organization" mode, and Layer 0 resolves an organisation-less principal's tenant-scoped reads to nothing under group, so the hook can read at most what that user's own organisation-less request reads. The card's sentence names "a user and its organisation"; the claim's exclusion names "only when a user is named"; the diff follows the claim, and neither reading leaks beyond the user's own envelope, so this stands as a note for the seat, not a defect. (b) A forwarded ADR-0090 agent ceiling was never honoured on this arm (the old envelope replaced it with []); the record-change door forwards no arrays at all; the delegated hook path is outside this card.

4. The approvals decider path after ruling 6267719791 Q1 A — right. resolveDecisionSegmentContext deletes the trigger user's positions, permissions, peers and email, sets userId to the decider and returns before seedRunGrants on a system run; the arm then hands the post-decision writes exactly Q1 A's { isSystem: true, userId: the decider }, no permission resolution for the run, elevation unchanged. The hook a post-decision write fires resolves the decider's grants, and the submit write's hook the submitter's (the hgp_review pin). The engine.ts docblock that leaned on "a system run's data context carries none" is rewritten to say what the hook now resolves. The approvals status mirror already writes { isSystem: true, userId, tenantId? } with no arrays (PR fix(plugin-approvals): an approval's status write-back runs its automation as the person who acted, in the record's organisation #24634, merged), so the two producers of the family now obey one rule.

5. plugin-approvals — right, and nothing else moved there. Exactly the two expectations the rework record 6277856952 allowed, the parked() helper's runAs:'system' one and the post-decision one of the runAs:'system' approve/reject it.each, now read { userId, isSystem: true } with no permissions key: one file, +2 −2, the package's only path in the diff.

6. The published type — right, and declared. RunIdentityContext.positions / permissions become optional; RunDataContext is that type; both are exported from the package entry. A reader-side narrowing of a published type of @objectstack/service-automation (published, 18.0.0-next.5), named in the changeset with the consequence for a reader; TypeScript Type Check is green, so no in-repo reader relied on the required shape.

7. Unchanged, as excluded by the claim — right. The runAs:'user' arm's code is not in any hunk (the optionality lands on the shared interface, not on that arm); the user-less control keeps positions: [] / permissions: [] with no userId, and the hook it fires is still refused HOOK_UNSCOPED_DATA_ACCESS 403 (pinned); hooks declaring runAs:'system' or 'inherit' are untouched.

② Semver level

.changeset/24614-system-run-user-grants.md matches what the diff publishes: @objectstack/service-automation: minor; a ! title; Clause-②: no (narrowing) in the reader's fixed spelling; the BREAKING banner, "shipped as minor under the launch-window convention for breaking changes", the form 29 sibling changesets at this head carry; the adr-0087 not-required (no-migration-prescription) marker with its why, closing the other categories on facts; and the one-line fix for an author ("declare the hook runAs:'system'"). The PR body carries the same Clause-② line verbatim from the claim. no rather than yes is the truthful value: no export, key, option or field is added, two members may now be absent, and the type change is the written form of that shrink. plugin-approvals' change is test-only and owes no changeset. Check Changeset and Lint & Repo Gates (the adr-0087 and no-major gates) are green on this head.

③ Boundary flags

• Dev round 0 (6277772125), deviations: (1) the plugin-approvals breach not taken — answered by the rework record and landed in round 1 exactly as allowed; (2) grant detail kept off GitHub — consistent with 5323310017, the public fixture is synthetic; (3) the above-baseline ablation red came from its envelope assertion — acceptable, the below-baseline and decider pins went red on their read assertions, so the behaviour was ablated, not only the shape; (4) the full suite ran before the 7c7741dcb merge — superseded, round 1 re-ran service-automation in full on this head and Test Core 1–6 is green; (5) cli, client and connector tests not run locally — Test Core covers them; (6) the body's Clause-② line verbatim — matches the changeset. open_questions: [].
• Dev round 1 (6278565512), deviations: the 1132 vs 1120 count (two mirror files now load), the re-run of the full suite, the labeler's labels (documentation is the labeler's reading of the changeset path; no doc is edited and none is owed: the docs describe runAs:'system' as elevated with the decider as attribution user, which stays true, and the drift check listed release-owned pages only), and the body's single session-URL footer — all in order. open_questions: [].
• out_of_scope_findings (both rounds): the hook seed resolves no email, so an email-keyed row policy in the user's own sets fails closed in such a hook until objectql: a runAs:'user' hook fired from a hand-built system context gets no email, so every current_user.email row policy hides rows its user can read (the email twin of #24497) #24639 lands. objectql: a runAs:'user' hook fired from a hand-built system context gets no email, so every current_user.email row policy hides rows its user can read (the email twin of #24497) #24639 is claimed (6278068776, domain:engine, file-disjoint). The seat's ordering note 6277888374 states the window correctly in direction and consequence: the RLS compiler puts an unresolved current_user.email on the deniedBy path, the policy fails closed, nothing leaks, and the window opens when this PR lands and closes with objectql: a runAs:'user' hook fired from a hand-built system context gets no email, so every current_user.email row policy hides rows its user can read (the email twin of #24497) #24639. One imprecision, answered here: "to no rows" holds when that policy is the only one admitting rows of the object; where the user's sets admit rows by other policies, those rows still come. Not escalated.
• Claim exclusions hold on the file list: no packages/objectql/**, no packages/core/**, the runAs:'user' arm untouched, plugin-approvals held to the two assertions. Serial order held: PR fix(service-automation): a runAs:'user' flow carries its user's email, so an email-keyed row policy admits the run as it admits the user's own request #24636 (14ccb1da9), PR feat(automation)!: an approval decision resumes a flow as the person who decided #24527 (1b4078077) and PR fix(plugin-approvals): an approval's status write-back runs its automation as the person who acted, in the record's organisation #24634 for plugin-approvals: the hand-built contexts its writes run under don't fully carry the deciding user's context, so a runAs:'user' hook they fire gets neither the user's organisation peers nor the user's own grants (the producer half of #24497) #24519 (b61353ffa) merged before this head. No governed surface in the diff (Governed Surface Queue Guard green); 435 changed lines; the PR is draft with auto-merge off.
• Carried to the seat as a note, not a flag: the organisation-less edge in ① item 3(a). Tightening the arm to a named user with a tenantId would keep such a hook on the organisation-less baseline instead; both readings stay inside the user's own envelope, so the choice is the seat's, in a follow-up if at all.
• Check-runs on 0f452e832bc477f7991713d0d21b4a0b91d4a434: 47, all completed, 39 success and 8 skipped (Build Docs, Console Pin Gate, Dogfood shards, Dogfood Verify CLI, Packed-tarball smoke, Temporal Conformance), none failed. The five required contexts and Check Changeset are success.

Implemented-by: claude/issue-24614-system-run-user-grants
Reviewed-by: session_01Nk17Z26X5DB59iQztDBADH

VERDICT: PASS

---

Generated by Claude Code

[objectstack-fleet]

席位核对

ACCEPT · domain:services seat 1 (#6021) · marchtian · session_01Nk17Z26X5DB59iQztDBADH · 2026-10-19T22:35Z · head 0f452e832b.

The contract review of record is PASS 6278843703 at CONTRACT_REVIEW_TIER on this head. It covers the whole diff on the narrowing face. This seat review records the rest. The PR lands through the merge queue.

• Shape:
  • The first line is Fixes #24614, and that is the only closing keyword in the body.
  • Clause-②: no (narrowing) is at a line start in the body and in .changeset/24614-system-run-user-grants.md.
  • The changeset is @objectstack/service-automation minor, with !, the BREAKING banner, adr-0087: not-required (no-migration-prescription), and the one-line fix for an author (declare the hook runAs:'system').
  • Card and PR assignee: marchtian.
  • Not governed: check-governed-merges reads none of the 8 paths, and 435 changed lines is ≤ 3000.
• Ruling 6271152775 (plugin-approvals: the hand-built contexts its writes run under don't fully carry the deciding user's context, so a runAs:'user' hook they fire gets neither the user's organisation peers nor the user's own grants (the producer half of #24497) #24519), applied to this producer as triage 6272519127 asks, met (the review's ①.1–①.7):
  • resolveRunDataContext's runAs:'system' arm carries no empty positions / permissions beside a named user, so a runAs:'user' hook its writes fire resolves that user's own grants through PR fix(objectql): a runAs:'user' hook sees its organization's members in sys_user, as the user's own request does #24518's seed.
  • isSystem, actor, userId and tenantId are unchanged, and a user-less system run keeps today's envelope. Its hook is still refused HOOK_UNSCOPED_DATA_ACCESS.
  • Every reader of a system context's arrays was traced. Only the seed's answer changes, as intended.
  • The approvals decider path (ruling 6267719791 Q1 A) now gives a post-decision write's hook the decider's own grants. The approvals mirror (PR fix(plugin-approvals): an approval's status write-back runs its automation as the person who acted, in the record's organisation #24634) already wrote this shape, so the family's two producers follow one rule.
• The narrowing, and the premise the claim set: the dev measured on the real stack that it is real. Both directions are pinned against the user's own request as the oracle: wider for one user, and narrower where a held set's row policy now applies to the hook's read. The concrete grant detail is in the seat's copy only (skills: five principle gaps the #9296 wave exposed in checklist-test / checklist-author / dogfood-verification #9387, 5323310017). So the claim's no (narrowing) stands, and no re-grade is owed.
• Rework: round 1 (6277856952) extended the surface to two plugin-approvals test expectations that pinned the old shape, after plugin-approvals: the hand-built contexts its writes run under don't fully carry the deciding user's context, so a runAs:'user' hook they fire gets neither the user's organisation peers nor the user's own grants (the producer half of #24497) #24519 had landed. One file, +2 −2, and nothing else in that package.
• Gates on this head:
  • 32 checks succeeded and 8 were skipped by design, the roster set. No check failed, and the five required contexts are green.
  • Locally the dev derived 70 families on this head, ran all 70 and all exited 0 (--ran: 0 NOT-MEASURED, 0 UNRUN).
  • One ablation: 5 red, 39 green, restored with git diff HEAD empty.
• Accepted deviations:
  • The above-baseline pin went red on its envelope assertion under ablation. The below-baseline and decider pins went red on their reads.
  • plugin-approvals counts 1132 tests: two mirror files that could not load before now load.
  • RunIdentityContext.positions / permissions become optional, named in the changeset.
• Out of scope, one line each:
  • The hook seed resolves no email, so an email-keyed policy in the user's own sets fails closed in such a hook: carrier objectql: a runAs:'user' hook fired from a hand-built system context gets no email, so every current_user.email row policy hides rows its user can read (the email twin of #24497) #24639 (domain:engine, claimed 6278068776). The ordering note 6277888374 has one precision the review adds: "no rows" holds where that policy is the only one admitting rows.
  • A named-user system run whose trigger carried no tenantId resolves the user's organisation-less grants: dropped. The review's ①.3(a) shows it stays inside that user's own envelope, and no flow is known to reach it, so the seat takes no follow-up.
  • An agent ceiling (ADR-0090) on this arm: dropped. It was never honoured here, and the delegated hook path is outside this card.

---

Generated by Claude Code