How our gauntlet loop works

You say GO and pick the options. I write every decision into one binding file, lapN-constraints-and-rulings.md, as numbered rulings (R4-SESSION, R4-READONLY, ...). Every agent reads it before it starts.

• Scope sweep: before building, search master, open PRs and other devs' branches so we don't rebuild something that exists.
• Standing rules ride along: commit identity, never push, never rebase mid-lap, tests only on kali/macv2, never prune Docker without you.

Tag today's master as the lap base (lap4/base). Every branch starts there and the lap never rebases, so a master change mid-lap can't break a run halfway.

• One task = one branch = one future PR. Tasks that don't touch each other run at the same time.
• There's always a harness task: the new matrix tests, written first, which must fail on the old code.

Each implementer works alone on its branch and has to prove its work before it reports back:

• Red then green: every new test fails on the old code and passes on the fix, with the output in the report.
• Gates: ruff + ruff format, tsc, vitest/jest; backend pytest through lap-pytest.sh (macv2 if free, else kali).
• Codex cap: one codex review against the base. Fix P1, and P2 on money, security, privacy or a broken flow. Anything else is a follow-up.
• Commit locally with your name, no trailers. Nothing is pushed.

A separate reviewer reads the branch against the rulings and either approves it or lists problems by severity.

• Critical / High / Medium go back to the same implementer as a fix round.
• Low goes into the handoff's follow-up list.
• A reviewer finding that changes the design becomes a new ruling (for example R4-READONLY), sent to every task it touches.
• Questions only you can answer are batched into the handoff, not pinged one by one.

One script builds a throwaway integration branch (base + every lap branch merged) and puts it on kali:

• Rebuild both integrations (backend, storefront) from the branch lists.
• Snapshot kali's DB, then deploy backend (with alembic upgrade heads), admin and storefront.
• Recreate the test slots, seed the lap data, convert the MIG forms, warm the pages, verify served commits.
• A disk guard stops it if kali has under 8 GB free.

The matrix is our Playwright suite of real purchases and flows (Stripe card, SCORE, Amazon Pay, coupons, MyPage), run from macv2's browser against kali, on desktop Chrome and a Pixel 7 profile. run-matrix.sh reads kali's settings first and warns if something would make a cell lie.

• New cells first: just this lap's tests, so a basic break shows in minutes.
• Then the whole matrix: about 18 minutes, 84 cells now.

Running alongside:

• Union gates: every test the lap touched, run on the merged tree and compared with the base. Only new reds count.
• Cross-branch audit (after wave 1): one agent reads all branches together for things no single reviewer could see.
• Exploratory testing: an agent drives a real browser on macv2 with charters ("try to read another buyer's orders").

Every slip becomes a rule so it can't happen twice: R4-RESEED (re-seed is always followed by the MIG convert), R4-DETACH (long runs are detached with a "done" file so a timeout can't orphan a test).

The lap ends only when the whole matrix passes twice in a row on the same served build, with a fresh re-seed before each run. A red is allowed only if it has its own ticket.

• §0 your questions, each with my pick, so you answer in one go (lap 4: 7 questions, answered "1 keep, 2 keep, 3 yes ...").
• What was delivered, results, branch heads, push order, the test-server night plan, chat/Jira drafts, follow-ups.

If your answers ask for changes, that's round 2: back to step 3 with new rulings, same loop, same exit bar.

kali proves the code; the test server proves it with the real services (Stripe, SCORE, Amazon sandbox, SES, the WAF).

• Evening (after 20:00 JST): TOALL message, build branch images with unique tags (never :latest), migrate, switch the services, card payments to 仮売上, seed, arm the night.
• Night: the launchd job runs the matrix at 01, 03, 05 JST using your Keychain passwords (I never see them). I triage between runs.
• Morning (before 07:30 JST): template edit removed, 即時売上 back, DB downgraded, master services back, branch revisions deleted, TOALL done. A backup watcher does the rollback by itself at 06:45 JST if I haven't.

• Fetch master, rebase each lap branch onto it (the no-rebase rule ends here).
• One PR per ticket (lap 4: backend, storefront, matrix), CI, merge, the lead dev deploys.
• Jira 完了, the QA heads-up, notes to devs whose work overlaps (lap 4: a teammate's V3-2451).