@aurorajs.dev/catalyst-cli 1.0.2 → 2.0.0

package/dist/templates/monorepo/docs/AURORA-CATALYST-BRIEF.md

@@ -0,0 +1,253 @@
+# Aurora Catalyst — Brief de capacidades para estimación
+
+Este documento describe qué proporciona la plataforma Aurora Catalyst **ya construido**, para
+estimar proyectos con precisión. La regla central: cada requisito del cliente cae en uno de tres
+buckets de coste — **generado** (coste ≈ horas), **plataforma** (coste ≈ configuración) o
+**custom** (coste real de desarrollo). Estimar sin esta clasificación produce errores en ambas
+direcciones: presupuestar como desarrollo desde cero lo que el generador emite en minutos, o
+asumir gratis lo que en realidad es lógica de negocio a medida.
+
+## Cómo usar este documento
+
+1. Lee el PRD / requisitos del cliente.
+2. Descompón cada requisito en piezas: entidades CRUD, APIs, pantallas, informes, integraciones, flujos.
+3. Clasifica cada pieza en bucket A (generado), B (plataforma) o C (custom) usando las secciones siguientes.
+4. Aplica la tabla de calibración del final; el esfuerzo del proyecto es la suma del bucket C más los ajustes de A y B.
+5. Revisa los "Avisos para no estimar mal" antes de cerrar la cifra.
+
+## Qué es Aurora Catalyst
+
+Plataforma de desarrollo de aplicaciones de gestión empresarial: un **CLI generador de código**
+(schema-first: el modelo de dominio se declara en YAML y el CLI genera backend y frontend
+completos) más un **conjunto de módulos de plataforma** listos para usar (identidad, seguridad,
+reporting, colas, integración SAP…). El código generado es código real del proyecto — editable,
+regenerable y reconciliable — no una caja negra.
+
+| Capa | Stack |
+| --- | --- |
+| Backend | NestJS 12, Drizzle ORM, PostgreSQL, GraphQL + REST, Vitest/Supertest |
+| Frontend | Angular (standalone, signals), Spartan UI, Tailwind 4, Apollo GraphQL, TanStack Table |
+| Arquitectura | Hexagonal / DDD por bounded contexts; monorepo pnpm |
+| Infra | SOPS (secretos), despliegue por ramas de entorno vía CI/CD |
+
+## Bucket A — Lo que genera el CLI (coste ≈ horas por módulo)
+
+Un módulo se declara en un fichero `*.aurora.yaml` y `catalyst generate` emite backend y frontend
+completos. Definir la entidad + generar + ajustar textos es trabajo de horas, no de días.
+
+### Lo que expresa el esquema YAML
+
+- **Tipos de campo**: id, varchar, text, int/smallint/bigint, decimal, float, boolean, date,
+  timestamp, enum, json/jsonb, blob, char, array, `password` (hash bcrypt automático al escribir,
+  oculto al leer) y `encrypted`.
+- **Relaciones**: one-to-one, one-to-many, many-to-one y many-to-many con tabla pivote generada
+  (la pivote admite sus propios campos, APIs y flags).
+- **Índices**: simples, únicos y compuestos.
+- **Flags de módulo**: multi-tenant (`hasTenant`), auditoría (`hasAuditing`), OAuth (`hasOAuth`),
+  entidades con traducción por idioma (`isI18n` con tabla companion).
+- **Presentación**: widget de formulario por campo (select, search-select, async-search,
+  multi-select, grids maestro-detalle), agrupación en tabs/grupos, ancho de campo, ocultación
+  en lista/detalle, icono y modo de detalle (página o diálogo).
+- **Recorte**: operaciones o ficheros excluibles de la generación.
+
+### Backend generado por módulo
+
+- **API CRUD completa por partida doble**: controladores REST y resolvers GraphQL para el
+  vocabulario cerrado de operaciones — count, create, createBatch, delete, find, findById, get,
+  paginate, update, updateById, upsert, max/min/sum.
+- Un handler + service de aplicación por operación (arquitectura hexagonal, listos para insertar
+  lógica de negocio).
+- **Validación automática** derivada del YAML (longitudes, nullabilidad, enums, formatos):
+  se aplica antes de entrar al handler; también formatea la salida (p. ej. password nunca se expone).
+- Modelo Drizzle + repositorio, fragmento de esquema GraphQL, DTOs.
+- **Seeds de permisos IAM**: cada módulo registra sus permisos automáticamente y las APIs quedan
+  protegidas con el decorador de autorización.
+- Tests e2e de aceptación opcionales (flag del generador).
+
+### Frontend generado por módulo
+
+- **Pantalla de listado**: data-table con ordenación, paginación servidor, búsqueda, filtros,
+  export, configuración de columnas y celdas tipadas (booleanos, relaciones resueltas).
+- **Formulario de detalle** con validaciones espejo del YAML, layout en grid de 12 columnas,
+  tabs/grupos, y todos los widgets declarados (selects asíncronos, grids de selección múltiple…).
+- Modo maestro-detalle embebido (entidad hija gestionada dentro del formulario del padre).
+- Entrada de navegación en el sidebar, breadcrumbs, resolvers de ruta que precargan opciones
+  de relaciones, operaciones GraphQL tipadas y claves i18n (en/es).
+
+### Additional APIs (semi-generado)
+
+Para verbos que no son CRUD (p. ej. "reset password", "heredar permisos") el YAML declara método
+HTTP + ruta + tipo de resolver, y el CLI genera el andamiaje (controller + resolver + handler
+vacío). **La lógica interna del handler es siempre bucket C.**
+
+### Ciclo de vida del proyecto (CLI)
+
+| Comando | Qué hace |
+| --- | --- |
+| `catalyst new` | Crea el monorepo completo de una aplicación nueva |
+| `catalyst generate back/front module` | Genera un módulo desde su YAML |
+| `catalyst origin` | Reconcilia regeneraciones con código editado a mano (diff/accept/reject) |
+| `catalyst env` | Cifra/descifra ficheros de entorno con SOPS |
+| `catalyst provision` / `deploy` | Provisiona hosting/DNS/CI-CD y despliega por entorno |
+| `catalyst sheets` | Sincroniza esquemas con Google Sheets (modelado con el cliente) |
+
+La regeneración convive con el código a mano: los ficheros modificados nunca se pisan; el CLI
+deja una propuesta `.origin` al lado para reconciliar. Personalizar un módulo generado no lo
+"rompe" ni obliga a mantenerlo fuera del generador.
+
+## Bucket B — Módulos de plataforma (coste ≈ configuración)
+
+Funcionalidad ya construida, con pantallas de administración incluidas. Si el requisito encaja
+en lo listado, el coste es parametrización y datos, no desarrollo.
+
+### IAM — identidad y autorización
+
+- Cuentas (usuario o servicio), usuarios con 2FA TOTP y flujo de recuperación de contraseña,
+  roles, permisos finos por bounded context, etiquetas y tenants jerárquicos.
+- RBAC de alto rendimiento: permisos denormalizados en la cuenta (autorización O(1) por request).
+- Proteger una API nueva = anotar con el permiso, ya sembrado por el generador. El frontend
+  se gatea con las mismas claves de permiso.
+- Multi-tenancy: cuentas en varios tenants, jerarquía con descendientes, scoping en consultas.
+- CRUD de administración completo para todas las entidades + bootstrap idempotente de admin inicial.
+
+### OAuth — servidor de autorización
+
+- Grant types: authorization_code, client_credentials, password y refresh_token.
+- Modelo application/client/scope (un scope mapea a roles IAM), tokens JWT RS256 revocables e
+  inmutables, TTLs configurables por cliente. UI de administración completa.
+
+### Tools — configuración, base de datos y campos personalizados
+
+- **key-value**: configuración runtime sin redeploy, 9 tipos incluido SECRET (cifrado asimétrico,
+  nunca cacheado), activable/desactivable.
+- **procedures**: funciones y triggers de Postgres versionados con detección de drift por hash.
+- **migrations**: migraciones SQL declarativas con orden de ejecución y estado.
+- **custom fields**: campos personalizados definibles en runtime, sin redeploy ni cambio de
+  esquema. Modelo de cuatro piezas: **grupos** (secciones visuales reutilizables entre
+  entidades), **definiciones** tipadas (TEXT, NUMBER, DATE, BOOLEAN, SELECT, MULTISELECT; flags
+  required/searchable/filterable, escala decimal, `key` inmutable), **opciones** de catálogo
+  para los selects (código inmutable) e **inventario de entidades** habilitadas. Etiquetas
+  traducibles (i18n embebido) y UI de administración completa para las cuatro piezas.
+  **La captura de valores en entidades de negocio no está operativa hoy — ver avisos.**
+
+### Dashboard — cuadros de mando
+
+- Layouts personalizables por usuario (grid drag & drop persistido).
+- Catálogo de widgets con **tres arquetipos declarativos** (stat, chart, table): un widget nuevo
+  sobre datos existentes se declara con una factoría + fuente de datos GraphQL + permiso; horas,
+  no días. Visibilidad gateada por permisos automáticamente.
+
+### Reporting — motor de informes
+
+- Modelo de dos capas: **cubo** (whitelist en código de tablas, joins, dimensiones y medidas,
+  revisado y con scoping multi-tenant obligatorio) e **informe** (selección guardada sobre un cubo,
+  creable desde la UI).
+- Catálogo de informes con favoritos y categorías, visor con export tipo CSV/XLSX, informes de
+  sistema curados, ejecución cliente (hasta 50.000 filas) o servidor paginada, pool de BD read-only dedicado.
+- Coste: informe nuevo sobre cubo existente ≈ configuración; **cubo nuevo = desarrollo acotado** (bucket C).
+
+### Hub — SSO y launcher de aplicaciones
+
+- Registro central de aplicaciones satélite con SSO OAuth 2.0 Authorization Code (RS256/JWKS)
+  y sesión compartida (saltar entre apps sin re-login).
+- Alta de una app = una pantalla: provisiona automáticamente application/client/scopes OAuth y
+  entrega las credenciales una única vez. Una app satélite se conecta **solo con variables de
+  entorno**, sin desarrollo adicional. Incluye launchpad para el usuario final.
+
+### Queue Manager — colas de trabajo
+
+- Colas BullMQ/Redis con registro de jobs (estados waiting/active/completed/failed/delayed/paused,
+  etiquetas filtrables).
+- UI de monitorización: lista y detalle de colas, inspector de payload de jobs, polling en vivo,
+  filtrado de fallidos. Los **procesadores de jobs** (la lógica que ejecuta cada job) son bucket C.
+
+### SAP Integration — sincronización con S/4HANA
+
+- Sync event-driven sin desarrollo ABAP: SAP notifica por CloudEvents (Event Mesh) y Aurora
+  recupera el dato por OData (push-then-pull); fallback por polling disponible.
+- Event log idempotente con dead-letter, estado de sincronización por entidad y almacén unificado
+  de errores (distingue "SAP inaccesible" de "error de mapeo"). Tres pantallas de monitorización read-only.
+- Conexión public-cloud (OAuth2) u on-premise (basic auth) por configuración.
+- Piloto implementado: Business Partner con réplica local. **Cada objeto SAP adicional requiere
+  su projector** (mapeo OData → réplica): desarrollo acotado, bucket C.
+
+### Capacidades transversales
+
+| Capacidad | Qué incluye |
+| --- | --- |
+| Auditoría | Snapshot antes/después por operación CRUD con soporte de rollback + log de comunicaciones HTTP externas; se activa por flag en el YAML |
+| i18n | Backend y frontend en inglés y español; entidades traducibles por idioma vía YAML |
+| Storage | Ficheros/adjuntos sobre Azure Blob con URLs firmadas (SAS) |
+| Mailer | Envío SMTP (usado p. ej. en recuperación de contraseña) |
+| Theming | Paletas y branding configurables en frontend |
+| Query DSL | Todas las APIs de listado aceptan un contrato común de filtrado/orden/paginación/agregación, mismo en back y front |
+
+## Bucket C — Lo que siempre es custom (el esfuerzo real del proyecto)
+
+- Lógica de negocio: reglas dentro de handlers, cálculos, workflows, máquinas de estado.
+- Lógica de los additional APIs y de los procesadores de jobs.
+- Pantallas fuera del patrón listado + detalle (wizards, editores visuales, portales públicos).
+- Integraciones con sistemas que no sean SAP S/4 (o mecanismos distintos al event-driven descrito).
+- Projectors de nuevos objetos SAP; cubos nuevos de reporting; widgets no cubiertos por los tres arquetipos.
+- Webhooks salientes (ver avisos), notificaciones push, tiempo real.
+- Migración de datos desde sistemas legados.
+
+## Calibración de esfuerzo
+
+Valores del equipo (julio 2026). Las horas asumen desarrollo con Claude Code sobre la plataforma
+e incluyen implementación, ajuste fino y revisión de la pieza. La gestión de proyecto, reuniones
+y margen comercial NO van dentro: se aplican como coeficiente global sobre el total.
+
+### Escala principal: módulos CRUD
+
+Clasifica cada entidad/pantalla del PRD en un nivel. El número de campos fija el punto de
+partida (T1–T3); las relaciones con proceso, la personalización de pantallas y salirse del
+código generado escalan a T4–T6. Ante la duda entre dos niveles, toma el superior.
+
+| Nivel | Criterios | Esfuerzo |
+| --- | --- | --- |
+| **T1 — CRUD simple** | 2–5 campos, sin relaciones relevantes, pantallas generadas tal cual | 4 h |
+| **T2 — CRUD medio** | 6–10 campos | 8 h |
+| **T3 — CRUD complejo** | 10–20 campos | 16 h |
+| **T4 — CRUD con relaciones y pantallas personalizadas** | ≥15 campos, relaciones many-to-many con procesos complejos, personalización de las pantallas generadas | 24 h |
+| **T5 — CRUD con procesos complejos fuera del codegen** | Relaciones + pantallas personalizadas + flujos/rutas fuera del patrón generado de Aurora | 40 h |
+| **T6 — Pantalla extremadamente compleja** | Editores, wizards o pantallas a medida de alta complejidad | 56 h |
+
+### Piezas no CRUD
+
+Derivadas por complejidad relativa de la escala anterior (columna "Base") — validar con datos
+reales cuando existan.
+
+| Pieza | Esfuerzo | Base |
+| --- | --- | --- |
+| Widget de dashboard declarativo (stat/chart/table) | 4 h | ≈ T1 |
+| Informe sobre cubo existente | 2 h | configuración |
+| Cubo de reporting nuevo + informe de sistema | 16 h | ≈ T3 |
+| Additional API (andamiaje + lógica media) | 8 h | ≈ T2 |
+| Regla de negocio en handler (validación cruzada, cálculo) | 4 h | ≈ T1 |
+| Cola nueva + procesador de jobs | 16 h | ≈ T3 |
+| Objeto SAP nuevo (projector + réplica + monitorización) | 24 h | ≈ T4 |
+| App satélite conectada al Hub (SSO) | 2 h | configuración |
+| Setup de proyecto nuevo (new + provision + deploy + IAM base) | 16 h | ≈ T3 |
+
+## Avisos para no estimar mal
+
+- **Webhooks**: el módulo está declarado en el esquema pero **no implementado**; cualquier
+  requisito de webhooks salientes es desarrollo nuevo (bucket C), no configuración.
+- **Custom fields**: la mitad administrativa (grupos, definiciones, opciones, entidades) es
+  funcional y estable; la captura de valores extremo a extremo **no está activa**. El generador
+  ya emite la tabla satélite de valores (flag `hasCustomFields`) y existe un formulario genérico
+  de captura, pero falta el handler de lectura de valores y hoy ninguna entidad del producto los
+  captura (el piloto sobre IamTag se revirtió). Habilitar custom fields en una entidad real es
+  desarrollo acotado (bucket C), no configuración.
+- **Idiomas**: hoy se distribuyen inglés y español; añadir un idioma es trabajo de traducción +
+  alta, no de arquitectura.
+- **OIDC Discovery**: el SSO del Hub usa configuración explícita por variables de entorno; no hay
+  `.well-known/openid-configuration`. Integrar terceros que lo exijan es bucket C.
+- **Reporting en modo cliente**: tope de 50.000 filas por diseño; volúmenes mayores usan modo
+  servidor paginado o export.
+- **La UI de administración generada es de back-office**: funcional y consistente, pero si el
+  cliente espera una experiencia de producto a medida (público final, branding fuerte), esas
+  pantallas son bucket C.
+- **El generador no estima la migración de datos**: cargar datos existentes del cliente es
+  siempre una partida propia.

