feat: pm_planner_dispatcher template runnable from a clean init (P0.4)#63
Merged
Conversation
A clean `loopy init --template pm_planner_dispatcher` scaffolded only the planner and dispatcher workflows, but the dispatcher's whole job is to spawn child sessions running inner_outer_eval — which was absent, so a clean init could not execute a single child (found during the July 2026 review; a direct blocker for driving multi-phase targets with the double loop from day one). The child set is composed from the inner_outer_eval template's own files at init time (PACKAGED_TEMPLATE_EXTRA_SOURCES), not duplicated on disk, so the two copies can never drift apart. Tests: the pm scaffold test now asserts all four child workflows exist, and a new end-to-end smoke proves a clean pm init can actually dispatch an inner_outer_eval child session through the real coordinator (register -> child request -> finished -> child task dispatched). 145 tests green; ruff/format/pyright clean. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PN8aFwwxA8FzMy9LgpbQFt
…nt goal Addresses both High findings from the Codex review of P0.4: 1. The PM template's team_harness_system_prompt_extension applied to EVERY harness run in the repo — including child inner_outer_eval sessions — so the child's implementer received "should not implement the child work directly" at system-prompt level. The extension is now empty (the planner/dispatcher prompt bodies already carry the parent-role boundary), with a template comment explaining why it must stay workflow-set-neutral. 2. The stock inner_outer_eval prompts declared the repo-root loopy_loop_goal.txt canonical — which in a child session is the PARENT's goal, steering the child toward the orchestration goal instead of its work item. All four prompts now treat the rendered Goal / Session goal path as canonical (also correct for top-level sessions, whose exact goal is copied into session goal.md). Per the Medium finding, the clean-init smoke now runs the dispatched child assignment through the real worker path (fake harness) and asserts the SEMANTICS, not just the dispatch: the rendered prompt carries the CHILD's goal, never names the repo-root goal file, and the child snapshot's system prompt extension contains no "not implement" instruction — so the "executable end to end" claim is now actually tested. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PN8aFwwxA8FzMy9LgpbQFt
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
A clean
loopy init --template pm_planner_dispatcherscaffolded only the planner/dispatcher workflows — but the dispatcher's whole job is to spawn child sessions runninginner_outer_eval, which was absent. A clean init could not execute a single child (flagged in the July 2026 review; a direct blocker for driving multi-phase targets with the double loop).inner_outer_evaltemplate's own files at init time (PACKAGED_TEMPLATE_EXTRA_SOURCES) — no duplication, the copies can't drift. Idempotency preserved (existing files untouched).Codex review (gpt-5.6-sol @ xhigh) — and what it caught
The mechanical change was fine, but the review found two High defects in the composed runtime semantics, both fixed:
system_prompt_extensionleaked into child sessions ("should not implement the child work directly" reached the child's implementer at system-prompt level). Now empty + a template comment explaining why it must stay workflow-set-neutral; the parent-role boundary lives in the planner/dispatcher prompt bodies where it belongs.loopy_loop_goal.txtcanonical — the parent's goal in a child session. All fourinner_outer_evalprompts now treat the rendered Goal / Session goal path as canonical (correct for top-level sessions too).Per the Medium finding, the end-to-end smoke now runs the dispatched child assignment through the real worker path (fake harness) and asserts the semantics: child goal in the rendered prompt, no root-goal reference, no "not implement" in the child's system prompt.
Verification
145 tests green (3 new/deepened); ruff/format/pyright clean. Codex confirmed idempotency, destination paths, both init orders, wheel packaging (both template trees ship), and CI determinism (no API key needed — provider
codex) as Checked-OK.🤖 Generated with Claude Code
https://claude.ai/code/session_01PN8aFwwxA8FzMy9LgpbQFt