flow_quality and flow_governance return only {hash} — handlers appear stubbed

[stackbilt-admin]

Summary

flow_quality and flow_governance are registered MCP tools with descriptive tool descriptions promising useful output. In practice both return a bare {hash} echo. Either the handlers are stubs or they're failing silently.

Repro

```json
// Input — valid hash from flow_create
{ "hash": "1fe73467aafb510f12d6a16d021456dacbd9f121340f227265dd364e17046497" }

// flow_quality response
{ "hash": "1fe73467aafb510f12d6a16d021456dacbd9f121340f227265dd364e17046497" }

// flow_governance response
{ "hash": "1fe73467aafb510f12d6a16d021456dacbd9f121340f227265dd364e17046497" }
```

Tool description for flow_quality: "Get quality and governance scores from a receipt hash."

Tool description for flow_governance: "Get governance posture from a receipt hash — determinism profile, capping, and verification."

Actual output: the hash, echoed back. Nothing else.

Not a lookup issue

The same hash returns full data via the sibling tools:

• flow_status({hash}) → {verified: true, hash} (verification works)
• flow_summary({hash}) → full receipt with facts, output, governance (threat_model, adr, test_plan), materialized files, promptContext

So the receipt is stored, queryable, and fully populated. flow_quality and flow_governance just don't read from it, or the fields they'd read are never populated.

Proposed fix

Three possibilities, in rough order of likelihood:

1. Handlers are stubs — registered in the tool manifest but return { hash } is a placeholder. Implement.
2. Handlers read from fields never populated — the underlying scaffold engine doesn't emit quality scores or governance posture separately; that logic needs to be added to the receipt generator in flow_create.
3. Handlers silently fail — check for swallowed errors / try-catch blocks returning the input unchanged on exception.

Inspection of the flow_quality and flow_governance handlers in this repo will tell you which. Given flow_summary already returns a governance block with threat_model/adr/test_plan, flow_governance could plausibly derive its "determinism profile, capping, and verification" view by post-processing that same data — so this may be low-effort once someone defines the output shape.

Severity

Low-Medium. Doesn't block any flow, but MCP clients that trust tool descriptions will try these and get nothing useful. Either fix the handlers or remove the tools from the manifest until they work.

Context

Found via full-surface MCP smoke test. All four flow introspection tools (flow_status, flow_summary, flow_quality, flow_governance) were tested with the same hash from a fresh flow_create call — first two work, last two don't.