@cristiancorreau/forge 2.9.5 → 2.9.6

package/assets/adapters/claude-code/commands/new-feature.md

@@ -1,11 +1,16 @@
 # new-feature
 
+> **Atajo de orquestación.** Este comando NO es un flujo competidor: es un wrapper que delega
+> en el pipeline SDD canónico `/plan` → `/work` → `/review` → `/ship`. Usa el mismo template de
+> spec (`core/templates/spec-template.md`) y la misma máquina de estados
+> (`DRAFT` → `REVIEW` → `APPROVED` → `IMPLEMENTED`). No dupliques aquí lógica de esos comandos:
+> invocá cada uno en su etapa.
+
 Inicia la implementación de una nueva feature siguiendo SDD (Spec-Driven Development).
 
 Argumentos: $ARGUMENTS — nombre de la feature o ruta a la spec existente.
 
-1. Si no existe spec para "$ARGUMENTS" en docs/specs/, crearla primero antes de escribir código.
-2. Leer la spec antes de proponer cualquier implementación.
-3. Proponer el plan de implementación y esperar aprobación explícita.
-4. Implementar con tests junto a la implementación, no al final.
-5. Al terminar, actualizar la spec con las decisiones tomadas durante la implementación.
+1. **Spec** — Si no existe spec para "$ARGUMENTS" en `docs/specs/`, ejecutar `/plan <fase> "$ARGUMENTS"` para crearla (queda en `APPROVED`). Si ya existe, leerla.
+2. **Implementación** — Ejecutar `/work` para implementar la spec aprobada. Propone el team, espera aprobación e implementa con tests junto a la implementación, no al final. `/work` marca la spec como `IMPLEMENTED` y completa "Notas de implementación".
+3. **Review** — Ejecutar `/review` para obtener el veredicto vinculante (persiste en `.claude/review-status.json`).
+4. **Ship** — Si el review resultó `APPROVED` y el usuario lo pide, ejecutar `/ship` para el deploy.

package/assets/adapters/claude-code/commands/plan.md

@@ -16,44 +16,66 @@ Construir el nombre del archivo:
 - Tomar el título, convertirlo a minúsculas, reemplazar espacios por guiones, eliminar caracteres especiales → `<slug>`
 - Nombre final: `docs/specs/<fase>-<slug>.md`
 
-Crear el archivo con este template exacto:
+Crear el archivo con el template canónico de `core/templates/spec-template.md` (misma fuente única de verdad que el skill `spec`):
 
 ```markdown
-# Spec: <título>
-**Fase:** <fase> | **Estado:** draft | **Fecha:** YYYY-MM-DD
+# <fase> Título de la Feature
 
-## Problem statement
-[¿Qué problema resuelve? ¿Por qué ahora?]
+> Estado: DRAFT | REVIEW | APPROVED | IMPLEMENTED
+> Responsable: [nombre o rol]
+> Creada: YYYY-MM-DD | Actualizada: YYYY-MM-DD
 
-## Non-goals
-[Qué NO cubre esta spec]
+## Contexto
 
-## Acceptance criteria
-- [ ] Criterio 1 (verificable, testeable)
-- [ ] Criterio 2
+Por qué existe esta feature. Qué problema resuelve. Qué pasa si no la hacemos.
 
-## Compliance mapping
-[Si el proyecto tiene frameworks de compliance en project.yaml, mapear qué artículos aplican. Si no aplica, escribir "N/A".]
+## Decisión
 
-## Edge cases
-[Casos límite que la implementación debe manejar]
+Qué vamos a implementar exactamente. Ser específico: endpoints, tablas, componentes.
 
-## Implementation notes
-[Se llena durante la implementación]
+## Alternativas consideradas
 
-## Decisiones tomadas
-[Se llena durante la implementación]
+| Opción | Pros | Contras | Descartada por |
+|--------|------|---------|----------------|
+| Opción A | ... | ... | ... |
+| Opción B | ... | ... | ... |
+
+## Criterios de aceptación
+
+- [ ] Criterio verificable 1
+- [ ] Criterio verificable 2
+- [ ] Criterio verificable N
+
+## Impacto de compliance
+
+Si el proyecto tiene `compliance.frameworks` configurado, completar:
+
+- **Ley 21.719**: art. X → [descripción del impacto]
+- **GDPR**: Art. Y → [descripción del impacto]
+- No aplica (si no hay impacto de compliance)
+
+## Dependencias
+
+- Requiere que [otra spec ID] esté implementada
+- Bloqueada por [issue/ticket]
+
+## Notas de implementación
+
+Cualquier decisión tomada durante la implementación que no estaba en la spec original.
 ```
 
