diff --git a/docs/plans/counter-asic-3-status.md b/docs/plans/counter-asic-3-status.md
index cce1b488d..9cf8984c6 100644
--- a/docs/plans/counter-asic-3-status.md
+++ b/docs/plans/counter-asic-3-status.md
@@ -192,7 +192,7 @@ No publish, no manifest, nothing on the live devnet; PC 2 one job at a time with
 | G5 | the PC-built Windows workers and the Mac workers from the same commit | GREEN, one gap named | the Windows workers cross-built on the Mac from a522d04 as 0.3.11's G5 did (the build job has no worker unit: a tooling gap): igneum-worker-cuda.exe e563126e... (1,536,512 bytes), igneum-worker-opencl.exe 7fce1249... (478,208), both with the resource block, mingw not bit-reproducible (a link-time stamp); the Mac igneum-bench 30c70754... from the same tree, the binary G4b mined with; the node and app from PC 2 job build-20261006-155958, every sha256 verified |
 | G6 | the node suites on PC 2 with --features igneum-pow, from a fork branch off the current release tip | GREEN | fork ca3-v4-node 5f7e0543 on release-0.3.13-node; PC 2 job build-20261006-155958 (15:59 to 16:08Z under the lock, the app untouched, the prover on): every stage ok in 392 s; kaspa-consensus 98 (2.0's flake did not recur), consensus-core 109 + 7 (`override_params_carry_the_program_class_v4_activation`), kaspa-pow 15 with the v4 engine test under the feature, p2p-flows 33, igneum-app 112 + 26 + 8 |
 
-BLOCKER before any cut (found by the hash lane, 17:0x UTC): `program_id(3, seed, attempt)` is class-independent, so all seven v4 packs carry the same program id as the v3 control of their seed (73bcbfe8ccf988f1), and a stale worker across the activation would see no id mismatch (2.0's G4 id check cannot fire on it; G4's per-epoch ids differ only because each epoch has its own seed). The fix is on the v4 seam, assigned to the node lane: a generator-4 stamp in the id so a v3 and a v4 program of one seed differ, v2 and v3 ids byte-identical, the packs re-exported (fingerprints unchanged, ids moved), G4's id assertion and the fuzz re-run. FIX MERGED (ca3-v4-node 7c22d0d, 17:3x UTC): the trap was the CLI's --era path (stamp_era stamped generator 3 on any class), not the chain seam (the fork already stamped generator 4 and its kaspa-pow test asserts the same-seed v3 and v4 ids differ); now generate_era and the CLI stamp the generator from the class, the shadow block marks class v4 in packcheck.rs, packfile.h and main.swift (a generator-3 pack with a shadow block is refused as "a v4 program stamped v3", a generator-4 pack without one refused; the ladder packs stay loadable); v2 and v3 ids byte-identical; the crate suite 97 of 97 on the merged tree; the seven gate packs re-exported with generator 4, class "v4" and program id c120d7963abdcd96 (the v3 control keeps 73bcbfe8ccf988f1), only the generator, id, class and comment lines changed, the kernels and vectors byte-identical. Still open before the cut is green: the G4 re-run with the id assertion and its own failed case (node lane, running), the Metal fingerprints of the re-exported packs (running), the fuzz, edge, stats and determinism re-run on the fixed class (hash lane). The PC 1 AMD rows taken on the old-id packs stand: the id is not an input to the hash.
+BLOCKER before any cut (found by the hash lane, 17:0x UTC): `program_id(3, seed, attempt)` is class-independent, so all seven v4 packs carry the same program id as the v3 control of their seed (73bcbfe8ccf988f1), and a stale worker across the activation would see no id mismatch (2.0's G4 id check cannot fire on it; G4's per-epoch ids differ only because each epoch has its own seed). The fix is on the v4 seam, assigned to the node lane: a generator-4 stamp in the id so a v3 and a v4 program of one seed differ, v2 and v3 ids byte-identical, the packs re-exported (fingerprints unchanged, ids moved), G4's id assertion and the fuzz re-run. FIX MERGED (ca3-v4-node 7c22d0d, 17:3x UTC): the trap was the CLI's --era path (stamp_era stamped generator 3 on any class), not the chain seam (the fork already stamped generator 4 and its kaspa-pow test asserts the same-seed v3 and v4 ids differ); now generate_era and the CLI stamp the generator from the class, the shadow block marks class v4 in packcheck.rs, packfile.h and main.swift (a generator-3 pack with a shadow block is refused as "a v4 program stamped v3", a generator-4 pack without one refused; the ladder packs stay loadable); v2 and v3 ids byte-identical; the crate suite 97 of 97 on the merged tree; the seven gate packs re-exported with generator 4, class "v4" and program id c120d7963abdcd96 (the v3 control keeps 73bcbfe8ccf988f1), only the generator, id, class and comment lines changed, the kernels and vectors byte-identical. The hash lane's re-run on the fix is GREEN (ca3-v4-hash ca61dec, merged; `hash-gates.md` "Follow-up 1"): the crate suite 97 of 97; the seven packs re-exported here equal the tree's (0 differing files); the fingerprints unchanged on the rebuilt Metal and Apple OpenCL harnesses (all eight); Mac G2 through the `class=v4` token 1,024 of 1,024 on all eight packs, both harnesses; the fuzz 200 programs and 800 units, stats, edge and determinism 4 of 4 on the class and 4 of 4 era-composed, the same-seed v3 and v4 ids now differ (`assert_ne`). Still open before the cut is green: the G4 re-run with the id assertion and its own failed case (node lane, running) and the Metal fingerprints from the node lane's packbench (running). Two conditions ride with the fix: every kit sent to a PC carries the re-exported packs (the AMD G2 kit is being rebuilt from the merged tree), and the mixer.rs harness change rides with any merge of 7c22d0d (it does, on ca3-coord). The PC 1 AMD rows taken on the old-id packs stand: the id is not an input to the hash.
 
 The per-tier cost line of the candidate (item 8, measured): the 5090 -0.2 percent of rate at 350 to 431 W (a rig about 23 percent more electricity), the M5 Max -1.5 percent at 21 to 37 W, pool users nothing, the verifier +0.17 ms per warp; the 9070 XT and the 4070 rows land with the PC 1 jobs. Owed before the cut, besides the blocker: AMD G2 (1,024 nonces on the 9070 XT, queued on PC 1 after the Ember run), the AMD watts (the sampler fix is in; the re-run queued), the 2019-class core (O-1.14; the US laptop's CPU could answer it with a Windows igneum-pow build, a proposal), the G2 found-lines file and digest and the 200 KB report cap (tooling, in hand on ca3-v4-hash).