package/dist/templates/monorepo/docs/_catalog-schema-base.json

@@ -14,7 +14,7 @@
       "type": "array",
       "minItems": 1,
       "uniqueItems": true,
-      "description": "Search terms (deliberately bilingual). Used by the conflict detector and inject-rules-context hook to find relevant rules from a prompt.",
+      "description": "Search terms (deliberately bilingual). Used by the conflict detector and inject-prompt-context hook to find relevant rules from a prompt.",
       "items": {
         "type": "string",
         "minLength": 1

package/dist/templates/monorepo/docs/business-rules/ARCHITECTURE.md

@@ -1,9 +1,11 @@
 # Business Rules — Architecture
 
 > Documento técnico que explica **cada pieza** del sistema de business rules y
-> **cómo se relacionan entre sí**. Para uso operativo (cómo añadir reglas,
-> cómo correr los comandos), ver el [`README.md`](./README.md). Para
-> migración a otros repos, ver [`MIGRATION.md`](./MIGRATION.md).
+> **cómo se relacionan entre sí**. Para el mapa de orientación del catálogo (qué
+> es, dónde vive cada pieza, tabla de comandos), ver el
+> [`README.md`](./README.md); para el procedimiento de añadir, derogar o
+> modificar reglas, [`.claude/skills/business-rules-guard/references/workflow.md`](../../.claude/skills/business-rules-guard/references/workflow.md).
+> Para migración a otros repos, ver [`MIGRATION.md`](./MIGRATION.md).
 
 ---
 
@@ -72,8 +74,7 @@ hermanas del mismo agregado.
 
 **Contenido**: frontmatter file-level (BC, agregados, paths, keywords) +
 body con secciones `## BR-<ID> — <título>`. Detalle exhaustivo del formato
-en [`README.md`](./README.md) y en
-[`.claude/skills/business-rules-guard/references/format.md`](../../.claude/skills/business-rules-guard/references/format.md).
+en [`.claude/skills/business-rules-guard/references/format.md`](../../.claude/skills/business-rules-guard/references/format.md).
 
 ---
 
@@ -150,7 +151,7 @@ con secciones; un parser markdown + sets de validación es más natural.
 - `check.ts` (los 4 modos).
 - `promote.ts` (busca dónde vive la regla a derogar).
 - `validate-citations.ts` (cruza `@rule` con `byId`).
-- **Hook `inject-rules-context.ts`** (matching del prompt vs reglas).
+- **Hook `inject-prompt-context.ts`** (matching del prompt vs reglas).
 
 **Cuándo se regenera**:
 
@@ -309,7 +310,7 @@ explícitamente.
 
 **Cuándo corre**: al iniciar cualquier sesión de Claude Code.
 
-#### `UserPromptSubmit` — `inject-rules-context.ts`
+#### `UserPromptSubmit` — `inject-prompt-context.ts`
 
 **Cuándo corre**: ANTES de cada prompt del usuario.
 
@@ -501,7 +502,8 @@ de defensa contra que Claude se invente convenciones distintas o
 ## Escenarios operativos completos
 
 > Esta sección describe **escenarios E2E** del sistema. Los escenarios A y B coinciden con
-> los **Workflows A y B** documentados en `README.md` (acciones sobre el catálogo); el
+> los **Workflows A y B** documentados en
+> [`.claude/skills/business-rules-guard/references/workflow.md`](../../.claude/skills/business-rules-guard/references/workflow.md) (acciones sobre el catálogo); el
 > escenario D es una manifestación del Workflow C. Los escenarios C y E son casos de uso
 > operativos (consulta, audit) que no se asocian a un workflow de modificación del catálogo.
 
@@ -647,7 +649,7 @@ Todos los archivos creados por el sistema (excluyendo las reglas en sí):
 .
 ├── docs/
 │   └── business-rules/
-│       ├── README.md                                    ← guía operativa
+│       ├── README.md                                    ← mapa de orientación
 │       ├── ARCHITECTURE.md                              ← este documento
 │       ├── MIGRATION.md                                 ← portabilidad a otros repos
 │       ├── _schema.json                                 ← JSON Schema del frontmatter
@@ -671,7 +673,7 @@ Todos los archivos creados por el sistema (excluyendo las reglas en sí):
 ├── .claude/
 │   ├── settings.json                                    ← (modificado) hook UserPromptSubmit
 │   ├── hooks/
-│   │   └── inject-rules-context.ts                      ← inyecta reglas relevantes
+│   │   └── inject-prompt-context.ts                      ← inyecta reglas relevantes
 │   ├── commands/
 │   │   └── business-rules/
 │   │       ├── promote.md                               ← /business-rules:promote
@@ -724,7 +726,8 @@ Todos los archivos creados por el sistema (excluyendo las reglas en sí):
 **Día a día**:
 
 - Cualquier cambio que toque dominio sigue el Workflow A (vía OpenSpec; ver
-  `README.md` o el escenario A más arriba).
+  `.claude/skills/business-rules-guard/references/workflow.md` o el escenario A
+  más arriba).
 - La pre-commit hook mantiene el índice sincronizado y valida estructura.
 - El CI estructural valida cada PR.
 

package/dist/templates/monorepo/docs/business-rules/INDEX.md

@@ -2,21 +2,100 @@
 
 > Generado automáticamente. **No editar a mano**. Regenera con `pnpm br:generate`.
 
-- Generado: `2026-06-09T07:56:35.978Z`
-- Reglas totales: **7**
-  - Activas: 7
-  - Derogadas: 0
+- Generado: `1970-01-01T00:00:00.000Z`
+- Reglas totales: **86**
+  - Activas: 75
+  - Derogadas: 11
   - Propuestas: 0
-- Archivos: 2
+- Archivos: 25
 
 ## Catálogo
 
 | ID | Título | BCs | Agregados | Estado | Severidad | Last updated | Archivo |
 | -- | ------ | --- | --------- | ------ | --------- | ------------ | ------- |
+| `BR-BPP-001` | Provisión atómica del IamTenant hijo al crear un business-partner | business-partner-portal | business-partner | `active` | `blocking` | 2026-07-07 | [link](../../cliter/business-partner-portal/business-rules/business-partner.md) |
+| `BR-BPP-002` | Deprovisión atómica en cascada al borrar un business-partner | business-partner-portal | business-partner | `active` | `blocking` | 2026-07-07 | [link](../../cliter/business-partner-portal/business-rules/business-partner.md) |
+| `BR-BPP-003` | El flag isUser gobierna el ciclo de vida de la cuenta del contacto | business-partner-portal | partner-contact | `active` | `blocking` | 2026-09-16 | [link](../../cliter/business-partner-portal/business-rules/partner-contact.md) |
+| `BR-BPP-004` | Unicidad del contacto principal (isPrincipal) por business-partner | business-partner-portal | partner-contact | `active` | `blocking` | 2026-09-16 | [link](../../cliter/business-partner-portal/business-rules/partner-contact.md) |
+| `BR-BPP-005` | El tenant del business-partner destino se verifica contra el alcance del llamante antes de provisionar | business-partner-portal | partner-contact | `active` | `blocking` | 2026-09-16 | [link](../../cliter/business-partner-portal/business-rules/partner-contact.md) |
+| `BR-BPP-SUPPLIER-DOCUMENT-001` | Transición de validación restringida a origen UPLOADED | business-partner-portal | supplier-document | `active` | `blocking` | 2026-08-03 | [link](../../cliter/business-partner-portal/business-rules/supplier-document.md) |
+| `BR-BPP-SUPPLIER-DOCUMENT-002` | Transición de recuperación restringida a origen REJECTED con limpieza de `rejectionNotes` | business-partner-portal | supplier-document | `active` | `blocking` | 2026-08-03 | [link](../../cliter/business-partner-portal/business-rules/supplier-document.md) |
+| `BR-BPP-SUPPLIER-DOCUMENT-003` | Cardinalidad 1:1 documento↔factura de compra | business-partner-portal | supplier-document | `active` | `blocking` | 2026-08-03 | [link](../../cliter/business-partner-portal/business-rules/supplier-document.md) |
+| `BR-BPP-SUPPLIER-DOCUMENT-004` | Los archivos de supplier-document se almacenan siempre como privados y se leen mediante una URL firmada de expiración corta acuñada por lectura (nunca persistida). | business-partner-portal | supplier-document | `active` | `blocking` | 2026-08-03 | [link](../../cliter/business-partner-portal/business-rules/supplier-document.md) |
+| `BR-COMMON-LANG-001` | Los UUIDs del catálogo de idiomas son estables e inmutables | common | lang | `active` | `blocking` | 2026-07-17 | [link](../../cliter/common/business-rules/lang.md) |
+| `BR-COMMON-LANG-002` | `environment.lang` gobierna los idiomas de la instalación en build-time | common | lang | `active` | `informational` | 2026-07-17 | [link](../../cliter/common/business-rules/lang.md) |
+| `BR-DASHBOARD-LAYOUT-001` | Un `DashboardLayout` pertenece a una account XOR a un role: propietario único, nunca ambos ni ninguno | dashboard | layout | `active` | `blocking` | 2026-06-22 | [link](../../cliter/dashboard/business-rules/layout.md) |
+| `BR-HUB-APP-001` | Provisión OAuth atómica al registrar un HubApp | hub, o-auth, iam | app, application, client, application-client, bounded-context, permission | `derogated` | `blocking` | 2026-09-03 | [link](../../cliter/hub/business-rules/app.md) |
+| `BR-HUB-APP-002` | El create-app del HUB es el único dueño de la provisión OAuth de satélites | hub, o-auth, iam | app, application, client, application-client, bounded-context, permission | `derogated` | `blocking` | 2026-09-03 | [link](../../cliter/hub/business-rules/app.md) |
+| `BR-HUB-APP-003` | El secret de OAuthApplication se genera en backend y se expone una sola vez | hub, o-auth, iam | app, application, client, application-client, bounded-context, permission | `active` | `blocking` | 2026-09-03 | [link](../../cliter/hub/business-rules/app.md) |
+| `BR-HUB-APP-004` | El launchpad y los endpoints de preferencias requieren `hub.launchpad.access` | hub, o-auth, iam | app, application, client, application-client, bounded-context, permission | `active` | `blocking` | 2026-09-03 | [link](../../cliter/hub/business-rules/app.md) |
+| `BR-HUB-APP-005` | El input de `reorder-apps` está acotado: máx 200 entradas, sin duplicados, UUIDs válidos | hub, o-auth, iam | app, application, client, application-client, bounded-context, permission | `derogated` | `blocking` | 2026-09-03 | [link](../../cliter/hub/business-rules/app.md) |
+| `BR-HUB-APP-006` | Dueño único bidireccional de la identidad OAuth de satélites | hub, o-auth, iam | app, application, client, application-client, bounded-context, permission | `active` | `blocking` | 2026-09-03 | [link](../../cliter/hub/business-rules/app.md) |
+| `BR-HUB-APP-007` | Deprovisión OAuth atómica al borrar un HubApp | hub, o-auth, iam | app, application, client, application-client, bounded-context, permission | `derogated` | `blocking` | 2026-09-03 | [link](../../cliter/hub/business-rules/app.md) |
+| `BR-HUB-APP-008` | Asimetría deliberada del borrado: historial HubApp vs credenciales OAuth hard-deleted | hub, o-auth, iam | app, application, client, application-client, bounded-context, permission | `active` | `informational` | 2026-09-03 | [link](../../cliter/hub/business-rules/app.md) |
+| `BR-HUB-APP-009` | Provisión atómica de siete escrituras al registrar un HubApp (con guard de colisión) | hub, o-auth, iam | app, application, client, application-client, bounded-context, permission | `derogated` | `blocking` | 2026-09-03 | [link](../../cliter/hub/business-rules/app.md) |
+| `BR-HUB-APP-010` | Deprovisión atómica ampliada al borrar un HubApp (con eliminación IAM) | hub, o-auth, iam | app, application, client, application-client, bounded-context, permission | `derogated` | `blocking` | 2026-09-03 | [link](../../cliter/hub/business-rules/app.md) |
+| `BR-HUB-APP-011` | Filtro de visibilidad server-side del launchpad por `<code>.access` | hub, o-auth, iam | app, application, client, application-client, bounded-context, permission | `derogated` | `blocking` | 2026-09-03 | [link](../../cliter/hub/business-rules/app.md) |
+| `BR-HUB-APP-012` | El `code` es el namespace: charset estricto y unicidad forzada en registro | hub, o-auth, iam | app, application, client, application-client, bounded-context, permission | `derogated` | `blocking` | 2026-09-03 | [link](../../cliter/hub/business-rules/app.md) |
+| `BR-HUB-APP-013` | `code` y `applicationId` son inmutables en el update de HubApp: el handler los elimina del payload (strip silencioso) antes de calcular el delta, y la UI deshabilita `code` en modo edición. | hub, o-auth, iam | app, application, client, application-client, bounded-context, permission | `active` | `blocking` | 2026-09-03 | [link](../../cliter/hub/business-rules/app.md) |
+| `BR-HUB-APP-014` | Provisión atómica de siete escrituras al registrar un HubApp (permiso `hub.app.<code>.access`) | hub, o-auth, iam | app, application, client, application-client, bounded-context, permission | `active` | `blocking` | 2026-09-03 | [link](../../cliter/hub/business-rules/app.md) |
+| `BR-HUB-APP-015` | Deprovisión atómica ampliada al borrar un HubApp (permiso `hub.app.<code>.access`) | hub, o-auth, iam | app, application, client, application-client, bounded-context, permission | `active` | `blocking` | 2026-09-03 | [link](../../cliter/hub/business-rules/app.md) |
+| `BR-HUB-APP-016` | Filtro de visibilidad server-side del launchpad por `hub.app.<code>.access` | hub, o-auth, iam | app, application, client, application-client, bounded-context, permission | `active` | `blocking` | 2026-09-03 | [link](../../cliter/hub/business-rules/app.md) |
+| `BR-HUB-APP-017` | El `code` es el namespace: charset estricto y unicidad forzada en registro (`hub.app.<code>.access`) | hub, o-auth, iam | app, application, client, application-client, bounded-context, permission | `active` | `blocking` | 2026-09-03 | [link](../../cliter/hub/business-rules/app.md) |
+| `BR-HUB-APP-ACCOUNT-001` | La preferencia pertenece exclusivamente a la cuenta autenticada | hub, iam | app-account, app, account | `active` | `blocking` | 2026-06-25 | [link](../../cliter/hub/business-rules/app-account.md) |
+| `BR-HUB-APP-ACCOUNT-002` | La fila de preferencia se crea de forma perezosa y nunca se duplica | hub, iam | app-account, app, account | `active` | `blocking` | 2026-06-25 | [link](../../cliter/hub/business-rules/app-account.md) |
+| `BR-HUB-APP-ACCOUNT-003` | Alternar el favorito resetea el `sort` personal al cambiar de grupo | hub, iam | app-account, app, account | `derogated` | `informational` | 2026-06-25 | [link](../../cliter/hub/business-rules/app-account.md) |
+| `BR-IAM-ACCOUNT-001` | `dPermissions` se recalcula en cada emisión de token | iam, o-auth | account, tenant, tenant-account, application | `active` | `blocking` | 2026-09-16 | [link](../../cliter/iam/business-rules/account.md) |
+| `BR-IAM-ACCOUNT-002` | El tipo de una cuenta no cambia después de crearla | iam, o-auth | account, tenant, tenant-account, application | `active` | `blocking` | 2026-09-16 | [link](../../cliter/iam/business-rules/account.md) |
+| `BR-IAM-ACCOUNT-003` | Las columnas derivadas de cuenta son de solo lectura para el cliente | iam, o-auth | account, tenant, tenant-account, application | `active` | `blocking` | 2026-09-16 | [link](../../cliter/iam/business-rules/account.md) |
+| `BR-IAM-ACCOUNT-004` | `dTenants` se recalcula desde la membresía directa y la jerarquía viva, y su ampliación está acotada al alcance EXPANDIDO del llamante | iam, o-auth | account, tenant, tenant-account, application | `active` | `blocking` | 2026-09-16 | [link](../../cliter/iam/business-rules/account.md) |
+| `BR-IAM-ROLE-001` | Precedencia de la ruta de aterrizaje al materializar la sesión | iam | role | `active` | `informational` | 2026-09-04 | [link](../../cliter/iam/business-rules/role.md) |
+| `BR-IAM-ROLE-002` | La navegación vertical arranca plegada cuando algún rol lo pide | iam | role | `active` | `informational` | 2026-09-04 | [link](../../cliter/iam/business-rules/role.md) |
+| `BR-IAM-USER-001` | Los campos sensibles del usuario se enmascaran en toda lectura y solo se leen crudos server-side vía repositorio | iam | user | `active` | `blocking` | 2026-07-26 | [link](../../cliter/iam/business-rules/user.md) |
+| `BR-IAM-USER-002` | Los campos sensibles de `IamUser` no son referenciables desde `where`, `order` ni `aggregation`, y su lectura cruda server-side exige una exención explícita | iam | user | `active` | `blocking` | 2026-07-26 | [link](../../cliter/iam/business-rules/user.md) |
+| `BR-LACREM-SHIPMENT-001` | La sincronización agrupa los registros de SAP por centro+material y suma las cantidades | lacrem | shipment | `active` | `informational` | 2026-06-17 | [link](../../cliter/lacrem/business-rules/shipment.md) |
+| `BR-LACREM-SHIPMENT-002` | Los registros con centro (WERKS) vacío se descartan y no se envían a Lacrem | lacrem | shipment | `active` | `informational` | 2026-06-17 | [link](../../cliter/lacrem/business-rules/shipment.md) |
+| `BR-LACREM-SHIPMENT-003` | Un envío fallido se reintenta hasta 3 veces con 15 minutos de espera | lacrem | shipment | `active` | `informational` | 2026-06-17 | [link](../../cliter/lacrem/business-rules/shipment.md) |
+| `BR-OAUTH-ACCESSTOKEN-001` | El `token` de `OAuthAccessToken`/`OAuthRefreshToken` se enmascara en toda lectura declarada; cinco vectores del Query DSL quedan fuera, documentados como deuda de framework | o-auth | access-token, refresh-token | `derogated` | `blocking` | 2026-09-03 | [link](../../cliter/o-auth/business-rules/access-token.md) |
+| `BR-OAUTH-ACCESSTOKEN-002` | El `token` de `OAuthAccessToken`/`OAuthRefreshToken` deja de ser referenciable desde `where`, `order` o `aggregation`, en lectura y en escritura | o-auth | access-token, refresh-token | `active` | `blocking` | 2026-09-03 | [link](../../cliter/o-auth/business-rules/access-token.md) |
+| `BR-OAUTH-APPLICATION-001` | El secret de OAuthApplication se persiste bcrypt-hasheado, se enmascara en lectura y solo se compara, nunca se devuelve legible | o-auth, hub | application, app | `active` | `blocking` | 2026-06-11 | [link](../../cliter/o-auth/business-rules/application.md) |
 | `BR-OAUTH-AUTHCODE-001` | Código de autorización de un solo uso (consumo atómico) | o-auth | authorization-code | `active` | `blocking` | 2026-06-08 | [link](../../cliter/o-auth/business-rules/authorization-code.md) |
 | `BR-OAUTH-AUTHCODE-002` | Expiración del código en ventana corta | o-auth | authorization-code | `active` | `blocking` | 2026-06-08 | [link](../../cliter/o-auth/business-rules/authorization-code.md) |
 | `BR-OAUTH-AUTHCODE-003` | Binding exacto de clientId y redirect_uri en el canje | o-auth | authorization-code | `active` | `blocking` | 2026-06-08 | [link](../../cliter/o-auth/business-rules/authorization-code.md) |
 | `BR-OAUTH-AUTHCODE-004` | Verificación PKCE S256 obligatoria en el canje | o-auth | authorization-code | `active` | `blocking` | 2026-06-08 | [link](../../cliter/o-auth/business-rules/authorization-code.md) |
 | `BR-OAUTH-AUTHCODE-005` | `/authorize`: validación de petición y redirect_uri sin open-redirect | o-auth | authorization-code | `active` | `blocking` | 2026-06-08 | [link](../../cliter/o-auth/business-rules/authorization-code.md) |
+| `BR-OAUTH-CREDENTIAL-001` | Vetos anti-escalada de la impersonación (cadena, auto-impersonación y objetivo privilegiado) | o-auth | credential | `active` | `blocking` | 2026-08-31 | [link](../../cliter/o-auth/business-rules/credential.md) |
+| `BR-OAUTH-CREDENTIAL-002` | El token de impersonación es solo access token, de TTL corto y no renovable | o-auth | credential | `active` | `blocking` | 2026-08-31 | [link](../../cliter/o-auth/business-rules/credential.md) |
+| `BR-OAUTH-CREDENTIAL-003` | Toda impersonación deja fila de auditoría con grantType IMPERSONATION y las dos cuentas | o-auth | credential | `active` | `blocking` | 2026-08-31 | [link](../../cliter/o-auth/business-rules/credential.md) |
 | `BR-OAUTH-HUBSESSION-001` | El logout RP-initiated termina la sesión del hub | o-auth | hub-session | `active` | `blocking` | 2026-06-09 | [link](../../cliter/o-auth/business-rules/hub-session.md) |
 | `BR-OAUTH-HUBSESSION-002` | Validación same-origin de `post_logout_redirect_uri` (anti open-redirect) | o-auth | hub-session | `active` | `blocking` | 2026-06-09 | [link](../../cliter/o-auth/business-rules/hub-session.md) |
+| `BR-PROD-EQUIPMENT-001` | Un equipment debe tener al menos un proceso asignado | production-planning | equipment | `active` | `blocking` | 2026-07-16 | [link](../../cliter/production-planning/business-rules/equipment.md) |
+| `BR-PROD-EVENT-001` | Causa identificable obligatoria al finalizar con typeStop = ISSUE | production-planning | production-order-position-event | `active` | `blocking` | 2026-07-13 | [link](../../cliter/production-planning/business-rules/production-order-position-event.md) |
+| `BR-PROD-HEADER-001` | Cascada de IN_PROGRESS al crear el primer evento | production-planning | production-order-header, production-order-position, production-order-position-event | `active` | `blocking` | 2026-07-13 | [link](../../cliter/production-planning/business-rules/production-order-header.md) |
+| `BR-PROD-HEADER-002` | Revert por borrado del último evento | production-planning | production-order-header, production-order-position, production-order-position-event | `active` | `blocking` | 2026-07-13 | [link](../../cliter/production-planning/business-rules/production-order-header.md) |
+| `BR-PROD-HEADER-003` | Cascada al finalizar evento (transición a DONE) | production-planning | production-order-header, production-order-position, production-order-position-event | `active` | `blocking` | 2026-07-13 | [link](../../cliter/production-planning/business-rules/production-order-header.md) |
+| `BR-PROD-HEADER-004` | Acumulación de duración en position y header al finalizar evento | production-planning | production-order-header, production-order-position, production-order-position-event | `active` | `blocking` | 2026-07-13 | [link](../../cliter/production-planning/business-rules/production-order-header.md) |
+| `BR-PROD-HEADER-005` | Cascada de DONE al header al cerrar el último position | production-planning | production-order-header, production-order-position, production-order-position-event | `active` | `blocking` | 2026-07-13 | [link](../../cliter/production-planning/business-rules/production-order-header.md) |
+| `BR-PROD-HEADER-006` | Re-apertura del header al crear position sobre campaña DONE + guard CANCELLED en creación | production-planning | production-order-header, production-order-position, production-order-position-event | `active` | `blocking` | 2026-07-13 | [link](../../cliter/production-planning/business-rules/production-order-header.md) |
+| `BR-PROD-HEADER-007` | Reevaluación del header tras borrar position + guard CANCELLED en borrado | production-planning | production-order-header, production-order-position, production-order-position-event | `active` | `blocking` | 2026-07-13 | [link](../../cliter/production-planning/business-rules/production-order-header.md) |
+| `BR-PROD-HEADER-008` | Provision con `targetStatus` parametrizado por positions DONE históricos | production-planning | production-order-header, production-order-position, production-order-position-event | `active` | `blocking` | 2026-07-13 | [link](../../cliter/production-planning/business-rules/production-order-header.md) |
+| `BR-PROD-POSITION-001` | Acumulación de pesos por tipo de proceso al finalizar evento | production-planning | production-order-position | `active` | `blocking` | 2026-07-13 | [link](../../cliter/production-planning/business-rules/production-order-position.md) |
+| `BR-PROD-POSITION-002` | Composición de procesos disponibles para crear evento sobre un position. | production-planning | production-order-position | `derogated` | `blocking` | 2026-07-13 | [link](../../cliter/production-planning/business-rules/production-order-position.md) |
+| `BR-PROD-POSITION-003` | Sello de `position.startDate` al crear el primer evento | production-planning | production-order-position | `active` | `blocking` | 2026-07-13 | [link](../../cliter/production-planning/business-rules/production-order-position.md) |
+| `BR-PROD-POSITION-004` | Reset de `position.startDate` al borrar el último evento | production-planning | production-order-position | `active` | `blocking` | 2026-07-13 | [link](../../cliter/production-planning/business-rules/production-order-position.md) |
+| `BR-PROD-POSITION-005` | Cierre manual del position (ON_HOLD → DONE) | production-planning | production-order-position | `active` | `blocking` | 2026-07-13 | [link](../../cliter/production-planning/business-rules/production-order-position.md) |
+| `BR-PROD-POSITION-006` | Composición de procesos disponibles para crear evento, filtrada por equipos asignados al position | production-planning | production-order-position | `active` | `blocking` | 2026-07-13 | [link](../../cliter/production-planning/business-rules/production-order-position.md) |
+| `BR-PROD-POSITION-007` | Oferta de combinaciones de equipos asignables | production-planning | production-order-position | `active` | `blocking` | 2026-07-13 | [link](../../cliter/production-planning/business-rules/production-order-position.md) |
+| `BR-PROD-POSITION-008` | Refresco del snapshot solo en reasignación | production-planning | production-order-position | `active` | `blocking` | 2026-07-13 | [link](../../cliter/production-planning/business-rules/production-order-position.md) |
+| `BR-PROD-POSITION-009` | Oferta de operarios asignables por el role configurado | production-planning | production-order-position | `active` | `blocking` | 2026-07-13 | [link](../../cliter/production-planning/business-rules/production-order-position.md) |
+| `BR-REPORT-001` | El motor SIEMPRE scopea por tenant en cada tabla del cubo | reporting | report | `active` | `blocking` | 2026-07-02 | [link](../../cliter/reporting/business-rules/report.md) |
+| `BR-REPORT-002` | La selección solo es válida contra la whitelist del cubo | reporting | report | `active` | `blocking` | 2026-07-02 | [link](../../cliter/reporting/business-rules/report.md) |
+| `BR-REPORT-003` | El resultado de un reporte en modo cliente tiene un cap duro de filas | reporting | report | `active` | `blocking` | 2026-07-02 | [link](../../cliter/reporting/business-rules/report.md) |
+| `BR-REPORT-004` | Todo cubo registrado DEBE declarar al menos un `systemReport` | reporting | report | `active` | `blocking` | 2026-07-02 | [link](../../cliter/reporting/business-rules/report.md) |
+| `BR-REPORT-CATEGORY-001` | El color de una categoría debe ser un hex RGB válido (#rrggbb) | reporting | report-category | `active` | `blocking` | 2026-07-02 | [link](../../cliter/reporting/business-rules/report-category.md) |
+| `BR-REPORT-CATEGORY-002` | El nombre de una categoría debe ser único | reporting | report-category | `active` | `blocking` | 2026-07-02 | [link](../../cliter/reporting/business-rules/report-category.md) |
+| `BR-REPORT-FAVORITE-001` | El favorito de un reporte pertenece exclusivamente a la cuenta del JWT | reporting | report-favorite | `active` | `blocking` | 2026-07-02 | [link](../../cliter/reporting/business-rules/report-favorite.md) |
+| `BR-SAP-EVENT-LOG-001` | El registro durable de un evento refleja el número real de intentos de procesamiento y el instante del último intento terminal; el campo `status` es el único discriminador del resultado (procesado vs dead-letter). | sap-integration | sap-event-log | `active` | `informational` | 2026-06-24 | [link](../../cliter/sap-integration/business-rules/sap-event-log.md) |
+| `BR-TOOLS-CUSTOM-FIELD-001` | Una definición de campo personalizado pertenece a un grupo y su key es inmutable | tools | custom-field-definition, custom-field-group, custom-field-option | `active` | `blocking` | 2026-08-05 | [link](../../cliter/tools/business-rules/custom-field.md) |
+| `BR-TOOLS-CUSTOM-FIELD-004` | Un grupo aflora sólo a las entidades listadas en `entity_types` (resolución fail-closed) | tools | custom-field-definition, custom-field-group, custom-field-option | `active` | `blocking` | 2026-08-05 | [link](../../cliter/tools/business-rules/custom-field.md) |
+| `BR-TOOLS-CUSTOM-FIELD-005` | El `code` de una opción es inmutable tras la creación | tools | custom-field-definition, custom-field-group, custom-field-option | `active` | `blocking` | 2026-08-05 | [link](../../cliter/tools/business-rules/custom-field.md) |

package/dist/templates/monorepo/docs/business-rules/MIGRATION.md

@@ -48,55 +48,14 @@ Tiempo estimado: **15-20 minutos**.
 
 ## Lista exhaustiva de archivos
 
-### Archivos NUEVOS (copiar tal cual)
+El árbol completo del sistema — qué es NUEVO (copiar tal cual), qué es MODIFICADO (aplicar como
+patch) y qué es GENERADO (no copiar, aparece al ejecutar) — está documentado una sola vez en
+[`ARCHITECTURE.md` — Mapa de archivos del sistema](./ARCHITECTURE.md#mapa-de-archivos-del-sistema)
+y en sus notas "Archivos modificados" / "Archivos artefacto generados" justo debajo. Cópialo tal
+cual para los archivos nuevos; aplica como parche (sin sobrescribir tu configuración existente) los
+que esa lista marca como modificados; no toques los que marca como generados.
 
-```
-docs/business-rules/README.md                         ← guía operativa
-docs/business-rules/ARCHITECTURE.md                   ← documento técnico
-docs/business-rules/MIGRATION.md                      ← este archivo
-docs/business-rules/_schema.json                      ← JSON Schema del frontmatter
-
-scripts/business-rules/types.ts                       ← interfaces compartidas
-scripts/business-rules/parse-catalog.ts               ← parser
-scripts/business-rules/generate-index.ts              ← generador de índice
-scripts/business-rules/validate-catalog.ts            ← validador estructural
-scripts/business-rules/validate-citations.ts          ← validador de @rule
-scripts/business-rules/audit.ts                       ← reporte estructural
-scripts/business-rules/promote.ts                     ← cristaliza desde archive
-scripts/business-rules/document.ts                    ← bootstrap retroactivo
-scripts/business-rules/check.ts                       ← validación dirigida
-
-.claude/hooks/inject-rules-context.ts                 ← UserPromptSubmit hook
-
-.claude/commands/business-rules/promote.md            ← /business-rules:promote
-.claude/commands/business-rules/document.md           ← /business-rules:document
-.claude/commands/business-rules/audit.md              ← /business-rules:audit
-.claude/commands/business-rules/check.md              ← /business-rules:check
-
-.claude/skills/business-rules-guard/SKILL.md          ← entry skill
-.claude/skills/business-rules-guard/references/format.md
-.claude/skills/business-rules-guard/references/workflow.md
-.claude/skills/business-rules-guard/references/audit.md
-
-.github/workflows/business-rules-check.yml            ← CI estructural
-```
-
-### Archivos MODIFICADOS (patches a aplicar)
-
-```
-package.json                                          ← scripts + devDependencies
-.husky/pre-commit                                     ← append bloque
-.claude/settings.json                                 ← append hook
-openspec/config.yaml                                  ← append context + rules  [opcional]
-CLAUDE.md                                             ← append sección + fila tabla
-```
-
-### Archivos GENERADOS (no copiar; aparecen al ejecutar)
-
-```
-cliter/business-rules-index.json                      ← pnpm br:generate
-docs/business-rules/INDEX.md                          ← pnpm br:generate
-```
+Lo que `ARCHITECTURE.md` no cubre — porque describe ESTE repo, no la migración — es qué NO copiar:
 
 ### Archivos ESPECÍFICOS del repo origen (NO copiar)
 
@@ -129,7 +88,7 @@ mkdir -p "$TARGET"/{scripts/business-rules,.claude/{hooks,commands/business-rule
 
 # Copiar archivos
 cp scripts/business-rules/*.ts "$TARGET"/scripts/business-rules/
-cp .claude/hooks/inject-rules-context.ts "$TARGET"/.claude/hooks/
+cp .claude/hooks/inject-prompt-context.ts "$TARGET"/.claude/hooks/
 cp .claude/commands/business-rules/*.md "$TARGET"/.claude/commands/business-rules/
 cp .claude/skills/business-rules-guard/SKILL.md "$TARGET"/.claude/skills/business-rules-guard/
 cp .claude/skills/business-rules-guard/references/*.md "$TARGET"/.claude/skills/business-rules-guard/references/
@@ -245,7 +204,7 @@ Añadir el hook `UserPromptSubmit`. Si el archivo no tiene la sección
         "hooks": [
           {
             "type": "command",
-            "command": "npx tsx \"$CLAUDE_PROJECT_DIR/.claude/hooks/inject-rules-context.ts\"",
+            "command": "npx tsx \"$CLAUDE_PROJECT_DIR/.claude/hooks/inject-prompt-context.ts\"",
             "timeout": 5
           }
         ]
@@ -368,7 +327,7 @@ docs/business-rules/                                  (nuevo dir, 5 archivos)
 cliter/production-planning/business-rules/            (nuevo, 3 archivos — REGLAS, no sistema)
 cliter/business-rules-index.json                      (nuevo, generado)
 scripts/business-rules/                               (nuevo dir, 10 archivos)
-.claude/hooks/inject-rules-context.ts                 (nuevo)
+.claude/hooks/inject-prompt-context.ts                 (nuevo)
 .claude/commands/business-rules/                      (nuevo dir, 4 archivos)
 .claude/skills/business-rules-guard/                  (nuevo dir, 4 archivos)
 .github/workflows/business-rules-check.yml            (nuevo)
@@ -386,7 +345,7 @@ CLAUDE.md                                             (modificado: +sección, +f
 ```bash
 # Commit 1 — Sistema (todo lo del sistema, sin reglas piloto)
 git add docs/business-rules/ scripts/business-rules/ \
-        .claude/hooks/inject-rules-context.ts \
+        .claude/hooks/inject-prompt-context.ts \
         .claude/commands/business-rules/ \
         .claude/skills/business-rules-guard/ \
         .github/workflows/business-rules-check.yml \