+Marcar el estado inicial como `DRAFT` (la primera línea del bloque de metadata: `> Estado: DRAFT`).
+
 ### Paso 3 — Guiar al usuario por cada sección
 
 Preguntar una sección a la vez, en orden:
 
-1. "¿Qué problema concreto resuelve esta feature? ¿Por qué ahora y no más adelante?"
-2. "¿Qué queda explícitamente fuera del scope de esta spec?"
-3. "¿Cuáles son los criterios de aceptación verificables? (cada uno debe ser testeable de forma objetiva)"
-4. Si `project.yaml` tiene frameworks de compliance: "¿Qué artículos o controles de compliance aplican a esta feature?"
-5. "¿Qué casos límite debe manejar la implementación? (ej: usuario sin permisos, datos vacíos, concurrencia)"
+1. **Contexto**: "¿Qué problema concreto resuelve esta feature? ¿Por qué ahora y no más adelante? ¿Qué pasa si no la hacemos?"
+2. **Decisión**: "¿Qué vamos a implementar exactamente? Ser específico: endpoints, tablas, componentes."
+3. **Alternativas consideradas**: "¿Qué otras opciones se evaluaron y por qué se descartaron?"
+4. **Criterios de aceptación**: "¿Cuáles son los criterios de aceptación verificables? (cada uno debe ser testeable de forma objetiva)"
+5. Si `project.yaml` tiene frameworks de compliance: "¿Qué artículos o controles de compliance aplican a esta feature?"
+6. **Dependencias**: "¿De qué otras specs o tickets depende esta feature?"
 
 Completar el archivo con las respuestas del usuario a medida que avanza.
 
@@ -68,28 +90,31 @@ Leer `project.yaml` → `project.mode`:
 **Cómo aplicar el Planner-Critic:**
 
 Adoptar el rol de "Critic" y revisar la spec completa buscando:
-- ¿Hay acceptance criteria que no son objetivamente verificables?
+- ¿Hay criterios de aceptación que no son objetivamente verificables?
 - ¿Hay términos ambiguos que diferentes personas podrían interpretar distinto?
-- ¿Hay edge cases no cubiertos que podrían romper la implementación?
-- ¿Los non-goals son suficientemente explícitos para evitar scope creep?
+- ¿El contexto y la decisión son suficientemente específicos para evitar scope creep?
+- ¿Faltan dependencias o alternativas relevantes que deberían documentarse?
 
-Mostrar las críticas como bullet points. Preguntar: "¿Ajustamos la spec antes de marcarla como ready?"
+Mostrar las críticas como bullet points. Preguntar: "¿Ajustamos la spec antes de pasarla a REVIEW?"
 
 Si el usuario ajusta: actualizar el archivo y repetir el Critic una vez más.
 
-### Paso 5 — Marcar como ready
+### Paso 5 — Marcar como APPROVED
 
 Cuando el usuario aprueba la spec (o decide no aplicar el Critic):
