@yemi33/minions 0.1.1886 → 0.1.1887

package/engine/lifecycle.js

@@ -1624,8 +1624,22 @@ async function updatePrAfterReview(agentId, pr, project, config, resultSummary,
   if (!postReviewStatus) {
     const verdict = reviewVerdictFromCompletion(structuredCompletion) || parseReviewVerdict(resultSummary);
     if (verdict) {
-      postReviewStatus = verdict;
-      log('info', `Read review verdict from agent completion for ${reviewPr.id}: ${verdict}`);
+      // P-e1c8a9d2 — Refuse self-review APPROVE: an agent approving their own PR
+      // is meaningless self-promotion (PR #1867/#1868/#2253 all shipped this way).
+      // Treat it like a bailout — don't apply the verdict (so reviewStatus stays
+      // 'waiting' and the engine routes the next review to a different agent on
+      // the next dispatch tick). The verdict-gate at runPostCompletionHooks sees
+      // the verdict and skips the no-verdict retry path, so _retryCount stays
+      // unchanged. REQUEST_CHANGES from a self-author is still accepted — a
+      // self-author flagging issues on their own PR is harmless and useful.
+      const reviewerLower = String(agentId || '').toLowerCase();
+      const authorLower = String(reviewPr.agent || '').toLowerCase();
+      if (verdict === 'approved' && reviewerLower && authorLower && reviewerLower === authorLower) {
+        log('warn', `review verdict rejected: self-review (reviewer=${reviewerName}, author=${reviewPr.agent})`);
+      } else {
+        postReviewStatus = verdict;
+        log('info', `Read review verdict from agent completion for ${reviewPr.id}: ${verdict}`);
+      }
     }
   }
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@yemi33/minions",
-  "version": "0.1.1886",
+  "version": "0.1.1887",
   "description": "Multi-agent AI dev team that runs from ~/.minions/ — five autonomous agents share a single engine, dashboard, and knowledge base",
   "bin": {
     "minions": "bin/minions.js"

package/playbooks/explore.md

@@ -37,7 +37,7 @@ After the requested exploration succeeds, write your findings to `{{team_root}}/
 - **Patterns**: conventions and patterns found
 - **Dependencies**: what depends on what
 - **Gaps**: anything missing, broken, or unclear
-- **Recommendations**: suggestions for the team
+- **Recommended next dispatches**: one bullet per follow-up using the format `<work-type> <agent> — <one-line scope>` (e.g., `implement ralph — wire X helper into Y caller`, `fix lambert — guard Z against null project`). If you have nothing concrete to recommend, the section must read exactly `Recommended next dispatches: none — no follow-up needed`.
 - **Source References**: for EVERY finding, include the source — file paths, line numbers, PR URLs, API endpoints, config keys. Format: `(source: path/to/file.ts:42)` or `(source: PR-12345)`. This is critical — other agents and humans need to verify your findings.
 
 If exploration is blocked or fails before you can produce sourced findings, do **not** write an inbox note. Report the blocker in your final response instead.

package/playbooks/meeting-conclude.md

@@ -31,11 +31,21 @@ Write a clear, **self-contained** meeting conclusion. Someone reading ONLY this
    - What the fix should be (concrete: "change X to Y", "add guard in Z")
    - Estimated complexity (small/medium/large)
 
-2. **Deferred items** — what was discussed but explicitly deprioritized, and why
+2. **Overrules** — required section. Document every priority where you (the synthesizer) chose differently than a participant argued in debate. Each bullet must take this exact form:
 
-3. **Unresolved disagreements** — where positions still differ (if any)
+   - `Overruled <participant>'s claim that <X>; chose <Y> because <reason cited from debate or source file>`
 
-4. **Open questions for human** — what needs human input before proceeding (if any)
+   The cited reason must be a concrete pointer (debate quote, finding ID, or `path/to/file.ext:line`), not a paraphrase. If the synthesizer truly overruled nothing — every priority above converged in debate — the section must read exactly:
+
+   - `Overrules: none — every priority converged in debate`
+
+   Do NOT omit this section. An empty `Overrules:` (without the escape-hatch sentence) is not acceptable.
+
+3. **Deferred items** — what was discussed but explicitly deprioritized, and why
+
+4. **Unresolved disagreements** — where positions still differ (if any)
+
+5. **Open questions for human** — what needs human input before proceeding (if any)
 
 **Be concrete, not vague.** Do NOT write "fix 3 bugs" — write which 3 bugs, in which files, with what fix. The conclusion is used as input to create an implementation plan, so it must contain enough detail to act on without re-reading the entire meeting.
 

package/playbooks/meeting-investigate.md

@@ -25,6 +25,10 @@ Investigate this topic from your unique perspective as {{agent_role}}.
 
 Focus on what YOU uniquely bring to this discussion. Be thorough but concise.
 
+### Evidence rule for code claims
+
+Every claim about repository code — a bug, a regression, a missing guard, a test gap, a behavior assertion — must include a concrete citation: a `path/to/file.ext:line` reference (or range like `path:120-145`) for current code, or a `git show <sha>:<path>` hunk reference when the claim is about a specific commit or historical state. Claims you cannot back with such a reference must be tagged `[unverified]` inline (e.g., "the dispatch loop ignores `paused` items `[unverified]`") so debaters in the next round can call them out and either verify or discard them. Do not paraphrase code from memory and present it as fact; if you have not opened the file in this session, it is `[unverified]`.
+
 ## Output Format
 
 Write your findings as a clear markdown document. Start with your key conclusion, then supporting evidence.

package/playbooks/plan.md

@@ -42,6 +42,7 @@ A user has described a feature they want built. Your job is to create a detailed
 - Order by dependency (foundations first)
 - Estimate complexity: `small` (1 file), `medium` (2-5 files), `large` (6+ files)
 - Each item should be independently testable
+- Also list ideas you considered and chose **not** to include — these go in the required `## Rejected items` section so scope is declared explicitly
 
 ### 5. Write the Plan
 
@@ -65,19 +66,24 @@ What exists today, what needs to change, key files involved.
 ## Approach
 High-level design decisions and rationale.
 
-## Work Breakdown
+## Work items
 
-### Phase 1: Foundation
-1. **Item name** (complexity: small/medium/large)
-   - What to build
-   - Files to create/modify
-   - Acceptance criteria
+Flat numbered list, ordered by dependency in prose (not by phase). Use phases only when items genuinely block each other across PR boundaries; otherwise the plan is a flat numbered list.
 
-### Phase 2: Core Implementation
-2. **Item name** ...
+### 1. <item name> (complexity: small/medium/large)
+- What to build
+- Files to create/modify
+- Acceptance criteria
 
-### Phase 3: Polish & Integration
-3. **Item name** ...
+### 2. <item name> (complexity: small/medium/large)
+- ...
+
+## Rejected items
+
+Required section. Declare scope by listing ideas you considered and chose not to include, one line per rejected item with the reason.
+
+- <rejected idea> — <one-line reason>
+- <rejected idea> — <one-line reason>
 
 ## Risks & Open Questions
 - Risk or question that needs user input

package/playbooks/review.md

@@ -54,7 +54,6 @@ Use subagents only for genuinely parallel, independent tasks (e.g., reviewing un
 
 8. If the code is genuinely ready:
    - Verdict: **APPROVE**
-   - Note any minor non-blocking suggestions
    - Do not request changes for nits, speculative edge cases, or unrelated improvements
 
 ## Post Review — Submit your verdict
@@ -79,10 +78,14 @@ Automated checks:
 - `<command>`: pass/fail/skipped — short result or reason
 
 Blocking issues:
-- None, or `path:line` — issue and required fix
+- `path:line — failure mode — required fix`
+- (one bullet per blocking finding; the literal string `None` is the only allowed empty form)
 
-Non-blocking suggestions:
-- None, or `path:line` — suggestion
+Minimum diff to ship: <one-line description of the smallest change that would flip this verdict to APPROVE>
+(REQUEST_CHANGES only — omit this line on APPROVE verdicts)
+
+Non-blocking observations: None
+- (default to `None`; if you list any, each must be tied to an existing diff line in the form `path:line — observation`)
 ```
 
 After running the command, confirm it succeeded (check the command output for errors). If it fails, retry once.