diff --git a/.planning/phases/04-harden-clean-up-optional/04-06-REPLAN-CHECKER-iter-1.md b/.planning/phases/04-harden-clean-up-optional/04-06-REPLAN-CHECKER-iter-1.md
new file mode 100644
index 0000000..e65572b
--- /dev/null
+++ b/.planning/phases/04-harden-clean-up-optional/04-06-REPLAN-CHECKER-iter-1.md
@@ -0,0 +1,272 @@
+# 04-06 RE-PLAN VALIDATION — iter-1
+
+**Plan:** `.planning/phases/04-harden-clean-up-optional/04-06-PLAN.md`
+**Commit reviewed:** `b59bd24` (`docs(04-06): re-plan — correct false jsdom premise + stale back-patch lines + baseline`)
+**Reviewer:** gsd-plan-checker (re-plan validation loop, iter-1)
+**Date:** 2026-05-22
+
+---
+
+## VERDICT: ITERATE-NEEDED
+
+**2 BLOCKER · 1 WARNING · 3 cosmetic-advisory**
+
+The re-plan correctly resolves DEFECT 2 (back-patch line numbers) and the `welcome.css` drop is sound. But the two load-bearing claims of the re-plan — the DEFECT 1 A17.8 delegation and the DEFECT 3 baseline reframe — are **both factually wrong against the live codebase**, and each will cause the plan to fail or mis-gate during execution. The re-plan substituted one false premise (jsdom) for two new false premises. Re-plan again.
+
+---
+
+## Defect-by-defect verdict
+
+### DEFECT 1 — false jsdom premise → node-env source-contract strategy
+
+**Sub-claim 1a — "vitest ships no DOM library":** CONFIRMED TRUE.
+`vitest.config.ts:18` is `environment: 'node'`. `node_modules/{jsdom,happy-dom,linkedom,@happy-dom}` all absent. No vitest test uses `DOMParser`. The node-env source-contract reframe of `inline-svg.test.ts` is the correct response to *that* fact.
+
+**Sub-claim 1b — the source-contract test meaningfully pins the contract:** ACCEPTABLE (not a blocker).
+`tests/i18n/manifest-i18n.test.ts` is a sound, in-repo `readFileSync` + `toContain` precedent. Test B's negative assertions (`NOT mokosh-mark.svg?url`, `NOT innerHTML`) genuinely pin the T-04-06-01 MV3-CSP mitigation and the import swap. A `readFileSync`+`toContain` test is admittedly weak (it pins source *text*, not runtime behavior) — but the plan is honest about this and the TDD RED→GREEN cycle is real: all 3 tests are genuine-RED today (SVG still `#181b2a`; welcome.ts still `?url`/`` DOM injection and the `currentColor`→parent-`color` CSS cascade — the *entire* runtime behavior the node-env unit test "deliberately cannot cover" — is covered by **nothing**. The plan's A17.8 update (Task 3) only swaps the `data:image/svg+xml` string-grep for a `stroke="currentColor"` + `viewBox` string-grep on the same `jsText`. That asserts *the raw SVG source is bundled* — it does NOT assert the SVG is parsed, injected, or that the cascade resolves.
+
+The PATTERNS.md the planner consumed (`04-PATTERNS.md:1126-1127`) explicitly specs **"A17.8b — inline SVG injected at populateMark() runtime: `document.querySelector('.welcome-hero__mark svg')` is non-null"**, and the plan's own Task 3 step (b) (`04-06-PLAN.md:306`) describes adding exactly that A17.8b DOM query — but qualifies it "**pick this unless the harness page cannot reach the welcome DOM in this driver** … if the driver structure makes a second DOM query infeasible, document why … and ship A17.8a only — A17.8a alone still satisfies UI-SPEC Acceptance Criterion #3."
+
+The driver structure **does** make it infeasible (verified above). So under the plan's own escape hatch the executor will ship A17.8a-only. Net result: **AC #3 of the UI-SPEC is the *only* automated gate for the inline-SVG technique, and A17.8a-only does not verify the technique** — it verifies the source string is in the bundle, which would also be true if `populateMark` were still broken. The plan asserts "A17.8a alone still satisfies UI-SPEC Acceptance Criterion #3"; UI-SPEC AC #3 (`04-UI-SPEC.md:248`) accepts an A17.8-rewrite of "raw SVG source bundled" — so strictly the *spec checkbox* is satisfiable — but the **goal** (D-P4-03 dark-logo strategy actually working) is then verified by zero automated coverage and rests entirely on the Task 4 operator eyeball.
+
+**Why this is a BLOCKER, not a WARNING:** the re-plan's stated thesis is "full live-DOM injection + currentColor cascade verification is delegated to the A17.8 harness sub-check in real Chrome." That delegation target does not exist. The plan ships a weak unit test *justified by* a harness check that cannot be written as specced. Either:
+- (a) the plan must add a **real** welcome-page DOM check — i.e. a harness driver that actually opens `welcome.html` in a Puppeteer page/tab, lets `populateMark()` run, and queries `.welcome-hero__mark svg` + its computed stroke. That is a genuine new harness capability (a `page.goto` / new-tab driver), not a "second `result.checks` entry" in `assertA17`. The plan must scope that work explicitly, OR
+- (b) the plan must drop the "delegated to A17.8 in real Chrome" claim and **honestly state** that the inline-SVG runtime behavior is verified ONLY by the Task 4 operator screenshot — and the planner/orchestrator must accept that the automated path has a real gap.
+
+Note option (b) is partially defensible (Task 4 *is* a genuine operator-empirical gate and a human looking at a dark+light screenshot *will* catch a black-on-dark mark). But the plan must not *claim* harness coverage it does not have. As written, the plan is internally inconsistent and a downstream executor following Task 3 step (b)'s escape hatch produces a weaker artifact than the plan's verification section promises.
+
+### DEFECT 2 — stale back-patch line numbers
+
+**VERDICT: RESOLVED — CONFIRMED CORRECT.**
+
+Verified `grep -nE 'Phase 5|deferred to Phase 5|deferred-to-5'` against the live `01-07-SUMMARY.md` (244 lines):
+
+| Line | Content | Plan says | Correct? |
+|------|---------|-----------|----------|
+| 22 | `affects:` graph — "Phase 5 … new entry: getDisplayMedia cursor visibility constraint" | FLIP | ✅ forward-looking deferral |
+| 47 | key-decisions — "Cursor visibility … deferred to Phase 5, not back-patched" | FLIP | ✅ stale deferral framing |
+| 82 | accomplishments — "Cursor-visibility refinement deferred to Phase 5" | FLIP | ✅ stale deferral framing |
+| 135 | Decisions Made #5 — "Cursor visibility refinement deferred to Phase 5" | FLIP | ✅ stale deferral framing |
+| 205 | User Setup — "The cursor visibility refinement (Phase 5) will, when activated, add…" | FLIP | ✅ false-future tense |
+| 40 | key-files — "ROADMAP.md … cursor-visibility refinement appended to Phase 5" | LEAVE | ✅ historical: describes the ROADMAP commit content |
+| 89 | Task Commits — `7df72aa` "… Phase 5 cursor-visibility appended" | LEAVE | ✅ historical: describes what commit `7df72aa` did |
+| 109 | Files Created/Modified — "ROADMAP.md … Phase 5 P1/P2 list appended" | LEAVE | ✅ historical commit record |
+| 110 | Files Created/Modified — "STATE.md … `[Phase 01-07-deferred-to-5]` decision-log tag" | LEAVE | ✅ historical commit record |
+
+The flip/leave classification is exactly right. Lines 22/47/82/135/205 each assert the deferral as a live forward-looking fact (false — `cursor:'always'` shipped in Plan 01-09, verified at `recorder.ts:285`). Lines 40/89/109/110 each describe what a specific Phase-1-closure commit *recorded at the time* — flipping them would falsify the historical record. DEFECT 2 is genuinely fixed.
+
+### DEFECT 3 — wrong vitest baseline
+
+**VERDICT: NOT RESOLVED — the reframe identifies the WRONG failing test. → BLOCKER 2.**
+
+The re-plan reframes the baseline as "**183 passed / 1 failed**, the 1 failure being `tests/build/strict-meta-json-validation.test.ts` … a pre-existing red on a clean tree." It then hard-codes a gate in Task 2 (`04-06-PLAN.md:275`, `:292`) and Task 4 (`:361`): "**Verify the failure set is EXACTLY {strict-meta-json-validation.test.ts}**. If any OTHER test fails, Plan 04-06 caused a regression."
+
+Empirically verified this run (2026-05-22, clean tree at `b59bd24`):
+
+- Full suite `npx vitest run`: **183 passed / 1 failed (184)** — count matches.
+- BUT the failing test was **`tests/background/webm-remux.test.ts > … ffprobe -count_frames reports between 905 and 912 frames`** — `Error: Test timed out in 5000ms`. **NOT `strict-meta-json-validation.test.ts`.**
+- `npx vitest run tests/build/strict-meta-json-validation.test.ts` in isolation: **8 passed / 8** — GREEN.
+- `npx vitest run tests/background/webm-remux.test.ts` in isolation: **5 passed / 5** — GREEN.
+
+Both candidate tests pass deterministically in isolation. The "1 failed" in the full suite is a **non-deterministic timeout** of an ffprobe-shelling test under parallel-worker load. This is precisely the pre-existing flake class that `04-CONTEXT.md` itself enumerates as Phase 4 in-scope items **#9 ("pre-existing parallel-vitest Tier-1-build-step race (~1/5 full-suite runs)")** and **#10 ("2 pre-existing ffprobe/ffmpeg vitest flakes")**.
+
+Consequences:
+1. The re-plan's premise — "`strict-meta-json-validation.test.ts` is a pre-existing red on a clean tree" — is false. That test is GREEN on a clean tree. The `deferred-items.md` entry it cites (logged 2026-05-22) is itself based on a one-shot observation that mis-attributed a flake to a specific test.
+2. The hard-coded gate `failure set EXACTLY == {strict-meta-json-validation.test.ts}` will **fail spuriously** during execution: on most runs the suite is 184/184 GREEN (so the gate "1 expected failure missing" trips), and on a flaky run the RED lands on `webm-remux` or an ffprobe test (so the gate "unexpected test failed → regression" trips and falsely blames Plan 04-06).
+3. The stated target "187 passed / 1 pre-existing fail (188 total)" is wrong twice over: the true clean-tree baseline is **184/184** (the "1 fail" is a flake, not a fixture), so after +4 new tests the correct expectation is **188/188 GREEN, modulo the known ~1/5 parallel-vitest flake which may land a transient RED on any ffprobe/parallel-race test.**
+
+**Required fix:** Task 2 and Task 4 vitest gates must be reframed to tolerate the **flake class**, not a named test. Correct gate logic: "Full suite is **188/188 GREEN**. If exactly one test is RED AND it is in the known ffprobe/parallel-race flake set (`webm-remux.test.ts` `-count_frames`, the 2 ffprobe/ffmpeg flakes per 04-CONTEXT #10, or a Tier-1-build-step race per #9), re-run once; a clean re-run confirms no regression. If a RED persists across a re-run, or a RED lands on a non-flake test, Plan 04-06 caused a regression." The plan must NOT name `strict-meta-json-validation.test.ts` as the expected failure — that is a phantom.
+
+(Secondary: routing this flake to `/gsd-debug` is fine, but it should be routed as "the parallel-vitest ffprobe flake (04-CONTEXT #9/#10)", not as "`strict-meta-json-validation.test.ts` fails on a clean tree" — the latter is a misdiagnosis that will waste the debug session.)
+
+---
+
+## welcome.css drop — VALIDATED (no-edit claim is CORRECT)
+
+The re-plan drops `src/welcome/welcome.css` from `files_modified` with the rationale: the bare `.welcome-hero__mark-img` selector matches `` like `` exactly as it matches `` injected via `DOMParser` + `replaceChildren` is a regular descendant element, so it inherits `color` from `.welcome-hero__mark` automatically. `stroke="currentColor"` on the SVG root then resolves to that inherited `color`. No `color: inherit` rule is needed.
+- This is exactly why Option A *requires* the inline-`` switch: an `` part 1/2, `must_haves.truths` 1-3, key_links 1-2 all carry the SVG-recolor + inline-`` + cascade thesis. SVG recolor is the verified single-attribute change (`stroke="#181b2a"`→`currentColor`; 13 children untouched).
+- **Cursor verification-only:** intact — `recorder.ts:285` confirmed to already carry `cursor: 'always'` (verified live, lines 284-291). Plan correctly treats it as verification-only via `tests/build/cursor-visibility.test.ts` (GREEN-on-arrival) per RESEARCH Finding 4. `recorder.ts` is correctly NOT in `files_modified`.
+- **A17.8 update:** intact in intent (raw-source grep replacing data-URL grep) — but see BLOCKER 1: the *real-Chrome DOM* half of the intended A17.8 update cannot be delivered by the existing driver.
+- **Operator-empirical Task 4:** intact — `type="checkpoint:human-verify" gate="blocking"`, `autonomous: false` (frontmatter line 21), dark + light Puppeteer screenshots via `emulateMediaFeatures([{name:'prefers-color-scheme',value:'dark'}])`, resume-signal contract present. Honors `feedback-trust-harness-over-manual-uat` (operator judges from screenshots, not a manual Chrome session) and UI-SPEC AC #6.
+
+---
+
+## Goal-backward — D-P4-03 closure
+
+D-P4-03 (locked, `04-CONTEXT.md`) = BOTH (a) cursor visibility + (b) dark-surface logo contrast.
+
+- **(a) cursor visibility:** closed — verification test + 5-line back-patch. Sound.
+- **(b) dark-logo contrast:** the *edits* that deliver it (SVG recolor + `?raw` + DOMParser `populateMark` + `globals.d.ts` decl) are correctly specified in Task 2. The closure is **goal-reachable** — but per BLOCKER 1 the *verification* that it actually works is weaker than the plan claims (no live-DOM/cascade automated coverage; rests on Task 4 operator eyeball). The goal can still be *achieved*; the plan's *verification story* for it is the defect.
+
+D-P4-03 is reachable once BLOCKER 1 and BLOCKER 2 are fixed.
+
+---
+
+## Atomic commit / frontmatter / hooks
+
+- **Task structure:** `gsd-sdk verify.plan-structure` → `valid: true`, 4 tasks, all 4 have Files+Action+Verify+Done. Task 4 is `checkpoint:human-verify`. Per-task atomic commit messages present and convention-correct (`test(04-06):`, `feat(04-06):` ×2, operator ack).
+- **Frontmatter:** valid; `revision_history` block present and detailed (3 defects documented); `must_haves` parses; `autonomous: false` correct for the checkpoint.
+- **FORBIDDEN_HOOK_STRINGS lockstep:** verified `tests/background/no-test-hooks-in-prod-bundle.test.ts:108-126` — inventory is **12 entries**. Plan 04-06 adds **no** `__MOKOSH_UAT__`-gated symbol (the `?raw` import, DOMParser, `inline-svg.test.ts`, `cursor-visibility.test.ts` are all production or unit-test surfaces, none test-mode-gated). The plan's claim "FORBIDDEN_HOOK_STRINGS stays at 12" (Task 4 Gate 6, `04-06-PLAN.md:359`/`:383`) is **correct**. No lockstep violation.
+- **`files_modified` completeness:** the 7 entries match the edits Tasks 1-3 actually make. `recorder.ts` correctly excluded (verification-only). `welcome.css` correctly excluded (no-edit, validated above). Complete.
+
+---
+
+## NEW issues introduced by the re-plan
+
+- **BLOCKER 1** and **BLOCKER 2** above are both *new* — the original plan's defects were jsdom/line-numbers/184-baseline; the re-plan fixed the line numbers but introduced a false A17.8-delegation claim and a false named-failing-test in place of the old false 184/184. The re-plan traded one wrong premise for two.
+- No new dependency-graph, scope, or context-compliance issues. Wave 5 / `depends_on: [01..05]` unchanged and consistent. Scope (4 tasks, 7 files) is within budget.
+
+---
+
+## ISSUES
+
+```yaml
+issues:
+ - id: BLOCKER-1
+ dimension: key_links_planned
+ severity: blocker
+ plan: "04-06"
+ task: 3
+ description: >
+ The re-plan's DEFECT 1 resolution justifies the weak node-env source-contract
+ unit test by "delegating full live-DOM injection + currentColor cascade
+ verification to the A17.8 harness sub-check in real Chrome". That delegation
+ target does not exist. The assertA17 driver (extension-page-harness.ts:2090-2305)
+ runs inside an extension-internal harness page and reaches the welcome page only
+ via fetch() + DOMParser string-parse of welcome.html and string-grep of the
+ welcome JS chunk (jsText). It never opens a live welcome-page tab, never runs
+ populateMark(), never queries document.querySelector('.welcome-hero__mark svg').
+ Task 3 step (b)'s own escape hatch ("if the driver cannot reach the welcome DOM,
+ ship A17.8a only") will therefore trigger, leaving the inline-SVG injection +
+ currentColor cascade with ZERO automated coverage. A17.8a (raw-source string
+ grep on jsText) would pass even if populateMark were still broken.
+ fix_hint: >
+ Either (a) scope an explicit NEW harness capability — a driver that opens
+ welcome.html in a Puppeteer page/tab, lets populateMark() run, and asserts
+ the live .welcome-hero__mark svg element + its resolved stroke (this is real
+ new work, not a second result.checks entry) — and make A17.8b that driver;
+ OR (b) drop the "delegated to A17.8 in real Chrome" claim entirely and state
+ honestly in and that the inline-SVG runtime
+ behavior is verified ONLY by the Task 4 operator screenshot, with the planner
+ accepting that automated gap. Do not claim harness coverage the harness lacks.
+
+ - id: BLOCKER-2
+ dimension: task_completeness
+ severity: blocker
+ plan: "04-06"
+ task: 2
+ description: >
+ The DEFECT 3 baseline reframe names the wrong failing test. The re-plan asserts
+ "183 passed / 1 failed; the 1 failure is tests/build/strict-meta-json-validation.test.ts,
+ a pre-existing red on a clean tree" and hard-codes a Task 2 + Task 4 gate
+ "verify the failure set is EXACTLY {strict-meta-json-validation.test.ts}".
+ Verified live (2026-05-22, clean tree b59bd24): the full-suite RED this run was
+ tests/background/webm-remux.test.ts (ffprobe -count_frames, Test timed out in
+ 5000ms) — NOT strict-meta-json-validation.test.ts. Both tests pass deterministically
+ in isolation (strict-meta-json 8/8 GREEN; webm-remux 5/5 GREEN). The "1 failed"
+ is a non-deterministic ffprobe/parallel-worker timeout flake — exactly the
+ pre-existing flake class 04-CONTEXT.md enumerates as in-scope items #9 and #10.
+ The hard-coded named-test gate will fail spuriously: on a 184/184 run it trips
+ "expected failure missing"; on a flaky run the RED lands elsewhere and it falsely
+ blames Plan 04-06 for a regression. The true clean-tree baseline is 184/184
+ GREEN, so the post-plan target is 188/188 GREEN (not 187/1).
+ fix_hint: >
+ Reframe the Task 2 + Task 4 vitest gates to tolerate the flake CLASS, not a
+ named test. Correct gate: "Full suite 188/188 GREEN; if exactly one test is RED
+ and it is in the known ffprobe/parallel-race flake set (webm-remux -count_frames,
+ the 2 ffprobe/ffmpeg flakes, a Tier-1-build-step race), re-run once — a clean
+ re-run confirms no regression; a persisting RED or a RED on a non-flake test is
+ a regression." Remove every reference to strict-meta-json-validation.test.ts as
+ the expected pre-existing failure. Correct the stated baseline to 184/184 and
+ the target to 188/188. If routing to /gsd-debug, route it as the 04-CONTEXT
+ #9/#10 parallel-vitest flake, not as "strict-meta-json fails on a clean tree".
+
+ - id: WARNING-1
+ dimension: verification_derivation
+ severity: warning
+ plan: "04-06"
+ description: >
+ With BLOCKER 1 unresolved, the dark-logo strategy's automated verification
+ reduces to A17.8a (a string-grep proving the raw SVG source is in the bundle).
+ That is a bundling check, not a behavior check — it does not distinguish
+ "populateMark correctly inline-injects the SVG and the cascade resolves" from
+ "populateMark is broken but the ?raw import still bundled the string". The
+ must_haves.truths #3 ("Injected inline inherits color ... verified in
+ real Chrome by the A17.8 harness sub-check") is therefore not actually
+ satisfied by any planned artifact.
+ fix_hint: >
+ Resolved automatically once BLOCKER 1 is fixed via option (a). If BLOCKER 1 is
+ resolved via option (b) instead, rewrite truth #3 to say the cascade is verified
+ by the Task 4 operator screenshot, and accept the reduced automated coverage
+ explicitly rather than implying harness coverage.
+
+ - id: ADVISORY-1
+ dimension: task_completeness
+ severity: cosmetic-advisory
+ plan: "04-06"
+ task: 3
+ description: >
+ Task 3's automated block runs the UAT with SKIP_PROD_REBUILD=1
+ while the prose for Task 3 instructs SKIP_PROD_REBUILD=0. Minor
+ internal inconsistency between the action narrative and the verify command.
+ fix_hint: >
+ Align the two — pick SKIP_PROD_REBUILD=0 (action) or =1 (verify) consistently;
+ whichever matches the intent that the harness rebuilds against the Task 2 edits.
+
+ - id: ADVISORY-2
+ dimension: requirement_coverage
+ severity: cosmetic-advisory
+ plan: "04-06"
+ description: >
+ frontmatter requirements: [] is empty. Correct for a Phase 4 plan (Phase 4
+ has no new REQ-* per ROADMAP), but the plan closes the charter decision
+ D-P4-03. Consider a charter-decision tag rather than leaving the field bare,
+ for traceability — non-blocking; tags already include charter-d-p4-03.
+
+ - id: ADVISORY-3
+ dimension: verification_derivation
+ severity: cosmetic-advisory
+ plan: "04-06"
+ description: >
+ Task 1 acceptance_criteria "grep -c 'jsdom' tests/welcome/inline-svg.test.ts
+ returns 0" is a fine guard, but the header-comment the plan asks the executor
+ to write WILL mention jsdom (explaining why jsdom is NOT used). A literal
+ grep -c 'jsdom' would then return >0 from the comment and fail the criterion.
+ fix_hint: >
+ Either scope the grep to non-comment lines, or reword the criterion to
+ "no import of jsdom / no jsdom-environment directive", or instruct the
+ header comment to say "no DOM-emulation library" without the literal token.
+```
+
+---
+
+## Remediation summary for the orchestrator
+
+**ITERATE-NEEDED** — spawn the planner for a second re-plan. Two blockers must be fixed:
+
+1. **BLOCKER 1 (A17.8 delegation is fictitious):** the planner must either scope a genuine new welcome-page-DOM harness driver (a `page.goto`/new-tab driver that runs `populateMark()` and queries the live `.welcome-hero__mark svg`), or drop the "delegated to A17.8 in real Chrome" claim and honestly document the inline-SVG runtime behavior as operator-screenshot-only verified.
+
+2. **BLOCKER 2 (DEFECT 3 names a phantom failing test):** the planner must reframe the Task 2/Task 4 vitest gates around the *flake class* (ffprobe/parallel-vitest race per 04-CONTEXT #9/#10) with a re-run tolerance, correct the baseline to 184/184 GREEN and the target to 188/188, and stop naming `strict-meta-json-validation.test.ts` as a pre-existing red — it is GREEN on a clean tree.
+
+DEFECT 2, the `welcome.css` drop, thesis preservation, frontmatter, FORBIDDEN_HOOK_STRINGS lockstep, and atomic-commit structure are all correct and need no change. WARNING-1 resolves with BLOCKER 1. The 3 advisories are nice-to-fix.