-- Cambiar `**Estado:** draft` → `**Estado:** ready` en el archivo
-- Confirmar: "Spec lista: `docs/specs/<archivo>.md`. Ahora podés ejecutar `/work` para implementarla."
+- Cambiar `> Estado: DRAFT` → `> Estado: APPROVED` en el archivo
+- Actualizar la fecha de `Actualizada:` a la fecha de hoy
+- Confirmar: "Spec aprobada: `docs/specs/<archivo>.md`. Ahora podés ejecutar `/work` para implementarla."
+
+> Estados de spec (alineados con `core/templates/spec-template.md`): `DRAFT` → `REVIEW` → `APPROVED` → `IMPLEMENTED`. `/plan` crea en `DRAFT` y aprueba a `APPROVED`; `/work` la marca `IMPLEMENTED`.
 
 ---
 
 ## Modo listar (`/plan` sin argumentos)
 
-Buscar todos los archivos `.md` en `docs/specs/` que contengan `**Estado:** draft` o `**Estado:** in-review`.
+Buscar todos los archivos `.md` en `docs/specs/` que contengan `> Estado: DRAFT` o `> Estado: REVIEW`.
 
-Si no hay ninguno: "No hay specs en estado draft o in-review. Ejecutá `/plan <fase> \"<título>\"` para crear una."
+Si no hay ninguno: "No hay specs en estado DRAFT o REVIEW. Ejecutá `/plan <fase> \"<título>\"` para crear una."
 
 Si hay alguno: mostrarlos como lista numerada con título, fase y fecha. Ejemplo:
 ```
@@ -106,10 +131,10 @@ Preguntar: "¿Cuál continuamos?"
 Leer el archivo de spec indicado.
 
 Aplicar el Planner-Critic completo:
-- ¿Los acceptance criteria son objetivamente testeables?
-- ¿Hay ambigüedades en el problem statement o en los criterios?
-- ¿Hay edge cases no cubiertos?
-- ¿Los non-goals son suficientemente explícitos?
+- ¿Los criterios de aceptación son objetivamente testeables?
+- ¿Hay ambigüedades en el contexto, la decisión o los criterios?
+- ¿Las alternativas consideradas justifican la decisión tomada?
+- ¿Las dependencias están completas y son explícitas?
 
 Mostrar sugerencias de mejora como bullet points con la sección específica que afectan.
 

package/assets/adapters/claude-code/commands/session-start.md

@@ -15,7 +15,7 @@ Ejecutar los siguientes comandos y guardar sus resultados:
 ## Paso 2 — Leer configuración del proyecto
 
 - Si existe `project.yaml` en el directorio actual, leerlo para obtener: `project.mode`, `project.name`, `stack.*`, `agents.active`
-- Si existe `docs/wiki/index.md`, leerlo para obtener contexto del proyecto
+- Si existe `wiki/index.md`, leerlo para obtener contexto del proyecto
 - Si ninguno existe, continuar con defaults: mode=startup, sin checks de compliance
 
 ## Paso 3 — Evaluar escenario y actuar

package/assets/adapters/claude-code/commands/ship.md

@@ -10,10 +10,12 @@ Leer `project.yaml`. Si no existe sección `deploy`: "deploy no configurado en p
 
 ## Paso 1 — Verificar review
 
-Buscar en el contexto de la sesión si se ejecutó `/review` y resultó en APPROVED.
+Leer `.claude/review-status.json` (es el archivo que persiste `/review` en su Paso 6).
 
-- Si hay evidencia de review aprobado: continuar.
-- Si no hay evidencia: "¿Confirmás que el código fue revisado y aprobado? (s/n)"
+- **Si el archivo existe**: parsear su contenido y validar el campo `verdict`.
+  - `verdict == "APPROVED"`: continuar. (Opcional: si el `timestamp` del review es anterior al último commit relevante, advertir que el review podría estar desactualizado y pedir confirmación.)
+  - `verdict == "CHANGES_REQUESTED"` o `verdict == "BLOCKED"`: "El último review resultó en `<verdict>`. Resolvé los puntos y volvé a ejecutar `/review` antes de hacer deploy." y detener.
+- **Si el archivo NO existe** (fallback): "No se encontró `.claude/review-status.json`. ¿Confirmás que el código fue revisado y aprobado? (s/n)"
   - Si n: "Ejecutá `/review` antes de hacer deploy." y detener.
 
 ## Paso 2 — Verificar git status
@@ -31,7 +33,7 @@ Preguntar: "¿Querés mergear el PR actual a main antes del deploy? (s/n)"
 Si sí:
 - Ejecutar `gh pr checks` para verificar que todos los checks pasan
 - Si algún check falla: "El PR tiene checks fallando. Resolvelos antes de mergear." y detener.
-- Si todos pasan: ejecutar `gh pr merge --merge` (o la estrategia configurada en `project.yaml` → `deploy.merge_strategy`)
+- Si todos pasan: ejecutar `gh pr merge --merge`
 
 Si no: continuar sin mergear.
 

package/assets/adapters/claude-code/commands/work.md

@@ -6,11 +6,11 @@ Scope: $ARGUMENTS (ej: `--serial`, `--autorun`, o vacío para modo paralelo est
 
 ## Paso 1 — Identificar la spec
 
-Buscar archivos `.md` en `docs/specs/` que contengan `**Estado:** ready`.
+Buscar archivos `.md` en `docs/specs/` que contengan `> Estado: APPROVED`.
 
 - Si hay exactamente una: mostrarla y confirmar "Implementando: `<archivo>`."
 - Si hay varias: mostrarlas como lista numerada y pedir que el usuario elija.
-- Si no hay ninguna: "No hay spec en estado ready. Ejecutá `/plan` primero." y detener.
+- Si no hay ninguna: "No hay spec en estado APPROVED. Ejecutá `/plan` primero." y detener.
 
 Leer la spec seleccionada completa antes de continuar.
 
@@ -94,8 +94,10 @@ Si hay errores o conflictos: reportar claramente y preguntar cómo proceder. No
 
 ## Paso 7 — Actualizar la spec
 
-- Al iniciar la implementación: cambiar `**Estado:** ready` → `**Estado:** in-progress`
-- Al completar exitosamente: cambiar `**Estado:** in-progress` → `**Estado:** implemented`
-- Completar las secciones "Implementation notes" y "Decisiones tomadas" con lo que se hizo
+Estados de spec (alineados con `core/templates/spec-template.md`): `DRAFT` → `REVIEW` → `APPROVED` → `IMPLEMENTED`.
 
-Confirmar: "Implementación completa. Spec actualizada a `implemented`. Podés ejecutar `/review` y luego `/ship`."
+- Al completar exitosamente: cambiar `> Estado: APPROVED` → `> Estado: IMPLEMENTED`
+- Actualizar la fecha de `Actualizada:` a la fecha de hoy
+- Completar la sección "Notas de implementación" con lo que se hizo y las decisiones tomadas
+
+Confirmar: "Implementación completa. Spec actualizada a `IMPLEMENTED`. Podés ejecutar `/review` y luego `/ship`."

package/assets/core/skills/README.md

@@ -31,7 +31,7 @@ wiki-lint   → health check + auto-reparación
 | `security-audit` | Universal | No | new-feature, security-auditor |
 | `db-migrate` | Universal | No (solo el ORM del proyecto) | new-feature |
 | `browser-test` | Universal | `agent-browser` CLI (npm i -g) | new-feature, usuario directo |
-| `wiki-ingest` | Wiki | No | usuario directo, docs-writer |
+| `wiki-ingest` | Wiki | No | usuario directo, agente docs-writer |
 | `wiki-query` | Wiki | No | usuario directo, new-feature |
 | `wiki-lint` | Wiki | No | usuario directo |
 | `local2prod` | Universal | CLI del provider de deploy | new-feature |
@@ -53,7 +53,7 @@ Configurar en `project.yaml` bajo `skills.active`:
 - **`new-feature`**: checklist completo de implementación (orquesta los otros)
 
 ### Wiki — knowledge base del proyecto
-Configurar en `project.yaml` bajo `skills.active`. Generan slash commands `/wiki-ingest`, `/wiki-query`, `/wiki-lint` en Claude Code. La estructura `docs/wiki/` se inicializa con `forge-init.py`:
+Configurar en `project.yaml` bajo `skills`. Generan slash commands `/wiki-ingest`, `/wiki-query`, `/wiki-lint` en Claude Code. La estructura `wiki/` se inicializa con `forge wiki ingest <archivo>`:
 - **`wiki-ingest`**: ingesta fuentes (URL, archivo, texto) → actualiza `raw/` + páginas wiki + index + log
 - **`wiki-query`**: responde preguntas usando el wiki como base, con citas a páginas
 - **`wiki-lint`**: verifica integridad del wiki: links, huérfanos, frontmatter, log

package/assets/core/skills/aitmpl-search/SKILL.md

@@ -1,8 +1,7 @@
 # Skill: aitmpl-search
 
 Busca en el catálogo curado de forge: frameworks de agentes IA, MCP servers instalables,
-profiles de stack y herramientas. La búsqueda es offline (catálogo local); opcionalmente
-puede extenderse a GitHub con `--github`.
+profiles de stack y herramientas. La búsqueda es offline (catálogo local).
 
 Triggers: /aitmpl-search, "buscar templates", "buscar en catálogo", "templates de AI",
 "buscar template", "buscar MCP", "buscar profile".
@@ -24,33 +23,22 @@ Triggers: /aitmpl-search, "buscar templates", "buscar en catálogo", "templates
 
 Búsqueda por texto en el catálogo local:
 ```bash
