docs(spec): ISecurityService and the data-engine contract page state the ADR-0096 D5 refusal of a principal-less context

[objectstack-fleet]

Fixes #22302
Clause-②: no

Summary

ADR-0096 D5 strict mode (merged as a3bcbcf) made plugin-security refuse a data-engine context that carries no principal and is not a system context. Two published texts still taught the old hand-off, and this PR corrects them. Text only: no shape, runtime or export moves.

• packages/spec/src/contracts/security-service.ts: the four sentences the card names, at three methods. Each now states what that context gets, in the words of the method's return, and cites ADR-0096 D5.
• content/docs/kernel/contracts/data-engine.mdx: the ExecutionContext passage no longer teaches { flowRunId } alone as an admitted context. It names the two admitted contexts and the refusal.
• .changeset/22302-security-service-principal-less-text.md: @objectstack/spec patch (the TSDoc ships in the published .d.ts).

What each sentence says now

A "principal" is what the existing text already defines: a position, a named permission set or a user id. The context in question has none of the three and is not isSystem.

Where	Before	After
getReadFilter, deny baseline paragraph	only a context with no principal at all keeps the scope the other layers compose, "ADR-0096 stages that context separately"	so does a non-system context with no principal at all (ADR-0096 D5 strict mode): the DENY filter, before any layer composes a scope, as the engine middleware's principal-less refusal (403 PERMISSION_DENIED) answers the same context
canExport, fails-closed paragraph	only a context with no principal at all is admitted, as the middleware hands it through	so does a non-system context with no principal at all (ADR-0096 D5 strict mode): false before anything resolves, the answer the middleware's principal-less refusal (403 PERMISSION_DENIED) gives it
canReadObject, arm list	the deny baseline arm, with "only a context that carries no principal at all is handed through" in parentheses	a new arm after isSystem: the ADR-0096 D5 refusal of a context with no principal at all (false, before anything resolves); the ADR-0056 D2 arm keeps its wording
canReadObject, fails-closed paragraph	only a context with no principal at all is admitted, as the middleware hands it through	same sentence as canExport
data-engine.mdx, ExecutionContext passage	a run with no resolvable identity passes only { flowRunId }, a context that deliberately carries no principal	what the engine needs is a principal or an explicit elevation: the caller's own context, or { isSystem: true }. A context with neither is refused by the security plugin with 403 PERMISSION_DENIED before the operation runs, for every verb. { flowRunId } alone is such a context: a run id is provenance, not identity

Unchanged on purpose: the system bypass sentences, the ADR-0056 D2 deny baseline for a caller that carries a principal and resolves no set, and the getReadableFields paragraph (it already says "a non-system caller who resolves no permission set", which a principal-less context now is). No PR number or tracker id is cited in the shipped text.

Hypotheses measured before writing

Measured against origin/main at fe98cc6 (the tree moved after the base 59d993c; the moved files do not touch principal-less handling, checked by diff of security-plugin.ts, which changed only in the organization-wall region).

• H1 holds. No mode switch. isPrincipalLessContext(context) is read at five call sites in security-plugin.ts: the engine middleware (throws principalLessDenial, a PermissionDeniedError, 403 PERMISSION_DENIED, for every verb, after the isSystem bypass, the public-form-grant branch and the pre-resolution gates, and before any permission-set resolution), getReadFilter (returns the deny filter), canReadObject, canWriteObject and canExport (each returns false). The sixth site, resolveProjectionFieldMask, no longer settles a principal-less context early: it falls through to the zero-set mask like any caller that resolves no set. SecurityPluginOptions has two keys (defaultPermissionSets, fallbackPermissionSet) and the file reads no environment variable on this path. principal-less-strict-mode.test.ts, can-read-object-admission.test.ts and can-write-object-admission.test.ts pass (3 files, 103 tests).
• H2: the file holds exactly the four sentences, and no canWriteObject passage. canWriteObject is not a member of ISecurityService (it is a method of the plugin only), so the contract file never describes it. The other principal hits in the file were each read: hasWriteBypass (:698), resolveWriteScope (:718), describeDelegationNarrowing (:754) and checkAuthoredRowWrite (:798) say a principal-less context fails closed, answers narrowed: false or abstains, all still true. getMetadataReadableFields (:389) says canReadObject is "the deny baseline for a caller that carries a principal", which is true and incomplete, not a hand-off statement, and is left alone.
• H3 holds for content/docs. data-engine.mdx is the only page that teaches { flowRunId } as an admitted context. The other flowRunId and "no principal" hits are auto-generated reference tables or are about other subjects (record-view auditing, the time-triggered flow acting organization, realtime subscriptions, rate-limit keys). One neighbouring sentence is named under Acceptance notes.

