rename (cosmetic): green-eye -> risc-v-gsp-rm-debugger in user-facing names, docs, CLI, launcher and CI workflow; internal greeneye package/module identifiers unchanged (includes in-flight greeneye module edits present in the tree)

1 files changed, 7 insertions, 7 deletions

diff --git a/debug/risc-v-gsp-rm-vm/docs/25-VALUE-VALIDATION.md b/debug/risc-v-gsp-rm-vm/docs/25-VALUE-VALIDATION.md
index d47b8ea..3409039 100644
--- a/debug/risc-v-gsp-rm-vm/docs/25-VALUE-VALIDATION.md
+++ b/debug/risc-v-gsp-rm-vm/docs/25-VALUE-VALIDATION.md
@@ -9,7 +9,7 @@
 
 ## 1. Why this document exists
 
-green-eye is only worth its maintenance if it turns real firmware questions
+risc-v-gsp-rm-debugger is only worth its maintenance if it turns real firmware questions
 into answers faster than static analysis and supervised hardware cycles. The
 project handoffs record those questions and their costs in wall-clock and
 cycles: the 0x59 RM-init chase (PART 91, 2026-10-01), the 20 GR counters
@@ -17,7 +17,7 @@ cycles: the 0x59 RM-init chase (PART 91, 2026-10-01), the 20 GR counters
 P6 service wiring (PART 92 ADDENDA 5–11, 2026-10-02), and the version pairing
 question (570.144 vs 570.211). This document maps each of them to a runnable
 demonstration under [`harness/value_demos/`](../harness/value_demos/), states
-the baseline cost from the handoffs, and measures the green-eye path.
+the baseline cost from the handoffs, and measures the risc-v-gsp-rm-debugger path.
 
 ## 2. Methodology
 
@@ -25,14 +25,14 @@ the baseline cost from the handoffs, and measures the green-eye path.
 
 | Class | Meaning | Where it appears |
 |---|---|---|
-| **Measured (analog)** | Wall-clock of the green-eye path on the bundled `uproc_demo` firmware, native RV64 interpreter or QEMU; answers, counts, session bytes, trace slowdown | `result.json` per demo, `artifacts/results.json` |
+| **Measured (analog)** | Wall-clock of the risc-v-gsp-rm-debugger path on the bundled `uproc_demo` firmware, native RV64 interpreter or QEMU; answers, counts, session bytes, trace slowdown | `result.json` per demo, `artifacts/results.json` |
 | **Recorded (real baseline)** | Cost actually paid on the physical path, as recorded in the handoffs (dates, cycles, PARTs, wall spans) | `real_case.static_baseline` in each `result.json`, §5 below |
 | **Projected** | What the same tool path would save on the real firmware once H2.2 executes it; labelled `projected` | `real_case.projection`; never presented as a result |
 | **Blocked** | Real firmware access requires the H2.2 QEMU device model; `blocked_on_device_model: true` | every real `.fwimage` scenario here |
 
 Fidelity is exactly docs/06: L0 instruction semantics and L1 memory behaviour
 are exercised; **L2 time/concurrency is not modelled** and **L3 device
-environment is absent**. A green-eye observation is evidence about the
+environment is absent**. A risc-v-gsp-rm-debugger observation is evidence about the
 firmware, and anything that would change `open-iov-vfio` is escalated to a
 physical capture before the product changes (docs/06 §6, docs/14 §7).
 
@@ -76,7 +76,7 @@ Measured on the reference host (CPython 3.12); numbers regenerate with
 `python3 harness/value_demos/run_all.py`. Times below are from the
 `run_all` aggregate (~18.4 s total).
 
-| # | Real scenario (source, date) | Green-eye tool | Static/Ghidra-only baseline (recorded) | Analog (measured) | Real-case projection |
+| # | Real scenario (source, date) | Risc-V GSP-RM debugger tool | Static/Ghidra-only baseline (recorded) | Analog (measured) | Real-case projection |
 |---|---|---|---|---|---|
 | s01 | 0x59 RM-init chase; fn72/fn73 (PART 91 + ADDENDA 2–7, 2026-10-01) | hook dispatcher, watch `result`, decode reply | cycles 2–13, ~11:40→16:52 ≈ 5 h 10 m; 10+ supervised boots (~5–6 min each); reply was generic `0x59` | **1.14 s**; 3/3 commands consumed and decoded; FAULT traps before the reply store | one hook + one watchpoint per command once H2.2 boots the image (blocked) |
 | s02 | 20 GR per-channel counters (PARTs 46–64, 2026-09-24…29) | watch publication field, per-slot readback | ~5 days; PART 49 “only 4 of 20 counters ever moved”; ~2–3 s pin vs ~2 s client deadline | **1.34 s**; 20/20 slots published, 28 stores, store PCs captured | per-channel page watchpoints on real counter pages (blocked) |
@@ -280,7 +280,7 @@ every later version.
 
 ## 7. OODA-loop compression
 
-| Stage | Before (real path, as recorded) | After (green-eye analog, measured) |
+| Stage | Before (real path, as recorded) | After (risc-v-gsp-rm-debugger analog, measured) |
 |---|---|---|
 | **Observe** | one supervised boot + capture per hypothesis: 5–6 min, fail-safe discipline, one device-write experiment per cycle | launch 0.001–0.13 s, then hooks/watchpoints and bounded runs: 0.2–5.8 s per question |
 | **Orient** | manual LOGINIT/LOGRM/NOCAT ring decode, static reports (REPORT3–10), hours per campaign; the ring was invisible until cycle 11 | `analyze`/`compare`/`Memory.diff` with named symbols: seconds, e.g. s05 attributes every changed byte to a schema field |
@@ -288,7 +288,7 @@ every later version.
 | **Act** | rebuild + supervised boot; escalate every conclusion to a physical capture | re-run the session (seconds); product change still gated on physical confirmation (docs/06 §6, docs/14 §7) |
 
 The compression is not “the simulator replaces the hardware”; it is the loop
-around each physical experiment. green-eye reduces the number of physical
+around each physical experiment. risc-v-gsp-rm-debugger reduces the number of physical
 cycles needed to reach a confident hypothesis and produces the evidence pack
 that makes the eventual physical confirmation cheap (s10).