-python3 .agentic/scripts/aitmpl-search.py "<query>" --limit 10
+forge aitmpl-search "<query>" --limit 10
 ```
 
-Filtrar por categoría (`framework`, `mcp-server`, `profile`, `tool`, `resource`):
+Filtrar por categoría (`mcp-server`, `framework`, `profile`):
 ```bash
-python3 .agentic/scripts/aitmpl-search.py "<query>" --category mcp-server
+forge aitmpl-search --category mcp-server
 ```
 
 Ver todas las categorías disponibles:
 ```bash
-python3 .agentic/scripts/aitmpl-search.py --list-categories
+forge aitmpl-search --list-categories
 ```
 
 Salida JSON (para integración o análisis):
 ```bash
-python3 .agentic/scripts/aitmpl-search.py "<query>" --json
-```
-
-Extender con búsqueda en GitHub (requiere red; límite 60 req/h sin token):
-```bash
-python3 .agentic/scripts/aitmpl-search.py "<query>" --github
-export GITHUB_TOKEN=ghp_...   # aumenta a 5000 req/h
-```
-
-Desde el CLI interactivo:
-```bash
-python3 .agentic/forge.py   # → "Buscar templates" → buscar o filtrar por categoría
+forge aitmpl-search "<query>" --json
 ```
 
 ### Paso 2 — Analizar resultados
@@ -71,4 +59,4 @@ Para profiles, ofrece agregar el profile a `project.yaml` directamente.
 
 - No asumir que un resultado del catálogo está actualizado — verificar el repositorio antes de recomendar
 - No crear agentes Tier 2 sin revisar si el stack ya tiene un profile en `profiles/`
-- No instalar MCP servers sin verificar que el usuario tiene Python 3.9+ y las dependencias requeridas
+- No instalar MCP servers sin verificar que el usuario tiene las dependencias requeridas

package/assets/core/skills/local2prod/SKILL.md

@@ -27,7 +27,7 @@ git status                      # confirmar qué va al commit
 
 git commit -m "tipo(scope): descripción en imperativo
 
-Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>"
+Co-Authored-By: <modelo> <noreply@anthropic.com>"
 ```
 
 Si ya hay un commit listo, ir directo al Paso 2.

