1 files changed, 9 insertions, 9 deletions
diff --git a/debug/risc-v-gsp-rm-vm/docs/05-GHIDRA-BRIDGE.md b/debug/risc-v-gsp-rm-vm/docs/05-GHIDRA-BRIDGE.md
index f7f46c3..4f41d33 100644
--- a/debug/risc-v-gsp-rm-vm/docs/05-GHIDRA-BRIDGE.md
+++ b/debug/risc-v-gsp-rm-vm/docs/05-GHIDRA-BRIDGE.md
@@ -2,7 +2,7 @@
 
 > **# TOOL IN DEVELOPMENT - NOT READY YET!** See 00 for status.
 
-Ghidra answers *what is the code*; green-eye answers *what did it do*. The
+Ghidra answers *what is the code*; risc-v-gsp-rm-debugger answers *what did it do*. The
 bridge joins them in both directions: Ghidra symbols into the runtime session,
 runtime hit addresses back into the Ghidra project.
 
@@ -19,13 +19,13 @@ runtime hit addresses back into the Ghidra project.
 * CUDA `libcuda` in the host oracle: runtime base from `/proc/<pid>/maps`;
   `--bias` normalises it if you want runtime addresses in the DB.
 * The project's `decompiled_index.tsv`/bucket TSVs carry **both** program and
-  file addresses; green-eye parses both and stores the program address in
+  file addresses; risc-v-gsp-rm-debugger parses both and stores the program address in
   `symbol.extras["program_addr"]`.
 
 ## 2. Build a symbol DB from Ghidra exports
 
 ```bash
-./greeneye.sh symbols export \
+./risc-v-gsp-rm-debugger.sh symbols export \
     --names   ../../userspace/cuda/570.144/annotations/names.tsv \
     --index   ../../userspace/cuda/570.144/run/analysis/decompiled/decompiled_index.tsv \
     --exports ../../userspace/cuda/570.144/run/analysis/elf-index/exports.tsv \
@@ -38,7 +38,7 @@ the existing export scripts (`ExportFunctionIndex.java`,
 `DecompileFunctions.java`, …) to produce TSVs, then:
 
 ```bash
-./greeneye.sh symbols export --index <export.tsv> --bias 0 -o symbols-gsp.json
+./risc-v-gsp-rm-debugger.sh symbols export --index <export.tsv> --bias 0 -o symbols-gsp.json
 ```
 
 `load_index_tsv` is column-aware: it accepts
@@ -62,7 +62,7 @@ live hit to the decompiled body.
 ## 4. Annotate hits back into Ghidra
 
 ```bash
-./greeneye.sh analyze dumps/<run> --symbols symbols-gsp.json --out run.md
+./risc-v-gsp-rm-debugger.sh analyze dumps/<run> --symbols symbols-gsp.json --out run.md
 python3 - <<'PY'
 from greeneye.ghidra import export_hits
 from greeneye.symbols import SymbolDB
@@ -81,7 +81,7 @@ $GHIDRA/support/analyzeHeadless <proj_dir> <project> -process <program> -noanaly
 ```
 
 `ExportForGreenEye.java` is the reverse helper: it walks the current program
-and writes a green-eye-compatible `addr<TAB>name<TAB>size` TSV.
+and writes a risc-v-gsp-rm-debugger-compatible `addr<TAB>name<TAB>size` TSV.
 
 `greeneye.ghidra.render_ghidra_command(proj_dir, project, program, hits_tsv)`
 renders the `analyzeHeadless … MarkGreenEyeHits.java` command line above for
@@ -92,11 +92,11 @@ scripts (the helper is not wired into the CLI).
 Two practical routes today:
 
 1. `greeneye decompose/decompile` → note the file vaddr → script
-   `s.hook("0x…")` (green-eye translates to runtime via the bias you loaded).
+   `s.hook("0x…")` (risc-v-gsp-rm-debugger translates to runtime via the bias you loaded).
 2. Use `symbols export` from the Ghidra index, then `s.hook("<name>")` by
    name — the most robust route across recompilations.
 
-A future Ghidra-side green-eye console (roadmap item) can call
+A future Ghidra-side risc-v-gsp-rm-debugger console (roadmap item) can call
 `greeneye` through its CLI to set breakpoints directly from the tool.
 
 ## 6. Limits
@@ -104,6 +104,6 @@ A future Ghidra-side green-eye console (roadmap item) can call
 * Wrapper-generated functions are re-laid-out between driver patch versions;
   transfer names, never raw wrapper addresses (the CUDA playbook's lesson).
 * The decompiler does not recover struct types; structure schemas for
-  green-eye decoding must be written or exported separately.
+  risc-v-gsp-rm-debugger decoding must be written or exported separately.
 * `decompiled_index.tsv` buckets are large and gitignored; keep symbol JSONs
   small (name/size/subsystem only) if they must be tracked.