@cristiancorreau/forge 2.1.0

package/assets/adapters/opencode/commands/plan.md

@@ -0,0 +1,119 @@
+---
+name: plan
+description: Crea o revisa una spec de feature en docs/specs/ siguiendo el flujo SDD.
+---
+
+Gestiona specs del ciclo SDD (Spec-Driven Development).
+
+Argumentos: `<fase> "<título>"` para crear, `--review <archivo>` para revisar, vacío para listar.
+
+## Modo crear spec (`/plan <fase> "<título>"`)
+
+### Paso 1 — Verificar directorio
+
+Verificar que existe `docs/specs/`. Si no existe, crearlo.
+
+### Paso 2 — Crear el archivo de spec
+
+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:
+
+```markdown
+# Spec: <título>
+**Fase:** <fase> | **Estado:** draft | **Fecha:** YYYY-MM-DD
+
+## Problem statement
+[¿Qué problema resuelve? ¿Por qué ahora?]
+
+## Non-goals
+[Qué NO cubre esta spec]
+
+## Acceptance criteria
+- [ ] Criterio 1 (verificable, testeable)
+- [ ] Criterio 2
+
+## Compliance mapping
+[Si el proyecto tiene frameworks de compliance en project.yaml, mapear qué artículos aplican. Si no aplica, escribir "N/A".]
+
+## Edge cases
+[Casos límite que la implementación debe manejar]
+
+## Implementation notes
+[Se llena durante la implementación]
+
+## Decisiones tomadas
+[Se llena durante la implementación]
+```
+
+### 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)"
+
+Completar el archivo con las respuestas del usuario a medida que avanza.
+
+### Paso 4 — Planner-Critic (condicional)
+
+Leer `project.yaml` → `project.mode`:
+
+- **mode=standard o mode=enterprise**: aplicar Planner-Critic obligatoriamente
+- **mode=startup**: preguntar "¿Querés aplicar el Planner-Critic para detectar ambigüedades antes de implementar? (s/n)"
+- Si `project.yaml` no existe: tratar como startup
+
+**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 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?
+
+Mostrar las críticas como bullet points. Preguntar: "¿Ajustamos la spec antes de marcarla como ready?"
+
+Si el usuario ajusta: actualizar el archivo y repetir el Critic una vez más.
+
+### Paso 5 — Marcar como ready
+
+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."
+
+---
+
+## Modo listar (`/plan` sin argumentos)
+
+Buscar todos los archivos `.md` en `docs/specs/` que contengan `**Estado:** draft` o `**Estado:** in-review`.
+
+Si no hay ninguno: "No hay specs en estado draft o in-review. Ejecutá `/plan <fase> \"<título>\"` para crear una."
+
+Si hay alguno: mostrarlos como lista numerada con título, fase y fecha. Ejemplo:
+```
+1. auth-oauth.md — Fase 2 — Auth con OAuth (2026-05-17)
+2. billing-webpay.md — Fase 3 — Pago con WebPay (2026-05-14)
+```
+
+Preguntar: "¿Cuál continuamos?"
+
+---
+
+## Modo revisar (`/plan --review <archivo-spec>`)
+
+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?
+
+Mostrar sugerencias de mejora como bullet points con la sección específica que afectan.
+
+Preguntar: "¿Aplicamos alguno de estos cambios?"

package/assets/adapters/opencode/commands/review.md

