@yemi33/minions 0.1.1863 → 0.1.1864

package/CHANGELOG.md

@@ -1,5 +1,10 @@
 # Changelog
 
+## 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.1864",
   "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.