package/assets/core/skills/new-feature/SKILL.md

@@ -117,7 +117,7 @@ Invocar el skill `/security-audit` como checklist mental antes de escribir cualq
    # > Estado: IMPLEMENTED
    ```
 
-5. **Actualizar CLAUDE.md** — mover el ID de spec de "En curso" a "Completadas"
+6. **Actualizar CLAUDE.md** — mover el ID de spec de "En curso" a "Completadas"
 
 ---
 

package/assets/core/skills/phase-kickoff/SKILL.md

@@ -3,6 +3,8 @@
 Protocolo para iniciar una nueva fase de desarrollo en un proyecto forge.
 Activar al comienzo de cada sprint o fase nueva.
 
+Triggers: /phase-kickoff, "iniciar sprint", "kickoff de fase", "empezar fase"
+
 ---
 
 ## Cuándo usar este skill

package/assets/core/skills/spec/SKILL.md

@@ -3,6 +3,8 @@
 Redactar specs de features siguiendo la plantilla del framework forge.
 Activar antes de escribir cualquier spec nueva.
 
+Triggers: /spec, "crear spec", "redactar spec", "nueva spec"
+
 ---
 
 ## Cuándo usar este skill

package/assets/core/skills/wiki-ingest/SKILL.md

@@ -33,7 +33,7 @@ Si es texto   → usar el texto tal como está
 ### Paso 2 — Almacenar en raw/ (inmutable)
 
 ```
-Path: docs/wiki/raw/<tema>/<YYYY-MM-DD>-<slug-del-titulo>.md
+Path: wiki/raw/<tema>/<YYYY-MM-DD>-<slug-del-titulo>.md
 
 Formato del archivo raw:
 ---
@@ -59,14 +59,14 @@ Leer el contenido y identificar:
 ### Paso 4 — Actualizar páginas wiki
 
 Para cada concepto identificado:
-- Si `docs/wiki/concepts/<nombre>.md` existe → agregar sección con nueva info + citar fuente
+- Si `wiki/concepts/<nombre>.md` existe → agregar sección con nueva info + citar fuente
 - Si no existe → crear la página desde la plantilla
 
 Para cada entidad identificada:
-- Si `docs/wiki/entities/<nombre>.md` existe → actualizar con nueva info
+- Si `wiki/entities/<nombre>.md` existe → actualizar con nueva info
 - Si no existe → crear la página desde la plantilla
 
-Crear siempre `docs/wiki/sources/<slug>.md` con resumen de la fuente:
+Crear siempre `wiki/sources/<slug>.md` con resumen de la fuente:
 
 ```markdown
 ---
@@ -95,11 +95,11 @@ tags: [tag1, tag2]
 
 ### Paso 5 — Actualizar index.md y log.md
 
-En `docs/wiki/index.md`:
+En `wiki/index.md`:
 - Agregar filas nuevas en las tablas correspondientes (concepts, entities, sources)
 - Si la categoría no existe, crearla
 
-En `docs/wiki/log.md` (append-only — NUNCA editar entradas anteriores):
+En `wiki/log.md` (append-only — NUNCA editar entradas anteriores):
 
 ```markdown
 ## [<YYYY-MM-DD>] ingest | <título de la fuente>
@@ -180,4 +180,4 @@ Si la nueva fuente contradice algo en el wiki:
 
 - `wiki-query` consume las páginas que este skill crea
 - `wiki-lint` verifica la integridad después de un ingest
-- `docs-writer` puede invocar wiki-ingest al documentar una decisión nueva
+- el agente `docs-writer` (no es un skill) puede invocar wiki-ingest al documentar una decisión nueva

package/assets/core/skills/wiki-lint/SKILL.md

@@ -20,7 +20,7 @@ wiki", "wiki health", "wiki check".
 
 ### 1. Integridad del índice
 
