adventure: write down the text-colour lead before it evaporates

Found while fixing the night-phase contrast, not fixed there. The evidence
points two ways — no such rule in the built CSS and a phase-ignoring computed
colour, but a screenshot showing that same text rendering correctly — and the
contradiction is the first thing to resolve, because it decides whether there
is a bug here at all. Recorded as a lead rather than dressed up as a finding.

Also records how the live-page measurement misleads, since every one of those
traps cost time and would cost it again.

adventure_expansion_spec.md

@@ -505,6 +505,48 @@ page reflects the row.
 5. **Ask 2 (LLM dispatches)** — last, because the prose guard is the only piece
    here that fails *publicly* if it is wrong.
 
-Open, not covered by any of the five: the live sheet poll patches only
-HP/AC/room/supplies/threat (`templates/who.html:287-290`). A richer sheet is a
-Pete-only change.
+## Follow-ups, not covered by any of the five
+
+Both Pete-only.
+
+### `text-[color:var(--ink)]/NN` may be a no-op — unresolved, verify first
+
+Found while fixing the night-phase contrast (`7d2d991`), **not** fixed there.
+The evidence points two ways and I could not reconcile it:
+
+- No such rule exists in the built `output.css` — `grep 'text-\[color:var(--ink)\]/55'`
+  finds nothing, and all 21 `var(--ink)` references in the output come from
+  hand-written component CSS, not from these classes.
+- The item description in the Worn panel computes to a **fixed `rgb(74,46,42)`
+  that does not change with the phase** — that is dawn's `--ink` as a literal,
+  from a source I never located.
+- Tailwind v3 cannot apply an opacity modifier to an arbitrary `var()` colour,
+  which would explain all of the above.
+- **But** a night-phase screenshot showed that same text rendering as readable
+  cream, which contradicts the computed value outright.
+
+So: probably a pre-existing site-wide no-op, silently dropping the muted-text
+styling wherever it appears — `who.html` uses `/45`, `/50`, `/55` throughout,
+and it is not confined to the new item panels. Treat the above as a lead, not a
+finding. **Start by explaining the screenshot/computed contradiction** — one of
+the two observations is measuring the wrong thing, and which one decides whether
+there is a bug here at all.
+
+Measuring this in the live page is booby-trapped, and each of these cost time:
+reading an element's own background returns its translucent chip fill rather
+than its backdrop (walk up from `parentElement`); a page reload resets
+`data-phase` to the server-rendered value (`data-phase-lock` in `layout.html:2`
+stops the clock script, not a reload); and reading the card colour and the text
+colour in different ticks silently mixes two phases. A screenshot was ground
+truth every time a computed value was not.
+
+If it is real, the fix is the same shape as `--warn`: a phase variable, or a
+hand-written utility — not a Tailwind arbitrary-value class with an opacity
+modifier. See the `pete_theme_contrast` note for why `dark:` is never the answer
+here (`darkMode` is unconfigured, so it follows the OS, not Pete's phase —
+`status.html` and `channel.html` still have that bug).
+
+### Richer live sheet
+
+The live sheet poll patches only HP/AC/room/supplies/threat
+(`templates/who.html:287-290`).