@yemi33/minions 0.1.334 → 0.1.335

package/CHANGELOG.md

@@ -1,5 +1,10 @@
 # Changelog
 
+## 0.1.335 (2026-04-03)
+
+### Fixes
+-  clear stale buildStatus when PRs are merged or abandoned
+
 ## 0.1.334 (2026-04-03)
 
 ### Features

package/engine/ado.js

@@ -146,6 +146,12 @@ async function pollPrStatus(config) {
           pr.reviewStatus = newStatus === PR_STATUS.MERGED ? 'approved' : 'pending';
           log('info', `PR ${pr.id} reviewStatus: waiting → ${pr.reviewStatus} (${newStatus})`);
         }
+        // Clear stale build status — checks won't be polled after close
+        if (pr.buildStatus && pr.buildStatus !== 'none') {
+          delete pr.buildStatus;
+          delete pr.buildFailReason;
+          delete pr._buildFailNotified;
+        }
         await engine().handlePostMerge(pr, project, config, newStatus);
       }
     }

package/engine/github.js

@@ -152,6 +152,12 @@ async function pollPrStatus(config) {
           pr.reviewStatus = newStatus === PR_STATUS.MERGED ? 'approved' : 'pending';
           log('info', `PR ${pr.id} reviewStatus: waiting → ${pr.reviewStatus} (${newStatus})`);
         }
+        // Clear stale build status — checks won't be polled after close
+        if (pr.buildStatus && pr.buildStatus !== 'none') {
+          delete pr.buildStatus;
+          delete pr.buildFailReason;
+          delete pr._buildFailNotified;
+        }
         await engine().handlePostMerge(pr, project, config, newStatus);
       }
     }

package/engine/playbook.js

@@ -293,6 +293,14 @@ function renderPlaybook(type, vars) {
     log('warn', `Playbook "${type}": substituted values contain unresolved {{...}} patterns (potential self-reference): ${selfRefVars.join(', ')}`);
   }
 
+  // Warn when a substituted value itself contains {{...}} patterns (potential self-reference)
+  const selfRefVars = Object.entries(allVars)
+    .filter(([, val]) => /\{\{\w+\}\}/.test(String(val)))
+    .map(([key]) => key);
+  if (selfRefVars.length > 0) {
+    log('warn', `Playbook "${type}": substituted values contain unresolved {{...}} patterns (potential self-reference): ${selfRefVars.join(', ')}`);
+  }
+
   // Warn on variables that resolved to empty string
   const emptyVars = Object.entries(allVars)
     .filter(([, val]) => String(val) === '')

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@yemi33/minions",
-  "version": "0.1.334",
+  "version": "0.1.335",
   "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/build-and-test.md

@@ -102,7 +102,7 @@ Structure your report exactly like this:
 
 ## Auto-file Work Items on Failure
 
-If the build OR tests fail, you MUST create a work item so another agent can fix it. Write a JSON entry to the project's work queue:
+If the build or tests fail, create a work item so another agent can fix it. Write a JSON entry to the project's work queue:
 
 ```bash
 # Read existing items, append new one, write back

package/playbooks/implement-shared.md

@@ -17,7 +17,7 @@ Implement PRD item **{{item_id}}: {{item_name}}**
 
 This is part of a **shared-branch plan**. Other agents may have already committed work to this branch before you. Your job is to build on top of their work.
 
-## Git Workflow (SHARED BRANCH — CRITICAL)
+## Git Workflow (Shared Branch)
 
 Your worktree is already set up. Pull latest before starting:
 
@@ -54,7 +54,7 @@ git push origin {{branch_name}}
 
 ## Build and Verify
 
-After implementation, you MUST:
+After implementation:
 1. Build the project using the repo's build system (check CLAUDE.md, package.json, README)
 2. Verify the build succeeds with your changes AND all prior commits on this branch
 3. If the build fails:

package/playbooks/implement.md

@@ -58,7 +58,7 @@ Do NOT remove the worktree — the engine handles cleanup automatically.
 
 ## Build and Demo Rule
 
-After implementation, you MUST:
+After implementation:
 1. Build the project using the repo's build system (check CLAUDE.md, package.json, README)
 2. Start if applicable
 3. Include the browser URL and run instructions in the PR description
@@ -71,7 +71,7 @@ After building, verify the build succeeded. If the build fails:
 
 ## Test Validation (MANDATORY before PR)
 
-Before creating a PR, you MUST run the project's test suite and ensure all existing tests pass:
+Before creating a PR, run the project's test suite and ensure all existing tests pass:
 
 1. Find the test command by reading the project's own documentation — check CLAUDE.md, agent.md, README, or package.json scripts in the project root. Every project defines its own conventions.
 2. Run the full test suite using whatever command the project specifies

package/playbooks/plan-to-prd.md

@@ -18,7 +18,7 @@ A user has provided a plan. Analyze it against the codebase and produce a struct
 3. **Break the plan into discrete, implementable items** — each should be a single PR's worth of work
 4. **Estimate complexity** — `small` (< 1 file), `medium` (2-5 files), `large` (6+ files or cross-cutting)
 5. **Order by dependency** — items that others depend on come first
-6. **Use unique item IDs** — generate a short uuid for each item (e.g. `P-a3f9b2c1`). NEVER use sequential `P001`/`P002` — IDs must be globally unique across all PRDs to avoid collisions
+6. **Use unique item IDs** — generate a short uuid for each item (e.g. `P-a3f9b2c1`). Do not use sequential `P001`/`P002` — IDs must be globally unique across all PRDs to avoid collisions
 7. **Identify open questions** — flag anything ambiguous in the plan that needs user input
 
 ## Output
@@ -83,7 +83,7 @@ When using `parallel`:
 
 Rules for items:
 - IDs must be `P-<uuid>` format (e.g. `P-a3f9b2c1`) — globally unique, never sequential
-- **`status` MUST always be `"missing"` — no exceptions.** Do NOT set `done`, `complete`, `implemented`, or any other value, even if you observe active PRs or completed work in the codebase. Status is exclusively engine-managed after the PRD is written. Pre-setting any other status causes items to be silently skipped by the engine and breaks dependency resolution for all downstream items.
+- **`status` is always `"missing"`** — do not set `done`, `complete`, `implemented`, or any other value, even if you observe active PRs or completed work in the codebase. Status is exclusively engine-managed after the PRD is written. Pre-setting any other status causes items to be silently skipped by the engine and breaks dependency resolution for all downstream items.
 - **`project` field is REQUIRED** — set it to the project name where the code changes go (e.g., `"OfficeAgent"`, `"office-bohemia"`). Cross-repo plans must route each item to the correct project. The engine materializes items into that project's work queue.
 - `depends_on` lists IDs of items that must be done first
 - Keep descriptions actionable — an implementing agent should know exactly what to build

package/playbooks/review.md

@@ -38,7 +38,7 @@ Branch: `{{pr_branch}}`
 
 ## Post Review — Comment AND Vote on PR
 
-You MUST do both of the following:
+Do both of the following:
 
 ### Step 1: Leave a detailed review comment
 
@@ -61,7 +61,7 @@ This vote is visible to human reviewers in the PR UI and helps them understand t
 If you encounter merge conflicts (e.g., the PR shows conflicts):
 1. Note the conflict in your review comment. Do NOT attempt to resolve — flag it for the author.
 
-## CRITICAL: Do NOT run git checkout on the main working tree. Use `git diff` and `git show` only.
+## Do not run git checkout on the main working tree. Use `git diff` and `git show` only.
 
 ## Signal Completion
 

package/playbooks/test.md

@@ -37,7 +37,7 @@ This is a **test/build/run task**. Your goal is to build, run, test, or verify s
 
 ## Run Command (IMPORTANT)
 
-When the build succeeds and the task involves running a server or app, you MUST output a ready-to-paste run command using **absolute paths** so the user can launch it from any terminal. Format it exactly like this:
+When the build succeeds and the task involves running a server or app, output a ready-to-paste run command using **absolute paths** so the user can launch it from any terminal. Format it exactly like this:
 
 ```
 ## Run Command

package/playbooks/verify.md

@@ -218,7 +218,7 @@ For each project worktree:
 - If a project doesn't build, still document what SHOULD be testable once fixed
 - Do NOT fix code — only report issues
 - Leave all worktrees in place for the user to inspect
-- The application MUST be started **detached** so it keeps running after your process exits
+- Start the application **detached** so it keeps running after your process exits
 - Use absolute paths everywhere so the user can copy-paste commands
 - E2E PRs are for review only — do NOT auto-complete or merge them
 

package/playbooks/work-item.md

@@ -53,7 +53,7 @@ Write your findings to: `{{team_root}}/notes/inbox/{{agent_id}}-{{item_id}}-{{da
 **Note:** Do NOT write to `agents/*/status.json` — the engine manages your status automatically.
 
 ## Rules
-- NEVER checkout branches in the main working tree — use worktrees
+- Do not checkout branches in the main working tree — use worktrees
 - Use the repo host's MCP tools for PR creation — check available MCP tools before starting
 - Use PowerShell for build commands on Windows if applicable
 - If you discover a repeatable workflow, output it as a ```skill block (the engine auto-extracts it to ~/.claude/skills/)