@ronaldjdevfs/forge 1.2.0 → 1.3.1

package/skills/forge/reference/architecture-template.md

@@ -0,0 +1,41 @@
+# Architecture State
+
+- Project Name: <name>
+- Framework: <detectado>
+- Runtime: <detectado>
+- Database: <detectado>
+- ORM: <detectado>
+- DI Strategy: <detectado>
+- Profile: <detectado>
+- Architecture: hexagonal-feature (Platform + Features + Shared + Infra)
+- Last Audit: <fecha> (score: <puntaje>)
+
+## Platform
+- platform/config/
+- platform/server/
+...
+
+## Features
+- features/users/
+...
+
+## Shared
+- shared/errors/
+...
+
+## Infrastructure
+- infra/prisma/
+...
+
+## Ownership
+- Health: healthy | degraded | critical
+- Score: 0-100
+- Orphans: 0
+- Duplicates: 0
+- Misplaced: 0
+
+## Architecture Graph
+...
+
+## Dependency Health
+...

package/skills/forge/reference/assay.md

@@ -80,3 +80,9 @@ Se recomienda:
 3. Priorizar acciones basado en las recomendaciones
 4. Refactorizar con `reforge`, `temper`, o `smelt`
 5. Repetir el ciclo
+
+## Ver también
+
+- `reference/inspect.md` — el reporte que alimenta el ensayo
+- `reference/adr.md` — ADRs como insumo para las opiniones de cada persona
+- `reference/principles.md` — principios contra los que assay contrasta las decisiones

package/skills/forge/reference/bounded-contexts.md

