Verification cost ~= implementation cost per milestone

[clintecker]

Summary

Per-milestone verification consumes nearly as many LLM turns as implementation itself, roughly doubling the cost of each milestone.

Evidence (run 0aea2a4f9e95)

Turn counts by node across the whole run:

• Implement: 321 turns
• VerifyMilestone: 305 turns

Verification ran once per milestone (clean node walk, no fix-loops at graph level) and cost ~95% of what implementation cost. Over 10 milestones that is a large fraction of total spend on re-reading and re-checking work that TestMilestone already gates.

Proposed change

• Consider running the heavy cross-review at phase / dependency boundaries rather than every single milestone, relying on TestMilestone for per-milestone gating.
• Or scope VerifyMilestone's reading to the milestone diff rather than re-deriving context each time.

Notes

VerifyMilestone is thorough and catches real scope issues (over-build guard etc.), so this is a tuning/efficiency question, not a request to remove it. Pairs naturally with the test-fidelity issue (spend the verify budget where it adds signal).

[clintecker]

Scoping note: both proposed fixes — run the heavy cross-review at phase/dependency boundaries instead of every milestone, or scope VerifyMilestone to the milestone diff — are build_product .dip changes that alter what gets checked and when, so they need real-run validation of the cost/coverage trade-off before shipping (the same class as #353's reviewer-cap value: a workflow-tuning decision that wants run data, not a blind edit to the flagship). The enabling primitives are already in place: per-node cost visibility (tracker diagnose cost-asymmetry detector) and safe caps (cost_exceeded_action: fail, #353). This is a workflow-tuning task best done alongside a real build to measure the before/after spend.

[clintecker]

Visibility slice shipped on main (2966574): the tracker run node-execution table now has a Cost column per node, so the verification-vs-implementation spend is visible at a glance (e.g. VerifyMilestone $1.56 next to Implement $1.64) instead of reverse-engineering the activity log. This makes the verify-cadence tuning data-driven.

Remaining (the actual cost reduction): the build_product cadence change — verify at phase/dependency boundaries instead of every milestone, or scope VerifyMilestone to the milestone diff — alters what gets checked and when, so it wants a real run to validate the cost/coverage trade-off before shipping (the same class as #353's cap-value). The enabling visibility (this + #353's cost-asymmetry detector) is now in place.