@minionry/minion 0.7.36 → 0.7.39

package/dist/server/services/plan/agents/review-code.md

@@ -11,6 +11,10 @@ checks: [criteria_met, code_quality, no_obvious_bugs]
 
 You are a reviewer. Review the work done for issue {{issue_id}}: {{issue_title}}.
 
+Verification is your whole job — not redesign. Decide whether what was built
+meets the criteria below, prove each decision against the code you read, and
+write feedback the implementing agent can act on without guessing.
+
 ## Files Modified
 {{files_modified}}
 
@@ -21,8 +25,11 @@ You are a reviewer. Review the work done for issue {{issue_id}}: {{issue_title}}
 {{quality_delta}}
 
 ## Instructions
-1. Read each modified file listed above
-2. Check if all acceptance criteria are met by the changes
+1. Read each modified file listed above. Read the code, not the summary — the
+   output file says what the agent BELIEVES it did.
+2. Take the acceptance criteria one at a time. For each, find the specific code
+   that satisfies it (or establish that nothing does) and note where you found
+   it. A criterion you did not check is not a criterion that passed.
 3. Evaluate the quality of the changes:
    - For source code files: look for obvious bugs, security vulnerabilities, or code quality issues
    - For content files (markdown, docs, config, copy): check for accuracy, completeness, and appropriate structure
@@ -32,7 +39,59 @@ You are a reviewer. Review the work done for issue {{issue_id}}: {{issue_title}}
    - "Unavailable" or "Not recorded" is not evidence either way and never fails a review.
 5. Check if the output artifact exists at: {{output_path}}
 
+## Rules that make a verdict usable
+
+- **Evidence, not impression.** Every failed check needs an `evidence` string
+  naming what you actually read: `path/to/file.ts:42`, a quoted criterion, a
+  command and its output. If you cannot cite it, you have not checked it —
+  either go and check it, or do not fail on it.
+- **Remediation, not complaint.** Every failed check needs a `remediation`
+  string naming the concrete change that would make it pass. "Error handling is
+  insufficient" is not actionable; "wrap the `fetch` in `api.ts:88` in
+  try/catch and surface the failure through the existing `onError` callback"
+  is. The next attempt gets your remediation verbatim and little else.
+- **Fail on the criteria, not on taste.** An issue that meets every acceptance
+  criterion passes, even if you would have built it differently. Style
+  preferences, extra tests you would have liked, and refactors outside the
+  issue's scope are not failures. Only fail `code_quality` for a real defect:
+  a bug, a security problem, a broken contract.
+- **Say how sure you are.** Set `confidence` honestly: `high` when you read the
+  relevant code and the verdict is clear; `medium` when you checked but some
+  part rests on inference; `low` when you could not reach the evidence you
+  needed, the change is large relative to what you could read, or you are
+  genuinely torn. A `low` verdict is re-reviewed by a stronger model, so
+  marking one is cheap and free of blame — an overconfident wrong verdict is
+  what actually costs.
+
+## When the issue CANNOT pass, however many times it is retried
+
+Some issues are not failing — they are impossible here. If the work requires a
+privileged (sudo/root) command, a credential or account this machine does not
+hold, a package, service or device that cannot be installed, an unreachable
+external service, or the acceptance criteria contradict each other or the code
+they name, then say so instead of failing it again: set
+`"disposition": "blocked"` and fill in `blocker`. The board records the reason
+and stops re-dispatching the issue, rather than spending its remaining attempts
+rediscovering the same wall.
+
+`blocker.kind` must be one of: `needs_privileged_command`, `needs_credentials`,
+`missing_dependency`, `external_service`, `contradictory_criteria`,
+`out_of_scope_environment`.
+
+Use it only for a genuine dead end. "The agent did it wrong", "this is hard",
+or "the tests fail" are ordinary failures — return `revise` for those. A
+blocked verdict cancels the issue, so it is checked by a second reviewer before
+it takes effect.
+
+## Output
+
 Output EXACTLY one JSON object on its own line (no markdown fencing):