@@ -0,0 +1,164 @@
+---
+name: review
+description: Revisión de código estructurada en un solo paso. Produce un veredicto APPROVED / CHANGES_REQUESTED / BLOCKED vinculante para /ship.
+---
+
+Orquesta una revisión de código estructurada y produce un veredicto vinculante para `/ship`.
+
+Argumentos: vacío para cambios uncommitted, `HEAD~N..HEAD` para rango de commits, `PR-N` para un PR específico.
+
+---
+
+## Paso 0 — Determinar modo de invocación
+
+Evaluar los argumentos:
+
+- **Vacío**: revisar cambios uncommitted (`git diff HEAD`)
+- **`HEAD~N..HEAD`** o cualquier rango git válido: revisar ese rango de commits
+- **`PR-N`** (ej: `PR-42`): obtener el diff del PR con `gh pr diff 42`
+
+Guardar el scope como descripción legible (ej: "cambios uncommitted", "últimos 3 commits", "PR #42").
+
+---
+
+## Paso 1 — Obtener el diff
+
+Según el modo detectado:
+
+- Cambios uncommitted: `git diff HEAD` (si está vacío, probar `git diff --cached`)
+- Rango de commits: `git diff <rango>`
+- PR: `gh pr diff <N>`
+
+Si el diff está vacío: "No hay cambios para revisar en el scope indicado." y detener.
+
+Mostrar un resumen de lo que se va a revisar:
+```
+Revisando: <scope>
+Archivos modificados: <N>
+Líneas añadidas/eliminadas: +X / -Y
+```
+
+---
+
+## Paso 2 — Leer mode del proyecto
+
+Leer `project.yaml` → `project.mode`. Si no existe: tratar como `startup`.
+
+---
+
+## Paso 3 — Revisión completa en un solo paso
+
+OpenCode ejecuta la revisión en un único paso cubriendo todas las dimensiones.
+
+**Seguridad**
+- ¿Hay tokens, passwords o claves hardcodeadas?
+- ¿Los endpoints nuevos o modificados verifican autenticación Y autorización?
+- ¿Hay concatenación de input del usuario en queries SQL (riesgo de SQLi)?
+- ¿Hay output de input del usuario sin escapar (riesgo de XSS)?
+- ¿Se loguea PII sin enmascarar?
+
+**Calidad**
+- ¿Hay naming confuso o inconsistente con el resto del proyecto?
+- ¿Hay código muerto o lógica duplicada?
+- ¿Hay N+1 queries o loops en caminos críticos?
+- ¿Faltan índices para queries que se ejecutan frecuentemente?
+
+**Tests**
+- ¿Cada función o endpoint modificado tiene al menos un test correspondiente?
+- ¿Los casos borde están cubiertos?
+
+**Compliance (solo si `project.mode` es enterprise)**
+- ¿Hay cambios en el manejo de PII?
+- ¿Se modificaron flujos de consentimiento?
+- ¿Hay cambios en logs de auditoría?
+- ¿Los cambios están alineados con los frameworks de compliance de `project.yaml`?
+
+---
+
+## Paso 4 — Sintetizar veredicto
+
+Evaluar la totalidad de los hallazgos y asignar uno de estos veredictos:
+
+### APPROVED
+No hay hallazgos bloqueantes ni cambios requeridos.
+
+### CHANGES_REQUESTED
+Hay issues que deben resolverse pero no son críticos:
+```
+CHANGES_REQUESTED
+
+Cambios requeridos:
+1. [Descripción del issue] — [archivo:línea si aplica]
+2. [Descripción del issue] — [archivo:línea si aplica]
+```
+
+### BLOCKED
+Hay issues críticos que deben resolverse antes de poder hacer `/ship`:
+```
+BLOCKED
+
+Issues críticos:
+1. [Descripción] — [archivo:línea si aplica] — Severidad: CRITICAL
+2. [Descripción] — [archivo:línea si aplica] — Severidad: HIGH
+
+Esta sesión no es apta para /ship hasta resolver estos puntos.
+```
+
+---
+
+## Paso 5 — Producir reporte
+
+```
+## Code Review — <scope>
+Fecha: YYYY-MM-DD HH:MM
+Modo: <startup|standard|enterprise>
+
+### Hallazgos
+
+#### Seguridad
+[hallazgos o "Sin hallazgos."]
+
+#### Calidad
+[hallazgos o "Sin hallazgos."]
+
+#### Tests
+[hallazgos o "Sin hallazgos."]
+
+#### Compliance
+[hallazgos o "Sin hallazgos." o "N/A (modo no-enterprise)"]
+
+---
+
+### Veredicto: <APPROVED|CHANGES_REQUESTED|BLOCKED>
+
+[Detalle del veredicto]
+```
+
+---
+
+## Paso 6 — Guardar resultado
+
+Escribir el archivo `.opencode/review-status.json` con el resultado:
+
+```json
+{
+  "verdict": "<APPROVED|CHANGES_REQUESTED|BLOCKED>",
+  "reviewer": "opencode/review",
+  "timestamp": "<ISO 8601>",
+  "scope": "<descripción del scope revisado>"
+}
+```
+
+Si el directorio `.opencode/` no existe, crearlo.
+
+Confirmar: "Review guardado en `.opencode/review-status.json`. `/ship` lo leerá para verificar que el review fue aprobado antes de hacer deploy."
+
+---
+
+## Si BLOCKED
+
+Recordar explícitamente al final del reporte:
+
+> **Esta sesión no es apta para `/ship` hasta resolver los puntos bloqueantes listados arriba.**
+
+No sugerir hacer deploy ni continuar con otros pasos hasta que el usuario reporte que los issues fueron resueltos y vuelva a ejecutar `/review`.

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

@@ -0,0 +1,111 @@
+---
+name: session-close
+description: Cierra la sesión de trabajo con commit, daily note, RELEASE-NOTES y PR.
+---
+
+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.
+
+## 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."

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

