docs: refresh status wording after the 64/64 baseline and the physical-backend lock

1 files changed, 12 insertions, 9 deletions

diff --git a/docs/README.md b/docs/README.md
index 284ca76..5f9a32f 100644
--- a/docs/README.md
+++ b/docs/README.md
@@ -98,7 +98,7 @@ and [`01-orientation/02-the-ai-edge-and-ecosystem.md`](01-orientation/02-the-ai-
 
 ## 3. Where is the project today?
 
-**Honest status (2026-09-29):**
+**Honest status (2026-10-01):**
 
 | Area | State |
 |------|-------|
@@ -107,8 +107,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 | 🟡 Partially — `cuInit` and device enumeration work; the client reaches `cuCtxCreate` and currently ends in a forced `999` on a completion wait while the completion/translation plumbing is made reliable. 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 | 🔴 Not yet — context creation must complete first, then real work forwarding; the execution backend is chosen but not started ([`03-architecture/08-physical-gpu-integration.md`](03-architecture/08-physical-gpu-integration.md)); today only decoded memsets/copies/semaphore releases execute, in the host |
+| 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 | 🔴 Not yet — the runtime client initializes and the kernel launch is queued, but execution awaits the backend; the mechanism is chosen (module-owned GPU + real GSP session) with ownership + firmware staging verified and the power-domain lock implemented pending supervised verification ([`03-architecture/08-physical-gpu-integration.md`](03-architecture/08-physical-gpu-integration.md)); the real GSP boot has not started, and today only decoded memsets/copies/semaphore releases execute, in the host |
 | OpenGL / Vulkan | 🔴 Not yet |
 | Windows guest | 🔴 Not yet |
 | Multi-tenant isolation (VFs, mdev-per-VM) | 🟡 Designed, partially implemented |
@@ -116,14 +116,17 @@ and [`01-orientation/02-the-ai-edge-and-ecosystem.md`](01-orientation/02-the-ai-
 We also know exactly where the CUDA bring-up stands and what the next step is:
 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 client reaches context creation, which currently ends on a
-completion wait while decoded work is made to execute reliably. The full
+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
 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).
-Beyond that, the missing piece for kernel execution is forwarding the guest's
-*work* (push buffers, page trees, execution) to the physical GPU under our
-control; the chosen backend — a module-owned GPU running its real GSP firmware
-as the resource-manager server — is specified in
+The remaining frontier is real execution on the physical GPU: the runtime client
+initializes and queues a kernel launch, but does not execute it. The chosen
+backend — a module-owned GPU running its real GSP firmware as the
+resource-manager server — has verified ownership + firmware staging and an
+implemented (pending supervised verification) power-domain lock; the real GSP
+boot has not started. It is specified in
 [`03-architecture/08-physical-gpu-integration.md`](03-architecture/08-physical-gpu-integration.md).
 
 For the visual end-state map and the cross-component call paths, see