@yemi33/minions 0.1.1861 → 0.1.1863

package/CHANGELOG.md

@@ -1,5 +1,15 @@
 # Changelog
 
+## 0.1.1863 (2026-05-11)
+
+### Fixes
+- push early + targeted-only verify, fully avoid runtime CLI crash trigger
+
+## 0.1.1862 (2026-05-11)
+
+### Fixes
+- use 'exit' event for OS exit code + dedup sentinel; warn agents off .cmd shims
+
 ## 0.1.1861 (2026-05-10)
 
 ### Fixes

package/engine/spawn-agent.js

@@ -409,11 +409,38 @@ function main() {
   }, MCP_STARTUP_TIMEOUT);
   proc.stdout.once('data', () => { gotFirstOutput = true; clearTimeout(startupTimer); });
 
+  // Track the real OS exit code via the 'exit' event. Node's 'close' event
+  // can report code=0 on Windows when the OS-level exit was non-zero
+  // (observed empirically with both Claude Code CLI and Copilot CLI exiting
+  // with OS exit code 1 silently during long PowerShell tool calls — procdump
+  // captured the 1, but the engine's onAgentClose saw the spawn-agent's parent
+  // pipe report code=0). The 'exit' event fires earlier and carries the OS code
+  // more reliably; 'close' waits for stdio teardown which can race.
+  let realExitFromEvent = null;
+  let realSignalFromEvent = null;
+  let sentinelWritten = false;
+  proc.on('exit', (code, signal) => {
+    if (Number.isInteger(code)) realExitFromEvent = code;
+    if (signal) realSignalFromEvent = signal;
+  });
   proc.on('close', (code, signal) => {
     clearTimeout(startupTimer);
-    const exitCode = normalizeRuntimeExit(code, signal);
-    const sentinelResult = writeProcessExitSentinel({ exitCode, signal });
-    fs.appendFileSync(debugPath, `EXIT: code=${exitCode}${signal ? ` signal=${signal}` : ''}\nSTDERR: ${stderrBuf.slice(0, 500)}\n`);
+    // Prefer the 'exit' event's code/signal when present — see note above.
+    const effectiveCode = (realExitFromEvent != null) ? realExitFromEvent : code;
+    const effectiveSignal = realSignalFromEvent || signal;
+    const exitCode = normalizeRuntimeExit(effectiveCode, effectiveSignal);
+    if (sentinelWritten) {
+      // Defense-in-depth: never write a duplicate sentinel. We observed pairs
+      // of [process-exit] code=0 lines in live-output.log across many failed
+      // runs, which suggests close has fired twice in some edge cases (e.g.,
+      // shim re-launch on Windows). One sentinel per spawn is the contract.
+      fs.appendFileSync(debugPath, `EXIT (duplicate close, skipping sentinel): code=${exitCode}${effectiveSignal ? ` signal=${effectiveSignal}` : ''}\n`);
+      process.exit(exitCode);
+      return;
+    }
+    sentinelWritten = true;
+    const sentinelResult = writeProcessExitSentinel({ exitCode, signal: effectiveSignal });
+    fs.appendFileSync(debugPath, `EXIT: code=${exitCode}${effectiveSignal ? ` signal=${effectiveSignal}` : ''} (close=${code} exit=${realExitFromEvent})\nSTDERR: ${stderrBuf.slice(0, 500)}\n`);
     if (!sentinelResult.fileWritten) {
       fs.appendFileSync(debugPath, `EXIT SENTINEL: file write failed for ${process.env.MINIONS_LIVE_OUTPUT_PATH}\n`);
     }
@@ -421,7 +448,10 @@ function main() {
   });
   proc.on('error', (err) => {
     fs.appendFileSync(debugPath, `ERROR: ${err.message}\n`);
-    writeProcessExitSentinel({ exitCode: 1 });
+    if (!sentinelWritten) {
+      sentinelWritten = true;
+      writeProcessExitSentinel({ exitCode: 1 });
+    }
     process.exit(1);
   });
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@yemi33/minions",
-  "version": "0.1.1861",
+  "version": "0.1.1863",
   "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/implement.md

@@ -59,21 +59,23 @@ Deliver this as if the user asked you directly in a CLI:
 You are already running in a git worktree on branch `{{branch_name}}`. Do NOT create additional worktrees — the engine pre-created one for you.
 Do NOT remove the worktree — the engine handles cleanup automatically.
 
-## Validation
+## Validation — TARGETED ONLY, before publish
 
-Before publishing, prove the change with the repo's own documented checks:
+Prove the change with the repo's own documented checks, BUT keep the
+verification surface narrow:
 
 - Use the project's source of truth for commands: `CLAUDE.md`, README, package scripts, Makefile, or equivalent build config.
-- Run the checks that are relevant to this task, including tests that cover the changed behavior. Prefer the full suite when practical.
-- Capture the exact commands run and the meaningful result in the PR description or completion report. Do not summarize validation as "tests passed" without naming what ran.
-- Fix regressions you introduced. If failures are pre-existing or outside the task, capture the evidence and make that explicit in the PR.
-- Do not publish changes with a broken build or failing tests that you introduced.
+- **Run only TARGETED tests covering the code you changed.** A single test file or a single test name is enough. Examples: `node test/unit/<my-file>.test.js`, `python -m pytest tests/test_my_module.py::test_my_case`, `cargo test --test my_test`.
+- **Do NOT run the full project test suite (`node test/unit.test.js`, `npm test`, `yarn test`, etc.) as a verification step.** The full-suite run in a long agent session is the primary trigger for the runtime CLI crash documented in shared-rules.md. The engine and PR CI handle full-suite regression detection — your job is to verify the code you wrote works, not to re-prove the entire suite.
+- Use a quick `node --check <file>` (or equivalent) for syntax validation — cheap and never crashes.
+- Capture the exact targeted commands run and the meaningful result in the PR description or completion report.
+- Do not publish changes with a broken build or failing tests that you introduced; if your targeted check fails, fix it before pushing.
 
 Long builds, dependency installs, and tests may be quiet for several minutes. Let the normal CLI command run naturally; do not add artificial heartbeat output or split commands just to show progress.
 
-## Publish
+## Publish — push EARLY, before any expansion of verification scope
 
-After the change is validated or any unavoidable limitation is clearly documented, commit only the relevant files and push this branch:
+After targeted validation passes, commit only the relevant files and push this branch IMMEDIATELY. This protects the work product: a runtime CLI crash on any later command cannot lose code that's already on the remote.
 
 ```bash
 git add <specific files>

package/playbooks/shared-rules.md

@@ -74,6 +74,49 @@ Use `status: "failed"` plus an accurate `failure_class`, `retryable`, and `needs
 
 **No-op completions:** when you correctly decline to do the work — the change was already shipped on master, the dispatch premise is wrong, the flagged review comment is your own author-notes, etc. — write `status: "success"`, `pr: "N/A"`, AND add `"noop": true`. The engine treats `noop: true` as the canonical signal that no PR was expected, marks the work item done with the rationale surfaced in `_noopReason` for the dashboard, and skips the missing-PR-attachment failure. Without `noop: true`, an empty PR will still be flagged as a silent failure and auto-retried up to `maxRetries` times.
 
+## CRITICAL RULE: Never run `npm`/`yarn`/`pnpm` test scripts via the shell tool
+
+**You will crash silently if you run `npm test`, `npm run <anything>`, `yarn test`,
+`pnpm test`, `npx mocha`, `npx jest`, `npx vitest`, or any package-manager
+script wrapper from your shell/PowerShell tool.** The runtime CLI (whether
+Copilot CLI or Claude Code CLI) deterministically exits with OS code 1 mid-
+conversation when invoking a `.cmd` shim that spawns a child node process
+producing substantial stdout. This is confirmed by controlled reproductions
+on both runtimes (2026-05-11) — including with full memory dumps. You will
+NOT see an error message; the engine will mark your work as "phantom
+completion" and the WI will fail with no PR.
+
+This rule overrides any contradictory guidance you might find elsewhere
+(including playbook instructions to "run the full suite"). The playbook
+wants the test signal; it does NOT want you to crash trying to get it.
+Use direct binary invocations every time:
+
+| ❌ never | ✅ instead |
+| --- | --- |
+| `npm test` | `node test/unit.test.js` (or whatever the project's `test` script wraps) |
+| `npm run <script>` | The underlying command — check `package.json` `scripts.<script>` |
+| `yarn test`, `pnpm test` | Same — find the underlying `node ...` invocation |
+| `npx mocha tests/` | `node node_modules/mocha/bin/mocha.js tests/` |
+| `npx jest <file>` | `node node_modules/jest/bin/jest.js <file>` |
+| `npx vitest run` | `node node_modules/vitest/vitest.mjs run` |
+
+Non-`.cmd` test runners are safe (no shim chain):
+
+- `python -m pytest tests/test_foo.py`  ← Python uses `.exe`, not `.cmd`
+- `cargo test --test foo`  ← Rust cargo is `.exe`
+- `dotnet test path/to/Project.Tests.csproj`  ← .NET dotnet is `.exe`
+- `go test ./...`  ← Go is `.exe`
+
+**Targeted single-file tests are STRONGLY preferred over full-suite runs**
+regardless of how you invoke them. They're faster, smaller in output, and
+produce the same regression signal for the code you actually changed.
+
+If the project's test setup truly requires `npm test` (e.g., it sets env
+vars in a hook), report this in your completion block and use the closest
+direct equivalent anyway. Do not invoke the wrapper — verification you
+don't get because you crashed is worse than verification you skipped
+deliberately.
+
 ## Long-Running Commands
 
 Builds, dependency installs, tests, and local servers can be quiet for long periods. Run the repo's normal CLI commands and let them finish; do not add artificial progress output, heartbeat loops, or command-specific workarounds just to keep Minions active.