-Leer `docs/wiki/index.md` y verificar:
+Leer `wiki/index.md` y verificar:
 
 ```
 ✓ Cada [[link]] del índice apunta a un archivo que existe
@@ -32,10 +32,10 @@ Auto-reparar: agregar al índice los archivos que faltan (con descripción vací
 ### 2. Wikilinks rotos
 
 Buscar en todas las páginas wiki referencias `[[ruta/nombre]]` y verificar que
-el archivo `docs/wiki/ruta/nombre.md` existe.
+el archivo `wiki/ruta/nombre.md` existe.
 
 ```bash
-grep -rn "\[\[" docs/wiki/ --include="*.md" | grep -v "raw/"
+grep -rn "\[\[" wiki/ --include="*.md" | grep -v "raw/"
 ```
 
 Reportar: lista de links rotos con el archivo donde aparecen.
@@ -53,7 +53,7 @@ Reportar: lista de huérfanas. No auto-borrar — requiere decisión humana.
 
 ### 4. Integridad del log
 
-Verificar que `docs/wiki/log.md` existe y tiene al menos una entrada.
+Verificar que `wiki/log.md` existe y tiene al menos una entrada.
 El log es append-only — nunca modificar entradas pasadas.
 
 Reportar si el log no ha sido actualizado en los últimos 30 días (wiki posiblemente abandonado).

package/assets/core/skills/wiki-query/SKILL.md

@@ -22,9 +22,9 @@ sabemos de", "wiki:", "query:", "consultar wiki", "what does the wiki say about"
 
 ### Paso 1 — Leer el índice
 
-Leer `docs/wiki/index.md` para identificar qué páginas son relevantes a la pregunta.
+Leer `wiki/index.md` para identificar qué páginas son relevantes a la pregunta.
 
-Si no hay wiki (`docs/wiki/` no existe o está vacío): indicar que el wiki está vacío
+Si no hay wiki (`wiki/` no existe o está vacío): indicar que el wiki está vacío
 y sugerir usar `/wiki-ingest` para agregar conocimiento.
 
 ### Paso 2 — Leer páginas relevantes
@@ -60,7 +60,7 @@ qué fuentes ingestar para cubrir el gap.
 Si la pregunta produjo una síntesis nueva (no trivial, reutilizable), archivarla:
 
 ```
-docs/wiki/synthesis/<tema>.md
+wiki/synthesis/<tema>.md
 ```
 
 Formato:

package/dist/commands/init.js

@@ -410,7 +410,7 @@ export async function init(args) {
                         ...allAgents.map(a => `.claude/agents/${a}.md`),
                     ];
                     const ts = new Date().toISOString();
-                    saveManifest(projectRoot, buildManifest(runtime, installedFiles, projectRoot, '2.9.5', ts));
+                    saveManifest(projectRoot, buildManifest(runtime, installedFiles, projectRoot, '2.9.6', ts));
                 },
             },
         ]);

package/dist/version.d.ts

@@ -1,3 +1,3 @@
 /** Single source of truth for the CLI version (kept in sync with package.json). */
-export declare const VERSION = "2.9.5";
+export declare const VERSION = "2.9.6";
 //# sourceMappingURL=version.d.ts.map

package/dist/version.js

@@ -1,3 +1,3 @@
 /** Single source of truth for the CLI version (kept in sync with package.json). */
-export const VERSION = '2.9.5';
+export const VERSION = '2.9.6';
 //# sourceMappingURL=version.js.map

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@cristiancorreau/forge",
-  "version": "2.9.5",
+  "version": "2.9.6",
   "description": "Agentic development framework — multi-runtime support for Claude Code, OpenCode, Codex and Kiro",
   "author": "Cristian Correa <cristian@socialweb.cl>",
   "license": "Apache-2.0",
@@ -28,7 +28,7 @@
     "build:all": "npm run build:assets && npm run build",
     "dev": "tsc --watch",
     "prepublishOnly": "npm run build:all",
-    "test": "node --test test/commands.test.mjs"
+    "test": "node --test test/commands.test.mjs test/assets.test.mjs"
   },
   "files": [
     "dist",