The control that says no.
Criteria and controls become executable tests. This run finds a real defect: a draft written before consent. Nobody had to remember to check.
1 · Requirements → 2 · Development → 3 · QA → 4 · Release → The screen it builds → 5 · Observability → 6 · Documentation
Story NP-AUTH-321 carries the same four controls it was given at requirements time. QA verifies them; it does not invent.
AUTH-PASS-016AUTH-PASS-017PRIV-CHILD-001A11Y-BASE-001Every suite below came from an acceptance criterion on NP-AUTH-321 and its attached control. None of it was written by hand.
AUTH-PASS-016AUTH-PASS-017PRIV-CHILD-001A11Y-BASE-001Run the control-driven suite to see what the attached controls actually verify.
An autosave writes a child-linked row before the guardian consent entry exists. The consent screen is correct; the background save is not.
FAIL consent-before-persistence · NP-AUTH-321 Given guardian consent has not completed When a wishlist draft autosaves after 8s idle Then no child-linked record should exist expected child_linked_rows = 0 received child_linked_rows = 1 └─ child_profile_draft(nickname, region) written by autosave consent_ledger entries: 0 ✗ control PRIV-CHILD-001 violated — promotion blocked
Exactly the defect a consent screen hides. It is caught because "including drafts" was written into the criterion at requirements time.
Why this is release-blocking: COPPA, GDPR Art. 8, LGPD, POPIA
QA does not decide whether the story ships. It publishes evidence; the gate reads it.
* The production workbench is internal — reachable over the corporate VPN only. This public page is a local demonstration.