fix: break delegate→plan-mode→approve infinite loop

[barkain]

Summary

• Loop trace: User approves plan via ExitPlanMode → remind_skill_continuation.py writes workflow_continuation_needed.json → stop hook emits decision: block, reason: "continue" → model sees orchestrator stub rule ("all work MUST go through /workflow-orchestrator:delegate") → re-invokes delegate → re-enters plan mode → regenerates same plan → loops forever.
• Root cause: Three-component interaction — (1) hooks/PostToolUse/remind_skill_continuation.py unconditionally signals continuation on ExitPlanMode, (2) hooks/stop/python_stop_hook.py emitted a vague "continue" reason that didn't disambiguate the next action, (3) system-prompts/orchestrator_stub.md rule + lack of entry guard in commands/delegate.md caused the synthetic continuation to re-route through delegate.
• Three-layer fix:
  • Layer 1 (hooks/stop/python_stop_hook.py): Replace vague reason: "continue" with explicit anti-redelegation directive ("PLAN ALREADY APPROVED. Execute Stage 1 NOW… DO NOT call /workflow-orchestrator:delegate. DO NOT call EnterPlanMode…").
  • Layer 2 (system-prompts/orchestrator_stub.md): Add "Exception — continuation after plan approval" section between ## Rule and ## Team Mode, telling the model the all-work-→-delegate rule does NOT apply mid-delegation.
  • Layer 3 (commands/delegate.md): Insert "RE-INVOCATION GUARD (READ FIRST)" section immediately after frontmatter, catching the loop at the delegate skill's own entry point.

Test plan

• git status -sb → only the three modified files staged
• git diff --stat → Layer 1/2/3 each show as expected
• uvx ruff format --check hooks/stop/python_stop_hook.py → pass
• uvx ruff check --select F,E711,E712,UP006,UP007,UP035,UP037,T201,S hooks/stop/python_stop_hook.py → pass
• uvx pyright hooks/stop/python_stop_hook.py → pass (0 errors)
• Read commands/delegate.md lines 1-30 → guard is FIRST content after frontmatter
• Read system-prompts/orchestrator_stub.md → Exception section present, after ## Rule, before ## Team Mode
• Grep hooks/stop/python_stop_hook.py for "reason": "continue" → no match
• Manual reproduction: requires a downstream session in a different repo (e.g. ~/dev/agentmem) after reinstalling the plugin — cannot be reproduced inside the session that authored the fix.

🤖 Generated with Claude Code

[qodo-code-review]

Review Summary by Qodo

Break infinite delegate→plan-mode→approve loop with layered guards

🐞 Bug fix

Walkthroughs

Description

• Breaks infinite delegate→plan-mode→approve loop via three-layer fix
• Stop hook now emits explicit anti-redelegation directive instead of vague "continue"
• Orchestrator stub adds exception clause overriding all-work→delegate rule post-approval
• Delegate command includes re-invocation guard preventing Stage 0 re-entry after ExitPlanMode

Diagram

flowchart LR
  A["ExitPlanMode"] -->|"Old: vague continue"| B["Stop Hook"]
  B -->|"Loops back"| C["Delegate"]
  C -->|"Re-enters"| D["EnterPlanMode"]
  D -->|"Loops"| A
  
  A -->|"New: explicit directive"| B2["Stop Hook<br/>Anti-redelegation"]
  B2 -->|"Skip delegate"| E["Stage 1 Execution"]
  C -->|"Guard checks"| F["Skip Stage 0"]
  F -->|"Direct to"| E
  G["Orchestrator Stub<br/>Exception clause"] -.->|"Overrides routing"| E

Loading

File Changes

1. hooks/stop/python_stop_hook.py 🐞 Bug fix +7/-2

Stop hook emits explicit anti-redelegation continuation directive

• Replaced vague reason: "continue" with explicit multi-line anti-redelegation directive
• New reason explicitly instructs model to execute Stage 1 directly without re-delegating or
 re-entering plan mode
• Updated systemMessage to clarify plan is already approved
• Maintains existing block decision mechanism while disambiguating continuation intent

hooks/stop/python_stop_hook.py

---

2. commands/delegate.md 🐞 Bug fix +4/-0

Delegate command adds re-invocation guard after frontmatter

• Added "RE-INVOCATION GUARD (READ FIRST)" section immediately after frontmatter
• Guard detects ExitPlanMode or continuation messages and prevents Stage 0 re-entry
• Explicitly instructs model to skip EnterPlanMode and proceed directly to Stage 1 execution
• Catches infinite loop at delegate skill's entry point before any tool invocation

commands/delegate.md

---

3. system-prompts/orchestrator_stub.md 🐞 Bug fix +4/-0

