vwemirror/BT411
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

tracker: add the FAILED RETEST status + the explicit post-playtest sweep. A tester Fail on a shipped fix was collapsing into QUEUED, which reads as 'never started' and understates a regression -- it now gets its own red status. Sweep rules made explicit per Test Status on every PATCHED-RETEST row: Pass -> close + move to CLOSED; Fail with detail -> FAILED RETEST + reopen + raise to >=P2 + post the evidence; Fail without detail -> NEED INFO with ONE discriminating question; blank -> stays yellow and rolls forward. Also records the ambiguity underneath all of it: a Pass or Fail carrying no BUILD NUMBER is uninterpretable (a Pass on an older build cannot verify a later fix), which is exactly why #27 and #38 sit at NEED INFO asking for the boot-screen build instead of going straight to red -- so every PATCHED-RETEST comment should stamp the build the fix shipped in. Sheet hover legends on the Test Status and Dev Status headers rewritten to teach both the vocabulary and the sweep to testers directly.

Browse Source 
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
Joe DiPrima
2026-08-14 23:42:44 -05:00
co-authored by Claude Opus 5
parent 74534cec9e
commit dba09e44b9
1 changed files with 17 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files
context/playtest-tracker.md
+17 -2
View File
@@ -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}`.