debug: green-eye porting automation - new-device and driver-version port scripts, simulator packaging, porting docs; control-discovery fix

1 files changed, 13 insertions, 6 deletions

diff --git a/debug/risc-v-gsp-rm-vm/docs/22-PORTING-CUDA-AND-DEVICES.md b/debug/risc-v-gsp-rm-vm/docs/22-PORTING-CUDA-AND-DEVICES.md
index 30f4720..ad8a5e7 100644
--- a/debug/risc-v-gsp-rm-vm/docs/22-PORTING-CUDA-AND-DEVICES.md
+++ b/debug/risc-v-gsp-rm-vm/docs/22-PORTING-CUDA-AND-DEVICES.md
@@ -71,7 +71,7 @@ tools/cudatool.py delta   <old>/run/libcuda.so.<old> <new>/run/libcuda.so.<new>
 | Step | Existing project tooling | green-eye addition |
 |---|---|---|
 | Export/interface diff | `tools/cudatool.py delta` | — |
-| Function matching / name-transfer measurement | `tools/cudatool.py fdematch --names <names.tsv>` | — |
+| Function matching / name-transfer measurement | `tools/cudatool.py fdematch <old-lib> <new-lib> --names <names.tsv>` | — |
 | Corpus-level diff (added/removed/resized functions) | `tools/diff_corpus.py <old_index> <new_index>` | — |
 | Name transfer + corpus annotation | `ApplyNameMap.java` (`--dry-run` first), `tools/annotate_corpus.py` | `./greeneye.sh symbols export` builds a runtime-address symbol DB from the same index/names |
 | Driver-API smoke | `tools/test/cuda_drv_test.c` compiled as `/tmp/cdt` (prints `ALL OK`) | `./greeneye.sh symbols resolve --db ... <addr>` spot-checks transferred addresses per call path |
@@ -241,9 +241,11 @@ The project's support ladder is `docs/06-portability/hardware-software-matrix.md
 1. Run `harness/portability_matrix.py` across the reference and candidate
    device firmware with the same scenario options (docs/18 §1); keep
    `<out>/portability-report.json`, per-pair compare reports and sessions.
-2. The planned version-diff/CI pipeline (docs/21-CI-RELEASE-PIPELINE.md,
-   planned) is where those reports become release-gated artifacts; until it
-   exists, attach them to the matrix process manually.
+2. The version-diff/CI pipeline
+   ([`docs/21`](21-CI-RELEASE-PIPELINE.md)) packages those reports into
+   release-gated artifacts; the porting scaffolds
+   ([`docs/28`](28-PORTING-AUTOMATION.md)) wrap it per version as unadmitted
+   pilots (evaluation in future-eng-ops F2/F3).
 3. Update the device profile (documentation today; `config/hardware/*.yaml` is
    not read by code — do not claim configuration-driven portability).
 4. Validate on the physical device with the supervised harness before claiming
@@ -345,9 +347,14 @@ Architecture (P3):
 | Differential execution and reimplementation loop | H4.5 | every port lands with A/B sessions and the M1–M6 table | reference-capture pipeline |
 | Adjacent-controller work for GB10-class bring-up | H5 | PMU/SEC2/ACR/SOE models, cross-controller sessions | H2.2 |
 | Multi-target orchestration | R6 / docs/18 | one report across firmware/device targets | v0.1 stable |
-| Version diff and release gating | planned (docs/21) | CI pipeline that gates a port on the evidence bundle | pipeline implemented |
-| Control discovery | planned (docs/19) | systematic control/class inventory across versions | document exists |
+| Version diff and release gating | implemented (docs/21) | CI pipeline that gates a port on the evidence bundle | pipeline implemented |
+| Control discovery | implemented (docs/19) | systematic control/class inventory across versions | document exists |
 
 Program-level success criterion served here: a new GSP version (or device) can
 be triaged — inventory diff + behaviour diff + metric table — in **hours**,
 with recorded evidence.
+
+<!-- change (2026-10-02): fix the fdematch invocation (it needs two libraries),
+and replace "planned docs/19/21" with their implemented status plus the docs/28
+scaffolds; scope: §2.2, §3.5, §6 only; benefit: commands run as written and
+status tables match the tree. -->