Observation recorded while implementing #9446 (PR #9584). No behaviour is wrong and no gate is red — this is a provenance note that is now incomplete.
What is stale
packages/spec/src/api/error-code-ledger.zod.ts, under @objectstack/runtime, describes both codes as the trigger door's:
FLOW_DISABLED — "the trigger door refused to dispatch a flow that is switched off — respondToFlowTrigger (domains/automation.ts) reads the engine's own AutomationResult.code and answers 409. Registered HERE and not under the engine's package for the same reason FLOW_FAILED is: this door, not the producer, is where the wire vocabulary is named."FLOW_NO_START_NODE — "Answered 422 by respondToFlowTrigger."
Since #9446, POST /api/v1/actions/:object/:action emits both as well, through dispatchFlowAction (packages/runtime/src/action-execution.ts) and errorFromThrown. The registration itself is unaffected: both doors live in @objectstack/runtime, so the package attribution is still right and no code is unregistered — pnpm check:dispatcher-error-vocabulary is green.
Why it is worth a note anyway
The ledger's own convention is to record a second emitter rather than let the first one's name stand for the rule. PACKAGE_DELETE_PARTIAL in the same file does exactly that ("Second EMITTER of the code ... the two doors now state the same failure the same way. Provenance, not identity"), and #7504 was filed for the case where the attribution really was wrong. A note that names one door reads, to the next author, as "this code belongs to that route" — which is the reading #9446 just ruled against.
FLOW_FAILED's note in the same block already names both doors and needs no change.
Scope
packages/spec is the spec seat's; the #9446 dev deliberately did not edit the ledger, since nothing needed widening and a comment-only touch to a spec contract fragment is not a dev-lane call. One-paragraph fix, no code, no gate movement.
Generated by Claude Code
Observation recorded while implementing #9446 (PR #9584). No behaviour is wrong and no gate is red — this is a provenance note that is now incomplete.
What is stale
packages/spec/src/api/error-code-ledger.zod.ts, under@objectstack/runtime, describes both codes as the trigger door's:FLOW_DISABLED— "the trigger door refused to dispatch a flow that is switched off —respondToFlowTrigger(domains/automation.ts) reads the engine's ownAutomationResult.codeand answers 409. Registered HERE and not under the engine's package for the same reason FLOW_FAILED is: this door, not the producer, is where the wire vocabulary is named."FLOW_NO_START_NODE— "Answered 422 byrespondToFlowTrigger."Since #9446,
POST /api/v1/actions/:object/:actionemits both as well, throughdispatchFlowAction(packages/runtime/src/action-execution.ts) anderrorFromThrown. The registration itself is unaffected: both doors live in@objectstack/runtime, so the package attribution is still right and no code is unregistered —pnpm check:dispatcher-error-vocabularyis green.Why it is worth a note anyway
The ledger's own convention is to record a second emitter rather than let the first one's name stand for the rule.
PACKAGE_DELETE_PARTIALin the same file does exactly that ("Second EMITTER of the code ... the two doors now state the same failure the same way. Provenance, not identity"), and #7504 was filed for the case where the attribution really was wrong. A note that names one door reads, to the next author, as "this code belongs to that route" — which is the reading #9446 just ruled against.FLOW_FAILED's note in the same block already names both doors and needs no change.Scope
packages/specis the spec seat's; the #9446 dev deliberately did not edit the ledger, since nothing needed widening and a comment-only touch to a spec contract fragment is not a dev-lane call. One-paragraph fix, no code, no gate movement.Generated by Claude Code