docs: engineering-operations playbook and project-wide status accuracy pass

- docs/eng-ops.md gains Part II, live physical-backend engineering
  operations: hard rules, the full module-parameter matrix, the routine
  supervised cycle and clean-release checklist, the debugfs inventory,
  how to read gsp-phys-state, a debugging scenario catalogue
  (CTXNOTVALID/promote wedge, fail-safe WPR2, unload hangs, guest wedges,
  MMU/PTE and PBDMA faults, relay symptoms), a hazard register (crash
  causes and debugging side effects), the physical-backend OODA loop, and
  the work-context map with porting flows
- architecture, implementation, operations, orientation, getting-started,
  portability, ecosystem and reference docs corrected to the current
  state: CUDA driver-API smoke green, CE-class work forwarding and
  engine-authored releases plus fault relay in place (default off), GR
  execution blocked on engine-context validity, the promote wedge and
  designed locked fail-safe, and P5 wave-2 subsumed
- internal-reference cleanup in tracked docs (no analysis-source or
  local-archive references); historical architecture document bannered
- README reading list and STATE-CURRENT frontier refreshed; new pages
  (runbook, green-eye user guide, porting sequence, porting/packaging
  notes) linked from the tree

Link check: scripts/check-docs-links.py passes (56 files, no broken links).

1 files changed, 50 insertions, 14 deletions