@@ -0,0 +1,311 @@
+# Bounded Contexts — DDD Estratégico
+
+Las features de Forge se corresponden con bounded contexts. Sin esta correspondencia, `src/features/<name>/` son solo directoríos con código agrupado por nombre, no unidades con integridad de dominio.
+
+---
+
+## Fundamentos de DDD Estratégico
+
+### Dominio y Subdominios
+
+El **dominio** es el área de actividad que el sistema modela. Se divide en tres tipos de **subdominio**:
+
+| Tipo | Características | Ejemplo en e-commerce |
+|---|---|---|
+| **Core** | Ventaja competitiva, complejo, hecho en casa | Pricing engine, recomendaciones |
+| **Supporting** | Necesario pero no diferenciador, puede externalizarse | Inventario, catálogo |
+| **Generic** | Commodity, comprar o usar OSS | Auth, notificaciones, pagos |
+
+Un **bounded context** es un límite explícito dentro del cual un modelo de dominio específico es consistente. Fuera del contexto, el mismo término puede tener significado distinto.
+
+```ts
+// En el contexto de "Catalog", Product tiene precio, descripción, imágenes
+// En el contexto de "Inventory", Product tiene SKU, stock, warehouse location
+// En el contexto de "Orders", Product tiene orderLine, quantity, status
+// Son tres modelos distintos para el mismo concepto del mundo real
+```
+
+### Ubiquitous Language
+
+Cada bounded context tiene su propio lenguaje ubicuo, compartido por el equipo de desarrollo y los expertos de negocio.
+
+**Reglas del lenguaje ubicuo:**
+- Los nombres de clases, métodos y módulos reflejan el lenguaje del negocio, no el lenguaje técnico
+- No hay traducción entre "lo que el negocio dice" y "lo que el código llama"
+- Si el negocio dice "Order" → la entidad se llama `OrderEntity`, no `OrderRecord` ni `OrderDoc`
+- Si el negocio dice "cancelar pedido" → el caso de uso se llama `CancelOrderUseCase`, no `OrderDeleterService`
+- Las discrepancias de lenguaje entre contexts son señales de límites válidos
+
+**Conflicto de lenguaje como herramienta:** cuando dos personas del equipo usan la misma palabra con significado distinto (ej. "cliente" significa "usuario registrado" para marketing y "cuenta corporativa" para billing), hay dos bounded contexts esperando ser descubiertos.
+
+---
+
+## Context Mapping
+
+Cada bounded context se relaciona con otros mediante relaciones explícitas. Estos son los 8 patrones del Context Mapping:
+
+### Partnership
+
+Dos contexts cooperan para entregar un flujo. Si uno falla, el otro también.
+
+```
+[Orders] ←→ [Inventory]
+```
+
+- Relación bidireccional
+- Coordinación frecuente entre equipos
+- Acoplamiento temporal tolerado
+- Útil para flujos transaccionales críticos (checkout)
+
+### Shared Kernel
+
+Comparten un subconjunto pequeño y estable del modelo.
+
+```
+[Orders] ← kernel: Customer, Money → [Billing]
+```
+
+- El kernel compartido está en `src/shared/contracts/`
+- Solo datos, no lógica de negocio
+- El kernel se mantiene por acuerdo entre equipos
+- Cambios requieren coordinación y tests
+- Si crece demasiado, es señal de que los contexts deberían fusionarse
+
+### Customer-Supplier
+
+Un contexto upstream provee datos que el downstream consume. El upstream gana.
+
+```
+[CRM] → [Marketing]  (CRM dicta el contrato)
+```
+
+- Upstream (supplier) define el contrato
+- Downstream (customer) se adapta
+- El downstream debe implementar una ACL si el upstream no cubre sus necesidades
+- Relación unidireccional
+
+### Conformist
+
+El downstream acepta el modelo del upstream sin cuestionarlo.
+
+```
+[SAP] → [Reporting]  (Reporting se adapta al modelo de SAP)
+```
+
+- Sin traducción: el downstream usa el modelo del upstream directamente
+- Útil cuando el upstream es un sistema externo commodity
+- Riesgo de corrupción del modelo de dominio downstream si el upstream cambia
+
+### Anti-Corruption Layer (ACL)
+
+El downstream protege su modelo con una capa de traducción.
+
+```
+[CRM Legacy] → [ACL] → [Orders]
+```
+
+- La ACL traduce del modelo legacy al modelo de dominio de Orders
+- Ver `reference/anti-corruption-layer.md`
+- Patrón obligatorio cuando se integra un sistema legacy o externo en un core domain
+
+### Open-Host Service
+
+El upstream expone un protocolo/shareable al que los downstreams se suscriben.
+
+```
+[Catalog] ── OHS (Published Language) ──→ [Search]
+                                          ──→ [Recommendations]
+                                          ──→ [Pricing]
+```
+
+- El upstream publica un Published Language (API, eventos, contratos compartidos)
+- Múltiples downstreams consumen sin coordinar entre sí
+- Es la relación ideal para la capa `adapter/out/` de una feature exponiendo eventos
+
+### Published Language
+
+El lenguaje compartido que el OHS usa. Puede ser:
+- Contratos TypeScript en `src/shared/contracts/`
+- Eventos de dominio con schema versionado
+- OpenAPI spec como contrato HTTP
+- Protobuf / Avro schemas
+
+Los contratos publicados deben ser:
+- Versionados (`src/shared/contracts/catalog/v1/`, `v2/`)
+- Inmutables una vez publicados
+- Documentados con ejemplos
+- Validados con tests de compatibilidad
+
+### Separate Ways
+
+Dos contexts no tienen relación. Cada uno modela su solución independientemente.
+
+```
+[Notifications]   [Analytics]
+(no se hablan)
+```
+
+- Válido cuando no hay solapamiento funcional
+- Forzado por R8 (no imports directos entre features): por defecto, toda feature que no comparte contratos está en Separate Ways con las demás
+
+---
+
+## Identificación de Bounded Contexts
+
+### Heurísticas prácticas
+
+| Señal | Pregunta guía |
+|---|---|
+| **Equipo** | ¿Otro equipo podría ser dueño de esto? |
+| **Lenguaje** | ¿Usan las mismas palabras con el mismo significado? |
+| **Modelo** | ¿La misma entidad tiene atributos o comportamientos distintos? |
+| **Frecuencia de cambio** | ¿Una parte del sistema cambia a ritmo distinto que otra? |
+| **Base de datos** | ¿Podría tener su propio schema o base de datos? |
+| **Deploy** | ¿Podría deployarse independientemente? |
+| **Fallo** | ¿Un fallo aquí no debería afectar a otras partes? |
+
+### Regla práctica de Forge
+
+Si puedes nombrar un directorio `src/features/<name>/` y describir qué hace sin usar términos de otra feature, tienes un bounded context candidato.
+
+Si necesitas decir "esto es parte de X pero usa el modelo de Y" o "comparte la BD con Z", el context mapping está mal definido.
+
+---
+
+## Mapeo Visual
+
+Un diagrama de contextos muestra los bounded contexts como cajas y las relaciones como flechas etiquetadas.
+
+```
+┌──────────────────────────────────────────────────────┐
+│                   E-Commerce System                    │
+│                                                        │
+│  ┌──────────┐  SK  ┌──────────┐  OHS    ┌──────────┐ │
+│  │  Orders  │◄────►│ Catalog  ├────────►│  Search  │ │
+│  └────┬─────┘      └──────────┘         └──────────┘ │
+│       │                     │                         │
+│       │PS                   │PL                        │
+│       ▼                     ▼                          │
+│  ┌──────────┐         ┌──────────┐                     │
+│  │Inventory │         │  Pricing │                     │
+│  └──────────┘         └──────────┘                     │
+│       │                                                │
+│       │CS                                               │
+│       ▼                                                │
+│  ┌──────────┐                                          │
+│  │Shipping  │                                          │
+│  └──────────┘                                          │
+│                                                        │
+│  ┌──────────┐  SW     ┌──────────┐                     │
+│  │  Auth    │         │Analytics │                     │
+│  └──────────┘         └──────────┘                     │
+└────────────────────────────────────────────────────────┘
+
+Leyenda:
+  SK  = Shared Kernel
+  OHS = Open-Host Service (vía Published Language)
+  PS  = Partnership
+  PL  = Published Language (unidirectional OHS)
+  CS  = Customer-Supplier
+  SW  = Separate Ways
+```
+
+---
+
+## Relación con el Modelo de Forge
+
+Cada `src/features/<name>/` mapea a (parte de) un bounded context.
+
+| Regla | Relación con bounded contexts |
+|---|---|
+| **R8** (no cross-feature imports) | Enforces Separate Ways entre contexts. Si dos features necesitan comunicarse, debe ser vía Published Language (contratos en shared/) o Partnership (interfaces inyectadas). |
+| **R9** (no ciclos) | Los ciclos entre contexts indican que el context mapping está mal: dos contexts que se necesitan mutuamente deberían fusionarse o introducir un tercer contexto mediador. |
+| **R2** (platform → feature) | Platform es un contexto genérico que sirve a todos. No debe invertirse. |
+| **R4** (shared → infra) | Shared kernel debe ser puro. Si shared necesita infra, el kernel está contaminado. |
+
+### La feature como bounded context implementado
+
+```
+src/features/orders/
+  domain/              ← Modelo del contexto Orders
+    entities/
+    events/
+    repositories/      ← Puertos
+  application/
+    use-cases/         ← Flujos del contexto Orders
+    mappers/           ← Traducción dentro del contexto
+  adapters/
+    in/http/           ← Entrada: Open-Host Service (API REST)
+    out/persistence/   ← Salida: repositorio concreto
+    out/events/        ← Salida: eventos publicados (Published Language)
+```
+
+---
+
+## Anti-patrones
+
+| Anti-patrón | Problema | Solución |
+|---|---|---|
+| **Contexto gigante (Orphan Core)** | Un solo contexto contiene todo el core domain. No hay límites. | Dividir por subdominio. Si duele partir, empezar por los flujos que cambian a ritmo distinto. |
+| **Contexto fantasma** | Un bounded context declarado que no tiene modelo propio. Solo llama APIs de otros contexts. | Fusionar con el contexto que realmente tiene el modelo o eliminarlo. |
+| **Contexto sin lenguaje** | El código usa nombres técnicos (UserService, DataManager, TransactionHelper). No hay rastro del lenguaje del negocio. | Hacer event storming con el equipo de negocio. Renombrar todo para reflejar el lenguaje ubícuo. |
+| **Shared Kernel gigante** | Los contratos compartidos crecen sin control porque es más fácil poner algo en shared que diseñar el límite. | Forzar revisión en cada PR de shared/contracts/. Shared kernel debe ser minimalista y estable. |
+| **Contexto anémico** | Un contexto que solo tiene CRUD y getters/setters. Sin reglas de negocio ni invariantes. | Preguntar: ¿qué reglas de negocio existen aquí? Si la respuesta es "ninguna", probablemente el contexto debería ser un subdominio genérico resuelto con infraestructura (CRUD framework). |
+
+---
+
+## Ejemplo Completo
+
+Sistema de e-commerce con 4 bounded contexts:
+
+**Catalog** (Supporting)
+- Modelo: `Product`, `Category`, `Price`
+- Lenguaje: producto, categoría, precio de lista, variante
+- Persistencia: PostgreSQL
+- Relaciones: OHS → Search (Published Language), CS → Pricing (provee precios base)
+
+**Orders** (Core)
+- Modelo: `Order`, `OrderLine`, `Payment`, `Shipment`
+- Lenguaje: pedido, línea, pago, envío, cancelación, reembolso
+- Persistencia: PostgreSQL (propio schema)
+- Relaciones: Partnership ↔ Inventory, CS → Shipping, consume eventos de Catalog (Published Language)
+
+**Inventory** (Supporting)
+- Modelo: `Stock`, `Warehouse`, `Movement`
+- Lenguaje: stock, almacén, entrada, salida, reserva
+- Persistencia: PostgreSQL
+- Relaciones: Partnership ↔ Orders, CS → Shipping (provee peso/volumen)
+
+**Search** (Generic, con Elasticsearch)
+- Modelo: `SearchableProduct` (read model desnormalizado de Catalog)
+- Lenguaje: búsqueda, filtro, índice, relevancia
+- Persistencia: Elasticsearch
+- Relaciones: consume OHS de Catalog
+- No tiene relaciones de salida: es puramente un contexto de lectura
+
+```
+Decisiones arquitectónicas reflejadas:
+- Catalog y Search están separados porque tienen distinta frecuencia de cambio y stack
+- Orders e Inventory en Partnership porque el checkout necesita coordinación transaccional
+- Catalog como OHS permite que Search, Pricing y Recommendations consuman sin acoplar
+- No hay ACL porque ningún legacy está involucrado (todos los contexts son nuevos)
+```
+
+---
+
+## Conexión con Forge
+
+| Comando | Acción |
+|---|---|
+| `forge cast` | Crea una nueva feature que se corresponde con un nuevo bounded context o subdomino |
+| `forge inspect` | Detecta violaciones de límites entre contexts (R8, R9) |
+| `forge graph` | Visualiza los bounded contexts y sus relaciones como grafo arquitectónico |
+| `forge relocate` | Migra código entre contexts o extrae un contexto de un monolito legacy |
+| `forge assay` | Evalúa cualitativamente la integridad de los límites entre contexts |
+
+## Ver también
+
+- `reference/modular-monolith.md` — contexto como unidad del monolith
+- `reference/anti-corruption-layer.md` — protección de límites entre contexts
+- `reference/cqrs.md` — separación command/query dentro de un context
+- `reference/sagas.md` — coordinación entre contexts