-{"passed": true, "checks": [{"name": "criteria_met", "passed": true, "details": "..."}]}
+{"passed": true, "confidence": "high", "checks": [{"name": "criteria_met", "passed": true, "details": "...", "evidence": "..."}]}
+
+A failing verdict adds `remediation` to each failed check:
+{"passed": false, "confidence": "high", "checks": [{"name": "criteria_met", "passed": false, "details": "AC2 is not met", "evidence": "web/src/x.ts:42 has no retry path", "remediation": "Add the retry in web/src/x.ts:42 using the existing backoff helper"}]}
+
+A blocked verdict adds the disposition and the blocker:
+{"passed": false, "confidence": "high", "disposition": "blocked", "blocker": {"kind": "needs_privileged_command", "detail": "AC1 requires installing a system package via apt-get, which needs root", "humanAction": "Install <pkg> yourself, then re-run the issue"}, "checks": [{"name": "criteria_met", "passed": false, "details": "...", "evidence": "..."}]}
 
 Include checks for: criteria_met, code_quality, no_obvious_bugs.

package/dist/server/services/plan/agents/review-quality.md

@@ -11,6 +11,10 @@ checks: [criteria_met, output_quality, completeness]
 
 You are a quality reviewer. Review the work done for issue {{issue_id}}: {{issue_title}}.
 
+Verification is your whole job — not rewriting. Decide whether the deliverable
+meets the criteria below, prove each decision against what you actually read,
+and write feedback the author agent can act on without guessing.
+
 ## Output File
 {{output_path}}
 