Orchestrator stub adds post-approval exception to routing rule

• Added "Exception — continuation after plan approval" section between Rule and Team Mode
• Exception clause overrides all-work→delegate routing rule during in-flight delegation
• Instructs model to skip delegate re-invocation and EnterPlanMode after plan approval
• Clarifies that orchestrator is already loaded and plan is approved for Stage 1 execution

system-prompts/orchestrator_stub.md

---

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (1)   📘 Rule violations (1)   📎 Requirement gaps (0)   🎨 UX Issues (0)

🐞\ ≡ Correctness (1)

📘\ ☼ Reliability (1)

1. python_stop_hook.py hard-blocks tools 📘 ☼

Description

The modified stop hook emits a hard-blocking response (decision: block) as part of its
continuation behavior. This violates the policy that only python_posttooluse_hook.py may
hard-block tool execution.

Code

hooks/stop/python_stop_hook.py[R173-185]

      # This mimics ralph-wiggum's loop mechanism
      output = {
          "decision": "block",
-            "reason": "continue",
-            "systemMessage": "⚡ Workflow continuation: Proceeding to STAGE 1 execution.",
+            "reason": (
+                "PLAN ALREADY APPROVED. Execute Stage 1 NOW directly from the existing "
+                "approved plan in context. DO NOT call /workflow-orchestrator:delegate. "
+                "DO NOT call EnterPlanMode. DO NOT re-enter plan mode. "
+                "Render the dependency graph and start spawning Wave 0 agents."
+            ),
+            "systemMessage": "⚡ Continuing to STAGE 1 execution (plan already approved).",
      }
      print(json.dumps(output))  # noqa: T201
      logger.debug("Output block decision with 'continue' reason")

Evidence

PR Compliance ID 295664 requires that only python_posttooluse_hook.py can hard-block tool
execution, but the changed continuation output in python_stop_hook.py is a blocking decision path.

Rule 295664: Only python_posttooluse_hook.py may hard-block tool execution
hooks/stop/python_stop_hook.py[172-186]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`hooks/stop/python_stop_hook.py` emits a hard-blocking decision (`decision: block`) in the continuation path, but policy allows only `python_posttooluse_hook.py` to hard-block tool execution.
## Issue Context
The PR updated the continuation `reason`/`systemMessage` text but left the stop hook in a hard-blocking mode. Compliance requires all other hooks to be advisory/non-blocking.
## Fix Focus Areas
- hooks/stop/python_stop_hook.py[172-186]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. Guard misroutes new tasks ☑ 🐞 ≡

Description

The new RE-INVOCATION GUARD in commands/delegate.md triggers solely on “most recent tool call was
ExitPlanMode” and instructs skipping Stage 0, which can cause a fresh
/workflow-orchestrator:delegate invocation (with a new task description) to incorrectly execute the
prior approved plan.

Code

commands/delegate.md[R7-10]

+## RE-INVOCATION GUARD (READ FIRST)
+
+Before doing ANYTHING else: if your most recent tool call in this conversation was `ExitPlanMode`, OR if you arrived here via a "PLAN ALREADY APPROVED" / "continuing to STAGE 1" continuation message, the plan is already approved. **Do NOT call `EnterPlanMode`. Do NOT re-enter Stage 0.** Skip directly to **STAGE 1: EXECUTION** — render the dependency graph from the approved plan in context and begin spawning Wave 0 agents. Re-entering plan mode here causes an infinite delegate→plan→approve loop.
+

Evidence

The guard explicitly keys off the most recent tool call being ExitPlanMode and then mandates jumping
to Stage 1 using the “approved plan in context,” regardless of the new delegate argument.
Separately, the orchestrator stub states that any new work request MUST be routed through
/workflow-orchestrator:delegate, making it realistic that a new task arrives immediately after an
ExitPlanMode—at which point this guard would still fire and misroute execution to the previous plan.

commands/delegate.md[1-10]
system-prompts/orchestrator_stub.md[1-16]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The delegate entry guard treats *any* delegate invocation following an `ExitPlanMode` as a continuation and forces Stage 1 execution, which can execute the wrong (previous) approved plan when the user is actually starting a new task.
## Issue Context
- `/workflow-orchestrator:delegate` is the required routing path for new work.
- A user can legitimately issue a new work request immediately after an `ExitPlanMode` happened in the conversation.
- The guard should only trigger for the stop-hook continuation path (explicit “PLAN ALREADY APPROVED” / “continuing to STAGE 1” message), not merely because `ExitPlanMode` occurred last.
## Fix Focus Areas
- commands/delegate.md[7-10]
## Implementation notes
- Remove or substantially weaken the `ExitPlanMode`-only heuristic.
- Make the guard conditional on *explicit continuation indicators* (e.g., presence of the stop-hook continuation message), and otherwise proceed with the normal Stage 0 routing based on the provided task description.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

