diff --git a/context/playtest-tracker.md b/context/playtest-tracker.md
index 605dffc..f867f09 100644
--- a/context/playtest-tracker.md
+++ b/context/playtest-tracker.md
@@ -37,6 +37,7 @@ The colour is **embedded in the label**, not applied as a cell fill:
 | Label | Meaning |
 |---|---|
 | `🟡 PATCHED - RETEST` | code landed, needs a playtest to confirm — the testers' retest list |
+| `🔴 FAILED RETEST` | a shipped fix did **not** hold; back on the bench (never collapse this into QUEUED — it understates a regression as "not started") |
 | `🟠 NEED INFO` | blocked on testers for a repro, detail, or log |
 | `🔵 YOUR CALL` | not a code question; needs their opinion or era memory |
 | `⚪ QUEUED` | logged and understood, work not started |
@@ -91,8 +92,22 @@ know if it happens again". If the thread already answers it, do not ask again.
 
 1. **Before a playtest** — regenerate/refresh: reconcile every row against gitea, clear stale
    statuses, make sure each `NEED INFO` carries an ask the testers can act on that night.
-2. **After a playtest** — read the sheet, file the unfiled `New` rows as tickets, link duplicates
-   to existing numbers, post the field evidence onto the tickets, then write results back.
+2. **After a playtest — THE SWEEP.** Read the sheet, file the unfiled `New` rows as tickets, link
+   duplicates to existing numbers, post the field evidence onto the tickets, then resolve every
+   `🟡 PATCHED - RETEST` row by what the tester wrote in Test Status:
+
+   | Test Status | Meaning | Action |
+   |---|---|---|
+   | `Pass` | fix confirmed | close in gitea, move the row to CLOSED |
+   | `Fail` + detail | the fix did not hold | `🔴 FAILED RETEST`, reopen in gitea, raise to ≥P2, post their evidence |
+   | `Fail`, no detail | cannot act yet | `🟠 NEED INFO` with ONE discriminating question |
+   | blank | nobody tested it | leave `🟡`, roll to the next session |
+
+   ⚠ **A Pass or Fail with no BUILD NUMBER is uninterpretable** — a Pass on an older build cannot
+   verify a fix that shipped later. Before treating a `Fail` as a regression, establish that the
+   tested build actually contained the fix; that ambiguity is why #27 and #38 sat at `NEED INFO`
+   (asking for the boot-screen build) rather than going straight to `🔴`. Stamp "shipped in build
+   NNN" into every `🟡` Dev Comment so the answer is checkable later.
 3. Reconciling ~50 tickets against their threads is a fan-out job — one agent per batch of ~7,
    returning `{num, dev_status, priority, dev_comment}`.