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

diff --git a/debug/risc-v-gsp-rm-vm/docs/10-RELATED-WORK.md b/debug/risc-v-gsp-rm-vm/docs/10-RELATED-WORK.md
index a2a45db..90ca799 100644
--- a/debug/risc-v-gsp-rm-vm/docs/10-RELATED-WORK.md
+++ b/debug/risc-v-gsp-rm-vm/docs/10-RELATED-WORK.md
@@ -11,7 +11,7 @@ frida-agent requires a hosted OS process. The GSP image is bare-metal RV64
 with its own libos; there is nothing to inject into, and even a hypothetical
 RISC-V port would need an OS layer the firmware does not have.
 
-**Where the Frida *idea* lives in green-eye:** the scripting model. `Session`
+**Where the Frida *idea* lives in risc-v-gsp-rm-debugger:** the scripting model. `Session`
 offers `hook`/`watch`/`memory`/`events` with Python callbacks, which is the
 part of Frida that matters for this workflow. The difference is transport:
 RSP to QEMU instead of an injected agent.
@@ -24,23 +24,23 @@ guest today.
 ## 2. GDB / gdbstub
 
 QEMU's gdbstub is the transport both tools share. GDB itself is still useful
-for *debugging green-eye* (stub behaviour, protocol traces), and `gdb
+for *debugging risc-v-gsp-rm-debugger* (stub behaviour, protocol traces), and `gdb
 -multiarch` can inspect the same target interactively. It is not the
 instrumentation layer here because:
 
 * every operation becomes a subprocess/parse problem instead of an API call;
 * recording, symbol annotation, structure decoding and session diffing would
   have to be rebuilt around GDB/MI anyway;
-* the project already uses GDB Python scripts for the CUDA corpus; green-eye
+* the project already uses GDB Python scripts for the CUDA corpus; risc-v-gsp-rm-debugger
   is the equivalent for firmware, with a stronger data model.
 
 ## 3. QEMU TCG plugins
 
 The correct complement, not a competitor: plugins execute inside QEMU and can
 observe **every** instruction and memory access, which gdbstub breakpoints
-cannot. green-eye's `qemu/greeneye_trace.c` emits a JSONL access trace for
+cannot. risc-v-gsp-rm-debugger's `qemu/greeneye_trace.c` emits a JSONL access trace for
 exactly this; integrating it into the session format is R4 on the roadmap.
-Rule of thumb: use green-eye hooks for semantics ("handler X ran with these
+Rule of thumb: use risc-v-gsp-rm-debugger hooks for semantics ("handler X ran with these
 args") and TCG plugins for coverage/heatmaps ("every write to this window").
 
 ## 4. Unicorn / emulator libraries
@@ -55,17 +55,17 @@ reason the roadmap defers that work.
 
 `rr` does not support RISC-V guests and records at the host-process level.
 QEMU's own record/replay (`-icount`) can provide deterministic reruns later;
-green-eye's session recording occupies a different niche (semantic events,
+risc-v-gsp-rm-debugger's session recording occupies a different niche (semantic events,
 not full replay) and can coexist.
 
 ## 6. Comparison table
 
-| Tool | Layer | RISC-V firmware | green-eye relationship |
+| Tool | Layer | RISC-V firmware | risc-v-gsp-rm-debugger relationship |
 |---|---|---|---|
 | Frida | userland process injection | no | conceptual model only |
-| GDB + gdbstub | execution control | yes (transport) | debugging green-eye; same stub |
+| GDB + gdbstub | execution control | yes (transport) | debugging risc-v-gsp-rm-debugger; same stub |
 | QEMU TCG plugin | full instruction/memory trace | yes | complement (R4) |
-| green-eye | semantic instrumentation + recording + analysis | yes | this tool |
+| risc-v-gsp-rm-debugger | semantic instrumentation + recording + analysis | yes | this tool |
 | Unicorn/rv8/etc. | CPU emulation library | yes | R2 candidate |
 | Ghidra | static decompilation | yes | symbol/hit bridge (05) |