[objectstack-fleet]

Fixes #19874
Clause-②: no

What changed

POST /automation/:name/runs/:runId/cancel and .../restore-suspension admit only the ADR-0095 PLATFORM_ADMIN rung. Their refusal told every refused caller to obtain "the unscoped admin_full_access grant, ADR-0068 D2". Under a walled posture (group / isolated) the platform-admin derivation no longer reads that grant as an anchor. The resolver sets legacyGrantAnchorRetired = postureEnforcesWall(resolveTenancyPosture()) and gates the grant route on it. So on a walled deployment the refusal named a remedy that fails silently.

The middle sentence of the refusal is now built from the inputs the derivation reads, using the same expression, postureEnforcesWall(resolveTenancyPosture()):

requested posture	the refusal says platform-operator standing comes from
group / isolated	only the deployment's declared platform administrators: an account whose verified email address is listed in OS_PLATFORM_OWNER_EMAIL
single	an unscoped admin_full_access grant (ADR-0068 D2), or the declared administrators in OS_PLATFORM_OWNER_EMAIL
unreadable (resolveTenancyPosture throws)	the declared administrators in OS_PLATFORM_OWNER_EMAIL (honoured on every posture), without echoing the environment value

• The first sentence (what the verbs are) and the last sentence (the resume door) are unchanged.
• The gate is unchanged. It is still ec.posture === 'PLATFORM_ADMIN' plus the isSystem bypass, still 403 PERMISSION_DENIED, and admits the same callers on every arm. The posture read sits inside a guard, so it can change the wording but never the answer.
• OS_PLATFORM_OWNER_EMAIL is quoted through PLATFORM_OWNER_EMAIL_ENV (@objectstack/types). That is the constant the boot-side walled lines in plugin-security already quote, and the name content/docs/deployment/environment-variables.mdx documents. The set name is quoted through ADMIN_FULL_ACCESS (@objectstack/spec/identity), the constant the resolver compares against.
• single is described as it ships today and nothing more. The runtime string carries no tracker id and does not predict the single disposition. platform-admin re-anchor follow-up (Choice 4B): config-anchor the single posture — first-user promotion becomes development-only fallback #11979 is not addressed here.

Docblocks corrected (comment-only)

• packages/runtime/src/domains/automation.ts: the run-lifecycle gate docblock said the rung "is derived from the unscoped admin_full_access evidence and nothing else". That is false. The config anchor confers on every posture, and walled postures retire the grant anchor. It now states the per-posture anchors, and notes that only the refusal sentence reads the posture while admission does not.

• packages/runtime/src/domains/activation-gate.ts:56: the same sentence, word for word ("derived from the unscoped-grant evidence and nothing else"), corrected the same way. This file is outside the claim's declared file surface. It was fixed under os-dev's bounded in-place-fix exemption:

  • ① same defect class: the twin sentence.
  • ② mechanical, with the shape set by the automation.ts fix.
  • ③ no open PR touches the file: the file lists of all 17 open PRs were read.
  • ④ comment-only, so no new verification surface.

  The claim's file surface needs this path added. activation-gate.ts:51 was left alone: it quotes the old premise and already says it "stopped holding", which is true.

Sweep of packages/runtime/src (non-test)

Spellings searched: unscoped `admin_full_access`, admin_full_access` grant, admin_full_access grant, unscoped grant, unscoped-grant, ADR-0068 D2, unscoped admin_full_access. Every non-comment string line naming a platform operator or admin was also read.

• The only runtime string that prescribed the grant was this refusal (automation.ts:656 on 3557f85f).
• activation-gate.ts:134 and :237 say "platform operator" and name no mechanism, which is true on every posture.
• dispatcher-error-vocabulary.ts:521 is ledger data about a vendor code, not a remedy.
• route-ledger.ts notes name the rung, not a remedy.

Tests

New file: packages/runtime/src/domains/automation-run-lifecycle-deny-remedy.test.ts (8 tests). It does not pin wording. For each of single, group and isolated it pins one equivalence: the refusal names a remedy if and only if the resolver honours it. For each candidate remedy, it builds a caller whose only route to standing is that remedy and resolves it through the runtime's own resolveExecutionContext, with the real core resolver underneath and the requested posture read from the environment as in production. It then hands that caller to the real dispatcher:

• If the resolver honours the remedy, the gate admits the caller (200, the verb called once). This is the lit control.
• If it does not, the caller is refused PERMISSION_DENIED + 403 with the same sentence, which does not name that remedy. This is the mirror.
• A control table shows the grant fixture does resolve PLATFORM_ADMIN under single. So a walled false means the anchor is retired, not that the fixture is broken.
• A non-vacuity assertion checks that every posture's refusal names at least one working remedy.
• Also covered: both doors answer an identical sentence, and an unreadable posture keeps PERMISSION_DENIED + 403.

Reverse verification ran on b4b3ed07 (fix and test committed first). Each mutation was applied with scripts/ablation-replace.mjs (anchor hit x1 to x0, blob changed) and ran under a trap. Each restore was proven: blob equal to the HEAD blob daa4fa8562bf, git diff HEAD empty, git status clean. The subject is imported through relative source paths, and runtime's vitest config aliases @objectstack/core, @objectstack/types and @objectstack/spec to src, so no dist/ rebuild applies. Every run turned red as predicted:

mutation	new suite
the pre-fix sentence restored as the middle part	7 of 8 red. The pre-existing door suite (38 tests) stays green under it, so the old suite could not see this defect. The "both doors" row stays green, as expected: it pins sameness, not content.
the walled arm also names the grant	2 red: the group and isolated equivalence rows, "grant: named ⇔ honoured: expected true to be false"
the single arm stops naming the grant	1 red: the single row, "expected false to be true"
the posture read left unguarded	1 red: the unreadable-posture row

Local verification (at 40bf21c9)

• pnpm --filter @objectstack/runtime exec vitest run --project local (the test script's project): 277 files passed, 3901 tests passed, 1 skipped.
• pnpm --filter @objectstack/runtime typecheck: exit 0. This covers tsc --noEmit and check:test-typecheck, which held the ledger at 27 files, 191 errors and 69 pinned signatures. The new test is inside tsconfig.test.json's program (--listFilesOnly: 1 hit).
• pnpm lint (full eslint . --no-inline-config union): exit 0.
• dispatch-gates --commands on the real diff derived the same 60 commands as the PM's list. Result: 58 exit 0, 2 NOT MEASURED. --ran reconciliation: "60 derived famil(ies) accounted for — 58 run, 2 NOT-MEASURED (2 DERIVED from a recorded exit 3)". This includes pnpm check:doc-authoring: "sibling-package prose ids hold the baseline — 816 pinned site(s) across 231 file(s) ... no growth, no burn-down unrecorded". scripts/doc-authoring-prose-id.baseline.json is unchanged, and automation.ts never had an entry in it.
• Also run, exit 0: the five roster gates whose rosters sit beside these paths (check-changeset-fixed, check:authz-resolver, check:error-code-casing, check:filter-alias-parity, check:route-ledger-census), and check-issue-citations --base 3557f85f ("every citation this change adds resolves").
• NOT MEASURED: check:dual-build-cjs-loads. Reason: exit 3, PREREQUISITE NOT MET. It is a whole-tree gate, and 39 packages have no dist/. A narrowed substitute ran for runtime only: after the build, require('@objectstack/runtime') in a real node process resolved dist/index.cjs (exit 0, 260 exports). dist/index.cjs carries the new sentence (1 hit) and not the old one (0 hits). This is a substitute, not the gate.
• NOT MEASURED: check:type-check-debt. Reason: exit 3, PREREQUISITE NOT MET (@objectstack/driver-turso has no built type entry). Runtime's own typecheck above is the per-package half.
• Declared to CI: runtime's test:repo project, and the families that take workflow values.

Acceptance notes

• check:doc-authoring: the card said this message sits "under the shrink-only check:doc-authoring baseline". Measured, that is not the case. That gate's runtime leg is a (file, tracker-id) ratchet over string literals. The old message carried no tracker id, and automation.ts has no baseline entry. Editing the message owes the baseline nothing as long as no #NNNN enters a string. The new strings carry ADR ids only.
• Stale comments, noted and not filed (comment drift, outside this claim; carrier: none):
  • packages/core/src/security/resolve-authz-context.ts: the §6d comment (about lines 1042-1045) and the hasPlatformAdminStanding docblock (about lines 1085-1098) still say PLATFORM_ADMIN derives from the unscoped-grant evidence "and nothing else". That file is read-only in this lane.
  • packages/qa/dogfood/test/authz-conformance.matrix.ts:178 says "derives only from an unscoped admin_full_access grant".
  • packages/runtime/src/domains/automation-run-lifecycle-door.test.ts:117: the OPERATOR_CTX doc comment says "derived from the unscoped admin_full_access grant".
• Route choice: the suggested route was one posture-neutral sentence with a single qualifier. That sentence would still name the grant on a walled deployment. The qualifier "until platform-admin re-anchor follow-up (Choice 4B): config-anchor the single posture — first-user promotion becomes development-only fallback #11979 decides otherwise" would also put a tracker id into a runtime string and predict that card's outcome. A config-only sentence would be true everywhere. But it would describe single as config-only, which is the reading the single disposition ruling reversed. So the sentence is chosen per posture, using the derivation's own expression.

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/runtime, touching 7 documentable anchor(s). ⚠️ 1 changed file(s) yielded no anchor (packages/runtime/src/domains/activation-gate.ts), so the pages documenting them are NOT COVERED by this run — this is not a clean bill of health for those files.

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

• content/docs/permissions/system-context.mdx (via refuseUngrantedRunLifecycleWrite (symbol, a top-level function))

What this run could not see

• 1 changed file(s) yielded no anchor (packages/runtime/src/domains/activation-gate.ts) — pages documenting those are invisible to this run
• the SDK route bridge reached 60 of 215 client-bound route-ledger rows — the other 155 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 155: 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; 100 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 — 26 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 b76aad5f6fac71cbbcd4ea6bfdf21a59e2fd4d56 → packageMentionDocs.

Which tree this was computed on

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

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

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