@aurorajs.dev/catalyst-cli 1.0.2 → 2.0.0

package/dist/templates/monorepo/docs/langs/README.md

@@ -0,0 +1,260 @@
+# Idiomas (langs)
+
+> Cómo funciona el mecanismo de idiomas de Aurora Catalyst: el catálogo, el panel del admin y las
+> traducciones de datos. Documento para desarrolladores; si eres una IA trabajando en este
+> mecanismo, lee primero `.claude/skills/catalyst-langs/SKILL.md`.
+
+## Índice
+
+- [Idiomas (langs)](#idiomas-langs)
+  - [Índice](#índice)
+  - [Idea central](#idea-central)
+  - [El catálogo: puerto + dos adaptadores](#el-catálogo-puerto--dos-adaptadores)
+    - [Cómo cambiar de adaptador (JSON → tabla o viceversa)](#cómo-cambiar-de-adaptador-json--tabla-o-viceversa)
+  - [El panel: `environment.lang`](#el-panel-environmentlang)
+    - [Los tres campos](#los-tres-campos)
+    - [Cómo se resuelve el panel](#cómo-se-resuelve-el-panel)
+    - [Cómo añadir un idioma nuevo al panel](#cómo-añadir-un-idioma-nuevo-al-panel)
+  - [¿Qué significa `isActive`?](#qué-significa-isactive)
+  - [Traducciones de datos (i18n de contenido)](#traducciones-de-datos-i18n-de-contenido)
+  - [Preguntas frecuentes](#preguntas-frecuentes)
+
+---
+
+## Idea central
+
+Todo el sistema de idiomas gira alrededor de una única query GraphQL: `coreGetLangs`. Es el
+**catálogo**: la lista de idiomas que el sistema conoce, con su nombre, su bandera, su UUID y su
+código ISO 639-2 (`iso6392`, ej. `es`, `en`, `de`).
+
+A partir de ahí, dos cosas distintas consumen ese catálogo con propósitos distintos:
+
+- **El panel** (la SPA de administración) decide QUÉ idiomas del catálogo activa y en qué orden,
+  vía la configuración `environment.lang` del build del frontend.
+- **Las traducciones de datos** (contenido de negocio traducible, como el nombre de un país en
+  varios idiomas) usan el mismo catálogo para saber qué locales son válidos.
+
+La regla que hay que interiorizar: **el `environment` activa, el catálogo describe.** El catálogo
+nunca decide por sí solo qué idiomas ve el usuario del panel; solo aporta los metadatos (nombre,
+bandera) de los idiomas que el `environment` ya eligió.
+
+---
+
+## El catálogo: puerto + dos adaptadores
+
+`coreGetLangs` está respaldado por un **puerto** (una interfaz abstracta, en el sentido de
+arquitectura hexagonal: define QUÉ se puede pedir — "dame los idiomas" — sin decir CÓMO se obtienen).
+Ese puerto se llama `CoreGetLangsService` (y su hermano `CoreGetFallbackLangService`, para resolver
+un único idioma por defecto) y viene del framework (`@aurorajs.dev/core-back`), no de este
+repositorio.
+
+Dos implementaciones concretas ("adaptadores", en el mismo vocabulario) satisfacen ese puerto:
+
+| Adaptador | Fuente de datos | Fichero |
+| --- | --- | --- |
+| **JSON** (por defecto) | Array hardcodeado en código | `backend/src/@aurora/modules/lang/core-langs.ts` |
+| **Tabla** | Tabla `common_lang` en PostgreSQL (bounded context `common`, generado con el CLI) | `backend/src/@app/common/lang/infrastructure/common-get-langs-from-table.service.ts` |
+
+Los dos devuelven exactamente la misma forma de dato (`CoreLang`: `id`, `name`, `iso6392`, `dir`,
+`sort`, `isActive`, …), así que para cualquier consumidor de `coreGetLangs` es indistinguible cuál
+de los dos está respondiendo.
+
+**¿Por qué dos?** El adaptador JSON no necesita base de datos — sirve para un proyecto nuevo que
+aún no tiene el bounded context `common` instalado. El adaptador tabla permite gestionar el
+catálogo desde el panel (crear/editar idiomas vía UI, en vez de tocar código y desplegar).
+
+### Cómo cambiar de adaptador (JSON → tabla o viceversa)
+
+El swap es **un único fichero, editado a mano**: `backend/src/@config/lang/lang.providers.ts`.
+
+```ts
+export const langProviderBindings: Provider[] = [
+  { provide: CoreGetLangsService, useClass: CoreGetLangsFromJsonService },
+  { provide: CoreGetFallbackLangService, useClass: CoreGetFallbackLangFromJsonService },
+];
+```
+
+Para pasar al adaptador tabla, se sustituyen los imports y los `useClass` por
+`CommonGetLangsFromTableService` / `CommonGetFallbackLangFromTableService` (de
+`@app/common/lang`). Nada más cambia: ni el módulo del bounded context `common`, ni los
+consumidores de `coreGetLangs`.
+
+**Por qué no es un `.env` o una variable de entorno**: la elección de adaptador es una decisión de
+proyecto, no algo que deba poder cambiarse en producción sin pasar por una revisión de código. Si
+fuera un flag de entorno, alguien podría activar el adaptador tabla sin que el bounded context
+`common` esté instalado ni sembrado — un estado roto invisible en el diff. Editando el fichero, el
+cambio de adaptador queda documentado en un commit y revisado en un pull request.
+
+**Antes de activar el adaptador tabla**, la tabla `common_lang` tiene que estar sembrada (ver
+siguiente sección). Si está vacía, el adaptador lanza un error explícito al arrancar en vez de
+fallar en silencio o caer de vuelta al JSON.
+
+**El seed preserva los UUIDs del JSON.** El seed de `CommonLang`
+(`backend/src/@app/common/shared/services/common-lang.seeder.ts`) inserta los 5 idiomas con los
+mismos identificadores (UUID), nombres y metadatos que ya tiene `core-langs.ts`. Esto importa
+porque `IamUser.langId` (el idioma preferido de cada usuario) ya guarda esos UUIDs en producción, y
+no hay una foreign key física que lo proteja — si el seed generara UUIDs nuevos, cada usuario con
+un idioma configurado quedaría con una referencia a un UUID inexistente, en silencio.
+
+---
+
+## El panel: `environment.lang`
+
+El panel (SPA de administración) NO lee el catálogo directamente para decidir qué idiomas mostrar
+en el selector. Lee la configuración `lang` de su fichero de entorno
+(`frontend/src/environments/environment.*.ts`, tipado en `environment.type.ts`).
+
+### Los tres campos
+
+```ts
+lang: {
+  base: string;      // idioma PRINCIPAL de datos
+  fallback: string;  // idioma por defecto del FRONTEND
+  langs: string[];   // universo de idiomas de la instalación
+}
+```
+
+| Campo | Qué gobierna | Ejemplo de uso |
+| --- | --- | --- |
+| `langs` | El universo de idiomas que esta instalación ofrece: el selector del panel (switcher) y las banderas de gestión de traducciones de datos. El ORDEN del array es el orden en que aparecen en el selector. | `['es', 'en']` → el switcher muestra español e inglés, en ese orden |
+| `fallback` | El idioma por defecto de la interfaz: con qué arranca el panel, qué se muestra si falta una clave de traducción, y las pantallas antes de iniciar sesión (login). | `'es'` → si un usuario nuevo entra sin preferencia, ve la interfaz en español |
+| `base` | El idioma PRINCIPAL de los DATOS (no de la interfaz). Es la traducción "de referencia" de un registro traducible — la que no se puede borrar y siempre se edita completa. **No interviene en el selector del panel ni en Transloco.** | Un país tiene su nombre en `base` como la versión canónica; las demás son traducciones opcionales |
+
+`fallback` y `base` casi siempre coinciden (normalmente ambos son `'es'`), pero son conceptos
+distintos: uno gobierna la INTERFAZ, el otro gobierna los DATOS. No los confundas ni los fusiones
+aunque hoy tengan el mismo valor — en un despliegue distinto podrían divergir (por ejemplo, un panel
+en inglés para datos cuyo idioma canónico sigue siendo el español).
+
+### Cómo se resuelve el panel
+
+El único punto del código que cruza `environment.lang.langs` con el catálogo es el `computed`
+`panel` de `LangService` (`frontend/src/@aurora/modules/lang/lang.service.ts`):
+
+```ts
+readonly panel = computed<CoreLang[]>(() => {
+  const catalog = this._langs();
+  return environment.lang.langs
+    .map((iso6392) => catalog.find((lang) => lang.iso6392 === iso6392))
+    .filter((lang): lang is CoreLang => lang !== undefined);
+});
+```
+
+Tres reglas importantes, todas encapsuladas aquí (ningún otro sitio del código las repite):
+
+1. **No hay filtro por `isActive`.** Un idioma marcado inactivo en el catálogo igualmente aparece
+   en el panel si está en `environment.lang.langs` — quien activa un idioma para el panel es el
+   fichero de entorno, no el catálogo.
+2. **El orden es el orden del array `langs`**, no el `sort` del catálogo. Si quieres reordenar el
+   switcher, editas `environment.lang.langs`; no hace falta tocar la base de datos.
+3. **Un idioma en `langs` sin entrada correspondiente en el catálogo se omite.** No hay nombre ni
+   bandera con los que pintarlo, así que simplemente no aparece — no es un error, es el
+   comportamiento esperado.
+
+El switcher del toolbar (`site-header.ts`) y el selector de idioma del formulario de cuenta de
+usuario (`account.resolvers.ts`) consumen `panel`. Si necesitas la lista de idiomas en un
+componente nuevo, usa `panel` — no reimplementes el cruce.
+
+### Cómo añadir un idioma nuevo al panel
+
+Cuatro pasos, en este orden:
+
+1. **Que el idioma exista en el catálogo.** Si usas el adaptador JSON, añádelo a `coreLangs`
+   (`backend/src/@aurora/modules/lang/core-langs.ts`) con un UUID propio. Si usas el adaptador
+   tabla, créalo desde la UI de gestión del bounded context `common` (o mediante el seed, si aún no
+   hay UI).
+2. **Añadir su código `iso6392` a `environment.lang.langs`** en el fichero de entorno
+   correspondiente (`environment.ts`, `environment.local.ts`, etc.).
+3. **Crear su fichero de traducciones**: `frontend/public/i18n/<iso6392>.json`. Este paso es
+   OBLIGATORIO y no lo valida el código — los ficheros de `public/i18n/` son assets del build; si
+   activas un idioma en `environment.lang.langs` sin su JSON, el switcher lo ofrece pero la
+   interfaz no tiene traducciones para él. La responsabilidad de mantener sincronizados
+   `environment.lang.langs` y los ficheros `public/i18n/*.json` es del desarrollador que añade el
+   idioma.
+4. **Registrar su bandera en `langFlagIcons`**
+   (`frontend/src/@aurora/modules/lang/lang-flag-icons.ts`). El campo `image` del catálogo guarda
+   el código de bandera del idioma (`'es'`, `'us'`, …) y la UI lo resuelve contra los iconos de
+   `@ng-icons/flag-icons` registrados en ese mapa. Los iconos de ng-icons se importan en tiempo de
+   build (no hay import dinámico posible), así que la bandera nueva se añade al mapa en el mismo
+   PR. Si falta, no hay error: la UI cae al nombre del idioma como texto.
+
+Si te saltas el paso 3, no hay ningún aviso en tiempo de compilación ni en tiempo de ejecución —
+simplemente el idioma se muestra con claves de traducción rotas o vacías. Verifícalo manualmente
+tras añadir un idioma.
+
+---
+
+## ¿Qué significa `isActive`?
+
+El campo `isActive` del catálogo (`CoreLang.isActive`) YA NO decide qué idiomas ve el panel — esa
+responsabilidad es de `environment.lang.langs` (ver arriba). Lo único que sigue leyendo `isActive`
+hoy es la validación de traducciones de datos en el backend
+(`CoreI18nEmbeddedService.assertActiveLocales`, de `@aurorajs.dev/core-back`, inyectado por los
+handlers de create/update generados — por ejemplo los de `tools/custom-field-option`): rechaza una
+traducción cuyo locale no esté entre los idiomas activos del catálogo, resolviendo el catálogo a
+través del mismo puerto `CoreGetLangsService`.
+
+El backend no puede leer `environment.lang.langs` directamente — es una configuración del build del
+frontend, no algo accesible desde el servidor. Por eso `isActive` sigue existiendo como el único
+mecanismo server-side de validar qué locales son aceptables para datos. Este es un punto **todavía
+abierto** en el diseño del sistema (ver `openspec/changes/centralize-langs/design.md`, sección "Open
+Questions"): a futuro puede convertirse en la convención "`environment.lang.langs` debe ser
+subconjunto del catálogo activo", cambiar la fuente de validación, o retirarse. Si te encuentras con
+un idioma que está en `environment.lang.langs` pero inactivo en el catálogo, no es necesariamente
+un bug — es un caso conocido y sin resolver todavía.
+
+---
+
+## Traducciones de datos (i18n de contenido)
+
+Además del idioma de la interfaz, algunos agregados de negocio tienen campos traducibles (por
+ejemplo, el nombre de un país). Existen dos estrategias, elegidas a nivel de agregado en su YAML:
+
+- **`embedded`** (por defecto): las traducciones viven en la misma fila, en columnas jsonb —
+  `<campo>_i18n` (mapa `locale → valor`) y `<campo>_i18n_search_text` (texto concatenado de todos
+  los locales, para búsquedas). Adecuado para agregados pequeños con pocos campos traducibles.
+- **`table`**: las traducciones viven en una tabla companion `<agregado>_i18n`, con su propia fila
+  por idioma, clave foránea al agregado padre y un idioma (`langId`) por fila. Adecuado para
+  agregados con muchos campos traducibles o donde conviene tratar cada traducción como una entidad
+  propia.
+
+Estas dos estrategias las genera (o generará) `aurora-catalyst-cli` a partir del YAML del agregado
+— este repositorio no implementa el generador, solo lo consume. Si necesitas los detalles del
+contrato de generación (nombres de columna exactos, comportamiento de borrado en cascada, contrato
+de UI de gestión de traducciones), consulta
+`openspec/changes/centralize-langs/design.md` (decisiones D5, D6 y D7) y, cuando exista, el briefing
+en `openspec/changes/centralize-langs/briefings/aurora-catalyst-cli.md`.
+
+Un ejemplo funcionando hoy de la estrategia `embedded` es `tools/custom-field-option`: sus handlers
+de create/update inyectan `CoreI18nEmbeddedService` (`@aurorajs.dev/core-back`), que valida locales
+activos, calcula `translatedLocales` (la unión de los locales presentes en cualquier campo
+traducible de la fila) y el texto de búsqueda concatenado. Ya no hace falta un servicio de i18n
+escrito a mano por agregado — el framework lo resuelve a través del mismo puerto
+`CoreGetLangsService`.
+
+---
+
+## Preguntas frecuentes
+
+**¿Por qué no hay una única lista de idiomas en un sitio?**
+Porque "idioma" significa cosas distintas según quién pregunta: el catálogo dice qué idiomas EXISTEN
+en el sistema (con nombre y bandera); `environment.lang.langs` dice cuáles ACTIVA esta instalación
+concreta para su panel; `isActive` (en desuso parcial, ver arriba) todavía condiciona qué locales
+son válidos para datos. Fusionarlos en una sola lista perdería la distinción entre "existe" y
+"está activo aquí".
+
+**Cambié `environment.lang.langs` y no veo el idioma nuevo en el switcher.**
+Revisa, en este orden: (1) que el `iso6392` exista en el catálogo (consulta `coreGetLangs` o revisa
+`core-langs.ts` / la tabla `common_lang`), (2) que el fichero
+`frontend/public/i18n/<iso6392>.json` exista, (3) que hayas editado el fichero de entorno correcto
+(local vs el que realmente sirve tu build).
+
+**¿Puedo activar el adaptador tabla sin sembrar `common_lang` primero?**
+No — el adaptador lanza un error explícito al arrancar si la tabla está vacía. Siembra primero
+(el seed corre automáticamente al arrancar el backend si el bounded context `common` está
+instalado), verifica que `common_lang` tiene filas, y solo entonces cambia el `useClass` en
+`lang.providers.ts`.
+
+**¿`base` y `fallback` pueden ser distintos?**
+Sí, y es un caso válido: un panel en un idioma (`fallback`) gestionando datos cuyo idioma
+canónico es otro (`base`). Hoy en los entornos de este repositorio ambos coinciden, pero el código
+no asume que sea así.

package/dist/templates/monorepo/docs/superpowers/specs/2026-07-02-report-creator-skill-design.md

@@ -0,0 +1,176 @@
+# Diseño: skill `catalyst-report-creator` + seed de instancias curadas
+
+**Fecha**: 2026-07-02
+**Estado**: aprobado (pendiente de implementación)
+**Vía**: directa (sin OpenSpec), tier Medium — TDD + `/code-review` para el código; la skill es documentación.
+
+## Objetivo
+
+Dotar a Claude Code (en este repo) de una guía para crear reportes a partir de una
+**necesidad de negocio en lenguaje natural** — "quiero un reporte que me muestre X,
+agrupado por Y, sacando la media de Z" — cubriendo tanto cubos como instancias, y con
+un protocolo de preguntas que cierre los gaps de información antes de escribir código.
+
+Dos entregables:
+
+1. **Skill** `catalyst-report-creator` en `.claude/skills/` (raíz del monorepo).
+2. **Refactor del seed de sistema** para que un cubo pueda declarar varias instancias
+   curadas (hoy el seed solo soporta una instancia mínima auto-generada por cubo).
+
+## Decisiones ya tomadas
+
+| Decisión | Elección | Motivo |
+| --- | --- | --- |
+| ¿Skill o CLAUDE.md? | Skill | CLAUDE.md es contexto siempre activo; esta guía es larga y bajo demanda |
+| Audiencia | Claude Code en este repo | Confirmado por el usuario |
+| Ubicación | `.claude/skills/` raíz (no `backend/`) | El trigger es una frase de negocio, anterior a tocar ficheros backend; mismo criterio que `catalyst-schema` |
+| Vía de instancias | Seed de sistema versionado | Confirmado por el usuario; las instancias ad-hoc por CRUD quedan fuera del alcance |
+| Refactor del seed | Ahora, junto a la skill | Sin él, la vía "instancia directa" documentaría un flujo que el código no permite (drift de nacimiento) |
+| Formalización | Directa, sin OpenSpec | Cambio pequeño y acotado; este doc deja el rastro escrito |
+
+## Parte 1 — La skill
+
+### Triaje en cascada (núcleo)
+
+Ante una necesidad de reporte, la IA inventaría lo existente (ficheros `*.cube.ts`,
+registros `ReportEngineModule.forFeature`, instancias de sistema declaradas) y baja
+por cuatro niveles, deteniéndose en el **primero** que aplique:
+
+| Nivel | Pregunta | Acción |
+| --- | --- | --- |
+| L1 | ¿Ya existe una instancia que da esta información? | Avisar al usuario ("ya existe, es X") y no crear nada salvo que insista |
+| L2 | ¿Hay un cubo cuya whitelist cubre dimensiones, medidas y filtros pedidos? | Crear solo la instancia (declaración en el seed) |
+| L3 | ¿Hay un cubo del mismo contexto que casi cubre la necesidad? | Evaluar extender el cubo vs crear uno nuevo (criterio abajo) |
+| L4 | No hay cubo relacionado | Crear cubo nuevo + instancia |
+
+**Criterio L3 (extender vs nuevo)**: se **extiende** si la necesidad comparte tabla de
+hechos y grano con el cubo existente y solo faltan dimensiones/medidas (cambio aditivo:
+no rompe instancias existentes). Se crea cubo **nuevo** si cambia la tabla de hechos, el
+grano, o exige joins que alterarían la cardinalidad de lo ya publicado (un join `many`
+nuevo puede convertir en insegura una medida `SUM`/`AVG` que hoy es válida).
+
+### Protocolo de entrevista (cierre de gaps)
+
+La skill enseña a traducir la frase de negocio a la terminología del motor
+("agrupado por" → dimensiones, "la media de" → medida `AVG`, "que solo muestre" →
+filtros) y define las preguntas obligatorias cuando falte información — una a una,
+siempre con propuesta por defecto:
+
+- Entidad / tabla de hechos (¿de qué BC son los datos?).
+- Agrupaciones (dimensiones) y agregaciones (medidas + función).
+- Filtros deseados (con la limitación actual: filtro de medida = solo `>=`).
+- Categoría del reporte (y color si es nueva → `CATEGORY_PALETTE`).
+- Visibilidad y tenant de la instancia.
+- `resultMode` (`client` con cap de filas vs `server` paginado).
+- Permisos requeridos del cubo.
+
+**Regla de oro**: la IA nunca inventa una columna de tenant, una cardinalidad de join
+ni un permiso. Si no puede verificarlo leyendo el código, pregunta.
+
+### Vía A — instancia sobre cubo existente
+
+- Componer la `selection` (`dimensions`, `measures`, `filters?`, `sort?`) validada
+  contra la whitelist del cubo con las mismas reglas que el runtime
+  (`validateReportSelection` + guard de cardinalidad), para fallar en diseño y no
+  en ejecución.
+- Declararla como instancia curada del cubo (ver Parte 2) — código versionado por PR.
+
+### Vía B — cubo nuevo
+
+Walkthrough anclado en `accounts-by-role.cube.ts` como plantilla anotada:
+
+- Naming de la key: `<bc>.<módulo>.<nombre>`.
+- Fichero en `backend/src/@app/<bc>/<módulo>/infrastructure/cubes/<nombre>.cube.ts`.
+- Checklist de `tenantColumns` para **cada** alias (tabla primaria + cada join),
+  incluidos pivots/lookups sin tenant propio (apuntan transitivamente al de la tabla
+  de hechos).
+- Decisión de cardinalidad (`one`/`many`) por join, con su implicación de seguridad
+  de datos (fan-out).
+- `requiredPermissions` solo con permisos ya seedados por el CRUD del BC dueño.
+- `display` 100 % serializable (nunca funciones; `cellRenderer` = clave de registry).
+- Registro en `ReportEngineModule.forFeature([...])` del módulo `@api` generado
+  (sección MANUALLY MAINTAINED).
+- Categoría nueva → añadirla a `CATEGORY_PALETTE`.
+
+### Verificación y gotchas
+
+- El boot valida el registro del cubo (falta un `tenantColumns` → la app no arranca);
+  arrancar el backend es el smoke mínimo.
+- Tabla de gotchas condensada (los 14 hallazgos de la exploración: tenant transitivo,
+  cardinalidad y SUM/AVG, `isArray`/`nullable` en tenant, filtros dimensión vs medida,
+  cap de `client` mode sin datos parciales, `hasTenant: false` con scoping hand-rolled
+  del catálogo, permisos custom no auto-seedados, time-grains sin ejemplo real, etc.).
+
+### Formato
+
+`SKILL.md` con frontmatter de triggers (frases de necesidad de reporte + identificadores
+técnicos: `ReportCube`, `definitionKey`, `selection`, `forFeature`…) siguiendo
+`catalyst-skill-creator`. Si el contenido crece, el detalle de la vía B puede ir a
+`references/`. Tras crearla: `catalyst-update-skill-registry`.
+
+## Parte 2 — Refactor del seed (instancias curadas declarables)
+
+### Problema
+
+`reporting-system-reports.seed.ts` hace find-or-create por `{ definitionKey, isSystem }`
+(sin `name`): una segunda instancia sobre el mismo cubo nunca se crearía. La limpieza
+de huérfanos borra por `definitionKey` no registrado, sin conocer instancias declaradas.
+
+### Diseño elegido
+
+- El cubo declara sus instancias curadas: campo opcional `systemReports?: CubeSystemReport[]`
+  en la interfaz `ReportCube` (`report-cube.types.ts`), con `name`, `description?` y
+  `selection`. Sin campo `visibility`: las filas de sistema ignoran visibility por diseño
+  del dominio (siempre públicas) — ofrecer el knob sería un no-op que sobre-expone
+  (hallazgo del code-review). Colocado junto al cubo: viaja por el token
+  `AURORA_REPORT` ya inyectado en el seeder — cero DI nueva.
+- **Validación al registro**: `validateCubeRegistration` valida cada `selection`
+  declarada contra la whitelist del propio cubo (dimensiones/medidas/filtros/sort) y
+  el guard de cardinalidad → fail-fast al boot, coherente con la filosofía del motor.
+- **Seeder**:
+  - Si el cubo declara `systemReports`, se seedean esas (find-or-create por
+    `definitionKey + name + isSystem`); la instancia mínima auto-generada solo se crea
+    cuando el cubo NO declara ninguna.
+  - Limpieza de huérfanos ampliada: borra filas `isSystem` cuyo `definitionKey` no está
+    registrado (comportamiento actual) **y** filas de un cubo registrado cuyo `name` ya
+    no está en el conjunto esperado (renombrados/retirados). Refinamientos del
+    code-review: la limpieza name-based de un cubo solo corre si su conjunto esperado se
+    seedeó con éxito en este boot (un fallo transitorio no puede dejar al cubo sin
+    reports); toda fila borrada limpia antes sus favoritos (el FK del pivot no tiene
+    cascade en BD); y `validateCubeRegistration` rechaza nombres duplicados dentro de
+    `systemReports` (name es la clave de identidad). Semántica explícita: las filas
+    `isSystem` son propiedad del código — el seed las converge; un renombre manual será
+    revertido en el siguiente boot.
+- Sin cambio de esquema de BD (solo lógica de seed + tipos del motor) — no aplica la
+  operator note de `DROP TABLE`.
+
+Alternativa descartada: token DI separado (`AURORA_SYSTEM_REPORT` + `forFeature` propio).
+Más ceremonia y separa la instancia de su cubo sin ganancia — la instancia curada
+pertenece conceptualmente al cubo.
+
+### Tests (TDD)
+
+- `validateCubeRegistration`: rechaza `systemReports` con ids fuera de whitelist y
+  medidas que violan cardinalidad; acepta declaraciones válidas.
+- Seeder: crea declaradas, no duplica en segundo boot, omite la mínima cuando hay
+  declaradas, limpia huérfanas por key y por name.
+
+Nota: el motor (`@aurora/modules/report-engine`) es hand-written puro (sin `@Auth` en
+las piezas a tocar), así que no aplica la limitación Jest/ESM de clases decoradas.
+
+## Fuera de alcance
+
+- Instancias ad-hoc de usuario vía CRUD/Monaco (existe, pero la skill no lo cubre).
+- Report builder visual (excluido explícitamente en el OpenSpec original).
+- IA embebida en el producto (posible reutilización futura del contenido, no ahora).
+- Operador configurable en filtros de medida (hoy solo `>=`; la skill lo documenta
+  como limitación, no lo cambia).
+
+## Riesgos
+
+- **Drift skill ↔ motor**: si el motor evoluciona (p. ej. operadores de filtro), la
+  skill queda desactualizada. Mitigación: la skill referencia rutas de ficheros como
+  fuente de verdad, no duplica firmas completas.
+- **Instalaciones existentes**: al declarar `systemReports` en un cubo que ya seedeó su
+  instancia mínima, la limpieza ampliada borrará la mínima (name distinto). Es el
+  comportamiento deseado (pre-producción), pero se documentará en el seed.

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

@@ -50,7 +50,10 @@ context: |
   - 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`.**
+    `.claude/skills/business-rules-guard/references/format.md` and `CLAUDE.md`.**
+  - **Do NOT "harmonize" the Harness Rules language mix either. It is
+    intentional and documented in
+    `.claude/skills/harness-rules-guard/references/format.md` and `CLAUDE.md`.**
 
   ## Lifecycle
 
@@ -124,13 +127,14 @@ context: |
   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
+  matching the pattern under the rule's paths. Every rule WITHOUT a `detect` 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.
+  messaging, with the agent applying judgment. Which rules are content-blocked is
+  read from `cliter/harness-rules-index.json` (`byId[<id>].detect` present or
+  absent), never from a list written in prose; today `HR-ACL-001` (the
+  `as unknown as` double cast) and `HR-DOCS-001` (rule-format content in the
+  `docs/` orientation maps) declare one. 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
 
@@ -238,8 +242,32 @@ rules:
       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 SPEC CONFORMITY verification task placed AFTER the last
+      implementation task and BEFORE the security-review task (when present) and
+      the final verification task. Run it in FRESH context, NOT by the
+      implementer, with a READ-ONLY verifier (Read/Grep/Glob plus Bash for
+      scoped tests — it never edits code). The verifier walks EVERY requirement
+      and scenario in the change's delta specs and classifies each one as
+      implemented, partial, or missing, citing evidence (file:line and the
+      covering test). Checked boxes in `tasks.md` are self-reported and do NOT
+      count as evidence. Any partial or missing requirement goes back to
+      implementation BEFORE the defect-review gate runs — completeness first,
+      then defect review. Skip only for Minor (trivial diff).
     - 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.
+      Complex change (two blind judges → orchestrator verifies every severe
+      finding → fix → one scoped re-judge; add `/code-review high` only when
+      the session runs in Framework mode); a single blind judge
+      (`judgment-day`, single-judge mode, two if the change touches an
+      authorization or data boundary) 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.
+    - If the change touches the SECURITY SURFACE — authentication/authorization
+      paths (`o-auth/`, `iam/`, guards, `@Auth`/permissions wiring), secrets or
+      sensitive configuration (SOPS, env), new public endpoints, file uploads,
+      raw queries, or crypto/token/session handling — include a security-review
+      task (`/security-review` over the change's diff, run in FRESH context, NOT
+      by the implementer) placed BEFORE the final verification task, regardless
+      of tier; confirmed findings are fixed before that gate runs. If the
+      security surface is NOT touched, do NOT add this task — the gate is
+      surface-based, not per-change.

package/dist/templates/monorepo/package.json

@@ -2,7 +2,7 @@
   "name": "aurora-catalyst",
   "version": "0.0.1",
   "private": true,
-  "packageManager": "pnpm@11.5.2+sha512.71c631e382066efc25625d5cf029075de07b61b37f6e27350fbd84b1bda5864c8c1967adc280776b45c30a715c0359a3be08fef42d5bb09e2b99029979692916",
+  "packageManager": "pnpm@11.24.0+sha512.bd27e345e976dcb0be0b7a1228217b049a817e21b1f355c90dbe7dc46671895a8bc1e6d06c24554505ea93ea0b45f489a27ec1bfbc8de6a9659fca0f16fa0000",
   "scripts": {
     "dev": "concurrently -n back,front -c blue,green \"pnpm back:dev\" \"pnpm front:dev\"",
     "back:dev": "pnpm --filter aurora-back start:dev",
@@ -16,7 +16,11 @@
     "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",
+    "db:generate": "pnpm --filter aurora-back db:generate",
+    "db:migrate": "pnpm --filter aurora-back db:migrate",
+    "db:check": "pnpm --filter aurora-back db:check",
+    "db:query": "pnpm --filter aurora-back db:query",
+    "format": "pnpm --filter aurora-back --filter aurora-front run format",
     "prepare": "husky || true",
     "br:generate": "tsx scripts/business-rules/generate-index.ts",
     "br:validate": "tsx scripts/business-rules/validate-catalog.ts",
@@ -25,7 +29,15 @@
     "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\""
+    "hr:lint-barrels": "tsx scripts/harness-rules/lint-barrels.ts",
+    "backlog:dispatch": "tsx scripts/backlog/dispatch.ts",
+    "backlog:watch": "tsx scripts/backlog/watch.ts",
+    "backlog:graph": "tsx scripts/backlog/graph-cli.ts",
+    "test:hooks": "tsx --test \".claude/hooks/**/*.test.ts\"",
+    "test:catalyst-regen": "node --import tsx --test \"scripts/catalyst/**/*.test.ts\"",
+    "test:skills-index": "node --import tsx --test \".claude/scripts/**/*.test.ts\"",
+    "test:catalog": "node --import tsx --test \"scripts/_catalog-runtime/**/*.test.ts\" \"scripts/harness-rules/**/*.test.ts\"",
+    "test:backlog": "node --import tsx --test \"scripts/backlog/**/*.test.ts\""
   },
   "devDependencies": {
     "@commitlint/cli": "^21.0.2",
@@ -35,6 +47,7 @@
     "ajv-formats": "^3.0.1",
     "concurrently": "^10.0.3",
     "cz-conventional-changelog": "^3.3.0",
+    "fast-glob": "^3.3.3",
     "gray-matter": "^4.0.3",
     "husky": "^9.1.7",
     "tsx": "^4.22.4"

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

@@ -17,7 +17,15 @@ allowBuilds:
   nx: true
   sharp: true
   unrs-resolver: true
+  yarn: true
 minimumReleaseAgeExclude:
   - concurrently@10.0.3
-  - '@spartan-ng/brain@0.0.1-alpha.707'
-  - '@spartan-ng/cli@0.0.1-alpha.707'
+  - '@spartan-ng/brain@0.0.1-alpha.711'
+  - '@spartan-ng/cli@0.0.1-alpha.711'
+  - '@angular/common@22.1.1'
+  - '@angular/compiler-cli@22.1.1'
+  - '@angular/compiler@22.1.1'
+  - '@angular/core@22.1.1'
+  - '@angular/forms@22.1.1'
+  - '@angular/platform-browser@22.1.1'
+  - '@angular/router@22.1.1'

package/dist/templates/monorepo/scripts/_catalog-runtime/README.md

@@ -0,0 +1,30 @@
+# `_catalog-runtime`
+
+Shared runtime for the markdown-driven rule catalogs in this repo:
+
+- **Business Rules** (`scripts/business-rules/`, catalog under `cliter/<bc>/business-rules/*.md`).
+- **Harness Rules** (`scripts/harness-rules/`, catalog under `cliter/harness-rules/*.md` and `cliter/<bc>/harness-rules/*.md`).
+
+It holds ONLY logic that is genuinely common to every catalog. Each catalog CLI
+(`scripts/business-rules/`, `scripts/harness-rules/`) shrinks to config + a call
+into these modules; bug fixes land here once and both catalogs benefit:
+
+- `types.ts` — catalog-neutral structural types (`ParsedFile`, `ParsedRule`, `CatalogIndex`, `IndexedRule`) and the single-source const maps `RULE_STATE`, `RULE_SEVERITY`, `RULE_PREFIX` (family prefixes `BR`/`HR`). `BaseFrontmatter` is the real base both `FileFrontmatter` and `HrFrontmatter` extend.
+- `repo-root.ts` — `findRepoRoot()` (locates the `aurora-catalyst` repo root by walking up to its `package.json`).
+- `frontmatter.ts` — `normalizeFrontmatter()` (coerces gray-matter `Date` values back to ISO `YYYY-MM-DD` strings).
+- `parse.ts` — `parseCatalog<TFrontmatter>({ repoRoot, globs })` (globs markdown, parses frontmatter, slices per-rule bodies and metadata tables). The rule-heading regex is anchored to the `RULE_PREFIX` union and accepts em-dash OR spaced hyphen; `detectHyphenHeadings()` lets validators WARN on the non-canonical hyphen form.
+- `glob.ts` — `globToRegex()`, `rulesByPath()`, `hasGlobMetachars()` (the glob-metachar test that lets path existence checks skip patterns).
+- `build-index.ts` — `buildIndex({ parsed, readFields, isFileInstalled, totalFilesMode })` and `buildHumanIndex(index, { title, generateCmd })`. Catalog behavior is injected via the `readFields` (per-field discriminated result) and `isFileInstalled` callbacks. Emits byte-identical JSON+MD across catalogs.
+- `validate.ts` — `runCatalogValidation({ schema, globs, extraChecks })` (AJV frontmatter, unique IDs, rule metadata, line-anchored `extractSection`, `validateImplementaPaths`). Returns the exit code. `extraChecks` injects catalog-specific validators.
+- `check-core.ts` — `runCheck({ indexPath, generateCmd, ruleIdRegex, messages })` plus the git plumbing (`workingTreeFiles` with porcelain `-z` rename handling, `defaultBaseBranch`, `gitDiffFiles`, `prFiles`) and `loadIndex` (guarded `JSON.parse`).
+- `cli.ts` — `runCatalogMain(fn, label)` (one top-level guard for sync+async leaf scripts).
+- `index.ts` — barrel re-exporting the public runtime symbols.
+
+The shared frontmatter schema definitions live in `docs/_catalog-schema-base.json`
+(`$defs` referenced via `$ref` from each catalog's `_schema.json`); AJV loads the
+base via `addSchema` before compiling so the cross-file `$ref` resolves.
+
+What does NOT belong here:
+
+- Catalog-specific globs, frontmatter schemas, scope filters, rule-id regexes, or message wording — those are passed in as config from each catalog's own CLI.
+- Unrelated utilities. This directory is for catalog runtime only; do not turn it into a generic `scripts/_shared/`.