package/skills/forge/reference/chain.md

@@ -71,3 +71,9 @@ node .opencode/skills/forge/scripts/architecture.mjs
 - Si hay ciclo, extraer la interfaz común a shared/
 - Documentar dependencias en ARCHITECTURE.md
 - Revisar dependencias después de cada migración
+
+## Ver también
+
+- `scripts/graph.mjs` — el grafo que chain analiza topológicamente
+- `reference/evolutionary-architecture.md` — fitness functions de dependencias
+- `reference/modular-monolith.md` — ciclo de dependencias como señal de split

package/skills/forge/reference/cohesion-checklist.md

@@ -0,0 +1,256 @@
+# Cohesion — Checklist de Referencias Cruzadas
+
+Checklist para llevar la cohesión del corpus de referencias de ~8.5/10 a 10/10. Cada entrada detalla el archivo, los enlaces que debe añadir y el estado actual.
+
+---
+
+## Estado actual
+
+```
+[x] F1 — Enlazar 7 archivos huérfanos (0 entrantes + 0 salientes)
+[x] F2 — Completar backlinks de las 10 referencias estratégicas
+[x] F3 — Cerrar 6 lagunas de referenciación
+[x] F4 — Asegurar bidireccionalidad entre pares
+```
+
+---
+
+## F1 — Huérfanos con "Ver también"
+
+7 archivos que actualmente tienen 0 enlaces entrantes y 0 enlaces salientes dentro del corpus.
+
+### F1.1 — `assay.md`
+
+- [ ] Añadir "Ver también" al final:
+  - `reference/inspect.md` — el reporte que assay evalúa cualitativamente
+  - `reference/adr.md` — ADRs como insumo para las opiniones de cada persona
+  - `reference/principles.md` — principios contra los que assay contrasta las decisiones
+  - `reference/sagas.md`, `reference/cqrs.md` — patrones que assay puede evaluar
+
+### F1.2 — `chain.md`
+
+- [ ] Añadir "Ver también" al final:
+  - `scripts/graph.mjs` — el grafo que chain analiza topológicamente
+  - `reference/evolutionary-architecture.md` — fitness functions de dependencias
+  - `reference/modular-monolith.md` — ciclo de dependencias como señal de split
+
+### F1.3 — `di-strategies.md`
+
+- [ ] Añadir "Ver también" al final:
+  - `reference/temper.md` — endurecimiento de DI (complemento directo)
+  - `reference/patterns.md` — naming y convenciones de contenedor DI
+  - `reference/testing-patterns.md` — mocks y DI testing
+
+### F1.4 — `forge.md`
+
+- [ ] Añadir "Ver también" al final:
+  - `reference/bounded-contexts.md` — identificación de contexts al inicializar
+  - `reference/modular-monolith.md` — decisión de estructura al iniciar proyecto
+  - `reference/principles.md` — principios que guían la inicialización
+  - `reference/evolutionary-architecture.md` — bootstrap como primer paso evolutivo
+
+### F1.5 — `hooks.md`
+
+- [ ] Añadir "Ver también" al final:
+  - `reference/quench.md` — validación que el hook ejecuta en pre-commit
+  - `reference/evolutionary-architecture.md` — fitness functions como hook
+  - `reference/adr.md` — ADRs como insumo para validación en hook
+  - `reference/detect.mjs` — script que el hook invoca
+
+### F1.6 — `smelt.md`
+
+- [ ] Añadir "Ver también" al final:
+  - `reference/relocate.md` — operación similar de extracción
+  - `reference/data-patterns.md` — identificación de qué extraer a shared
+  - `reference/errors.md` — errores tipados como candidatos a smelt
+
+### F1.7 — `temper.md`
+
+- [ ] Añadir "Ver también" al final:
+  - `reference/di-strategies.md` — selección de estrategia DI antes de temperar
+  - `reference/patterns.md` — convenciones de naming en DI
+  - `reference/testing-patterns.md` — testabilidad que DI disciplinada habilita
+
+---
+
+## F2 — Backlinks de referencias estratégicas
+
+Backlinks faltantes desde las referencias existentes hacia las 10 nuevas.
+
+### F2.1 — `modular-monolith.md`
+
+Backlinks esperados: relocate, reforge, cast
+
+| Desde | Estado | Acción |
+|---|---|---|
+| `relocate.md` | ✅ Ya enlaza | — |
+| `reforge.md` | ✅ Ya enlaza | — |
+| `cast.md` | ✅ Ya enlaza | — |
+
+### F2.2 — `adr.md`
+
+Backlinks esperados: reforge, cast, inscribe
+
+| Desde | Estado | Acción |
+|---|---|---|
+| `reforge.md` | ✅ Ya enlaza | — |
+| `cast.md` | ✅ Ya enlaza | — |
+| `inscribe.md` | ✅ Ya enlaza | — |
+
+### F2.3 — `anti-corruption-layer.md`
+
+Backlinks esperados: relocate, reforge, cast
+
+| Desde | Estado | Acción |
+|---|---|---|
+| `relocate.md` | ✅ Ya enlaza | — |
+| `reforge.md` | ✅ Ya enlaza | — |
+| `cast.md` | ✅ Ya enlaza | — |
+
+### F2.4 — `evolutionary-architecture.md`
+
+Backlinks esperados: inspect, reforge, quench, graph
+
+| Desde | Estado | Acción |
+|---|---|---|
+| `inspect.md` | ✅ Ya enlaza | — |
+| `reforge.md` | ✅ Ya enlaza | — |
+| `quench.md` | ✅ Ya enlaza | — |
+| `graph.md` | ✅ No existe en reference/ | No-op |
+
+### F2.5 — `cqrs.md`
+
+Backlinks esperados: data-patterns, events, cast
+
+| Desde | Estado | Acción |
+|---|---|---|
+| `data-patterns.md` | ✅ Ya enlaza | — |
+| `events.md` | ✅ Ya enlaza | — |
+| `cast.md` | ✅ Ya enlaza | — |
+
+### F2.6 — `sagas.md`
+
+Backlinks esperados: events, cast
+
+| Desde | Estado | Acción |
+|---|---|---|
+| `events.md` | ✅ Ya enlaza | — |
+| `cast.md` | ✅ Ya enlaza | — |
+
+### F2.7 — `transactional-outbox.md`
+
+Backlinks esperados: events, idempotency, sagas
+
+| Desde | Estado | Acción |
+|---|---|---|
+| `events.md` | ✅ Ya enlaza | — |
+| `idempotency.md` | ✅ Ya enlaza | — |
+| `sagas.md` | ✅ Ya enlaza | — |
+
+### F2.8 — `idempotency.md`
+
+Backlinks esperados: api-design, events, sagas, transactional-outbox
+
+| Desde | Estado | Acción |
+|---|---|---|
+| `api-design.md` | ✅ Ya enlaza | — |
+| `events.md` | ✅ Ya enlaza | — |
+| `sagas.md` | ✅ Ya enlaza | — |
+| `transactional-outbox.md` | ✅ Ya enlaza | — |
+
+### F2.9 — `api-versioning.md`
+
+Backlinks esperados: api-design, patterns, cast, reforge
+
+| Desde | Estado | Acción |
+|---|---|---|
+| `api-design.md` | ✅ Ya enlaza | — |
+| `patterns.md` | ✅ Ya enlaza | — |
+| `cast.md` | ✅ Ya enlaza | — |
+| `reforge.md` | ✅ Ya enlaza | — |
+
+### F2.10 — `bounded-contexts.md`
+
+Backlinks esperados: modular-monolith, anti-corruption-layer, cqrs, sagas, cast, reforge, relocate
+
+| Desde | Estado | Acción |
+|---|---|---|
+| `modular-monolith.md` | ✅ Ya enlaza | — |
+| `anti-corruption-layer.md` | ✅ Ya enlaza | — |
+| `cqrs.md` | ✅ Ya enlaza | — |
+| `sagas.md` | ✅ Ya enlaza | — |
+| `cast.md` | ✅ Ya enlaza | — |
+| `reforge.md` | ✅ Ya enlaza | — |
+| `relocate.md` | ✅ Ya enlaza | — |
+
+**Único pendiente F2:**
+- [x] `graph.md` → no existe en reference/ — no-op
+
+---
+
+## F3 — Lagunas de referenciación
+
+Conceptos mencionados en una referencia pero sin enlace a la referencia dedicada.
+
+### F3.1 — `assay.md`
+
+- [ ] Donde menciona "violaciones" y "auditoría", enlazar a `reference/inspect.md`
+
+### F3.2 — `chain.md`
+
+- [ ] Donde habla de "dependencias" y "ciclos", enlazar a `scripts/graph.mjs` y `reference/evolutionary-architecture.md`
+
+### F3.3 — `forge.md`
+
+- [ ] Donde menciona "perfil tecnológico" y "bootstrapping", enlazar a `reference/bounded-contexts.md` y `reference/modular-monolith.md`
+
+### F3.4 — `hooks.md`
+
+- [ ] Donde menciona "validación arquitectónica" y "pre-commit", enlazar a `reference/quench.md` y `reference/evolutionary-architecture.md`
+
+### F3.5 — `security-patterns.md`
+
+- [ ] Donde menciona "middleware" y "AuthN/AuthZ", enlazar a `reference/api-design.md`
+
+### F3.6 — `testing-patterns.md`
+
+- [ ] Donde menciona "tests de adapters" y "ACL", enlazar a `reference/anti-corruption-layer.md`
+
+---
+
+## F4 — Bidireccionalidad
+
+Pares donde existe enlace A→B pero falta B→A.
+
+### Pares incompletos
+
+| A | B | A→B | B→A | Acción |
+|---|---|---|---|---|
+| `bounded-contexts.md` | `anti-corruption-layer.md` | ✅ | ✅ | — |
+| `bounded-contexts.md` | `modular-monolith.md` | ✅ | ✅ | — |
+| `bounded-contexts.md` | `cqrs.md` | ✅ | ✅ | — |
+| `bounded-contexts.md` | `sagas.md` | ✅ | ✅ | — |
+| `modular-monolith.md` | `evolutionary-architecture.md` | ✅ | ✅ | — |
+| `sagas.md` | `transactional-outbox.md` | ✅ | ✅ | — |
+| `sagas.md` | `idempotency.md` | ✅ | ✅ | — |
+| `idempotency.md` | `transactional-outbox.md` | ✅ | ✅ | — |
+| `evol-arch.md` | `adr.md` | ✅ | ✅ | — |
+| `api-design.md` | `api-versioning.md` | ✅ | ✅ | — |
+
+- [x] **Verificar que todos los pares anteriores son bidireccionales.** Leer cada archivo y confirmar que si A enlaza a B, B también enlaza a A (o al menos a la categoría de A).
+
+---
+
+## Criterio de completitud (10/10)
+
+- [x] **Cero enlaces rotos** — ✅
+- [x] **Cero huérfanos** — ✅ (33/35 archivos tienen ≥1 enlace saliente a otro reference/; solo help.md y architectural-depth-checklist.md, ambos intencionales)
+- [x] **Cero backlinks perdidos** — ✅ (todas las referencias estratégicas tienen backlinks)
+- [x] **Formato consistente** — ✅ (28 archivos con `## Ver también`, 0 con inline `Ver también:`)
+- [x] **Bidireccionalidad ≥ 90%** — ✅ (33/35 archivos tienen backlinks)
+
+---
+
+## Integración en SKILL.md
+
+- [x] Añadir `reference/cohesion-checklist.md` al Module Index