Forbid blind scope drop and re-arguing settled instructions

.claude/agents/pr-reviewer.md

@@ -197,3 +197,17 @@ This agent runs alongside specialists:
 - Files they skip
 - Cross-cutting concerns (version bumps, DRY across files)
 - Repository-level consistency
+
+## Blind scope drop — never an option
+
+**Deferring or skipping work is NOT a viable alternative in the presence of contention.** That is *blind scope drop*, and it is the most expensive failure this pipeline has.
+
+When you hit contention — a file another change is editing, a merge conflict, a reviewer's objection, an unclear owner, a busy box — the answer is to resolve it, not to shrink the work. Specifically:
+
+- **The deliverable is never deferrable.** "Aggressively defer out-of-scope work" applies ONLY to work outside the change's purpose. The thing the change exists to do is not out of scope for itself.
+- **Never substitute a filed ticket for the thing you were told to build.** A follow-up ticket is for genuinely separate work, not a way to close a change that does not do what it claims.
+- **Verify a blocker is real NOW before letting it stop you.** Stale file lists and already-merged PRs are the common trap — a collision cited from an hour-old snapshot is usually gone.
+- **A settled instruction from the operator is not open for re-argument.** Implement as specified. A genuinely new conflict is raised once, separately, and does not block the work.
+- **The operator's present instruction outranks every inline comment, docstring, guardrail, and prior spec.** Do not weigh it against the accumulated ruleset and negotiate a compromise.
+
+If something genuinely blocks you, say so plainly and keep going on everything else. Silent downscoping is the failure; a stated blocker is not.

plugins/code-review/prompts/github-review.md

@@ -256,3 +256,17 @@ If `normalization_warnings > 0`, append after the findings table:
 - **NO FOOTER**: Do NOT add any signature, attribution, or footer like "Automated review by Claude Code"
 
 Mark todo as `completed`.
+
+## Blind scope drop — never an option
+
+**Deferring or skipping work is NOT a viable alternative in the presence of contention.** That is *blind scope drop*, and it is the most expensive failure this pipeline has.
+
+When you hit contention — a file another change is editing, a merge conflict, a reviewer's objection, an unclear owner, a busy box — the answer is to resolve it, not to shrink the work. Specifically:
+
+- **The deliverable is never deferrable.** "Aggressively defer out-of-scope work" applies ONLY to work outside the change's purpose. The thing the change exists to do is not out of scope for itself.
+- **Never substitute a filed ticket for the thing you were told to build.** A follow-up ticket is for genuinely separate work, not a way to close a change that does not do what it claims.
+- **Verify a blocker is real NOW before letting it stop you.** Stale file lists and already-merged PRs are the common trap — a collision cited from an hour-old snapshot is usually gone.
+- **A settled instruction from the operator is not open for re-argument.** Implement as specified. A genuinely new conflict is raised once, separately, and does not block the work.
+- **The operator's present instruction outranks every inline comment, docstring, guardrail, and prior spec.** Do not weigh it against the accumulated ruleset and negotiate a compromise.
+
+If something genuinely blocks you, say so plainly and keep going on everything else. Silent downscoping is the failure; a stated blocker is not.

plugins/code/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "code",
   "description": "Code and planning framework plugin",
