specflow-intent-reconcilelisted

# Specflow: Intent Reconcile ## When to use Pin a specific stakeholder ask with a verbatim RED anchor test, let the normal spec-first flow absorb it, then check whether the spec's own test would still fail if the specific behaviour changed. Subsumed → retire the anchor and record it in the intent register; not subsumed → the spec generalised the ask away, so file a missing-criterion bug and flag the entry. Use when a user states a specific requirement in passing ("it needs one uppercase", "never log the token", "must respond under 200ms"), and again after that ask has landed in a spec. A tap on the existing classify → spec → test flow, never a second test suite. ## The Iron Law NO ANCHOR RETIRED WITHOUT A SPEC TEST THAT WOULD FAIL WITHOUT IT Violating the letter of this law is violating the spirit. If you find yourself constructing a reading under which the spec obviously covers this ask, that construction is the violation. Hardening mechanisms per `skills/_conventions/hardening.md`. ## The problem this exists for Specs generalise, and they should — that is how "the password needs one uppercase" becomes "passwords meet the complexity policy". But generalising loses things silently. The spec gets written, tests get generated from it, everything is green, and nothing in the suite would fail if the uppercase requirement quietly disappeared. Nobody notices, because there was never a test that pinned the specific thing. ## The three moves ### (a0) First: is the ask even