3. Continuation sentinel removed 🐞 ≡

Description

python_stop_hook's continuation path is documented as injecting a special "continue" sentinel, but
the PR replaces the literal "reason": "continue" with a long instruction string while leaving
comments/logging that still assume a "continue" reason. If any downstream logic (or Claude Code hook
semantics) relies on the sentinel value, workflow auto-continuation may stop working or behave
inconsistently.

Code

hooks/stop/python_stop_hook.py[R173-185]

 # This mimics ralph-wiggum's loop mechanism
 output = {
     "decision": "block",
-            "reason": "continue",
-            "systemMessage": "⚡ Workflow continuation: Proceeding to STAGE 1 execution.",
+            "reason": (
+                "PLAN ALREADY APPROVED. Execute Stage 1 NOW directly from the existing "
+                "approved plan in context. DO NOT call /workflow-orchestrator:delegate. "
+                "DO NOT call EnterPlanMode. DO NOT re-enter plan mode. "
+                "Render the dependency graph and start spawning Wave 0 agents."
+            ),
+            "systemMessage": "⚡ Continuing to STAGE 1 execution (plan already approved).",
 }
 print(json.dumps(output))  # noqa: T201
 logger.debug("Output block decision with 'continue' reason")

Evidence

The Stop hook header and inline comments describe blocking stop and injecting "continue"; the
emitted JSON no longer contains the "continue" sentinel, yet the debug log message still claims it
does. The continuation state file is explicitly about "continue workflow execution", reinforcing
that this path is meant to be a specific continuation mechanism rather than an arbitrary reason
string.

hooks/stop/python_stop_hook.py[1-10]
hooks/stop/python_stop_hook.py[152-186]
hooks/PostToolUse/remind_skill_continuation.py[40-69]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`hooks/stop/python_stop_hook.py` documents and logs that it "injects continue" / outputs a block decision with a "continue" reason, but the emitted JSON now sets `reason` to a long instruction string. If the continuation mechanism depends on the sentinel value (`reason == "continue"`), this change can break workflow continuation.
## Issue Context
This stop-hook path is triggered by `.claude/state/workflow_continuation_needed.json` written by `remind_skill_continuation.py` to force the session to continue after `ExitPlanMode`.
## Fix Focus Areas
- hooks/stop/python_stop_hook.py[152-186]
- hooks/stop/python_stop_hook.py[1-10]
## Suggested fix
- Set `output["reason"]` back to the literal sentinel value (e.g. `"continue"`) to preserve any sentinel-based contract.
- Move the new anti-loop guidance into `systemMessage` (or another non-sentinel field if supported) so the model still receives the explicit instructions.
- Update the surrounding comments/log line so they match the actual output (or vice-versa).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

4. Stub continuation exception ambiguous ☑ 🐞 ⚙

Description

orchestrator_stub.md's new exception triggers on "most recent tool call was ExitPlanMode" and also
instructs to spawn Wave 0 agents, while the stub earlier states to use only Tasks
API/AskUserQuestion/delegate. This ambiguity can lead to inconsistent behavior (skipping delegation
in non-orchestrator plan-mode exits, or uncertainty about whether Agent tool usage is allowed in the
exception path).

Code

system-prompts/orchestrator_stub.md[R11-16]

The main agent does not execute work tools directly. Use only: Tasks API, AskUserQuestion, and `/workflow-orchestrator:delegate`. The delegate command loads the full orchestrator (planning, agent assignment, execution waves) on demand.
+## Exception — continuation after plan approval
+
+If your most recent tool call was `ExitPlanMode`, OR you received a "PLAN ALREADY APPROVED" / "continuing to STAGE 1" continuation message, **do NOT re-invoke `/workflow-orchestrator:delegate`** and **do NOT call `EnterPlanMode`** again. The orchestrator is already loaded and the plan is already approved — proceed directly to Stage 1 execution by rendering the dependency graph and spawning Wave 0 agents. The "all work → delegate" rule above does NOT apply during in-flight delegation.
+

Evidence

The stub first constrains the main agent to Tasks API/AskUserQuestion/delegate, then adds an
exception that (a) is keyed broadly on ExitPlanMode and (b) instructs direct Stage 1 execution steps
that normally involve Agent spawning, without explicitly reconciling the earlier tool-usage
restriction.

