diff --git a/release/director/plan.md b/release/director/plan.md
index abe8e78e..56a7c021 100644
--- a/release/director/plan.md
+++ b/release/director/plan.md
@@ -140,7 +140,7 @@ status: `open → doing → done`, or `closed`. each row is one unit; its accept
 | C2a | §5.5 body malleation: a body that is not the one its header commits to (does not split, empty against a non-empty `tx_root`, `tx_root` mismatch) makes the node mark **the valid header** invalid (`engine_api.rs:136-139` `invalidate(id)` on any `decode_body` error, as `specs/chain.md` §5.5 says: "a block failing 6–8 marks the header invalid"), so a peer relaying an honest header with a corrupted body makes the node refuse the honest block while the id stays in the rejected set (the class of Bitcoin CVE-2012-2459). Found by C2's generator (run 40393654353, session 98). Fix: check the commitment (split + `tx_root`) first; a body that fails it is dropped without touching the header; only failures after the match invalidate | soft3 · wide, `decision` (changes `specs/chain.md` §5.5: D6, the owner's hand) | a PR into `release/phase1` with the §5.5 wording and the engine change, and a test that sends the valid header with a corrupted body, then the valid body, and gets `Extended`: red on `release/phase1`, green on the PR, on the build service; asked of the owner with a deadline before the 2026-11-02 freeze (a security fix with a failing test may merge in the freeze) | to the owner 2026-10-26 (session 101) — **receipts read and posted, #350 ready for review** (comment 6428610063). Red **40408280127** (`784f8a4` = `release/phase1` `5ff6d82` + the test only): the test FAILED at `rules.rs:288`, `case 0: the honest block was refused`, `Err(Rejected(..))` vs `Ok(Extended)`; lib 287/1. Green **40408283118** (`093f7c3` = `f047eba` + diag workflow): the test `ok`, lib **288 passed 0 failed**, every binary ok, **`warnings: 0`**; its job reads `failure` only because `upload-artifact` refused the name `c2a-diag/c2a-green` (a `/`), after every test step succeeded. #350 head `c53b409` differs from the green tree by one doc-comment and one spec cross-reference (`git diff f047eba c53b409`). Review: tagged leaf/node hashing with odd-node promotion (`tree.rs` `odd_nodes_promote_not_duplicate`) means a body passing 6a is the header's up to a hemera collision, so 6b still condemns rightly; no duplicate-leaf route. Waits on the owner (D6), deadline 2026-10-29 12:00 UTC — was doing 2026-10-26 (session 100) — **soft3#350** (draft, `decision`, `wide`, into `release/phase1`; the owner's to merge, D6): `72032b2` the test `body_malleation_never_invalidates_the_honest_header` alone (truncated, empty, wrong-`tx_root` bodies on the valid header, then the valid body → `Extended`; a 6b failure under a matching root → `Rejected` on resend), `ef18f6b` `apply::body_matches` (6a: fits `MAX_BLOCK_BYTES`, splits, non-empty, `tx_root` equal; never invalidates) then `decode_matched` (6b: invalidates as before), `f047eba` §5.5 step 6 → 6a/6b, `c53b409` section reference. Implemented by a sonnet subagent, reviewed by me: diff minimal, replay and `decoded` unchanged, the net layer keeps no id blacklist (`kernel.rs` scores the peer), corpus verdicts unchanged. Receipts dispatched on 40357603776's stand: **red** `diag/c2a-red` run **40408280127** (test commit on `release/phase1`), **green** `diag/c2a-green` run **40408283118** (fix head, whole suite, warnings). Next: read both, post them on #350, mark it ready; owner's deadline 2026-10-29 12:00 UTC |
 | C3 | the economy at genesis: the conformance vectors of registry rows 26 (passive stake earns 0), 27 (θ split), 41 (epoch record agreed) run in soft3-tests | soft3 · wide | the named vectors pass in soft3-tests on all legs | built; acceptance waits on L4 (session 58) — **verified on `release/phase1` `771e070`: every vector the three rows name is already in the crate and runs under `soft3-tests` (`cargo test --locked` in `crate/`); nothing to build.** The gates are in `cyber/launch.md`. **Row 26**, the 2-epoch vector that pays the passive position 0: `economy/vectors.rs:263-274` (+1, 0, −1 locks; `the passive position earns nothing`) is blessed as `chain.snap` `two epochs: epoch 1 record`/`payouts`/`budget, paid, pool after`, and `tests/economy.rs` `multi_epoch_settlement_end_to_end` asserts `v = 0 never earns`. **Row 27**, θ split, focus pool min(½, θ^½), integer root: `economy/tests.rs` `integers_of_section_14` holds the `specs/chain-conformance.md` §14 table (`focus_bps` 0/99/999/5,000/5,000; `cut` at 1,000 and 5,000 bps), and `coinbase_split_follows_the_active_stake_of_the_last_boundary` checks that the passive stake does not count. **Row 41**, the epoch record agreed: `two_nodes_agree_on_every_epoch_and_a_restart_replays_it` (node B fed blocks only, records equal for epochs 1–3, restart replays them), plus the blessed reorg pair. `chain/conformance.rs` `committed_chain_snap_matches_this_build` holds every `chain::economy@v1` entry to `conformance/chain.snap` (tru engine `e660d1e` = tru head in tick `20261026T121504Z`). **Not yet passing**: soft3-tests has not compiled on any leg since L4 (rehearsal 40307972588, package-resolution: `cybergraph` has no `local-storage`). The row closes on the first rehearsal after L4 with these tests green on all legs. If hemera 0.4 moves the economy digests, that is G6's drift, blessed in the PR that causes it |
 | C4 | cybernode: land the owner's soft3#406 (the node leaves soft3, proposals/cybernode.md C2–C4) on `release/phase1` | soft3 · wide | `drift` green; `crate/Cargo.lock` resolved by the build service; a rehearsal with `soft3=fix/cybernode-drift` and 40446879208's overrides in which soft3-tests, soft3-release and node-status are no worse than in 40446879208; merged | doing 2026-10-27 (session 166): **rehearsal 40553564510 is read in full. #407 causes no red, and it waits only on cybernode#1.** The stack leg is job 122363639791, 17:45:45 → 19:21:15 (95.5 min of 210). Stand (`sources.json`, `rehearsal: true`): soft3 `4041b37`, cybernode `pull/1/head` `31fca56`, simulation `pull/2/head` `5518998`. `cybernode-tests` is **green, 314 passed** (lib 310 + 2 + 1 + 1, 0 failed, 1 ignored, `warnings: false`). stack-chain-genesis, simulation-gate, conformance-snapshot, soft3-tests, soft3-release and node-status are green, and so are stack bbg, cybergraph, file, foculus, hemera, lens, nox, radio, tok, tru and vault. The reds are the baseline's own: stack-mudra (`tests/domain_compat.rs:11`), stack-neuron (`cannot update the lock file … --locked`), stack-zheng (`wrap/tests.rs:135`, 64 KiB, L3b), phase1-pins and release-notes-source. That is gate by gate against 40446879208's `release-validation.json`. sha256 of `release-validation.json` starts `973aa5ab…`. Receipt on #407: comment 6451673696. #407 is `CLEAN` (drift and test green) but is **not merged**. The `cybernode` pin must point at a commit on cybernode `main`, and `main` `52538a6` has no lock, so `cybernode-tests` would go red there. Next: once the owner merges cybernode#1, move the pin to the merge commit, run a check, and merge #407. simulation#2 merges once soft3 `main` reaches 0.11. Was (session 163): **the platform half of rehearsal 40553564510 is read, and it is green where it must be.** Stand (`sources.json`): soft3 `4041b37`, cybernode `31fca56`, simulation `5518998`. On all four platform legs, `cybernode-tests` is green with **314 passed, 0 failed, 1 ignored**, which equals C2's 314. `committed_chain_snap_matches_this_build` is ok, `exit_code: 0` and `warnings: false`. soft3-tests, soft3-release and node-status are green, and phase1-pins and release-notes-source are red, exactly as in 40446879208. No gate is worse. Receipts are in `state/run-40553564510/` (release-validation.json sha256: x86_64 linux `bc261717`, aarch64 linux `a95a9ed4`, aarch64 mac `39b507fb`, x86_64 mac `ed20eca4`), posted on #407 (comment 6450505737). Next: read the stack leg (targets stack-chain-genesis and simulation-gate green, the rest no worse than 40446879208). Once cybernode#1 merges (the owner's), move the pin to its merge commit, then merge #407. Was (session 162): **the `cybernode-tests` gate is on #407 and rehearsing.** `4041b37` (sonnet subagent, reviewed) adds the product gate `cybernode-tests` to `release/train_gates.py`: `cargo test --locked` in `cybernode/rs`, `SOFT3_CONFORMANCE_DIR=<soft3>/conformance`, 1800 s. It sits in the node tests' old slot between soft3-tests and soft3-release, so G16a's gate order holds. A missing checkout is recorded as blocked. Two unit tests are added. PR gates on `4041b37`: Release engine success (40553578257) and Components registry success (40553578073). Rehearsal **40553564510** (`--ref fix/cybernode-drift`, `cut=false`) uses 40446879208's overrides with `soft3=4041b37`, `cybernode=pull/1/head` (`31fca56`) and `simulation=pull/2/head` (`5518998`), recorded in `state/c4-gate/overrides.txt`. Its targets: cybernode-tests 314 passed on every building leg; soft3-tests, soft3-release and node-status no worse than 40446879208; stack-chain-genesis and simulation-gate green. Receipt posted on #407 (comment 6449390103). Next: read 40553564510. Once cybernode#1 merges (the owner's), move the pin to its merge commit, then merge #407. Was (session 161): **both stack reds that #406 introduced close on the train's stand; simulation's lock went to the owner as simulation#2.** Diagnostic 40547036801 (`diag/simulation-lock` `47f8f20`, never merged; soft3 `f16cc0f`, 40446879208's overrides, cybernode at cybernode#1 `31fca56`; artifacts in `state/run-40547036801/`): simulation's committed lock (sha256 `ddb2329f…`) fails `--locked` as in 40525967811; re-resolved from it, with no `generate-lockfile` (sha256 `7ca0d5c4…`), the diff is only a new `cybernode 0.1.0` entry carrying soft3 0.10.0's 23 dependencies, plus `soft3 0.11.0` depending on `cybernode` alone. **simulation-gate: success** with the train's command, 16 scenarios, 0 fail, economy's 2 expected reds, 14m 22s. **stack-chain-genesis: success**: pussy `bae85f40…`, `chain.snap: 54 entries, no drift`. Opened **cyberia-to/simulation#2** (draft, fork `cyberia-apparatus/simulation` created this session, commit `5518998`; no lane label: simulation has none and the director has read access only). **Merge order, decided (opus, no fable):** the train checks out simulation at `main` HEAD and soft3 is 0.10.0 on both `main` and `release/phase1`, so simulation#2 merged early would turn simulation-gate red the other way round. It merges when soft3 `main` carries 0.11 (#407 → `release/phase1` → #376); until then rehearsals take `simulation=pull/2/head`. Receipt posted on #407 (comment 6448798473). Next: once cybernode#1 merges, on #407 move the `cybernode` pin, add the `cybernode-tests` gate, then a rehearsal with `simulation=pull/2/head`, and merge. Was (session 160): **#407's rehearsal is read in full: it is two gates worse than 40446879208 on the stack leg, and both reds are #406's.** Rehearsal 40525967811 (manager `fix/cybernode-drift` `f16cc0f`, 40446879208's overrides; artifacts in `state/run-40525967811/`) compared gate by gate with 40446879208. The mac legs are no worse: aarch64-apple-darwin and x86_64-apple-darwin soft3-tests, soft3-release and node-status are green on both, and phase1-pins and release-notes-source are red on both, as before. The stack leg has the same reds as before (phase1-pins, release-notes-source, stack-mudra, stack-neuron, stack-zheng) **plus two new ones**: (1) **stack-chain-genesis**, green → red. The genesis build reproduces pussy particle `bae85f40…`, state_root `d48fee47…` and block0_id `73208ee2…`, but `conformance check chain` reports all 54 entries as `(new)`, so it read an empty snapshot. The run took cybernode `main` `52538a6` (`sources.json`), whose `cli.rs:906` defaults `--snap` to cybernode's own `conformance/`. cybernode#1 `31fca56` already makes that default `chain_snap_path()`, the soft3 sibling, so this red closes when #1 merges. (2) **simulation-gate**, green → red in 0.165 s, exit 101: `cannot update the lock file …/simulation/Cargo.lock because --locked was passed`. simulation-chain takes soft3 by path (`../../soft3/crate`, feature `sim`), and its lock at `5483a3f` still records `soft3 0.10.0` with the node inline, while #406 makes soft3 0.11.0 depending on `cybernode`. simulation is `push: false` to the director, so its lock goes to the owner from a fork, as cybernode#1 did. Dispatched diagnostic **40547036801** (`diag/simulation-lock` `47f8f20`, never merged): the same stand with cybernode at `31fca56`. It re-resolves simulation's lock from the committed one (no `generate-lockfile`) and uploads the lock and its diff, then runs both gates' own commands with `--locked`. Its targets are simulation-gate green and `chain.snap: 54 entries, no drift`. #407 still does not merge. Next: read 40547036801, then open the simulation lock PR (fork) for the owner. Once cybernode#1 and that PR merge, #407 gets the pins, the `cybernode-tests` gate and a rehearsal. Was (session 158): **cybernode#1 is green, 314 passed and 0 failed, and it is ready for the owner.** Diagnostic 40536044737 (`diag/cybernode-lock-snap` `3cf0ef6`, never merged; the train's stand with 40446879208's overrides, `materialized 33 red: []`) checked out cybernode at exactly `31fca56` (asserted with `rev-parse HEAD`) and applied no patch. The committed `rs/Cargo.lock` has sha256 `91533a1c…` and resolves under `cargo metadata --locked`, and no `CARGO_BIN_EXE_soft3` is left. `cargo test --locked`: lib **310 passed, 0 failed, 1 ignored**, plus integration suites 2 + 1 + 1, for **314 passed, 0 failed**. That equals soft3-tests' 314 in 40446879208 (C2 acceptance). `committed_chain_snap_matches_this_build ... ok` (log line 1313), and it reads soft3's snapshot through the sibling path. `cargo build --release --locked` succeeded (5m 59s) and there were no warnings (receipt `state/run-40536044737/measure.log`, sha256 `741b84b7…`). I marked cybernode#1 ready and posted the receipt (comment 6447200525). It merges by the owner's hand, because cybernode is `push: false`. Next, once cybernode#1 merges: on #407, move the `cybernode` pin to the merge commit and add the `cybernode-tests` gate (`cargo test --locked` in `cybernode/rs`, 1800 s, all four platforms, with `SOFT3_CONFORMANCE_DIR` set explicitly). Then run a rehearsal and merge. Was (session 157): **313 of 314 node tests pass in cybernode. The one red is `chain.snap`, which stayed in soft3; the fix is on cybernode#1.** Diagnostic 40532608817 (`diag/cybernode-lock-bin` `7da072d`, cybernode `52538a6` with the lock and the bin rename applied on the stand) ran `cargo test --locked --no-fail-fast`: lib **309 passed, 1 failed, 1 ignored**, then integration suites 2 + 1 + 1, for **313 passed and 1 failed** (Summary step). `cybernode-release` succeeded and there were no warnings (receipt `state/run-40532608817/`). The red is `chain::conformance::tests::committed_chain_snap_matches_this_build`, which panicked at `src/chain/conformance.rs:313` with `conformance/chain.snap: NotFound`. It reads `rs/../conformance/chain.snap`. Because `proposals/cybernode.md` (§ the table, "conformance snapshots" → soft3) keeps conformance snapshots in soft3, that file is not in cybernode (`git/trees/52538a6`) and is at soft3 `conformance/chain.snap`. The `cybernode conformance` CLI default (`cli.rs:906`) had the same dead path. **Decided (opus; no fable, since the proposal settles it):** the snapshot stays in soft3, and cybernode reads it from `$SOFT3_CONFORMANCE_DIR/chain.snap`, or else from the sibling soft3 checkout (`rs/../../soft3/conformance/chain.snap`, the train's layout). A missing file still fails the test. **cybernode#1 head `31fca56`** (sonnet subagent, reviewed: one `chain_snap_path()`, both sites use it, `--snap` still overrides, nothing skipped; comment 6446771337). Dispatched diagnostic **40536044737** (`diag/cybernode-lock-snap` `3cf0ef6`, never merged). It takes cybernode at exactly `31fca56` with its committed lock and applies no patch on the stand. The target is 314 passed, 0 failed, which equals soft3-tests' 314 in 40446879208 (C2 acceptance). Next: read 40536044737. If green, mark cybernode#1 ready for the owner. Then, on #407: the `cybernode-tests` gate (with `SOFT3_CONFORMANCE_DIR` set explicitly), the pin moved to the merge commit, a rehearsal, and the merge. Was (session 156): **cybernode's tests did not compile, so the fix went to the owner as cybernode#1.** Diagnostic 40529591978 (`diag/cybernode-lock` `bb9b199`, red): the lock resolves on the stand, sha256 `91533a1c…` (artifact `cybernode-lock`, 819-line diff against #407's seed lock). `cargo build --release --locked` finished in 4m 35s and `cybernode --version` printed `cybernode 0.1.0`. But `cargo test --locked` stopped at `tests/chain_adversary.rs:89`: `environment variable CARGO_BIN_EXE_soft3 not defined` (`test-cybernode.log:440`), so **0 of the 312 tests ran**. The move renamed the bin `soft3` → `cybernode` and kept the CLI (`src/cli.rs:39-41` `node`/`mine`/`chain`). That line is the only `CARGO_BIN_EXE_soft3` in `rs/tests`. cybernode is `push: false` for `cyberia-apparatus` and has only `main`, so the lock and the one-line fix went in as a fork PR: **cybernode#1** (draft, `cyberia-apparatus:fix/lock-and-bin-name` `9a2ee26`, lock sha256 checked; the lane label was refused, 403 admin, so `contained` is stated in the body). Dispatched diagnostic **40532608817** (`diag/cybernode-lock-bin` `7da072d` = `bb9b199` + a step that applies the rename on the stand, never merged) to measure the count. Its target is 312 passed. Next: read 40532608817. If green, mark cybernode#1 ready for the owner. Once it merges: pin cybernode to the merge commit on #407, add the `cybernode-tests` gate, run a rehearsal, then merge #407. Was (session 155): **#407 is green but blinds the gate: it moves the node's tests out of every gate, so it does not merge yet.** Rehearsal 40525967811 (`fix/cybernode-drift` `f16cc0f`, 40446879208's overrides), both linux legs (`candidate-x86_64-unknown-linux-gnu`, `candidate-aarch64-unknown-linux-gnu`, `receipt/release-validation.json`): soft3-tests, soft3-release and node-status are **green**, `exit_code: 0`, `warnings: false`, the same as 40446879208. But `logs/soft3-tests.txt` shows **2 passed in 3 suites (x86_64), against 314 passed in 6 suites** in 40446879208. The chain_adversary, mine_e2e and chain_checkpoints tests, the C2 corpus, the C3 economy vectors and the G14 and G16 receipts all left with the node to `cybernode/rs`. No gate runs them there: `train_gates.py` `run_gates` stack owners have no `cybernode`, and `cybernode/rs` at `52538a6` has **no `Cargo.lock`** (`gh api …/contents/rs`), so `cargo test --locked` cannot run in it. `proposals/cybernode.md` C2 acceptance asks for "`cargo test` in cybernode equals the soft3 crate's test count before the move", and § 9 leaves the tests to the director. **Decided (opus; no fable):** before #407 merges, (a) cybernode gets an `rs/Cargo.lock` resolved by the build service and seeded from #407's soft3 lock, so the shared versions are identical; (b) the pin moves to that commit; (c) the soft3 product legs gain a `cybernode-tests` gate (`cargo test --locked` in `cybernode/rs`, 1800 s, all four platforms, the same as soft3-tests had). Step (a) is dispatched: diagnostic **40529591978** (`diag/cybernode-lock` `bb9b199` = `f16cc0f` + one workflow, never merged; same stand). It resolves the lock, runs `cargo test --locked --no-fail-fast` and `cargo build --release --locked` in `cybernode/rs`, and uploads `cybernode-lock`. Its target is 312 node tests passed. 40525967811's mac and stack legs were still running at 15:18. Next: read 40529591978, then the cybernode lock PR, the pin, the gate on #407 and a rehearsal. Was (session 154): **rehearsal re-dispatched with #407 as the manager: 40525967811.** 40522989900 measured nothing: its manager was `release/phase1` `0c6db6b`, whose `release/phase1.toml` has no `cybernode` sibling (#407 adds it; `train_sources.py` `snapshot` reads the manifest from the manager), so all four building legs went red in 0.03 s on `failed to read …/sources/cybernode/rs/Cargo.toml` (`candidate-x86_64-unknown-linux-gnu` `logs/soft3-tests.txt`, exit 101; receipt in `state/run-40522989900/`). Cancelled it (its stack leg could not measure soft3 either; the `release-train` group queues) and dispatched `--ref fix/cybernode-drift` (`f16cc0f`; differs from `release/phase1` only in `plan.md`, so the train code is the same) with the same 15 overrides as exact commits (`state/run-40522989900/overrides.txt`). next: compare soft3-tests, soft3-release, node-status per leg against 40446879208, then merge #407. Was (session 153): **lock committed, rehearsal dispatched.** Diagnostic 40519917254 (`measure` success) built soft3 at #407's head `d49849a` and cybernode at its pin `52538a6` with 40446879208's overrides: lock before `cb7c91ab…` (= #407's), after `e4e90704…`, diff = one new `cybernode` 0.1.0 package holding the node's 23 deps, `soft3` 0.10.0 → 0.11.0 depending on `cyb` + `cybernode`; `cargo test --locked` (lib 2 passed) and `cargo build --release --locked` (3m 34s) finished there. That lock committed to #407 as `f16cc0f` (sha256 checked against the receipt). Rehearsal **40522989900** (`candidate-20261027.92`, `cut=false`) dispatched with 40446879208's overrides and `soft3=f16cc0f`; next: compare soft3-tests, soft3-release, node-status per leg against 40446879208, then merge #407. Run 40519226722 (14:14, `main`, tick's dispatch on the moved defaults) is red as the defaults are before the landings (package-resolution `lens/gpu`), nothing new. Was (session 152): **#406 reviewed and carried by soft3#407** (`fix/cybernode-drift` = #406 `58920a8` + `d49849a`; #406 untouched, closes as merged when #407 merges). #406's `drift` was red (run 40517639036: `layer 7 component missing from the home ladder: soft3`); `d49849a` (sonnet subagent, reviewed): registry `cybernode` ops → `apparatus` (§ 7.1), new `cybernode` product at layer 7, `soft3` without `layer`/`role`, foculus·radio·sync·solong `part_of = "cybernode"`, chart rung-7 node/8 edges/`LADDER`, a `status.md` row — checker `no drift`, Components registry on #407 green (run 40519963024). Open: #406 left `crate/Cargo.lock` stale (0 `cybernode` entries) while soft3-tests/soft3-release run `--locked` (`train_gates.py:304-305`) → diagnostic `diag/cybernode-406-lock` `b1fba54` (never merged), run **40519917254**, resolves the lock on the stand and runs both gate commands; next: commit its lock to #407, then the rehearsal. `cybernode` is public (`visibility: public`), so the train can check out the sibling pin `52538a6`. Review comment on #406: 6444426906 |
