fix(conductor): reject unsupported whole-branch review scopes

docs/guides/HOW_IT_WORKS.md

@@ -455,7 +455,7 @@ Presents plan summary with hardening notes and design status. Four options:
 
 ### `/lp-conductor`
 
-Use `/lp-conductor` for a change large enough to plan and build in separate sessions. One session becomes the Conductor, checking the work of an Author who plans and an Implementer who builds. It answers routine questions and brings you the decisions that need you. Both role sessions can use Claude Code or Codex.
+Use `/lp-conductor` for a change large enough to plan and build in separate sessions. One session becomes the Conductor, checking the work of an Author who plans and an Implementer who builds. It answers routine questions and brings you the decisions that need you. Both role sessions can use Claude Code or Codex. Final whole-branch reviews require `origin/main` with a merge base matching the recorded review base; unsupported scopes stop before review.
 
 Run `/lp-define` first, then `/lp-conductor` and answer its questions. Paste the printed prompt into a new session and keep the Conductor open. If a plan is already approved or a build is already under way, say so when it asks where the work stands; it then prints the Implementer prompt, or a short prompt for the session already building, instead. It prints the Implementer prompt when the plan is ready. After the Conductor compacts, run `/lp-conductor resume` to restore its state and check for unanswered reports.
 

plugins/launchpad/commands/lp-conductor.md

@@ -61,7 +61,7 @@ Keep an ordered list of every root conducted in this session, in the order first
 ## Start mode
 
 1. **Root.** Apply Path safety to the repository and root before use and after physical resolution, including symlinks. Require the root to be inside the repository and `git check-ignore -q "<root>/x"` to succeed. Otherwise stop and print the `.gitignore` line to add; do not write there yet.
-2. **Ask one at a time, each with a recommendation.** First ask "Where does this work stand?" with three cases: (a) Nothing yet, recommended for new work; (b) A plan is approved; (c) An Implementer is mid-build. Then ask the unit slug, goal in two sentences, source paths (spec, brainstorm, issue), and where the Author and Implementer work (checkout or worktree, branch, base head). The slug must match `^[a-z0-9][a-z0-9-]{0,39}$` and must not be `resume`; ask again otherwise. Always create fresh inboxes; never adopt an existing inbox. If either intended inbox already exists, ask for a fresh slug. For (b) read the approved plan and record the current branch head as the base. For (c), ask the last finished section and its head. Use that verified last-finished-section head as the verification base; with no finished section, use the verified original implementation base. Record the current checkout head separately in Preconditions and State, verify the base is its ancestor, and start the Sections table at the next section. Do not invent or repeat finished work. Resolve `review_base` at start in every mode as the original implementation or PR review base, a verified commit in the recorded Implementer repository. Never derive it from a checkpoint. If it cannot be resolved, ask the user with a recommendation instead of narrowing the review.
+2. **Ask one at a time, each with a recommendation.** First ask "Where does this work stand?" with three cases: (a) Nothing yet, recommended for new work; (b) A plan is approved; (c) An Implementer is mid-build. Then ask the unit slug, goal in two sentences, source paths (spec, brainstorm, issue), and where the Author and Implementer work (checkout or worktree, branch, base head). The slug must match `^[a-z0-9][a-z0-9-]{0,39}$` and must not be `resume`; ask again otherwise. Always create fresh inboxes; never adopt an existing inbox. If either intended inbox already exists, ask for a fresh slug. For (b) read the approved plan and record the current branch head as the base. For (c), ask the last finished section and its head. Use that verified last-finished-section head as the verification base; with no finished section, use the verified original implementation base. Record the current checkout head separately in Preconditions and State, verify the base is its ancestor, and start the Sections table at the next section. Do not invent or repeat finished work. Resolve `review_base` at start in every mode as the original implementation or PR review base, a verified commit in the recorded Implementer repository. Never derive it from a checkpoint. If it cannot be resolved, ask the user with a recommendation instead of narrowing the review. Final whole-branch review is supported only when `origin/main` exists and `git merge-base origin/main HEAD` equals `review_base` in that repository; warn at start if this precondition does not hold.
 3. **Project facts.** Fill `conductor-rules.md` from explicit project `CLAUDE.md` / `AGENTS.md` instructions and defaults otherwise. Show it in one block and ask "change anything?". If it exists, show and keep it unless the user edits it. Required lines:
    - `Gates:` with full commands.
    - `Subagent model (Claude Code):` a cheaper model by default, named in every call.

