@aurorajs.dev/catalyst-cli 1.1.3 → 2.0.0

package/dist/templates/monorepo/.claude/skills/judgment-day/SKILL.md

@@ -1,10 +1,10 @@
 ---
 name: judgment-day
-description: "Trigger: judgment day, dual review, adversarial review, juzgar. Run blind dual review, fix confirmed issues, then re-judge."
+description: "Trigger: judgment day, dual review, adversarial review, juzgar. Run blind judges, verify every severe finding against the code, fix, then re-judge the fixed hunks."
 license: Apache-2.0
 metadata:
   author: gentleman-programming
-  version: "1.4"
+  version: "1.5"
   triggers:
     - judgment day
     - dual review
@@ -22,11 +22,15 @@ Load this skill only when the user explicitly asks for Judgment Day, dual/advers
 ## Hard Rules
 
 - Resolve project skills before launching agents: read skill registry, match skill paths by target files/task, and inject the same `Skills to load before work` block into both judge prompts and fix prompts.
-- Launch **two blind judges in parallel** with identical target and criteria; never review the code yourself.
-- Wait for both judges before synthesis; never accept a partial verdict.
+- Launch blind judges in parallel with identical target and criteria; never review the code yourself.
+- Judge count: two blind judges for a Complex change; ONE for a Medium change, unless the target touches an authorization boundary (guards, `@Auth`, `@TenantConstraint`/`@TenantPolicy`, `dTenants`/`dPermissions`, provisioning guards) or a data boundary (migrations, pivot semantics, cross-BC writes) — then two.
+- Wait for all launched judges before synthesis; never accept a partial verdict.
 - Classify warnings as `WARNING (real)` only if normal intended use can trigger them; otherwise downgrade to INFO as `WARNING (theoretical)`.
-- Ask before fixing Round 1 confirmed issues.
-- After any fix agent runs, immediately re-launch both judges in parallel before commit/push/done/session summary.
+- Every CRITICAL/BLOCKER and every `WARNING (real)` is VERIFIED BY THE ORCHESTRATOR against the code before any fix, whether one judge or two reported it. Agreement between judges is neither required nor sufficient. A finding whose `evidence_class` is `static-analysis` is measured (run the test, the lint, or read the exact path) before acting.
+- Verification outcomes: `verified` (fix it), `refuted` (record why, INFO), `unverifiable` (report as suspect; never auto-fix).
+- Ask before fixing Round 1 verified issues.
+- After any fix agent runs, immediately re-judge before commit/push/done/session summary: ONE judge scoped to the changed hunks plus the frozen ledger; relaunch two only when the fix touched an authorization or data boundary — the same two triggers as the round-1 judge-count rule.
+- Judges receive the task's acceptance criteria (or the change's delta-spec requirements) as review criteria. Naming/conventions are NOT a judge criterion (lint owns them).
 - Terminal states are only `JUDGMENT: APPROVED` or `JUDGMENT: ESCALATED`.
 - After 2 fix iterations with remaining issues, ask the user whether to continue.
 
@@ -35,25 +39,24 @@ Load this skill only when the user explicitly asks for Judgment Day, dual/advers
 | Condition | Action |
 |---|---|
 | Target unclear | Ask for scope; do not launch judges. |
-| No skill registry | Warn, proceed with generic criteria, and record `Skill Resolution: none`. |
-| Both judges find same CRITICAL/real WARNING | Confirmed; ask/fix according to round rules. |
-| One judge finds issue | Suspect; report and triage, do not auto-fix. |
-| Judges contradict | Escalate for manual decision. |
+| No skill registry | Warn, proceed with generic criteria, and report `skill_resolution: none`. |
+| Severe finding reported (by one or two judges) | Orchestrator verifies against the code; verified → ask/fix per round rules; refuted → INFO with reason; unverifiable → suspect, report. |
+| Judges contradict | Verify both claims; if still contradictory, escalate. |
 | Round 2+ has only theoretical warnings/suggestions | Report as INFO; do not re-judge. |
 
 ## Execution Steps
 
 1. Confirm target and optional custom criteria.
 2. Resolve exact skill paths from registry or warn if missing.
