@ronaldjdevfs/forge 1.0.1

package/skills/forge/reference/forge.md

@@ -0,0 +1,44 @@
+# Forge
+
+Inicializa un proyecto para trabajar con Forge como Backend Architecture Operating System.
+
+## Cuándo usarlo
+
+- Proyecto nuevo sin estructura definida
+- Proyecto existente sin `ARCHITECTURE.md`
+- Después de clonar un repositorio
+- Para bootstrappear los layers Platform, Shared e Infrastructure
+
+## Flujo
+
+1. Ejecutar `scripts/context.mjs` para detectar stack actual (incluye platform, features, shared, infra)
+2. Ejecutar `scripts/bootstrap.mjs` para crear layers faltantes (platform, shared, infra)
+3. Ejecutar `scripts/profile.mjs` para determinar perfil tecnológico
+4. Ejecutar `scripts/armorer.mjs` para detectar ownership y huérfanos
+5. Ejecutar `scripts/graph.mjs` para construir grafo arquitectónico global
+6. Ejecutar `scripts/chain.mjs` para analizar dependencias multi-capa
+7. Si `ARCHITECTURE.md` no existe, crearlo con `forge inscribe`
+8. Si faltan dependencias clave (según perfil), listarlas
+9. Si el proyecto tiene código legacy, sugerir `forge relocate`
+10. Si el proyecto está listo, sugerir `forge cast`
+
+## Output esperado
+
+- `ARCHITECTURE.md` creado en la raíz del proyecto
+- Layers Platform, Shared e Infrastructure creados si no existían
+- Perfil tecnológico detectado y registrado
+- Ownership analizado
+- Dependencias base verificadas
+- Próximos pasos sugeridos según el estado del proyecto
+
+## Severidades
+
+| Condición | Severidad |
+|---|---|
+| Sin `src/` directory | ERROR |
+| Sin `package.json` | ERROR |
+| Sin perfil detectable | WARNING |
+| Sin `ARCHITECTURE.md` | INFO |
+| Platform layer ausente | SUGGESTION |
+| Dependencias faltantes | WARNING |
+| Ownership con huérfanos | WARNING |

package/skills/forge/reference/inscribe.md

@@ -0,0 +1,129 @@
+# Inscribe
+
+Genera y mantiene el archivo `ARCHITECTURE.md` del proyecto.
+
+## Cuándo usarlo
+
+- Proyecto nuevo (crear ARCHITECTURE.md inicial)
+- Después de migrar un feature (actualizar estado)
+- Después de refactorizar (actualizar decisiones)
+- Cuando se detecta que ARCHITECTURE.md está desactualizado
+- On demand: `forge inscribe`
+
+## Formato generado
+
+```md
+# Architecture State
+
+**Project Name:** <detectado>
+**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/database/
+- platform/http/
+- platform/logger/
+
+## Features
+- features/users/
+- features/payments/
+
+## Shared
+- shared/errors/
+- shared/types/
+- shared/utils/
+
+## Infrastructure
+- infra/prisma/
+- infra/redis/
+
+## Ownership
+**Health:** healthy | degraded | critical
+**Score:** 85/100
+**Orphans:** 0
+**Duplicates:** 0
+**Misplaced:** 0
+
+## Architecture Graph
+**Nodes:** 15
+**Edges:** 20
+**Risk Score:** 12/100
+**Health:** healthy
+**Dependency Health:** 95%
+
+### Platform Layer
+- `platform:config` — config
+
+### Feature Layer
+- `feature:users` — users
+
+### Shared Layer
+- `shared:errors` — errors
+
+### Infrastructure Layer
+- `infra:prisma` — prisma
+
+### Domain Layer
+- `domain:users` — users/domain
+
+### Adapter Layer
+- `adapter:users` — users/adapters
+
+### Violations
+| Rule | From | To | Severity | Description |
+|------|------|----|----------|-------------|
+| R1 | `feature:users` | `infra:prisma` | CRITICAL | Features no acceden infraestructura directamente |
+
+### Dependency Graph
+- `feature:users` → [domain:users, adapter:users]
+
+## Dependency Health
+**Valid Edges:** 19/20
+**Dependency Health:** 95%
+**Risk Score:** 12/100
+**Health:** healthy
+
+## Violations
+...
+
+## Context
+...
+
+## Tech Stack
+...
+```
+
+## Campos auto-detectados
+
+| Campo | Fuente |
+|---|---|
+| Framework | `scripts/context.mjs` |
+| Database | `scripts/context.mjs` |
+| ORM | `scripts/context.mjs` |
+| DI Strategy | `scripts/context.mjs` |
+| Active Profile | `scripts/profile.mjs` |
+| Platform | `scripts/context.mjs` → platform |
+| Features | `scripts/context.mjs` → features |
+| Shared | `scripts/context.mjs` → shared |
+| Infra | `scripts/context.mjs` → infra |
+| Ownership | `scripts/armorer.mjs` |
+| Architecture Graph | `scripts/graph.mjs` |
+| Risk Score | `scripts/graph.mjs` → stats.riskScore |
+| Violations | `scripts/graph.mjs` → violations |
+| Last Audit | `scripts/inspect.mjs` → fecha + score |
+
+## Reglas
+
+- ARCHITECTURE.md se guarda en la raíz del proyecto
+- Forge lo lee antes de cada ejecución
+- Si está desactualizado (última auditoría > 7 días), Forge sugiere actualizarlo
+- Se actualiza automáticamente después de cada comando
+- No editar manualmente los campos auto-detectados
+- Forge preserva cualquier sección adicional que el usuario agregue

package/skills/forge/reference/inspect.md

@@ -0,0 +1,58 @@
+# Inspect
+
+Inspecciona la conformidad arquitectónica del proyecto.
+
+## Cuándo usarlo
+
+- Diagnóstico inicial del proyecto
+- Post-migración de feature
+- On demand para verificar estado actual
+- Pre-deploy para garantizar calidad arquitectónica
+
+## Flujo
+
+1. Ejecutar `scripts/context.mjs` → detectar stack y estructura
+2. Ejecutar `scripts/profile.mjs` → determinar perfil activo
+3. Ejecutar `scripts/chain.mjs` → construir cadena de dependencias
+4. Ejecutar `scripts/detect.mjs` → detectar todas las violaciones
+5. Construir reporte con puntuación y severidades
+6. Mostrar resultado al usuario
+
+## Categorías
+
+| Categoría | Pts | Qué mide |
+|---|---|---|
+| Estructura | 30 | Features completos (domain, application, adapters) |
+| Capas | 25 | Imports prohibidos, lógica en controllers, BD directa |
+| Decoradores | 20 | @injectable y @inject presentes donde corresponde |
+| Legacy | 15 | Archivos residuales en ubicaciones antiguas |
+| Configuración | 10 | tsconfig, dependencias, reflect-metadata |
+| Grafo | 20 | Violaciones arquitectónicas (R1-R6), risk score, salud del grafo |
+
+## Severidades
+
+| Severidad | Significado | Ejemplo |
+|---|---|---|
+| CRITICAL | Viola principio fundamental de la arquitectura | Domain importa de adapters |
+| ERROR | Viola una regla de capas o estructura | Controller con lógica de negocio |
+| WARNING | Inconsistencia que requiere atención | Feature sin repository interface |
+| INFO | Observación sobre el estado actual | Feature incompleto |
+| SUGGESTION | Recomendación de mejora | Usar tokens de clase en @inject |
+
+## Interpretación del score
+
+| Rango | Nota | Significado |
+|---|---|---|
+| 90-100 | A | Arquitectura sólida. Cumple todos los principios. |
+| 80-89 | B | Inconsistencias menores. Fáciles de corregir. |
+| 65-79 | C | Varias violaciones. Requiere trabajo estructurado. |
+| 50-64 | D | Arquitectura comprometida. Migración necesaria. |
+| 0-49 | F | Proyecto no migrado o con violaciones generalizadas. |
+
+## Ejecución
+
+```bash
+node .opencode/skills/forge/scripts/inspect.mjs
+node .opencode/skills/forge/scripts/inspect.mjs --json
+node .opencode/skills/forge/scripts/detect.mjs --severity ERROR
+```

package/skills/forge/reference/patterns.md

@@ -0,0 +1,108 @@
+# Patterns — Naming Conventions
+
+## Global
+
+| Elemento | Formato | Ejemplo |
+|---|---|---|
+| Directorios | `kebab-case/` | `credit-card/`, `event-bus/` |
+| Archivos | `<PascalCase>.<artefacto>.ts` | `User.entity.ts` |
+| Interfaces | `I<PascalCase>.<artefacto>.ts` | `IUser.repository.ts` |
+| Use cases | `<Action>.uc.ts` | `CreateUser.uc.ts` |
+| Clases | `PascalCase` | `UserController`, `DatabaseConfig` |
+| Funciones/variables | `camelCase` | `formatDate`, `userService` |
+| Constantes | `UPPER_SNAKE_CASE` | `MAX_RETRY_COUNT` |
+| Tipos (type/interface puros) | `PascalCase` | `UserPayload`, `PaginatedResult` |
+| Enums | `PascalCase` | `UserRole`, `OrderStatus` |
+| Barrel files | `index.ts` | named exports, no `export default` |
+
+---
+
+## Platform Layer
+
+| Directorio | Archivos |
+|---|---|
+| `config/` | `App.config.ts`, `Env.config.ts`, `Database.config.ts` |
+| `server/` | `Server.ts`, `App.ts` |
+| `database/` | `Database.config.ts`, `Connection.ts` |
+| `http/` | `Router.ts`, `Auth.middleware.ts`, `Error.middleware.ts`, `RateLimiter.middleware.ts` |
+| `logger/` | `Logger.config.ts`, `Logger.service.ts` |
+| `cache/` | `Cache.config.ts`, `Cache.service.ts` |
+| `security/` | `Auth.middleware.ts`, `Encryption.service.ts` |
+| `events/` | `EventBus.ts`, `EventHandler.ts` |
+| `scheduler/` | `Scheduler.config.ts`, `Scheduler.service.ts` |
+| `observability/` | `Metrics.ts`, `Tracing.ts`, `Health.ts` |
+| `di/` | `Container.ts`, `Tokens.ts`, `Module.ts` |
+
+---
+
+## Feature Layer
+
+| Ruta | Archivo | Ejemplo |
+|---|---|---|
+| `domain/` | `<Name>.entity.ts` | `User.entity.ts` |
+| `domain/` | `I<Name>.repository.ts` | `IUser.repository.ts` |
+| `application/use-cases/` | `<Action>.uc.ts` | `CreateUser.uc.ts`, `GetUser.uc.ts` |
+| `application/mappers/` | `<Name>.mapper.ts` | `User.mapper.ts` |
+| `adapters/in/http/` | `<Name>.controller.ts` | `User.controller.ts` |
+| `adapters/in/http/` | `<Name>.routes.ts` | `User.routes.ts` |
+| `adapters/out/persistence/` | `<Name>.repository.ts` | `User.repository.ts` |
+| `adapters/out/persistence/` | `<Name>.schema.ts` | `User.schema.ts` |
+
+Estructura de directorios:
+
+```
+src/features/<feature-name>/
+├── domain/
+│   ├── <Domain>.entity.ts
+│   └── I<Domain>.repository.ts
+├── application/
+│   ├── use-cases/
+│   │   ├── Create<Domain>.uc.ts
+│   │   ├── Get<Domain>.uc.ts
+│   │   ├── List<Domain>.uc.ts
+│   │   ├── Update<Domain>.uc.ts
+│   │   └── Delete<Domain>.uc.ts
+│   └── mappers/
+│       └── <Domain>.mapper.ts
+└── adapters/
+    ├── in/http/
+    │   ├── <Domain>.controller.ts
+    │   └── <Domain>.routes.ts
+    └── out/persistence/
+        ├── <Domain>.repository.ts
+        └── <Domain>.schema.ts
+```
+
+---
+
+## Shared Layer
+
+| Directorio | Archivos | Ejemplo |
+|---|---|---|
+| `errors/` | `<Name>Error.ts` | `NotFoundError.ts`, `ValidationError.ts` |
+| `contracts/` | `I<Name>.ts` | `IPaginatedResponse.ts` |
+| `types/` | `<dominio>.types.ts` | `user.types.ts`, `api.types.ts` |
+| `utils/` | `<util>.ts` (camelCase) | `formatDate.ts`, `pagination.ts` |
+
+---
+
+## Infra Layer
+
+| Directorio | Archivos | Ejemplo |
+|---|---|---|
+| `prisma/` | `Prisma.client.ts`, `Prisma.service.ts` | — |
+| `mongodb/` | `Mongo.config.ts`, `<Name>.model.ts` | `User.model.ts` |
+| `redis/` | `Redis.config.ts`, `Redis.service.ts` | — |
+| `mail/` | `Mail.config.ts`, `Mail.service.ts` | — |
+| `s3/` | `S3.config.ts`, `S3.service.ts` | — |
+
+---
+
+## Export Conventions
+
+- Cada directorio expone un `index.ts` barrel con named exports
+- Usar `export * from "./<Name>.<artifact>.js"` en barrels
+- Preferir `export function` / `export class` sobre `export default`
+- Imports relativos dentro del mismo feature (`../../domain/`)
+- Path alias para cross-layer: `@/platform/`, `@/shared/`, `@/infra/`
+- Extension `.js` en imports (ESM compat): `import { X } from "./foo.js"`

package/skills/forge/reference/principles.md

@@ -0,0 +1,29 @@
+# Principles
+
+> Forge es una **disciplina arquitectónica**, no un template. Nace de la convicción de que el código limpio no se escribe, se forja. Combina **Arquitectura Hexagonal**, **DDD ligero** (sin sobreingeniería) y **vertical slices** para producir sistemas donde cada dominio de negocio es dueño absoluto de su destino. La inyección de dependencias no es un detalle técnico: es la herramienta que garantiza que el dominio nunca se contamine de infraestructura.
+
+## Principios Inquebrantables
+
+1. **Arquitectura hexagonal basada en features** — La unidad de organización es el feature, no la capa técnica. Cada dominio contiene su propio `domain/`, `application/` y `adapters/`. Las capas existen *dentro* de cada feature, no al revés.
+
+2. **DDD ligero, sin sobreingeniería** — Usa la terminología y estructura de Domain-Driven Design (entidades, repositorios, casos de uso) pero sin la rigidez académica. No crees "value objects" donde basta un `string`. No fuerces aggregate roots donde una interfaz limpia resuelve el problema. Pragmatismo sobre dogma.
+
+3. **Separación estricta entre dominio e infraestructura** — El dominio no sabe qué framework, base de datos o servicios externos existen. Las interfaces (puertos) están en `domain/`. Las implementaciones (adapters) están en `adapters/out/`. Esta frontera es la razón de ser de la arquitectura hexagonal.
+
+4. **Un feature es una unidad autónoma** — Todo lo que pertenece a un dominio vive dentro de `features/<name>/`. Entidades, repositorios, casos de uso, controladores, rutas, esquemas, mappers, DTOs. Si un archivo importa código de otro feature fuera de su directorio, la separación está rota.
+
+5. **Dependencias unidireccionales** — La flecha apunta SIEMPRE hacia adentro: `adapters → application → domain → (nada)`. Domain no importa nada. Application solo importa de domain y shared. Cualquier import que viole esto se rechaza en code review. No hay excepciones.
+
+6. **Cero lógica de negocio en controladores** — El controller parsea la request, llama al caso de uso, y responde. No valida reglas, no calcula montos, no decide flujos. Si hay un `if` con lógica de dominio en un controller, está en el lugar equivocado.
+
+7. **Cero acceso a BD fuera de infraestructura** — Los repositories son la ÚNICA puerta a la base de datos. Ningún use case, controller o servicio llama al ORM, toca esquemas o ejecuta queries directamente. Las operaciones de BD solo aparecen en los repositories.
+
+8. **Código explícito sobre código mágico** — Prefiere imports explícitos, inyección por constructor y tipos declarados sobre decoradores ocultos, proxies automáticos o registros implícitos. El código debe leerse de arriba a abajo y entender su flujo sin herramientas externas de análisis.
+
+9. **Inyección de dependencias disciplinada** — La inyección de dependencias es por constructor, sin service locators ni singletons globales. Si el proyecto es pequeño, DI manual basta. Si crece, usar el sistema de DI del framework o un contenedor externo. Nunca `container.resolve()` dentro de lógica de negocio.
+
+10. **Escalabilidad horizontal de features** — Agregar un nuevo feature NUNCA implica modificar un feature existente. Nuevo dominio = nuevo directorio `features/<name>/`, nuevos casos de uso, nuevos adapters. El acoplamiento entre features solo ocurre mediante inyección de interfaces, nunca con imports directos entre features.
+
+11. **El sistema es un grafo arquitectónico vivo** — Todo componente es un nodo tipado (platform, feature, shared, infra, domain, adapter, application). Toda relación es un edge validado. Las violaciones son edges prohibidos. El grafo es la fuente de verdad del sistema y se regenera en cada auditoría. Riesgo, salud y ownership se derivan del grafo, no de opiniones.
+
+12. **Cuatro dominios arquitectónicos con ownership estricto** — Todo backend se modela en cuatro capas: Platform (backbone técnico), Features (negocio), Shared (código puro reutilizable) e Infrastructure (implementaciones concretas). Cada componente tiene un único propietario arquitectónico. Los huérfanos, duplicados y componentes mal ubicados se detectan automáticamente. Las reglas de dependencia entre capas son obligatorias: `feature → platform → infra`, `feature → shared`, `adapter → infra`. Cualquier violación es una degradación arquitectónica.

