@yemi33/minions 0.1.1862 → 0.1.1863

package/CHANGELOG.md

@@ -1,5 +1,10 @@
 # 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

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@yemi33/minions",
-  "version": "0.1.1862",
+  "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,36 +74,48 @@ 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.
 
-## Test Invocation — direct binary, not `.cmd` shims
-
-When running tests via the shell/PowerShell tool, invoke the underlying
-runner binary **directly** instead of going through a package-manager
-wrapper. The runtime CLIs (Copilot CLI, Claude Code CLI) deterministically
-crash on Windows when invoking `.cmd` shims (`npm`, `yarn`, `pnpm`, `npx`,
-`mocha`, `jest`, `vitest`) for substantial test commands inside a real
-agent-prompt session (confirmed 2026-05-11 by controlled reproduction).
-The crash signature: silent exit with OS code 1, no result event, no error
-message — the engine surfaces it as "phantom completion."
-
-For test verification, prefer:
-
-- ❌ `npm test`, `yarn test`, `pnpm test`, `npx vitest`, `npx jest`, `npx mocha`
-- ✅ `node test/<file>.test.js` (Node projects with custom runners)
-- ✅ `node node_modules/<runner>/bin/<runner>.js <args>` (resolve the runner manually)
-- ✅ `python -m pytest tests/test_foo.py` (Python — `.exe`, not `.cmd`)
-- ✅ `cargo test --test foo` (Rust)
-- ✅ `dotnet test path/to/Project.Tests.csproj` (.NET)
-- ✅ `go test ./...` (Go)
-
-To map a package-manager wrapper to its direct invocation, check the
-project's `package.json` `scripts` section (Node), `pyproject.toml` (Python),
-`Cargo.toml` (Rust), or the project's CLAUDE.md / README. Direct invocations
-are also significantly faster (no shim overhead).
-
-If the project's test setup *requires* the wrapper (e.g., it sets env vars
-or installs dependencies in a hook), report this in your completion block
-and use targeted node invocations for verification anyway — the wrapper
-crashes the agent before the test results land.
+## 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