@aurorajs.dev/catalyst-cli 1.0.0

package/dist/templates/monorepo/openspec/config.yaml

@@ -0,0 +1,245 @@
+schema: spec-driven
+
+# Project context shown to the AI when creating artifacts.
+context: |
+  This project maintains a Business Rules Catalog at
+  `cliter/<bounded-context>/business-rules/<aggregate>.md`. Each rule has a stable
+  identifier `BR-<BC>-<AGG>-<NNN>` (UPPERCASE). A consolidated index lives at
+  `cliter/business-rules-index.json` (regenerated by `pnpm br:generate`).
+
+  ## How to consult the catalog when proposing a change
+
+  When you generate ANY artifact for this change (proposal, design, specs, tasks),
+  you MUST first consult the catalog to detect potential conflicts or extensions
+  with existing rules. Procedure:
+
+  1. Identify the bounded contexts (BCs) that this change is likely to affect.
+     Use the change description's keywords AND any file paths the change is
+     expected to touch (e.g., paths under `backend/src/@app/<bc>/...`,
+     `frontend/src/app/.../<bc>/...`, or `cliter/<bc>/...`).
+
+  2. Load the index at `cliter/business-rules-index.json` and look up rules
+     whose `bounded_contexts` array contains any of the candidate BCs (cross-BC
+     rules will appear automatically because the frontmatter is plural).
+
+  3. Read the relevant rule files at `cliter/<bc>/business-rules/<aggregate>.md`
+     for full context.
+
+  4. Pass-of-grace: ask yourself — "Are there other bounded contexts that this
+     change could plausibly affect that I have not considered?" If yes, repeat
+     step 2 for those.
+
+  5. For each existing rule, decide: does this proposal CONTRADICT, EXTEND, or
+     leave UNTOUCHED that rule?
+
+  6. If you find a CONTRADICTION or a tension that the user should resolve,
+     STOP and ask the user to choose:
+       (a) Derogate the existing rule (the new change replaces it).
+       (b) Create an exception that coexists with the existing rule.
+       (c) Justify that there is no actual conflict and override the analysis.
+     Record the choice in the proposal's "Business rules affected" section.
+
+  7. If no contradiction, continue. The proposal MAY still declare new rules
+     to be created (post-archive via `/business-rules:promote`).
+
+  ## Catalog conventions
+
+  - Identifiers in UPPERCASE (`BR-PROD-EVENT-005`).
+  - Frontmatter fields in kebab-lowercase (matches `*.aurora.yaml`).
+  - Prose (rule statements, case tables, glossaries) in **Spanish**.
+  - Identifiers, file names, JSON keys, and citations in **English**.
+  - Keywords are deliberately **bilingual** (Spanish + English).
+  - **Do NOT "harmonize" the language mix. It is intentional and documented in
+    `docs/business-rules/README.md` and `CLAUDE.md`.**
+
+  ## Lifecycle
+
+  - Rules are crystallized POST-implementation. The proposal declares which
+    rules will be affected; the catalog is updated AFTER archive via
+    `/business-rules:promote`.
+  - Rules are NOT a precondition for any change. A change can proceed even if
+    its rule documentation is not yet written.
+  - Rules are MODIFIED by derogating the previous one and creating a new one
+    with a NEW identifier; identifiers are NEVER reused.
+
+  ## Optional code citations
+
+  Code MAY cite a rule with `@rule BR-<BC>-<AGG>-<NNN>` in JSDoc. Citations are
+  NOT enforced — they are aids for future readers. The audit reports orphan
+  citations (cite-but-no-rule) and zombie rules (rule-but-no-cite) without
+  failing builds.
+
+  ## Harness Rules — a second catalog, consulted IN ADDITION to Business Rules
+
+  Harness Rules (HR) are consulted in addition to the Business Rules above; both
+  run independently for every change. HR are architectural/framework CONSTRAINTS
+  (you COMPLY or you VIOLATE them), NOT business invariants crystallized
+  post-implementation. The catalog lives at `cliter/harness-rules/<topic>.md`
+  (core, scope project) and `cliter/<bounded-context>/harness-rules/<topic>.md`
+  (bc-bound or multi-bc). Identifiers are `HR-<TOPIC>-<NNN>` (core) or
+  `HR-<BC>-<TOPIC>-<NNN>` (bc-bound), always UPPERCASE. A consolidated index lives
+  at `cliter/harness-rules-index.json` (regenerated by `pnpm hr:generate`).
+
+  Harness Rules are the project's architectural/framework constraints — where
+  things live, how code is structured, which patterns are followed (ports and
+  adapters, cross-BC bridges, generated-code reconciliation, dev modes, type and
+  ACL hygiene). A BR is a domain invariant; an HR is a harness constraint.
+
+  ## How to consult the harness catalog when proposing a change
+
+  During `/opsx:propose`, in addition to the Business Rules procedure above, you
+  MUST consult the harness catalog. Procedure:
+
+  1. Identify the file paths this change is expected to touch (under
+     `backend/src/@app/<bc>/...`, `backend/src/@aurora/...`,
+     `backend/src/@bridges/...`, `frontend/src/...`, `cliter/...`, `scripts/...`,
+     `.claude/...`, or `docs/...`).
+
+  2. Load `cliter/harness-rules-index.json` and use its `byPath` array (entries
+     of pattern plus ruleIds) to find every ACTIVE rule whose glob pattern
+     matches any candidate path. Cross-check `byKeyword` when the change mentions
+     a harness concept (shadow module, cross-BC, ports, generated code, dev mode,
+     double cast) but the paths are unclear. Look a rule up directly in `byId`
+     when the user cites an `HR-<TOPIC>-<NNN>` identifier.
+
+  3. Read the matching rule files at `cliter/harness-rules/<topic>.md` (or the
+     bc-bound location) for the full Enunciado, the Casos exhaustivos decision
+     matrix, and the Anchor patterns.
+
+  4. For each GOVERNING rule, decide which one the approach does — COMPLY (honors
+     the rule; the default, recorded so the analysis is auditable), VIOLATE
+     (breaks the rule as written), or DEROGATE (a deliberate architectural
+     decision to retire or replace the rule, which is itself an architectural
+     change, not a side effect of an ordinary proposal).
+
+  5. If, and ONLY if, the approach would VIOLATE a rule of `blocking` severity
+     (read from the rule's index entry), STOP and ask the user to choose —
+     (a) derogate the rule, (b) create an exception that coexists with it, or
+     (c) justify that there is no actual conflict. Record the choice in the
+     proposal's "Harness rules applicable" section. A VIOLATE of an
+     `informational` rule is surfaced but does NOT halt.
+
+  ## Two-level harness enforcement (context for the agent)
+
+  Harness Rules are enforced at two levels, not uniformly. A rule that declares a
+  `detect` field (a literal pattern plus a message, propagated to the rule's
+  index entry) is CONTENT-BLOCKED — a PreToolUse content-guard blocks writes
+  matching the pattern under the rule's paths. Today the only content-blocked
+  rule is `HR-ACL-001` (the `as unknown as` double cast). Every other rule
+  (HR-MODULES-001, HR-BRIDGES-001, HR-PORTS-001, HR-CODEGEN-001, HR-MODES-001) is
+  ADVISORY — surfaced via the skill, prompt-time injection, and checkpoint
+  messaging, with the agent applying judgment. A path glob cannot tell a
+  legitimate new flow from a shadow module, so advisory rules are never
+  auto-blocked.
+
+  ## Harness lifecycle — stable constraints, NOT per-change invariants
+
+  Unlike Business Rules, Harness Rules do NOT use the BR `mantiene / deroga /
+  extiende` vocabulary in proposals, and there is NO `/harness-rules:promote`
+  lifecycle. A proposal does not crystallize an HR after archive. A Harness Rule
+  changes ONLY through a deliberate architectural decision (its own change), by
+  derogating the old rule and creating a new one with a NEW identifier;
+  identifiers are never reused. An ordinary proposal records COMPLY, VIOLATE, or
+  DEROGATE against the EXISTING catalog and never declares HR to be created
+  later, never schedules an HR promote task, and never lists "new HR" to be
+  written post-archive (that document/promote tooling is deferred to slice S4).
+
+# Per-artifact rules.
+rules:
+  proposal:
+    - The proposal MUST include a top-level section `## Business rules affected`
+      placed immediately before `## Impact`.
+    - For every existing rule that this change touches, list its identifier and
+      the action the change will take on it; valid actions are `mantiene`
+      (untouched, but referenced), `deroga` (derogate), `extiende`
+      (extension/exception with a new sibling rule).
+    - For every NEW rule that this change will create, declare it under a
+      `Nuevas` subsection with format `- en \`<bc>/<aggregate>\` — <title>`.
+      Optionally prepend an ID prefix when the destination file has no previous
+      rules — `- BR-<PREFIX> en \`<bc>/<aggregate>\` — <title>`. The real
+      identifier (sequence number) is assigned by `/business-rules:promote`,
+      which creates a scaffold in the destination file with state=proposed and
+      [VERIFICAR] markers in the body. The human fills the body and changes
+      state to active.
+    - If no existing rules are touched and no new rules will be created, write
+      `None` under the section.
+    - If during conflict detection you found a contradiction, you MUST halt
+      proposal generation and present the resolution options (derogate /
+      exception / no-conflict justification) to the user, recording the chosen
+      resolution in the section.
+    - The conflict detection procedure described in `context` is MANDATORY
+      before completing this artifact.
+    - The proposal MUST also include a top-level section `## Harness rules
+      applicable` placed immediately AFTER `## Business rules affected` (and
+      before `## Impact`).
+    - For every ACTIVE Harness Rule whose `byPath` pattern matches a file path
+      the change touches, list its identifier and declare COMPLY, VIOLATE, or
+      DEROGATE with a one-line justification (for example, HR-ACL-001 COMPLY when
+      the new adapters import the canonical type from `@api/graphql` with no
+      double cast).
+    - In the Harness section do NOT use the Business Rules `mantiene / deroga /
+      extiende` vocabulary and do NOT add a `Nuevas` subsection; Harness Rules
+      are stable constraints, not per-change crystallized invariants, and there
+      is no `/harness-rules:promote` lifecycle to feed.
+    - If NO active Harness Rule governs any of the touched paths, write `None`
+      under the `## Harness rules applicable` section.
+    - HALT proposal generation ONLY if the proposed approach would VIOLATE a
+      Harness Rule of `blocking` severity (read from its index entry). On halt,
+      present the resolution options (derogate the rule / create an exception /
+      justify no conflict) and record the chosen resolution. A VIOLATE of an
+      `informational` rule is recorded but does not halt.
+
+  design:
+    - When the change implies a state-machine modification, a new cascade, or a
+      new derived invariant, reference the affected rule identifiers by ID.
+    - Document trade-offs concerning rule changes (derogation vs exception vs
+      new rule) in the `## Decisions` section when non-trivial.
+    - When the design's approach touches a path governed by an active Harness
+      Rule, reference the affected `HR-<TOPIC>-<NNN>` identifiers by ID in the
+      relevant decision and explain how the design honors them.
+    - If the change is a deliberate DEROGATE of a Harness Rule, document the
+      architectural trade-off in the `## Decisions` section (why the constraint
+      is retired or replaced, and the new rule that supersedes it).
+    - When the change writes hand-written logic, state the test strategy and the
+      runner (`pnpm --filter <pkg> test`) in `## Decisions`, so the tasks can be
+      sequenced test-first and apply has a concrete runner.
+
+  specs:
+    - When a requirement codifies behavior already documented in the catalog,
+      cite the rule identifier inline (e.g., "implements BR-PROD-EVENT-005").
+    - Do not duplicate the rule's case table; reference the rule and add only
+      the spec-level acceptance scenarios.
+    - When a requirement codifies behavior constrained by the harness catalog,
+      cite the rule identifier inline (for example, must keep cross-BC wiring in
+      `@bridges/` per HR-BRIDGES-001).
+    - Do not duplicate the rule's Casos exhaustivos matrix; reference the rule by
+      ID and add only the spec-level acceptance scenarios.
+
+  tasks:
+    - If the proposal's "Business rules affected" section declares any rule
+      change (deroga, extiende, or Nuevas), include a final task to invoke
+      `/business-rules:promote` after `/opsx:archive` to crystallize the changes
+      into the catalog.
+    - If the change adds code under paths that are covered by an active rule
+      (per the index's `byPath` lookup), consider including a task to add an
+      `@rule` JSDoc citation in the relevant function or service. This task is
+      optional, not required.
+    - Do NOT add a `/harness-rules:promote` task; no such lifecycle exists for
+      Harness Rules (BR-only, deferred to a later slice). A proposal records
+      COMPLY, VIOLATE, or DEROGATE against the existing catalog and never
+      schedules HR to be crystallized after archive.
+    - If the change is a deliberate DEROGATE of a Harness Rule, include a task to
+      edit the rule file directly (state `derogated` plus a replacement rule with
+      a new identifier) and run `pnpm hr:generate && pnpm hr:validate`. This is a
+      manual catalog edit, not a promote command.
+    - Sequence tasks TEST-FIRST — for every task that writes non-trivial
+      hand-written code, emit the failing-test task BEFORE its implementation task
+      (red → green → refactor, per `superpowers:test-driven-development`). EXCLUDE
+      tasks that only touch CLI-generated code (`@aurora-catalyst-generated`) —
+      those are tested at the `.eta` template level (Framework mode), never over
+      the regenerable output.
+    - Include a FINAL verification task (after implementation, before archive) to
+      be run in FRESH context, NOT by the implementer — `judgment-day` for a
+      Complex change (blind dual review → fix → re-judge), `/code-review` for a
+      Medium change. Skip only for Minor (trivial diff). This keeps the quality
+      gate auditable in `tasks.md` and preserves the independent-judgment rule.

package/dist/templates/monorepo/package.json

@@ -0,0 +1,47 @@
+{
+  "name": "aurora-catalyst",
+  "version": "0.0.1",
+  "private": true,
+  "packageManager": "pnpm@11.5.2+sha512.71c631e382066efc25625d5cf029075de07b61b37f6e27350fbd84b1bda5864c8c1967adc280776b45c30a715c0359a3be08fef42d5bb09e2b99029979692916",
+  "scripts": {
+    "dev": "concurrently -n back,front -c blue,green \"pnpm back:dev\" \"pnpm front:dev\"",
+    "back:dev": "pnpm --filter aurora-back start:dev",
+    "back:add": "pnpm --filter aurora-back add",
+    "back:test": "pnpm --filter aurora-back test",
+    "back:test:e2e": "pnpm --filter aurora-back test:e2e",
+    "back:graphql:types": "pnpm --filter aurora-back graphql:types",
+    "back:lint": "pnpm --filter aurora-back lint",
+    "front:dev": "pnpm --filter aurora-front start:local",
+    "front:add": "pnpm --filter aurora-front add",
+    "front:build": "pnpm --filter aurora-front build",
+    "front:graphql:types": "pnpm --filter aurora-front graphql:types",
+    "front:test": "pnpm --filter aurora-front test",
+    "format": "pnpm -r run format",
+    "prepare": "husky || true",
+    "br:generate": "tsx scripts/business-rules/generate-index.ts",
+    "br:validate": "tsx scripts/business-rules/validate-catalog.ts",
+    "br:validate:citations": "tsx scripts/business-rules/validate-citations.ts",
+    "br:check": "tsx scripts/business-rules/check.ts",
+    "hr:generate": "tsx scripts/harness-rules/generate-index.ts",
+    "hr:validate": "tsx scripts/harness-rules/validate-catalog.ts",
+    "hr:check": "tsx scripts/harness-rules/check.ts",
+    "test:packager": "node --test \"scripts/packager/**/*.test.mjs\""
+  },
+  "devDependencies": {
+    "@commitlint/cli": "^21.0.2",
+    "@commitlint/config-conventional": "^21.0.2",
+    "@types/node": "^25.9.1",
+    "ajv": "^8.20.0",
+    "ajv-formats": "^3.0.1",
+    "concurrently": "^10.0.3",
+    "cz-conventional-changelog": "^3.3.0",
+    "gray-matter": "^4.0.3",
+    "husky": "^9.1.7",
+    "tsx": "^4.22.4"
+  },
+  "config": {
+    "commitizen": {
+      "path": "cz-conventional-changelog"
+    }
+  }
+}

package/dist/templates/monorepo/pnpm-workspace.yaml

@@ -0,0 +1,23 @@
+packages:
+  - "backend"
+  - "frontend"
+overrides:
+  rxjs: "7.8.2"
+allowBuilds:
+  "@apollo/protobufjs": true
+  "@nestjs/core": true
+  "@parcel/watcher": true
+  "@scarf/scarf": false
+  bcrypt: true
+  esbuild: true
+  highlight.js: true
+  less: true
+  lmdb: true
+  msgpackr-extract: true
+  nx: true
+  sharp: true
+  unrs-resolver: true
+minimumReleaseAgeExclude:
+  - concurrently@10.0.3
+  - '@spartan-ng/brain@0.0.1-alpha.707'
+  - '@spartan-ng/cli@0.0.1-alpha.707'

package/dist/templates/monorepo/scripts/business-rules/audit.ts

@@ -0,0 +1,344 @@
+/**
+ * Structural audit of the business-rules catalog.
+ *
+ * Sections produced by this script:
+ *   A) Health      — counts, BCs covered, estimated catalog size in tokens.
+ *   B) Drift       — Implementa paths missing, orphan/zombie citations.
+ *   C) Assumptions — outstanding [VERIFICAR] / [ASUNCIÓN] markers older than 30 days.
+ *   D) Cross-BC    — rules listing several bounded_contexts: verify pointer
+ *                    presence in the non-owning BC catalog files.
+ *
+ * Section E (semantic tensions / pairwise analysis) is NOT produced here.
+ * It is added by Claude continuing the session when the audit is invoked
+ * via the slash command /business-rules:audit (script + LLM continuation
+ * pattern, same as /business-rules:promote). Detection of contradictions
+ * is also covered preventively in /opsx:propose via openspec/config.yaml.
+ *
+ * Usage:
+ *   The script is invoked from the slash command /business-rules:audit
+ *   (it is NOT exposed as `pnpm br:*` to keep the public API aligned with
+ *   how the audit is actually consumed: the useful output is the integrated
+ *   one with section E, which only the slash command produces).
+ *
+ *   Direct invocation (e.g. for tooling, debugging, future CI):
+ *     npx tsx scripts/business-rules/audit.ts            # human-readable
+ *     npx tsx scripts/business-rules/audit.ts --json     # JSON for tooling
+ *
+ * Exit codes:
+ *   0 — clean
+ *   2 — warnings present (drift, assumptions, missing pointers)
+ */
+import { readFileSync, existsSync } from 'node:fs';
+import { resolve } from 'node:path';
+import fastGlob from 'fast-glob';
+import { parseCatalog, findRepoRoot } from './parse-catalog';
+import { extractSection, hasGlobMetachars } from '../_catalog-runtime';
+import type { CatalogIndex, ParsedFile } from './types';
+
+const STALE_AGE_DAYS = 30;
+const SIZE_INFO = 150;
+const SIZE_WARN = 250;
+const SIZE_SOFT_ERROR = 500;
+const SIZE_REARCHITECT = 1000;
+const TOKENS_PER_RULE_AVG = 700;
+
+interface AuditReport {
+  generatedAt: string;
+  health: {
+    totalFiles: number;
+    activeRules: number;
+    derogatedRules: number;
+    proposedRules: number;
+    totalRules: number;
+    boundedContextsCovered: string[];
+    estimatedTokens: number;
+    sizeBucket: string;
+  };
+  drift: {
+    missingImplementaPaths: Array<{ ruleId: string; path: string }>;
+    orphanCitations: Array<{ ruleId: string; filePath: string; line: number }>;
+    zombieRules: Array<{ ruleId: string; ageDays: number }>;
+  };
+  assumptions: Array<{ ruleId: string; marker: string; ageDays: number; file: string }>;
+  crossBcMissingPointers: Array<{
+    ruleId: string;
+    boundedContext: string;
+    expectedPointerIn: string;
+  }>;
+}
+
+async function findCitations(
+  repoRoot: string,
+): Promise<Array<{ ruleId: string; filePath: string; line: number }>> {
+  const patterns = ['backend/src/**/*.{ts,tsx}', 'frontend/src/**/*.{ts,tsx,html}'];
+  const files = await fastGlob(patterns, {
+    cwd: repoRoot,
+    absolute: true,
+    ignore: ['**/node_modules/**', '**/dist/**', '**/.angular/**'],
+  });
+  const pattern = /@rule\s+(BR-[A-Z0-9-]+)/g;
+  const out: Array<{ ruleId: string; filePath: string; line: number }> = [];
+  for (const filePath of files) {
+    let content: string;
+    try {
+      content = readFileSync(filePath, 'utf-8');
+    } catch {
+      continue;
+    }
+    if (!content.includes('@rule')) continue;
+    const lines = content.split('\n');
+    for (let i = 0; i < lines.length; i++) {
+      for (const m of lines[i].matchAll(pattern)) {
+        out.push({ ruleId: m[1], filePath, line: i + 1 });
+      }
+    }
+  }
+  return out;
+}
+
+function daysSince(iso: string): number {
+  const t = new Date(iso).getTime();
+  return Math.floor((Date.now() - t) / 86400000);
+}
+
+function classifySize(activeRules: number): string {
+  if (activeRules >= SIZE_REARCHITECT) return 'REARCHITECT';
+  if (activeRules >= SIZE_SOFT_ERROR) return 'SOFT_ERROR';
+  if (activeRules >= SIZE_WARN) return 'WARN';
+  if (activeRules >= SIZE_INFO) return 'INFO';
+  return 'OK';
+}
+
+const ASSUMPTION_MARKER = /\[(VERIFICAR|ASUNCIÓN)[^\]]*\]/g;
+
+function extractAssumptions(
+  parsed: ParsedFile[],
+): Array<{ ruleId: string; marker: string; ageDays: number; file: string }> {
+  const out: Array<{ ruleId: string; marker: string; ageDays: number; file: string }> = [];
+  for (const file of parsed) {
+    const fileAge = daysSince(file.frontmatter.last_updated);
+    if (fileAge < STALE_AGE_DAYS) continue;
+    for (const rule of file.rules) {
+      for (const m of rule.body.matchAll(ASSUMPTION_MARKER)) {
+        out.push({
+          ruleId: rule.id,
+          marker: m[0],
+          ageDays: fileAge,
+          file: file.relativePath,
+        });
+      }
+    }
+  }
+  return out;
+}
+
+function detectCrossBcMissingPointers(parsed: ParsedFile[]): Array<{
+  ruleId: string;
+  boundedContext: string;
+  expectedPointerIn: string;
+}> {
+  const issues: Array<{
+    ruleId: string;
+    boundedContext: string;
+    expectedPointerIn: string;
+  }> = [];
+  for (const file of parsed) {
+    if (file.frontmatter.bounded_contexts.length <= 1) continue;
+    const ownerBc = file.frontmatter.bounded_contexts[0];
+    for (const rule of file.rules) {
+      for (const bc of file.frontmatter.bounded_contexts.slice(1)) {
+        const found = parsed.some(
+          (other) =>
+            other !== file &&
+            other.frontmatter.bounded_contexts.includes(bc) &&
+            other.frontmatter.bounded_contexts[0] === bc &&
+            new RegExp(`\\b${rule.id}\\b`).test(readFileSync(other.filePath, 'utf-8')),
+        );
+        if (!found) {
+          issues.push({
+            ruleId: rule.id,
+            boundedContext: bc,
+            expectedPointerIn: `cliter/${bc}/business-rules/<some-aggregate>.md`,
+          });
+        }
+      }
+      void ownerBc;
+    }
+  }
+  return issues;
+}
+
+async function main(): Promise<void> {
+  const args = process.argv.slice(2);
+  const asJson = args.includes('--json');
+  const repoRoot = findRepoRoot();
+
+  const indexPath = resolve(repoRoot, 'cliter/business-rules-index.json');
+  if (!existsSync(indexPath)) {
+    console.error('✗ No existe el índice. Ejecuta `pnpm br:generate` primero.');
+    process.exit(1);
+  }
+  const index = JSON.parse(readFileSync(indexPath, 'utf-8')) as CatalogIndex;
+  const parsed = await parseCatalog({ repoRoot });
+
+  const citations = await findCitations(repoRoot);
+  const cited = new Set(citations.map((c) => c.ruleId));
+
+  const orphanCitations = citations.filter((c) => !index.byId[c.ruleId]);
+  const zombieRules: Array<{ ruleId: string; ageDays: number }> = [];
+  for (const rule of Object.values(index.byId)) {
+    if (rule.state !== 'active') continue;
+    if (cited.has(rule.id)) continue;
+    const age = daysSince(rule.last_updated);
+    if (age >= STALE_AGE_DAYS) zombieRules.push({ ruleId: rule.id, ageDays: age });
+  }
+
+  const missingImplementaPaths: Array<{ ruleId: string; path: string }> = [];
+  const pathPattern = /`(backend|frontend|cliter|scripts|docs)\/[^`]+`/g;
+  for (const file of parsed) {
+    for (const rule of file.rules) {
+      // Shared, line-anchored section extraction (fix #8): `### Implementa` no
+      // longer mis-bounds `### Implementación`.
+      const section = extractSection(rule.body, '### Implementa');
+      if (section === null) continue;
+      for (const m of section.matchAll(pathPattern)) {
+        const candidate = m[0].replace(/`/g, '').split(':')[0];
+        // Skip glob patterns; only concrete paths are existence-checked (fix #9).
+        if (hasGlobMetachars(candidate)) continue;
+        if (!existsSync(resolve(repoRoot, candidate))) {
+          missingImplementaPaths.push({ ruleId: rule.id, path: candidate });
+        }
+      }
+    }
+  }
+
+  const assumptions = extractAssumptions(parsed);
+  const crossBcMissingPointers = detectCrossBcMissingPointers(parsed);
+
+  const boundedContextsCovered = Object.keys(index.byBoundedContext).sort();
+  const estimatedTokens = index.totalRules * TOKENS_PER_RULE_AVG;
+  const sizeBucket = classifySize(index.activeRules);
+
+  const report: AuditReport = {
+    generatedAt: new Date().toISOString(),
+    health: {
+      totalFiles: index.totalFiles,
+      activeRules: index.activeRules,
+      derogatedRules: index.derogatedRules,
+      proposedRules: index.proposedRules,
+      totalRules: index.totalRules,
+      boundedContextsCovered,
+      estimatedTokens,
+      sizeBucket,
+    },
+    drift: {
+      missingImplementaPaths,
+      orphanCitations,
+      zombieRules,
+    },
+    assumptions,
+    crossBcMissingPointers,
+  };
+
+  if (asJson) {
+    console.log(JSON.stringify(report, null, 2));
+  } else {
+    printHumanReport(report);
+  }
+
+  const hasWarnings =
+    missingImplementaPaths.length > 0 ||
+    orphanCitations.length > 0 ||
+    zombieRules.length > 0 ||
+    assumptions.length > 0 ||
+    crossBcMissingPointers.length > 0 ||
+    sizeBucket !== 'OK';
+
+  process.exit(hasWarnings ? 2 : 0);
+}
+
+function printHumanReport(report: AuditReport): void {
+  const h = report.health;
+  console.log('=== Business rules — audit ===');
+  console.log(`Generado: ${report.generatedAt}\n`);
+
+  console.log('A) SALUD');
+  console.log(`  Reglas activas:    ${h.activeRules}`);
+  console.log(`  Reglas derogadas:  ${h.derogatedRules}`);
+  console.log(`  Reglas propuestas: ${h.proposedRules}`);
+  console.log(`  Total:             ${h.totalRules} en ${h.totalFiles} archivos`);
+  console.log(`  BCs cubiertos:     ${h.boundedContextsCovered.join(', ') || '(ninguno)'}`);
+  console.log(`  Tamaño estimado:   ~${h.estimatedTokens.toLocaleString()} tokens`);
+  console.log(`  Bucket de tamaño:  ${h.sizeBucket}`);
+  if (h.sizeBucket !== 'OK') {
+    console.log(
+      `  ⚠ Considera filtrado por BC en propose y revisión de la arquitectura del catálogo.`,
+    );
+  }
+
+  console.log('\nB) DRIFT');
+  if (report.drift.missingImplementaPaths.length === 0) {
+    console.log('  ✓ Sin paths inexistentes en `Implementa`.');
+  } else {
+    console.log(`  ⚠ Paths inexistentes (${report.drift.missingImplementaPaths.length}):`);
+    for (const x of report.drift.missingImplementaPaths) {
+      console.log(`    - [${x.ruleId}] ${x.path}`);
+    }
+  }
+  if (report.drift.orphanCitations.length === 0) {
+    console.log('  ✓ Sin citaciones huérfanas.');
+  } else {
+    console.log(`  ⚠ Citaciones huérfanas (${report.drift.orphanCitations.length}):`);
+    for (const x of report.drift.orphanCitations) {
+      console.log(`    - ${x.ruleId} en ${x.filePath}:${x.line}`);
+    }
+  }
+  if (report.drift.zombieRules.length === 0) {
+    console.log('  ✓ Sin reglas zombi.');
+  } else {
+    console.log(`  ⚠ Reglas zombi (${report.drift.zombieRules.length}):`);
+    for (const x of report.drift.zombieRules) {
+      console.log(`    - ${x.ruleId} (${x.ageDays} días sin citas)`);
+    }
+  }
+
+  console.log('\nC) ASUNCIONES PENDIENTES');
+  if (report.assumptions.length === 0) {
+    console.log('  ✓ Sin asunciones antiguas.');
+  } else {
+    console.log(`  ⚠ Marcadores con > ${STALE_AGE_DAYS} días (${report.assumptions.length}):`);
+    for (const x of report.assumptions) {
+      console.log(`    - [${x.ruleId}] ${x.marker} (${x.ageDays} días) en ${x.file}`);
+    }
+  }
+
+  console.log('\nD) CROSS-BC POINTERS');
+  if (report.crossBcMissingPointers.length === 0) {
+    console.log('  ✓ Todas las reglas cross-BC tienen apuntadores.');
+  } else {
+    console.log(`  ⚠ Apuntadores faltantes (${report.crossBcMissingPointers.length}):`);
+    for (const x of report.crossBcMissingPointers) {
+      console.log(`    - ${x.ruleId} no aparece en ${x.expectedPointerIn}`);
+    }
+  }
+
+  console.log(
+    '\nNota: este script ha cubierto la parte estructural del audit. Para incluir',
+  );
+  console.log(
+    '      el análisis semántico (tensiones latentes entre reglas), invoca el slash',
+  );
+  console.log(
+    '      command /business-rules:audit en Claude Code: corre este script y luego',
+  );
+  console.log(
+    '      Claude continúa la sesión con el análisis pairwise (sección E del reporte).',
+  );
+  console.log('');
+}
+
+main().catch((err) => {
+  console.error('✗ audit falló:');
+  console.error(err.message ?? err);
+  process.exit(1);
+});