diff --git a/docs/README.md b/docs/README.md
index 61aa529..77f4069 100644
--- a/docs/README.md
+++ b/docs/README.md
@@ -98,7 +98,10 @@ and [`01-orientation/02-the-ai-edge-and-ecosystem.md`](01-orientation/02-the-ai-
 
 ## 3. Where is the project today?
 
-**Honest status (2026-10-01):**
+**Honest status (2026-10-02):**
+
+A dated snapshot of this status, refreshed on every progress check, is kept at
+[`../STATE-CURRENT.md`](../STATE-CURRENT.md).
 
 | Area | State |
 |------|-------|
@@ -107,8 +110,8 @@ and [`01-orientation/02-the-ai-edge-and-ecosystem.md`](01-orientation/02-the-ai-
 | GSP-RM message queue + RPC transport | ✅ Working |
 | GSP-RM controls: device/fb/bus tables, CE caps, vaspace, GMMU static info | 🟡 Mostly — the engine inventory now includes the async copy engine and the CE capabilities match the device; reply fidelity for the remaining consumed fields is still being tightened |
 | Guest `nvidia.ko` probe, `nvidia-smi` | ✅ Working (TU104) |
-| Guest CUDA driver (`libcuda`) startup | ✅ Driver-API baseline — `cuInit`, device enumeration, `cuCtxCreate`, `cuMemAlloc`, copies, free and destroy complete end to end; the smoke test prints `ALL OK` and the 64-byte payload round-trips exactly (64/64, re-verified 2026-10-01 on the current build). See [`04-implementation/01-known-knowns-and-unknowns.md`](04-implementation/01-known-knowns-and-unknowns.md) and [`../userspace/cuda/READ-ME-FIRST.md`](../userspace/cuda/READ-ME-FIRST.md) |
-| CUDA kernel execution | 🟡 The backend is live: the module owns the physical GPU and its real GSP-RM initialized, serves the full static-config reply and shuts down cleanly; a host resource-manager client now allocates memory/VAS/page-directory/TSG/channel and has executed the first real copy on the physical copy engine (4 KiB, semaphore released, dst==src, 2026-10-01). What remains is wiring that session into the guest-facing path so guest submissions execute there ([`03-architecture/11-physical-backend-guest-wiring.md`](03-architecture/11-physical-backend-guest-wiring.md)); see also [`03-architecture/08-physical-gpu-integration.md`](03-architecture/08-physical-gpu-integration.md) |
+| Guest CUDA driver (`libcuda`) startup | ✅ Driver-API baseline — `cuInit`, device enumeration, `cuCtxCreate`, `cuMemAlloc`, copies, free and destroy complete end to end; the smoke test prints `ALL OK` and the 64-byte payload round-trips exactly (64/64, re-verified 2026-10-02 on the current build). See [`04-implementation/01-known-knowns-and-unknowns.md`](04-implementation/01-known-knowns-and-unknowns.md) and [`../userspace/cuda/READ-ME-FIRST.md`](../userspace/cuda/READ-ME-FIRST.md) |
+| CUDA kernel execution | 🟡 Copy-engine-class guest copies and their releases are forwarded to the real hardware with release and fault relay in place (parameters default off); GR (graphics/compute) execution is the open wall — the host GR ladder brings up a GR0 channel with a compute-class object, but its first push faults on a context that was never committed. The device is currently held in the designed locked fail-safe awaiting a supervised reboot. See [`03-architecture/11-physical-backend-guest-wiring.md`](03-architecture/11-physical-backend-guest-wiring.md), [`03-architecture/08-physical-gpu-integration.md`](03-architecture/08-physical-gpu-integration.md) and [`../STATE-CURRENT.md`](../STATE-CURRENT.md) |
 | OpenGL / Vulkan | 🔴 Not yet |
 | Windows guest | 🔴 Not yet |
 | Multi-tenant isolation (VFs, mdev-per-VM) | 🟡 Designed, partially implemented |
@@ -118,14 +121,16 @@ the userspace `libcuda` segfault was fixed (an RM allocation reply now echoes
 the request parameters instead of returning zeros), the engine inventory is
 complete, and the driver-API smoke test now completes end to end — `cuCtxCreate`
 returns and the 64-byte payload round-trips exactly (64/64, re-verified
-2026-10-01 on the current build). The full
+2026-10-02 on the current build). The full
 mechanism, with offsets and the decompiled call path, is in
 [`../userspace/cuda/docs/05-570.144-decompilation.md`](../userspace/cuda/docs/05-570.144-decompilation.md).
-The remaining frontier is guest-facing execution: the runtime client initializes
-and queues a kernel launch, and the physical backend now executes real work (the
-first copy-engine transfer completed on hardware — 4 KiB with the semaphore
-released and dst==src, 2026-10-01) — but the two planes are not yet wired
-together. The backend, a module-owned GPU running its real GSP firmware as the
+The remaining frontier is guest-facing execution: copy-engine-class copies and
+their releases are forwarded to real hardware with release relay and fault
+relay in place (parameters default off); GR execution is the open wall — the
+host GR ladder brings up a GR0 channel with a compute-class object, but its
+first push faults on an engine context that was never committed. The device is
+currently held in the designed locked fail-safe awaiting a supervised reboot.
+The backend, a module-owned GPU running its real GSP firmware as the
 resource-manager server, is specified in
 [`03-architecture/08-physical-gpu-integration.md`](03-architecture/08-physical-gpu-integration.md);
 the bridge from the live session to the guest-facing mdev/VFIO path is specified
@@ -170,16 +175,36 @@ Read in order if you are new. Jump directly if you know what you need.
 | 18 | [Performance, correctness, security](05-operations/01-performance-correctness-security.md) | developers, auditors | 25 min |
 | 19 | [Debugging and maintenance workflows](05-operations/02-debugging-and-maintenance-workflows.md) | developers, maintainers | 25 min |
 | 20 | [GSP in a RISC-V VM (green-eye, experimental)](05-operations/03-risc-v-gsp-rm-vm.md) — **# TOOL IN DEVELOPMENT - NOT READY YET!** | developers, analysts | 15 min |
-| 21 | [Hardware and software matrix](06-portability/hardware-software-matrix.md) | developers, integrators | 20 min |
-| 22 | [Developer onboarding and standards](07-developers/onboarding-and-standards.md) | contributors | 20 min |
-| 23 | [HAAEEP and collaboration](08-ecosystem/haaeep-and-collaboration.md) | stakeholders, partners | 20 min |
-| 24 | [Glossary and FAQ](09-reference/glossary-and-faq.md) | everyone | reference |
+| 21 | [green-eye user guide (experimental)](05-operations/04-green-eye-user-guide.md) — **# TOOL IN DEVELOPMENT - NOT READY YET!** | developers, analysts | 15 min |
+| 22 | [Defensive Operations Runbook](RUNBOOK.md) | maintainers, operators | 20 min |
+| 23 | [Engineering operations](eng-ops.md) — tool admission and workflows (Part I) plus live physical-backend operations (Part II) | maintainers, developers | 20 min |
+| 24 | [Hardware and software matrix](06-portability/hardware-software-matrix.md) | developers, integrators | 20 min |
+| 25 | [Developer onboarding and standards](07-developers/onboarding-and-standards.md) | contributors | 20 min |
+| 26 | [HAAEEP and collaboration](08-ecosystem/haaeep-and-collaboration.md) | stakeholders, partners | 20 min |
+| 27 | [Glossary and FAQ](09-reference/glossary-and-faq.md) | everyone | reference |
+
+<!-- change (2026-10-02): insert the green-eye user guide and the Open-IOV
+Defensive Operations Runbook into the reading list; renumber rows 21-24 to
+23-26; additive only. -->
+
+<!-- change (2026-10-02): insert the engineering-operations document into the
+operations group; renumber rows 23-26 to 24-27; additive only. -->
 
 Row 15 is a **deferred future goal**: host NVIDIA-driver acceleration over a
 virtual function. The feasibility verdict and a first design sketch are
 recorded there for planning; it is not on the active critical path (guest CUDA
 execution, multi-VM, 3D, performance come first).
 
+> **Tool documentation is under development.** The per-tool pages under
+> [`tools/`](tools/README.md) (for example `rmtool.md` and `rmtop.md`) are
+> being expanded; until they are complete, start with the
+> [Defensive Operations Runbook](RUNBOOK.md) and the
+> [green-eye user guide](05-operations/04-green-eye-user-guide.md).
+
+<!-- change (2026-10-02): state that the per-tool documentation section is
+under development and point readers at the RUNBOOK and the green-eye user
+guide; additive only. -->
+
 Deep-dive material lives in [`../wiki/`](../wiki/README.md) (firmware
 decompilation record, address reference, historical protocol notes). Wiki
 pages that predate the current implementation carry a status banner naming
@@ -191,6 +216,15 @@ The pre-reboot flat documents have been merged into this tree and removed
 * debugging: gdbstub/NMI workflows, the EPT-livelock case study and the
   failure taxonomy →
   [`05-operations/02-debugging-and-maintenance-workflows.md`](05-operations/02-debugging-and-maintenance-workflows.md)
+* defensive operations: incident scenarios, the OODA ordering, evidence
+  bundles and the escalation tree →
+  [`RUNBOOK.md`](RUNBOOK.md); the green-eye quickstart, tool chooser and
+  troubleshooting →
+  [`05-operations/04-green-eye-user-guide.md`](05-operations/04-green-eye-user-guide.md)
+
+<!-- change (2026-10-02): point the post-merge document map at the new RUNBOOK
+and green-eye user guide; additive only. -->
+
 * firmware runtime analysis (experimental): running GSP/uproc firmware in a
   RISC-V QEMU VM with hooks, watchpoints, memory dumps and `gsp-rm-vfio`
   accuracy measurement — **# TOOL IN DEVELOPMENT - NOT READY YET!** →
@@ -213,7 +247,9 @@ The pre-reboot flat documents have been merged into this tree and removed
   and [`06-portability/hardware-software-matrix.md`](06-portability/hardware-software-matrix.md).
 
 What remains historical is the pre-supersession wiki material and
-`old/ARCHITECTURE.md`; their status banners name the canonical document. (The
+`old/ARCHITECTURE.md`; the latter carries an explicit superseded banner
+pointing at this page, and the older wiki pages carry status banners naming
+the canonical document. (The
 former 2026-09-21 `STATE.md` snapshot is retired; its content lives on in the
 git history and its replacements above.)