Blocked-by: #15168
content/docs/ui/actions.mdx, in the Flow actions paragraph under "Authorization inside an action", carries the same honesty clause the contract's TSDoc carried:
On the flow face the key is declared but not yet populated: the flow dispatcher does not pass the signal into the run's context yet, so until that lands a flow run never sees it and a guard on it is inert (never true), never wrong.
#15168 lands the runtime half — dispatchFlowAction spreads the producer's signal into the flow's AutomationContext on both doors (REST POST /api/v1/actions/... and the MCP run_action bridge). Its point 4 retires the equivalent sentence on the contract (packages/spec/src/contracts/automation-service.ts) and flips the pin that named it. The docs sentence is the same statement in a second place, and #15168's file surface was enumerated as the two runtime files, their pins and that one spec file — so this paragraph was deliberately out of that card's bounds and stays behind.
Why this is a defect and not a nicety. The direction is the inverted form of the Prime Directive #10 corollary: not a doc advertising a capability the runtime does not deliver, but a doc denying one it now does. An author who reads it will not write the guard — the exact guard the whole two-card sequence exists to make possible — and nothing red will ever tell them otherwise. pnpm check:affected-docs and check:drift-comment both run green over this change (measured on the #15168 branch), so no gate carries this.
The fix is mechanical, four lines: replace the "declared but not yet populated" clause with the populated statement, matching the contract's retired-sentence replacement, and leave the surrounding runAs: 'user' / runAs: 'system' prose and the ctx.record.id table untouched — nothing else in that section changes. The wording that landed on the contract for reference:
Populated on the flow face since #15168: dispatchFlowAction takes the producer's load outcome and spreads the signal into the context it hands automation.execute, on both doors, so a flow run receives this key exactly when a handler would.
content/docs/automation/hook-bodies.mdx needs no change — its one mention is scoped to the action-body face and stays true.
Sequencing: this must not land before #15168 does, or the docs would advertise a capability the runtime has not shipped — the failure mode in the original direction.
Blocked-by: #15168
content/docs/ui/actions.mdx, in the Flow actions paragraph under "Authorization inside an action", carries the same honesty clause the contract's TSDoc carried:#15168 lands the runtime half —
dispatchFlowActionspreads the producer's signal into the flow'sAutomationContexton both doors (RESTPOST /api/v1/actions/...and the MCPrun_actionbridge). Its point 4 retires the equivalent sentence on the contract (packages/spec/src/contracts/automation-service.ts) and flips the pin that named it. The docs sentence is the same statement in a second place, and #15168's file surface was enumerated as the two runtime files, their pins and that one spec file — so this paragraph was deliberately out of that card's bounds and stays behind.Why this is a defect and not a nicety. The direction is the inverted form of the Prime Directive #10 corollary: not a doc advertising a capability the runtime does not deliver, but a doc denying one it now does. An author who reads it will not write the guard — the exact guard the whole two-card sequence exists to make possible — and nothing red will ever tell them otherwise.
pnpm check:affected-docsandcheck:drift-commentboth run green over this change (measured on the #15168 branch), so no gate carries this.The fix is mechanical, four lines: replace the "declared but not yet populated" clause with the populated statement, matching the contract's retired-sentence replacement, and leave the surrounding
runAs: 'user'/runAs: 'system'prose and thectx.record.idtable untouched — nothing else in that section changes. The wording that landed on the contract for reference:content/docs/automation/hook-bodies.mdxneeds no change — its one mention is scoped to the action-body face and stays true.Sequencing: this must not land before #15168 does, or the docs would advertise a capability the runtime has not shipped — the failure mode in the original direction.