← ClaudeAtlas

derive-testslisted

Use only after the lock (gate 2b) is on record for the slice portion, to derive the fidelity ledger and acceptance scenarios from the locked prototype. Triggers when a portion is newly locked or re-locked. Never use before the lock, and never use it to hand-author prototype-fidelity test cases from prose.
teklabsdigital/x2-method · ★ 13 · AI & Automation · score 70
Install: claude install-skill teklabsdigital/x2-method
# X2 Derive Tests Turn the locked portion into its tests. Nothing here is authored from imagination: the locked prototype is the acceptance contract, and the tests are projections of it. ## What derives from the lock - **The per-slice fidelity ledger** (`design/ledger/slice-NNN.md`): the locked portion's visual atoms, enumerated. The kernel tests it in both directions: every ledger atom renders (exhaustiveness) and nothing renders beyond the ledger (de-fabrication). Until the prototype-to-ledger exporter exists (owed on the claim), the hand-derived ledger is a known second-source risk: derive it at lock time only, from the artifact on disk, never maintain it by hand alongside a moving prototype. - **The acceptance scenarios** on the e2e floor: the flows the locked portion shows, driven through the real client services against a running server. ## The scoping of "no hand-authored test cases" The ban is precise, per the record's wording fix: - **Banned**: authoring prototype-fidelity tests ahead of the lock. They derive from it. - **Not banned**: claim-driven tests: harness scenarios, gate tests, guard tests. These keep the write-it-first, watch-it-fail shape, and they did the most catching in the pilot. ## Coverage expectations the exit report will check Derivation should leave these satisfiable, because slice-exit reports them: - Every public method of every client data service has at least one harness scenario through the real transport, and when the