QA and test data

Both parts are optional, asked at setup (default on) and changeable by re-running init (--qa-checklist, --test-data).

QA checklist

work/qa/checklist.md is generated from the living specs — never edited by hand:

• one item per scenario, grouped by capability and requirement;
• the EARS sentence, the Given / When / Then steps, the ZOMBIES tag;
• the test-data fixture that provides the scenario's data (or "no fixture").

agent-kit qa sync regenerates it (and checklist.html); agent-kit specs merge runs it for you.

QA runs

A QA pass is a dated file in work/qa/runs/:

npx @razcue/agent-kit qa run --env staging

Fill Result (pass · fail · blocked · n/a) and Note for each scenario. Or open work/qa/checklist.html in a browser, record results there (kept in the browser) and Export run to save the same file.

agent-kit qa status shows the latest result per scenario. Each run stores the scenario's text hash, so a scenario that changed after it passed shows re-check, and one never tested shows never run.

Test data (Supabase)

Supabase projects get supabase/test-data/ (path and prefix configurable):

Rules the scripts and the stack skill enforce:

• The _env guard first. Both scripts refuse unless _env says dev, test or staging — no row or production means no change.
• Marked rows only. Every row starts with the prefix (TEST_); purge matches with starts_with(), never LIKE.
• Through the RPCs, so balances, stock and audit rows stay consistent.
• Relative dates (current_date - 30).
• Fixtures per scenario, chosen with ZOMBIES: -- @fixture invoices.R2.S3 @boundary. agent-kit qa gaps lists scenarios without a fixture and fixtures naming unknown scenarios.

Preflight warns when migrations change and neither seed nor purge does. See the test data guide for applying them.