@aurorajs.dev/catalyst-cli 1.1.3 → 2.0.0

package/dist/templates/monorepo/cliter/harness-rules/barrels.md

@@ -1,7 +1,7 @@
 ---
 scope: project
 bounded_contexts: []
-last_updated: 2026-09-01
+last_updated: 2026-09-11
 keywords:
   - barrel
   - barrel import
@@ -22,6 +22,12 @@ keywords:
   - wiring surface
   - superficie de wiring
   - adapters sub-barrel
+  - code splitting
+  - code-splitting
+  - chunk boundary
+  - límite de chunk
+  - lazy route
+  - ruta lazy
 paths:
   - backend/src/@api/**
   - backend/src/@app/**
@@ -49,7 +55,7 @@ paths:
 >   (`@aurora/shared.module`, `@aurora/core.module`) se importan directamente. Frontend: `@aurora`
 >   expone un barrel raíz (`src/@aurora/index.ts`, siempre `from '@aurora'`) MÁS un conjunto de
 >   **sub-barrel aliases declarados explícitamente** en `frontend/tsconfig.json`
->   (`@aurora/components`, `@aurora/modules/health`, …, HR-BARRELS-003); un specifier que nombra
+>   (`@aurora/components`, `@aurora/modules/health`, …, HR-BARRELS-004); un specifier que nombra
 >   un fichero de implementación NO está en esa tabla y simplemente no resuelve.
 
 ---
@@ -123,7 +129,7 @@ falsos positivos en sub-barrels):
 - `backend/src/@app/o-auth/shared/index.ts` — expone `TokenRetentionService`.
 - `backend/src/@bridges/iam/permission/index.ts` — barrel de consumo de un módulo de `@bridges` (la composición de superficies de `@bridges` la gobierna HR-BARRELS-002).
 - `backend/src/@api/o-auth/o-auth.module.ts`, `backend/src/@api/iam/iam.module.ts` — importan los adapters por sub-barrel público.
-- `scripts/harness-rules/lint-barrels.ts` — lint determinista de los anchor patterns de HR-BARRELS-003 y HR-BARRELS-002; superficies: `pnpm hr:lint-barrels` (full/staged), pre-commit staged (`.husky/pre-commit`), PostToolUse por-fichero (`.claude/hooks/lint-barrels.ts`).
+- `scripts/harness-rules/lint-barrels.ts` — lint determinista de los anchor patterns de HR-BARRELS-004 y HR-BARRELS-002; superficies: `pnpm hr:lint-barrels` (full/staged), pre-commit staged (`.husky/pre-commit`), PostToolUse por-fichero (`.claude/hooks/lint-barrels.ts`).
 
 ### Reglas relacionadas
 
@@ -132,7 +138,7 @@ falsos positivos en sub-barrels):
 - **HR-MODGRAPH-001** — la razón por la que un sub-barrel acotado (`domain/ports`) es a veces obligatorio: importar por el barrel raíz arrastraría el `AuthenticationModule` (hoja) y arriesgaría un ciclo.
 - **HR-MODULES-001** — barrel-and-spread para el registro en módulos; misma filosofía del barrel como superficie pública.
 - **HR-FLOWS-001** — barrel-and-spread de flows hand-written; consistente con esta convención.
-- **HR-BARRELS-003** — regla sustituta, activa desde 2026-09-01.
+- **HR-BARRELS-004** — regla sustituta activa (vía **HR-BARRELS-003**, sustituta intermedia desde 2026-09-01, derogada 2026-09-11 por defecto de proceso — ver su propia `### Derogación`).
 
 ### Derogación
 
@@ -148,9 +154,9 @@ cambios.
 
 | Campo     | Valor                                                                                                                                                                                                                          |
 | --------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| Estado    | `active`                                                                                                                                                                                                                       |
+| Estado    | `derogated`                                                                                                                                                                                                                    |
 | Severidad | `informational`                                                                                                                                                                                                              |
-| Origen    | Sustituye a **HR-BARRELS-001** (`derogated` 2026-09-01): change `reduce-frontend-eager-payload`. El frontend `@aurora` deja de ser un barrel único y pasa a exponer, además del barrel raíz, un conjunto de sub-barrel aliases declarados explícitamente en `frontend/tsconfig.json` (`@aurora/components`, `@aurora/modules/health`, …). El resto del enunciado y de la matriz de casos de HR-BARRELS-001 se conserva sin cambios. |
+| Origen    | Sustituye a **HR-BARRELS-001** (`derogated` 2026-09-01): change `reduce-frontend-eager-payload`. El frontend `@aurora` deja de ser un barrel único y pasa a exponer, además del barrel raíz, un conjunto de sub-barrel aliases declarados explícitamente en `frontend/tsconfig.json` (`@aurora/components`, `@aurora/modules/health`, …). El resto del enunciado y de la matriz de casos de HR-BARRELS-001 se conserva sin cambios. Sustituida por **HR-BARRELS-004** (defecto de proceso, T-45, ver `### Derogación`). |
 
 ### Enunciado
 
@@ -217,7 +223,7 @@ falsos positivos en sub-barrels):
 ### Implementa
 
 - `frontend/tsconfig.json` — tabla de sub-barrel aliases declarados del `@aurora` frontend (D1 de `reduce-frontend-eager-payload`).
-- `scripts/harness-rules/lint-barrels.ts` — lint determinista de los anchor patterns de HR-BARRELS-003 y HR-BARRELS-002; superficies: `pnpm hr:lint-barrels` (full/staged), pre-commit staged (`.husky/pre-commit`), PostToolUse por-fichero (`.claude/hooks/lint-barrels.ts`).
+- `scripts/harness-rules/lint-barrels.ts` — lint determinista de los anchor patterns de HR-BARRELS-004 y HR-BARRELS-002; superficies: `pnpm hr:lint-barrels` (full/staged), pre-commit staged (`.husky/pre-commit`), PostToolUse por-fichero (`.claude/hooks/lint-barrels.ts`).
 
 ### Reglas relacionadas
 
@@ -227,6 +233,120 @@ falsos positivos en sub-barrels):
 - **HR-MODGRAPH-001** — la razón por la que un sub-barrel acotado (`domain/ports`) es a veces obligatorio: importar por el barrel raíz arrastraría el `AuthenticationModule` (hoja) y arriesgaría un ciclo.
 - **HR-MODULES-001** — barrel-and-spread para el registro en módulos; misma filosofía del barrel como superficie pública.
 - **HR-FLOWS-001** — barrel-and-spread de flows hand-written; consistente con esta convención.
+- **HR-BARRELS-004** — regla sustituta, activa desde 2026-09-11 (ver `### Derogación`).
+
+### Derogación
+
+**2026-09-11**: en revisión se detectó que la excepción por `import()` dinámico de rutas lazy
+(T-45, caso 10) se había registrado editando EN SITIO el `### Enunciado`, la matriz de
+`### Casos exhaustivos` y el `### Anchor patterns` de esta regla, en vez de derogar y crear una
+regla nueva — violación de la convención 7 de `harness-rules-guard` ("cambios semánticos = derogar
++ crear con id nuevo", anti-patrón 3). Se deroga esta regla y se sustituye por **HR-BARRELS-004**,
+que incorpora la excepción como caso nuevo y la declara explícitamente en su propio `### Enunciado`
+para que no contradiga su propia matriz de casos.
+
+---
+
+## HR-BARRELS-004 — Importar activos por barrel (módulo o sub-barrel público), no por deep-path
+
+| Campo     | Valor                                                                                                                                                                                                                          |
+| --------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Estado    | `active`                                                                                                                                                                                                                       |
+| Severidad | `informational`                                                                                                                                                                                                              |
+| Origen    | Sustituye a **HR-BARRELS-003** (`derogated` 2026-09-11): defecto de proceso detectado en revisión — la excepción por `import()` dinámico de rutas lazy (T-45) se había registrado editando EN SITIO el `### Enunciado` y la matriz de `### Casos exhaustivos` de HR-BARRELS-003 en vez de derogar y crear una regla nueva (convención 7 de `harness-rules-guard`). El resto del enunciado y de la matriz de casos de HR-BARRELS-003 se conserva sin cambios; esta regla añade el caso 10 (excepción por FORMA para `import()` dinámico) y lo declara explícitamente en el `### Enunciado`, para que el enunciado no contradiga su propia matriz de casos. |
+
+### Enunciado
+
+Un activo de un módulo se importa a través de un **barrel** (`index.ts`): el del módulo
+(`<alias>/<bc>/<module>`) o un **sub-barrel público** del módulo (una subcarpeta con su propio
+`index.ts` que expone una superficie acotada, p.ej. `.../domain/ports`, `.../ports`,
+`.../infrastructure/guards`). NUNCA por **deep-path a un fichero de implementación**
+(`.../services/x.service`, `.../strategies/x.strategy`, `.../data-access/x.config`). El barrel es
+la superficie pública; los ficheros internos son detalle de implementación y no deben aparecer en
+el import specifier de OTRO módulo. Si el activo no está expuesto, se AÑADE al `index.ts`
+correspondiente (del módulo o de un sub-barrel) y se importa por barrel.
+
+**Excepción por FORMA — `import()` dinámico**: el specifier de un `import('...')` con literal
+como target de una ruta lazy (típicamente `loadComponent`/`loadChildren` de una ruta Angular en un
+`*.routes.ts`) queda EXENTO de esta regla sea cual sea su profundidad — es el límite de
+code-splitting que Angular usa para emitir un chunk propio por ruta; enrutarlo por un barrel
+arrastraría el módulo entero al chunk, la regresión que esta regla existe para evitar. La excepción
+es de la FORMA del import (`import(...)` con literal), NUNCA del fichero: un `import ... from '...'`
+ESTÁTICO al mismo target, o en el mismo `*.routes.ts` (p.ej. un resolver), sigue siendo deep-path
+prohibido.
+
+Importar de un sub-barrel acotado en vez del barrel raíz no solo es válido: a veces es
+OBLIGATORIO. Ej.: los contratos de `@aurora/modules/authentication/domain/ports` (Symbols +
+interfaces, cero side-effects) se importan por ese sub-barrel para NO arrastrar el
+`AuthenticationModule` vía el barrel raíz, respetando HR-MODGRAPH-001 (authentication es hoja).
+
+**Alcance.** Backend: `@api`, `@app`, `@bridges` (`[bc]/[module]`) y `@aurora`
+(`@aurora/modules/<module>`, `@aurora/decorators`, …; ficheros sueltos de primer nivel sin barrel
+se importan directamente). Frontend: `@aurora` expone un **barrel raíz** (`from '@aurora'`) MÁS un
+conjunto de **sub-barrel aliases declarados explícitamente** en `frontend/tsconfig.json`
+(`@aurora/components`, `@aurora/modules/health`, …) — importar de un alias declarado es válido; un
+specifier que nombra un fichero de implementación sigue prohibido y, al no estar en esa tabla,
+simplemente NO RESUELVE. Y los BC bajo `app/domains/admin/apps/<bc>/<module>` y `<bc>/shared`
+(cada uno con su `index.ts`).
+
+La regla gobierna la **FORMA** del import, no su **legitimidad**: qué módulo puede importar de cuál
+lo siguen gobernando HR-BRIDGES-001 (cross-BC SOLO vía un port en `@bridges/`) y HR-MODULES-001.
+Usar la forma barrel NUNCA autoriza un import cross-BC que esas reglas prohíben.
+
+### Casos exhaustivos
+
+| #   | Situación                                                                                                            | ¿Permitido? | Acción correcta                                                                            |
+| --- | -------------------------------------------------------------------------------------------------------------------- | ----------- | ------------------------------------------------------------------------------------------ |
+| 1   | Importar de otro módulo por su barrel: `from '@app/o-auth/shared'`                                                    | SÍ          | Forma canónica: importar del `index.ts` del módulo.                                        |
+| 2   | Importar de un sub-barrel público (carpeta con `index.ts`): `from '@aurora/modules/authentication/domain/ports'`     | SÍ          | Válido — y a veces obligatorio para no arrastrar el módulo (HR-MODGRAPH-001).              |
+| 3   | Deep-path a un fichero de implementación: `from '@app/o-auth/shared/services/token-retention.service'`               | **NO**      | Exportar el activo en el `index.ts` (del módulo o de un sub-barrel) e importar por barrel. |
+| 4   | El activo no está expuesto por ningún barrel                                                                          | SÍ          | Añadir `export * from './…'` al `index.ts` correspondiente; luego importar por barrel.     |
+| 5   | Usar la forma barrel para cruzar a OTRO BC (`@app/<other-bc>/…`) y saltarse la frontera                              | **NO**      | No autoriza cross-BC: va por un port en `@bridges/` (HR-BRIDGES-001).                      |
+| 6   | Imports relativos DENTRO del mismo módulo (`./…`) o los re-exports del propio `index.ts`                             | SÍ          | Lo interno del módulo usa rutas relativas; la regla aplica a imports ENTRE módulos.        |
+| 7   | Fichero suelto de primer nivel de `@aurora` (backend) sin barrel (`@aurora/shared.module`, `@aurora/core.module`)    | SÍ          | No es un módulo con barrel: el import directo del fichero es correcto.                     |
+| 8   | Frontend — deep-path a un fichero de otro módulo BC: `from '…/apps/iam/user/data-access/user.list-config'` | **NO**      | Importar del barrel del módulo: `…/apps/iam/user` (o `iam/shared`).            |
+| 9   | Frontend — importar de un sub-barrel `@aurora` declarado en `frontend/tsconfig.json`: `from '@aurora'`, `from '@aurora/components'`, `from '@aurora/modules/health'` | SÍ          | Barrel raíz o alias declarado — ambos son superficie pública; un specifier que nombra un fichero de implementación no está en la tabla y no resuelve. |
+| 10  | Frontend — `import()` dinámico con literal como target de una ruta lazy, en un `*.routes.ts`: `loadComponent: () => import('./queue/features/queue-list.component')` | SÍ          | Excepción por FORMA (T-45): el specifier de un `import()` dinámico es el límite de code-splitting que Angular usa para emitir un chunk propio por ruta — enrutarlo por un barrel arrastraría el módulo entero al chunk, la regresión que esta regla existe para evitar. La excepción es de la FORMA del import, NUNCA del fichero: un `import ... from '...'` ESTÁTICO al mismo target, o en el mismo `*.routes.ts` (p.ej. un resolver), sigue siendo deep-path prohibido. |
+
+### Anchor patterns
+
+Un futuro guard (lint) debe vigilar — el discriminante es **fichero-de-implementación vs
+carpeta-con-`index.ts`**, NO la profundidad de segmentos (una heurística por profundidad daría
+falsos positivos en sub-barrels):
+
+- **Backend**: un import bajo `@(api|app|bridges)/<bc>/<module>/…` o `@aurora/modules/<module>/…`
+  cuyo destino es un FICHERO `.ts` de implementación (no una carpeta con `index.ts`). Importar de
+  un sub-barrel (carpeta con `index.ts`: `ports`, `domain/ports`, `infrastructure/guards`) NO es
+  violación.
+- **Frontend**: un import a `app/domains/admin/apps/<bc>/<module>/<subdir>/<file>` que
+  apunta a un fichero interno en vez de al barrel `<bc>/<module>` o `<bc>/shared`. `@aurora` acepta
+  el barrel raíz (`from '@aurora'`) y cualquier sub-barrel alias declarado en
+  `frontend/tsconfig.json`; un specifier RELATIVO que escapa a un fichero interno de `@aurora`
+  bypaseando esa tabla es violación igual que un deep-path por alias.
+- **Excepción por FORMA — `import()` dinámico (T-45, caso 10)**: un `import('...')` con literal
+  (típicamente `loadComponent`/`loadChildren` de una ruta Angular en un `*.routes.ts`) queda EXENTO
+  de esta regla sea cual sea su profundidad — es el límite de code-splitting que la propia regla
+  protege (evitar el eager payload que un barrel de grupo arrastraría, la regresión de
+  `reduce-frontend-eager-payload`). La exención es de la FORMA (`import(...)` con literal), NUNCA
+  del nombre de fichero: NO se exime `*.routes.ts` en bloque — un `import ... from '...'` ESTÁTICO
+  en ese mismo fichero (p.ej. un resolver importado por deep-path) sigue gobernado y reportándose.
+- **Excepciones legítimas**: imports relativos `./…` internos al propio módulo; los
+  `export * from './…'` del propio `index.ts`; los ficheros sueltos de primer nivel de `@aurora`
+  backend; y cualquier sub-barrel público (carpeta con su propio `index.ts`).
+
+### Implementa
+
+- `frontend/tsconfig.json` — tabla de sub-barrel aliases declarados del `@aurora` frontend (D1 de `reduce-frontend-eager-payload`).
+- `scripts/harness-rules/lint-barrels.ts` — lint determinista de los anchor patterns de HR-BARRELS-004 y HR-BARRELS-002; superficies: `pnpm hr:lint-barrels` (full/staged), pre-commit staged (`.husky/pre-commit`), PostToolUse por-fichero (`.claude/hooks/lint-barrels.ts`).
+
+### Reglas relacionadas
+
+- **HR-BARRELS-003** — regla derogada que esta sustituye; mismo enunciado y Alcance, solo añade la excepción por FORMA del `import()` dinámico (T-45) y la declara en el `### Enunciado` (defecto de proceso corregido: ver `### Derogación` de HR-BARRELS-003).
+- **HR-BARRELS-002** — composición de superficies en `@bridges`: qué exporta el barrel de módulo y qué el sub-barrel `adapters/`. HR-BARRELS-004 gobierna la FORMA del import; la 002, el CONTENIDO de cada barrel.
+- **HR-BRIDGES-001** — gobierna QUÉ se importa cross-BC (vía port en `@bridges/`); HR-BARRELS-004 gobierna la FORMA (barrel) del import legítimo, sin relevar fronteras.
+- **HR-MODGRAPH-001** — la razón por la que un sub-barrel acotado (`domain/ports`) es a veces obligatorio: importar por el barrel raíz arrastraría el `AuthenticationModule` (hoja) y arriesgaría un ciclo.
+- **HR-MODULES-001** — barrel-and-spread para el registro en módulos; misma filosofía del barrel como superficie pública.
+- **HR-FLOWS-001** — barrel-and-spread de flows hand-written; consistente con esta convención.
 
 ---
 

package/dist/templates/monorepo/cliter/harness-rules/bridges.md

@@ -1,7 +1,7 @@
 ---
 scope: project
 bounded_contexts: []
-last_updated: 2026-07-31
+last_updated: 2026-09-13
 keywords:
   - cross-bc
   - cross-bounded-context
@@ -12,8 +12,12 @@ keywords:
   - bridges
   - dependency inversion entre BCs
   - app no importa otro app
+  - crossBcRelations
+  - aurora-drizzle-schema
 paths:
   - backend/src/@bridges/**
+  - backend/src/@config/drizzle/aurora-drizzle-schema.ts
+  - backend/src/@app/**/domain/**/*.field-schema.ts
 ---
 
 # Cross-BC bridges (ports y adapters)
@@ -33,9 +37,9 @@ paths:
 
 | Campo     | Valor                                                                                                 |
 | --------- | ----------------------------------------------------------------------------------------------------- |
-| Estado    | `active`                                                                                              |
+| Estado    | `derogated`                                                                                           |
 | Severidad | `blocking`                                                                                            |
-| Origen    | spec `openspec/specs/cross-bc-ports/spec.md` (convención formalizada); supersede `feedback_cross_bc_adapter_location.md`, que toleraba adapters en `@app/` |
+| Origen    | spec `openspec/specs/cross-bc-ports/spec.md` (convención formalizada); supersede `feedback_cross_bc_adapter_location.md`, que toleraba adapters en `@app/`. Superseded by **HR-BRIDGES-002** (task T-19, see `### Derogación`). |
 
 ### Enunciado
 
@@ -86,3 +90,122 @@ Un futuro guard debe vigilar:
 
 - **HR-PORTS-001** — el patrón ports/adapters como default para deps cross-layer `@aurora ↔ app`;
   misma mecánica de dependency inversion, distinta frontera (framework↔app vs BC↔BC).
+- **HR-BRIDGES-002** — active replacement since 2026-09-13 (see `### Derogación`).
+
+### Derogación
+
+**2026-09-13** (task T-19): two statements of this rule are false against the code and could not be
+fixed by an in-place edit. First, "Toda dependencia cross-BC se materializa bajo `@bridges/`" is
+contradicted by the declarative cross-BC persistence relations the generator emits: 17 imports from
+`domain/*.field-schema.ts` into another BC's `domain/`, and the `crossBcRelations` block of
+`backend/src/@config/drizzle/aurora-drizzle-schema.ts` (the single, irreducible assembly point).
+Neither was governed by any rule; the `domain/` exemption lived only in an ESLint comment. Second,
+the claim that "ningún archivo bajo `@app/<bc>/` importa de otro `@app/<other-bc>/`" is linter
+enforceable did not hold: the linter only checked `application/` and `infrastructure/`. Replaced by
+**HR-BRIDGES-002**, which keeps the core unchanged, names both exceptions, and states exactly what
+the linter enforces and what it does not.
+
+---
+
+## HR-BRIDGES-002 — Cross-BC ports y adapters viven en @bridges/, con relaciones de persistencia nombradas
+
+| Campo     | Valor                                                                                                 |
+| --------- | ----------------------------------------------------------------------------------------------------- |
+| Estado    | `active`                                                                                              |
+| Severidad | `blocking`                                                                                            |
+| Origen    | Replaces **HR-BRIDGES-001** (`derogated` 2026-09-13, task T-19). Core convention from spec `openspec/specs/cross-bc-ports/spec.md`, unchanged. The two named exceptions come from code measured on 2026-09-13: the `crossBcRelations` assembly point and its rationale in `backend/src/@config/drizzle/aurora-drizzle-schema.ts`, and the generated `domain/*.field-schema.ts` relation targets. |
+
+### Enunciado
+
+Every cross-BC **behavioral** dependency — one BC reading data from, or invoking an operation of,
+another BC — lives under `backend/src/@bridges/<bc>/`, NEVER under `@app/<bc>/` or `@api/<bc>/`. The
+consumer declares a port and injects it by token; the supplier implements the adapter.
+`@bridges/<bc>/` is the external face of the BC (its cross-BC contracts); `@app/<bc>/` is the internal
+face (handlers, services, repositories). Aurora deliberately diverges from literal Evans/Vernon DDD
+here: cross-BC integration is a separable concern, materialized in `@bridges/`.
+
+**Named exceptions — declarative persistence relations.** Only two places may express a relation
+between two BCs without a port, and only in this form:
+
+- **E1 — generated field-schemas.** A `@app/<bc>/**/domain/**/*.field-schema.ts` may import the
+  `domain/` of another BC, and nothing else from it, to describe a relation target for the Query DSL
+  eager-load.
+- **E2 — the relations assembly point.** Only `backend/src/@config/drizzle/aurora-drizzle-schema.ts`
+  declares Drizzle relations between BCs (`crossBcRelations`), and from `@app` it imports only each
+  BC's `@app/<bc>/<bc>.relations`. Drizzle RQB resolves relations once against the merged schema, so
+  this single point cannot be split per BC.
+
+Both exceptions exist only because every BC shares ONE Postgres database behind ONE Drizzle engine. A
+change that moves a BC to its own datastore invalidates E1 and E2 for that BC and must revisit them.
+
+**Enforcement mecánico — exactly what `backend/eslint.config.mjs` checks, no more.** It checks only
+imports whose target is under `@app/**` and whose specifier is a string literal (`import`,
+`export … from`, `import()`, `require()`); TypeScript `import x = require()` and a non-literal
+`import()` are not seen. Layers are matched by folder name.
+
+- A file under a folder named `application/`, `infrastructure/` or `domain/` inside `@app/<bc>`
+  (other than an E1 field-schema) imports nothing from another `@app/<other-bc>`.
+- An E1 field-schema imports from another `@app/<other-bc>` only its `domain/`.
+- The E2 assembly point imports from `@app` only a BC-root `*.relations.ts` module (the generated
+  `<bc>.relations`).
+
+**Declared limit — not an exemption.** The linter does NOT check the other files of `@app/<bc>/`
+(for example `shared/` and `<bc>.relations.ts`), anything under `@api/**` (including generated DTOs
+and `graphql.ts`), any other source file outside `@app/**` except the E2 assembly point (for example
+`@bridges/**` and the other `@config/` files), or any import whose target is under `@api/**` or
+`@bridges/**`. The first
+paragraph of this statement still applies to them, and review is its only enforcement. This rule
+makes no claim that they comply: a clean lint run proves nothing about them.
+
+### Casos exhaustivos
+
+| #   | Situación                                                                                  | ¿Permitido? | Acción correcta                                                                                                       |
+| --- | ------------------------------------------------------------------------------------------ | ----------- | --------------------------------------------------------------------------------------------------------------------- |
+| 1   | Declare a port so a consumer BC can read data from another BC                               | SÍ          | `@bridges/<consumer-bc>/<feature>/ports/<thing>.port.ts` + `<thing>.token.ts` (co-located DI Symbol).                 |
+| 2   | Implement that port (adapter)                                                               | SÍ          | `@bridges/<supplier-bc>/<module>/adapters/<thing>.adapter.ts`, named with the **supplier** prefix, `@Injectable()`.   |
+| 3   | Put the port in `@app/<consumer>/shared/ports/` or the adapter in `@app/<supplier>/.../infrastructure/adapters/` | **NO**      | Move them to `@bridges/<bc>/<feature>/`.                                                                               |
+| 4   | A handler/module of `@app/<consumer>` imports directly from `@app/<supplier>`               | **NO**      | Inject the port by token (`@Inject(TOKEN)`); `BridgesModule` (`@Global`) serves the resolution.                      |
+| 5   | A generated `domain/*.field-schema.ts` imports another BC's `domain/` barrel to name a relation target (E1) | SÍ          | Keep it: it is the generator's relation description, reintroduced on every regen.                                     |
+| 6   | A field-schema imports another BC's handlers, services, `shared/` or root barrel; or a non-field-schema `domain/` file imports another BC | **NO**      | A relation target needs only the other BC's `domain/`; any behavior goes through a `@bridges/` port.                  |
+| 7   | Declare a relation between two BCs' tables in `crossBcRelations` of `aurora-drizzle-schema.ts` (E2) | SÍ          | Keep it there; the generator upserts entries, and hand edits are reconciled through `.origin` (HR-CODEGEN-001).       |
+| 8   | Declare a cross-BC Drizzle relation anywhere else (a `<bc>.relations.ts`, `@bridges/`, another `@config/` file), or import from `@app` anything other than `<bc>.relations` into the assembly point | **NO**      | Move the relation to E2's `crossBcRelations`; import other BCs' schemas only through `<bc>.relations`.                |
+
+> **Aclaración aditiva al caso 1, carried over unchanged from HR-BRIDGES-001:** when the reading BC is
+> a **platform-capability BC** (e.g. `tools`, not a peer domain BC like `iam` or `o-auth`) and the
+> contract is **consumer-agnostic** (every method discriminates the caller ONLY by a parameter such as
+> `entityType`, and the returned DTO is a minimal snapshot with no consumer-specific projection), the
+> port and its token MAY live in the **supplier's** territory (`@bridges/<supplier-bc>/<feature>/ports/`)
+> — open-host / published-language variant. Case 1 stays `SÍ`: the port is still under `@bridges/`,
+> with no `@app → @app` import. Precedents: `TOOLS_CUSTOM_FIELD_ENTITY_REGISTRAR` (write port) and
+> `TOOLS_KEY_VALUE_CONFIG`; worked example: `TOOLS_CUSTOM_FIELD_DEFINITION_READER`
+> (`@bridges/tools/custom-field/ports/`). See skill `catalyst-cross-bounded-context-ports` (section
+> "Platform-capability read port") and `openspec/specs/cross-bc-ports/spec.md`.
+
+### Anchor patterns
+
+A guard must watch:
+
+- Any cross-BC `*.adapter.ts` or `*.port.ts` under `backend/src/@app/**/infrastructure/adapters/**` or
+  `backend/src/@app/**/ports/**`: wrong location, they belong in `@bridges/`.
+- An import in `backend/src/@app/**` or `backend/src/@api/**` that resolves to another BC's `@app/` or
+  `@api/` — linted only for `@app/` targets from the three layers above; review for the rest
+  (declared limit).
+- An import in `backend/src/@app/**/domain/**/*.field-schema.ts` that resolves to another BC outside
+  its `domain/`.
+- A relation between two BCs declared outside `backend/src/@config/drizzle/aurora-drizzle-schema.ts`.
+- A `bridges.module.ts` that exports adapter classes or concrete supplier services instead of only the
+  Symbols (tokens).
+
+### Implementa
+
+- `backend/eslint.config.mjs` — the `boundaries/element-types` block that implements the
+  "Enforcement mecánico" list, and nothing beyond it.
+- `backend/src/@config/drizzle/aurora-drizzle-schema.ts` — E2, the `crossBcRelations` assembly point.
+
+### Reglas relacionadas
+
+- **HR-BRIDGES-001** — derogated rule this one replaces; same core, without the named exceptions and
+  with an enforcement claim that did not hold (see its `### Derogación`).
+- **HR-PORTS-001** — ports/adapters as the default for cross-layer deps `@aurora ↔ app`; same
+  dependency-inversion mechanics, different boundary (framework↔app vs BC↔BC).
+- **HR-CODEGEN-001** — E1 and E2 are generator-owned; hand edits are reconciled through `.origin`.

package/dist/templates/monorepo/cliter/harness-rules/generated-artifacts.md

@@ -0,0 +1,104 @@
+---
+scope: project
+bounded_contexts: []
+last_updated: 2026-09-16
+keywords:
+  - artefacto generado
+  - generated artifact
+  - salida compilada
+  - compiled output
+  - dist versionado
+  - tracked dist
+  - puerta de deriva
+  - drift gate
+  - espejo del packager
+  - packager mirror
+  - prepare on install
+paths:
+  - scripts/packager/**
+  - scripts/rebuild-core-packages.sh
+---
+
+# Artefactos generados: seguidos con puerta, o no seguidos
+
+> **Glosario**:
+>
+> - **Artefacto generado**: cualquier fichero que una herramienta produce a partir de otro fichero
+>   del repositorio — salida de `tsc`, de `ng-packagr`, de `scripts/packager/publish.mjs`.
+> - **Seguido**: presente en el índice de git (`git ls-files` lo lista), con historial propio.
+> - **Puerta de deriva**: un paso de CI que REGENERA el artefacto y exige que
+>   `git status --porcelain` salga vacío sobre su ruta.
+> - **Consumidor externo**: algo que necesita el artefacto sin poder construirlo, por no tener las
+>   dependencias de desarrollo a mano.
+
+Esta regla NO habla de los ficheros con cabecera `@aurora-catalyst-generated` bajo `@app`/`@api`:
+esos son editables a mano y los reconcilia `.origin` — ver **HR-CODEGEN-001**. Aquí se trata de
+salida que nadie edita, solo se produce.
+
+> **Límite de la búsqueda `byPath`**: el esquema del catálogo solo admite rutas bajo
+> `backend|frontend|cliter|scripts|docs` (`docs/_catalog-schema-base.json`), así que
+> `packages/**`, `.github/workflows/**` y los `.gitignore` NO se pueden declarar aquí aunque la
+> regla los gobierne. Se llega a esta regla por `byKeyword` (`dist versionado`, `tracked dist`,
+> `puerta de deriva`, `artefacto generado`), no por la ruta del fichero que estés tocando.
+
+---
+
+## HR-ARTIFACTS-001 — Un artefacto generado no se versiona sin puerta de deriva
+
+| Campo     | Valor                                                                                                   |
+| --------- | ------------------------------------------------------------------------------------------------------- |
+| Estado    | `active`                                                                                                |
+| Severidad | `informational`                                                                                         |
+| Origen    | sesión 2026-09-16: 816 ficheros de `packages/core-back/dist` seguidos sin puerta; PR #234 los desindexa |
+
+### Enunciado
+
+Un artefacto generado está en UNO de dos estados, y el tercero está prohibido:
+
+1. **No seguido.** Es el estado por defecto. Lo produce la instalación (`"prepare": "pnpm run build"`
+   del propio paquete) o un paso de build bajo demanda. Su ruta está en un `.gitignore` que se
+   cumple de verdad.
+2. **Seguido CON puerta de deriva.** Solo cuando un consumidor externo lo necesita sin poder
+   construirlo. Entonces CI regenera el artefacto en cada pull request y falla si queda alguna
+   diferencia.
+
+**Prohibido: seguido SIN puerta.** Son dos copias de la misma cosa dentro de git y nada que
+compruebe que siguen coincidiendo. La deriva no avisa: aparece como un error de tipos en el
+consumidor sobre un símbolo que está a la vista en el código fuente.
+
+Un `.gitignore` NO es la puerta, ni prueba el estado 1. Git no desindexa lo que ya estaba dentro
+cuando se escribió la regla, así que una ruta puede estar ignorada y seguida a la vez, durante años,
+sin que nada lo señale. El estado se comprueba con `git ls-files <ruta> | wc -l`, nunca leyendo el
+`.gitignore`.
+
+### Casos exhaustivos
+
+| #   | Situación                                                                                          | ¿Permitido? | Acción correcta                                                                                                                                                              |
+| --- | -------------------------------------------------------------------------------------------------- | ----------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| 1   | Salida de build de un paquete del workspace que solo consumen este repo, CI y los slots             | NO seguirla | Dejar que el `prepare` del paquete la produzca en cada `pnpm install`. Es el caso de `packages/core-back/dist` y `packages/core-front/dist`.                                    |
+| 2   | Espejo que un consumidor externo lee sin construir nada                                             | SÍ, con puerta | Seguirlo Y añadir el paso de CI que lo regenera y exige `git status --porcelain` vacío. Es el caso de `packages/cli/src/templates/{backend,frontend,monorepo}`.               |
+| 3   | Seguir un artefacto "para que no haya que construirlo" sin añadir puerta                            | **NO**      | O se justifica un consumidor externo y se añade la puerta, o no se sigue. La comodidad no es una de las dos condiciones.                                                       |
+| 4   | Añadir la ruta al `.gitignore` y dar por hecho que ya no se versiona                                | **NO**      | Medir con `git ls-files`. Si devuelve ficheros, hace falta además `git rm -r --cached <ruta>`.                                                                                  |
+| 5   | Desindexar un artefacto que los consumidores resuelven en tiempo de ejecución                        | SÍ, con red | El commit BORRA esos ficheros del disco de todo el mundo sin tocar ninguna fuente. Hace falta que algo los reconstruya al traerlo — en este repo, `scripts/rebuild-core-packages.sh` desde `post-merge`/`post-checkout`. |
+| 6   | Añadir una puerta de deriva que corra fuera de pull request                                          | **NO**      | Las puertas de este repositorio corren en PR. Una comprobación posterior al merge deja una ventana en la que `main` ya está derivada, y nadie sabría leerla cuando falle.      |
+
+### Anchor patterns
+
+Un futuro guard debe vigilar:
+
+- Una ruta que aparezca a la vez en un `.gitignore` y en `git ls-files`. Es el estado prohibido, y es
+  silencioso: así estuvieron los 816 ficheros de `packages/core-back/dist`.
+- Un pull request que añada salida de build al índice sin tocar `.github/workflows/`. Seguir sin
+  puerta.
+- Una propuesta que resuelva una deriva construyendo en `main` después del merge, o con un bot que
+  empuje el artefacto regenerado. Caso 6.
+- Un `git rm -r --cached` sobre un artefacto que se resuelve en tiempo de ejecución, sin nada que lo
+  reconstruya al hacer `pull`. Caso 5.
+
+### Reglas relacionadas
+
+- **HR-CODEGEN-001** — el otro sentido de "generado": ficheros con cabecera
+  `@aurora-catalyst-generated` que SÍ se editan a mano y reconcilia `.origin`. Esta regla no los
+  gobierna.
+- **HR-DOCS-001** — misma familia de disciplina: un artefacto con un sitio declarado y una
+  comprobación que lo sostiene.