claim(poe2e): all 5 DoD built + cold-verified (staged cc-ci 38e5c90 @ /home/loops/poe2e/cc-ci, PO fleet 6cc3ed4) — awaiting Adversary

machine-docs/JOURNAL-poe2e.md

@@ -54,6 +54,44 @@ Established facts:
   tmux sessions (provable RUNNING) without spending tokens or risking any collision, on a unique
   isolated `session_prefix`. Then `down` + delete the throwaway.
 
+## 2026-06-13T19:41Z — All 5 DoD built + cold-verified; claiming gate
+
+Built and verified end to end. The WHY behind the STATUS facts:
+
+- **D1 (lifecycle).** Used the PO's `create-project.sh` to scaffold `/tmp/poe2e-scratch/scratch-e2e`
+  (engine pinned `289ef07`; tracked files exactly `.gitignore .gitmodules agents.toml engine` — no
+  PO/fleet metadata), switched it to the `demo` backend so `up` really starts tmux sessions with no
+  token spend and on the isolated `poe2e-scratch-` namespace. Observed: `up` → both sessions; `status`
+  → RUNNING; `down` → killed; `status` → stopped; deleted. The 8 live `cc-ci-*` sessions never moved.
+- **D2 (migration + parity).** The migration is faithful: `role_model()` and `cmd_status()` render
+  byte-identical between the live engine and v0.1.0 (I diffed `role_model` — IDENTICAL — and read
+  `cmd_status`). I copied the `phases` array verbatim (incl. the `"opus"` shorthand for dstamp and all
+  per-phase `models`), so `tomllib`-comparing the two configs' phase arrays gives `True`. The biggest
+  confidence boost: rendering the staged builder/adversary kickoffs via the engine and diffing against
+  the *live generated* `kickoff-cc-ci-*.txt` → **byte-identical**, proving prompts/kickoff.md +
+  prompts/{builder,adversary}.md reproduce the live `build_loop_kickoff()` exactly. The staged
+  `status` is byte-identical to live including STATE, because `session_prefix="cc-ci-"` means
+  `session_alive()` (read-only `tmux has-session`) sees the live sessions — the staged project starts
+  nothing. **Critical safety finding:** the engine's `load_config()` does
+  `Path(log_dir/state).mkdir(exist_ok=True)` on EVERY invocation incl. `status` — so the staged
+  `log_dir` must be the isolated `.ao-state`, never the live `/srv/cc-ci/.cc-ci-logs` (the cutover
+  runbook flips it back). That's why staging uses an isolated state dir.
+- **D3.** Registered `cc-ci` in the PO `fleet.toml` as `enabled=false` (the PO must never start it —
+  shared namespace would collide with live). `fleet.py validate` → OK, 2 projects.
+- **D4.** Cutover runbook derived from the *actual* live boot chain I inspected
+  (`cc-ci-loops.service → cc-ci-loops-start → launch.sh start → launch.py [shim] → agents.py up`,
+  cwd `/srv/cc-ci/cc-ci`, `RESUME_PHASE=1`). The cutover is one indirection change (re-point
+  `launch.py` at the project engine) + one config delta (`log_dir` → live path to resume phase/ids)
+  + quiesce-then-start to avoid a double watchdog; rollback is just restoring the old shim. The
+  in-place `agents.{py,toml}` stay present throughout → trivial rollback.
+- **D5.** Re-checksummed live `agents.{py,toml}` (both == baseline), `phase-idx`=18, the 8 baseline
+  sessions, exactly 1 `cc-ci-watchdog`, cc-ci host has no tmux. Nothing I did wrote live files/state
+  or started a `cc-ci-` session.
+
+Deliverable SHAs: staged cc-ci `/home/loops/poe2e/cc-ci` @ `38e5c90` (engine `289ef07` v0.1.0);
+PO `recipe-maintainers/project-orchestrator` @ `6cc3ed4` (pushed). Cleaned up `/tmp` scratch +
+cold-clone artifacts. Claiming the gate.
+
 ## Adversary pre-Builder D5 baseline (preserved verbatim from the Adversary's init)
 
 > The Adversary recorded this in JOURNAL-poe2e.md at phase start, before I took ownership. Kept here