@yemi33/minions 0.1.1868 → 0.1.1869

package/CHANGELOG.md

@@ -1,5 +1,10 @@
 # Changelog
 
+## 0.1.1869 (2026-05-11)
+
+### Other
+- revert(playbooks): drop incorrect .cmd-shim crash theory
+
 ## 0.1.1868 (2026-05-11)
 
 ### Other

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@yemi33/minions",
-  "version": "0.1.1868",
+  "version": "0.1.1869",
   "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/docs.md

@@ -63,7 +63,8 @@ If the doc describes vapor, delete the section. If real features are missing, ad
 
 - Re-read the changed doc end-to-end after editing — does it still flow?
 - If the project has doc-validation tests (lint, link-check, snippet-execution), run
-  them. **Use direct binary invocations** (`node test/<file>.test.js`, `python -m pytest`, etc.) — do NOT use package-manager wrappers (`npm test`, `yarn test`) and do NOT run the full-project suite. See shared-rules.md's CRITICAL RULE on test invocation.
+  them. Otherwise run `npm test` (or the project's documented test command) to make
+  sure nothing else broke.
 - For docs with embedded code samples, mentally execute each sample against current
   code — stale samples are worse than missing ones.
 

package/playbooks/fix.md

@@ -57,17 +57,15 @@ Handle this like the PR author responding directly from a CLI:
 - Handle merge conflicts when needed, preserving the PR's intended changes while keeping the branch reviewable.
 - Do not add unrelated cleanups or broaden the PR beyond the review feedback unless that is necessary to make the fix correct.
 
-## Validation — TARGETED ONLY, before publish
+## Validation
 
-Prove the review fix did not break the branch, BUT keep verification narrow:
+Before pushing, prove the review fix did not break the branch:
 
 - Use the project's source of truth for commands: `CLAUDE.md`, README, package scripts, Makefile, or equivalent build config.
-- **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 comment and completion report.
+- Run checks that are relevant to the addressed findings. Prefer the full suite when practical.
+- Capture the exact commands run and meaningful results in the PR comment and completion report.
 - Fix regressions you introduced. If failures are pre-existing or unrelated, capture the evidence and include it in the PR comment.
-- Do not push code that breaks existing tests or the build because of your changes; if your targeted check fails, fix it before pushing.
+- Do not push code that breaks existing tests or the build because of your changes.
 
 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.
 

package/playbooks/implement-shared.md

@@ -62,7 +62,7 @@ Deliver this as if the user asked you directly in a CLI, with the added constrai
 Before publishing, prove the shared branch still works with your change included:
 
 - Use the project's source of truth for commands: `CLAUDE.md`, README, package scripts, Makefile, or equivalent build config.
-- **Run only TARGETED tests covering the code you changed.** 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 deterministically crashes the runtime CLI (see shared-rules.md). Use single test files or test names instead. The engine and PR CI handle full-suite regression detection.
+- Run checks that are relevant to this item and to the integrated branch state. Prefer the full suite when practical.
 - Fix regressions you introduced. If failures are pre-existing or caused by earlier branch work, capture the evidence and say so clearly.
 - Do not push code with a broken build or failing tests that you introduced.
 

package/playbooks/implement.md

@@ -59,23 +59,21 @@ 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 — TARGETED ONLY, before publish
+## Validation
 
-Prove the change with the repo's own documented checks, BUT keep the
-verification surface narrow:
+Before publishing, prove the change with the repo's own documented checks:
 
 - Use the project's source of truth for commands: `CLAUDE.md`, README, package scripts, Makefile, or equivalent build config.
-- **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.
+- 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.
 
 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 — push EARLY, before any expansion of verification scope
+## Publish
 
-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.
+After the change is validated or any unavoidable limitation is clearly documented, commit only the relevant files and push this branch:
 
 ```bash
 git add <specific files>

package/playbooks/shared-rules.md

@@ -1,35 +1,3 @@
-## ⚠️ HARD STOP — read this first
-
-**You will silently crash the runtime CLI (Copilot or Claude Code) on
-Windows if you run a full-project test suite from your shell tool.**
-This is a deterministic native-level fault — no error message, no result
-event, just exit code 1. Your work is lost (worktree wiped) and the WI
-hard-fails. Repro confirmed 2026-05-11 across both runtimes, multiple
-attempts, with full memory dumps.
-
-**Forbidden** — never run these as agent shell commands:
-
-- `npm test`, `npm run <anything>`, `yarn test`, `yarn <script>`, `pnpm test`, `pnpm <script>`, `npx mocha`, `npx jest`, `npx vitest`
-- `node test/unit.test.js` (this repo's full unit suite)
-- ANY command that invokes the project's "run all tests" path
-
-**Allowed** — single-file or single-test invocations:
-
-- `node test/unit/<one-file>.test.js`
-- `node node_modules/<runner>/bin/<runner>.js <one-file>`
-- `python -m pytest tests/test_one_file.py`
-- `cargo test --test one_test`
-- `dotnet test path/to/Project.Tests.csproj --filter "FullyQualifiedName~OneTest"`
-
-**Rules that follow from this:**
-
-1. Run only targeted tests for the code YOU changed. The engine and PR CI handle full-suite regression detection — that is not your job.
-2. If your targeted test fails, fix the code and re-run *the targeted test*. Never expand to the full suite as a sanity check.
-3. Push the branch and open the PR as early as possible — before any final verification you might be tempted to run. If you do crash on a later command, the work survives on the remote and the engine can auto-link.
-4. This rule overrides any contradictory guidance in playbooks or task descriptions. If a playbook section says "prefer the full suite", that section is outdated — ignore it and use targeted tests.
-
-If a project genuinely requires the wrapper (env vars in a hook, etc.), use the closest direct equivalent anyway and note the deviation in your completion block. Verification you don't get because you crashed is worse than verification you skipped deliberately.
-
 ## Operating Principle
 
 Treat a Minions assignment like the user typed the same task directly into a capable CLI agent. Optimize for the requested outcome and use the repo's own tools, conventions, and acceptance criteria.
@@ -106,49 +74,6 @@ 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.