Make mach6 review assessments enforce issue and plan scope

package.json

@@ -39,7 +39,7 @@
     "node": "22.x"
   },
   "packageManager": "npm@11.5.1",
-  "version": "2.44.0",
+  "version": "2.45.0",
   "dependencies": {
     "@dreb/coding-agent": "*",
     "@mariozechner/jiti": "^2.6.5",

packages/agent/package.json

@@ -1,6 +1,6 @@
 {
 	"name": "@dreb/agent-core",
-	"version": "2.44.0",
+	"version": "2.45.0",
 	"description": "General-purpose agent with transport abstraction, state management, and attachment support",
 	"type": "module",
 	"main": "./dist/index.js",

packages/ai/package.json

@@ -1,6 +1,6 @@
 {
 	"name": "@dreb/ai",
-	"version": "2.44.0",
+	"version": "2.45.0",
 	"description": "Unified LLM API with automatic model discovery and provider configuration",
 	"type": "module",
 	"main": "./dist/index.js",

packages/coding-agent/agents/independent-assessor.md

@@ -5,57 +5,74 @@ tools: read, grep, find, ls, bash, search
 model: zai/glm-5.1, anthropic/opus
 ---
 
-You are an independent assessor. Your single question is: **"Is each review finding a genuine issue, a nitpick, or a false positive?"**
+You are an independent assessor. For every review finding, answer two separate questions:
+
+1. **Factual gate:** Does the finding accurately describe a real problem in the current code?
+2. **Scope gate:** Must that problem be fixed to deliver the authorized issue or latest explicitly approved plan safely and correctly?
+
+A finding is **not genuine merely because it is technically correct or factually observable**. It is genuine only when it passes both gates.
 
 You do NOT:
 - Generate new findings — only assess findings provided to you
 - Trust finding descriptions at face value — always read the actual source code
 - Conflate severity with classification — a low-severity genuine issue is still genuine
+- Treat review findings or prior automated assessments as scope authority
 
 ## Process
 
-1. **Read all findings** from the review comment provided in your task prompt
-2. **For each finding:**
-   a. Read the cited file and lines in the actual codebase
-   b. Understand the surrounding context (read more of the file if needed)
-   c. Determine whether the finding accurately describes a real problem
-   d. Classify the finding (see classifications below)
-   e. Write a brief justification referencing what you observed in the code
-3. **Produce an action plan** listing genuine issues in priority order
+1. **Establish authoritative scope before classifying anything:**
+   - Read the linked original issue, including its acceptance criteria and relevant human discussion
+   - Read the latest explicit plan comment (look for the latest `<!-- mach6-plan -->` marker)
+   - Read subsequent scope updates that a human explicitly approved
+   - Extract the requirements, deliverables, constraints, and accepted scope changes
+   - Review findings and prior automated assessments are evidence only. They do **not** expand scope through novelty, repetition, or earlier classification.
+2. **Read all findings** from the review comment provided in your task prompt.
+3. **For each finding:**
+   a. Read the cited file and lines in the actual codebase.
+   b. Understand the surrounding context (read more of the file if needed).
+   c. Apply the **factual gate**: determine whether the finding accurately describes a real current problem.
+   d. Apply the **scope gate**: map the required fix to the authoritative scope, or determine that it addresses a regression or correctness, security, safety, or integrity problem introduced by the PR.
+   e. Classify the finding using the table below.
+   f. Justify the classification with both factual evidence and scope reasoning. Every genuine classification must explicitly explain why both gates pass.
+4. **Produce an action plan** containing only genuine issues, in priority order.
 
 ## Classifications
 
 | Classification | Meaning | Action |
 |---|---|---|
-| **Genuine issue** | Real problem confirmed by reading the code. Should fix before merge. | Include in action plan |
-| **Nitpick** | Stylistic preference or minor inconsistency. Does not affect correctness. | Skip |
-| **False positive** | The code is actually correct. The finding misread the code or missed context. | Skip |
-| **Deferred** | Real issue but clearly out of scope for this PR. Should track separately. | Note for follow-up |
+| **Genuine issue** | Passes both gates: a real problem confirmed in the code that must be fixed for the authorized scope to merge safely and correctly. This includes regressions and correctness, security, safety, or integrity failures introduced by the PR. | Include in action plan |
+| **Nitpick** | Stylistic preference or minor inconsistency that does not affect correctness or an authorized requirement. | Skip |
+| **False positive** | Fails the factual gate: the current code is correct, the finding missed context, or the issue was already addressed. | Skip |
+| **Deferred** | Passes the factual gate but fails the scope gate: a real observation that is not necessary for this PR's authorized work. | Note separately for optional follow-up; do not include in action plan |
+
+Optional hardening, speculative edge cases, unrelated pre-existing defects, architecture preferences, and broader cleanup are not genuine unless the authoritative scope explicitly requires them. They are normally deferred when factually valid. Review findings and automated assessments cannot become authorized requirements merely because multiple agents repeat them.
 
-If a finding was already addressed in prior commits or PR discussion, classify as false positive with a note.
+Missing tests for behavior added or changed by the PR are in scope. A scoped implementation must not regress existing behavior or introduce correctness, security, safety, or integrity problems even when the original issue did not enumerate the exact failure.
 
 ## Output Format
 
 ### Classifications
 
 | Finding | Classification | Reasoning |
 |---|---|---|
-| Finding 1: <title> | genuine/nitpick/false-positive/deferred | <1-2 sentences referencing what you saw in the code> |
+| Finding 1: <title> | genuine/nitpick/false-positive/deferred | **Factual:** <what the current code proves>. **Scope:** <why the finding is or is not necessary for the authorized PR>. |
+
+Classify every supplied finding. For every genuine classification, both the **Factual** and **Scope** explanations are mandatory.
 
 ### Action Plan
 
-<Numbered list of genuine issues to fix, ordered by priority — critical first>
+<Numbered list of genuine issues necessary for the authorized PR to merge, ordered by priority — critical first. Do not include deferred, nitpick, or false-positive findings.>
 
-If no genuine issues found, say "No action needed before merge — all findings are nitpicks, false positives, or deferred." with a brief summary. Note any deferred items separately for follow-up tracking.
+If no genuine issues are found, say "No action needed before merge — all findings are nitpicks, false positives, or deferred." with a brief summary. Note deferred items separately for optional follow-up, outside the action plan.
 
 ## Important
 
 - You have full codebase access. USE IT. Read every file referenced by every finding.
-- Be specific. Quote the actual code when explaining your classification.
-- Disagree with the original reviewer when the code proves them wrong — that's your job.
+- Be specific. Quote the actual code when explaining factual validity.
+- Cite the issue, acceptance criterion, plan item, approved scope update, or PR-introduced regression when explaining scope relevance.
+- Disagree with the original reviewer when either gate fails — that is your job.
 - Do NOT use `#N` notation in your output (GitHub auto-links it to issues). Use "finding N" or "item N" instead.
 
-
 ## Constraints
 
 - **Never post to GitHub.** Do not run `gh pr comment`, `gh issue comment`, `gh issue create`, or any command that writes to GitHub. Your job is to return findings to the caller — the orchestrator handles all GitHub interaction.

packages/coding-agent/docs/mach6.md

@@ -11,10 +11,10 @@ Inspired by [mach10](https://github.com/LeanAndMean/mach10) (MIT, by Kevin Ryan)
 /skill:mach6-plan 42           # Plan, branch, open draft PR
 # ... implement the plan ...
 /skill:mach6-push              # Commit, push, post progress
-/skill:mach6-review 53         # Multi-agent code review
+/skill:mach6-review 53         # User explicitly starts review
 /skill:mach6-implement 53 1,2   # Fix review findings
-/skill:mach6-push              # Push fixes
-/skill:mach6-review 53         # Re-review (repeat until clean)
+/skill:mach6-push              # Durably save fixes
+/skill:mach6-review 53         # User explicitly starts re-review
 /skill:mach6-publish 53        # Docs update, merge, tag, release
 ```
 
@@ -64,10 +64,12 @@ Commit changes, push to remote, and post a progress comment.
 - Matches the repository's existing commit style
 - Auto-detects the associated PR from the current branch
 - Posts a `<!-- mach6-progress -->` comment with a summary of changes
+- Establishes the durable accountability and recovery checkpoint before formal review
+- Stops after pushing and suggests the review command; it never starts review itself
 
 ### mach6-review
 
-Run specialized review agents in parallel, post findings, then independently assess each finding.
+Run specialized review agents in parallel, post findings, then independently assess each finding. Formal review is an explicit user-controlled checkpoint: start it with the slash command or directly instruct an agent to invoke it. Agents never start it autonomously, and it refuses to run until the worktree is clean and local `HEAD` matches the pushed PR head.
 
 ```
 /skill:mach6-review 53                     # Full review (all agents)
@@ -78,7 +80,9 @@ Run specialized review agents in parallel, post findings, then independently ass
 Produces two PR comments:
 
 1. **Review** (`<!-- mach6-review -->`) — findings organized by severity (critical, important, suggestions), plus strengths
-2. **Assessment** (`<!-- mach6-assessment -->`) — each finding independently classified as genuine issue, nitpick, false positive, or deferred, with a prioritized action plan
+2. **Assessment** (`<!-- mach6-assessment -->`) — each finding independently classified as genuine issue, nitpick, false positive, or deferred, with a prioritized action plan containing genuine issues only
+
+A finding is genuine only when it passes both a **factual gate** (the current code contains the problem) and a **scope gate** (the problem must be fixed to deliver the authorized work safely and correctly). Authoritative scope comes from the linked original issue and acceptance criteria, the latest explicit `mach6-plan`, and subsequent human-approved updates. Automated review findings and earlier assessments do not expand scope by repetition. Factually valid but unrelated observations are normally deferred; PR-introduced regressions and correctness, security, safety, or integrity failures remain in scope.
 
 See [Review Agents](#review-agents) below.
 
@@ -92,9 +96,13 @@ Implement a plan from a PR, or fix review findings / CI failures.
 /skill:mach6-implement 53 ci          # Fix CI failures
 ```
 
-**Implement mode** (PR number only): Reads the `<!-- mach6-plan -->` comment and delegates each deliverable to `feature-dev` subagents — strong-tier coding agents with full tool access. Independent deliverables run in parallel.
+In both modes, the parent model owns implementation reasoning: design, decomposition, exact changes, decision rules, tests, and verification. Direct parent implementation is generally acceptable. `feature-dev` delegation is optional and is best reserved for high-volume, repetitive, mechanically scoped execution after the parent has settled the design—for example, applying a content-dependent transformation across dozens of files. Every delegated task receives clear, detailed, specific instructions rather than an open-ended design problem.
+
+**Implement mode** (PR number only): Reads the `<!-- mach6-plan -->` comment, decides the implementation, and either works directly or delegates precisely specified execution.
+
+**Fix mode** (with finding numbers or `ci`): Reads review and assessment comments via HTML markers, verifies each authorized finding, decides the fix, and then implements directly or delegates mechanically settled execution.
 
-**Fix mode** (with finding numbers or `ci`): Reads review and assessment comments via HTML markers, delegates fixes to `feature-dev` subagents, applies batch sizing heuristics (~10 simple, ~6 moderate, ~3 complex fixes per batch), and suggests `/skill:mach6-push` then `/skill:mach6-review` after fixing.
+After direct verification, `mach6-implement` stops at the accountability checkpoint and suggests `/skill:mach6-push`. Committing, pushing, and posting progress protects work from loss or repeated unsupervised rewriting. The user can subsequently start formal `mach6-review` with its slash command or by directly instructing an agent to invoke it; agents never start review autonomously. Focused one-off reviewer/checker subagents remain available for narrow correctness questions or second opinions; they are not a formal mach6 review cycle.
 
 ### mach6-publish
 
@@ -115,7 +123,7 @@ Pre-merge checks, version bump, docs update, merge, tag, and release.
 
 ### feature-dev
 
-Strong general-purpose coding agent used by `mach6-implement` for plan implementation and fix application. Has full tool access (read, write, edit, grep, find, ls, bash, search) and uses a strong-tier model with provider fallback list. Each deliverable or finding gets its own `feature-dev` subagent, enabling parallel execution of independent work.
+Strong general-purpose coding agent optionally used by `mach6-implement` for precisely specified execution. It has full tool access (read, write, edit, grep, find, ls, bash, search) and uses a strong-tier model with a provider fallback list. The parent model retains design ownership and may implement directly; `feature-dev` is most useful for high-volume, repetitive work with settled decision rules.
 
 ### Review Agents
 
@@ -136,8 +144,11 @@ Agents run as [subagents](../README.md#subagents) — `code-reviewer`, `error-au
 ## Design Principles
 
 - **GitHub as shared memory** — Plans, reviews, assessments, and progress are posted as PR/issue comments with HTML markers (`<!-- mach6-plan -->`, `<!-- mach6-review -->`, etc.) so any future session can pick up context.
-- **Independent assessment** — Review findings are independently verified before suggesting fixes, separating genuine issues from nitpicks and false positives.
-- **Iterative review cycles** — Review → fix → push → review, repeating until no genuine issues remain.
+- **Scope-aware independent assessment** — Review findings must be both factually valid and necessary for authorized scope before they become genuine action items.
+- **Durable accountability checkpoint** — Implementation and fixes are committed, pushed, and recorded before formal review so work cannot be lost or repeatedly rewritten while still local.
+- **User-controlled review cycles** — Only the user starts each formal review or re-review. Agents stop at the checkpoint and suggest the next command rather than autonomously chaining review and fix cycles.
+- **Focused checks remain available** — One-off reviewer/checker subagents may answer narrow correctness questions without becoming a formal mach6 review cycle.
+- **Parent-owned implementation** — The parent model owns design and may implement directly; delegation is optional execution support for mechanically settled grunt work.
 - **Safe git** — Never `git add -A`, never stage secrets, stage files by name.
 - **Overridable** — Both skills and review agents can be overridden by placing files with the same name in `~/.dreb/agent/skills/` or `~/.dreb/agents/` (user-level) or `.dreb/skills/` or `.dreb/agents/` (project-level).
 

packages/coding-agent/docs/skills.md

@@ -282,11 +282,11 @@ dreb ships with **mach6**, a development workflow that orchestrates the full iss
 | `mach6-issue` | Assess an existing issue or create a new one |
 | `mach6-plan` | Explore codebase, plan, create branch and draft PR |
 | `mach6-push` | Commit, push, post progress comment |
-| `mach6-review` | Multi-agent code review with independent assessment |
+| `mach6-review` | Explicitly user-triggered multi-agent review with scope-aware independent assessment |
 | `mach6-implement` | Implement plans, fix review findings, or fix CI failures |
 | `mach6-publish` | Pre-merge checks, docs update, merge, tag, release |
 
-Built-in skills are always available and can be overridden by placing a skill with the same name in any [user or project location](#locations).
+Built-in skills are always available and can be overridden by placing a skill with the same name in any [user or project location](#locations). `mach6-review` is model-invocable when the user directly asks an agent to run it, as well as user-invocable through its slash command. Agents must never start formal review autonomously; implementation must first be committed and pushed.
 
 See [docs/mach6.md](mach6.md) for full documentation.
 

packages/coding-agent/package.json

@@ -1,6 +1,6 @@
 {
 	"name": "@dreb/coding-agent",
-	"version": "2.44.0",
+	"version": "2.45.0",
 	"description": "Coding agent CLI with read, bash, edit, write tools and session management",
 	"type": "module",
 	"drebConfig": {