recipe-maintainers/cc-ci
0
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
c4301bd3077e25a9f62ff978ce1fd3948c865049
cc-ci/machine-docs/JOURNAL-poe2e.md
autonomic-bot d12d8a12ca
Some checks failed
continuous-integration/drone/push Build is failing
Details
inbox(poe2e): consume BUILDER-INBOX; take JOURNAL ownership (baseline preserved); set up STATUS/BACKLOG; heads-up to Adversary
2026-06-13 19:30:10 +00:00

4.7 KiB
Raw Blame History

JOURNAL — phase poe2e (Builder)

Ownership: per protocol §6.1 JOURNAL is Builder-owned (my reasoning; the Adversary does not read it before forming a verdict, for anti-anchoring). The Adversary pre-created this file with its D5 baseline; I have preserved that baseline verbatim in the "Adversary pre-Builder D5 baseline" section below (it is reproducible — plain sha256 of the live files — so nothing is lost) and sent an ADVERSARY-INBOX note that I took JOURNAL over and that baselines belong in REVIEW.

2026-06-13T19:30Z — Bootstrap / orientation

Read in full: plan-phase-poe2e-end-to-end.md, plan-agent-orchestrator.md, plan-phase-porepo-project-orchestrator.md, the engine README.md, the live agents.toml + build_loop_kickoff() in the live agents.py. Inspected the PO repo and engine clone.

Established facts:

  • Engine v0.1.0 working clone: /home/loops/aoeng/agent-orchestrator (tag v0.1.0 → commit 289ef07). PO repo working clone: /home/loops/porepo/project-orchestrator (main @ 346ed31, engine submodule pinned 289ef07). Both public on Gitea.
  • Live cc-ci status (the parity target), captured read-only from /srv/cc-ci/cc-ci-plan via the live agents.py status: 
    phase: poe2e [19/19]  plan=plan-phase-poe2e-end-to-end.md  (in progress)
orchestrator   persistent  claude    claude-opus-4-8      heal       RUNNING
builder        loop        claude    claude-opus-4-8      heal+stall RUNNING
adversary      loop        claude    claude-sonnet-4-6    heal+stall RUNNING
assistant      persistent  claude    claude-sonnet-4-6    none       stopped (disabled)
upgrader       task        claude    claude-sonnet-4-6    none       RUNNING (disabled)
report         task        claude    claude-opus-4-8      none       RUNNING (disabled)
cleanlogs      service     -         -                    -          RUNNING
watchdog       service     -         -                    -          RUNNING
    Note the builder=opus / adversary=sonnet rows are the per-phase model override for phase poe2e (defaults.model is sonnet; the poe2e phase entry sets models = { builder=opus, adversary=sonnet }). Parity is on the agents / models / phases columns — NOT the STATE column (the staged project is never started, so its rows will read stopped, which is correct and expected).

Design approach (the WHY)

  • Staging form = a local git repo + engine submodule, not a new Gitea repo. The phase says "new repo OR a staging dir"; a local staging repo is the safer choice (no collision with the live recipe-maintainers/cc-ci repo, fully local, obviously staging). Its engine/ is a real pinned submodule (DoD requires "engine submodule pinned"). fleet.toml registers it by local path; the cutover runbook documents the eventual production repo/location.
  • Kickoff template migration. The live preamble is hardcoded in the live agents.py build_loop_kickoff() with /srv/cc-ci/cc-ci-plan/{plan} paths. The engine v0.1.0 generalizes this to a project-supplied prompts/kickoff.md with {phase_id}/{plan}/{status}/{role} slots + roles_dir. I reproduce the live preamble text in the staged project's prompts/kickoff.md (baking the /srv/cc-ci/cc-ci-plan/ plan-path prefix into the template so the phases array keeps bare filenames, which is what the status plan= column shows — preserving parity).
  • prompts/ builder.md + adversary.md copied verbatim from live /srv/cc-ci/cc-ci-plan/prompts/.
  • session_prefix decision: deferred to the build step (recorded there). The prefix never appears in status output, so it does not affect parity; the guardrail is about never starting a watchdog on the cc-ci- namespace, which I will not do.
  • Scratch lifecycle (D1) uses the engine's dependency-free demo backend so up really starts tmux sessions (provable RUNNING) without spending tokens or risking any collision, on a unique isolated session_prefix. Then down + delete the throwaway.

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 so it is not lost; the Adversary owns/should track it in REVIEW-poe2e.md.

Baseline @2026-06-13T19:25Z (pre-Builder):

  • agents.toml SHA256: 0d78ba55329705055bbb39722292b6d131cdd30f37eb814e50316f7c0e222b88
  • agents.py SHA256: b4567b73099a587b5727a194f80a5e908d1a1589691294230e6ad1492fb9fe9a
  • state/phase-idx: 18 (poe2e)
  • tmux sessions on orchestrator (pre-Builder): cc-ci-adv, cc-ci-assistant3, cc-ci-cleanlogs, cc-ci-builder, cc-ci-orchestrator, cc-ci-report, cc-ci-upgrader, cc-ci-watchdog
  • cc-ci host tmux: no tmux sessions