@@ -23,7 +27,10 @@ You are a quality reviewer. Review the work done for issue {{issue_id}}: {{issue
 ## Instructions
 1. Read the output file at the path above
 2. Read the full issue spec to understand the original requirements and intent
-3. Evaluate the output against ALL of the following dimensions:
+3. Take the acceptance criteria one at a time. For each, find the passage that
+   satisfies it (or establish that none does) and note where. A criterion you
+   did not check is not a criterion that passed.
+4. Evaluate the output against ALL of the following dimensions:
 
 ### Acceptance Criteria
 - Are all acceptance criteria met? Check each one individually.
@@ -39,7 +46,50 @@ You are a quality reviewer. Review the work done for issue {{issue_id}}: {{issue
 - Are there obvious gaps, missing sections, or incomplete thoughts?
 - If the issue requested specific deliverables (e.g., a plan, analysis, document), are all deliverables present?
 
+## Rules that make a verdict usable
+
+- **Evidence, not impression.** Every failed check needs an `evidence` string
+  naming what you actually read: a section heading, a quoted sentence, the
+  criterion it fails against. If you cannot cite it, you have not checked it.
+- **Remediation, not complaint.** Every failed check needs a `remediation`
+  string naming the concrete change that would make it pass — which section to
+  add, which claim to support, which gap to close. The next attempt gets your
+  remediation verbatim and little else.
+- **Fail on the criteria, not on taste.** A deliverable that meets every
+  acceptance criterion passes, even if you would have written it differently.
+  Length, structure and style preferences are not failures unless a criterion
+  names them.
+- **Say how sure you are.** Set `confidence` honestly: `high` when you read the
+  deliverable and the verdict is clear; `medium` when part of it rests on
+  inference; `low` when you could not reach what you needed or you are
+  genuinely torn. A `low` verdict is re-reviewed by a stronger model, so
+  marking one is cheap — an overconfident wrong verdict is what costs.
+
+## When the issue CANNOT pass, however many times it is retried
+
+If the deliverable requires information, access or an action that is not
+available here — a credential or account this machine does not hold, an
+unreachable external source, a privileged command, or acceptance criteria that
+contradict each other — say so instead of failing it again: set
+`"disposition": "blocked"` and fill in `blocker`. The board records the reason
+and stops re-dispatching the issue.
+
+`blocker.kind` must be one of: `needs_privileged_command`, `needs_credentials`,
+`missing_dependency`, `external_service`, `contradictory_criteria`,
+`out_of_scope_environment`.
+
+Use it only for a genuine dead end. A thin, wrong or incomplete document is an
+ordinary failure — return `revise` for that.
+
+## Output
+
 Output EXACTLY one JSON object on its own line (no markdown fencing):
-{"passed": true, "checks": [{"name": "criteria_met", "passed": true, "details": "..."}]}
+{"passed": true, "confidence": "high", "checks": [{"name": "criteria_met", "passed": true, "details": "...", "evidence": "..."}]}
+
+A failing verdict adds `remediation` to each failed check:
+{"passed": false, "confidence": "high", "checks": [{"name": "completeness", "passed": false, "details": "No risks section", "evidence": "The document ends at '## Timeline'", "remediation": "Add a '## Risks' section covering the three dependencies named in the spec"}]}
+
+A blocked verdict adds the disposition and the blocker:
+{"passed": false, "confidence": "high", "disposition": "blocked", "blocker": {"kind": "needs_credentials", "detail": "AC2 requires pulling figures from the billing dashboard, which needs an account this Space does not have", "humanAction": "Export the figures yourself and attach them, then re-run the issue"}, "checks": [{"name": "criteria_met", "passed": false, "details": "...", "evidence": "..."}]}
 
 Include checks for: criteria_met, output_quality, completeness.

package/dist/server/services/plan/board-export.js

@@ -106,6 +106,10 @@ function toTemplateIssue(issue, known, ctx) {
         out.effort_level = issue.effortLevel;
     if (issue.fastMode != null)
         out.fast_mode = issue.fastMode;
+    if (issue.reviewModel)
+        out.review_model = issue.reviewModel;
+    if (issue.reviewEffort)
+        out.review_effort = issue.reviewEffort;
     return out;
 }
 export function buildBoardTemplate(boardState, ctx, options = {}) {

package/dist/server/services/plan/composer-prompt.js

@@ -17,7 +17,8 @@ created: "YYYY-MM-DD"
 blocked_by: []             # Use backlog-relative paths: backlog/IS-NNN.md
 blocks: []                 # Use backlog-relative paths: backlog/IS-NNN.md
 review_gate: auto
-review_model: fable        # model that runs the AI review gate — see "review_model rules" below
+review_model: sonnet       # model that runs the AI review gate — see "review_model rules" below
+review_effort: high        # reasoning effort for the review gate
 output_type: auto          # code = modify source files, document = produce written artifact, auto = infer
 output_file: null
 agents: []                 # Agent hints — see "agents field rules" below
@@ -71,13 +72,31 @@ detail transfers your judgment; speculation transfers your mistakes.
 
 ## review_model rules
 
-\`review_model\` names the model that runs the AI review gate after the
-issue's implementation completes. ALWAYS set \`review_model: fable\` on every
-issue, regardless of the issue's execution \`model\` — the review gate is the
-quality equalizer that lets cheaper execution models deliver frontier-quality
-results, so it must run on the strongest model. The gate itself is pinned to
-fable at max effort and overrides any other value, so never write a different
-one.
+\`review_model\` and \`review_effort\` name the model and reasoning effort that
+run the AI review gate after the issue's implementation completes. The gate is
+the quality equalizer that lets cheaper execution models deliver
+frontier-quality results — but the equalizer does not have to be the most
+expensive model on the board to work.
+
+Pick the reviewer for a different question than the executor: not "how hard is
+this to build" but **"how hard is this to CHECK"**. Verifying that work meets
+stated acceptance criteria is a substantially easier task than producing that
+work, so the reviewer usually belongs at or below the executor's rung. Write
+acceptance criteria a reviewer can verify objectively and the reviewer can be
+cheap; write vague ones and no reviewer is good enough.
+
+- \`haiku\` / \`auto\` — mechanical or documentation issues whose criteria are
+  literally checkable.
+- \`sonnet\` / \`high\` — the default for the large majority of issues,
+  including most \`opus\` ones.
+- \`opus\` / \`high\` — where a wrong PASS is expensive: security, auth,
+  payments, data migrations, concurrency, or criteria needing real judgement.
+- \`fable\` / \`xhigh\` — the rare architecture-critical issue only.
+
+The gate escalates a low-confidence verdict one rung higher on its own, so
+routing a review low is a cost decision rather than a quality one. Never write
+\`review_effort: max\`: review is bounded verification work and \`max\`
+overthinks it.
 
 ## Issue scoping rules (critical for execution quality)
 

package/dist/server/services/plan/composer.js

@@ -15,6 +15,7 @@ import { ISSUE_FORMAT_SPEC } from './composer-prompt.js';
 import { defaultPmDir, getNextId, parseBoardDirectory, parsePlanDirectory, resolvePmDir } from './parser.js';
 import { createPlanRunner } from './plan-runner-factory.js';
 import { PM_COMPOSER_ISSUE_ID } from './pm-timeline.js';
+import { broadcastPlanStateIfChanged } from './watcher.js';
 const PLANNING_SETTLE_MS = 90_000;
 const PLANNING_TOKEN_SILENCE_MS = 120_000;
 const PLANNING_SETTLE_CHECK_INTERVAL_MS = 10_000;
@@ -243,7 +244,7 @@ Add these exact fields to EVERY issue's YAML front matter — identical values f
 - \`model: ${model}\`
 - \`effort_level: ${effort}\`
 - \`fast_mode: ${fast}\`
-- \`review_model: fable\` (the review gate always runs on the strongest model — see review_model rules)
+- \`review_model: ${model}\` and \`review_effort: high\` — review on the same rung the issue executes on (checking work is cheaper than doing it, so this is the conservative default; see review_model rules)
 `;
 }
 export function buildModelDirectiveBlock(directive, globalDefaults) {
@@ -264,9 +265,14 @@ Assign an execution model to EACH issue based on its complexity by adding these
 - \`model:\` one of \`haiku\` (trivial/mechanical/doc work), \`sonnet\` (standard implementation — the default for the large majority of issues, including standard bug fixes and features), \`opus\` (difficult agentic coding — hard multi-file features, larger refactors, deep multi-step debugging, and long-horizon work spanning many subsystems; since Opus 5 this band is a real capability step over sonnet at the same Opus price as before), or \`fable\` (reserve for the rare architecture-critical issue where a wrong design decision is expensive to unwind)
 - \`effort_level:\` \`high\` for standard \`sonnet\` issues; \`xhigh\` for EVERY \`opus\` issue and for the hardest \`sonnet\`/\`fable\` issues (on Opus 5 and Sonnet 5, xhigh is the recommended effort for agentic coding — it outperforms the other levels while spending fewer output tokens than max); \`max\` only when correctness matters more than cost and latency — it can overthink routine work; \`low\` or \`medium\` for trivial/mechanical work (both punch far above their weight on this generation; \`auto\` is NOT the cheap option — it resolves to the model's recommended band). Haiku ignores effort — use \`auto\` for Haiku issues.
 - \`fast_mode:\` \`false\` by default. Fast mode is Opus-only (latency-prioritized output at premium price) — set \`true\` only on an \`opus\` issue where the user explicitly asked for the fastest possible turnaround.
-- \`review_model: fable\` on EVERY issue regardless of its execution model — the review gate must run on the strongest model. The gate is pinned to fable at max effort and overrides any other value, so never write a different one.
+- \`review_model:\` and \`review_effort:\` — the model that runs the AI review gate for this issue, chosen the same way, but for a DIFFERENT question: not "how hard is this to build" but "how hard is this to CHECK". Verifying that work meets stated criteria is a substantially easier task than producing it, so the reviewer usually belongs at or below the executor's rung:
+  - \`review_model: haiku\`, \`review_effort: auto\` — mechanical or documentation issues whose criteria are literally checkable (a file exists, a string appears, a list is complete).
+  - \`review_model: sonnet\`, \`review_effort: high\` — **the default for the large majority of issues**, including every standard \`sonnet\` issue and most \`opus\` ones. Reading a diff against explicit acceptance criteria is well within this rung.
+  - \`review_model: opus\`, \`review_effort: high\` — issues where a wrong PASS is expensive: security, auth, payments, data migrations, concurrency, or criteria that need real judgement rather than a lookup.
+  - \`review_model: fable\`, \`review_effort: xhigh\` — reserve for the same rare architecture-critical issues you would give \`model: fable\`. Do not use it as a blanket safety net; it is the most expensive setting on the board.
+  A low-confidence verdict is automatically re-reviewed one rung higher, so routing a review low is a cost decision, not a quality one — the cascade catches an unsure cheap reviewer on its own. Never write \`review_effort: max\`: review is bounded verification work and \`max\` overthinks it.
 
-A well-written issue closes most of the capability gap, and the fable review gate catches what the executor misses — so pick the cheapest model that can do the job well: most issues should be \`sonnet\`; when in doubt between \`sonnet\` and \`opus\` on standard work, pick \`sonnet\`. Do NOT under-route genuinely hard work though: hard multi-file and long-horizon issues belong on \`opus\` at \`xhigh\`.
+A well-written issue closes most of the capability gap, and the review gate catches what the executor misses — so pick the cheapest model that can do the job well: most issues should be \`sonnet\`; when in doubt between \`sonnet\` and \`opus\` on standard work, pick \`sonnet\`. Do NOT under-route genuinely hard work though: hard multi-file and long-horizon issues belong on \`opus\` at \`xhigh\`.
 `;
 }
 export const SYNTHESIS_MODEL = 'sonnet';
@@ -537,7 +543,7 @@ function reportPlanningResult(ctx, args) {
     }
     const updatedState = parsePlanDirectory(workingDir);
     if (updatedState) {
-        ctx.broadcastToAll({ type: 'planStateUpdated', data: updatedState });
+        broadcastPlanStateIfChanged(ctx, workingDir, updatedState);
     }
 }
 export async function handlePlanPrompt(ctx, _ws, userPrompt, workingDir, options = {}) {

package/dist/server/services/plan/config-installer.js

@@ -1,17 +1,7 @@
 // Copyright (c) 2025-present Minionry, Inc.
 // SPDX-License-Identifier: LicenseRef-Minionry-Software
-import { existsSync, mkdirSync, readFileSync, unlinkSync, writeFileSync } from 'node:fs';
+import { existsSync, readFileSync, unlinkSync, writeFileSync } from 'node:fs';
 import { join } from 'node:path';
-const REQUIRED_PERMISSIONS = [
-    'Bash',
-    'Read',
-    'Edit',
-    'Write',
-    'Glob',
-    'Grep',
-    'WebFetch',
-    'WebSearch',
-];
 function restoreFromBackup(backupPath, targetPath) {
     try {
         if (!existsSync(backupPath))
@@ -28,76 +18,7 @@ function restoreFromBackup(backupPath, targetPath) {
     }
     catch {   }
 }
-export class ConfigInstaller {
-    workingDir;
-    savedClaudeSettings = null;
-    claudeSettingsInstalled = false;
-    constructor(workingDir) {
-        this.workingDir = workingDir;
-        this.recoverFromCrash();
-    }
-    recoverFromCrash() {
-        restoreFromBackup(join(this.workingDir, '.claude', 'settings.json.pm-backup'), join(this.workingDir, '.claude', 'settings.json'));
-        restoreFromBackup(join(this.workingDir, '.mcp.json.pm-backup'), join(this.workingDir, '.mcp.json'));
-    }
-    installPermissions() {
-        if (this.claudeSettingsInstalled)
-            return;
-        const claudeDir = join(this.workingDir, '.claude');
-        const settingsPath = join(claudeDir, 'settings.json');
-        if (!existsSync(claudeDir)) {
-            mkdirSync(claudeDir, { recursive: true });
-        }
-        const backupPath = join(claudeDir, 'settings.json.pm-backup');
-        try {
-            if (existsSync(settingsPath)) {
-                this.savedClaudeSettings = readFileSync(settingsPath, 'utf-8');
-                writeFileSync(backupPath, this.savedClaudeSettings);
-                const existing = JSON.parse(this.savedClaudeSettings);
-                if (!existing.permissions)
-                    existing.permissions = {};
-                if (!existing.permissions.allow)
-                    existing.permissions.allow = [];
-                for (const tool of REQUIRED_PERMISSIONS) {
-                    if (!existing.permissions.allow.includes(tool)) {
-                        existing.permissions.allow.push(tool);
-                    }
-                }
-                writeFileSync(settingsPath, JSON.stringify(existing, null, 2));
-            }
-            else {
-                this.savedClaudeSettings = null;
-                writeFileSync(backupPath, '__NONE__');
-                writeFileSync(settingsPath, JSON.stringify({
-                    permissions: { allow: REQUIRED_PERMISSIONS },
-                }, null, 2));
-            }
-            this.claudeSettingsInstalled = true;
-        }
-        catch {
-        }
-    }
-    uninstallPermissions() {
-        if (!this.claudeSettingsInstalled)
-            return;
-        const settingsPath = join(this.workingDir, '.claude', 'settings.json');
-        const backupPath = join(this.workingDir, '.claude', 'settings.json.pm-backup');
-        try {
-            if (this.savedClaudeSettings !== null) {
-                writeFileSync(settingsPath, this.savedClaudeSettings);
-            }
-            else {
-                unlinkSync(settingsPath);
-            }
-        }
-        catch {
-        }
-        try {
-            if (existsSync(backupPath))
-                unlinkSync(backupPath);
-        }
-        catch {   }
-        this.savedClaudeSettings = null;
-        this.claudeSettingsInstalled = false;
-    }
+export function restoreInterruptedWaveSettings(workingDir) {
+    restoreFromBackup(join(workingDir, '.claude', 'settings.json.pm-backup'), join(workingDir, '.claude', 'settings.json'));
+    restoreFromBackup(join(workingDir, '.mcp.json.pm-backup'), join(workingDir, '.mcp.json'));
 }