jorgex-stack 1.9.72 → 1.9.74

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "jorgex-stack",
-  "version": "1.9.72",
+  "version": "1.9.74",
   "description": "Harness multi-agente portable: instala la config JorgeX (agentes, skills, hooks, Engram, MCPs) en Claude Code, Codex CLI, OpenCode y Pi",
   "type": "module",
   "license": "MIT",
@@ -49,7 +49,8 @@
     "prepublishOnly": "pnpm typecheck && pnpm test && pnpm build"
   },
   "dependencies": {
-    "@clack/prompts": "^1.5.1"
+    "@clack/prompts": "^1.5.1",
+    "jsonc-parser": "3.3.1"
   },
   "devDependencies": {
     "@types/node": "^25.9.2",

package/stack/agents/test-analyzer.md

@@ -35,13 +35,13 @@ Apply the risk, existing-protection, behavior, seam, and non-duplication rules f
 1. Compare each changed behavior with the actual evidence in existing or changed tests.
 2. Evaluate refactor resistance, determinism, accidental `test.only`/exclusive-focus slips, stable UI semantics, negative cases, and async/concurrency behavior only where relevant to the diff.
 3. Report an actionable gap only when the existing evidence cannot catch a meaningful regression. Name that failure, the test considered, the proposed seam, and its criticality.
-4. Separately flag brittle, redundant, nondeterministic, or implementation-coupled tests worth fixing or removing.
+4. Separately flag brittle, redundant, nondeterministic, or implementation-coupled tests, repeated setup/fixtures/helpers, and suites fragmented by task, delivery or RED/GREEN phase rather than contract. Before supporting Ready, assess whether the assigned test structure can be simplified with equivalent protection and isolation; do not merge setups that protect distinct boundaries. Report structural duplication as a test-quality finding, not a missing-coverage gap; the coordinator routes the fix to its owner.
 
 ## Rating guidelines
 
 - **8–10 — Critical**: Data loss, security issue, system failure, or substantial business/user failure without sufficient evidence
 - **5–7 — Important**: Concrete user-facing, business, or operational regression with moderate impact
-- **1–4**: Not a missing-test finding; mention only a brittle or redundant existing test worth removing
+- **1–4**: Not a missing-test finding; mention only a brittle or redundant test or setup worth simplifying
 
 ## Output format
 
@@ -51,7 +51,7 @@ Apply the risk, existing-protection, behavior, seam, and non-duplication rules f
 4. **Test Quality Issues**: Brittle, redundant, nondeterministic, or implementation-coupled tests
 5. **Positive Observations**: Strong existing decisions and evidence
 
-For every recommendation, state the failure it would catch, why existing protection is insufficient, and why the proposed seam is stronger than another layer.
+For a coverage recommendation, state the failure it would catch, why existing protection is insufficient, and why the proposed seam is stronger than another layer. For a structural quality finding, identify the duplicated preparation, its maintenance cost, the proposed reuse or consolidation, and the contracts and isolation that must remain intact; do not invent missing coverage to justify simplification.
 
 ## Result contract
 

package/stack/agents/tester.md

@@ -19,6 +19,8 @@ Your job is to produce the strongest testing evidence for the risk—not to maxi
 
 Inspect the complete relevant contract (implementation, public API, docs, configuration, and existing tests), then detect the project's real runner, script/command, setup, scope, and helpers. Mirror local naming and assertion conventions; use tooling already installed. Documented project scripts, including `pnpm`, `npm`, and similar package-manager scripts, are valid. Do not add dependencies or invent a second testing stack; prohibit only invoking or resolving a command that could auto-install a missing runner/tool or require interaction without permission. If a needed suite or boundary infrastructure is absent, propose the missing protection or state the limitation rather than turning absence into a no-test decision.
 
+Organize suites by behavior or contract, not by task, delivery or RED/GREEN phase. Before creating another suite or setup, reuse relevant existing helpers and fixtures within the assignment. Share only genuinely common preparation; keep distinct boundaries and state isolation separate. One authoritative seam does not mean one test case: preserve meaningful positive, negative, platform and real-SDK cases.
+
 When time/timezone, randomness/IDs, ordering, shared state, filesystem, or network can affect the evidence, control only the relevant sources with isolated temporary fixtures and cleanup; keep expected-error assertions narrow and unexpected output visible.
 
 Make one explicit testing decision: