Context
Originally reported by codebeast (via Kurt) as "flow_quality / flow_governance return {hash} echo only" — sibling to Stackbilt-dev/tarotscript#199. That specific bug was an envelope-unwrap issue in the gateway (gateway was reading receipt fields off the root; worker nests them under .receipt.*). Fixed + regression tests added alongside this issue's filing.
This follow-up captures the larger design decision Codebeast raised: given that flow_* is being sunset in favor of scaffold_*, should we delete the flow_* ops from the MCP manifest entirely, or keep them as thin wrappers?
Current state (post-fix)
All five flow_* ops are functional:
flow_create — async scaffold run, returns receipt hash
flow_status — {verified, createdAt, hash}
flow_summary — full envelope
flow_quality — {governance, quality: {confidence, shadow_density, position_count}, hash}
flow_governance — same as flow_quality (same backing receipt field)
flow_quality and flow_governance still have overlapping semantics. If we're keeping both, we should probably split the fields cleanly: governance → just {governance, hash}, quality → just {quality, hash}. If we're deleting, that split is wasted work.
Proposed options
- Delete
flow_* from the manifest — callers migrate to scaffold_* (or the forthcoming scaffold_quality / scaffold_governance if they exist / are planned). Cleanest if the sunset is real and near.
- Keep
flow_* as wrappers — but split the quality / governance semantics so they're not clones.
- Keep
flow_* marked deprecated — add a deprecated: true flag to the tool descriptions and a deprecation_target: 'scaffold_*' hint. Gives downstream a migration window.
Acceptance
Cross-repo context
- Fix for the immediate echo bug: this repo,
src/gateway.ts envelope unwrap
- Sibling silent-coercion bug:
Stackbilt-dev/tarotscript#199 (fixed)
- Original triage:
Stackbilt-dev/stackbilt-engine#23 (closed — wrong repo)
Context
Originally reported by codebeast (via Kurt) as "flow_quality / flow_governance return {hash} echo only" — sibling to
Stackbilt-dev/tarotscript#199. That specific bug was an envelope-unwrap issue in the gateway (gateway was reading receipt fields off the root; worker nests them under.receipt.*). Fixed + regression tests added alongside this issue's filing.This follow-up captures the larger design decision Codebeast raised: given that
flow_*is being sunset in favor ofscaffold_*, should we delete theflow_*ops from the MCP manifest entirely, or keep them as thin wrappers?Current state (post-fix)
All five
flow_*ops are functional:flow_create— async scaffold run, returns receipt hashflow_status—{verified, createdAt, hash}flow_summary— full envelopeflow_quality—{governance, quality: {confidence, shadow_density, position_count}, hash}flow_governance— same as flow_quality (same backing receipt field)flow_qualityandflow_governancestill have overlapping semantics. If we're keeping both, we should probably split the fields cleanly: governance → just{governance, hash}, quality → just{quality, hash}. If we're deleting, that split is wasted work.Proposed options
flow_*from the manifest — callers migrate toscaffold_*(or the forthcomingscaffold_quality/scaffold_governanceif they exist / are planned). Cleanest if the sunset is real and near.flow_*as wrappers — but split thequality/governancesemantics so they're not clones.flow_*marked deprecated — add adeprecated: trueflag to the tool descriptions and adeprecation_target: 'scaffold_*'hint. Gives downstream a migration window.Acceptance
route-table.ts+tool-registry.tsupdated to matchflow_qualityandflow_governanceno longer return identical payloadsCross-repo context
src/gateway.tsenvelope unwrapStackbilt-dev/tarotscript#199(fixed)Stackbilt-dev/stackbilt-engine#23(closed — wrong repo)