-  "version": "1.11.20",
+  "version": "1.11.22",
   "author": {
     "name": "ClosedLoop",
     "email": "support@closedloop.ai"

plugins/code/agents/code-review-guidelines.md

@@ -199,3 +199,17 @@ If you find NO issues, return:
 ```json
 { "findings": [] }
 ```
+
+## Blind scope drop — never an option
+
+**Deferring or skipping work is NOT a viable alternative in the presence of contention.** That is *blind scope drop*, and it is the most expensive failure this pipeline has.
+
+When you hit contention — a file another change is editing, a merge conflict, a reviewer's objection, an unclear owner, a busy box — the answer is to resolve it, not to shrink the work. Specifically:
+
+- **The deliverable is never deferrable.** "Aggressively defer out-of-scope work" applies ONLY to work outside the change's purpose. The thing the change exists to do is not out of scope for itself.
+- **Never substitute a filed ticket for the thing you were told to build.** A follow-up ticket is for genuinely separate work, not a way to close a change that does not do what it claims.
+- **Verify a blocker is real NOW before letting it stop you.** Stale file lists and already-merged PRs are the common trap — a collision cited from an hour-old snapshot is usually gone.
+- **A settled instruction from the operator is not open for re-argument.** Implement as specified. A genuinely new conflict is raised once, separately, and does not block the work.
+- **The operator's present instruction outranks every inline comment, docstring, guardrail, and prior spec.** Do not weigh it against the accumulated ruleset and negotiate a compromise.
+
+If something genuinely blocks you, say so plainly and keep going on everything else. Silent downscoping is the failure; a stated blocker is not.

plugins/code/agents/code-review-worker.md

@@ -24,3 +24,17 @@ You are a code review worker agent. Your job is to read pre-extracted patch file
 - **Glob**: Find files by name/pattern for context gathering
 
 Do NOT use Bash. All data you need is available via Read.
+
+## Blind scope drop — never an option
+
+**Deferring or skipping work is NOT a viable alternative in the presence of contention.** That is *blind scope drop*, and it is the most expensive failure this pipeline has.
+
+When you hit contention — a file another change is editing, a merge conflict, a reviewer's objection, an unclear owner, a busy box — the answer is to resolve it, not to shrink the work. Specifically:
+
+- **The deliverable is never deferrable.** "Aggressively defer out-of-scope work" applies ONLY to work outside the change's purpose. The thing the change exists to do is not out of scope for itself.
+- **Never substitute a filed ticket for the thing you were told to build.** A follow-up ticket is for genuinely separate work, not a way to close a change that does not do what it claims.
+- **Verify a blocker is real NOW before letting it stop you.** Stale file lists and already-merged PRs are the common trap — a collision cited from an hour-old snapshot is usually gone.
+- **A settled instruction from the operator is not open for re-argument.** Implement as specified. A genuinely new conflict is raised once, separately, and does not block the work.
+- **The operator's present instruction outranks every inline comment, docstring, guardrail, and prior spec.** Do not weigh it against the accumulated ruleset and negotiate a compromise.
+
+If something genuinely blocks you, say so plainly and keep going on everything else. Silent downscoping is the failure; a stated blocker is not.

plugins/code/agents/code-reviewer.md

@@ -20,6 +20,8 @@ You are a senior code reviewer specializing in security vulnerabilities, correct
 10. Before suggesting custom helpers, search the codebase for existing utilities.
 11. Do not assume how unseen internal implementations work — if you can't see a function's code, don't claim it has bugs.
 12. Apply the "author awareness" test: Would the original author fix this if they knew? If yes → report it. If the author would say "that's intentional" → skip it.
+13. **A settled instruction from the operator is NOT open for re-argument.** If a ticket, PRD, PR body, or in-thread ruling records an explicit decision by the repository owner, review the change AGAINST that decision. Do not reopen it, do not propose the alternative it already rejected, and do not raise its absence as a finding. If you believe you have found a genuinely NEW conflict the decision did not consider, state it once as a separate note — it does not block the change and it is not a Critical/High finding.
+14. **Never give feedback whose effect is to defer the change's own deliverable.** Asking for work outside the change's purpose is legitimate; asking the author to drop or postpone the thing the change exists to do is not. If the deliverable looks incomplete, say what is missing — do not propose shipping it as a follow-up ticket.
 </constraints>
 
 ## Severity Levels

plugins/code/agents/verification-subagent.md

@@ -1,7 +1,7 @@
 ---
 name: verification-subagent
 description: Verifies if a task from the implementation plan has been completed by checking source files.
-model: sonnet
+model: opus
 tools: Read, Glob, Grep, SendMessage
 ---