qualifying-a-requestlisted

# Qualifying a request Two questions arrive together and are not the same question: **should this exist**, and **how much process does it earn**. A pack that answers only the first produces ceremony nobody finishes. A pack that answers only the second builds the wrong thing efficiently. This skill owns both. It does not design the thing, and it does not decide which checks the resulting work runs. The failure it exists to stop is the one that costs the most and is hardest to see afterwards: implementation began, and the request was never interrogated, so the work is correct against an intent nobody wrote down. ## What the request earns Four tiers. Ask in order and stop at the first match — the order is what keeps a contract-bearing change from being classified as small because it looks small. | | The request | What it earns | |---|---|---| | 1 | **An existing consumer contract must survive it** — a published interface, an internal call surface, a data format, an event shape, an assertion someone else relies on | A recorded baseline **before** anything is touched. The criterion for this work is whether the contract broke, not what value was delivered, and that criterion is unavailable once you have already edited | | 2 | **Same-shape, low-semantics, and a binary verifier already exists** — one command that answers pass or fail over the whole set | The verifier is the intake. Do not write a design; establish that the verifier rejects a known-bad member, then run the chang