requirement-convergence

# Requirement Convergence ## Purpose Requirements arrive bloated, ambiguous, or aimed at the wrong outcome. A capable model reconciles all three into a coherent plan and builds it faithfully — delivering exactly what was asked for when what was asked for was wrong. This skill converges **what to build**. How to build it, and which documents the change requires, are settled after the what is. ## Convergence Fields | Field | Pass condition | |-------|----------------| | `outcome` | One observable result. A requirement that does not serve it is excess. | | `requirements[]` | Every item labeled `current-state`, `desired-future`, or `speculative`. | | `nonGoals[]` | Authored by the user, or the user stated there are none. | | `cost` | A band with the structural evidence that places it, plus the unknowns that remain. | `cost` is a rough band, not the effort estimate a work plan schedules against; requirements cannot support person-days. Its unknowns carry more decision weight than its size. Each field carries a readiness label: `ready`, `weak`, or `weak-but-explicit` (weak, and the user agreed to leave it unresolved). Only the user sets `weak-but-explicit`. Requirements are converged when every applicable field is `ready` or `weak-but-explicit`. Judgment rules per field: [references/criteria.md](references/criteria.md). ## Hearing Protocol Eliciting and judging the convergence fields require user interaction, so the orchestrator owns them. The hearing runs after the speci...