docs(memory): the regression I shipped in 23d37b6, the three-way measurement, and why colors_in_legend was never cosmetic

TODO.md

@@ -130,6 +130,17 @@ the design doc's M0–M4 is the intent behind it — see that doc's §0).
       Numbers reflect the profiled-subset denominator fix. The whole path (orchestrator → this
       Space → machine-auth gate → curated artifact) is now proven in production.
 
+## Open — a chart regression is LIVE on prod; the fix is committed but not deployed
+
+- [ ] **DEPLOY `819da30`.** Prod (`23d37b6`) has a regression shipped 2026-08-05: a query that
+      NARROWS the gene set leaves the previous answer's bars under the new answer's caution for one
+      render. Self-corrects on a second click and never shows a wrong *number*, but it does show one
+      cohort's bars beneath another cohort's warning. `819da30` fixes it (handler now blanks the
+      chart before yielding the answer) and is verified in BOTH directions on a single click — the
+      check whose absence caused this. 234 tests pass. Not deployed: needs Annie's go-ahead.
+      **Do not "clean up" `colors_in_legend` back in** — it looks cosmetic and is not; see `memory.md`
+      2026-08-05 (latest) for the three-way measurement.
+
 ## Open — the dev lane cannot be click-through verified while private
 
 - [ ] **Decide: make `pdac-genomics-agent-dev` public, or accept that UI verification happens on prod

memory.md

@@ -4,6 +4,49 @@ Current status + history. Architecture → `CLAUDE.md`. Backlog → `TODO.md`.
 
 ---
 
+## 2026-08-05 (latest) — I shipped a regression to prod and caught it in the post-deploy click-through (`819da30`, NOT deployed)
+
+`23d37b6` went to prod and fixed the three real bugs. It also introduced a fourth, which the
+post-deploy click-through found: **on a query that NARROWED the gene set, the chart body lagged one
+render behind** — caution and legend updated, the bars kept the previous answer's data. One cohort's
+numbers under another cohort's warning, which is the same class of wrong answer the whole change set
+existed to remove.
+
+**`colors_in_legend` was the cause, and I had added it as the *cosmetic* half of the fix.** Passing a
+value that CHANGES between renders is what forced the colour scale to rebuild — which is what fixed
+the narrow→wide direction. It was never cosmetic; it was load-bearing for a reason I had not
+understood. Measured, each against `40ab3dd` as control:
+
+| build | narrow → wide | wide → narrow |
+|---|---|---|
+| `40ab3dd` (before) | marks dropped | correct |
+| `23d37b6` (`colors_in_legend`) | correct | **stale one render** |
+| `color_map` alone | marks dropped | correct |
+
+So the two configurations I had were **the same bug pointing in opposite directions**, and the
+direction I happened to test first was the one that looked fixed.
+
+**Also tried and rejected:** holding the modality categories open with NaN placeholder rows so the
+domain never changes shape. NaN poisons the y extent — no bars and no axis render at all. (Zeros
+would have worked visually and were never an option: NRG1 is not 0% mutated, it is unassayed.)
+
+**The fix stops relying on the plot diffing correctly.** `_ui_variant_status` is now a generator: it
+blanks the chart, then yields the answer. The worst intermediate state a reader can catch is an
+EMPTY chart, which claims nothing, rather than a stale one, which claims something false. Both
+directions verified repainting on a single click. `test_ui_handler_gating` reads the final frame via
+`_final()`; the ADR-0004 assertions are untouched and a denied path still yields exactly one frame.
+
+**Three process lessons, all of them mine:**
+1. **I explained away the symptom the first time.** I saw the stale chart locally, guessed "my click
+   missed the button", and moved on. It had not missed. A surprising observation deserves one cheap
+   check before a comfortable explanation.
+2. **A fix verified in one direction is not verified.** Both bugs here are the same scale-rebuild
+   fault; testing narrow→wide only was the whole gap.
+3. **Green tests proved nothing about either.** Every version passed its own tests, because the tests
+   asserted the payload and the hypothesis, not the rendered result across a SEQUENCE of renders.
+
+---
+
 ## 2026-08-05 — first signed-in click-through since 2026-07-27; two display bugs found (`6c7b8cc`, NOT deployed)
 
 Everything shipped that day had been verified only by reading the deployed tree over `resolve/main`