plugins/launchpad/scripts/tests/test_conductor.py

@@ -291,3 +291,19 @@ def test_final_review_has_separate_whole_branch_base() -> None:
     assert "{{review_base}}" in handoff.split("## Preconditions", 1)[1].split("## Roles", 1)[0]
     assert "{{review_base}}" in handoff.split("## Kickoff prompt", 1)[1].split("## CONTINUE prompt", 1)[0]
     assert "{{review_base}}" in handoff.split("## CONTINUE prompt", 1)[1]
+
+
+
+def test_final_review_stops_outside_supported_origin_main_scope() -> None:
+    protocol = " ".join((TEMPLATES / "protocol-implementer.md").read_text().split())
+    final = protocol.split("## Last section", 1)[1].split("## Models", 1)[0]
+    guard = final.index("git merge-base origin/main HEAD")
+    invocation = final.index("Only after this precondition passes, run `/lp-review`")
+    assert guard < invocation
+    assert "git rev-parse --verify origin/main" in final
+    assert "must equal the recorded review_base" in final
+    assert "stop with an unsupported-scope explanation" in final
+    assert "never accept the working-tree fallback as a whole-branch review" in final
+    assert "both review modes" in final
+    command = " ".join((PLUGIN / "commands/lp-conductor.md").read_text().split())
+    assert "warn at start if this precondition does not hold" in command

plugins/launchpad/templates/conductor/protocol-implementer.md

@@ -44,7 +44,9 @@ Standing permissions, with no stop but recorded under deviations: test helpers a
 
 ## Last section
 
-After implementation code is complete and before any PR, run `/lp-review` over the whole branch (`git diff "<review_base>...HEAD"`), plus any review passes `Gates:` names. Use review_base from the handoff, the original implementation or PR review base, not the checkpoint verification base. Review that entire range and record the actual base, range and head so the whole-branch scope is explicit. Use native LaunchPad review subagents. Round 1 reviews the complete change with the full applicable configured roster. Consolidate and deduplicate findings, verify against code and classify FIX, REBUT or DEFER. Fix accepted issues and run their holding tests. Round 2 reviews round-1 fixes, round 3 reviews round-2 fixes, and round 4 reviews round-3 fixes if needed. Do not force extra rounds. Later rounds rerun only agents whose findings were fixed in the immediately preceding round, reviewing only the diff since that reviewed snapshot, with the original findings, verdicts and evidence. Record reviewed commit identities, agent subsets, dispositions and checks. Honor task review caps; keep local rounds separate from post-PR CI review rounds. Stop when there are zero unresolved P1s and only trivial P2/P3 residue with explicit rationale; never relabel a real P1 to claim convergence.
+After implementation code is complete and before any PR, first check the supported scope in the recorded Implementer repository: `git rev-parse --verify origin/main` must succeed and `git merge-base origin/main HEAD` must equal the recorded review_base. If either check fails, stop with an unsupported-scope explanation in the inbox; never accept the working-tree fallback as a whole-branch review. Apply the same precondition to both review modes and each additional review pass in Gates.
+
+Only after this precondition passes, run `/lp-review` over the whole branch (`git diff "<review_base>...HEAD"`), plus any review passes `Gates:` names. Use review_base from the handoff, the original implementation or PR review base, not the checkpoint verification base. Review that entire range and record the actual base, range and head so the whole-branch scope is explicit. Use native LaunchPad review subagents. Round 1 reviews the complete change with the full applicable configured roster. Consolidate and deduplicate findings, verify against code and classify FIX, REBUT or DEFER. Fix accepted issues and run their holding tests. Round 2 reviews round-1 fixes, round 3 reviews round-2 fixes, and round 4 reviews round-3 fixes if needed. Do not force extra rounds. Later rounds rerun only agents whose findings were fixed in the immediately preceding round, reviewing only the diff since that reviewed snapshot, with the original findings, verdicts and evidence. Record reviewed commit identities, agent subsets, dispositions and checks. Honor task review caps; keep local rounds separate from post-PR CI review rounds. Stop when there are zero unresolved P1s and only trivial P2/P3 residue with explicit rationale; never relabel a real P1 to claim convergence.
 
 Fix every finding or record it with a reason. With gates green, write the final checkpoint, wait for successful verification and CONTINUE (or resume after a scheduled PAUSE), then write the push stop with the proposed PR title and body. Push, PR and merge proceed only on the user's own message.