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 build-relevant item labeled `current-state` or `desired-future`. | | `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. Keep request signals classified as evaluation requests, speculative ideas, or prescribed mechanisms in active convergence context as judgment-only candidates. `requirements[]` and durable documents receive a candidate only after explicit user confirmation. 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` ...