@@ -0,0 +1,62 @@
+---
+name: session-start
+description: Inicializa una sesión de trabajo detectando el estado del repo y enrutando según el escenario.
+---
+
+Inicializa la sesión de trabajo: detecta el estado del repo, identifica el escenario y actúa 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 `AGENTS.md`, leerlo para obtener contexto del proyecto
+- Si ninguno existe, continuar con defaults: mode=startup
+
+## 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) Implementar en serie — OpenCode no soporta subagentes paralelos. (5) 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

package/assets/adapters/opencode/commands/ship.md

@@ -0,0 +1,135 @@
+---
+name: ship
+description: Pipeline de deploy. Solo disponible cuando project.yaml tiene sección deploy configurada.
+---
+
+Pipeline de deploy. Solo disponible cuando `project.yaml` tiene sección `deploy`.
+
+## Verificación inicial
+
+Leer `project.yaml`. Si no existe sección `deploy`: "deploy no configurado en project.yaml. Agregá la sección deploy para usar /ship." y detener.
+
+---
+
+## Paso 1 — Verificar review
+
+Leer `.opencode/review-status.json` si existe.
+
+- Si el archivo existe y `verdict` es `APPROVED`: continuar.
+- Si el archivo existe y `verdict` es `BLOCKED` o `CHANGES_REQUESTED`: "El último review no está aprobado (veredicto: <verdict>). Ejecutá `/review` y resolvé los issues antes de hacer deploy." y detener.
+- Si el archivo no existe: "¿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
+
+Ejecutar `git status --short`.
+
+Si hay cambios sin commitear: "Hay cambios sin commitear. Commiteá primero antes de hacer deploy." y detener.
+
+Si el working tree está limpio: continuar.
+
+## Paso 3 — Merge PR a main (condicional)
+
+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 no: continuar sin mergear.
+
+## Paso 4 — Trigger deploy
+
+Leer `project.yaml` → `deploy.provider`:
+
+- **vercel**: ejecutar `vercel deploy --prod` (o el deploy se triggeará automáticamente con el merge/push si está configurado). Guardar la URL del deployment del output para el polling.
+- **railway**: ejecutar `railway up` si está disponible en el PATH.
+- **fly**: ejecutar `fly deploy`.
+- **aws**: indicar el comando apropiado según la configuración y pedir al usuario que lo ejecute.
+- Provider no reconocido: "Provider '<valor>' no reconocido. Soportados: vercel, railway, fly, aws."
+
+## Paso 5-8 — Polling de estado con backoff
+
+**REGLA CRITICA: máximo 1 consulta al estado del deploy por minuto. Nunca encadenar polls consecutivos sin pausa.**
+
+Loop de polling (máximo 20 intentos = 20 minutos):
+
+```
+Para cada intento:
+  1. Consultar estado del deploy (una sola consulta)
+  2. Evaluar resultado:
+     - BUILDING / QUEUED / IN_PROGRESS:
+         Reportar: "Deploy en progreso (intento N/20)... esperando 60 segundos."
+         Esperar 60 segundos antes del siguiente poll.
+     - ERROR / FAILED / CANCELED:
+         Leer build logs completos.
+         Reportar el error al usuario con los logs relevantes.
+         DETENER — no continuar al Paso 9.
+     - READY / SUCCESS:
+         Continuar al Paso 9.
+  3. Si se alcanzan 20 intentos sin READY: reportar timeout y detener.
+```
+
+**Comandos según provider:**
+- Vercel: `vercel inspect <deployment-url> --json | jq '.readyState'`  o  `vercel ls --json | jq '.[0].readyState'`
+- Railway: `railway status`
+- Fly: `fly status`
+
+## Paso 9 — Verificar runtime logs
+
+Leer los primeros 60 segundos de logs post-deploy:
+- Vercel: `vercel logs <deployment-url> --since 1m`
+- Railway/Fly: logs equivalentes del provider
+
+Si hay errores en los logs:
+- Reportar los errores al usuario con contexto
+- Sugerir rollback: "¿Querés hacer rollback al deploy anterior? (s/n)"
+- **NO ejecutar rollback automáticamente — siempre requiere confirmación explícita.**
+- Si el usuario confirma rollback: ejecutar el comando de rollback del provider.
+
+Si los logs están limpios: continuar.
+
+## Paso 10 — Smoke tests (condicional)
+
+Si `project.yaml` → `deploy.smoke_tests` está definido y tiene URLs:
+
+Para cada URL de smoke test:
+```bash
+curl -s -o /dev/null -w "%{http_code}" <url>
+```
+
+- Si el código HTTP es 2xx: marcar como pasado.
+- Si el código HTTP es 4xx o 5xx: reportar fallo.
+
+Si algún smoke test falla:
+- Reportar qué URL falló y el código HTTP
+- Sugerir rollback: "¿Querés hacer rollback? (s/n)"
+- **NO ejecutar rollback automáticamente.**
+
+---
+
+## Al terminar exitosamente
+
+Obtener la URL de producción de `project.yaml` → `deploy.production_url` o del output del provider.
+
+Reportar: "Deploy exitoso. URL: [production_url]"
+
+Agregar entrada al daily note si existe `docs/daily-notes/` (buscar el archivo del día actual):
+```
+## Deploy
+- Fecha: YYYY-MM-DD HH:MM
+- Estado: exitoso
+- URL: [production_url]
+```
+
+---
+
+## Si hay errores en cualquier paso
+
+Reportar claramente:
+- En qué paso ocurrió el error
+- Qué salió mal (con logs si están disponibles)
+- Qué acción correctiva se sugiere
+
+**Nunca continuar automáticamente después de un error de deploy.** Siempre esperar confirmación explícita del usuario antes de cualquier acción de remediación.