Verification

All on commit 4363c58 (the head of this branch).

• Gates: node scripts/pm/dispatch-gates.mjs --commands --repo objectstack-ai/objectstack derived 101 commands (95 at dispatch, plus 6 that apply once the changeset exists). 100 ran with exit 0. 1 is NOT MEASURED: pnpm check:dual-build-cjs-loads exited 3, PREREQUISITE NOT MET (it reads dist/ of 32 packages and needs a repo-wide pnpm build; nothing was measured). Basis for leaving it to CI (Build Core): this diff emits no JavaScript. The new sentences appear only in packages/spec/dist/contracts/index.d.ts and index.d.mts; a recursive grep of dist/ finds them in no .js or .cjs, and finds none of the old sentences anywhere. Three gates first exited 3 for unbuilt prerequisites (@objectstack/formula, @objectstack/lint, @objectstack/client-react); after building those they ran and exited 0.
• --ran verdict line: dispatch-gates --ran: 101 derived famil(ies) accounted for — 100 run, 1 NOT-MEASURED (1 DERIVED from a recorded exit 3). Exit 0.
• pnpm --filter @objectstack/spec build exit 0. pnpm --filter @objectstack/spec typecheck exit 0.
• pnpm --filter @objectstack/spec exec vitest run --maxWorkers=2 src/contracts/security-service.test.ts src/contracts/core-service-contracts.test.ts: 2 files, 33 tests passed.
• Reverse verification and ablation do not apply: no behaviour moves, so there is no assertion to turn red.
• Not run here, left to CI: the repo-wide lint run, Test Core, Dogfood Regression Gate, Build Docs and the type-check lanes outside @objectstack/spec.

Line budget

59 changed lines against the merge base (42 added, 17 removed) in 3 files. No governed path is touched (docs/adr/**, skills/**, .claude/**, AGENTS.md, CLAUDE.md: 0).

Acceptance notes

Noted, not edited, because they sit outside the two files the claim names. They state the same hand-off in published or shipped text and are worth one follow-up edit together:

• packages/spec/src/kernel/execution-context.zod.ts, the flowRunId field TSDoc (about :336-341): "A run that resolves no principal ... passes exactly { flowRunId }: ... such a context authorizes identically to no context at all, and the run keeps the unscoped posture it already had". Stale: that context is refused now.
• packages/spec/src/kernel/execution-context.zod.ts about :499-501, the ExecutionContext type TSDoc: "a flow run with no resolvable identity passes provenance alone ({ flowRunId })". Teaches the refused context as a valid one.
• packages/spec/src/data/data-engine.zod.ts about :66-71, the BaseEngineOptionsSchema.context TSDoc: "a flow run that resolves no identity passes provenance alone ({ flowRunId }), a context deliberately carrying no principal at all". Same.
• packages/spec/src/contracts/analytics-service.ts about :441-443: the rationale for forwarding the request context says a context-less bridge ran "completely unscoped" because "the security middleware's fall-open skipped its own RLS injection". Historical, but with plugin-security composed the context-less call is refused rather than unscoped.
• content/docs/permissions/access-recipes.mdx :52: "A schedule-triggered run has no user, so under user it runs unscoped". The runAs text in content/docs/automation/approvals.mdx, hooks.mdx and the generated automation-api.mdx says such a run's data operations are refused. I did not run a schedule-triggered flow, so this is a read-only inference.
• hook.zod.ts about :1126 ("a schedule-triggered flow run resolves no principal") reads true as written and is left alone.

One behaviour edge, measured by reading and by principal-less-strict-mode.test.ts, not a text defect: the middleware's public-form-grant branch (ADR-0056) sits ahead of the principal-less refusal, so a hand-built { publicFormGrant: { object } } with no named set would be admitted for its create and read-back on that object, while canReadObject, canExport and getReadFilter answer deny for it. The only producer in the tree, the REST form-submit route, builds its context with permissions: ['guest_portal'], so it carries a principal and is not in the class this text describes. The new text says "the middleware's principal-less refusal" rather than claiming the middleware refuses every such context for that reason.

Patch round 1 (the seat amended the claim surface)

Adds the TSDoc of two more published sources and one docs line. Comment and docs text only: 0 of 71 changed lines in the three .ts files is outside a comment block.

• packages/spec/src/kernel/execution-context.zod.ts: the flowRunId field TSDoc and the ExecutionContext input type TSDoc. packages/spec/src/data/data-engine.zod.ts: the BaseEngineOptionsSchema.context TSDoc. They no longer say a run with no principal passes exactly the flowRunId-only context, which authorizes like no context and keeps the unscoped posture, or that such a context is deliberately principal-less. They now say a non-system context with no principal is refused with 403 PERMISSION_DENIED (ADR-0096 D5), that a run id is provenance and not a principal, and, for the flowRunId field, what the automation engine really hands the engine.
• content/docs/permissions/access-recipes.mdx line 52: a schedule-triggered run under runAs user is refused, not run unscoped.
• The changeset gains one sentence naming the three passages (still @objectstack/spec patch, Clause-② no).

Measured before written, on origin/main at 28bff18 (the merge base of this round): packages/services/service-automation/src/runtime-identity.ts, resolveRunDataContext (line 178). With runAs system it returns isSystem true plus actor svc:flow:NAME, empty positions and permissions, the run id, and the trigger userId and tenantId only when the trigger resolved them (lines 180-218). With runAs user and no trigger user, which is what a schedule run has, it throws UnscopedRunDataAccessError (code AUTOMATION_UNSCOPED_RUN_DATA_ACCESS) at line 231, before any call reaches the data engine. With a trigger user it returns that user identity (line 233 on). engine.ts resolveRunContext (lines 6057 and 6062) stamps runAs (default user) and flowRunId on the run context. Nothing in service-automation builds a flowRunId-only context: the RunProvenanceContext type is exported but produced nowhere. Pinned by src/builtin/crud-runas.test.ts (24 tests pass; lines 221, 247, 288 and 316: a user-mode run with no user throws, a schedule run reaches the data layer with zero operations and fails, a record-change run fired by a user-less write is refused the same way).

Verification on head b7cc3e2: spec build exit 0; the old sentences are in no file of packages/spec/dist (.d.ts, .d.mts, .js, .mjs: 0 files); the type TSDoc lands in manifest.zod-*.d.ts and .d.mts, the field TSDoc in the kernel, data, api and browser JS bundles only (a field comment is not emitted into a declaration); spec typecheck exit 0; check:docs exit 0; dispatch-gates --ran: 102 derived, 101 run, 1 NOT-MEASURED (check:dual-build-cjs-loads, exit 3 PREREQUISITE NOT MET, needs a repo-wide build, left to Build Core). Line budget against the merge base: 101 changed lines (68 added, 33 removed), 6 files, 0 governed paths. This round the comments do ship in JS bundles, so the round-0 statement that the diff emits no JavaScript no longer holds; the gate stays NOT MEASURED on the basis that every changed line in the three .ts files is a comment line.

Acceptance notes added: (1) skills/objectstack-query/SKILL.md line 66 still reads that flowRunId is passed for provenance alone; it is a governed Tier H file, not edited, needs its own carrier. (2) packages/services/service-automation/src/runtime-identity.ts lines 56-81 and engine.ts lines 6042-6046 still describe the pre-refusal middleware skip, and the RunProvenanceContext export has no producer; noted, not edited, carrier none. (3) contracts/analytics-service.ts about line 441 stays, as the seat ruled: past-tense history.

CI note, not caused by a test: Test Core 6 of 6 fails at the step Check this shard timing drift (exit 1) on this PR at both 4363c58 and b7cc3e2, with the shard test step before it passing; the same shard is green on the current origin/main push run. The job log is not reachable from this container (the log blob host is refused), so the drift numbers are NOT MEASURED here.

Merge-main round (head 7c79aade4)

#22014's shard-timings refresh (PR #22368) unblocked Test Core (6/6)'s drift step, so main (27a8b33de, 53 commits past the earlier base 28bff18d0) was merged with scripts/pm/os-regen-merge.sh. Zero files conflicted.

• The PR's delta is unchanged: the same six files, +68 / −33, 101 changed lines. The three .ts files change comments only (stripComments comparison, 27a8b33de vs head).
• No sentence went false. main touched none of the six paths, and fix(service-automation)!: retire RunProvenanceContext; pre-D5 principal-less readings outside packages/spec say D5 refuses it #22357 / docs(skills): objectstack-query names the context the engine admits since ADR-0096 D5 #22382 restate the same principal-less rule in agreement.
• Measured: @objectstack/spec unit, local project 627 files / 18757 passed and repo project 54 / 915. 102 derived gates ran: 101 exited 0, and check:dual-build-cjs-loads was left to CI's Build Core (comment-only diff).
• CI on this head: 33 success, 2 skipped.
• Review: the fresh contract review PASS 6076493127. The Verification and Line budget sections above keep the round-0 numbers for the record.

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

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

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

• content/docs/kernel/contracts/index.mdx (via ISecurityService (symbol, a top-level interface))
• content/docs/kernel/runtime-services/index.mdx (via ISecurityService (symbol, a top-level interface))

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

• content/docs/releases/v17/17-0.mdx (via ISecurityService (symbol, a top-level interface))
• content/docs/releases/v17/17-5.mdx (via ISecurityService (symbol, a top-level interface))
• content/docs/releases/v17/17-6.mdx (via ISecurityService (symbol, a top-level interface))
• content/docs/releases/v17/17-7.mdx (via ISecurityService (symbol, a top-level interface))

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

• 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 — 139 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 3054516ef1f16f0e5839cb33d13c0c9d5f8ab84f → packageMentionDocs.

Which tree this was computed on

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

node scripts/docs-audit/affected-docs.mjs --json 3054516ef1f16f0e5839cb33d13c0c9d5f8ab84f

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

[objectstack-fleet]

CI on 4363c583d: Test Core (6/6) red on its timing-drift step, not on a test · domain:spec seat 2 (#18549) · session session_01DhTqaEHqPVSVnAkjG3jywn · 2026-10-08T17:44Z.

• What failed: the shard-timing drift step read 2442.2s measured vs 1609.1s predicted (1.52x, red past 1.5x). No test failed: check-test-completeness accounted for all 15824 scheduled tests.
• Why it is not this PR's: this diff changes comments and one docs page only, and the overshoots are runtime, plugin-security and driver-sql. PRs fix(spec,service-automation)!: an undeclared config key on 10 more builtin node types is refused at the build doors; one judge per type #22319 and feat(spec, metadata-protocol): each _drafts row carries the draft body's own label, or null #22323 drifted on the same shard and packages today. The dataset's staleness is tracked on finding(ci): the shard-timings dataset rests on ONE scheduled run, and records @objectstack/spec at 1134.86 s against 1573–1651 s executed — #16468's 25%-headroom ceilings built on it would red every PR that runs spec #22014, with today's readings in its latest comment. No fix exists to port.
• Re-run: this PR's patch round 1 (seat comment 6065402920 on docs(spec): ISecurityService TSDoc still says a context with no principal is admitted or keeps its scope; PR #22297 (#21908, ADR-0096 D5 strict mode) refuses it #22302) pushes next and re-runs every shard.

---

Generated by Claude Code

[objectstack-fleet]

Contract review

Served-tier: CONTRACT_REVIEW_TIER
Head-sha: b7cc3e2178f4881d57785baa3d20e125df7e0055
Local-runs: none

Inputs read: card #22302 (body and all 7 comments, triage 6061436428 through ACCEPT 6067117343), PR #22327 (body, 6-file list, net diff against merge base 28bff18d0), the 42 check-runs on the head, and the governing text on origin/main (3599fef12): AGENTS.md, ADR-0096 D5 and its dated note, plugin-security/src/security-plugin.ts, service-automation/src/runtime-identity.ts. Scratch: pr-22327/ only. Read at 2026-10-08T19:15Z.

① Derived judgments

No accept-set change and no public-surface change. Every hunk in the three .ts files sits inside a /** … */ block (33 + 26 + 12 changed lines, 0 outside a comment); the other three files are two docs pages and the changeset. No schema, export, type or .describe() string moves. Check Changeset, Lint & Repo Gates (check:docs, check:api-surface), Build Core, Build Docs and every type-check lane are green on the head.

Each rewritten sentence, judged against the code on origin/main:

Sentence (head)	Judged against	Verdict
security-service.ts:316-319 getReadFilter: a non-system context with no principal gets the DENY filter before any layer composes a scope	security-plugin.ts:5942-5946: isSystem → undefined; isPrincipalLessContext → { ...RLS_DENY_FILTER } ahead of resolveSharingReadFilter	right
security-service.ts:631-634 canExport: false before anything resolves	security-plugin.ts:6774-6777: isSystem → true; isPrincipalLessContext → false before resolvePermissionSetsForContext	right
security-service.ts:653-659 canReadObject arm list: isSystem, the D5 refusal, the D2 deny baseline, unresolved posture, the D3 AND-gate, allowRead, the D10 delegator	security-plugin.ts:6380-6420: arms 1–6 in that order (isSystem, isPrincipalLessContext, permissionSets.length === 0, unresolved, capability AND-gate, CRUD grant, delegator)	right
security-service.ts:673-676 canReadObject fails-closed paragraph	same site	right
execution-context.zod.ts:334-343 flowRunId: never a principal; { flowRunId } alone refused 403 PERMISSION_DENIED; the automation engine builds no such context; a runAs:'user' run with no trigger user is refused AUTOMATION_UNSCOPED_RUN_DATA_ACCESS before the data engine; a runAs:'system' run passes isSystem: true with the id beside it	isPrincipalLessContext (security-plugin.ts:383-387) keys on positions/permissions/userId after the isSystem bypass; resolveRunDataContext (runtime-identity.ts:178-241): system branch returns isSystem: true, actor, positions: [], permissions: [], flowRunId; !context?.userId throws UnscopedRunDataAccessError (code = 'AUTOMATION_UNSCOPED_RUN_DATA_ACCESS'); every data node calls it (crud-nodes.ts:484/572/720/812, plugin.ts:1248); no producer of a { flowRunId }-only engine context in packages/** (git grep)	right
execution-context.zod.ts:502-507 the ExecutionContext type: any subset is legal input, not every subset admitted; the two admitted contexts	ADR-0096 D5 dated note, word for word on the refusal, the three principal fields and the isSystem: true opt-in	right
data-engine.zod.ts:67-72 BaseEngineOptionsSchema.context	same	right
data-engine.mdx:128-135 ExecutionContext passage: refused for every verb, { flowRunId } alone is such a context	the one engine middleware (security-plugin.ts:2654) throws principalLessDenial for every operation; the ADR note says "every verb"	right
access-recipes.mdx:52: a schedule-triggered runAs: 'user' run's data operations are refused	UnscopedRunDataAccessError message prescribes runAs: 'system' "to make the elevation explicit and intended"; hooks.mdx:176 already says the same	right

Sentences the diff leaves in the touched files, re-read: security-service.ts:203 (narrowed: false for a principal-less context), :703, :723, :759, :803 (fail closed / abstain for a principal-less context) stay true and are now the stronger reading. :390 (canReadObject is "the deny baseline for a caller that carries a principal") is incomplete, not false: the D5 arm answers the other caller false too. execution-context.zod.ts:57-58 ("a context carrying only [attributedUserId] authorizes exactly like a context carrying nothing — ANONYMOUS") stays true: both are refused. Nothing left in the five files states the hand-off. content/docs on origin/main holds no other "carries no principal" / "provenance alone" / "runs unscoped" sentence about a principal (the flows.mdx:2387 hit is tenant scoping under the single posture, a different subject).

One imprecision, not a defect: the changeset's "The corrected text ships in the published .d.ts" holds for the ISecurityService and the ExecutionContext type TSDoc; the flowRunId field and BaseEngineOptionsSchema.context comments sit inside z.object({}) literals and ship in the JS bundles, as the dev's round-1 measurement says. The changeset names the right surface for the text its title is about.

② Semver level

.changeset/22302-security-service-principal-less-text.md: @objectstack/spec: patch, Clause-②: no, no arm — matches the diff. Comment text in a released package's .d.ts and JS bundles publishes, so skip-changeset would be wrong (AGENTS.md Post-Task Checklist §3), and nothing is added, widened or narrowed, so minor would over-declare. No ADR-0087 marker is owed (not breaking). content/docs/** is not an npm surface. PR body carries Clause-②: no, the same line. Check Changeset green on the head.

③ Boundary flags

open_questions: [] in both dev reports (6065357115, 6067044558). Dev flags and acceptance notes, each answered:

1. Public-form-grant edge (a hand-built { publicFormGrant: { object } } with no named set is admitted for create / read-back by the middleware, while the three probes deny it). Answered, no escalation: publicFormGrant is not a field of ExecutionContextSchema (no hit in packages/spec/src/kernel/execution-context.zod.ts); it is an ADR-0056 declaration-derived admission on a server-constructed key whose only producer (rest-server.ts:11200-11202) carries permissions: ['guest_portal'], so it carries a principal and is outside the class the new text describes. The contract text is correct for the published context shape. Stays in Acceptance notes.
2. skills/objectstack-query/SKILL.md:66 ("flowRunId for provenance alone"). Tier H, not editable here; the seat's ACCEPT (6067117343) owes the Tier H card after the merge. Answered: that card is the carrier; it is owed, not optional.
3. Stale sibling comments, "carrier none" — service-automation/src/runtime-identity.ts:56-81, service-automation/src/engine.ts:6042-6046, and (found here) objectql/src/engine.ts:5393 ("{ flowRunId }, all an identity-less flow run has"). Escalated. RunProvenanceContext is exported from service-automation/src/index.ts:195 and listed in its README, so its docstring ("the empty-principal fall-open … indistinguishable from passing no context at all", present tense) is published contract text of @objectstack/service-automation that the runtime no longer honours — the same filing gate ① this card was filed on. It needs a domain:services card, not "carrier none". Not this PR's defect (outside the claim surface, another lane).
4. analytics-service.ts:441-443: "That is exactly how security(analytics): ObjectQLStrategy 不消费 getReadScope — NativeSQL 回落后聚合查询无 RLS/租户谓词(#2852 修复未覆盖的另一半) #3597 happened … the security middleware's fall-open skipped its own RLS injection" is past tense, as the seat ruled. Answered: stays.
5. check:dual-build-cjs-loads NOT MEASURED locally: Build Core is green on the head. Answered by the check-run.
6. Red check-runs on the head, recorded as the brief requires: Test Core (6/6) — failure at step 14 Check this shard's timing drift (step 12 Run this shard's tests and step 15 Test completeness guard succeeded); Test Core (the aggregate) — failure at step 4 Verify test shard results, which follows from the shard. The drift readings are NOT MEASURED here (the job-log blob host is refused from this container); the dev and seat attribute them to the dataset tracked on finding(ci): the shard-timings dataset rests on ONE scheduled run, and records @objectstack/spec at 1134.86 s against 1573–1651 s executed — #16468's 25%-headroom ceilings built on it would red every PR that runs spec #22014. A comment-only diff cannot move shard timing, and the shard's tests passed. The seat's landing to-do already holds the PR until every check is green; this record does not green it.

Implemented-by: claude/issue-22302-security-service-principal-less-tsdoc
Reviewed-by: session_01DhTqaEHqPVSVnAkjG3jywn

VERDICT: PASS

---

Generated by Claude Code

[objectstack-fleet]

Contract review

Served-tier: CONTRACT_REVIEW_TIER
Head-sha: 7c79aade4b1bb4ae31ab3b88f867b7b5039aad93
Local-runs: none

Inputs read: card #22302 (body and all 9 comments, triage 6061436428 through the merge-main dev report 6075540848), PR #22327 (body, 6-file list, net diff against the merge base 27a8b33de, which is the main this head merges and an ancestor of origin/main), the 35 check-runs on the head, and the merged tree itself at 27a8b33de / the head: plugin-security/src/security-plugin.ts, service-automation/src/runtime-identity.ts, ADR-0096 D5 and its dated note, the two pages the Docs Drift Check names, and the main commits #22357 (746637e51) and #22382 (191543456). Scratch: pr-22327/ only. Read at 2026-10-09T07:29Z. This record judges this head on its own; the record 6067252881 on b7cc3e217 is an input, not a carrier.

① Derived judgments

No accept-set change and no public-surface change. The head is a merge of 27a8b33de (53 commits past the previous base 28bff18d0) into b7cc3e217, with zero conflicted files, and its net delta against main is the same six files as before: +68 / −33, 101 changed lines. In the three .ts files (33 + 12 + 26 changed lines) every added and removed line is a comment line: a filter over the diff for a changed line that does not open with * or /** returns nothing. No schema, export, type or .describe() string moves; publicFormGrant is still not a field of ExecutionContextSchema (0 hits), and canWriteObject is still not a member of ISecurityService (0 hits), so the contract text rightly names only canReadObject and canExport. main touched none of the six paths between 28bff18d0 and 27a8b33de (git log on each path is empty), so the merge could not have made a sentence false by editing its file. Lint & Repo Gates, TypeScript Type Check, Build Core, Build Docs, Check Changeset and every type-check lane are success on the head.

Each sentence the PR states, judged against the merged main (27a8b33de), not against the earlier tree:

Sentence (head)	Judged against	Verdict
security-service.ts:316-319 getReadFilter: a non-system context with no principal gets the DENY filter, before any layer composes a scope, as the middleware's principal-less refusal answers it	security-plugin.ts:5943 isSystem → undefined; :5947 isPrincipalLessContext → { ...RLS_DENY_FILTER }, ahead of the OWD/sharing predicate and every RLS branch	right
security-service.ts:631-634 canExport: false before anything resolves	security-plugin.ts:6778 isSystem → true; :6781 isPrincipalLessContext → false, before resolvePermissionSetsForContext	right
security-service.ts:653-659 canReadObject arm list: isSystem, the D5 refusal, the D2 deny baseline, unresolvable posture, the D3 AND-gate, allowRead, the D10 delegator	security-plugin.ts:6384-6420: arm 1 isSystem, arm 2 isPrincipalLessContext, permissionSets.length === 0, arm 3 unresolved, arm 4 capability AND-gate, arm 5 CRUD grant, the delegator intersection (resolved once ahead of arms 4 and 6, a dangling link denying there)	right
security-service.ts:673-676 canReadObject fails-closed paragraph	same site	right
data-engine.mdx:128-135: refused with 403 PERMISSION_DENIED (PermissionDeniedError) before the operation runs, for every verb; { flowRunId } alone is such a context	security-plugin.ts:2451 isSystem → next(); :2655-2656 isPrincipalLessContext(opCtx.context) → throw principalLessDenial(opCtx.operation, opCtx.object) in the one operation middleware, keyed on no verb; principalLessDenial (:398-406) constructs PermissionDeniedError with the two-remedy text; the D5 dated note says "every verb" and 403 PERMISSION_DENIED	right
execution-context.zod.ts:334-343 flowRunId: never a principal; { flowRunId } alone refused; the automation engine builds no such context; a runAs:'user' run with no trigger user is refused AUTOMATION_UNSCOPED_RUN_DATA_ACCESS before the data engine; a runAs:'system' run passes isSystem: true with the id beside it	isPrincipalLessContext (security-plugin.ts:383-387) keys on positions / permissions / userId; runtime-identity.ts after #22357: RunProvenanceContext is retired and RunDataContext extends RunIdentityContext (:103-108), so the type system now also says no provenance-only context exists; resolveRunDataContext returns isSystem: true (:172) with flowRunId beside it (:201) for system, and throws UnscopedRunDataAccessError (code = 'AUTOMATION_UNSCOPED_RUN_DATA_ACCESS', :77) at :219 when !context?.userId	right, and stronger than at b7cc3e217
execution-context.zod.ts:502-507 the ExecutionContext type: any subset is legal input, not every subset admitted; the two admitted contexts	ADR-0096 D5 dated note at head, word for word on the refusal, the three principal fields and the isSystem: true opt-in	right
data-engine.zod.ts:67-72 BaseEngineOptionsSchema.context	same note; the same five predicate sites	right
access-recipes.mdx:52: a schedule-triggered runAs: 'user' run's data operations are refused; declare system to make the elevation explicit and intended	runtime-identity.ts:219 throws before the engine is called; hooks.mdx:176 on the merged tree says the same ("refuses its data operations instead of running them with no principal at all")	right

The two main commits that restate the rule agree with this PR, sentence for sentence. #22357 (746637e51, domain:services) retired RunProvenanceContext and rewrote 24 pre-D5 comment sites outside packages/spec to say the middleware "used to" hand the context through and that D5 refuses it; its security-plugin.ts hunk is comment text only (getMetadataReadableFields docstring), so the five predicate sites this PR describes are the code the earlier head was judged on. #22382 (191543456) rewrote skills/objectstack-query/SKILL.md:65-70 to "{ isSystem: true } for a system read, otherwise the caller's own context (user, position or permission set), or 403 PERMISSION_DENIED (ADR-0096 D5)", the same two admitted contexts and the same refusal this PR names. Neither contradicts a sentence in the diff, and neither touches a PR file.

The Docs Drift Check pages, re-read on the merged tree. content/docs/kernel/contracts/index.mdx:43 is one table row: ISecurityService is "Query surface for access decisions — row-level read scope, readable-field projection, effective permission sets, access explanation". content/docs/kernel/runtime-services/index.mdx:66-69 says only that the interface "is listed with the other kernel contracts". Neither states who is admitted or what a principal-less context gets, so neither contradicts this PR; neither needs an edit.

Sweep of the merged tree for leftover hand-off wording, outside releases/ and references/: content/docs yields hooks.mdx:176 (agrees), flows.mdx:2393 ("timeRelative sweep runs unscoped" is organization scoping under the single posture, another subject), forms.mdx:47 ("never the anonymous fall-open", a negation, true) and tenant-audit-census.mdx:124 (a spread literal, another subject). packages/spec/src yields the two new sentences, security-service.ts:803 (a principal-less context abstains, true), analytics-service.ts:442 (past tense, the seat's ruling stands) and :502 (an absent getReadScope hook on an analytics strategy, not an engine context). skills/ yields nothing now that #22382 is in the tree. Nothing left in the merged tree states the hand-off in the present tense.

One imprecision, carried over, not a defect: the changeset's "The corrected text ships in the published .d.ts" holds for the ISecurityService and ExecutionContext type TSDoc; the flowRunId field and BaseEngineOptionsSchema.context comments sit inside z.object({}) literals and ship in the JS bundles, as the dev measured at b7cc3e217 and again at this head. The changeset names the right surface for the text its title is about.

② Semver level

.changeset/22302-security-service-principal-less-text.md: @objectstack/spec: patch, Clause-②: no, no arm — matches the diff. Comment text in a released package's .d.ts and JS bundles publishes, so skip-changeset would be wrong (AGENTS.md Post-Task Checklist §3); nothing is added, widened or narrowed, so minor would over-declare. No ADR-0087 marker is owed (not breaking). content/docs/** is not an npm surface. The PR body carries Clause-②: no, the same line. Check Changeset is success on the head. The merge brought no second changeset onto the branch and the delta still holds exactly one.

③ Boundary flags

open_questions: [] in all three dev reports (6065357115, 6067044558, 6075540848); out_of_scope_findings: [] in the merge-main report. The flags the earlier record carried are re-judged on this head, and the merge-main report's own notes are answered:

1. Public-form-grant edge (a hand-built { publicFormGrant: { object } } with no named set is admitted by the middleware's ADR-0056 branch, which sits after isSystem and ahead of the D5 refusal, while the three probes deny it). Answered, no escalation: publicFormGrant is not a field of ExecutionContextSchema at this head (0 hits), so the published context shape has no such key, and the contract text is correct for the shape it documents. Stays in the PR's Acceptance notes, carrier none.
2. skills/objectstack-query/SKILL.md:66 (Tier H, owed as a post-merge card by the ACCEPT 6067117343). Resolved on main: docs(skills): objectstack-query names the context the engine admits since ADR-0096 D5 #22382 (191543456) landed the correction, and the merged tree carries it. The post-merge Tier H card is no longer owed.
3. RunProvenanceContext docstring (the earlier record's escalation, filed as service-automation: the exported RunProvenanceContext docstring still says a { flowRunId }-only context falls open ("indistinguishable from passing no context at all"); ADR-0096 D5 now refuses it, and the type is produced nowhere #22345). Resolved on main: service-automation: the exported RunProvenanceContext docstring still says a { flowRunId }-only context falls open ("indistinguishable from passing no context at all"); ADR-0096 D5 now refuses it, and the type is produced nowhere #22345 is closed by fix(service-automation)!: retire RunProvenanceContext; pre-D5 principal-less readings outside packages/spec say D5 refuses it #22357 (746637e51), which retired the type and rewrote the sibling sites in runtime-identity.ts and engine.ts. The merged tree carries it, and the flowRunId TSDoc in this PR is now backed by the type as well as the code.
4. analytics-service.ts:441-443: past tense ("That is exactly how security(analytics): ObjectQLStrategy 不消费 getReadScope — NativeSQL 回落后聚合查询无 RLS/租户谓词(#2852 修复未覆盖的另一半) #3597 happened"), the seat's ruling. Answered: stays.
5. check:dual-build-cjs-loads NOT MEASURED locally (exit 3, needs a repo-wide build): Build Core is success on the head. Answered by the check-run.
6. Test Core (6/6) timing-drift red at the two earlier heads: Test Core and all six shards are success on this head; the shard-timings dataset refresh (chore(ci): refresh the Test Core shard-timings dataset #22368) is in the merged tree. Answered by the check-runs.
7. Two main commits after the merge, not merged (86ae11992 fix(cli): with no built Console, /_console/ answers 503 naming the remedy instead of a bare 404 #22419, 3054516ef fix(cli): doctor's Environment files row names os serve / os start as its loaders in the source posture (#22249) #22417): both are packages/cli plus their changesets and tests, no path in common with this PR, and the merge queue rebuilds the PR onto current main anyway (AGENTS.md §7). Answered: no second merge lap is owed for this record.
8. ci(pm): check:pm-dispatch-gates is red on main — its live-tree case reads mkdtempSync(join(process.cwd(), …)) in a #22365 dogfood test as an unresolved temp base #22422 (security-catalog-cold-boot-environment-holder.dogfood.test.ts:108), named by the dev as never in play: Dogfood Regression Gate and its three shards are success on this head. Not this diff.
9. PR body prose: the "Verification" and "Line budget" sections still carry the round-0 numbers (4363c583d, 59 lines, 3 files); the round-1 addendum in the same body carries the current ones (101 lines, 6 files), and the merge-main round wrote no addendum. The file list and the diff are the record of what lands; this is prose staleness, not a contract defect, and a body rewrite is a footer hazard (AGENTS.md, PR body). Noted for the owning seat; not blocking.

Check-runs on the head: 33 success, 2 skipped (Console Pin Gate, no .objectui-sha change; Packed-tarball smoke, opt-in), 0 failure. The seven required contexts are all success. Governed surfaces: none of the six paths; Governed Surface Queue Guard success. Head repo equals base repo; 101 changed lines. The PR is still a draft: landing is the owning seat's act after this record, as the ACCEPT's to-do states.

Implemented-by: claude/issue-22302-security-service-principal-less-tsdoc
Reviewed-by: session_01DhTqaEHqPVSVnAkjG3jywn

VERDICT: PASS

---

Generated by Claude Code