-3. Start Judge A and Judge B concurrently via delegation.
-4. Synthesize findings into confirmed, suspect, contradiction, and INFO buckets.
-5. Ask before Round 1 fixes; delegate a separate fix agent for confirmed approved fixes only.
-6. Re-judge in parallel after fixes; repeat until approved, escalated, or user asks to stop.
+3. Launch judges per the judge-count rule (one or two) via delegation.
+4. Synthesize findings and VERIFY every severe finding against the code (verified / refuted / unverifiable); bucket theoretical warnings and suggestions as INFO.
+5. Ask before Round 1 fixes; delegate a separate fix agent for verified, approved fixes only.
+6. Re-judge with a single judge scoped to the changed hunks plus the frozen ledger (two only if the fix touched an authorization or data boundary); repeat until approved, escalated, or user asks to stop.
 7. Before any terminal action, verify every active Judgment Day has a terminal state.
 
 ## Output Contract
 
-Return `## Judgment Day — {target}` with round number, verdict table, confirmed/suspect/contradiction counts, fixes applied, re-judgment result, `Skill Resolution`, and final `JUDGMENT: APPROVED ✅` or `JUDGMENT: ESCALATED ⚠️`.
+Return `## Judgment Day — {target}` with round number, verdict table, verified/refuted/unverifiable counts, fixes applied, re-judgment result, each judge's `skill_resolution:` and `status:` lines, and final `JUDGMENT: APPROVED ✅` or `JUDGMENT: ESCALATED ⚠️`.
 
 ## References
 

package/dist/templates/monorepo/.claude/skills/judgment-day/references/prompts-and-formats.md

@@ -11,63 +11,88 @@ You are an adversarial code reviewer. Your ONLY job is to find problems.
 ## Skills to load before work
 {matching SKILL.md paths, if available}
 
+## Acceptance criteria to judge against
+{task acceptance criteria or delta-spec requirements}
+
 ## Review Criteria
 - Correctness: logical errors and behavior mismatches
 - Edge cases: missing states, inputs, or platform constraints
 - Error handling: propagation, logging, recovery
 - Performance: N+1, wasteful loops, excessive allocations
 - Security: injection, secrets, auth boundaries
-- Naming/conventions: project standards and local patterns
+- TEST QUALITY (mandatory): for each new test, would it FAIL if the logic it covers were broken?
 {custom criteria, if provided}
 
+## Evidence discipline
+- You have no shell. State per finding whether it is `deterministic` (you read the exact code path that proves it) or `static-analysis` (reasoning, not executed).
+- Never cite a code comment as proof of runtime behavior.
+- Do not report what a linter, type checker, or Prettier already catches.
+- Do not report pre-existing issues on untouched lines unless the diff activates them — if it does, say so explicitly.
+
 ## Return Format
-Findings only. No praise.
+Findings only. No praise. ONE format — the JSON object from your agent definition, no markdown fields block alongside it:
 
-Each finding:
-- Severity: CRITICAL | WARNING (real) | WARNING (theoretical) | SUGGESTION
-- File: path/to/file.ext (line N if applicable)
-- Description: what is wrong and why it matters
-- Suggested fix: one-line intent
+- `findings[]`, each with:
+  - `location`: `path:line`
+  - `severity`: `BLOCKER | CRITICAL | WARNING | SUGGESTION`
+  - `claim`: the observable incorrect behavior — for a `WARNING`, the text starts with `(real)` or `(theoretical)`
+  - `evidence_class`: `deterministic | static-analysis`
+  - `causal_disposition`: introduced | behavior-activated | worsened | pre-existing | base-only | unknown
+  - `proof_refs[]`: concrete proof
+- `evidence[]`: what was inspected
 