package/skills/forge/reference/quench.md

@@ -0,0 +1,74 @@
+# Quench
+
+Valida que el proyecto cumpla las reglas arquitectónicas.
+
+## Cuándo usarlo
+
+- Después de migrar un feature
+- Después de crear un feature con `forge cast`
+- Después de refactorizar con `forge reforge`
+- Pre-commit o pre-deploy
+
+## Reglas críticas
+
+| Regla | Código | Severidad | Descripción |
+|---|---|---|---|
+| Domain no importa infraestructura | — | CRITICAL | Domain no puede importar adapters, setting ni infraestructura |
+| Application no importa adapters | — | ERROR | Application solo importa de domain y shared |
+| Sin container.resolve() en use cases | — | ERROR | El contenedor solo se usa en bootstrap |
+| Sin lógica de negocio en controllers | — | ERROR | Controllers solo parsean, delegan y responden |
+| Sin BD directa fuera de repositorios | — | ERROR | Repositories son la única puerta a datos |
+| Sin imports directos entre features | — | WARNING | Comunicación via interfaces inyectadas |
+| DI consistente dentro del feature | — | WARNING | No mezclar manual + contenedor en el mismo feature |
+| Tests pasando | — | ERROR | Tests deben pasar después de cualquier cambio |
+
+## Reglas del grafo arquitectónico
+
+| Código | Regla | Severidad | Descripción |
+|---|---|---|---|
+| R1 | core → feature | CRITICAL | Core nunca debe depender de features |
+| R2 | domain → infra | CRITICAL | Domain no puede importar infraestructura |
+| R3 | feature → infra (directo) | CRITICAL | Features no acceden infraestructura sin adapter |
+| R4 | feature → feature (directo) | ERROR | Features no se importan directamente entre sí |
+| R5 | Ciclo de dependencias | ERROR | Ciclo detectado en el grafo de features |
+| R6 | infra → domain/feature | WARNING | Infraestructura no debe importar dominio interno |
+
+El grafo se construye automáticamente con `scripts/graph.mjs` y las violaciones se incluyen en `scripts/detect.mjs` (categoría `graph`).
+
+## Checklist pre-migración
+
+- [ ] Dependencias del perfil instaladas (tsyringe, reflect-metadata, etc.)
+- [ ] Decoradores habilitados en tsconfig (si aplica)
+- [ ] Entry point configurado
+- [ ] Orden topológico definido
+- [ ] Dependencias de cada feature identificadas
+
+## Checklist post-migración (por feature)
+
+- [ ] @injectable() en use cases, controller y repository
+- [ ] @inject() con tokens de clase (no strings)
+- [ ] Sin container.resolve() en lógica de negocio
+- [ ] Imports actualizados (sin referencias legacy)
+- [ ] Archivo .di.ts legacy eliminado
+- [ ] Controller usa arrow-methods
+- [ ] Use case tiene un único execute()
+- [ ] Repository implementa la interfaz del dominio
+- [ ] Mapper tiene toDomain() y toPersistence()
+- [ ] Routes/index.ts actualizado
+- [ ] Tests migrados y pasando
+- [ ] pnpm lint pasa
+- [ ] pnpm build pasa
+- [ ] pnpm test pasa
+
+## Ejecución
+
+```bash
+# Validación completa
+node .opencode/skills/forge/scripts/detect.mjs
+
+# Solo errores y críticos
+node .opencode/skills/forge/scripts/detect.mjs --severity ERROR
+
+# Solo un tipo específico
+node .opencode/skills/forge/scripts/detect.mjs --type layers
+```

package/skills/forge/reference/reforge.md

@@ -0,0 +1,40 @@
+# Reforge
+
+Refactoriza la arquitectura de un feature o de un componente de platform/shared/infra.
+
+## Cuándo usarlo
+
+- Un feature tiene violaciones arquitectónicas
+- Un feature legacy necesita reestructurarse
+- Un componente de platform necesita refinarse
+- Un componente de shared necesita rediseñarse
+- El grafo arquitectónico muestra violaciones que requieren intervención
+
+## Flujo básico
+
+1. Ejecutar `forge inspect` para obtener estado actual
+2. Identificar violaciones en el grafo arquitectónico
+3. Identificar ownership problemático (huérfanos, duplicados, mal ubicados)
+4. Decidir las acciones correctivas en orden:
+   - Violaciones CRITICAL primero (R1, R2, R5, R6)
+   - Violaciones ERROR después (R3, R4, R8, R9)
+   - Ownership problemático
+   - Warnings
+5. Ejecutar cambios en el feature o componente
+6. Ejecutar `forge quench` para verificar
+7. Actualizar `ARCHITECTURE.md`
+
+## Refactorización multi-capa
+
+Reforge ahora considera las cuatro capas arquitectónicas:
+
+- **Platform**: Mover componentes técnicos sueltos a `src/platform/`
+- **Features**: Reestructurar features con violaciones
+- **Shared**: Extraer código duplicado a `src/shared/`
+- **Infra**: Organizar implementaciones concretas en `src/infra/`
+
+## Post-refactorización
+
+- `forge inspect` — confirmar mejora en puntuación
+- `forge chain` — verificar que no se introdujeron ciclos
+- `forge armorer` — verificar ownership saludable

package/skills/forge/reference/relocate.md

@@ -0,0 +1,38 @@
+# Relocate
+
+Migra un feature existente desde estructura legacy hacia la arquitectura basada en features.
+
+También puede migrar componentes legacy a los layers Platform, Shared o Infrastructure.
+
+## Cuándo usarlo
+
+- El proyecto tiene código legacy fuera de `src/features/`
+- Hay componentes en directorios legacy que deben migrarse a:
+  - `src/platform/` (si es infraestructura técnica global)
+  - `src/shared/` (si es código reutilizable puro)
+  - `src/infra/` (si es implementación concreta)
+  - `src/features/<name>/` (si es lógica de negocio)
+
+## Flujo
+
+1. Identificar el componente a migrar
+2. Clasificarlo en el layer correcto:
+   - Configuración, servidor, logger, DI → **Platform**
+   - Lógica de negocio, entidades, casos de uso → **Feature**
+   - Código reutilizable sin dependencias externas → **Shared**
+   - Implementaciones de BD, servicios externos → **Infra**
+3. Crear la estructura target según el layer
+4. Migrar archivos manteniendo la lógica intacta
+5. Actualizar imports
+6. Eliminar estructura legacy
+7. Ejecutar `forge quench` para verificar
+8. Actualizar `ARCHITECTURE.md`
+
+## Estrategias por layer
+
+| Layer | Desde | Hacia |
+|---|---|---|
+| Platform | `src/config/`, `src/setting/`, `src/middleware/` | `src/platform/<name>/` |
+| Feature | `src/application/use-cases/<name>/` | `src/features/<name>/` |
+| Shared | `src/utils/`, `src/helpers/`, `src/lib/` | `src/shared/<name>/` |
+| Infra | `src/database/`, `src/providers/` | `src/infra/<name>/` |

package/skills/forge/reference/smelt.md

@@ -0,0 +1,31 @@
+# Smelt
+
+Extrae código reutilizable desde features hacia `shared/`.
+
+## Cuándo usarlo
+
+- Dos o más features usan el mismo tipo, interfaz o utility
+- Un feature contiene lógica que no es de negocio y podría ser compartida
+- Se detecta duplicación de código entre features
+- Se necesita mover un tipo o utilidad a `shared/` para mantener el principio DRY
+
+## Flujo
+
+1. Identificar el código candidato a extraer
+2. Verificar que no tenga dependencias de infraestructura
+3. Verificar que no tenga lógica de negocio específica de un feature
+4. Mover el código a `src/shared/<category>/`:
+   - Tipos → `src/shared/types/`
+   - Interfaces → `src/shared/contracts/`
+   - Errores → `src/shared/errors/`
+   - Utilidades → `src/shared/utils/`
+5. Actualizar todos los imports en los features que lo usaban
+6. Ejecutar `forge quench` para verificar que no hay violaciones
+7. Actualizar `ARCHITECTURE.md`
+
+## Reglas
+
+- El código extraído NO debe importar de features
+- El código extraído NO debe importar de infraestructura
+- El código extraído debe ser puro o depender solo de otros componentes shared
+- Si el código depende de platform, considerar moverlo a platform en lugar de shared

package/skills/forge/reference/temper.md

@@ -0,0 +1,49 @@
+# Temper
+
+Templa la arquitectura aplicando reglas de inyección de dependencias, seguridad y consistencia.
+
+## Cuándo usarlo
+
+- El proyecto tiene código legacy con DI manual que necesita migrar a contenedor
+- Se detectaron violaciones de inyección de dependencias
+- El proyecto usa strings como tokens de DI
+- Hay container.resolve() esparcido en la lógica de negocio
+
+## Reglas de DI
+
+### Universal (aplica a cualquier perfil)
+
+| Regla | Severidad |
+|---|---|
+| Siempre inyección por constructor | ERROR |
+| Sin service locators | ERROR |
+| Sin singletons globales | WARNING |
+| Sin new de dependencias en clases inyectadas | WARNING |
+
+### Para perfiles con tsyringe
+
+- `@injectable()` en toda clase con dependencias
+- `@inject(Token)` con tokens de clase, nunca strings
+- `container.resolve()` solo en bootstrap (app.ts, routes)
+- `container.registerSingleton()` para interfaces en app.ts
+- `container.registerInstance()` para mocks en tests
+
+### Para DI manual
+
+- Crear instancias explícitamente en bootstrap
+- Pasar dependencias por constructor
+- Usar factories o functions para lazy initialization
+
+### Para NestJS
+
+- Usar `@Injectable()` de NestJS
+- Configurar módulos con `providers` y `exports`
+- Usar `@InjectRepository()` para TypeORM
+
+## Prohibiciones
+
+- ❌ `container.resolve()` dentro de use cases, entities o adapters
+- ❌ `new UseCase(dep1, dep2)` en features migrados a contenedor
+- ❌ Importar tsyringe en archivos de dominio
+- ❌ Mezclar DI manual y contenedor en el mismo feature
+- ❌ Proxies automáticos o decoradores ocultos que dificulten el rastreo