system-prompts/orchestrator_stub.md[5-16]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`system-prompts/orchestrator_stub.md` introduces an exception keyed on `ExitPlanMode` that bypasses the core "all work -> /delegate" rule and tells the model to execute Stage 1 (spawn Wave 0 agents). This can be ambiguous because the stub also says to use only Tasks API/AskUserQuestion/delegate, and `ExitPlanMode` could occur outside the orchestrator flow.
## Issue Context
This stub is injected broadly (SessionStart) and is meant to be a minimal routing layer. Exceptions should be narrowly scoped and unambiguous about which tools/actions are allowed.
## Fix Focus Areas
- system-prompts/orchestrator_stub.md[5-16]
## Suggested fix
- Narrow the exception condition to the explicit continuation message marker (e.g., only when receiving the "PLAN ALREADY APPROVED" / "Continuing to STAGE 1" continuation message), rather than `ExitPlanMode` alone.
- Explicitly state that Stage 1 execution may use the Agent tool (and any other required tools) during this exception, overriding the earlier "use only" sentence for this specific case.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

ⓘ The new review experience is currently in Beta. Learn more

[qodo-code-review]

1. Continuation sentinel removed 🐞 Bug ≡ Correctness

python_stop_hook's continuation path is documented as injecting a special "continue" sentinel, but
the PR replaces the literal "reason": "continue" with a long instruction string while leaving
comments/logging that still assume a "continue" reason. If any downstream logic (or Claude Code hook
semantics) relies on the sentinel value, workflow auto-continuation may stop working or behave
inconsistently.

Agent Prompt

## Issue description
`hooks/stop/python_stop_hook.py` documents and logs that it "injects continue" / outputs a block decision with a "continue" reason, but the emitted JSON now sets `reason` to a long instruction string. If the continuation mechanism depends on the sentinel value (`reason == "continue"`), this change can break workflow continuation.

## Issue Context
This stop-hook path is triggered by `.claude/state/workflow_continuation_needed.json` written by `remind_skill_continuation.py` to force the session to continue after `ExitPlanMode`.

## Fix Focus Areas
- hooks/stop/python_stop_hook.py[152-186]
- hooks/stop/python_stop_hook.py[1-10]

## Suggested fix
- Set `output["reason"]` back to the literal sentinel value (e.g. `"continue"`) to preserve any sentinel-based contract.
- Move the new anti-loop guidance into `systemMessage` (or another non-sentinel field if supported) so the model still receives the explicit instructions.
- Update the surrounding comments/log line so they match the actual output (or vice-versa).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

[barkain]

Thanks for the review!

Re: #1 Continuation sentinel removed — the suggested swap would actually defeat Layer 1 of the fix. Per the Claude Code Stop hook docs:

Field	Behavior
reason	Explanation shown to Claude when decision is "block". Not shown to user.
systemMessage	Warning message shown to the user. Not added to Claude's context.

reason is the only field the model receives in its continuation context. Moving the anti-redelegation directive into systemMessage would make it invisible to the model, which is exactly what Layer 1 needs to prevent the loop.

Repo-wide grep also confirms there is no downstream code that parses reason as a sentinel value — the literal "continue" was just label text in the prior implementation, never a magic value. The only consumer of .claude/state/workflow_continuation_needed.json is the same check_workflow_continuation function that writes the JSON output, and it only checks file existence + unlinks. So replacing "continue" with the directive is safe.

Layer 1 is intentional: long directive in reason (model-facing), short toast in systemMessage (user-facing).

Re: #2 Stub continuation exception ambiguous — addressed in commit d3d0b6a. Trigger narrowed to the deterministic continuation marker only, and the Agent/TaskCreate/TaskUpdate/TaskGet/TeamCreate/SendMessage tools are now explicitly whitelisted in the exception path.

🤖 Generated with Claude Code

[barkain]

/agentic_review

[qodo-code-review]

Persistent review updated to latest commit d3d0b6a

[barkain]

/agentic_review

[qodo-code-review]

Persistent review updated to latest commit d3d0b6a

[barkain]

/agentic_review

[qodo-code-review]

Persistent review updated to latest commit 2352603

[qodo-code-review]

1. python_stop_hook.py hard-blocks tools 📘 Rule violation ☼ Reliability

The modified stop hook emits a hard-blocking response (decision: block) as part of its
continuation behavior. This violates the policy that only python_posttooluse_hook.py may
hard-block tool execution.

Agent Prompt

## Issue description
`hooks/stop/python_stop_hook.py` emits a hard-blocking decision (`decision: block`) in the continuation path, but policy allows only `python_posttooluse_hook.py` to hard-block tool execution.

## Issue Context
The PR updated the continuation `reason`/`systemMessage` text but left the stop hook in a hard-blocking mode. Compliance requires all other hooks to be advisory/non-blocking.

## Fix Focus Areas
- hooks/stop/python_stop_hook.py[172-186]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools