enigma-cli 1.13.0 → 1.13.2

package/assets/memory/AGENTS.md

@@ -14,7 +14,7 @@
 - backend-policy, frontend-policy, database-expert, validation-policy: server, client, persistence, and input-validation work.
 - security-policy: secrets, auth, permissions, crypto, untrusted/tool output, and AI-agent/MCP/tool-use safety.
 - dependency-policy: adding/upgrading/auditing dependencies, lockfiles, and supply-chain risk.
-- testing-policy, code-review-policy, debugging-policy, git-policy: tests, pre-delivery review, debugging, and commits/PRs.
+- testing-policy, test-organization-policy, code-review-policy, debugging-policy, git-policy: tests, test-suite layout (structured subfolders, never a flat tests/ dump), pre-delivery review, debugging, and commits/PRs.
 - task-completion-policy: long or multi-item tasks (1:1 ports, migrations, repo-wide changes) - work-unit inventory, persistent coverage ledger, and verified completion before any "done" claim.
 
 ### Always-On Rules (never skipped, even if no skill loads)
@@ -32,6 +32,7 @@
 - Map the dependencies between subtasks before starting, and do only the decomposition the task genuinely needs - never over-decompose simple work.
 - For multi-item work (ports, migrations, batch changes), enumerate the FULL inventory of work units with deterministic commands before implementing, persist it as a checklist (file or todo system), and mark a unit done only after verifying it - never because a similar unit worked.
 - Never declare a task complete while any unit is pending, stubbed, or unverified. Before saying "done": reconcile counts against the inventory, build/typecheck the whole artifact, and grep for TODO/stub markers you introduced. If anything remains, say exactly what remains instead of rounding up to "done". Never silently skip or stub an item - record it with a reason and report it.
+- Never offload doable work to the user: "you can adjust/refresh X yourself" in a final report is a hidden deferral. If you can execute the action, do it before reporting; hand off only what genuinely requires the user (credentials, irreversible/destructive choices, business decisions) or what they explicitly approved deferring.
 
 <!-- enigma:parallel-subagents:start -->
 - When subtasks are genuinely independent and your runtime can spawn sub-agents (parallel task or sub-agent tools), delegate them to sub-agents that run in parallel to finish faster, then reconcile their results into a coherent whole. If the runtime has no sub-agent support, execute the subtasks sequentially.

package/assets/memory/CLAUDE.md

@@ -14,7 +14,7 @@
 - backend-policy, frontend-policy, database-expert, validation-policy: server, client, persistence, and input-validation work.
 - security-policy: secrets, auth, permissions, crypto, untrusted/tool output, and AI-agent/MCP/tool-use safety.
 - dependency-policy: adding/upgrading/auditing dependencies, lockfiles, and supply-chain risk.
-- testing-policy, code-review-policy, debugging-policy, git-policy: tests, pre-delivery review, debugging, and commits/PRs.
+- testing-policy, test-organization-policy, code-review-policy, debugging-policy, git-policy: tests, test-suite layout (structured subfolders, never a flat tests/ dump), pre-delivery review, debugging, and commits/PRs.
 - task-completion-policy: long or multi-item tasks (1:1 ports, migrations, repo-wide changes) - work-unit inventory, persistent coverage ledger, and verified completion before any "done" claim.
 
 ### Always-On Rules (never skipped, even if no skill loads)
@@ -32,6 +32,7 @@
 - Map the dependencies between subtasks before starting, and do only the decomposition the task genuinely needs - never over-decompose simple work.
 - For multi-item work (ports, migrations, batch changes), enumerate the FULL inventory of work units with deterministic commands before implementing, persist it as a checklist (file or todo system), and mark a unit done only after verifying it - never because a similar unit worked.
 - Never declare a task complete while any unit is pending, stubbed, or unverified. Before saying "done": reconcile counts against the inventory, build/typecheck the whole artifact, and grep for TODO/stub markers you introduced. If anything remains, say exactly what remains instead of rounding up to "done". Never silently skip or stub an item - record it with a reason and report it.
+- Never offload doable work to the user: "you can adjust/refresh X yourself" in a final report is a hidden deferral. If you can execute the action, do it before reporting; hand off only what genuinely requires the user (credentials, irreversible/destructive choices, business decisions) or what they explicitly approved deferring.
 
 <!-- enigma:parallel-subagents:start -->
 - When subtasks are genuinely independent and your runtime can spawn sub-agents (parallel task or sub-agent tools), delegate them to sub-agents that run in parallel to finish faster, then reconcile their results into a coherent whole. If the runtime has no sub-agent support, execute the subtasks sequentially.

package/assets/skills/backend-policy/skill.json

@@ -3,6 +3,6 @@
   "version": "1.0.0",
   "provider": "FJRG2007/enigma",
   "description": "Backend/API architecture: controller-service-repository layering, API and request optimization, server-side caching (Redis), and Zod boundary validation.",
-  "cliVersion": "1.13.0",
+  "cliVersion": "1.13.2",
   "sha": "c442bc9e39a7710cb709ef2abb8d15ecd8aa16ed4f5c8af92b7af6877401cba4"
 }

package/assets/skills/ciphera-style-policy/skill.json

@@ -3,6 +3,6 @@
   "version": "1.1.1",
   "provider": "FJRG2007/enigma",
   "description": "Ciphera code style conventions (formatting, naming, imports, comments, code-level anti-patterns; TypeScript-first, language-agnostic).",
-  "cliVersion": "1.13.0",
+  "cliVersion": "1.13.2",
   "sha": "74f638aec13e8c93257fe1ad604c28b07e9a7c456796a4ceefcc99217d9e7039"
 }

package/assets/skills/code-review-policy/skill.json

@@ -3,6 +3,6 @@
   "version": "1.0.0",
   "provider": "FJRG2007/enigma",
   "description": "Pre-delivery self-review gate, prioritized review dimensions, and change-quality criteria.",
-  "cliVersion": "1.13.0",
+  "cliVersion": "1.13.2",
   "sha": "3d3bbe0602d5bbb4afe37648fe3c2fa39376b1bcbac5d8c441f01fad1e866ed0"
 }

package/assets/skills/core-engineering-policy/SKILL.md

@@ -34,6 +34,7 @@ description: Highest-authority engineering rules - priority hierarchy, modular a
   - Any UI, client state, data fetching, or client caching -> frontend-policy.
   - Any API endpoint, service, controller, or server request flow -> backend-policy.
   - Any new or changed code that needs verification -> testing-policy.
+  - Any test file created, moved, or renamed, or a test suite scaffolded/restructured -> test-organization-policy.
   - Any source code written, refactored, or reviewed (formatting, naming, language idioms) -> ciphera-style-policy.
   - Before declaring a change done, or when reviewing a diff/PR -> code-review-policy.
   - Any bug, crash, failing test, or unexpected behavior -> debugging-policy.
@@ -80,6 +81,7 @@ This core policy owns orchestration, architecture, and the global rules. Each co
 - frontend-policy: frontend structure, reusable components, abstraction threshold, client-side caching, optimistic UI and rollback.
 - backend-policy: API/service architecture, controller-service-repository layering, API/request optimization, server-side caching (Redis).
 - testing-policy: test strategy, coverage gates, deterministic tests, test/regression-first discipline.
+- test-organization-policy: test-suite layout - structure by test type and domain, mirrored source paths, file naming, fixture/helper/factory placement.
 - code-review-policy: self-review before delivery, review dimensions, change-quality gates.
 - debugging-policy: reproduce-isolate-fix methodology and root-cause discipline.
 - git-policy: commits, branches, and pull request standards.

package/assets/skills/core-engineering-policy/skill.json

@@ -1,8 +1,8 @@
 {
   "name": "core-engineering-policy",
-  "version": "1.5.0",
+  "version": "1.6.0",
   "provider": "FJRG2007/enigma",
   "description": "Core engineering execution policy and harness orchestration (highest-authority rules).",
-  "cliVersion": "1.13.0",
-  "sha": "e4e8be13e5923cb2d1f57e1bad6e78f54b02611e834e16af165c18c5478d9453"
+  "cliVersion": "1.13.2",
+  "sha": "b44681bc21675fff949a2d9e1a67617bc7638dc5acec6270906f3ca0a9052a86"
 }

package/assets/skills/database-expert/skill.json

@@ -3,6 +3,6 @@
   "version": "1.1.0",
   "provider": "FJRG2007/enigma",
   "description": "Senior database architecture policy: query optimization, anti-duplication/normalization, scalability, and RGPD/GDPR encryption.",
-  "cliVersion": "1.13.0",
+  "cliVersion": "1.13.2",
   "sha": "2883bcecb3202683ae6f81b073c3d6a9cec9c55029e011bdd06ba7ac3537297e"
 }

package/assets/skills/debugging-policy/skill.json

@@ -3,6 +3,6 @@
   "version": "1.0.0",
   "provider": "FJRG2007/enigma",
   "description": "Reproduce-isolate-fix debugging methodology with root-cause discipline and regression verification.",
-  "cliVersion": "1.13.0",
+  "cliVersion": "1.13.2",
   "sha": "14b0064c8b33a0dc85e51464b05005cf5801c756b1101789a6924b9548420f6b"
 }

package/assets/skills/dependency-policy/skill.json

@@ -3,6 +3,6 @@
   "version": "1.0.0",
   "provider": "FJRG2007/enigma",
   "description": "Dependency and supply-chain security: lockfiles and reproducible installs, version pinning, vulnerability auditing, vetting/minimizing packages, vendoring, and SBOM/provenance.",
-  "cliVersion": "1.13.0",
+  "cliVersion": "1.13.2",
   "sha": "6375d835c2aef2c9bd31ce116444dc3d796f510f9970a213aa3ac4696d7e21b9"
 }

package/assets/skills/frontend-policy/skill.json

@@ -3,6 +3,6 @@
   "version": "1.2.0",
   "provider": "FJRG2007/enigma",
   "description": "Frontend architecture: reusable components, abstraction thresholds, state management, no-op save detection, and optimistic UI with rollback.",
-  "cliVersion": "1.13.0",
+  "cliVersion": "1.13.2",
   "sha": "3766096616a9177ce66685bfaaaef66f7e8ceb62e2a6542e83dee713b9d1b56f"
 }

package/assets/skills/git-policy/skill.json

@@ -3,6 +3,6 @@
   "version": "1.3.0",
   "provider": "FJRG2007/enigma",
   "description": "Git & contribution policy (senior engineering standards).",
-  "cliVersion": "1.13.0",
+  "cliVersion": "1.13.2",
   "sha": "73a978ef11f4def067f9252fc3e2e6aa737a08b6d58ad8a2a45cbcd4b02813f6"
 }

package/assets/skills/security-policy/skill.json

@@ -3,6 +3,6 @@
   "version": "1.0.0",
   "provider": "FJRG2007/enigma",
   "description": "Application and AI-agent security: secrets, authn/authz (least privilege), OWASP Top 10, transport/crypto baseline, secure logging, and agent/MCP/tool-use safety.",
-  "cliVersion": "1.13.0",
+  "cliVersion": "1.13.2",
   "sha": "9971e9d9127397d0152e89d24aad3191e2935e55a8483db7fd15f5d4d7a60e7a"
 }

package/assets/skills/task-completion-policy/SKILL.md

@@ -58,6 +58,7 @@ A completion claim is forbidden unless ALL of these hold:
 
 - The final report must state: total units, done, deferred (with approval), and the verification evidence (commands run and their results).
 - Anything that could not be verified is reported as unverified. Never upgrade unverified to done.
+- Never offload doable work to the user. "You can adjust X yourself", "refresh the lockfile if you prefer", "wire the remaining seam when needed" in a final report are deferrals in disguise: if the agent can execute the action (edit the pin, refresh the freeze, run the migration, wire the seam), it does so BEFORE reporting. Hand work to the user only when it genuinely requires them - credentials or access the agent lacks, irreversible or destructive choices, or business decisions - or when the user explicitly approved deferring it.
 
 ---
 

package/assets/skills/task-completion-policy/skill.json

@@ -1,8 +1,8 @@
 {
   "name": "task-completion-policy",
-  "version": "1.0.0",
+  "version": "1.1.0",
   "provider": "FJRG2007/enigma",
   "description": "Exhaustive completion discipline for long/multi-item tasks - inventory, coverage ledger, verified done.",
-  "cliVersion": "1.13.0",
-  "sha": "37f475a60a4004d291f2682a7e9c1636a5271354678697b5ca22e8afdb760b88"
+  "cliVersion": "1.13.2",
+  "sha": "6e3facba307eb2b55cefbab2e4b2a346a2b82f93c3ef47e11ebeb78c3c9453a8"
 }

package/assets/skills/test-organization-policy/SKILL.md

@@ -0,0 +1,88 @@
+---
+name: test-organization-policy
+description: Expert test-suite organization - directory structure by test type and domain, mirrored source paths, file naming conventions, and fixture/helper/factory placement. Use when creating, moving, or renaming test files, scaffolding or restructuring a test suite, or deciding where a new test lives - never dump tests flat into a single tests/ folder.
+---
+
+# Test Organization Policy (Senior Engineering Standards)
+
+## Activation Scope
+
+- Apply whenever a test file is created, moved, or renamed, and whenever a test suite is scaffolded or restructured.
+- Owns test-suite layout: directory structure, subfolders, file naming, and placement of fixtures, helpers, factories, and mocks.
+- Test strategy, coverage, determinism, and mocking discipline live in testing-policy; compose with it, never restate it.
+
+---
+
+## Core Principle
+
+- A test suite is navigable code: anyone must find the tests for a module in seconds from the module's path alone, and find the module from its test's path.
+- Never dump test files flat into a single tests/ folder. Flat suites hide coverage gaps, cause name collisions, and stop scaling past a handful of files.
+- Organize from the first test file. Structure is cheapest at file creation and most expensive after the folder is a mess.
+
+---
+
+## Framework Convention First
+
+- Every ecosystem has an established convention; it beats any custom layout:
+  - JS/TS (Vitest, Jest, Bun): colocated `*.test.ts` next to the source file, a `__tests__/` folder per directory, or a mirrored `tests/` tree - follow whichever the repo already uses.
+  - Python (pytest): a `tests/` package mirroring the source package; shared fixtures in `conftest.py` at the narrowest directory that covers their users.
+  - Go: `_test.go` colocated in the same package (mandated by the toolchain); black-box tests use the `_test` package suffix.
+  - Rust: unit tests in `#[cfg(test)] mod tests` inside the module; integration tests as separate files under the crate-root `tests/`.
+  - Java/Kotlin: `src/test/<lang>/` mirroring the `src/main/<lang>/` package path exactly.
+- In an existing repo, detect the established layout and extend it; never introduce a second competing layout. Migrations to a better layout are proposed explicitly, not done by stealth.
+
+---
+
+## Structure by Test Type, Then by Domain
+
+- When more than one test type exists, separate types at the top level - they differ in speed, dependencies, and CI stage:
+
+  ```text
+  tests/
+    unit/          fast, isolated, no I/O
+    integration/   module boundaries, DB, contracts
+    e2e/           critical user flows only
+    fixtures/      shared static data
+    helpers/       shared builders, factories, fakes
+  ```
+
+- Inside each type, mirror the source tree: tests for `src/<domain>/<module>` live at `tests/<type>/<domain>/<module>.<suffix>`.
+- Group e2e tests by user flow (e.g. `e2e/checkout/`), not by source module - flows cross modules.
+- Default to one test file per module under test; split a large file by scenario, never by arbitrary size cuts.
+- Keep the test runner's discovery config (`testMatch`, `testpaths`, includes) in sync with the layout; a test the runner cannot find is dead code.
+
+---
+
+## Naming Conventions
+
+- Test file name = module under test + the framework's suffix: `parser.test.ts`, `test_parser.py`, `parser_test.go`.
+- When splitting by scenario, encode the scenario in the name: `parser.errors.test.ts`, `auth.session-expiry.test.ts`.
+- Suite and case names describe behavior, not implementation (naming-by-behavior rules live in testing-policy).
+- Forbidden names: `test1`, `misc`, `temp`, `new`, `utils-tests`, or any name that does not identify what is verified.
+
+---
+
+## Shared Test Code Placement
+
+- Fixtures (static data), factories/builders (object construction), helpers (setup/assertion logic), and fakes each get their own folder; do not mix them in one grab-bag file.
+- Place shared test code at the narrowest scope that covers its users; promote it upward only when a second consumer appears (same reuse rule as production code).
+- Test helpers are production code: deduplicate, name well, and review them like any other module.
+- Never import from another test file; extract the shared piece into a helper module instead.
+- Large fixtures live as data files under `fixtures/`, named after the scenario they encode, not inlined into test bodies.
+
+---
+
+## Scaling & Maintenance
+
+- When adding a test to an existing flat or misplaced suite: place the new test correctly and surface the layout debt; do not extend the mess to match it.
+- Layout migrations are pure moves: never change test logic in the same commit as a file move (atomic-commit rule in git-policy).
+- After any move, run the affected suite to prove discovery still works, and delete emptied folders.
+- If two layouts coexist after a partial migration, finish the migration or document the boundary; a half-migrated suite is worse than either layout.
+
+---
+
+## Decision Rule: Colocated vs Centralized
+
+- Colocated tests (next to source) fit unit tests in ecosystems that idiomatically support it (JS/TS, Go, Rust) - shortest navigation distance, moves with the code.
+- A centralized `tests/` tree fits integration/e2e tests, packages that must exclude tests from the published artifact, and ecosystems whose tooling expects it (Python, Java).
+- Mixing is fine when each side follows its rule (e.g. colocated unit + centralized integration); mixing within the same test type is not.