-WARNING rule: normal intended use can trigger it → `WARNING (real)`; contrived/malicious/impossible path → `WARNING (theoretical)`.
+WARNING rule: normal intended use can trigger it → claim starts with `(real)`; contrived/malicious/impossible path → claim starts with `(theoretical)`.
 
-If clean: `VERDICT: CLEAN — No issues found.`
+If clean: `{"findings":[],"evidence":["what was inspected"]}`.
 
-Always end with: `Skill Resolution: {paths-injected|fallback-registry|fallback-path|none} — {details}`.
+AFTER the JSON, on two separate lines, the two contract lines `skill_resolution:` and `status:` required by `.claude/skills/catalyst-delegation/SKILL.md`.
 ```
 
+## Re-judgment prompt
+
+Variant of the Judge Prompt above, used after a fix round:
+
+- One judge only (two if the fix touched an authorization or data boundary — the same two triggers as the round-1 judge-count rule).
+- Target = the frozen ledger from the prior round PLUS the fix delta only — not the whole file/feature again.
+- May record NEW fix-caused defects (a fix that introduces its own bug), in addition to confirming the ledger's items are resolved.
+
 ## Fix Agent Prompt
 
 ```markdown
-You are a surgical fix agent. Apply ONLY the confirmed issues listed below.
+You are a surgical fix agent. Apply ONLY the verified issues listed below.
 
-## Confirmed Issues to Fix
-{confirmed findings table}
+## Verified Issues to Fix
+{verified findings table}
 
 ## Skills to load before work
 {matching SKILL.md paths, if available}
 
 ## Instructions
-- Fix only confirmed issues.
+- Fix only verified issues.
 - Do not refactor beyond the required fix.
 - Do not change unflagged code.
 - If fixing a repeated pattern in touched files, fix all occurrences of that same pattern.
 - Return changed file, line, and fix summary.
 
-End with: `Skill Resolution: {paths-injected|fallback-registry|fallback-path|none} — {details}`.
+End with the two contract lines:
+
+skill_resolution: <paths-injected | fallback-registry | fallback-footer | none>
+status: <completed | needs-guidance>
 ```
 
 ## Verdict Table
 
 ```markdown
