@yemi33/minions 0.1.1863 → 0.1.1865

package/CHANGELOG.md

@@ -1,5 +1,15 @@
 # Changelog
 
+## 0.1.1865 (2026-05-11)
+
+### Fixes
+- put hard-stop rule at top of shared-rules.md so agents can't miss it
+
+## 0.1.1864 (2026-05-11)
+
+### Fixes
+- apply targeted-only-test rule to fix/implement-shared/docs playbooks
+
 ## 0.1.1863 (2026-05-11)
 
 ### Fixes

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@yemi33/minions",
-  "version": "0.1.1863",
+  "version": "0.1.1865",
   "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,8 +63,7 @@ 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. Otherwise run `npm test` (or the project's documented test command) to make
-  sure nothing else broke.
+  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.
 - 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,15 +57,17 @@ 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
+## Validation — TARGETED ONLY, before publish
 
-Before pushing, prove the review fix did not break the branch:
+Prove the review fix did not break the branch, BUT keep verification narrow:
 
 - Use the project's source of truth for commands: `CLAUDE.md`, README, package scripts, Makefile, or equivalent build config.
-- 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.
+- **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.
 - 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.
+- Do not push code that breaks existing tests or the build because of your changes; 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.
 

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 checks that are relevant to this item and to the integrated branch state. Prefer the full suite when practical.
+- **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.
 - 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/shared-rules.md

@@ -1,3 +1,35 @@
+## ⚠️ 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.