@cristiancorreau/forge 2.9.12 → 2.10.0

package/CHANGELOG.md

@@ -7,6 +7,38 @@ Versioning: [Semantic Versioning](https://semver.org/lang/es/)
 
 ---
 
+## [2.10.0] — 2026-06-04
+
+### Agregado
+- **Skills `session-start` / `session-close` centralizados** (#29). Definidos en `core/skills/`, registrados en el catálogo y expuestos por el CLI (`forge session-start` / `forge session-close`); los templates de Claude Code, OpenCode y Codex referencian el skill central en vez de duplicar la lógica.
+- **Flujo de agentes Tier 3 (dominio)** (#31). El schema acepta `agents.specialized`; `forge scaffold --tier 3 --name <agente>` genera un agente Tier 3 conforme a `docs/agent-standard.md`; `forge validate` y `forge audit` verifican su existencia y el wizard de `forge init` los autodetecta.
+- **Hooks de guardrail ejecutables en todos los runtimes** (#32). Kiro suma hooks JSON `pre-bash-check` y `post-turn-check` (además del branch-guard); OpenCode y Codex obtienen un `.githooks/pre-commit` POSIX compartido (sin Python) con branch-guard y detección de debug.
+- **Barrera spec-first opt-in** (#28). Los hooks `pre-edit-check` exigen una spec `APPROVED` en `docs/specs/` (advierten por defecto; bloquean solo en `mode=enterprise`). Se agregan plantilla de PR, `CONTRIBUTING.md`, `docs/spec-gate-flow.md` y el workflow informativo `spec-gate.yml`.
+- **Dogfooding: forge se auto-hostea** (#27). `project.yaml`, `CLAUDE.md`, `.forge/manifest.json` y scaffold de `docs/specs/` en la raíz, validados por el propio CLI.
+
+### Cambiado
+- **CI principal migrado a la suite Node del CLI** (#24). `tests.yml` corre los tests del paquete publicado (Node 20/22 + Bun) en cada push/PR a `main`; el pytest legacy se movió a `tests-legacy.yml` (manual).
+
+### Corregido
+- **`hooks-registry.yaml` apuntaba a hooks `.py` inexistentes** (#23). Ahora referencia solo los hooks `.js/.sh` que el CLI instala, restaurando el contrato "sin Python".
+- **Versiones desincronizadas** (#25). `forge.py`, `manifest.json` y `packages/cli/package.json` quedan coherentes.
+
+### Documentación
+- README: `migrate`, `scaffold` y `teardown` marcados como disponibles (#26).
+- Deprecación de la CLI legacy de Python con `MIGRATION.md` y sunset en v3.0.0 (#30).
+
+---
+
+## [2.9.13] — 2026-06-04
+
+### Cambiado (UI)
+- **Selects del wizard/dashboard: colores invertidos y más altos.** El item bajo el cursor ahora usa el fondo resaltado (`#1e3a5f`) con texto amarillo; las opciones no seleccionadas quedan sobre el fondo del panel (antes estaba al revés: el cursor se veía oscuro y el resto azul). Se agregó `itemSpacing: 1`, `showScrollIndicator` y mayor altura (`options × 3 + 1`, acotada a `BODY_H − 4`) para que cada opción tenga aire. Aplicado en `askSelect`, el welcome y el nav del dashboard. Verificado en PTY reconstruyendo el grid.
+
+### Deprecado
+- **`forge.py` y `scripts/*.py` (CLI legacy de Python).** La CLI es 100% TypeScript desde la v2.8.0; la implementación Python queda deprecada y será **removida en v3.0.0**. Usá `npx @cristiancorreau/forge` (Node/Bun, sin dependencias de Python) para todos los comandos. Timeline y guía de migración en [MIGRATION.md](MIGRATION.md).
+
+---
+
 ## [2.9.12] — 2026-06-04
 
 ### Agregado

package/README.md

@@ -8,6 +8,9 @@
 
 Wizard interactivo que detecta tu stack, instala agentes especializados, genera guardrails y mantiene un manifest con SHA-256 para auditar cada cambio.
 
+> ⚠️ **Deprecation Notice**: `forge.py` y los scripts Python (`scripts/*.py`) están deprecados y serán removidos en **v3.0.0**.
+> Usa `npx @cristiancorreau/forge` para todos los comandos (Node/Bun, sin Python). Ver [MIGRATION.md](MIGRATION.md).
+
 ---
 
 ## Quick start
@@ -39,7 +42,7 @@ El wizard detecta y configura el proyecto en cinco pasos:
 | SDD (Spec-Driven Development) | Flujo spec-first: ninguna tarea de código arranca sin una spec `APPROVED`. El `orchestrator` rechaza spawnear agentes sin spec aprobada; el skill `/spec` redacta specs en `docs/specs/`. | ✅ | Claude Code, OpenCode, Codex, Kiro |
 | Agentes Tier 1 (universal) | Agentes definidos por output, no por stack: `orchestrator`, `backend-engineer`, `frontend-engineer`, `test-engineer`, `docs-writer`, `compliance-reviewer`, `security-auditor`. Sirven en cualquier proyecto. | ✅ | Claude Code, OpenCode, Codex, Kiro |
 | Agentes Tier 2 (stack) | Mismo rol que Tier 1 con instrucciones del stack: Hono+Drizzle, FastAPI, Express, NestJS, Django, Go-Gin, Laravel, Rails, Next.js, Expo, Astro, SvelteKit, Nuxt/Vue, WordPress, Playwright. | ✅ | Claude Code, OpenCode, Codex, Kiro |
-| Agentes Tier 3 (dominio) | Agentes que conocen el negocio (`dsar-specialist`, `gcm-engineer`, `policy-engineer`, `banner-engineer`). Viven en el proyecto y se registran en `agents.specialized`. | 🚧 | Claude Code, OpenCode, Codex, Kiro |
+| Agentes Tier 3 (dominio) | Agentes que conocen el negocio (`dsar-specialist`, `gcm-engineer`, `policy-engineer`, `banner-engineer`). Viven en el proyecto y se registran en `agents.specialized`. | ✅ | Claude Code, OpenCode, Codex, Kiro |
 | Hooks de guardrail (sin Python) | Guardrails de pre-edit/branch-guard, detección de debug, secretos y prod-safety, ejecutados por el runtime. | 🚧 | Claude Code, Codex, Kiro |
 | Operaciones reversibles | Manifest SHA-256 + dry-run para instalaciones reversibles y verificables. | 🚧 | Claude Code, OpenCode, Codex, Kiro |
 | Multi-runtime | Un mismo proyecto forge se adapta a varios runtimes con sus marcadores de detección y niveles de soporte. | ✅ | Claude Code (completo), OpenCode, Codex, Kiro |
@@ -50,8 +53,8 @@ El wizard detecta y configura el proyecto en cinco pasos:
 | Browser testing | Automatización de navegador (agent-browser sobre CDP) para verificar UI, flujos críticos, evidencia y diffs visuales/responsive (`/browser-test`). | ✅ | Claude Code, OpenCode, Codex, Kiro |
 | DB migrations | Flujo seguro de migraciones compatible con Prisma, Drizzle, ActiveRecord, Alembic y Goose (`/db-migrate`). | ✅ | Claude Code, OpenCode, Codex, Kiro |
 | Deploy a producción | Publicación con gate `READY/SUCCESS` sobre Vercel, Railway, Fly.io, GitHub Actions y pipelines custom (`/local2prod`). | ✅ | Claude Code, OpenCode, Codex, Kiro |
-| Migración v1→v2 | Portado de proyectos forge v1 a v2. Comando `migrate` aún sin portar. | ❌ | Claude Code, Kiro |
-| Scaffold / Teardown | Generación y desmontaje de estructura de proyecto. Comandos sin portar a la nueva CLI. | ❌ | Claude Code, OpenCode, Codex, Kiro |
+| Migración v1→v2 | Migración de `project.yaml` v1 a v2 con detección automática de versión, soporte `--dry-run` y `--backup` (`forge migrate`). | ✅ | Claude Code, OpenCode, Codex, Kiro |
+| Scaffold / Teardown | `forge scaffold` genera profiles Tier 2 (`--force`, `--description`, `--stack-details`) y `forge teardown` desinstala forge limpiamente vía manifest (`--dry-run`, `--keep-config`). Ambos en la CLI TypeScript con tests. | ✅ | Claude Code, OpenCode, Codex, Kiro |
 
 Leyenda: ✅ disponible · 🚧 parcial · ❌ pendiente.
 
@@ -124,6 +127,8 @@ Toda la CLI corre en Node.js. Los hooks de guardrail son JavaScript puro.
 
 No hay `pip install`, no hay `requirements.txt`, no hay dependencias de sistema fuera de Node.js 20+.
 
+> El `forge.py` y los scripts `scripts/*.py` que aún viven en el repositorio son la implementación **legacy** y están **deprecados**: serán removidos en v3.0.0. No los necesitás para usar forge vía `npx @cristiancorreau/forge`. Ver [MIGRATION.md](MIGRATION.md).
+
 ---
 
 ## Comparativa

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

@@ -1,109 +1,8 @@
 # session-close
 
-Cierra la sesión de trabajo con un pipeline de 8 pasos: commit, changeset, GitHub Projects, daily note, release notes, close commit, sync y PR.
+Cierra la sesión de trabajo con un pipeline de 8 pasos: commit → changeset →
+GitHub Projects → daily note → RELEASE-NOTES → commit de cierre → sync → PR.
 
-## Paso 1 — Verificar estado
-
-Ejecutar `git status --short` y `git diff --stat HEAD 2>/dev/null`. Reportar qué hay pendiente.
-
-## Paso 2 — Commitear cambios pendientes
-
-Si hay cambios sin commitear:
-
-- Preguntar al usuario: "¿Qué describe este commit? (usa Conventional Commits: feat/fix/chore/docs/refactor/test)"
-- Commitear con: `git add -A && git commit -m "<type>(<scope>): <descripción>"`
-- Incluir siempre en el cuerpo del commit: `Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>`
-
-Si no hay nada que commitear: indicar "Nada pendiente de commitear." y continuar.
-
-## Paso 3 — Changeset (condicional)
-
-Si el commit del Paso 2 fue de tipo `feat:` o `fix:` Y `package.json` contiene `"@changesets/cli"`:
-
-- Ejecutar `npx changeset` para generar el changeset
-
-En cualquier otro caso, omitir este paso sin mencionarlo.
-
-## Paso 4 — GitHub Projects (condicional)
-
-Leer `project.yaml`. Si tiene una sección `github.project` con `number`, `owner` y `repo`:
-
-- Preguntar: "¿Qué issues trabajaste en esta sesión? (números separados por coma, o Enter para saltar)"
-- Si el usuario provee números: ejecutar `gh issue close <N> --comment "Completado en esta sesión"` para cada uno
-- Mover los issues a Done en el proyecto si es posible con gh CLI
-
-Si `project.yaml` no tiene sección `github.project`: indicar "GitHub Projects no configurado en project.yaml." y continuar.
-
-## Paso 5 — Daily note
-
-Crear el directorio `docs/daily-notes/` si no existe.
-
-Determinar:
-- `FECHA`: resultado de `date +%Y-%m-%d`
-- `TEMA`: derivado del nombre de la rama actual, eliminando el prefijo de tipo y el sufijo de fecha (ej: `feature/billing-webpay-2026-05-16` → `billing-webpay`)
-
-Crear el archivo `docs/daily-notes/FECHA-TEMA.md` con este contenido:
-
-```
-# Session FECHA — TEMA
-
-## Completado
-[listar qué se implementó o cambió en esta sesión]
-
-## Archivos modificados
-[output de: git diff --name-only HEAD~1..HEAD 2>/dev/null || git diff --name-only HEAD 2>/dev/null]
-
-## Commits
-[output de: git log --oneline HEAD~3..HEAD]
-
-## Decisiones tomadas
-[preguntar al usuario: "¿Alguna decisión de diseño o arquitectura que vale registrar?"]
-
-## Blockers para próxima sesión
-[preguntar al usuario: "¿Quedó algo bloqueado o incompleto?"]
-```
-
-Completar las secciones "Archivos modificados" y "Commits" con los outputs reales. Completar "Completado", "Decisiones tomadas" y "Blockers" con las respuestas del usuario.
-
-## Paso 6 — RELEASE-NOTES.md
-
-Agregar al final de `RELEASE-NOTES.md` (crear si no existe):
-
-```
-## FECHA — TEMA
-[resumen en una línea de qué cambió]
-```
-
-Usar el resumen de la daily note para redactar la línea.
-
-## Paso 7 — Commit de cierre
-
-Commitear los archivos generados:
-
-```
-git add docs/daily-notes/ RELEASE-NOTES.md && git commit -m "docs(progress): session close FECHA — TEMA"
-```
-
-## Paso 8 — Sync y PR
-
-Ejecutar:
-
-```
-git fetch origin main
-git log HEAD..origin/main --oneline
-```
-
-- Si main tiene commits nuevos: ejecutar `git rebase origin/main` y luego `git push --force-with-lease origin <rama-actual>`
-- Si main no tiene cambios nuevos: ejecutar `git push -u origin <rama-actual>`
-
-Luego crear el PR:
-
-```
-gh pr create --title "<resumen de cambios>" --body "<resumen de sesión tomado de la daily note>"
-```
-
-Si `gh` no está disponible: hacer solo el push y recordar al usuario "Crea el PR manualmente en GitHub."
-
-## Al finalizar el pipeline
-
-Confirmar con: "Sesión cerrada. PR creado: [URL]" o, si gh no estuvo disponible: "Sesión cerrada. Push hecho a [branch] — crea el PR en GitHub."
+La lógica vive en el skill central `core/skills/session-close/SKILL.md`.
+Seguí esos 8 pasos en orden. En el Paso 2, firmá el commit con el
+`Co-Authored-By` del runtime activo (Claude Code).

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

@@ -1,59 +1,8 @@
 # session-start
 
-Inicializa una sesión de trabajo: detecta el estado del repo, identifica el escenario y enruta según corresponda.
+Inicializa una sesión de trabajo: detecta el estado del repo, identifica el
+escenario (rama activa, main con PRs, main limpio) y enruta según corresponda.
 
-## Paso 1 — Leer estado del repo
-
-Ejecutar los siguientes comandos y guardar sus resultados:
-
-- `git branch --show-current` → rama actual
-- `git status --short` → cambios sin commitear
-- `git log --oneline -5` → commits recientes
-- `gh pr list --author @me --state open --json number,title,headRefName 2>/dev/null` → PRs abiertos (saltar si gh no está disponible)
-- `git branch --sort=-committerdate --format='%(refname:short)' | grep -v 'HEAD' | head -8` → ramas recientes
-
-## 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 `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
-
-### Escenario A — Ya en una rama de feature (no es main/master/develop)
-
-- Mostrar los últimos 5 commits de esta rama para contexto
-- Mostrar archivos con cambios sin commitear si los hay
-- Reportar: "Continuando sesión en [branch]. Contexto: [mensaje del último commit]."
-- Preguntar: "¿Qué trabajamos hoy?"
-
-### Escenario B — En main/master con PRs abiertos o ramas recientes de feature
-
-- Listar los PRs abiertos del Paso 1 como menú numerado
-- Listar las ramas recientes que no sean main/master/develop del Paso 1
-- Preguntar: "¿Continuás uno de estos o arrancamos algo nuevo?"
-- Si el usuario elige continuar uno existente: hacer checkout de esa rama
-- Si el usuario quiere algo nuevo: pasar al flujo del Escenario C
-
-### Escenario C — En main/master sin trabajo previo identificado
-
-- Esperar el primer mensaje del usuario describiendo qué quiere trabajar
-- Antes de cualquier edición de código, proponer un nombre de rama siguiendo la convención:
-  - `feature/<tema-corto>-$(date +%Y-%m-%d)` para features
-  - `fix/<tema-corto>-$(date +%Y-%m-%d)` para correcciones
-  - `chore/<tema-corto>-$(date +%Y-%m-%d)` para tareas técnicas
-  - `docs/<tema-corto>-$(date +%Y-%m-%d)` para documentación
-- Crear la rama: `git checkout -b <nombre-propuesto>`
-- Confirmar: "Branch creada: [nombre]. Listo para trabajar."
-
-## Paso 4 — Recordatorio de reglas de sesión
-
-Una vez determinado el escenario, enunciar estas reglas una sola vez:
-
-"Reglas de sesión: (1) No editar código en main. (2) Conventional Commits. (3) Spec antes de implementar si el proyecto es standard/enterprise. (4) Cerrar con /session-close."
-
-## Comportamiento adaptativo
-
-- Si `gh` no está disponible: omitir los pasos que lo requieren y agregar nota "gh no disponible — revisar PRs en GitHub.com manualmente"
-- Si `project.yaml` no existe: continuar con defaults, no interrumpir el flujo
-- Si la rama actual no sigue la convención de nombres: mencionarlo pero no bloquear
+La lógica vive en el skill central `core/skills/session-start/SKILL.md`.
+Seguí esos pasos al pie de la letra: leer estado del repo, leer `project.yaml`,
+evaluar el escenario A/B/C y enunciar las reglas de sesión una sola vez.

package/assets/adapters/codex/HOOKS.md

@@ -0,0 +1,55 @@
+# Forge Hooks — Adaptación para Codex
+
+Codex CLI no tiene un sistema de hooks de bloqueo nativo equivalente al
+PreToolUse/Stop de Claude Code. Este documento describe cómo Forge aplica sus
+guardrails en Codex.
+
+> **Mecanismo de hook de este runtime:** git hooks compartidos (`.githooks/`),
+> no hooks nativos. `forge generate --runtime codex` genera `.githooks/pre-commit`
+> (branch guard + detección de debug). El resto de los guardrails viven como
+> instrucciones en `AGENTS.md`.
+
+---
+
+## 1. Equivalencia de hooks
+
+| Hook Forge (Claude Code) | Equivalente en Codex | Mecanismo |
+|--------------------------|----------------------|-----------|
+| `PreToolUse:Edit` — branch guard (bloquear edición en main) | **git pre-commit** | `.githooks/pre-commit` (automático) + AGENTS.md |
+| `PreToolUse:Bash` — detección de console.log/print de debug | **git pre-commit** | `.githooks/pre-commit` (automático) + AGENTS.md |
+| `PreToolUse:Bash` — bloqueo de comandos destructivos en producción | **Ninguno nativo** | Instrucción en AGENTS.md |
+| `Stop` — resumen de sesión y persistencia de memoria | **Ninguno nativo** | Flujo SDD manual |
+
+**Conclusión:** Codex no tiene hooks de bloqueo nativos. Branch guard y detección
+de debug se ejecutan automáticamente vía el git hook compartido
+`.githooks/pre-commit`; el resto de los guardrails se embeben como instrucciones
+en AGENTS.md.
+
+---
+
+## 2. Git hook compartido (`.githooks/pre-commit`)
+
+`forge generate` genera un hook ejecutable POSIX (sin Python) en
+`.githooks/pre-commit`, idéntico al que usa OpenCode. Activalo una vez por clon:
+
+```sh
+git config core.hooksPath .githooks
+```
+
+Qué hace en cada `git commit`:
+
+1. **Branch guard** — bloquea el commit si estás en `main`/`master` y hay
+   archivos de código staged (los `*.md`, `*.yaml`, `*.json`, `*.txt` quedan exentos).
+2. **Debug detection** — bloquea el commit si encuentra `console.log(`,
+   `debugger;`, `binding.pry`, `var_dump(` o `dd(` en archivos staged.
+
+Para saltarlo puntualmente (bajo tu responsabilidad): `git commit --no-verify`.
+
+---
+
+## 3. Guardrails que dependen del agente
+
+El git hook solo corre en `git commit`. Los comandos destructivos en producción
+(`DROP TABLE`, `TRUNCATE`, `--force-reset`, `rm -rf /`, `git push --force`) NO
+los intercepta: ante cualquiera de ellos, Codex debe parar y pedir confirmación
+explícita al humano. Estas reglas están documentadas en el `AGENTS.md` generado.

package/assets/adapters/codex/commands/session-close.md

@@ -1,53 +1,13 @@
 ---
 name: session-close
-description: Template para cerrar una sesión de trabajo con Codex CLI
+description: Cierra una sesión de trabajo con Codex CLI siguiendo el skill central de forge
 usage: Copia el contenido de Prompt al final de tu sesión de Codex
 ---
 
 ## Prompt para Codex
 
-Cierra la sesión de trabajo. Ejecuta estos checks en orden:
+Cierra la sesión de trabajo siguiendo el skill central `core/skills/session-close/SKILL.md`.
 
-1. **Verificar estado del trabajo**
-   - Ejecuta `git status --short`.
-   - Si hay cambios sin commitear: listarlos. ¿Deben commitearse o descartarse?
-   - Ejecuta `git diff --stat HEAD` para ver el resumen de cambios en el último commit.
-
-2. **Verificar build y tests**
-   - Lee `project.yaml` para el comando de check configurado (`scripts.check`).
-   - Si no hay comando configurado: ejecuta el check estándar del stack (tsc --noEmit para TypeScript, py_compile para Python).
-   - Reporta si pasan o fallan. Si fallan, listar los errores.
-
-3. **Verificar specs**
-   - Lee `AGENTS.md` o `CLAUDE.md` para ver el estado de specs activas.
-   - Lista specs en `docs/specs/` con estado `APPROVED` que no estén `IMPLEMENTED`.
-   - ¿Hay specs en progreso que quedaron incompletas esta sesión? Reportarlas.
-
-4. **Registrar progreso**
-   - ¿Qué se completó en esta sesión? Lista los archivos modificados:
-     `git diff --name-only HEAD~1 HEAD 2>/dev/null || git diff --name-only`
-   - ¿Qué quedó pendiente?
-   - ¿Hay bloqueadores para la próxima sesión?
-
-5. **Verificar debug statements olvidados**
-   - Ejecuta en archivos modificados: busca `console.log(`, `print(`, `debugger;`.
-   - Si hay alguno: listarlos con archivo y línea.
-
-6. **Reporte de cierre**
-   Presenta este resumen:
-   ```
-   Sesión cerrada — [fecha]
-
-   Completado:
-   - [item 1]
-   - [item 2]
-
-   Pendiente para próxima sesión:
-   - [item 1]
-
-   Bloqueadores:
-   - [item o "ninguno"]
-
-   Estado del repo: [limpio | N archivos con cambios]
-   Tests: [pasando | fallando]
-   ```
+Ejecuta su pipeline de 8 pasos en orden: commit → changeset → GitHub Projects →
+daily note → RELEASE-NOTES → commit de cierre → sync → PR. En el Paso 2, firma
+el commit con `Co-Authored-By: Codex <noreply@openai.com>`.

package/assets/adapters/codex/commands/session-start.md

@@ -1,49 +1,14 @@
 ---
 name: session-start
-description: Template para iniciar una sesión de trabajo con Codex CLI
+description: Inicia una sesión de trabajo con Codex CLI siguiendo el skill central de forge
 usage: Copia el contenido de Prompt al inicio de tu sesión de Codex
 ---
 
 ## Prompt para Codex
 
-Inicia la sesión de trabajo. Ejecuta estos checks en orden y reporta el resultado:
+Inicia la sesión de trabajo siguiendo el skill central `core/skills/session-start/SKILL.md`.
 
-1. **Verificar herramientas disponibles**
-   - Ejecuta `git --version` — reporta la versión o error.
-   - Ejecuta `python3 --version` — reporta la versión o error.
-   - Si alguna herramienta crítica falta, reporta el error y detente.
-
-2. **Verificar branch actual**
-   - Ejecuta `git branch --show-current`.
-   - Si el resultado es `main` o `master`: advierte que estás en la branch protegida.
-     Sugiere: `git checkout -b feature/<tema>-$(date +%Y-%m-%d)`
-   - Si estás en una feature branch: OK.
-
-3. **Verificar cambios sin commitear**
-   - Ejecuta `git status --short`.
-   - Si hay cambios: listarlos y advertir.
-   - Si no hay cambios: OK.
-
-4. **Verificar project.yaml**
-   - Busca `project.yaml` en el directorio actual y directorios padre (hasta 3 niveles).
-   - Si no existe: advierte que el proyecto no está inicializado con Forge. Sugiere ejecutar el wizard.
-   - Si existe: lee los campos `project.name` y `project.mode`.
-     - Si faltan esos campos: advertir.
-     - Si están presentes: reportar nombre y modo del proyecto.
-
-5. **Verificar variables de producción activas**
-   - Ejecuta `env | grep -iE '^(PROD_|PRODUCTION_)'`.
-   - Si hay variables de producción activas: ADVERTENCIA — verificar que es intencional trabajar con contexto de producción.
-   - Si no hay ninguna: OK.
-
-6. **Leer AGENTS.md**
-   - Lee `AGENTS.md` en la raíz del repositorio.
-   - Confirma que lo leíste y resume el nombre del proyecto y el workflow activo.
-
-Formato del reporte final:
-```
-Sesión iniciada — [nombre del proyecto]
-Branch: [nombre]
-Estado: [limpio | N cambios sin commitear]
-Warnings: [lista o "ninguno"]
-```
+Ejecuta sus 4 pasos en orden: (1) leer estado del repo, (2) leer `project.yaml`
+(en Codex, leer también `AGENTS.md` para contexto), (3) evaluar el escenario
+A/B/C y enrutar, (4) enunciar las reglas de sesión una sola vez. Si `gh` no está
+disponible, omite los pasos que lo requieren y avisa.

package/assets/adapters/opencode/HOOKS.md

@@ -2,19 +2,47 @@
 
 OpenCode no tiene un sistema de hooks equivalente al PreToolUse/Stop de Claude Code. Este documento describe cómo adaptar cada comportamiento de hook de Forge para OpenCode.
 
+> **Mecanismo de hook de este runtime:** git hooks compartidos (`.githooks/`),
+> no hooks nativos. `forge generate --runtime opencode` genera
+> `.githooks/pre-commit` (branch guard + detección de debug). Los demás
+> guardrails se embeben como instrucciones en `AGENTS.md`.
+
 ---
 
 ## 1. Equivalencia de hooks
 
 | Hook Forge (Claude Code) | Equivalente en OpenCode | Mecanismo |
 |--------------------------|------------------------|-----------|
-| `PreToolUse:Edit` — branch guard (bloquear edición en main) | **Ninguno nativo** | Instrucción en AGENTS.md |
-| `PreToolUse:Bash` — detección de console.log/print de debug | **Ninguno nativo** | Instrucción en AGENTS.md |
+| `PreToolUse:Edit` — branch guard (bloquear edición en main) | **git pre-commit** | `.githooks/pre-commit` (automático) + AGENTS.md |
+| `PreToolUse:Bash` — detección de console.log/print de debug | **git pre-commit** | `.githooks/pre-commit` (automático) + AGENTS.md |
 | `PreToolUse:Bash` — bloqueo de comandos destructivos en producción | **Ninguno nativo** | Instrucción en AGENTS.md |
 | `Stop` — resumen de sesión y persistencia de memoria | **Ninguno nativo** | Flujo `/session-close` |
 | `pre-commit` git hook — inyección de token stats en progress.html | **Compatible** | El hook git funciona igual en OpenCode |
 
-**Conclusión:** OpenCode no tiene PreToolUse ni Stop hooks. Todos los guardrails deben embeberse como instrucciones en AGENTS.md.
+**Conclusión:** OpenCode no tiene PreToolUse ni Stop nativos. Branch guard y
+detección de debug se ejecutan de forma automática vía el git hook compartido
+`.githooks/pre-commit`; el resto de los guardrails se embeben como instrucciones
+en AGENTS.md.
+
+---
+
+## 1.bis. Git hook compartido (`.githooks/pre-commit`)
+
+`forge generate` genera un hook ejecutable POSIX (sin Python) en
+`.githooks/pre-commit`. Activalo una vez por clon:
+
+```sh
+git config core.hooksPath .githooks
+```
+
+Qué hace en cada `git commit`:
+
+1. **Branch guard** — bloquea el commit si estás en `main`/`master` y hay
+   archivos de código staged (los `*.md`, `*.yaml`, `*.json`, `*.txt` quedan exentos).
+2. **Debug detection** — bloquea el commit si encuentra `console.log(`,
+   `debugger;`, `binding.pry`, `var_dump(` o `dd(` en archivos staged.
+
+Para saltarlo puntualmente (bajo tu responsabilidad): `git commit --no-verify`.
 
 ---
 

package/assets/adapters/opencode/commands/session-close.md

@@ -1,111 +1,10 @@
 ---
 name: session-close
-description: Cierra la sesión de trabajo con commit, daily note, RELEASE-NOTES y PR.
+description: Cierra la sesión de trabajo siguiendo el skill central de forge.
 ---
 
-Cierra la sesión de trabajo con un pipeline de 8 pasos: commit, changeset, GitHub Projects, daily note, release notes, close commit, sync y PR.
+Cierra la sesión de trabajo siguiendo el skill central `core/skills/session-close/SKILL.md`.
 
-## Paso 1 — Verificar estado
-
-Ejecutar `git status --short` y `git diff --stat HEAD 2>/dev/null`. Reportar qué hay pendiente.
-
-## Paso 2 — Commitear cambios pendientes
-
-Si hay cambios sin commitear:
-
-- Preguntar al usuario: "¿Qué describe este commit? (usa Conventional Commits: feat/fix/chore/docs/refactor/test)"
-- Commitear con: `git add -A && git commit -m "<type>(<scope>): <descripción>"`
-- Incluir siempre en el cuerpo del commit: `Co-Authored-By: OpenCode <noreply@opencode.ai>`
-
-Si no hay nada que commitear: indicar "Nada pendiente de commitear." y continuar.
-
-## Paso 3 — Changeset (condicional)
-
-Si el commit del Paso 2 fue de tipo `feat:` o `fix:` Y `package.json` contiene `"@changesets/cli"`:
-
-- Ejecutar `npx changeset` para generar el changeset
-
-En cualquier otro caso, omitir este paso sin mencionarlo.
-
-## Paso 4 — GitHub Projects (condicional)
-
-Leer `project.yaml`. Si tiene una sección `github.project` con `number`, `owner` y `repo`:
-
-- Preguntar: "¿Qué issues trabajaste en esta sesión? (números separados por coma, o Enter para saltar)"
-- Si el usuario provee números: ejecutar `gh issue close <N> --comment "Completado en esta sesión"` para cada uno
-
-Si `project.yaml` no tiene sección `github.project`: omitir este paso.
-
-## Paso 5 — Daily note
-
-Crear el directorio `docs/daily-notes/` si no existe.
-
-Determinar:
-- `FECHA`: resultado de `date +%Y-%m-%d`
-- `TEMA`: derivado del nombre de la rama actual, eliminando el prefijo de tipo y el sufijo de fecha (ej: `feature/billing-webpay-2026-05-16` → `billing-webpay`)
-
-Crear el archivo `docs/daily-notes/FECHA-TEMA.md` con este contenido:
-
-```
-# Session FECHA — TEMA
-
-## Completado
-[listar qué se implementó o cambió en esta sesión]
-
-## Archivos modificados
-[output de: git diff --name-only HEAD~1..HEAD 2>/dev/null || git diff --name-only HEAD 2>/dev/null]
-
-## Commits
-[output de: git log --oneline HEAD~3..HEAD]
-
-## Decisiones tomadas
-[preguntar al usuario: "¿Alguna decisión de diseño o arquitectura que vale registrar?"]
-
-## Blockers para próxima sesión
-[preguntar al usuario: "¿Quedó algo bloqueado o incompleto?"]
-```
-
-Completar las secciones "Archivos modificados" y "Commits" con los outputs reales. Completar "Completado", "Decisiones tomadas" y "Blockers" con las respuestas del usuario.
-
-## Paso 6 — RELEASE-NOTES.md
-
-Agregar al final de `RELEASE-NOTES.md` (crear si no existe):
-
-```
-## FECHA — TEMA
-[resumen en una línea de qué cambió]
-```
-
-Usar el resumen de la daily note para redactar la línea.
-
-## Paso 7 — Commit de cierre
-
-Commitear los archivos generados:
-
-```bash
-git add docs/daily-notes/ RELEASE-NOTES.md && git commit -m "docs(progress): session close FECHA — TEMA"
-```
-
-## Paso 8 — Sync y PR
-
-Ejecutar:
-
-```bash
-git fetch origin main
-git log HEAD..origin/main --oneline
-```
-
-- Si main tiene commits nuevos: ejecutar `git rebase origin/main` y luego `git push --force-with-lease origin <rama-actual>`
-- Si main no tiene cambios nuevos: ejecutar `git push -u origin <rama-actual>`
-
-Luego crear el PR:
-
-```bash
-gh pr create --title "<resumen de cambios>" --body "<resumen de sesión tomado de la daily note>"
-```
-
-Si `gh` no está disponible: hacer solo el push y recordar al usuario "Crea el PR manualmente en GitHub."
-
-## Al finalizar el pipeline
-
-Confirmar con: "Sesión cerrada. PR creado: [URL]" o, si gh no estuvo disponible: "Sesión cerrada. Push hecho a [branch] — crea el PR en GitHub."
+Ejecuta su pipeline de 8 pasos en orden: commit → changeset → GitHub Projects →
+daily note → RELEASE-NOTES → commit de cierre → sync → PR. En el Paso 2, firma
+el commit con `Co-Authored-By: OpenCode <noreply@opencode.ai>`.