rob thijssenandClaude Opus 5
7b8308d34e
helexa#179's application-owned system prompts let tireless shape both ends of the cc->oc handoff, so the "will a 27B execute an Opus plan" risk becomes a tunable rather than a hope. Three prompts, versioned as one set: plan.cc.md tells Claude Code it is writing for a literal, absent reader; implement.oc.md tells OpenCode to execute exactly that and report rather than improvise; implement.cc.md covers unplanned issues. PromptSet::load refuses a mismatched set, and tests assert the prompts mention every section ChildSpec requires. The middle is validated, not trusted. plan::validate rejects a plan before any implementation job is enqueued unless every child carries a runnable acceptance command (a stopping condition) and a non-empty out-of-scope list (a boundary) -- the two sections a small model needs and a human reader does not. Dangling and cyclic dependencies are caught too, and implementation_order derives the start order. cc uses --append-system-prompt, never --system-prompt: replacing Claude Code's default discards the tool-use scaffolding that makes it a coding agent. Pin bumped to 2.1.220, the version this flag surface was verified against. The oc path depends on helexa#179's passthrough guarantee, which is still open and unverified for qwen3 arch templating. Stage 5 now opens with a PONG probe rather than debugging it through a failed implementation run. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DHhHtohxcdk1PL3tfnYJdH