package/assets/adapters/opencode/commands/work.md

@@ -0,0 +1,82 @@
+---
+name: work
+description: Implementa una spec en modo serial. OpenCode no soporta subagentes paralelos — toda la implementación ocurre en esta sesión.
+---
+
+Implementa una spec siguiendo el flujo SDD. OpenCode ejecuta todo en serie en la sesión actual — no se crean subagentes paralelos.
+
+Argumentos: vacío para modo estándar, `--autorun` para ejecutar sin confirmaciones intermedias.
+
+## Paso 1 — Identificar la spec
+
+Buscar archivos `.md` en `docs/specs/` que contengan `**Estado:** ready`.
+
+- 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.
+
+Leer la spec seleccionada completa antes de continuar.
+
+## Paso 2 — Leer configuración del proyecto
+
+Leer `project.yaml` si existe. Obtener:
+- `project.mode` (startup/standard/enterprise) — default: startup si no existe
+- `stack.*` — stack técnico del proyecto
+- `agents.active` — agentes disponibles (para conocer el dominio, no para spawnearlos)
+
+Si `project.yaml` no existe, continuar con defaults: mode=startup.
+
+## Paso 3 — Proponer plan de implementación
+
+Evaluar la naturaleza de la tarea según el acceptance criteria de la spec.
+
+Presentar un plan de implementación secuencial organizado por rol:
+
+```
+Plan de implementación:
+1. [Backend] Implementar endpoints/lógica de negocio: <descripción>
+2. [Frontend] Construir componentes UI: <descripción>
+3. [Tests] Escribir tests para los cambios: <descripción>
+```
+
+Adaptar el plan según el `project.mode`:
+- **startup**: plan mínimo (1-2 pasos, sin separación rígida de roles)
+- **standard**: plan con separación backend/frontend/tests
+- **enterprise**: plan con separación backend/frontend/tests + revisión de compliance al final
+
+## Paso 4 — Confirmar con el usuario
+
+Preguntar: "¿Aprobás este plan o querés ajustarlo?"
+
+Si el usuario ajusta: modificar el plan según su feedback antes de ejecutar.
+
+Si se usó `--autorun`: advertir una sola vez "Modo --autorun: ejecutaré hasta completar sin confirmaciones intermedias." y continuar.
+
+## Paso 5 — Ejecutar en serie
+
+Implementar cada paso del plan secuencialmente. Por cada paso:
+
+1. Anunciar: "Implementando: [descripción del paso]"
+2. Ejecutar los cambios de código necesarios
+3. Si hay tests para este paso: escribirlos junto con el código, no al final
+4. Reportar: "Completado: [descripción breve de qué se hizo]"
+
+En modo estándar (sin `--autorun`): pausar brevemente entre pasos para permitir que el usuario intervenga si algo no está bien.
+
+Seguir el acceptance criteria de la spec como checklist — marcar cada ítem cuando esté implementado.
+
+## Paso 6 — Verificar implementación
+
+Al completar todos los pasos, ejecutar:
+- El comando de tests del proyecto (según stack en `project.yaml`)
+- El comando de lint si está disponible
+
+Reportar los resultados. Si hay fallos: describirlos y resolverlos antes de continuar.
+
+## 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
+
+Confirmar: "Implementación completa. Spec actualizada a `implemented`. Podés ejecutar `/review` y luego `/ship`."