-| Finding | Judge A | Judge B | Severity | Status |
-|---------|---------|---------|----------|--------|
-| Missing null check in auth.go:42 | ✅ | ✅ | CRITICAL | Confirmed |
-| Windows volume root edge case | ❌ | ✅ | WARNING (theoretical) | INFO |
-| Naming mismatch | ✅ | ❌ | SUGGESTION | Suspect |
+| Finding | Reported by | Severity | Verification |
+|---------|-------------|----------|--------------|
+| Missing null check in auth.go:42 | A+B | CRITICAL | verified |
+| (theoretical) Windows volume root edge case | B | WARNING | refuted |
+| Naming mismatch | A | SUGGESTION | unverifiable |
 ```
 
-Approved criteria after Round 1: zero confirmed CRITICALs and zero confirmed real WARNINGs. Theoretical warnings and suggestions may remain.
+`Reported by` records who raised the finding — `A`, `B`, or `A+B` — and is informational only; it never substitutes for orchestrator verification. `Verification` is one of `verified | refuted | unverifiable`, set by the orchestrator against the code, never by judge agreement alone.
+
+Approval criteria after Round 1: zero VERIFIED CRITICAL/BLOCKER and zero VERIFIED real WARNINGs. Theoretical warnings, suggestions, refuted findings, and unverifiable findings do not block approval on their own.
 
 ## Language Snippets
 

package/dist/templates/monorepo/.claude/skills-triggers-index.json

@@ -28,8 +28,15 @@
         "subtarea",
         "PRD",
         "milestone",
+        "depends-on",
+        "grafo",
+        "board:graph",
+        "supervisada",
+        "headless",
         "tier:",
-        "lane:"
+        "lane:",
+        "mode:",
+        "Registro de ejecución"
       ]
     },
     {

package/dist/templates/monorepo/.husky/post-checkout

@@ -0,0 +1,17 @@
+#!/usr/bin/env sh
+
+# Switching branches moves the sources the same way a pull does, and runs no
+# install either — see scripts/rebuild-core-packages.sh.
+#
+# Git passes: $1 previous HEAD, $2 new HEAD, $3 flag — 1 for a BRANCH checkout,
+# 0 for a single-file one. Only the branch case moves whole trees, so the file
+# case exits without work.
+# `.husky/**` is copied verbatim into the CLI scaffold, but the scaffold has no
+# `packages/` tree — there the core packages come from npm, so this script does
+# not ship and there is nothing to rebuild. Without this line every `git pull`
+# in a generated project would print `husky - <hook> script failed (code 127)`.
+[ -f scripts/rebuild-core-packages.sh ] || exit 0
+
+[ "$3" = "1" ] || exit 0
+
+sh scripts/rebuild-core-packages.sh "$1" "$2"

package/dist/templates/monorepo/.husky/post-merge

@@ -0,0 +1,15 @@
+#!/usr/bin/env sh
+
+# A pull or merge brings new sources but runs no install, so the core packages'
+# own `prepare` never fires. Rebuild the ones whose sources just changed — see
+# scripts/rebuild-core-packages.sh for why the gap exists at all.
+#
+# `ORIG_HEAD` is the pre-merge tip, set by merge itself. `HEAD@{1}` is the
+# fallback for the shapes that do not set it.
+# `.husky/**` is copied verbatim into the CLI scaffold, but the scaffold has no
+# `packages/` tree — there the core packages come from npm, so this script does
+# not ship and there is nothing to rebuild. Without this line every `git pull`
+# in a generated project would print `husky - <hook> script failed (code 127)`.
+[ -f scripts/rebuild-core-packages.sh ] || exit 0
+
+sh scripts/rebuild-core-packages.sh "$(git rev-parse ORIG_HEAD 2>/dev/null || git rev-parse 'HEAD@{1}' 2>/dev/null)" "$(git rev-parse HEAD)"

package/dist/templates/monorepo/.husky/pre-commit

@@ -55,11 +55,11 @@ run_catalog 'business-rules' '^cliter/[^/]+/business-rules/.*\.md$' 'br:generate
 # Harness rules: cliter/harness-rules/*.md (core scope) or cliter/<bc>/harness-rules/*.md (bc-bound / multi-bc)
 run_catalog 'harness-rules' '^cliter/harness-rules/.*\.md$|^cliter/[^/]+/harness-rules/.*\.md$' 'hr:generate' 'hr:validate' 'cliter/harness-rules-index.json' 'docs/harness-rules/INDEX.md'
 
-# Barrel lint: lint staged .ts files governed by HR-BARRELS-003 and HR-BARRELS-002.
+# Barrel lint: lint staged .ts files governed by HR-BARRELS-004 and HR-BARRELS-002.
 # Exit semantics from pnpm hr:lint-barrels (D6 del design):
 #   0  → limpio (no violations) or only fixes needed for generated files — no block.
 #   1  → blocking violation (HR-BARRELS-002 today) — aborts the commit.
-#   2  → informational violation (HR-BARRELS-003 today) — prints warnings but does NOT block.
+#   2  → informational violation (HR-BARRELS-004 today) — prints warnings but does NOT block.
 # Only runs when at least one .ts under the governed roots is staged.
 staged_ts=$(git diff --cached --name-only --diff-filter=ACMR | grep -E \
   '^backend/src/|^frontend/src/app/domains/admin/apps/' | \
@@ -75,7 +75,7 @@ if [ -n "$staged_ts" ]; then
     echo "  Corrige los imports indicados arriba y vuelve a commitear."
     exit 1
   fi
-  # Exit code 2 = solo avisos informativos (HR-BARRELS-003). No bloquea.
+  # Exit code 2 = solo avisos informativos (HR-BARRELS-004). No bloquea.
   if [ "$barrel_exit" = "0" ] || [ "$barrel_exit" = "2" ]; then
     echo "✓ hr:lint-barrels: sin violaciones blocking en los ficheros staged."
   fi