requirement-convergence

Run a convergence pass that separates the single observable outcome from the requirements list, labels each item current-state or desired-future, and records user-authored non-goals. Each field gets a readiness label, and design only starts when all applicable fields are ready or explicitly accepted as weak.

Band cost from structural evidence: count targets and boundaries via grep/glob, check for existing equivalents, detect schema migrations, and verify test harness existence. The result is a band (low-reversible, medium, high-irreversible) with its unknowns, not a person-day estimate.

Current-state requirements describe behavior that already exists and are facts, not work. Desired-future requirements are the actual change being requested and are buildable. Mixing them into one list makes bloated plans look coherent, so each item must be explicitly labeled.

Challenge intensity follows the cost band: low-reversible changes are recorded and accepted, medium-cost changes get one lower-cost alternative presented, and high-irreversible changes (public contracts, persisted data shapes, dependency swaps) require an explicit user decision before design.

A field that still fails its pass condition after one re-ask can be marked weak-but-explicit only with the user's agreement. Downstream consumers treat it as a recorded open question and return the missing decision to the owning workflow when work depends on it.