Converge what to build before design starts

[shinpr]

Problem

implementation-approach Design Convergence already minimises the design surface for a requirement, but it treats the requirement itself as binding: a Failed Item is justified by "a current requirement" alone. That is the right contract for deciding how to build something, and it leaves what to build unexamined.

So a requirement that is bloated, internally ambiguous, or aimed at the wrong outcome gets minimised faithfully and built faithfully. Nothing upstream asks whether the requirement is worth its cost, and nothing carries the scope the user chose to exclude into design, planning, or review.

Approach

A new requirement-convergence skill holds the criteria and the hearing protocol. The three capabilities involved sit in different layers, so the skill is shared rather than owned:

• the orchestrator can ask the user but cannot investigate
• requirement-analyzer can investigate but cannot ask
• the document owners can write but do not judge

This mirrors how external-resource-context already splits a hearing protocol, a storage location, and a downstream reference protocol across one skill.

What converges

Field	Pass condition
outcome	One observable result; a requirement that does not serve it is excess
requirements[]	Each item labelled 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 placing it, plus remaining unknowns

Flattening the three requirement layers into one list is what makes a bloated plan read as uniformly required, so the labels are what keep an idea raised in passing from becoming committed work.

cost is a rough band rather than an effort estimate. Requirements cannot support person-days, and its only consumer is a three-row challenge intensity table, so a low-cost reversible change is recorded and accepted while an irreversible one needs a user decision before design. Cost follows structure and count — call sites, boundaries crossed, existing equivalents, persisted-state conversion, verification support, unknowns — none of which requires reading what the code does.

Downstream

The record reaches design through the documents that already exist: outcome into the PRD's Success Criteria, non-goals and speculative items into Future / Out of Scope with an Origin column separating what the user authored from what the analysis judged, and a new Requirement Convergence section in the Design Doc for flows without a PRD. Fields the user agreed to leave unresolved stay visible in the Design Doc in every case.

Consumers treat non-goals and speculative requirements as excluded, and an unresolved field as an open question rather than a settled decision.

Scale

File count measures size, not structural impact, so a two-file change can still reshape a contract or a data flow. Structural Escalation raises the requirement to Medium at minimum when any ADR Creation Condition applies. It only raises a level; existing thresholds stand. No new criteria are introduced — the conditions were already documented, they simply did not reach the document gate.

Also in this branch

Prompt defects found while working through the above:

• The hearing protocol's steps now name their completion evidence, so a skipped step is visible rather than silent
• requirement-analyzer gains the Task Registration mandate every other agent carries
• Prohibitions replaced with target states, including the training-cutoff note in four agents
• The orchestrated recipes no longer register a rule-selection task, which had been pulling rule-advisor into flows that no flow table includes; its description now scopes it to work whose rules no defined process has determined

Compatibility

Additive. Existing artefacts stay valid, the new Design Doc section is skippable with a reason, and no template field changes meaning.