-| R0 | soft3's landing: `release/phase1 → main` with the receipts (D1, D11) | soft3 · wide (`decision`: the owner's approval) | the PR open with receipts, conflict-free, PR gates on its head; merged by the director after the owner approves | to the owner 2026-10-27 (session 125). **soft3#376** is open: head `cd15055`, base `main` `2e5ba00`, 274 ahead and 0 behind, so it merges with no conflict. It has 48 files and no `specs/` file. Labels `decision`, `wide`; `mergeable_state: blocked` means it waits on the review. Receipts on the PR come from rehearsal 40446879208 at `5ca1d64`. On all five legs, soft3-tests, soft3-release and node-status are green (receipt sha256 `64cdcf80` `2abcae89` `19b762ea` `40d01b8a` `8c6d71d5`). The reds are only the owned ones (G8, G9, L3b, L3c). Since `5ca1d64` the only input change is `release/phase1.toml` (#373, whose PR gates are green). The order is noted on lens#36 (comment 6435030150). Each later plan PR adds commits to #376's head. That is plan text only, and the PR gates rerun. |
+| R0 | soft3's landing: `release/phase1 → main` with the receipts (D1, D11) | soft3 · wide (`decision`: the owner's approval) | the PR open with receipts, conflict-free, PR gates on its head; merged by the director after the owner approves | to the owner 2026-10-27 (session 125). **Re-synced in session 167 (D2):** `main` had gained four of the owner's commits after `2e5ba00` (`130ceed`, `ff06667`, `9d6f5e5`, `3045d54` CLAUDE.md → AGENTS.md), which left the line 4 behind (`rev-list --left-right --count` `4 358`). soft3#423 merged `main` `3045d54` into `release/phase1` as a merge commit (`4ae13d9`). It touches 5 doc and proposal files, with no `specs/` and no code, and `merge-tree` was clean. No PR gate matches those paths. The line is now `0 360`, so #376 (head `4ae13d9`) is again 0 behind and conflict-free. **soft3#376** is open: head `cd15055`, base `main` `2e5ba00`, 274 ahead and 0 behind, so it merges with no conflict. It has 48 files and no `specs/` file. Labels `decision`, `wide`; `mergeable_state: blocked` means it waits on the review. Receipts on the PR come from rehearsal 40446879208 at `5ca1d64`. On all five legs, soft3-tests, soft3-release and node-status are green (receipt sha256 `64cdcf80` `2abcae89` `19b762ea` `40d01b8a` `8c6d71d5`). The reds are only the owned ones (G8, G9, L3b, L3c). Since `5ca1d64` the only input change is `release/phase1.toml` (#373, whose PR gates are green). The order is noted on lens#36 (comment 6435030150). Each later plan PR adds commits to #376's head. That is plan text only, and the PR gates rerun. |
 | R1 | the candidate: a dispatched `cut=false` run green on all five legs from origin defaults, then the 12:00 cut of the same inputs | soft3 | `release-validation.json` green on every leg; the draft `candidate-YYYYMMDD.N` exists; the owner's promotion the only step left | open |
 
 reading the order: G2 makes "green" checkable for every sibling PR; L1 → L2 → L3 → L4 is the dependency order of the 0.4 line (leaves first); G4–G8 are independent and may interleave whenever a gate is the reddest; G9 comes after the landings; R1 closes the plan.
