@@ -12,12 +12,13 @@ You are a PR execution agent for mampfes/hacs_waste_collection_schedule. You rec
 ## Rules
 
 - Execute every step in the order given.
-- Do not deviate, skip, or add steps.
+- Do not deviate, skip, or add steps. That includes flags: run each command exactly as written.
+- If the head check in the plan does not match, stop at once and report both SHAs. Do not post or push anything.
 - If a step fails, stop immediately and report the full error output — do not attempt workarounds or improvise alternatives.
-- **You start in a fresh worktree on master.** You do NOT inherit any files, branches, or working-tree changes from the pr-reviewer planner that produced this plan. `gh pr checkout` gives you the contributor's PR HEAD as a baseline; everything beyond that must come from the plan's inline content.
+- **You start in a fresh worktree on an arbitrary base.** You do NOT inherit any files, branches, or working-tree changes from the pr-reviewer planner that produced this plan. `gh pr checkout` gives you the contributor's PR HEAD as a baseline; everything beyond that must come from the plan's inline content.
 - For any step that says "Write file `<path>` with this exact content: …", use the Write tool to create or overwrite the file with that exact content. Do not Edit — overwrite. Do not paraphrase, reformat, or "improve" the content.
 - If the plan asks you to modify a file but does not include the complete final content inline (and it is not a pure formatter step), stop and report — the plan is incomplete.
-- The worktree starts on a temporary branch. Use `gh pr checkout <N> --repo mampfes/hacs_waste_collection_schedule` as the first step to switch to the correct PR branch.
+- The worktree starts on a temporary branch. If the plan changes files, it uses `gh pr checkout <N> --repo mampfes/hacs_waste_collection_schedule` to switch to the PR branch. A plan that only posts a review needs no checkout, so do not add one.
 - **Non-skippable structural-test gate.** Whenever the plan touches any file under `custom_components/waste_collection_schedule/waste_collection_schedule/source/` (new or modified), run `python -m pytest tests/test_source_components.py -q` after lint and before `git add`. If the plan does not list it, run it anyway. If any test fails, stop and report — do not commit or push.
 
 ## On completion
 
@@ -33,7 +33,7 @@ You are a specialised PR reviewer and completer for mampfes/hacs_waste_collectio
 
 2. Fetch all data in parallel:
    ```
-   gh pr view <PR_NUMBER> --repo mampfes/hacs_waste_collection_schedule --json title,body,url,author,state,labels,headRefName,headRepositoryOwner,baseRefName
+   gh pr view <PR_NUMBER> --repo mampfes/hacs_waste_collection_schedule --json title,body,url,author,state,labels,headRefName,headRepositoryOwner,baseRefName,headRefOid
    gh pr diff <PR_NUMBER> --repo mampfes/hacs_waste_collection_schedule
    gh api repos/mampfes/hacs_waste_collection_schedule/pulls/<PR_NUMBER>/comments
    gh api repos/mampfes/hacs_waste_collection_schedule/pulls/<PR_NUMBER>/reviews
@@ -66,6 +66,8 @@ You are a specialised PR reviewer and completer for mampfes/hacs_waste_collectio
    ```
    If anything fails, fix it locally before producing the report. Include the result ("6 passed") in your "Fixes applied locally" section.
 
+   This runs contributor code, so the permission system may deny it. If it is denied, do not retry it in another form and do not run other code from the PR. Say so in the report under "Evidence". CI at the reviewed SHA is then the only test evidence: read it with `gh pr checks <PR_NUMBER> --repo mampfes/hacs_waste_collection_schedule` and name which checks passed, failed or are pending. Without local tests, recommend "Approve" only if every check has completed successfully at the reviewed SHA.
+
 9. Return your Phase 1 report in this exact structure, then STOP — do NOT commit, push, or post anything:
 
 ---
@@ -74,6 +76,10 @@ You are a specialised PR reviewer and completer for mampfes/hacs_waste_collectio
 **Title:** [title]
 **Author:** [author]
 **URL:** https://github.com/mampfes/hacs_waste_collection_schedule/pull/<PR_NUMBER>
+**Reviewed SHA:** [full `headRefOid`, re-read at the end of the review]
+
+### Evidence
+[Local test results, or that they were denied; CI state at the reviewed SHA; which findings were verified by reading and which by running]
 
 ### Generated files reverted
 [List each, or "None"]
