spec-driven-developmentlisted

# Spec-Driven Development Cómo trabajar día a día una vez que el proyecto ya tiene `SPEC.md` + `spec/` (creados por la skill `project-init`). Esta skill no crea estructura — gobierna el flujo de lectura/escritura sobre la estructura que ya existe. ## Regla de apertura de sesión Antes de cualquier acción, leer `SPEC.md` completo (es corto a propósito, esto no debería costar tokens significativos) y confirmar contexto con el mensaje exacto definido en `CLAUDE.md`: ``` ✅ Contexto cargado — SPEC.md v[VERSION] | [N] tests | Próximo paso: [PRIMER_ITEM_PENDIENTE] ``` No empezar a trabajar sin esta confirmación — es la forma de detectar temprano si `SPEC.md` está desactualizado respecto al estado real del código (ver "Detección de inconsistencias" más abajo). ## Regla de cierre de sesión — registro inmediato, no acumulado Después de cualquier breakthrough (feature completada, bug crítico resuelto, migración ejecutada), actualizar de inmediato, antes de seguir con la siguiente tarea: 1. `SPEC.md` — marcar ítems `[x]`, actualizar tabla de estado (sección 2) y footer con conteo de tests 2. `spec/completado.md` — agregar la línea del ítem completado 3. `spec/historial.md` — agregar contenido de references/historial-md-template.md 4. Si el proyecto usa `brain/`: evaluar si esta decisión amerita un ADR nuevo (ver skill `brain-adr` para el criterio) **No esperar al cierre de sesión para hacer esto.** Acumular actualizaciones "para el final" es la causa más común de que `SPEC.md` qu