@@ -317,3 +317,4 @@ reading the order: G2 makes "green" checkable for every sibling PR; L1 → L2 
 | 2026-10-27 19:00 | director session 164 | **C4: waiting on the stack leg of rehearsal 40553564510, so nothing new was measured.** The tick `20261027T185837Z` was unchanged (`changed=0`). The owner has not moved: cybernode#1 (`31fca56`), simulation#2 (`5518998`) and #376 are open and unmerged (REST, 18:59). `red-40519226722.json` (`main`, from before the landings) holds nothing new. Stack job 122363639791 is in `Qualify stack and product` since 17:46:08, within G10a's ≈155 min worst case, and the four platform legs were already read in session 163. #407 does not merge yet. Nothing merged except this plan PR. No subagent, no fable. Next: read the stack leg when it completes (targets: stack-chain-genesis and simulation-gate green, the rest no worse than 40446879208), then cybernode#1's merge → pin → merge #407 |
 | 2026-10-27 19:20 | director session 165 | **C4: still waiting on the stack leg of rehearsal 40553564510, so nothing new was measured.** The tick is `20261027T191604Z`. Its last run is 40553564510 (`in_progress`). The snapshot job and the four platform legs are complete; session 163 read the platform legs. Stack job 122363639791 has been in `Qualify stack and product` since 17:45:45, about 91 min at 19:16. That is within G10a's ≈155 min worst case (`gh run view 40553564510 --json jobs`, 19:17). The owner has not moved. cybernode#1 (`31fca56`, `clean`), simulation#2 (`5518998`, `clean`) and #376 (`blocked`, 0 reviews) are open and unmerged (REST, 19:17). #384 and #398 are triaged already (sessions 144 and after 12:12). `red-40519226722.json` (`main`, from before the landings) holds nothing new. #407 does not merge yet. Nothing merged except this plan PR. No subagent, no fable. Next: read the stack leg when it completes. The targets are stack-chain-genesis and simulation-gate green, the rest no worse than 40446879208. Then cybernode#1's merge → pin → merge #407 |
 | 2026-10-27 19:40 | director session 166 | **C4: the stack leg of rehearsal 40553564510 is read. #407 causes no red, and it waits on cybernode#1.** Stack job 122363639791 finished at 19:21. `cybernode-tests` is green with 314 passed. stack-chain-genesis and simulation-gate are green. The stack reds (mudra, neuron, zheng) and the two pin/notes reds are the same as 40446879208's. Receipt on #407 is comment 6451673696. Tick `20261027T193247Z`: the drift is the same in kind. `red-40519226722.json` (`main`, from before the landings) holds nothing new. The owner has not moved: cybernode#1 (`31fca56`), simulation#2 (`5518998`) and #376 (`BLOCKED`, 0 reviews) are open. Nothing merged except this plan PR. No subagent, no fable. The doctrine forbids AI co-authorship trailers (`AGENTS.md` § git), so from this session the plan commits carry none. Next: the owner's cybernode#1 → pin → merge #407 |
+| 2026-10-27 19:55 | director session 167 | **R0 kept conflict-free (D2): soft3#423 merged `main` `3045d54` into `release/phase1` (`4ae13d9`).** The owner's four `main` commits since `2e5ba00` (docs, the mimi removal, proposals/state-economics, CLAUDE.md → AGENTS.md) had left the line 4 behind. The merge is clean, 5 files, with no `specs/` and no code. No workflow reads `CLAUDE.md` (`git grep` over py/yml/sh/nu/toml/rs). Labels `contained`, `ready`. No PR gate matches the paths. #376 is 0 behind again. The doctrine read from now on is soft3 `AGENTS.md` (the owner, 2026-10-27). Tick `20261027T195106Z`: the owner merged **zheng#80** (`release/0.4 → master`, `4068e9c`, 19:22), so L3's zheng landing is on its default. Run 40570117323 (tick's `main` baseline, `3045d54`, no overrides) is red as 40519226722 was, plus stack-zheng (zheng `master` 0.4 now needs `lens/gpu`, which only lens#36 brings) and stack-mudra (`zheng = "^0.3"` against zheng `master` 0.4.0, the L4 consumer port). Neither is a regression of the line; both close by the landing order (lens#36, then the consumers). C4 still waits on the owner's cybernode#1. No subagent, no fable. Next: the owner's cybernode#1 → pin → merge #407 |