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, 10 insertions, 10 deletions

diff --git a/docs/05-operations/02-debugging-and-maintenance-workflows.md b/docs/05-operations/02-debugging-and-maintenance-workflows.md
index cfc452d..975b3dc 100644
--- a/docs/05-operations/02-debugging-and-maintenance-workflows.md
+++ b/docs/05-operations/02-debugging-and-maintenance-workflows.md
@@ -192,13 +192,13 @@ Watch the serial log afterwards for backtraces. A truly hard-wedged vCPU
 (spinning on a faulting MMIO instruction) may print nothing — use the gdbstub
 instead.
 
-### 3.9 Firmware runtime analysis — green-eye (experimental)
+### 3.9 Firmware runtime analysis — risc-v-gsp-rm-debugger (experimental)
 
 > **# TOOL IN DEVELOPMENT - NOT READY YET!**
 
 For firmware-side questions (what does the GSP/uproc server do at runtime,
 what does it read/write, how do its state machines evolve), the experimental
-green-eye tooling runs uproc/GSP firmware in a `qemu-system-riscv64` VM with
+risc-v-gsp-rm-debugger tooling runs uproc/GSP firmware in a `qemu-system-riscv64` VM with
 hooks, watchpoints, memory dumps and session recording, without a physical
 GPU, WPR2 risk or a reboot. See
 [`03-risc-v-gsp-rm-vm.md`](03-risc-v-gsp-rm-vm.md) for purpose, status and
@@ -322,13 +322,13 @@ version × each hardware family, run the step-5 bring-up sequence. When adding
 a version, extend the matrix rather than replacing the old column —
 regressions across versions are the cheapest bugs to catch.
 
-### 4.1.1 Green-eye-assisted upgrade/porting workflow (experimental)
+### 4.1.1 Risc-V GSP-RM debugger-assisted upgrade/porting workflow (experimental)
 
-<!-- change (2026-10-02): add the green-eye probe -> symbols -> version diff ->
+<!-- change (2026-10-02): add the risc-v-gsp-rm-debugger probe -> symbols -> version diff ->
 portability matrix -> decide pipeline to the upgrade runbook, with pointers to
-the new RUNBOOK and green-eye user guide; additive only. -->
+the new RUNBOOK and risc-v-gsp-rm-debugger user guide; additive only. -->
 
-For firmware-side questions the experimental green-eye tooling (see
+For firmware-side questions the experimental risc-v-gsp-rm-debugger tooling (see
 [`03-risc-v-gsp-rm-vm.md`](03-risc-v-gsp-rm-vm.md)) turns steps 3–5 above into
 a repeatable pipeline that produces attachable evidence before any emulation
 change. It never replaces the physical backend when silicon truth is required,
@@ -336,11 +336,11 @@ and it never touches a guest, a kernel module or the installed driver.
 
 | Rung | Command (from `debug/risc-v-gsp-rm-vm/`) | Output |
 |---|---|---|
-| Probe | `./greeneye.sh probe <new.fwimage> --symbols symbols-<ver>.json --record` | first-divergence report; first-touch map |
-| Symbols | `./greeneye.sh symbols export --index <export.tsv> --bias 0 -o symbols-<ver>.json` | runtime-address symbol DB with provenance |
+| Probe | `./risc-v-gsp-rm-debugger.sh probe <new.fwimage> --symbols symbols-<ver>.json --record` | first-divergence report; first-touch map |
+| Symbols | `./risc-v-gsp-rm-debugger.sh symbols export --index <export.tsv> --bias 0 -o symbols-<ver>.json` | runtime-address symbol DB with provenance |
 | Version diff | `python3 harness/version_diff.py --old <old> --new <new> --out dumps/vdiff-<ver>` | shape/symbol/corpus/probe/behavior diff plus the M1–M6 skeleton |
 | Portability matrix | `python3 harness/portability_matrix.py --target <old> --target <new> --out dumps/matrix-<ver>` | per-target sessions and per-pair `compare` reports |
-| Decide | `./greeneye.sh compare dumps/<old-run> dumps/<new-run> --symbols` | symbol-attributed deltas; a product change only after physical confirmation |
+| Decide | `./risc-v-gsp-rm-debugger.sh compare dumps/<old-run> dumps/<new-run> --symbols` | symbol-attributed deltas; a product change only after physical confirmation |
 
 Decision discipline: verify the pairing first; behaviour that moved without a
 code change is usually a state/ordering fix; changed code on a live path is
@@ -348,7 +348,7 @@ prioritised; a symbol never hit in either run is a coverage gap, not dead code.
 The full incident procedures (symptoms, evidence, response order, rollback) are
 in the [Open-IOV Defensive Operations Runbook](../RUNBOOK.md) S1 and its OODA
 ordering; the quickstart and tool chooser are in the
-[green-eye user guide](04-green-eye-user-guide.md).
+[risc-v-gsp-rm-debugger user guide](04-risc-v-gsp-rm-debugger-user-guide.md).
 
 ### 4.2 New guest driver version