package/assets/skills/test-organization-policy/skill.json

@@ -0,0 +1,8 @@
+{
+  "name": "test-organization-policy",
+  "version": "1.0.0",
+  "provider": "FJRG2007/enigma",
+  "description": "Expert test-suite organization: structure by test type and domain, mirrored source paths, naming conventions, and fixture/helper placement.",
+  "cliVersion": "1.13.2",
+  "sha": "09184beb8e423efd26fce0221cd374d41b6ba0bb3d223d7edce250d9d978767e"
+}

package/assets/skills/testing-policy/SKILL.md

@@ -9,6 +9,7 @@ description: Test strategy (test pyramid), coverage gates, deterministic tests,
 
 - Apply whenever code is written, changed, or fixed, and whenever the user asks for tests.
 - Owns test strategy, coverage expectations, determinism, and test-first discipline.
+- Test file placement, suite layout, naming of test files, and fixture/helper organization live in test-organization-policy; apply it alongside this skill when creating or moving test files.
 
 ---
 

package/assets/skills/testing-policy/skill.json

@@ -1,8 +1,8 @@
 {
   "name": "testing-policy",
-  "version": "1.0.0",
+  "version": "1.1.0",
   "provider": "FJRG2007/enigma",
   "description": "Test strategy, coverage gates, deterministic tests, mocking discipline, and regression-first bug fixing.",
-  "cliVersion": "1.13.0",
-  "sha": "d19fa8ec7985ed231478be504d3c80360897f555d0bc0624bea19c091f459fb0"
+  "cliVersion": "1.13.2",
+  "sha": "dd5c0bb67aba7f31b2f520e626a9df512b5ad2d2e7baf5567fe64d9e28a437db"
 }

package/assets/skills/validation-policy/skill.json

@@ -3,6 +3,6 @@
   "version": "1.0.0",
   "provider": "FJRG2007/enigma",
   "description": "Strict frontend + backend schema validation, schema consistency, and safe client-facing error handling.",
-  "cliVersion": "1.13.0",
+  "cliVersion": "1.13.2",
   "sha": "a33622a2f810ee4cea39824cb1a7ca34b355a917d4224025df50d77dd74f0b3a"
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "enigma-cli",
-  "version": "1.13.0",
+  "version": "1.13.2",
   "description": "Everything you need to work with a coding agent: install shared policy skills for Claude Code, OpenAI Codex and opencode, and set up portable git security hooks.",
   "type": "module",
   "bin": {