/derive-tests

name: derive-tests
description: 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.

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 record**, derived mechanically: a deterministic exporter reads the

locked artifact on disk into a computed record, and the built screens are compared against that record computationally, in both directions (everything in the record renders; nothing renders beyond it). Never hand-derive fidelity: a hand-typed summary standing in for the artifact produces drift as its designed output, because the artifact is never read again after the lock. The third project exited two slices with drifted screens that way, then built the mechanical route mid-project and drift stopped (record: PC-30). The ledger file (`design/ledger/slice-NNN.md`) keeps only what cannot be computed: acceptance scenarios and owner rulings, including licensed divergences.

• **The portion is declared, never assumed.** A locked portion smaller than a whole screen is

declared as excluded subtrees, each citing its ruling, held in the same extent guard as the comparison. And coverage is per drawn state, not per screen: a built state that ships never-compared is the gap an extent guard that only sees screens cannot see.

• **Chrome is contract; sample content is illustration.** The locked artifact says which parts of

a screen are specification and which are sample data; compare the specification. Fixtures for comparisons come from the wire types, values the product can actually emit, and an artifact-versus-product disagreement is a finding for the record, never smoothed over locally.

• **A rule the storage engine happens to enforce proves nothing.** Where a product rule is also

enforced by the engine as a side effect (a collation, a constraint), the falsifying test must run on a tier the engine does not cover, or the test can never fail.

• **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 product owns identity, the harness exercises the real sign-in path at least once; minting around auth is setup for other scenarios, never a substitute (INV-10, ruled: the gated harness profile makes this achievable).

• A composed-app smoke exists per primary flow: the actual entrypoint, at least one real request

(INV-07).

• A service method with no surface in the locked portion is a sanctioned UI-unsurfaced state when

it is e2e-covered and its boundary is documented (CONF-03). It is never resolved by inventing UI the prototype does not contain; the fidelity tests would fail that fabrication, and they should.

One discipline line

Prove a derived suite can fail: write one assertion wrong, watch it fail, fix it. A suite that cannot fail is not evidence.

Human-turn contract

• No gate of its own. A gap between the locked portion and what is derivable is a record-gap

question for the human, never an invented criterion.

What this skill must NOT produce

• Nothing before the lock is on record.
• No criteria the prototype does not show, no edits to the prototype or ledger direction, no

implementation code.

Next

implement.