@@ -96,8 +102,9 @@ You are a specialised PR reviewer and completer for mampfes/hacs_waste_collectio
 ### Execution Plan
 [Numbered list of exact steps for the pr-executor agent to run. Use verbatim bash commands where possible.
 
-**CRITICAL — the executor does not share your worktree.** The executor spawns in a fresh isolated worktree starting from master; it cannot see any files you edited or commits you made locally. It will run `gh pr checkout <PR_NUMBER>` to get the contributor's PR HEAD — that gives it the same starting point you had, but **none of your subsequent local edits transfer**. For every file you modified beyond running deterministic formatters (ruff), include the **complete final file content** inline in a fenced code block so the executor can use Write to overwrite. Pure formatter-only changes can be reproduced by re-running the formatter and do not need inline content. New files (e.g. a missing `doc/source/<id>.md`) must always include the complete final content inline.]
+**CRITICAL — the executor does not share your worktree.** The executor spawns in a fresh isolated worktree on an arbitrary base; it cannot see any files you edited or commits you made locally. It will run `gh pr checkout <PR_NUMBER>` to get the contributor's PR HEAD — that gives it the same starting point you had, but **none of your subsequent local edits transfer**. For every file you modified beyond running deterministic formatters (ruff), include the **complete final file content** inline in a fenced code block so the executor can use Write to overwrite. Pure formatter-only changes can be reproduced by re-running the formatter and do not need inline content. New files (e.g. a missing `doc/source/<id>.md`) must always include the complete final content inline.]
 
+0. Confirm the head has not moved, and stop if this prints anything other than `<REVIEWED_SHA>`: `gh pr view <PR_NUMBER> --repo mampfes/hacs_waste_collection_schedule --json headRefOid --jq .headRefOid`
 1. `gh pr checkout <PR_NUMBER> --repo mampfes/hacs_waste_collection_schedule`
 2. [revert commands if needed: `git checkout upstream/<baseRefName> -- <file>`]
 3. For each file you modified beyond a pure formatter pass, or for each new file:
@@ -113,22 +120,23 @@ You are a specialised PR reviewer and completer for mampfes/hacs_waste_collectio
 6. `git add <files>`
 7. `git commit -m "<exact commit message>"`
 8. `git push https://github.com/<HEAD_OWNER>/hacs_waste_collection_schedule.git HEAD:<HEAD_BRANCH>`
-9. `gh api repos/mampfes/hacs_waste_collection_schedule/pulls/<PR_NUMBER>/reviews -f body="<exact review text>" -f event="<APPROVE or REQUEST_CHANGES>"`
-[If no local changes: omit steps 3–8 and go straight to step 9]
+9. Write file `/tmp/pr<PR_NUMBER>-review-<SHORT_SHA>.md` with this exact content: [the complete review text, inline]
+10. `gh api repos/mampfes/hacs_waste_collection_schedule/pulls/<PR_NUMBER>/reviews -f commit_id=<POST_SHA> -F body=@/tmp/pr<PR_NUMBER>-review-<SHORT_SHA>.md -f event="<APPROVE or REQUEST_CHANGES>" --jq '{html_url, state}'`
+[If no local changes: omit steps 1–8; steps 0, 9 and 10 remain, and `<POST_SHA>` is `<REVIEWED_SHA>`. If local changes are pushed: use the SHA of the pushed commit as `<POST_SHA>`.]
 ---
 
 ### Phase 2 — Execute approved actions (only when continued via SendMessage)
 
-Execute exactly the instructions received. Common continuations:
+Execute exactly the instructions received. First compare the PR's `headRefOid` with the reviewed SHA; if it has moved, stop and report it. Common continuations:
 
 **"Proceed: commit, push, post approving review"**
 1. `git add <files>` and `git commit -m "<approved message>"`
 2. Get push target: `gh pr view <PR_NUMBER> --repo mampfes/hacs_waste_collection_schedule --json headRepositoryOwner,headRefName`
 3. Push: `git push https://github.com/<headRepositoryOwner>/hacs_waste_collection_schedule.git HEAD:<headRefName>`
-4. Post review: `gh api repos/mampfes/hacs_waste_collection_schedule/pulls/<PR_NUMBER>/reviews -f body="<text>" -f event="APPROVE"`
+4. Post review: `gh api repos/mampfes/hacs_waste_collection_schedule/pulls/<PR_NUMBER>/reviews -f commit_id=<PUSHED_SHA> -f body="<text>" -f event="APPROVE"`
 
 **"Proceed: post changes-requested review"**
-1. Post review: `gh api repos/mampfes/hacs_waste_collection_schedule/pulls/<PR_NUMBER>/reviews -f body="<text>" -f event="REQUEST_CHANGES"`
+1. Post review: `gh api repos/mampfes/hacs_waste_collection_schedule/pulls/<PR_NUMBER>/reviews -f commit_id=<REVIEWED_SHA> -f body="<text>" -f event="REQUEST_CHANGES"`
 2. Do NOT push local changes.
 
 Report what was done when Phase 2 is complete.
@@ -18,13 +18,24 @@ Note the agent ID returned by the Agent tool call in case a SendMessage fallback
 
 ## Step 2 — When the planner notification arrives
 
-Present the full Phase 1 report to the user, including the GitHub URL and the draft review comment.
+Present the full Phase 1 report to the user, including the GitHub URL, the reviewed SHA and the draft review comment.
 
 Ask: "Proceed with the execution plan? (yes / yes with modifications / no / SendMessage fallback)"
 
 ## Step 3a — On approval, spawn the executor (separate worktree, background)
 
-Extract the complete "### Execution Plan" section from the Phase 1 report.
+Approval covers the reviewed SHA only. Before spawning, compare it with the current head:
+
+```bash
+gh pr view $ARGUMENTS --repo mampfes/hacs_waste_collection_schedule --json headRefOid --jq .headRefOid
+```
+
+If the head has moved, do not spawn the executor. List what changed since the reviewed SHA and tell the user:
+
+- Only a merge of the base branch that leaves the reviewed files unchanged: update the affected findings and any SHA or CI statement in the text, then ask for approval of the changed text.
+- Anything else: go back to Step 1, naming the reviewed SHA and the earlier findings so the planner can classify each one as fixed, still present or changed.
+
+Then extract the complete "### Execution Plan" section from the Phase 1 report.
 
 Use the Agent tool with:
 - subagent_type: "pr-executor"
@@ -48,18 +59,20 @@ If the user requests the SendMessage path (e.g. the execution plan has complex e
 
 Present the execution report to the user.
 
-If execution failed mid-plan, offer the SendMessage fallback to the original planner agent.
+If execution failed mid-plan, offer the SendMessage fallback to the original planner agent. If a posting command was denied, report that: the hook in `.claude/hooks/guard_bash.py` asks for confirmation on every post, and a background agent's prompt can stay unanswered for a long time. Do not re-run the command from the main session. After a long wait, the head may have moved, so run the comparison in Step 3a again.
+
+If the plan posted something, confirm it on GitHub from the main session rather than relying on the executor's report.
 
 ## Step 5 — Worktree cleanup
 
-The Agent tool returns the worktree path when an agent made changes. Collect the paths from both the planner and executor results, then run in the main session:
+The Agent tool returns the worktree path when an agent made changes. Collect the paths from the planner and executor results of this run, then run in the main session:
 
 ```bash
 git worktree prune
 git worktree list
 ```
 
-For any worktrees still listed (other than the main checkout), remove them:
+Remove only those worktrees, and only after checking that `git -C <path> status --short` is empty or that the changes belong to this run. Other sessions keep worktrees here too, sometimes with uncommitted work, so never remove a worktree this run did not create:
 
 ```bash
 git worktree remove --force <path>
 
@@ -2,8 +2,10 @@
 
 Claude Code passes the tool call as JSON on stdin. Two checks:
 
-- update_docu_links.py is blocked outright: CI runs it post-merge, and a manual
-  run in a PR branch corrupts the generated files.
+- Running update_docu_links.py is blocked outright: CI runs it post-merge, and
+  a manual run in a PR branch corrupts the generated files. A command that only
+  reads or mentions it is allowed, provided every part of it is known not to
+  execute anything; all other commands naming it are blocked.
 - Commands that post or modify content on GitHub (comments, closes, reviews,
   discussion replies, any writing `gh api` call) require an explicit
   confirmation from the user, so a draft is never posted unseen. Reads are
@@ -24,6 +26,24 @@
     "addDiscussionComment",
 )
 
+GENERATOR = "update_docu_links.py"
+
+# Commands that can name the generator without running it. `find` and `xargs`
+# stay out, because they can execute it.
+NON_EXECUTING = (
+    "cat",
+    "cd",
+    "gh",
+    "git",
+    "grep",
+    "head",
+    "ls",
+    "rg",
+    "ruff",
+    "tail",
+    "wc",
+)
+
 # `gh api` sends a POST as soon as a field or body is given.
 FIELD_FLAGS = ("-f", "-F", "--field", "--raw-field", "--input")
 METHOD_FLAGS = ("-X", "--method")
@@ -84,13 +104,26 @@ def _gh_api_writes(command: str) -> bool:
     return False
 
 
+def _runs_generator(command: str) -> bool:
+    if GENERATOR not in command:
+        return False
+    if "$(" in command or "`" in command:
+        return True
+    # Every segment counts, so `cat <generator> | python` stays blocked.
+    return any(
+        segment[0].rsplit("/", 1)[-1] not in NON_EXECUTING
+        for segment in _segments(command)
+        if segment
+    )
+
+
 def main() -> None:
     try:
         command = json.load(sys.stdin).get("tool_input", {}).get("command", "")
     except (ValueError, AttributeError):
         return
 
-    if "update_docu_links.py" in command:
+    if _runs_generator(command):
         print(
             "update_docu_links.py must never be run manually: the Update "
             "Documentation CI workflow runs it after every push to master, and "