docs(spec): correct AutomationContext.flowName's attribution prose — elevation decides authorization, not attribution

[hotlong]

Fixes#14011

A prose-only correction. The shipped runtime behaviour is right and is untouched — the sentence describing it was not.

The stale sentence

packages/spec/src/contracts/automation-service.ts, documenting AutomationContext.flowName (published as dist/contracts/index.d.ts, line 3033 on 17.1.0 / line 3000 on this branch's 17.2.0 build):

a runAs:'system' run resolves no user, so resolveRunDataContext labels its data operations svc:flow:FLOWNAME on ExecutionContext.actor … instead of leaving the audit row unattributed

That reads as "system elevation costs you the operator in the audit trail."

What actually ships — re-verified against origin/main, not taken from the card

The card's reading was measured on the 17.1.0 artifact; every claim below was re-derived from the source in this checkout at 62a137b.

• packages/services/service-automation/src/runtime-identity.ts → resolveRunDataContext, runAs:'system' branch: { isSystem: true, actor: 'svc:flow:' + flowName, ...(context.userId ? { userId: context.userId } : {}), ...(context.tenantId ? { tenantId } : {}), positions: [], permissions: [] }. The operator is carried through unchanged (Automation create_record under runAs:'system' inserts rows with owner_id/organization_id/created_by all NULL — records born untouchable even by admin #5494) — the comment on that line says so in as many words: "elevation is not anonymity … isSystem alone decides authorization, while the user drives the platform's attribution stamps."
• packages/objectql/src/plugin.ts → sys_stamp_audit_insert / sys_stamp_audit_update stamp created_by / updated_by under if (session?.userId). There is no isSystem test anywhere on that path.
• packages/plugins/plugin-audit/src/audit-writers.ts → writeAudit computes userId = sess.userId ?? provenance.attributedUserId and actorLabel = userId ?? sess.actor. The svc:flow: label is the fallback, in that order, with no isSystem gate.

So the svc:flow: labelling the sentence described is real — but it is the user-less case (a schedule, or a runAs:'system' flow fired by a write that itself carried no user). The sentence generalised it to every runAs:'system' run.

What changed

1. The prose (packages/spec/src/contracts/automation-service.ts). The flowName JSDoc now states what is true of both cases: elevation decides AUTHORIZATION and leaves ATTRIBUTION alone; the svc:flow: actor label is the fallback a genuinely user-less run lands on, where ADR-0118 D1 keeps the user column null rather than inventing a sentinel.

2. A sweep for the same wrong concept. Searched packages/spec/src, every package's JSDoc, and content/docs/ for the family — resolves no user, unattributed, user-less, Unknown user, elevation/anonymity, and every prose mention of runAs: 'system' and svc:flow:. Exactly one site carried the wrong generalisation, the one fixed here. Everything else that mentions a user-less run is already scoped to the genuinely user-less case and was deliberately left alone (for instance content/docs/permissions/system-context.mdx line 200, "a user-less system write stamps nothing", and service-automation/src/engine.ts line 3436, "for runs that resolve no user" — both correct as written).

3. A line between the prose and the code that rings.packages/services/service-automation/src/runas-attribution-contract.test.ts asserts the invariant the prose now states, at the end of the chain — the session envelope the audit writers actually read — rather than at resolveRunDataContext's return shape, which builtin/crud-runas.test.ts already pins:

• an elevated, user-triggered run updates a row created by a different user, and updated_by moves to the triggering operator — the same value the identical write produces on the plain user path, with created_by left on the creator;
• a genuinely user-less run (schedule shape) creates a row whose user column stays NULL, and whose hook-visible session.actor is svc:flow:night_sweep.

If the code ever becomes what the old prose described, this file goes red instead of the next reader having to re-measure.

Reverse verification — and what it caught

Direction predicted before running: the operator limb goes RED, the user-less limb stays GREEN (it has no user to strip).

Ablation A — deleted the userId carry-through from resolveRunDataContext's system branch (i.e. made the code match the old prose). The first run reddened only the hook-session assertion; the updated_by column assertion passed under mutation, because the row had been seeded by the operator and already carried that value from its own insert. That assertion was measuring the insert, not the elevated update. Fixed by seeding the rows as a different user (usr_creator), so the column has to move for the assertion to pass. Re-ablated:

AssertionError: the elevated run must stamp the triggering operator: expected 'usr_creator' to be 'usr_operator'
Test Files 1 failed (1)
Tests 1 failed | 1 passed (2)

Ablation B — replaced the svc:flow: label with a constant, to check the second limb is live too:

AssertionError: the flow label names WHICH automation wrote (ADR-0014 D2): expected 'svc:ABLATED' to be 'svc:flow:elevated_touch'
AssertionError: the svc:flow: label is the fallback attribution: expected 'svc:ABLATED' to be 'svc:flow:night_sweep'
Test Files 1 failed (1)
Tests 2 failed (2)

Both ablations mutated a committed tree, proved the mutation on disk by grep counts plus a git hash-object comparison against the HEAD blob, carried an absolute-path trap … EXIT INT TERM, and restored to the byte-identical HEAD blob (git diff HEAD empty) before the next measurement. No rebuild step was needed for either: runtime-identity.ts is reached from builtin/crud-nodes.ts by a relative source import inside its own package, and this package's vitest config aliases only @objectstack/platform-objects — nothing routes its own modules through exports/dist.

Verification

All readings below are from aca37be, the branch head; the gate union was run after the final commit.

Check	Result
@objectstack/service-automation full suite	93 files / 1099 tests passed — no existing behaviour assertion moved
@objectstack/spec full suite	447 files / 11991 tests passed
@objectstack/spectsc --noEmit	0 errors
@objectstack/service-automationtsc --noEmit	exactly the 3 ledgered TS2341 in nested-region-parity.test.ts; 0 from the new file, and --listFiles confirms the new test file is in that program
pnpm lint (repo-wide eslint . --no-inline-config)	exit 0, no findings
Derived gate family (scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack --commands)	48 commands, 45 green

The three non-green results are all exit 3 / PREREQUISITE NOT MET — nothing measured, not findings:

• check:type-check-debt and check:dual-build-cjs-loads and scripts/check-dev-prereqs.mjs all refuse without a fully built workspace closure. CI builds it before those steps, exactly as lint.yml does. The substance the ratchet guards was measured directly instead, in the tsc --noEmit row above: the new test file is in the program and contributes zero errors, so the @objectstack/service-automation entry (errors: 3) does not move.
• scripts/check-test-completeness.mjs (exit 3) needs a saved turbo run test log it cannot produce itself, and scripts/pm/check-half-states.mjs (exit 3) needs repo-scoped egress this container does not have. Both declare that exit as NOT MEASURED.

packages/spec was rebuilt after the edit, and the corrected sentence is present in dist/contracts/index.d.ts (1 occurrence) with the stale one gone (0 occurrences).

Notes for the reviewer

• Left draft deliberately, and no domain:* label set: this was dispatched by the downstream steedos-labs/hotcrm-heimao PM seat under a direct maintainer instruction, not by this repo's spec lane. The spec seat or the maintainer lands it.
• .changeset/automation-context-flowname-attribution-prose.md bumps @objectstack/specpatch — the correction ships in the published .d.ts. @objectstack/service-automation gets no bump: its only change is a new test file.
• No overlap with A hook cannot elevate, so a hook-written computed column cannot be protected by field-level editable: false — the guard and the writer are the same door #14010, which adds runAs to HookSchema and changes runtime. HookSchema is untouched here, and nothing in this prose forward-announces a capability that has not landed.

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

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

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

• content/docs/releases/v15.mdx(via AutomationContext (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

• 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 — 128 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 0d80862366f5181b5db75c5ba103c69db98df181 → packageMentionDocs.

Which tree this was computed on

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

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

[hotlong]

Docs Drift Check 的两行都查过了，结论分开：一行是误报，一行是真的，已按守则立卡而非在此编辑。 本 PR 未触碰 content/docs/releases/，也不会去触碰。

它列的页	结论
content/docs/releases/v15.mdx:863	正确，无需动作。 原文是「Flow-type actions now receive the caller's identity as a real AutomationContext（runAs: 'user' flows evaluate RLS as the caller）」—— 讲的是 runAs: 'user'，本身成立。它被列出只因为点名了 AutomationContext 这个符号，正是该 bot 宣称的 precision-first 行为在正常工作。
（bot 未列，我顺着同一个概念扫出来的）content/docs/releases/v17.mdx:2073	真的有问题，已立 #14039。

那条真的

v17.mdx:2072-2073（#4366）：

…and a runAs: 'system' flow's writes are audited as svc:flow:<flowName> instead of "Unknown user"

无限定，读起来就是所有 system 提权运行的通则 —— 也就是本 PR 正在契约散文里消灭的那个错概念。

而 同一个发布页 的 v17.mdx:2860-2861 是 #5494：

runAs: 'system'create_record stamps all three ADR-0118 columns — organization, owner and creator are non-NULL.

两条各自都不假（一条讲 actor 标签、一条讲落库的三列），但并排读，靠前那条在靠后那条之前约 800 行，中间没有任何东西把它们连起来。front-to-back 读 v17 的人会先遇到无限定版本。

⛔ 不建议直接改写 #4366 那条 —— 那会篡改它当时确实交付的东西。#14039 里给了两个保持记录诚实的选项（加限定+指引 / 依赖本 PR 修好的契约散文），并说明发布说明政策是发布流程的事，不是下游报告人的，所以我没有提 PR。

关于 dev 的扫描范围

派发词明令禁止编辑 content/docs/releases/，dev 遵守了。它的同族措辞扫描覆盖了 packages/spec/src、各包 JSDoc 与 content/docs/，报「exactly one site carried the wrong generalisation」。那个读数对本 PR 可改的范围是准的 —— v17 那条落在只读区，本来就不该出现在一个可改清单里。这不是漏扫，是边界。

---

Generated by Claude Code

[hotlong]

CI 全绿，交接给 spec 席位。 head aca37be 上 10 个工作流全部 success，含最慢的两条（Lint & Type Check 01:03、CI 01:10）。无冲突，无评审意见待处理。

保持 draft，我不转 ready 也不合 —— 这是本仓契约面的裁量权，不属于一个下游 PM 席位。我这边对本 PR 的驱动到此为止。

要落它需要知道的三件事，集中在这里免得翻楼：

1. 运行时行为一个字没改，改的是描述它的散文加一份钉住不变式的测试。service-automation 93 文件 / 1099 测试全过，无既有断言移动。
2. packages/spec patch 级 changeset —— 更正随发布的 .d.ts 出去。service-automation 不升版，它只多了一个测试文件。
3. Docs Drift Check 的两行都查过了（见上方评论）：v15.mdx 那行正确、无需动作；顺着同一概念另外扫到 v17.mdx:2073 确有问题，已按只读守则立卡不编辑（v17 release notes: the #4366 entry states the svc:flow: audit label unqualified, and the #5494 entry later in the same page supersedes it — nothing connects them #14039）。本 PR 未触碰 content/docs/releases/。

与 #14044（#14010 半 B）不重叠：那张改 CLI/lint/runtime，本张只改 spec 契约散文与一个新测试。

---

Generated by Claude Code

[hotlong]

Fixes#14011

A prose-only correction. The shipped runtime behaviour is right and is untouched — the sentence describing it was not.

The stale sentence

packages/spec/src/contracts/automation-service.ts, documenting AutomationContext.flowName (published as dist/contracts/index.d.ts, line 3033 on 17.1.0 / line 3000 on this branch's 17.2.0 build):

a runAs:'system' run resolves no user, so resolveRunDataContext labels its data operations svc:flow:FLOWNAME on ExecutionContext.actor … instead of leaving the audit row unattributed

That reads as "system elevation costs you the operator in the audit trail."

What actually ships — re-verified against origin/main, not taken from the card

The card's reading was measured on the 17.1.0 artifact; every claim below was re-derived from the source in this checkout at 62a137b.

• packages/services/service-automation/src/runtime-identity.ts → resolveRunDataContext, runAs:'system' branch: { isSystem: true, actor: 'svc:flow:' + flowName, ...(context.userId ? { userId: context.userId } : {}), ...(context.tenantId ? { tenantId } : {}), positions: [], permissions: [] }. The operator is carried through unchanged (Automation create_record under runAs:'system' inserts rows with owner_id/organization_id/created_by all NULL — records born untouchable even by admin #5494) — the comment on that line says so in as many words: "elevation is not anonymity … isSystem alone decides authorization, while the user drives the platform's attribution stamps."
• packages/objectql/src/plugin.ts → sys_stamp_audit_insert / sys_stamp_audit_update stamp created_by / updated_by under if (session?.userId). There is no isSystem test anywhere on that path.
• packages/plugins/plugin-audit/src/audit-writers.ts → writeAudit computes userId = sess.userId ?? provenance.attributedUserId and actorLabel = userId ?? sess.actor. The svc:flow: label is the fallback, in that order, with no isSystem gate.

So the svc:flow: labelling the sentence described is real — but it is the user-less case (a schedule, or a runAs:'system' flow fired by a write that itself carried no user). The sentence generalised it to every runAs:'system' run.

What changed

1. The prose (packages/spec/src/contracts/automation-service.ts). The flowName JSDoc now states what is true of both cases: elevation decides AUTHORIZATION and leaves ATTRIBUTION alone; the svc:flow: actor label is the fallback a genuinely user-less run lands on, where ADR-0118 D1 keeps the user column null rather than inventing a sentinel.

2. A sweep for the same wrong concept. Searched packages/spec/src, every package's JSDoc, and content/docs/ for the family — resolves no user, unattributed, user-less, Unknown user, elevation/anonymity, and every prose mention of runAs: 'system' and svc:flow:. Exactly one site carried the wrong generalisation, the one fixed here. Everything else that mentions a user-less run is already scoped to the genuinely user-less case and was deliberately left alone (for instance content/docs/permissions/system-context.mdx line 200, "a user-less system write stamps nothing", and service-automation/src/engine.ts line 3436, "for runs that resolve no user" — both correct as written).

3. A line between the prose and the code that rings.packages/services/service-automation/src/runas-attribution-contract.test.ts asserts the invariant the prose now states, at the end of the chain — the session envelope the audit writers actually read — rather than at resolveRunDataContext's return shape, which builtin/crud-runas.test.ts already pins:

• an elevated, user-triggered run updates a row created by a different user, and updated_by moves to the triggering operator — the same value the identical write produces on the plain user path, with created_by left on the creator;
• a genuinely user-less run (schedule shape) creates a row whose user column stays NULL, and whose hook-visible session.actor is svc:flow:night_sweep.

If the code ever becomes what the old prose described, this file goes red instead of the next reader having to re-measure.

Reverse verification — and what it caught

Direction predicted before running: the operator limb goes RED, the user-less limb stays GREEN (it has no user to strip).

Ablation A — deleted the userId carry-through from resolveRunDataContext's system branch (i.e. made the code match the old prose). The first run reddened only the hook-session assertion; the updated_by column assertion passed under mutation, because the row had been seeded by the operator and already carried that value from its own insert. That assertion was measuring the insert, not the elevated update. Fixed by seeding the rows as a different user (usr_creator), so the column has to move for the assertion to pass. Re-ablated:

AssertionError: the elevated run must stamp the triggering operator: expected 'usr_creator' to be 'usr_operator'
Test Files 1 failed (1)
Tests 1 failed | 1 passed (2)

Ablation B — replaced the svc:flow: label with a constant, to check the second limb is live too:

AssertionError: the flow label names WHICH automation wrote (ADR-0014 D2): expected 'svc:ABLATED' to be 'svc:flow:elevated_touch'
AssertionError: the svc:flow: label is the fallback attribution: expected 'svc:ABLATED' to be 'svc:flow:night_sweep'
Test Files 1 failed (1)
Tests 2 failed (2)

Both ablations mutated a committed tree, proved the mutation on disk by grep counts plus a git hash-object comparison against the HEAD blob, carried an absolute-path trap … EXIT INT TERM, and restored to the byte-identical HEAD blob (git diff HEAD empty) before the next measurement. No rebuild step was needed for either: runtime-identity.ts is reached from builtin/crud-nodes.ts by a relative source import inside its own package, and this package's vitest config aliases only @objectstack/platform-objects — nothing routes its own modules through exports/dist.

Verification

All readings below are from aca37be, the branch head; the gate union was run after the final commit.

Check	Result
@objectstack/service-automation full suite	93 files / 1099 tests passed — no existing behaviour assertion moved
@objectstack/spec full suite	447 files / 11991 tests passed
@objectstack/spectsc --noEmit	0 errors
@objectstack/service-automationtsc --noEmit	exactly the 3 ledgered TS2341 in nested-region-parity.test.ts; 0 from the new file, and --listFiles confirms the new test file is in that program
pnpm lint (repo-wide eslint . --no-inline-config)	exit 0, no findings
Derived gate family (scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack --commands)	48 commands, 45 green

The three non-green results are all exit 3 / PREREQUISITE NOT MET — nothing measured, not findings:

• check:type-check-debt and check:dual-build-cjs-loads and scripts/check-dev-prereqs.mjs all refuse without a fully built workspace closure. CI builds it before those steps, exactly as lint.yml does. The substance the ratchet guards was measured directly instead, in the tsc --noEmit row above: the new test file is in the program and contributes zero errors, so the @objectstack/service-automation entry (errors: 3) does not move.
• scripts/check-test-completeness.mjs (exit 3) needs a saved turbo run test log it cannot produce itself, and scripts/pm/check-half-states.mjs (exit 3) needs repo-scoped egress this container does not have. Both declare that exit as NOT MEASURED.

packages/spec was rebuilt after the edit, and the corrected sentence is present in dist/contracts/index.d.ts (1 occurrence) with the stale one gone (0 occurrences).

Notes for the reviewer

• Left draft deliberately, and no domain:* label set: this was dispatched by the downstream steedos-labs/hotcrm-heimao PM seat under a direct maintainer instruction, not by this repo's spec lane. The spec seat or the maintainer lands it.
• .changeset/automation-context-flowname-attribution-prose.md bumps @objectstack/specpatch — the correction ships in the published .d.ts. @objectstack/service-automation gets no bump: its only change is a new test file.
• No overlap with A hook cannot elevate, so a hook-written computed column cannot be protected by field-level editable: false — the guard and the writer are the same door #14010, which adds runAs to HookSchema and changes runtime. HookSchema is untouched here, and nothing in this prose forward-announces a capability that has not landed.

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

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

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

• content/docs/releases/v15.mdx(via AutomationContext (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

• 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 — 128 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 0d80862366f5181b5db75c5ba103c69db98df181 → packageMentionDocs.

Which tree this was computed on

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

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

[hotlong]

Docs Drift Check 的两行都查过了，结论分开：一行是误报，一行是真的，已按守则立卡而非在此编辑。 本 PR 未触碰 content/docs/releases/，也不会去触碰。

它列的页	结论
content/docs/releases/v15.mdx:863	正确，无需动作。 原文是「Flow-type actions now receive the caller's identity as a real AutomationContext（runAs: 'user' flows evaluate RLS as the caller）」—— 讲的是 runAs: 'user'，本身成立。它被列出只因为点名了 AutomationContext 这个符号，正是该 bot 宣称的 precision-first 行为在正常工作。
（bot 未列，我顺着同一个概念扫出来的）content/docs/releases/v17.mdx:2073	真的有问题，已立 #14039。

那条真的

v17.mdx:2072-2073（#4366）：

…and a runAs: 'system' flow's writes are audited as svc:flow:<flowName> instead of "Unknown user"

无限定，读起来就是所有 system 提权运行的通则 —— 也就是本 PR 正在契约散文里消灭的那个错概念。

而 同一个发布页 的 v17.mdx:2860-2861 是 #5494：

runAs: 'system'create_record stamps all three ADR-0118 columns — organization, owner and creator are non-NULL.

两条各自都不假（一条讲 actor 标签、一条讲落库的三列），但并排读，靠前那条在靠后那条之前约 800 行，中间没有任何东西把它们连起来。front-to-back 读 v17 的人会先遇到无限定版本。

⛔ 不建议直接改写 #4366 那条 —— 那会篡改它当时确实交付的东西。#14039 里给了两个保持记录诚实的选项（加限定+指引 / 依赖本 PR 修好的契约散文），并说明发布说明政策是发布流程的事，不是下游报告人的，所以我没有提 PR。

关于 dev 的扫描范围

派发词明令禁止编辑 content/docs/releases/，dev 遵守了。它的同族措辞扫描覆盖了 packages/spec/src、各包 JSDoc 与 content/docs/，报「exactly one site carried the wrong generalisation」。那个读数对本 PR 可改的范围是准的 —— v17 那条落在只读区，本来就不该出现在一个可改清单里。这不是漏扫，是边界。

---

Generated by Claude Code

[hotlong]

CI 全绿，交接给 spec 席位。 head aca37be 上 10 个工作流全部 success，含最慢的两条（Lint & Type Check 01:03、CI 01:10）。无冲突，无评审意见待处理。

保持 draft，我不转 ready 也不合 —— 这是本仓契约面的裁量权，不属于一个下游 PM 席位。我这边对本 PR 的驱动到此为止。

要落它需要知道的三件事，集中在这里免得翻楼：

1. 运行时行为一个字没改，改的是描述它的散文加一份钉住不变式的测试。service-automation 93 文件 / 1099 测试全过，无既有断言移动。
2. packages/spec patch 级 changeset —— 更正随发布的 .d.ts 出去。service-automation 不升版，它只多了一个测试文件。
3. Docs Drift Check 的两行都查过了（见上方评论）：v15.mdx 那行正确、无需动作；顺着同一概念另外扫到 v17.mdx:2073 确有问题，已按只读守则立卡不编辑（v17 release notes: the #4366 entry states the svc:flow: audit label unqualified, and the #5494 entry later in the same page supersedes it — nothing connects them #14039）。本 PR 未触碰 content/docs/releases/。

与 #14044（#14010 半 B）不重叠：那张改 CLI/lint/runtime，本张只改 spec 契约散文与一个新测试。

---

Generated by Claude Code

[hotlong]

Fixes#14011

A prose-only correction. The shipped runtime behaviour is right and is untouched — the sentence describing it was not.

The stale sentence

packages/spec/src/contracts/automation-service.ts, documenting AutomationContext.flowName (published as dist/contracts/index.d.ts, line 3033 on 17.1.0 / line 3000 on this branch's 17.2.0 build):

a runAs:'system' run resolves no user, so resolveRunDataContext labels its data operations svc:flow:FLOWNAME on ExecutionContext.actor … instead of leaving the audit row unattributed

That reads as "system elevation costs you the operator in the audit trail."

What actually ships — re-verified against origin/main, not taken from the card

The card's reading was measured on the 17.1.0 artifact; every claim below was re-derived from the source in this checkout at 62a137b.

• packages/services/service-automation/src/runtime-identity.ts → resolveRunDataContext, runAs:'system' branch: { isSystem: true, actor: 'svc:flow:' + flowName, ...(context.userId ? { userId: context.userId } : {}), ...(context.tenantId ? { tenantId } : {}), positions: [], permissions: [] }. The operator is carried through unchanged (Automation create_record under runAs:'system' inserts rows with owner_id/organization_id/created_by all NULL — records born untouchable even by admin #5494) — the comment on that line says so in as many words: "elevation is not anonymity … isSystem alone decides authorization, while the user drives the platform's attribution stamps."
• packages/objectql/src/plugin.ts → sys_stamp_audit_insert / sys_stamp_audit_update stamp created_by / updated_by under if (session?.userId). There is no isSystem test anywhere on that path.
• packages/plugins/plugin-audit/src/audit-writers.ts → writeAudit computes userId = sess.userId ?? provenance.attributedUserId and actorLabel = userId ?? sess.actor. The svc:flow: label is the fallback, in that order, with no isSystem gate.

So the svc:flow: labelling the sentence described is real — but it is the user-less case (a schedule, or a runAs:'system' flow fired by a write that itself carried no user). The sentence generalised it to every runAs:'system' run.

What changed

1. The prose (packages/spec/src/contracts/automation-service.ts). The flowName JSDoc now states what is true of both cases: elevation decides AUTHORIZATION and leaves ATTRIBUTION alone; the svc:flow: actor label is the fallback a genuinely user-less run lands on, where ADR-0118 D1 keeps the user column null rather than inventing a sentinel.

2. A sweep for the same wrong concept. Searched packages/spec/src, every package's JSDoc, and content/docs/ for the family — resolves no user, unattributed, user-less, Unknown user, elevation/anonymity, and every prose mention of runAs: 'system' and svc:flow:. Exactly one site carried the wrong generalisation, the one fixed here. Everything else that mentions a user-less run is already scoped to the genuinely user-less case and was deliberately left alone (for instance content/docs/permissions/system-context.mdx line 200, "a user-less system write stamps nothing", and service-automation/src/engine.ts line 3436, "for runs that resolve no user" — both correct as written).

3. A line between the prose and the code that rings.packages/services/service-automation/src/runas-attribution-contract.test.ts asserts the invariant the prose now states, at the end of the chain — the session envelope the audit writers actually read — rather than at resolveRunDataContext's return shape, which builtin/crud-runas.test.ts already pins:

• an elevated, user-triggered run updates a row created by a different user, and updated_by moves to the triggering operator — the same value the identical write produces on the plain user path, with created_by left on the creator;
• a genuinely user-less run (schedule shape) creates a row whose user column stays NULL, and whose hook-visible session.actor is svc:flow:night_sweep.

If the code ever becomes what the old prose described, this file goes red instead of the next reader having to re-measure.

Reverse verification — and what it caught

Direction predicted before running: the operator limb goes RED, the user-less limb stays GREEN (it has no user to strip).

Ablation A — deleted the userId carry-through from resolveRunDataContext's system branch (i.e. made the code match the old prose). The first run reddened only the hook-session assertion; the updated_by column assertion passed under mutation, because the row had been seeded by the operator and already carried that value from its own insert. That assertion was measuring the insert, not the elevated update. Fixed by seeding the rows as a different user (usr_creator), so the column has to move for the assertion to pass. Re-ablated:

AssertionError: the elevated run must stamp the triggering operator: expected 'usr_creator' to be 'usr_operator'
Test Files 1 failed (1)
Tests 1 failed | 1 passed (2)

Ablation B — replaced the svc:flow: label with a constant, to check the second limb is live too:

AssertionError: the flow label names WHICH automation wrote (ADR-0014 D2): expected 'svc:ABLATED' to be 'svc:flow:elevated_touch'
AssertionError: the svc:flow: label is the fallback attribution: expected 'svc:ABLATED' to be 'svc:flow:night_sweep'
Test Files 1 failed (1)
Tests 2 failed (2)

Both ablations mutated a committed tree, proved the mutation on disk by grep counts plus a git hash-object comparison against the HEAD blob, carried an absolute-path trap … EXIT INT TERM, and restored to the byte-identical HEAD blob (git diff HEAD empty) before the next measurement. No rebuild step was needed for either: runtime-identity.ts is reached from builtin/crud-nodes.ts by a relative source import inside its own package, and this package's vitest config aliases only @objectstack/platform-objects — nothing routes its own modules through exports/dist.

Verification

All readings below are from aca37be, the branch head; the gate union was run after the final commit.

Check	Result
@objectstack/service-automation full suite	93 files / 1099 tests passed — no existing behaviour assertion moved
@objectstack/spec full suite	447 files / 11991 tests passed
@objectstack/spectsc --noEmit	0 errors
@objectstack/service-automationtsc --noEmit	exactly the 3 ledgered TS2341 in nested-region-parity.test.ts; 0 from the new file, and --listFiles confirms the new test file is in that program
pnpm lint (repo-wide eslint . --no-inline-config)	exit 0, no findings
Derived gate family (scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack --commands)	48 commands, 45 green

The three non-green results are all exit 3 / PREREQUISITE NOT MET — nothing measured, not findings:

• check:type-check-debt and check:dual-build-cjs-loads and scripts/check-dev-prereqs.mjs all refuse without a fully built workspace closure. CI builds it before those steps, exactly as lint.yml does. The substance the ratchet guards was measured directly instead, in the tsc --noEmit row above: the new test file is in the program and contributes zero errors, so the @objectstack/service-automation entry (errors: 3) does not move.
• scripts/check-test-completeness.mjs (exit 3) needs a saved turbo run test log it cannot produce itself, and scripts/pm/check-half-states.mjs (exit 3) needs repo-scoped egress this container does not have. Both declare that exit as NOT MEASURED.

packages/spec was rebuilt after the edit, and the corrected sentence is present in dist/contracts/index.d.ts (1 occurrence) with the stale one gone (0 occurrences).

Notes for the reviewer

• Left draft deliberately, and no domain:* label set: this was dispatched by the downstream steedos-labs/hotcrm-heimao PM seat under a direct maintainer instruction, not by this repo's spec lane. The spec seat or the maintainer lands it.
• .changeset/automation-context-flowname-attribution-prose.md bumps @objectstack/specpatch — the correction ships in the published .d.ts. @objectstack/service-automation gets no bump: its only change is a new test file.
• No overlap with A hook cannot elevate, so a hook-written computed column cannot be protected by field-level editable: false — the guard and the writer are the same door #14010, which adds runAs to HookSchema and changes runtime. HookSchema is untouched here, and nothing in this prose forward-announces a capability that has not landed.

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

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

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

• content/docs/releases/v15.mdx(via AutomationContext (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

• 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 — 128 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 0d80862366f5181b5db75c5ba103c69db98df181 → packageMentionDocs.

Which tree this was computed on

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

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

[hotlong]

Docs Drift Check 的两行都查过了，结论分开：一行是误报，一行是真的，已按守则立卡而非在此编辑。 本 PR 未触碰 content/docs/releases/，也不会去触碰。

它列的页	结论
content/docs/releases/v15.mdx:863	正确，无需动作。 原文是「Flow-type actions now receive the caller's identity as a real AutomationContext（runAs: 'user' flows evaluate RLS as the caller）」—— 讲的是 runAs: 'user'，本身成立。它被列出只因为点名了 AutomationContext 这个符号，正是该 bot 宣称的 precision-first 行为在正常工作。
（bot 未列，我顺着同一个概念扫出来的）content/docs/releases/v17.mdx:2073	真的有问题，已立 #14039。

那条真的

v17.mdx:2072-2073（#4366）：

…and a runAs: 'system' flow's writes are audited as svc:flow:<flowName> instead of "Unknown user"

无限定，读起来就是所有 system 提权运行的通则 —— 也就是本 PR 正在契约散文里消灭的那个错概念。

而 同一个发布页 的 v17.mdx:2860-2861 是 #5494：

runAs: 'system'create_record stamps all three ADR-0118 columns — organization, owner and creator are non-NULL.

两条各自都不假（一条讲 actor 标签、一条讲落库的三列），但并排读，靠前那条在靠后那条之前约 800 行，中间没有任何东西把它们连起来。front-to-back 读 v17 的人会先遇到无限定版本。

⛔ 不建议直接改写 #4366 那条 —— 那会篡改它当时确实交付的东西。#14039 里给了两个保持记录诚实的选项（加限定+指引 / 依赖本 PR 修好的契约散文），并说明发布说明政策是发布流程的事，不是下游报告人的，所以我没有提 PR。

关于 dev 的扫描范围

派发词明令禁止编辑 content/docs/releases/，dev 遵守了。它的同族措辞扫描覆盖了 packages/spec/src、各包 JSDoc 与 content/docs/，报「exactly one site carried the wrong generalisation」。那个读数对本 PR 可改的范围是准的 —— v17 那条落在只读区，本来就不该出现在一个可改清单里。这不是漏扫，是边界。

---

Generated by Claude Code

[hotlong]

CI 全绿，交接给 spec 席位。 head aca37be 上 10 个工作流全部 success，含最慢的两条（Lint & Type Check 01:03、CI 01:10）。无冲突，无评审意见待处理。

保持 draft，我不转 ready 也不合 —— 这是本仓契约面的裁量权，不属于一个下游 PM 席位。我这边对本 PR 的驱动到此为止。

要落它需要知道的三件事，集中在这里免得翻楼：

1. 运行时行为一个字没改，改的是描述它的散文加一份钉住不变式的测试。service-automation 93 文件 / 1099 测试全过，无既有断言移动。
2. packages/spec patch 级 changeset —— 更正随发布的 .d.ts 出去。service-automation 不升版，它只多了一个测试文件。
3. Docs Drift Check 的两行都查过了（见上方评论）：v15.mdx 那行正确、无需动作；顺着同一概念另外扫到 v17.mdx:2073 确有问题，已按只读守则立卡不编辑（v17 release notes: the #4366 entry states the svc:flow: audit label unqualified, and the #5494 entry later in the same page supersedes it — nothing connects them #14039）。本 PR 未触碰 content/docs/releases/。

与 #14044（#14010 半 B）不重叠：那张改 CLI/lint/runtime，本张只改 spec 契约散文与一个新测试。

---

Generated by Claude Code

[hotlong]

Fixes#14011

A prose-only correction. The shipped runtime behaviour is right and is untouched — the sentence describing it was not.

The stale sentence

packages/spec/src/contracts/automation-service.ts, documenting AutomationContext.flowName (published as dist/contracts/index.d.ts, line 3033 on 17.1.0 / line 3000 on this branch's 17.2.0 build):

a runAs:'system' run resolves no user, so resolveRunDataContext labels its data operations svc:flow:FLOWNAME on ExecutionContext.actor … instead of leaving the audit row unattributed

That reads as "system elevation costs you the operator in the audit trail."

What actually ships — re-verified against origin/main, not taken from the card

The card's reading was measured on the 17.1.0 artifact; every claim below was re-derived from the source in this checkout at 62a137b.

• packages/services/service-automation/src/runtime-identity.ts → resolveRunDataContext, runAs:'system' branch: { isSystem: true, actor: 'svc:flow:' + flowName, ...(context.userId ? { userId: context.userId } : {}), ...(context.tenantId ? { tenantId } : {}), positions: [], permissions: [] }. The operator is carried through unchanged (Automation create_record under runAs:'system' inserts rows with owner_id/organization_id/created_by all NULL — records born untouchable even by admin #5494) — the comment on that line says so in as many words: "elevation is not anonymity … isSystem alone decides authorization, while the user drives the platform's attribution stamps."
• packages/objectql/src/plugin.ts → sys_stamp_audit_insert / sys_stamp_audit_update stamp created_by / updated_by under if (session?.userId). There is no isSystem test anywhere on that path.
• packages/plugins/plugin-audit/src/audit-writers.ts → writeAudit computes userId = sess.userId ?? provenance.attributedUserId and actorLabel = userId ?? sess.actor. The svc:flow: label is the fallback, in that order, with no isSystem gate.

So the svc:flow: labelling the sentence described is real — but it is the user-less case (a schedule, or a runAs:'system' flow fired by a write that itself carried no user). The sentence generalised it to every runAs:'system' run.

What changed

1. The prose (packages/spec/src/contracts/automation-service.ts). The flowName JSDoc now states what is true of both cases: elevation decides AUTHORIZATION and leaves ATTRIBUTION alone; the svc:flow: actor label is the fallback a genuinely user-less run lands on, where ADR-0118 D1 keeps the user column null rather than inventing a sentinel.

2. A sweep for the same wrong concept. Searched packages/spec/src, every package's JSDoc, and content/docs/ for the family — resolves no user, unattributed, user-less, Unknown user, elevation/anonymity, and every prose mention of runAs: 'system' and svc:flow:. Exactly one site carried the wrong generalisation, the one fixed here. Everything else that mentions a user-less run is already scoped to the genuinely user-less case and was deliberately left alone (for instance content/docs/permissions/system-context.mdx line 200, "a user-less system write stamps nothing", and service-automation/src/engine.ts line 3436, "for runs that resolve no user" — both correct as written).

3. A line between the prose and the code that rings.packages/services/service-automation/src/runas-attribution-contract.test.ts asserts the invariant the prose now states, at the end of the chain — the session envelope the audit writers actually read — rather than at resolveRunDataContext's return shape, which builtin/crud-runas.test.ts already pins:

• an elevated, user-triggered run updates a row created by a different user, and updated_by moves to the triggering operator — the same value the identical write produces on the plain user path, with created_by left on the creator;
• a genuinely user-less run (schedule shape) creates a row whose user column stays NULL, and whose hook-visible session.actor is svc:flow:night_sweep.

If the code ever becomes what the old prose described, this file goes red instead of the next reader having to re-measure.

Reverse verification — and what it caught

Direction predicted before running: the operator limb goes RED, the user-less limb stays GREEN (it has no user to strip).

Ablation A — deleted the userId carry-through from resolveRunDataContext's system branch (i.e. made the code match the old prose). The first run reddened only the hook-session assertion; the updated_by column assertion passed under mutation, because the row had been seeded by the operator and already carried that value from its own insert. That assertion was measuring the insert, not the elevated update. Fixed by seeding the rows as a different user (usr_creator), so the column has to move for the assertion to pass. Re-ablated:

AssertionError: the elevated run must stamp the triggering operator: expected 'usr_creator' to be 'usr_operator'
Test Files 1 failed (1)
Tests 1 failed | 1 passed (2)

Ablation B — replaced the svc:flow: label with a constant, to check the second limb is live too:

AssertionError: the flow label names WHICH automation wrote (ADR-0014 D2): expected 'svc:ABLATED' to be 'svc:flow:elevated_touch'
AssertionError: the svc:flow: label is the fallback attribution: expected 'svc:ABLATED' to be 'svc:flow:night_sweep'
Test Files 1 failed (1)
Tests 2 failed (2)

Both ablations mutated a committed tree, proved the mutation on disk by grep counts plus a git hash-object comparison against the HEAD blob, carried an absolute-path trap … EXIT INT TERM, and restored to the byte-identical HEAD blob (git diff HEAD empty) before the next measurement. No rebuild step was needed for either: runtime-identity.ts is reached from builtin/crud-nodes.ts by a relative source import inside its own package, and this package's vitest config aliases only @objectstack/platform-objects — nothing routes its own modules through exports/dist.

Verification

All readings below are from aca37be, the branch head; the gate union was run after the final commit.

Check	Result
@objectstack/service-automation full suite	93 files / 1099 tests passed — no existing behaviour assertion moved
@objectstack/spec full suite	447 files / 11991 tests passed
@objectstack/spectsc --noEmit	0 errors
@objectstack/service-automationtsc --noEmit	exactly the 3 ledgered TS2341 in nested-region-parity.test.ts; 0 from the new file, and --listFiles confirms the new test file is in that program
pnpm lint (repo-wide eslint . --no-inline-config)	exit 0, no findings
Derived gate family (scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack --commands)	48 commands, 45 green

The three non-green results are all exit 3 / PREREQUISITE NOT MET — nothing measured, not findings:

• check:type-check-debt and check:dual-build-cjs-loads and scripts/check-dev-prereqs.mjs all refuse without a fully built workspace closure. CI builds it before those steps, exactly as lint.yml does. The substance the ratchet guards was measured directly instead, in the tsc --noEmit row above: the new test file is in the program and contributes zero errors, so the @objectstack/service-automation entry (errors: 3) does not move.
• scripts/check-test-completeness.mjs (exit 3) needs a saved turbo run test log it cannot produce itself, and scripts/pm/check-half-states.mjs (exit 3) needs repo-scoped egress this container does not have. Both declare that exit as NOT MEASURED.

packages/spec was rebuilt after the edit, and the corrected sentence is present in dist/contracts/index.d.ts (1 occurrence) with the stale one gone (0 occurrences).

Notes for the reviewer

• Left draft deliberately, and no domain:* label set: this was dispatched by the downstream steedos-labs/hotcrm-heimao PM seat under a direct maintainer instruction, not by this repo's spec lane. The spec seat or the maintainer lands it.
• .changeset/automation-context-flowname-attribution-prose.md bumps @objectstack/specpatch — the correction ships in the published .d.ts. @objectstack/service-automation gets no bump: its only change is a new test file.
• No overlap with A hook cannot elevate, so a hook-written computed column cannot be protected by field-level editable: false — the guard and the writer are the same door #14010, which adds runAs to HookSchema and changes runtime. HookSchema is untouched here, and nothing in this prose forward-announces a capability that has not landed.

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

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

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

• content/docs/releases/v15.mdx(via AutomationContext (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

• 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 — 128 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 0d80862366f5181b5db75c5ba103c69db98df181 → packageMentionDocs.

Which tree this was computed on

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

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

[hotlong]

Docs Drift Check 的两行都查过了，结论分开：一行是误报，一行是真的，已按守则立卡而非在此编辑。 本 PR 未触碰 content/docs/releases/，也不会去触碰。

它列的页	结论
content/docs/releases/v15.mdx:863	正确，无需动作。 原文是「Flow-type actions now receive the caller's identity as a real AutomationContext（runAs: 'user' flows evaluate RLS as the caller）」—— 讲的是 runAs: 'user'，本身成立。它被列出只因为点名了 AutomationContext 这个符号，正是该 bot 宣称的 precision-first 行为在正常工作。
（bot 未列，我顺着同一个概念扫出来的）content/docs/releases/v17.mdx:2073	真的有问题，已立 #14039。

那条真的

v17.mdx:2072-2073（#4366）：

…and a runAs: 'system' flow's writes are audited as svc:flow:<flowName> instead of "Unknown user"

无限定，读起来就是所有 system 提权运行的通则 —— 也就是本 PR 正在契约散文里消灭的那个错概念。

而 同一个发布页 的 v17.mdx:2860-2861 是 #5494：

runAs: 'system'create_record stamps all three ADR-0118 columns — organization, owner and creator are non-NULL.

两条各自都不假（一条讲 actor 标签、一条讲落库的三列），但并排读，靠前那条在靠后那条之前约 800 行，中间没有任何东西把它们连起来。front-to-back 读 v17 的人会先遇到无限定版本。

⛔ 不建议直接改写 #4366 那条 —— 那会篡改它当时确实交付的东西。#14039 里给了两个保持记录诚实的选项（加限定+指引 / 依赖本 PR 修好的契约散文），并说明发布说明政策是发布流程的事，不是下游报告人的，所以我没有提 PR。

关于 dev 的扫描范围

派发词明令禁止编辑 content/docs/releases/，dev 遵守了。它的同族措辞扫描覆盖了 packages/spec/src、各包 JSDoc 与 content/docs/，报「exactly one site carried the wrong generalisation」。那个读数对本 PR 可改的范围是准的 —— v17 那条落在只读区，本来就不该出现在一个可改清单里。这不是漏扫，是边界。

---

Generated by Claude Code

[hotlong]

CI 全绿，交接给 spec 席位。 head aca37be 上 10 个工作流全部 success，含最慢的两条（Lint & Type Check 01:03、CI 01:10）。无冲突，无评审意见待处理。

保持 draft，我不转 ready 也不合 —— 这是本仓契约面的裁量权，不属于一个下游 PM 席位。我这边对本 PR 的驱动到此为止。

要落它需要知道的三件事，集中在这里免得翻楼：

1. 运行时行为一个字没改，改的是描述它的散文加一份钉住不变式的测试。service-automation 93 文件 / 1099 测试全过，无既有断言移动。
2. packages/spec patch 级 changeset —— 更正随发布的 .d.ts 出去。service-automation 不升版，它只多了一个测试文件。
3. Docs Drift Check 的两行都查过了（见上方评论）：v15.mdx 那行正确、无需动作；顺着同一概念另外扫到 v17.mdx:2073 确有问题，已按只读守则立卡不编辑（v17 release notes: the #4366 entry states the svc:flow: audit label unqualified, and the #5494 entry later in the same page supersedes it — nothing connects them #14039）。本 PR 未触碰 content/docs/releases/。

与 #14044（#14010 半 B）不重叠：那张改 CLI/lint/runtime，本张只改 spec 契约散文与一个新测试。

---

Generated by Claude Code

[hotlong]

Fixes#14011

A prose-only correction. The shipped runtime behaviour is right and is untouched — the sentence describing it was not.

The stale sentence

packages/spec/src/contracts/automation-service.ts, documenting AutomationContext.flowName (published as dist/contracts/index.d.ts, line 3033 on 17.1.0 / line 3000 on this branch's 17.2.0 build):

a runAs:'system' run resolves no user, so resolveRunDataContext labels its data operations svc:flow:FLOWNAME on ExecutionContext.actor … instead of leaving the audit row unattributed

That reads as "system elevation costs you the operator in the audit trail."

What actually ships — re-verified against origin/main, not taken from the card

The card's reading was measured on the 17.1.0 artifact; every claim below was re-derived from the source in this checkout at 62a137b.

• packages/services/service-automation/src/runtime-identity.ts → resolveRunDataContext, runAs:'system' branch: { isSystem: true, actor: 'svc:flow:' + flowName, ...(context.userId ? { userId: context.userId } : {}), ...(context.tenantId ? { tenantId } : {}), positions: [], permissions: [] }. The operator is carried through unchanged (Automation create_record under runAs:'system' inserts rows with owner_id/organization_id/created_by all NULL — records born untouchable even by admin #5494) — the comment on that line says so in as many words: "elevation is not anonymity … isSystem alone decides authorization, while the user drives the platform's attribution stamps."
• packages/objectql/src/plugin.ts → sys_stamp_audit_insert / sys_stamp_audit_update stamp created_by / updated_by under if (session?.userId). There is no isSystem test anywhere on that path.
• packages/plugins/plugin-audit/src/audit-writers.ts → writeAudit computes userId = sess.userId ?? provenance.attributedUserId and actorLabel = userId ?? sess.actor. The svc:flow: label is the fallback, in that order, with no isSystem gate.

So the svc:flow: labelling the sentence described is real — but it is the user-less case (a schedule, or a runAs:'system' flow fired by a write that itself carried no user). The sentence generalised it to every runAs:'system' run.

What changed

1. The prose (packages/spec/src/contracts/automation-service.ts). The flowName JSDoc now states what is true of both cases: elevation decides AUTHORIZATION and leaves ATTRIBUTION alone; the svc:flow: actor label is the fallback a genuinely user-less run lands on, where ADR-0118 D1 keeps the user column null rather than inventing a sentinel.

2. A sweep for the same wrong concept. Searched packages/spec/src, every package's JSDoc, and content/docs/ for the family — resolves no user, unattributed, user-less, Unknown user, elevation/anonymity, and every prose mention of runAs: 'system' and svc:flow:. Exactly one site carried the wrong generalisation, the one fixed here. Everything else that mentions a user-less run is already scoped to the genuinely user-less case and was deliberately left alone (for instance content/docs/permissions/system-context.mdx line 200, "a user-less system write stamps nothing", and service-automation/src/engine.ts line 3436, "for runs that resolve no user" — both correct as written).

3. A line between the prose and the code that rings.packages/services/service-automation/src/runas-attribution-contract.test.ts asserts the invariant the prose now states, at the end of the chain — the session envelope the audit writers actually read — rather than at resolveRunDataContext's return shape, which builtin/crud-runas.test.ts already pins:

• an elevated, user-triggered run updates a row created by a different user, and updated_by moves to the triggering operator — the same value the identical write produces on the plain user path, with created_by left on the creator;
• a genuinely user-less run (schedule shape) creates a row whose user column stays NULL, and whose hook-visible session.actor is svc:flow:night_sweep.

If the code ever becomes what the old prose described, this file goes red instead of the next reader having to re-measure.

Reverse verification — and what it caught

Direction predicted before running: the operator limb goes RED, the user-less limb stays GREEN (it has no user to strip).

Ablation A — deleted the userId carry-through from resolveRunDataContext's system branch (i.e. made the code match the old prose). The first run reddened only the hook-session assertion; the updated_by column assertion passed under mutation, because the row had been seeded by the operator and already carried that value from its own insert. That assertion was measuring the insert, not the elevated update. Fixed by seeding the rows as a different user (usr_creator), so the column has to move for the assertion to pass. Re-ablated:

AssertionError: the elevated run must stamp the triggering operator: expected 'usr_creator' to be 'usr_operator'
Test Files 1 failed (1)
Tests 1 failed | 1 passed (2)

Ablation B — replaced the svc:flow: label with a constant, to check the second limb is live too:

AssertionError: the flow label names WHICH automation wrote (ADR-0014 D2): expected 'svc:ABLATED' to be 'svc:flow:elevated_touch'
AssertionError: the svc:flow: label is the fallback attribution: expected 'svc:ABLATED' to be 'svc:flow:night_sweep'
Test Files 1 failed (1)
Tests 2 failed (2)

Both ablations mutated a committed tree, proved the mutation on disk by grep counts plus a git hash-object comparison against the HEAD blob, carried an absolute-path trap … EXIT INT TERM, and restored to the byte-identical HEAD blob (git diff HEAD empty) before the next measurement. No rebuild step was needed for either: runtime-identity.ts is reached from builtin/crud-nodes.ts by a relative source import inside its own package, and this package's vitest config aliases only @objectstack/platform-objects — nothing routes its own modules through exports/dist.

Verification

All readings below are from aca37be, the branch head; the gate union was run after the final commit.

Check	Result
@objectstack/service-automation full suite	93 files / 1099 tests passed — no existing behaviour assertion moved
@objectstack/spec full suite	447 files / 11991 tests passed
@objectstack/spectsc --noEmit	0 errors
@objectstack/service-automationtsc --noEmit	exactly the 3 ledgered TS2341 in nested-region-parity.test.ts; 0 from the new file, and --listFiles confirms the new test file is in that program
pnpm lint (repo-wide eslint . --no-inline-config)	exit 0, no findings
Derived gate family (scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack --commands)	48 commands, 45 green

The three non-green results are all exit 3 / PREREQUISITE NOT MET — nothing measured, not findings:

• check:type-check-debt and check:dual-build-cjs-loads and scripts/check-dev-prereqs.mjs all refuse without a fully built workspace closure. CI builds it before those steps, exactly as lint.yml does. The substance the ratchet guards was measured directly instead, in the tsc --noEmit row above: the new test file is in the program and contributes zero errors, so the @objectstack/service-automation entry (errors: 3) does not move.
• scripts/check-test-completeness.mjs (exit 3) needs a saved turbo run test log it cannot produce itself, and scripts/pm/check-half-states.mjs (exit 3) needs repo-scoped egress this container does not have. Both declare that exit as NOT MEASURED.

packages/spec was rebuilt after the edit, and the corrected sentence is present in dist/contracts/index.d.ts (1 occurrence) with the stale one gone (0 occurrences).

Notes for the reviewer

• Left draft deliberately, and no domain:* label set: this was dispatched by the downstream steedos-labs/hotcrm-heimao PM seat under a direct maintainer instruction, not by this repo's spec lane. The spec seat or the maintainer lands it.
• .changeset/automation-context-flowname-attribution-prose.md bumps @objectstack/specpatch — the correction ships in the published .d.ts. @objectstack/service-automation gets no bump: its only change is a new test file.
• No overlap with A hook cannot elevate, so a hook-written computed column cannot be protected by field-level editable: false — the guard and the writer are the same door #14010, which adds runAs to HookSchema and changes runtime. HookSchema is untouched here, and nothing in this prose forward-announces a capability that has not landed.

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

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

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

• content/docs/releases/v15.mdx(via AutomationContext (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

• 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 — 128 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 0d80862366f5181b5db75c5ba103c69db98df181 → packageMentionDocs.

Which tree this was computed on

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

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

[hotlong]

Docs Drift Check 的两行都查过了，结论分开：一行是误报，一行是真的，已按守则立卡而非在此编辑。 本 PR 未触碰 content/docs/releases/，也不会去触碰。

它列的页	结论
content/docs/releases/v15.mdx:863	正确，无需动作。 原文是「Flow-type actions now receive the caller's identity as a real AutomationContext（runAs: 'user' flows evaluate RLS as the caller）」—— 讲的是 runAs: 'user'，本身成立。它被列出只因为点名了 AutomationContext 这个符号，正是该 bot 宣称的 precision-first 行为在正常工作。
（bot 未列，我顺着同一个概念扫出来的）content/docs/releases/v17.mdx:2073	真的有问题，已立 #14039。

那条真的

v17.mdx:2072-2073（#4366）：

…and a runAs: 'system' flow's writes are audited as svc:flow:<flowName> instead of "Unknown user"

无限定，读起来就是所有 system 提权运行的通则 —— 也就是本 PR 正在契约散文里消灭的那个错概念。

而 同一个发布页 的 v17.mdx:2860-2861 是 #5494：

runAs: 'system'create_record stamps all three ADR-0118 columns — organization, owner and creator are non-NULL.

两条各自都不假（一条讲 actor 标签、一条讲落库的三列），但并排读，靠前那条在靠后那条之前约 800 行，中间没有任何东西把它们连起来。front-to-back 读 v17 的人会先遇到无限定版本。

⛔ 不建议直接改写 #4366 那条 —— 那会篡改它当时确实交付的东西。#14039 里给了两个保持记录诚实的选项（加限定+指引 / 依赖本 PR 修好的契约散文），并说明发布说明政策是发布流程的事，不是下游报告人的，所以我没有提 PR。

关于 dev 的扫描范围

派发词明令禁止编辑 content/docs/releases/，dev 遵守了。它的同族措辞扫描覆盖了 packages/spec/src、各包 JSDoc 与 content/docs/，报「exactly one site carried the wrong generalisation」。那个读数对本 PR 可改的范围是准的 —— v17 那条落在只读区，本来就不该出现在一个可改清单里。这不是漏扫，是边界。

---

Generated by Claude Code

[hotlong]

CI 全绿，交接给 spec 席位。 head aca37be 上 10 个工作流全部 success，含最慢的两条（Lint & Type Check 01:03、CI 01:10）。无冲突，无评审意见待处理。

保持 draft，我不转 ready 也不合 —— 这是本仓契约面的裁量权，不属于一个下游 PM 席位。我这边对本 PR 的驱动到此为止。

要落它需要知道的三件事，集中在这里免得翻楼：

1. 运行时行为一个字没改，改的是描述它的散文加一份钉住不变式的测试。service-automation 93 文件 / 1099 测试全过，无既有断言移动。
2. packages/spec patch 级 changeset —— 更正随发布的 .d.ts 出去。service-automation 不升版，它只多了一个测试文件。
3. Docs Drift Check 的两行都查过了（见上方评论）：v15.mdx 那行正确、无需动作；顺着同一概念另外扫到 v17.mdx:2073 确有问题，已按只读守则立卡不编辑（v17 release notes: the #4366 entry states the svc:flow: audit label unqualified, and the #5494 entry later in the same page supersedes it — nothing connects them #14039）。本 PR 未触碰 content/docs/releases/。

与 #14044（#14010 半 B）不重叠：那张改 CLI/lint/runtime，本张只改 spec 契约散文与一个新测试。

---

Generated by Claude Code

[hotlong]

Fixes#14011

A prose-only correction. The shipped runtime behaviour is right and is untouched — the sentence describing it was not.

The stale sentence

packages/spec/src/contracts/automation-service.ts, documenting AutomationContext.flowName (published as dist/contracts/index.d.ts, line 3033 on 17.1.0 / line 3000 on this branch's 17.2.0 build):

a runAs:'system' run resolves no user, so resolveRunDataContext labels its data operations svc:flow:FLOWNAME on ExecutionContext.actor … instead of leaving the audit row unattributed

That reads as "system elevation costs you the operator in the audit trail."

What actually ships — re-verified against origin/main, not taken from the card

The card's reading was measured on the 17.1.0 artifact; every claim below was re-derived from the source in this checkout at 62a137b.

• packages/services/service-automation/src/runtime-identity.ts → resolveRunDataContext, runAs:'system' branch: { isSystem: true, actor: 'svc:flow:' + flowName, ...(context.userId ? { userId: context.userId } : {}), ...(context.tenantId ? { tenantId } : {}), positions: [], permissions: [] }. The operator is carried through unchanged (Automation create_record under runAs:'system' inserts rows with owner_id/organization_id/created_by all NULL — records born untouchable even by admin #5494) — the comment on that line says so in as many words: "elevation is not anonymity … isSystem alone decides authorization, while the user drives the platform's attribution stamps."
• packages/objectql/src/plugin.ts → sys_stamp_audit_insert / sys_stamp_audit_update stamp created_by / updated_by under if (session?.userId). There is no isSystem test anywhere on that path.
• packages/plugins/plugin-audit/src/audit-writers.ts → writeAudit computes userId = sess.userId ?? provenance.attributedUserId and actorLabel = userId ?? sess.actor. The svc:flow: label is the fallback, in that order, with no isSystem gate.

So the svc:flow: labelling the sentence described is real — but it is the user-less case (a schedule, or a runAs:'system' flow fired by a write that itself carried no user). The sentence generalised it to every runAs:'system' run.

What changed

1. The prose (packages/spec/src/contracts/automation-service.ts). The flowName JSDoc now states what is true of both cases: elevation decides AUTHORIZATION and leaves ATTRIBUTION alone; the svc:flow: actor label is the fallback a genuinely user-less run lands on, where ADR-0118 D1 keeps the user column null rather than inventing a sentinel.

2. A sweep for the same wrong concept. Searched packages/spec/src, every package's JSDoc, and content/docs/ for the family — resolves no user, unattributed, user-less, Unknown user, elevation/anonymity, and every prose mention of runAs: 'system' and svc:flow:. Exactly one site carried the wrong generalisation, the one fixed here. Everything else that mentions a user-less run is already scoped to the genuinely user-less case and was deliberately left alone (for instance content/docs/permissions/system-context.mdx line 200, "a user-less system write stamps nothing", and service-automation/src/engine.ts line 3436, "for runs that resolve no user" — both correct as written).

3. A line between the prose and the code that rings.packages/services/service-automation/src/runas-attribution-contract.test.ts asserts the invariant the prose now states, at the end of the chain — the session envelope the audit writers actually read — rather than at resolveRunDataContext's return shape, which builtin/crud-runas.test.ts already pins:

• an elevated, user-triggered run updates a row created by a different user, and updated_by moves to the triggering operator — the same value the identical write produces on the plain user path, with created_by left on the creator;
• a genuinely user-less run (schedule shape) creates a row whose user column stays NULL, and whose hook-visible session.actor is svc:flow:night_sweep.

If the code ever becomes what the old prose described, this file goes red instead of the next reader having to re-measure.

Reverse verification — and what it caught

Direction predicted before running: the operator limb goes RED, the user-less limb stays GREEN (it has no user to strip).

Ablation A — deleted the userId carry-through from resolveRunDataContext's system branch (i.e. made the code match the old prose). The first run reddened only the hook-session assertion; the updated_by column assertion passed under mutation, because the row had been seeded by the operator and already carried that value from its own insert. That assertion was measuring the insert, not the elevated update. Fixed by seeding the rows as a different user (usr_creator), so the column has to move for the assertion to pass. Re-ablated:

AssertionError: the elevated run must stamp the triggering operator: expected 'usr_creator' to be 'usr_operator'
Test Files 1 failed (1)
Tests 1 failed | 1 passed (2)

Ablation B — replaced the svc:flow: label with a constant, to check the second limb is live too:

AssertionError: the flow label names WHICH automation wrote (ADR-0014 D2): expected 'svc:ABLATED' to be 'svc:flow:elevated_touch'
AssertionError: the svc:flow: label is the fallback attribution: expected 'svc:ABLATED' to be 'svc:flow:night_sweep'
Test Files 1 failed (1)
Tests 2 failed (2)

Both ablations mutated a committed tree, proved the mutation on disk by grep counts plus a git hash-object comparison against the HEAD blob, carried an absolute-path trap … EXIT INT TERM, and restored to the byte-identical HEAD blob (git diff HEAD empty) before the next measurement. No rebuild step was needed for either: runtime-identity.ts is reached from builtin/crud-nodes.ts by a relative source import inside its own package, and this package's vitest config aliases only @objectstack/platform-objects — nothing routes its own modules through exports/dist.

Verification

All readings below are from aca37be, the branch head; the gate union was run after the final commit.

Check	Result
@objectstack/service-automation full suite	93 files / 1099 tests passed — no existing behaviour assertion moved
@objectstack/spec full suite	447 files / 11991 tests passed
@objectstack/spectsc --noEmit	0 errors
@objectstack/service-automationtsc --noEmit	exactly the 3 ledgered TS2341 in nested-region-parity.test.ts; 0 from the new file, and --listFiles confirms the new test file is in that program
pnpm lint (repo-wide eslint . --no-inline-config)	exit 0, no findings
Derived gate family (scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack --commands)	48 commands, 45 green

The three non-green results are all exit 3 / PREREQUISITE NOT MET — nothing measured, not findings:

• check:type-check-debt and check:dual-build-cjs-loads and scripts/check-dev-prereqs.mjs all refuse without a fully built workspace closure. CI builds it before those steps, exactly as lint.yml does. The substance the ratchet guards was measured directly instead, in the tsc --noEmit row above: the new test file is in the program and contributes zero errors, so the @objectstack/service-automation entry (errors: 3) does not move.
• scripts/check-test-completeness.mjs (exit 3) needs a saved turbo run test log it cannot produce itself, and scripts/pm/check-half-states.mjs (exit 3) needs repo-scoped egress this container does not have. Both declare that exit as NOT MEASURED.

packages/spec was rebuilt after the edit, and the corrected sentence is present in dist/contracts/index.d.ts (1 occurrence) with the stale one gone (0 occurrences).

Notes for the reviewer

• Left draft deliberately, and no domain:* label set: this was dispatched by the downstream steedos-labs/hotcrm-heimao PM seat under a direct maintainer instruction, not by this repo's spec lane. The spec seat or the maintainer lands it.
• .changeset/automation-context-flowname-attribution-prose.md bumps @objectstack/specpatch — the correction ships in the published .d.ts. @objectstack/service-automation gets no bump: its only change is a new test file.
• No overlap with A hook cannot elevate, so a hook-written computed column cannot be protected by field-level editable: false — the guard and the writer are the same door #14010, which adds runAs to HookSchema and changes runtime. HookSchema is untouched here, and nothing in this prose forward-announces a capability that has not landed.

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

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

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

• content/docs/releases/v15.mdx(via AutomationContext (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

• 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 — 128 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 0d80862366f5181b5db75c5ba103c69db98df181 → packageMentionDocs.

Which tree this was computed on

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

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

[hotlong]

Docs Drift Check 的两行都查过了，结论分开：一行是误报，一行是真的，已按守则立卡而非在此编辑。 本 PR 未触碰 content/docs/releases/，也不会去触碰。

它列的页	结论
content/docs/releases/v15.mdx:863	正确，无需动作。 原文是「Flow-type actions now receive the caller's identity as a real AutomationContext（runAs: 'user' flows evaluate RLS as the caller）」—— 讲的是 runAs: 'user'，本身成立。它被列出只因为点名了 AutomationContext 这个符号，正是该 bot 宣称的 precision-first 行为在正常工作。
（bot 未列，我顺着同一个概念扫出来的）content/docs/releases/v17.mdx:2073	真的有问题，已立 #14039。

那条真的

v17.mdx:2072-2073（#4366）：

…and a runAs: 'system' flow's writes are audited as svc:flow:<flowName> instead of "Unknown user"

无限定，读起来就是所有 system 提权运行的通则 —— 也就是本 PR 正在契约散文里消灭的那个错概念。

而 同一个发布页 的 v17.mdx:2860-2861 是 #5494：

runAs: 'system'create_record stamps all three ADR-0118 columns — organization, owner and creator are non-NULL.

两条各自都不假（一条讲 actor 标签、一条讲落库的三列），但并排读，靠前那条在靠后那条之前约 800 行，中间没有任何东西把它们连起来。front-to-back 读 v17 的人会先遇到无限定版本。

⛔ 不建议直接改写 #4366 那条 —— 那会篡改它当时确实交付的东西。#14039 里给了两个保持记录诚实的选项（加限定+指引 / 依赖本 PR 修好的契约散文），并说明发布说明政策是发布流程的事，不是下游报告人的，所以我没有提 PR。

关于 dev 的扫描范围

派发词明令禁止编辑 content/docs/releases/，dev 遵守了。它的同族措辞扫描覆盖了 packages/spec/src、各包 JSDoc 与 content/docs/，报「exactly one site carried the wrong generalisation」。那个读数对本 PR 可改的范围是准的 —— v17 那条落在只读区，本来就不该出现在一个可改清单里。这不是漏扫，是边界。

---

Generated by Claude Code

[hotlong]

CI 全绿，交接给 spec 席位。 head aca37be 上 10 个工作流全部 success，含最慢的两条（Lint & Type Check 01:03、CI 01:10）。无冲突，无评审意见待处理。

保持 draft，我不转 ready 也不合 —— 这是本仓契约面的裁量权，不属于一个下游 PM 席位。我这边对本 PR 的驱动到此为止。

要落它需要知道的三件事，集中在这里免得翻楼：

1. 运行时行为一个字没改，改的是描述它的散文加一份钉住不变式的测试。service-automation 93 文件 / 1099 测试全过，无既有断言移动。
2. packages/spec patch 级 changeset —— 更正随发布的 .d.ts 出去。service-automation 不升版，它只多了一个测试文件。
3. Docs Drift Check 的两行都查过了（见上方评论）：v15.mdx 那行正确、无需动作；顺着同一概念另外扫到 v17.mdx:2073 确有问题，已按只读守则立卡不编辑（v17 release notes: the #4366 entry states the svc:flow: audit label unqualified, and the #5494 entry later in the same page supersedes it — nothing connects them #14039）。本 PR 未触碰 content/docs/releases/。

与 #14044（#14010 半 B）不重叠：那张改 CLI/lint/runtime，本张只改 spec 契约散文与一个新测试。

---

Generated by Claude Code

[hotlong]

Fixes#14011

A prose-only correction. The shipped runtime behaviour is right and is untouched — the sentence describing it was not.

The stale sentence

packages/spec/src/contracts/automation-service.ts, documenting AutomationContext.flowName (published as dist/contracts/index.d.ts, line 3033 on 17.1.0 / line 3000 on this branch's 17.2.0 build):

a runAs:'system' run resolves no user, so resolveRunDataContext labels its data operations svc:flow:FLOWNAME on ExecutionContext.actor … instead of leaving the audit row unattributed

That reads as "system elevation costs you the operator in the audit trail."

What actually ships — re-verified against origin/main, not taken from the card

The card's reading was measured on the 17.1.0 artifact; every claim below was re-derived from the source in this checkout at 62a137b.

• packages/services/service-automation/src/runtime-identity.ts → resolveRunDataContext, runAs:'system' branch: { isSystem: true, actor: 'svc:flow:' + flowName, ...(context.userId ? { userId: context.userId } : {}), ...(context.tenantId ? { tenantId } : {}), positions: [], permissions: [] }. The operator is carried through unchanged (Automation create_record under runAs:'system' inserts rows with owner_id/organization_id/created_by all NULL — records born untouchable even by admin #5494) — the comment on that line says so in as many words: "elevation is not anonymity … isSystem alone decides authorization, while the user drives the platform's attribution stamps."
• packages/objectql/src/plugin.ts → sys_stamp_audit_insert / sys_stamp_audit_update stamp created_by / updated_by under if (session?.userId). There is no isSystem test anywhere on that path.
• packages/plugins/plugin-audit/src/audit-writers.ts → writeAudit computes userId = sess.userId ?? provenance.attributedUserId and actorLabel = userId ?? sess.actor. The svc:flow: label is the fallback, in that order, with no isSystem gate.

So the svc:flow: labelling the sentence described is real — but it is the user-less case (a schedule, or a runAs:'system' flow fired by a write that itself carried no user). The sentence generalised it to every runAs:'system' run.

What changed

1. The prose (packages/spec/src/contracts/automation-service.ts). The flowName JSDoc now states what is true of both cases: elevation decides AUTHORIZATION and leaves ATTRIBUTION alone; the svc:flow: actor label is the fallback a genuinely user-less run lands on, where ADR-0118 D1 keeps the user column null rather than inventing a sentinel.

2. A sweep for the same wrong concept. Searched packages/spec/src, every package's JSDoc, and content/docs/ for the family — resolves no user, unattributed, user-less, Unknown user, elevation/anonymity, and every prose mention of runAs: 'system' and svc:flow:. Exactly one site carried the wrong generalisation, the one fixed here. Everything else that mentions a user-less run is already scoped to the genuinely user-less case and was deliberately left alone (for instance content/docs/permissions/system-context.mdx line 200, "a user-less system write stamps nothing", and service-automation/src/engine.ts line 3436, "for runs that resolve no user" — both correct as written).

3. A line between the prose and the code that rings.packages/services/service-automation/src/runas-attribution-contract.test.ts asserts the invariant the prose now states, at the end of the chain — the session envelope the audit writers actually read — rather than at resolveRunDataContext's return shape, which builtin/crud-runas.test.ts already pins:

• an elevated, user-triggered run updates a row created by a different user, and updated_by moves to the triggering operator — the same value the identical write produces on the plain user path, with created_by left on the creator;
• a genuinely user-less run (schedule shape) creates a row whose user column stays NULL, and whose hook-visible session.actor is svc:flow:night_sweep.

If the code ever becomes what the old prose described, this file goes red instead of the next reader having to re-measure.

Reverse verification — and what it caught

Direction predicted before running: the operator limb goes RED, the user-less limb stays GREEN (it has no user to strip).

Ablation A — deleted the userId carry-through from resolveRunDataContext's system branch (i.e. made the code match the old prose). The first run reddened only the hook-session assertion; the updated_by column assertion passed under mutation, because the row had been seeded by the operator and already carried that value from its own insert. That assertion was measuring the insert, not the elevated update. Fixed by seeding the rows as a different user (usr_creator), so the column has to move for the assertion to pass. Re-ablated:

AssertionError: the elevated run must stamp the triggering operator: expected 'usr_creator' to be 'usr_operator'
Test Files 1 failed (1)
Tests 1 failed | 1 passed (2)

Ablation B — replaced the svc:flow: label with a constant, to check the second limb is live too:

AssertionError: the flow label names WHICH automation wrote (ADR-0014 D2): expected 'svc:ABLATED' to be 'svc:flow:elevated_touch'
AssertionError: the svc:flow: label is the fallback attribution: expected 'svc:ABLATED' to be 'svc:flow:night_sweep'
Test Files 1 failed (1)
Tests 2 failed (2)

Both ablations mutated a committed tree, proved the mutation on disk by grep counts plus a git hash-object comparison against the HEAD blob, carried an absolute-path trap … EXIT INT TERM, and restored to the byte-identical HEAD blob (git diff HEAD empty) before the next measurement. No rebuild step was needed for either: runtime-identity.ts is reached from builtin/crud-nodes.ts by a relative source import inside its own package, and this package's vitest config aliases only @objectstack/platform-objects — nothing routes its own modules through exports/dist.

Verification

All readings below are from aca37be, the branch head; the gate union was run after the final commit.

Check	Result
@objectstack/service-automation full suite	93 files / 1099 tests passed — no existing behaviour assertion moved
@objectstack/spec full suite	447 files / 11991 tests passed
@objectstack/spectsc --noEmit	0 errors
@objectstack/service-automationtsc --noEmit	exactly the 3 ledgered TS2341 in nested-region-parity.test.ts; 0 from the new file, and --listFiles confirms the new test file is in that program
pnpm lint (repo-wide eslint . --no-inline-config)	exit 0, no findings
Derived gate family (scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack --commands)	48 commands, 45 green

The three non-green results are all exit 3 / PREREQUISITE NOT MET — nothing measured, not findings:

• check:type-check-debt and check:dual-build-cjs-loads and scripts/check-dev-prereqs.mjs all refuse without a fully built workspace closure. CI builds it before those steps, exactly as lint.yml does. The substance the ratchet guards was measured directly instead, in the tsc --noEmit row above: the new test file is in the program and contributes zero errors, so the @objectstack/service-automation entry (errors: 3) does not move.
• scripts/check-test-completeness.mjs (exit 3) needs a saved turbo run test log it cannot produce itself, and scripts/pm/check-half-states.mjs (exit 3) needs repo-scoped egress this container does not have. Both declare that exit as NOT MEASURED.

packages/spec was rebuilt after the edit, and the corrected sentence is present in dist/contracts/index.d.ts (1 occurrence) with the stale one gone (0 occurrences).

Notes for the reviewer

• Left draft deliberately, and no domain:* label set: this was dispatched by the downstream steedos-labs/hotcrm-heimao PM seat under a direct maintainer instruction, not by this repo's spec lane. The spec seat or the maintainer lands it.
• .changeset/automation-context-flowname-attribution-prose.md bumps @objectstack/specpatch — the correction ships in the published .d.ts. @objectstack/service-automation gets no bump: its only change is a new test file.
• No overlap with A hook cannot elevate, so a hook-written computed column cannot be protected by field-level editable: false — the guard and the writer are the same door #14010, which adds runAs to HookSchema and changes runtime. HookSchema is untouched here, and nothing in this prose forward-announces a capability that has not landed.

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

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

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

• content/docs/releases/v15.mdx(via AutomationContext (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

• 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 — 128 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 0d80862366f5181b5db75c5ba103c69db98df181 → packageMentionDocs.

Which tree this was computed on

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

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

[hotlong]

Docs Drift Check 的两行都查过了，结论分开：一行是误报，一行是真的，已按守则立卡而非在此编辑。 本 PR 未触碰 content/docs/releases/，也不会去触碰。

它列的页	结论
content/docs/releases/v15.mdx:863	正确，无需动作。 原文是「Flow-type actions now receive the caller's identity as a real AutomationContext（runAs: 'user' flows evaluate RLS as the caller）」—— 讲的是 runAs: 'user'，本身成立。它被列出只因为点名了 AutomationContext 这个符号，正是该 bot 宣称的 precision-first 行为在正常工作。
（bot 未列，我顺着同一个概念扫出来的）content/docs/releases/v17.mdx:2073	真的有问题，已立 #14039。

那条真的

v17.mdx:2072-2073（#4366）：

…and a runAs: 'system' flow's writes are audited as svc:flow:<flowName> instead of "Unknown user"

无限定，读起来就是所有 system 提权运行的通则 —— 也就是本 PR 正在契约散文里消灭的那个错概念。

而 同一个发布页 的 v17.mdx:2860-2861 是 #5494：

runAs: 'system'create_record stamps all three ADR-0118 columns — organization, owner and creator are non-NULL.

两条各自都不假（一条讲 actor 标签、一条讲落库的三列），但并排读，靠前那条在靠后那条之前约 800 行，中间没有任何东西把它们连起来。front-to-back 读 v17 的人会先遇到无限定版本。

⛔ 不建议直接改写 #4366 那条 —— 那会篡改它当时确实交付的东西。#14039 里给了两个保持记录诚实的选项（加限定+指引 / 依赖本 PR 修好的契约散文），并说明发布说明政策是发布流程的事，不是下游报告人的，所以我没有提 PR。

关于 dev 的扫描范围

派发词明令禁止编辑 content/docs/releases/，dev 遵守了。它的同族措辞扫描覆盖了 packages/spec/src、各包 JSDoc 与 content/docs/，报「exactly one site carried the wrong generalisation」。那个读数对本 PR 可改的范围是准的 —— v17 那条落在只读区，本来就不该出现在一个可改清单里。这不是漏扫，是边界。

---

Generated by Claude Code

[hotlong]

CI 全绿，交接给 spec 席位。 head aca37be 上 10 个工作流全部 success，含最慢的两条（Lint & Type Check 01:03、CI 01:10）。无冲突，无评审意见待处理。

保持 draft，我不转 ready 也不合 —— 这是本仓契约面的裁量权，不属于一个下游 PM 席位。我这边对本 PR 的驱动到此为止。

要落它需要知道的三件事，集中在这里免得翻楼：

1. 运行时行为一个字没改，改的是描述它的散文加一份钉住不变式的测试。service-automation 93 文件 / 1099 测试全过，无既有断言移动。
2. packages/spec patch 级 changeset —— 更正随发布的 .d.ts 出去。service-automation 不升版，它只多了一个测试文件。
3. Docs Drift Check 的两行都查过了（见上方评论）：v15.mdx 那行正确、无需动作；顺着同一概念另外扫到 v17.mdx:2073 确有问题，已按只读守则立卡不编辑（v17 release notes: the #4366 entry states the svc:flow: audit label unqualified, and the #5494 entry later in the same page supersedes it — nothing connects them #14039）。本 PR 未触碰 content/docs/releases/。

与 #14044（#14010 半 B）不重叠：那张改 CLI/lint/runtime，本张只改 spec 契约散文与一个新测试。

---

Generated by Claude Code

[hotlong]

Fixes#14011

A prose-only correction. The shipped runtime behaviour is right and is untouched — the sentence describing it was not.

The stale sentence

packages/spec/src/contracts/automation-service.ts, documenting AutomationContext.flowName (published as dist/contracts/index.d.ts, line 3033 on 17.1.0 / line 3000 on this branch's 17.2.0 build):

a runAs:'system' run resolves no user, so resolveRunDataContext labels its data operations svc:flow:FLOWNAME on ExecutionContext.actor … instead of leaving the audit row unattributed

That reads as "system elevation costs you the operator in the audit trail."

What actually ships — re-verified against origin/main, not taken from the card

The card's reading was measured on the 17.1.0 artifact; every claim below was re-derived from the source in this checkout at 62a137b.

• packages/services/service-automation/src/runtime-identity.ts → resolveRunDataContext, runAs:'system' branch: { isSystem: true, actor: 'svc:flow:' + flowName, ...(context.userId ? { userId: context.userId } : {}), ...(context.tenantId ? { tenantId } : {}), positions: [], permissions: [] }. The operator is carried through unchanged (Automation create_record under runAs:'system' inserts rows with owner_id/organization_id/created_by all NULL — records born untouchable even by admin #5494) — the comment on that line says so in as many words: "elevation is not anonymity … isSystem alone decides authorization, while the user drives the platform's attribution stamps."
• packages/objectql/src/plugin.ts → sys_stamp_audit_insert / sys_stamp_audit_update stamp created_by / updated_by under if (session?.userId). There is no isSystem test anywhere on that path.
• packages/plugins/plugin-audit/src/audit-writers.ts → writeAudit computes userId = sess.userId ?? provenance.attributedUserId and actorLabel = userId ?? sess.actor. The svc:flow: label is the fallback, in that order, with no isSystem gate.

So the svc:flow: labelling the sentence described is real — but it is the user-less case (a schedule, or a runAs:'system' flow fired by a write that itself carried no user). The sentence generalised it to every runAs:'system' run.

What changed

1. The prose (packages/spec/src/contracts/automation-service.ts). The flowName JSDoc now states what is true of both cases: elevation decides AUTHORIZATION and leaves ATTRIBUTION alone; the svc:flow: actor label is the fallback a genuinely user-less run lands on, where ADR-0118 D1 keeps the user column null rather than inventing a sentinel.

2. A sweep for the same wrong concept. Searched packages/spec/src, every package's JSDoc, and content/docs/ for the family — resolves no user, unattributed, user-less, Unknown user, elevation/anonymity, and every prose mention of runAs: 'system' and svc:flow:. Exactly one site carried the wrong generalisation, the one fixed here. Everything else that mentions a user-less run is already scoped to the genuinely user-less case and was deliberately left alone (for instance content/docs/permissions/system-context.mdx line 200, "a user-less system write stamps nothing", and service-automation/src/engine.ts line 3436, "for runs that resolve no user" — both correct as written).

3. A line between the prose and the code that rings.packages/services/service-automation/src/runas-attribution-contract.test.ts asserts the invariant the prose now states, at the end of the chain — the session envelope the audit writers actually read — rather than at resolveRunDataContext's return shape, which builtin/crud-runas.test.ts already pins:

• an elevated, user-triggered run updates a row created by a different user, and updated_by moves to the triggering operator — the same value the identical write produces on the plain user path, with created_by left on the creator;
• a genuinely user-less run (schedule shape) creates a row whose user column stays NULL, and whose hook-visible session.actor is svc:flow:night_sweep.

If the code ever becomes what the old prose described, this file goes red instead of the next reader having to re-measure.

Reverse verification — and what it caught

Direction predicted before running: the operator limb goes RED, the user-less limb stays GREEN (it has no user to strip).

Ablation A — deleted the userId carry-through from resolveRunDataContext's system branch (i.e. made the code match the old prose). The first run reddened only the hook-session assertion; the updated_by column assertion passed under mutation, because the row had been seeded by the operator and already carried that value from its own insert. That assertion was measuring the insert, not the elevated update. Fixed by seeding the rows as a different user (usr_creator), so the column has to move for the assertion to pass. Re-ablated:

AssertionError: the elevated run must stamp the triggering operator: expected 'usr_creator' to be 'usr_operator'
Test Files 1 failed (1)
Tests 1 failed | 1 passed (2)

Ablation B — replaced the svc:flow: label with a constant, to check the second limb is live too:

AssertionError: the flow label names WHICH automation wrote (ADR-0014 D2): expected 'svc:ABLATED' to be 'svc:flow:elevated_touch'
AssertionError: the svc:flow: label is the fallback attribution: expected 'svc:ABLATED' to be 'svc:flow:night_sweep'
Test Files 1 failed (1)
Tests 2 failed (2)

Both ablations mutated a committed tree, proved the mutation on disk by grep counts plus a git hash-object comparison against the HEAD blob, carried an absolute-path trap … EXIT INT TERM, and restored to the byte-identical HEAD blob (git diff HEAD empty) before the next measurement. No rebuild step was needed for either: runtime-identity.ts is reached from builtin/crud-nodes.ts by a relative source import inside its own package, and this package's vitest config aliases only @objectstack/platform-objects — nothing routes its own modules through exports/dist.

Verification

All readings below are from aca37be, the branch head; the gate union was run after the final commit.

Check	Result
@objectstack/service-automation full suite	93 files / 1099 tests passed — no existing behaviour assertion moved
@objectstack/spec full suite	447 files / 11991 tests passed
@objectstack/spectsc --noEmit	0 errors
@objectstack/service-automationtsc --noEmit	exactly the 3 ledgered TS2341 in nested-region-parity.test.ts; 0 from the new file, and --listFiles confirms the new test file is in that program
pnpm lint (repo-wide eslint . --no-inline-config)	exit 0, no findings
Derived gate family (scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack --commands)	48 commands, 45 green

The three non-green results are all exit 3 / PREREQUISITE NOT MET — nothing measured, not findings:

• check:type-check-debt and check:dual-build-cjs-loads and scripts/check-dev-prereqs.mjs all refuse without a fully built workspace closure. CI builds it before those steps, exactly as lint.yml does. The substance the ratchet guards was measured directly instead, in the tsc --noEmit row above: the new test file is in the program and contributes zero errors, so the @objectstack/service-automation entry (errors: 3) does not move.
• scripts/check-test-completeness.mjs (exit 3) needs a saved turbo run test log it cannot produce itself, and scripts/pm/check-half-states.mjs (exit 3) needs repo-scoped egress this container does not have. Both declare that exit as NOT MEASURED.

packages/spec was rebuilt after the edit, and the corrected sentence is present in dist/contracts/index.d.ts (1 occurrence) with the stale one gone (0 occurrences).

Notes for the reviewer

• Left draft deliberately, and no domain:* label set: this was dispatched by the downstream steedos-labs/hotcrm-heimao PM seat under a direct maintainer instruction, not by this repo's spec lane. The spec seat or the maintainer lands it.
• .changeset/automation-context-flowname-attribution-prose.md bumps @objectstack/specpatch — the correction ships in the published .d.ts. @objectstack/service-automation gets no bump: its only change is a new test file.
• No overlap with A hook cannot elevate, so a hook-written computed column cannot be protected by field-level editable: false — the guard and the writer are the same door #14010, which adds runAs to HookSchema and changes runtime. HookSchema is untouched here, and nothing in this prose forward-announces a capability that has not landed.

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

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

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

• content/docs/releases/v15.mdx(via AutomationContext (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

• 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 — 128 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 0d80862366f5181b5db75c5ba103c69db98df181 → packageMentionDocs.

Which tree this was computed on

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

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

[hotlong]

Docs Drift Check 的两行都查过了，结论分开：一行是误报，一行是真的，已按守则立卡而非在此编辑。 本 PR 未触碰 content/docs/releases/，也不会去触碰。

它列的页	结论
content/docs/releases/v15.mdx:863	正确，无需动作。 原文是「Flow-type actions now receive the caller's identity as a real AutomationContext（runAs: 'user' flows evaluate RLS as the caller）」—— 讲的是 runAs: 'user'，本身成立。它被列出只因为点名了 AutomationContext 这个符号，正是该 bot 宣称的 precision-first 行为在正常工作。
（bot 未列，我顺着同一个概念扫出来的）content/docs/releases/v17.mdx:2073	真的有问题，已立 #14039。

那条真的

v17.mdx:2072-2073（#4366）：

…and a runAs: 'system' flow's writes are audited as svc:flow:<flowName> instead of "Unknown user"

无限定，读起来就是所有 system 提权运行的通则 —— 也就是本 PR 正在契约散文里消灭的那个错概念。

而 同一个发布页 的 v17.mdx:2860-2861 是 #5494：

runAs: 'system'create_record stamps all three ADR-0118 columns — organization, owner and creator are non-NULL.

两条各自都不假（一条讲 actor 标签、一条讲落库的三列），但并排读，靠前那条在靠后那条之前约 800 行，中间没有任何东西把它们连起来。front-to-back 读 v17 的人会先遇到无限定版本。

⛔ 不建议直接改写 #4366 那条 —— 那会篡改它当时确实交付的东西。#14039 里给了两个保持记录诚实的选项（加限定+指引 / 依赖本 PR 修好的契约散文），并说明发布说明政策是发布流程的事，不是下游报告人的，所以我没有提 PR。

关于 dev 的扫描范围

派发词明令禁止编辑 content/docs/releases/，dev 遵守了。它的同族措辞扫描覆盖了 packages/spec/src、各包 JSDoc 与 content/docs/，报「exactly one site carried the wrong generalisation」。那个读数对本 PR 可改的范围是准的 —— v17 那条落在只读区，本来就不该出现在一个可改清单里。这不是漏扫，是边界。

---

Generated by Claude Code

[hotlong]

CI 全绿，交接给 spec 席位。 head aca37be 上 10 个工作流全部 success，含最慢的两条（Lint & Type Check 01:03、CI 01:10）。无冲突，无评审意见待处理。

保持 draft，我不转 ready 也不合 —— 这是本仓契约面的裁量权，不属于一个下游 PM 席位。我这边对本 PR 的驱动到此为止。

要落它需要知道的三件事，集中在这里免得翻楼：

1. 运行时行为一个字没改，改的是描述它的散文加一份钉住不变式的测试。service-automation 93 文件 / 1099 测试全过，无既有断言移动。
2. packages/spec patch 级 changeset —— 更正随发布的 .d.ts 出去。service-automation 不升版，它只多了一个测试文件。
3. Docs Drift Check 的两行都查过了（见上方评论）：v15.mdx 那行正确、无需动作；顺着同一概念另外扫到 v17.mdx:2073 确有问题，已按只读守则立卡不编辑（v17 release notes: the #4366 entry states the svc:flow: audit label unqualified, and the #5494 entry later in the same page supersedes it — nothing connects them #14039）。本 PR 未触碰 content/docs/releases/。

与 #14044（#14010 半 B）不重叠：那张改 CLI/lint/runtime，本张只改 spec 契约散文与一个新测试。

---

Generated by Claude Code