product-playbook 1.0.0

package/i18n/es/references/07c-architecture-setup.md

@@ -0,0 +1,197 @@
+# Handoff de Desarrollo — ARCHITECTURE.md + setup.sh
+
+## 📄 Plantilla ARCHITECTURE.md
+
+```markdown
+# [Nombre del Producto] — Arquitectura Técnica
+
+## Estructura de Directorios
+
+[Generar la estructura de directorios correspondiente basada en el stack tecnológico]
+
+## Diseño de Base de Datos
+
+[Consolidar del DB Schema del PRD — convertir a SQL CREATE TABLE o definiciones de modelos ORM]
+
+### Diagrama ER
+
+[Mermaid erDiagram]
+
+### Descripciones de Tablas Clave
+
+| Tabla | Descripción | Campos Clave | Recomendaciones de Índices |
+|-------|------------|-------------|--------------------------|
+| | | | |
+
+## Diseño de API
+
+[Definir endpoints de API RESTful o schema GraphQL basado en User Stories y especificaciones de funcionalidades]
+
+### Lista de Endpoints
+
+| Método | Ruta | Descripción | Tarea Correspondiente |
+|--------|------|------------|----------------------|
+| GET | /api/v1/[recurso] | [Descripción] | T1.1 |
+| POST | /api/v1/[recurso] | [Descripción] | T1.2 |
+
+### Autenticación
+
+[JWT / Session / OAuth, etc.]
+
+## Servicios de Terceros
+
+| Servicio | Propósito | Funcionalidad Correspondiente |
+|----------|----------|-------------------------------|
+| | | |
+
+## Arquitectura de Seguridad
+
+### Configuración CORS
+
+| Configuración | Valor | Notas |
+|--------------|-------|-------|
+| Orígenes Permitidos | [Dominio de producción, localhost:puerto] | No usar wildcard * |
+| Métodos Permitidos | GET, POST, PUT, DELETE | Basado en necesidades reales de API |
+| Cabeceras Permitidas | Content-Type, Authorization | |
+| Credentials | true/false | Depende del método de autenticación |
+
+### Cabeceras de Seguridad
+
+[Seleccionar cabeceras aplicables de references/08-security-checklist.md §5 basado en requisitos del producto]
+
+### Estrategia de Rate Limiting
+
+| Tipo de Endpoint | Límite | Método de Identificación |
+|-----------------|-------|-------------------------|
+| API General | [X] req/min | IP + User ID |
+| Login/Registro | [X] req/min | IP |
+| Subida de Archivos | [X] req/min | User ID |
+
+### Manejo de Datos Sensibles
+
+- Gestión de secretos: [.env + variables de entorno de plataforma / Secrets Manager]
+- Reglas de logging: Nunca registrar contraseñas, tokens o datos personales
+- Encriptación de datos: [TLS en tránsito / requisitos de encriptación en reposo]
+
+> Lista completa de seguridad en `references/08-security-checklist.md`
+```
+
+---
+
+## 📄 Plantilla .gitignore
+
+```gitignore
+# Variables de entorno y secretos
+.env
+.env.local
+.env.*.local
+*.pem
+*.key
+
+# Progreso de planificación de producto (puede contener información de negocio sensible)
+.product-playbook-progress.md
+
+# IDE y OS
+.idea/
+.vscode/
+*.swp
+.DS_Store
+Thumbs.db
+
+# Dependencias
+node_modules/
+__pycache__/
+*.pyc
+venv/
+
+# Output de build
+dist/
+build/
+.next/
+```
+
+---
+
+## 📄 Plantilla setup.sh
+
+```bash
+#!/bin/bash
+# [Nombre del Producto] — Script de Inicialización del Proyecto
+# Uso: chmod +x scripts/setup.sh && ./scripts/setup.sh
+
+set -e
+
+echo "🚀 Inicializando [Nombre del Producto]..."
+
+# ===== Verificar prerequisitos =====
+command -v [node/python/etc] >/dev/null 2>&1 || { echo "❌ [runtime] es requerido"; exit 1; }
+
+# ===== Instalar dependencias =====
+echo "📦 Instalando dependencias..."
+[npm install / pip install -r requirements.txt / etc]
+
+# ===== Configuración del entorno =====
+if [ ! -f .env ]; then
+  echo "📝 Creando archivo .env..."
+  cp .env.example .env
+  echo "⚠️  Por favor edita .env y completa las variables de entorno requeridas"
+fi
+
+# ===== Inicialización de base de datos =====
+echo "🗄️  Inicializando base de datos..."
+[comandos de migración]
+
+echo ""
+echo "✅ ¡Inicialización completa!"
+echo ""
+echo "Siguientes pasos:"
+echo "  1. Edita .env para completar las variables de entorno"
+echo "  2. Inicia el servidor de desarrollo: [comando de inicio]"
+echo "  3. Comienza a desarrollar: claude \"Lee CLAUDE.md y TASKS.md, luego comienza a ejecutar la Fase 1\""
+```
+
+---
+
+## Texto de Guía al Usuario
+
+### En Claude Chat / Cowork
+
+Después de producir el paquete de handoff, muestra la siguiente guía:
+
+```
+📦 ¡El paquete de handoff de desarrollo está listo! Incluye los siguientes archivos:
+
+  CLAUDE.md        → Memoria de proyecto de Claude Code (contexto de producto + especificaciones técnicas)
+  TASKS.md         → Lista de tareas de desarrollo (4 Fases, [N] Tareas en total)
+  TICKETS.md       → Lista de tickets ([N] tickets, listos para crear en Jira/Asana/Linear)
+  docs/PRD.md      → PRD completo
+  docs/ARCHITECTURE.md → Arquitectura técnica (esquema BD + API + estructura de directorios)
+  docs/PRODUCT-SPEC.md → Resumen de Spec de Producto
+  scripts/setup.sh → Script de inicialización en un solo comando
+
+🔗 Cómo iniciar el desarrollo:
+
+  1. Descarga y extrae a tu carpeta de proyecto
+  2. Abre una terminal y navega a la carpeta del proyecto
+  3. Lanza Claude Code:
+     $ claude
+  4. Dile a Claude Code que comience:
+     > Lee CLAUDE.md y TASKS.md, luego comienza a ejecutar la Fase 0
+
+💡 Consejos:
+  - Claude Code lee automáticamente CLAUDE.md, así que ya conoce el contexto completo del producto
+  - Después de completar cada Fase, preguntará si deseas proceder a la siguiente
+  - Para ajustar el alcance de funcionalidades, simplemente edita TASKS.md directamente
+  - La lista "Explícitamente No Hacer" en CLAUDE.md previene que Claude Code construya fuera del alcance
+```
+
+### Confirmación Final Pre-Output
+
+```
+Antes de producir el paquete de handoff de desarrollo, necesito confirmar algunas cosas:
+
+1. Stack tecnológico: [Confirmado / Necesita confirmación]
+2. Nombre del producto (para el nombre de la carpeta del proyecto): [Confirmado / Necesita confirmación]
+3. ¿Alguna otra restricción o preferencia técnica?
+   - p.ej., Debe usar un ORM específico, necesita soportar navegadores específicos, CI/CD existente, etc.
+```

package/i18n/es/references/08-security-checklist.md

@@ -0,0 +1,221 @@
+# Lista de Verificación de Seguridad
+
+> Se carga antes de producir el paquete de handoff de desarrollo. Asegura que los requisitos críticos de seguridad se consideren durante la fase de planificación de producto, previniendo que la seguridad sea una ocurrencia tardía.
+
+## 🔐 Verificación Rápida de Arquitectura de Seguridad
+
+Antes de producir el paquete de handoff de desarrollo, verifica cada uno de los siguientes aspectos de seguridad. Marca cada uno como ✅ (cubierto en planificación) o ❌ (necesita agregarse).
+
+### 1. Autenticación y Autorización
+
+```
+| Ítem de Verificación | Estado | Notas |
+|---------------------|--------|-------|
+| Método de autenticación determinado (JWT / Session / OAuth / Passkey) | | |
+| Almacenamiento de token es seguro (HttpOnly Cookie, no localStorage) | | |
+| Expiración de token y mecanismo de refresh diseñado | | |
+| Almacenamiento de contraseña usa bcrypt / argon2 (no MD5/SHA) | | |
+| Modelo de permisos definido (RBAC / ABAC / roles simples) | | |
+| Todos los endpoints API tienen verificaciones de autorización correspondientes | | |
+| Fallos de login tienen protección contra fuerza bruta (bloqueo / retraso progresivo) | | |
+```
+
+**Mejores Prácticas JWT (si se usa JWT):**
+- Usa Access Tokens de corta duración (15-30 minutos) + Refresh Tokens de larga duración
+- Almacena Refresh Tokens en HttpOnly Secure Cookies
+- Implementa Token Revocation (invalida Refresh Token al cerrar sesión)
+- No almacenes información sensible en el payload del JWT
+
+### 2. Política CORS (Cross-Origin Resource Sharing)
+
+```
+| Ítem de Verificación | Estado | Notas |
+|---------------------|--------|-------|
+| Lista de orígenes permitidos definida (sin wildcard *) | | |
+| Solo métodos HTTP necesarios están permitidos | | |
+| Access-Control-Allow-Credentials configurado | | |
+| Duración de caché de preflight es razonable (Access-Control-Max-Age) | | |
+```
+
+**Plantilla de Configuración CORS:**
+```
+Orígenes Permitidos:
+  - Producción: https://[tu-dominio.com]
+  - Desarrollo: http://localhost:[puerto]
+
+Métodos Permitidos: GET, POST, PUT, DELETE, PATCH
+Cabeceras Permitidas: Content-Type, Authorization
+Credentials: true (si se usa autenticación basada en cookies)
+Max-Age: 86400 (24 horas)
+```
+
+### 3. Validación de Input y Sanitización
+
+```
+| Ítem de Verificación | Estado | Notas |
+|---------------------|--------|-------|
+| Todos los inputs de API tienen validación del lado del servidor | | |
+| Se usan consultas parametrizadas para prevenir SQL Injection | | |
+| Input de usuario tiene output-encoding antes de renderizar a HTML (prevención XSS) | | |
+| Subidas de archivos tienen restricciones de tipo / tamaño | | |
+| URL / destinos de redirección tienen validación por whitelist (prevención Open Redirect) | | |
+```
+
+**Principios de Validación:**
+- La validación frontend es UX; la validación backend es seguridad — ambas son necesarias, pero la validación backend es innegociable
+- Usa una Biblioteca de Validación de Schema (p.ej., Zod, Joi, Pydantic) para lógica de validación unificada
+- Rechaza inputs que no coincidan con formatos esperados — no intentes "arreglar" el input del usuario
+
+### 4. Protección CSRF (Cross-Site Request Forgery)
+
+```
+| Ítem de Verificación | Estado | Notas |
+|---------------------|--------|-------|
+| Operaciones que cambian estado usan POST/PUT/DELETE (no GET) | | |
+| CSRF Token implementado o SameSite Cookie usado | | |
+| Operaciones críticas tienen confirmación secundaria | | |
+```
+
+### 5. Cabeceras de Seguridad
+
+```
+| Cabecera | Propósito | Valor Recomendado |
+|----------|----------|-------------------|
+| Content-Security-Policy (CSP) | Prevenir XSS, inyección de datos | default-src 'self'; script-src 'self' |
+| X-Content-Type-Options | Prevenir MIME sniffing | nosniff |
+| X-Frame-Options | Prevenir clickjacking | DENY o SAMEORIGIN |
+| Strict-Transport-Security (HSTS) | Forzar HTTPS | max-age=31536000; includeSubDomains |
+| X-XSS-Protection | Filtro XSS del navegador | 0 (depender de CSP es más confiable) |
+| Referrer-Policy | Controlar información de referrer | strict-origin-when-cross-origin |
+| Permissions-Policy | Restringir funcionalidades del navegador | camera=(), microphone=(), geolocation=() |
+```
+
+### 6. Seguridad API y Rate Limiting
+
+```
+| Ítem de Verificación | Estado | Notas |
+|---------------------|--------|-------|
+| API tiene rate limiting global (p.ej., 100 req/min/IP) | | |
+| Endpoints sensibles tienen límites más estrictos (login 5 req/min, registro 3 req/min) | | |
+| Respuestas de error API no filtran detalles internos (stack traces, sentencias SQL) | | |
+| Estrategia de versionamiento de API determinada (/api/v1/) | | |
+| Endpoints de datos masivos tienen límites de paginación | | |
+```
+
+**Recomendaciones de Diseño de Rate Limiting:**
+```
+| Tipo de Endpoint | Límite Recomendado | Método de Identificación |
+|-----------------|-------------------|-------------------------|
+| API General | 100 req/min | IP + User ID |
+| Login/Registro | 5 req/min | IP |
+| Restablecimiento de Contraseña | 3 req/hora | IP + Email |
+| Subida de Archivos | 10 req/min | User ID |
+| Búsqueda/Consulta | 30 req/min | IP + User ID |
+```
+
+### 7. Anti-Scraping y Protección contra Bots
+
+```
+| Ítem de Verificación | Estado | Notas |
+|---------------------|--------|-------|
+| robots.txt configurado (restringir rutas sensibles) | | |
+| Formularios críticos tienen protección contra bots (reCAPTCHA / hCaptcha / Honeypot) | | |
+| API tiene verificaciones de User-Agent (opcional) | | |
+| Operaciones sensibles tienen análisis de comportamiento (opcional, avanzado) | | |
+```
+
+**Estrategia de Protección por Capas:**
+1. **Capa básica**: Rate Limiting + robots.txt — Todo producto debería tener esto
+2. **Capa estándar**: + CAPTCHA (registro/login) + campos Honeypot — Recomendado para productos B2C
+3. **Capa avanzada**: + Análisis de comportamiento + reputación de IP + Device Fingerprint — Productos de alto riesgo
+
+### 8. Protección de Datos Sensibles
+
+```
+| Ítem de Verificación | Estado | Notas |
+|---------------------|--------|-------|
+| Datos sensibles encriptados en tránsito (HTTPS/TLS) | | |
+| Datos sensibles encriptados en reposo (si es requerido) | | |
+| Secretos y claves no almacenados en código | | |
+| .env y archivos sensibles agregados a .gitignore | | |
+| Logs no registran contraseñas, tokens, números de tarjeta de crédito, etc. | | |
+| Política clara de retención y eliminación de datos (GDPR si aplica) | | |
+```
+
+**Recomendaciones de Gestión de Secretos:**
+- Desarrollo: Archivo `.env` (no en control de versiones) + `.env.example` (solo nombres de claves, sin valores)
+- Producción: Usar gestión de variables de entorno de la plataforma (Vercel Environment Variables / Railway Variables / AWS Secrets Manager)
+- Nunca mencionar secretos en mensajes de commit, descripciones de PR o issues
+
+### 9. Plantilla de Seguridad .gitignore
+
+```gitignore
+# Variables de entorno y secretos
+.env
+.env.local
+.env.*.local
+*.pem
+*.key
+
+# Progreso de planificación de producto (puede contener información de negocio sensible)
+.product-playbook-progress.md
+
+# IDE y OS
+.idea/
+.vscode/
+*.swp
+.DS_Store
+Thumbs.db
+
+# Dependencias
+node_modules/
+__pycache__/
+*.pyc
+venv/
+
+# Output de build
+dist/
+build/
+.next/
+```
+
+---
+
+## 🏷️ Referencia Rápida OWASP Top 10
+
+| # | Riesgo | ¿Relevante para Este Producto? | Verificación Correspondiente |
+|---|--------|-------------------------------|----------------------------|
+| A01 | Broken Access Control | [Sí/No] | §1 Autenticación y Autorización |
+| A02 | Cryptographic Failures | [Sí/No] | §8 Protección de Datos Sensibles |
+| A03 | Injection (SQL / XSS / Command) | [Sí/No] | §3 Validación de Input |
+| A04 | Insecure Design | [Sí/No] | Diseño general de arquitectura |
+| A05 | Security Misconfiguration | [Sí/No] | §5 Cabeceras + §2 CORS |
+| A06 | Vulnerable Components | [Sí/No] | Gestión de dependencias (npm audit / pip audit) |
+| A07 | Authentication Failures | [Sí/No] | §1 Autenticación y Autorización |
+| A08 | Data Integrity Failures | [Sí/No] | §3 Validación de Input + §8 Protección de Datos |
+| A09 | Logging & Monitoring Failures | [Sí/No] | §8 Reglas de logging |
+| A10 | SSRF (Server-Side Request Forgery) | [Sí/No] | §3 Validación de URL por whitelist |
+
+---
+
+## 📎 Momento de Integración
+
+| Disparador | Acción de Integración |
+|-----------|----------------------|
+| Antes de producir el paquete de handoff de desarrollo | Ejecutar la verificación rápida de seguridad, integrar resultados en las secciones "Alertas de Riesgo" de CLAUDE.md y "Arquitectura de Seguridad" de ARCHITECTURE.md |
+| Al producir el PRD | Integrar resultados de verificación de seguridad en PRD §6 "Consideraciones Técnicas → Requisitos de Seguridad" |
+| Paso de Pre-mortem | Invitar al usuario a considerar escenarios de falla de seguridad |
+| Modo Revisión S1 | Invitar al usuario a proporcionar la postura de seguridad actual del producto existente |
+
+## Autoevaluación de Calidad
+
+```
+| Ítem de Verificación | ✅/❌ |
+|---------------------|------|
+| Método de autenticación elegido explícitamente, no dejado como "TBD" | |
+| Al menos 3 cabeceras de seguridad planificadas | |
+| Estrategia de rate limiting adaptada a las características del producto (no solo copiada de la plantilla) | |
+| .gitignore incluye todos los archivos sensibles | |
+| Todos los ítems OWASP Top 10 marcados como "relevantes" tienen medidas correspondientes | |
+| Complejidad de medidas de seguridad coincide con la etapa del producto (MVP no necesita seguridad perfecta, pero lo básico es innegociable) | |
+```

package/i18n/es/references/rules-build.md

@@ -0,0 +1,152 @@
+# ⚡ Secuencia de Pasos del Modo Build (7 Pasos + Output Final)
+
+> Este archivo es la definición autoritativa de pasos para el Modo Build. Cargado por el despachador central de SKILL.md.
+
+> ⚠️ Recordatorio obligatorio: "Omitir la fase de investigación de usuarios significa que tu solución está construida sobre suposiciones. Recomendamos realizar Descubrimiento Continuo lo antes posible después de la ejecución para validar."
+
+## Secuencia de Pasos
+
+```
+S1. Confirmar declaración del problema (una oración)
+S2. PR-FAQ → Leer references/04a-prfaq.md
+S3. Soluciones paralelas → Leer references/04b-solutions.md → 3.2
+S4. Pre-mortem → Leer references/04b-solutions.md → 3.3
+S5. Priorización GEM + RICE → Leer references/04b-solutions.md → 3.4 + 3.5
+S6. MVP + Lista de No Hacer → Leer references/04c-mvp.md
+S7. North Star + Aha Moment → Leer references/05a-northstar-aha.md
+────
+Output Final → Resumen de ejecución orientado a ingenieros
+```
+
+## Instrucciones de Carga de Referencias
+
+| Paso | Archivo de Referencia |
+|------|----------------------|
+| S1 | No se necesita referencia externa (guiar directamente al usuario para declarar el problema) |
+| S2 | `references/04a-prfaq.md` |
+| S3-S5 | `references/04b-solutions.md` |
+| S6 | `references/04c-mvp.md` |
+| S7 | `references/05a-northstar-aha.md` |
+
+## Formato del Output Final
+
+**Resumen de ejecución orientado a ingenieros**: Decisiones de solución → Límites del MVP → Métricas de éxito → Riesgos clave
+
+Al completar, sigue `references/rules-end-of-flow.md` para ejecutar las reglas de fin de flujo.
+
+---
+
+## 🔧 Ruta Rápida de Extensión de Feature (4 Pasos)
+
+> Se cambia automáticamente a esta ruta cuando el usuario está **agregando una sola funcionalidad a un producto existente**.
+> Condiciones de activación: La descripción del usuario incluye frases como "agregar una funcionalidad," "nueva funcionalidad," "agregar funcionalidad XX," "sobre el sistema existente," "el producto existente necesita," etc.
+
+**Diferencias con el Modo Build completo (7 pasos)**: Un producto existente ya tiene North Star, Aha Moment y posicionamiento de producto — no es necesario redefinirlos. Una sola funcionalidad no requiere un comunicado de prensa PR-FAQ ni una re-priorización completa GEM+RICE. El enfoque está en "qué agregar, cómo agregarlo, y si romperá funcionalidades existentes."
+
+### Secuencia de Pasos de Extensión de Feature
+
+```
+S1. Problema + contexto del sistema existente
+S2. Tres soluciones paralelas + pros/contras + recomendación AI → Leer references/04b-solutions.md → 3.2
+S3. Evaluación de riesgos (regresión + compatibilidad) → Leer references/04b-solutions.md → 3.3
+S4. Alcance de ejecución (qué hacer / qué no tocar / criterios de aceptación) → Leer references/04c-mvp.md
+────
+Output Final → Especificación de desarrollo de feature
+```
+
+### Pre-paso S1: Carga de Contexto de Producto
+
+Antes de entrar a S1, lee `references/rules-context.md` y verifica `.product-context.md`:
+
+- **Contexto completo disponible (Escenario 1)**: Trae automáticamente nombre del producto, stack tecnológico, módulos clave, y las 3 entradas más recientes del Historial de Decisiones. Cambia la guía de S1 a **estilo confirmación**: "Tu producto es [nombre], usando [stack tecnológico], con módulos clave incluyendo [lista de módulos]. ¿Qué funcionalidad quieres agregar? ¿Qué módulos serán afectados?" (Preguntas 2 y parte de la pregunta 3 están pre-llenadas — solo necesita confirmación)
+- **Sin contexto (Escenario 2)**: Activar Context Bootstrap (`rules-context.md` Sección 4), luego proceder al S1 estándar abajo
+- **Contexto parcial (Escenario 3)**: Traer stack tecnológico y módulos conocidos (fusionados del Historial de Decisiones), y recopilar las partes faltantes. Por ejemplo: "Además de [módulos conocidos], ¿hay otros módulos que podrían verse afectados?"
+
+### Contenido de Guía S1 (Problema + Contexto del Sistema Existente)
+
+Claude necesita recopilar la siguiente información (guiar paso a paso — no hacer todas las preguntas a la vez. Si el contexto ya ha pre-llenado algunas respuestas, confirmar en lugar de re-recopilar):
+
+```
+1. ¿Qué funcionalidad quieres agregar? ¿Qué problema resuelve?
+2. Resumen de la arquitectura actual del producto (stack tecnológico, módulos clave) ← el contexto puede pre-llenar
+3. ¿Qué módulos existentes afectará esta funcionalidad? ← el contexto puede pre-llenar parcialmente
+4. ¿Hay algún feedback de usuarios o datos que respalden este requisito?
+```
+
+### Contenido de Guía S2 (Tres Soluciones Paralelas + Recomendación AI)
+
+```
+| HMW | Solución A (Conservadora / cambio mínimo) | Solución B (Equilibrada) | Solución C (Audaz / refactorización) |
+|-----|------------------------------------------|-------------------------|-------------------------------------|
+| [Problema] | | | |
+
+| Solución | Pros | Contras | Alcance de Impacto | Complejidad de Implementación |
+|----------|------|---------|-------------------|-------------------------------|
+| A | | | | |
+| B | | | | |
+| C | | | | |
+
+🤖 Recomendación AI: Solución [X]
+Justificación: [Juicio integral basado en alcance de impacto, complejidad y riesgo]
+```
+
+### Contenido de Guía S3 (Evaluación de Riesgos — Enfocada en Regresión y Compatibilidad)
+
+```
+| Tipo de Riesgo | Riesgo Específico | Probabilidad | Mitigación |
+|---------------|-------------------|-------------|-----------|
+| Riesgo de regresión | [Áreas donde funcionalidades existentes pueden verse afectadas] | | |
+| Riesgo de compatibilidad | [Conflictos con arquitectura/datos/APIs existentes] | | |
+| Riesgo de rendimiento | [Impacto de la nueva funcionalidad en el rendimiento del sistema] | | |
+| Riesgo de seguridad | [Consideraciones de seguridad introducidas por la nueva funcionalidad] | | |
+```
+
+### Contenido de Guía S4 (Alcance de Ejecución)
+
+```
+**Qué hacer (Alcance)**:
+- [Ítems específicos de funcionalidad a agregar]
+- [Módulos existentes que necesitan modificación]
+
+**No Tocar**:
+- [Módulos y funcionalidades que explícitamente no se deben modificar]
+- [Razón para no tocarlos]
+
+**Criterios de Aceptación**:
+- [ ] [Condición específica comprobable]
+- [ ] [Prueba de regresión: confirmar que funcionalidades existentes no se ven afectadas]
+```
+
+### Formato del Output Final de Extensión de Feature
+
+**Especificación de desarrollo de feature**: Declaración del problema → Solución seleccionada + justificación → Alcance de impacto → Alcance de ejecución + criterios de aceptación → Lista de riesgos
+
+### Salida Incremental de Documento (cuando hay documento fuente disponible)
+
+Si el usuario subió un documento fuente (PRD, especificación, etc.) durante el proceso:
+
+1. **Versión incremental** (predeterminada cuando existe documento fuente):
+   - Insertar/modificar secciones en la estructura del documento original
+   - Mantener el formato, estilo y convenciones de nomenclatura del archivo original
+   - Contenido nuevo marcado con `[NEW]`
+   - Contenido modificado marcado con `[UPDATED]` con el original preservado como referencia
+   - Las secciones no relacionadas con la nueva funcionalidad permanecen completamente intactas
+
+2. **Versión independiente** (cuando no hay documento fuente):
+   - Usar el formato estándar de especificación de desarrollo de feature (como se definió arriba)
+
+3. **Preguntar al usuario antes de generar**:
+   "Detecté que subiste un [tipo de documento]. ¿Cómo deseas la salida?
+    A) Actualización incremental sobre el documento original (recomendado)
+    B) Especificación de desarrollo de feature independiente"
+
+### Instrucciones de Carga de Referencias
+
+| Paso | Archivo de Referencia |
+|------|----------------------|
+| S1 | No se necesita referencia externa |
+| S2 | `references/04b-solutions.md` → 3.2 |
+| S3 | `references/04b-solutions.md` → 3.3 |
+| S4 | `references/04c-mvp.md` |
+
+Al completar, sigue `references/rules-end-of-flow.md` para ejecutar las reglas de fin de flujo.

package/i18n/es/references/rules-change-propagation.md

@@ -0,0 +1,74 @@
+# 🔄 Reglas de Propagación de Cambios
+
+> Se carga cuando el usuario modifica un paso previamente completado.
+
+## 📍 Indicador de Progreso (debe mostrarse en cada paso)
+
+Al ejecutar cualquier paso, Claude debe mostrar una barra de progreso al inicio de la respuesta, en este formato:
+
+```
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+📍 [Modo de Ejecución] ｜ Progreso S[número de paso actual] / S[total de pasos]
+✅ S1: [Nombre del paso] (completado)
+✅ S2: [Nombre del paso] (completado)
+▶️ S3: [Nombre del paso] (en progreso)
+⬜ S4: [Nombre del paso] (pendiente)
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+```
+
+Este indicador de progreso debe aparecer en las siguientes situaciones:
+- Al entrar a un nuevo paso
+- Cuando el usuario regresa a un paso para hacer modificaciones
+- Al completar un paso y solicitar confirmación del usuario antes de pasar al siguiente
+
+## Métodos de Activación
+- "Volver a Persona," "Volver a JTBD," "Volver a HMW," "Volver a PR-FAQ," o cualquier otro nombre de paso
+- "Quiero modificar [nombre del paso]," "[nombre del paso] — quiero cambiar algo"
+- Referirse directamente a una tabla o contenido ya producido con "cambia esto a..."
+
+## Acciones Requeridas Después de Modificación
+
+Cuando cualquier paso se modifica, Claude **debe realizar proactivamente las siguientes verificaciones**:
+
+```
+Capa Modificada               Downstream Afectado (debe re-confirmar o actualizar)
+─────────────────────────────────────────────────────
+Persona / JTBD            → HMW, Tabla de Evaluación de Oportunidades, Posicionamiento, PR-FAQ, North Star, Resumen de Spec de Producto
+HMW / Evaluación de Oportunidades → PR-FAQ, Soluciones Paralelas, MVP, North Star, Resumen de Spec de Producto
+Posicionamiento               → PR-FAQ, Resumen de Spec de Producto
+PR-FAQ / Soluciones        → Pre-mortem, GEM/RICE, MVP, Aha Moment, Resumen de Spec de Producto
+MVP / Lista de No Hacer      → User Story, esquema BD (si ya se generó), Resumen de Spec de Producto
+North Star / Métricas      → Plan de Validación de Hipótesis, Resumen de Spec de Producto
+Resumen de Spec de Producto      → Reporte HTML, PRD (si ya se generó)
+```
+
+### Dependencia de Extensión de Funcionalidad:
+```
+Dependencia de Extensión de Funcionalidad:
+─────────────────────────────────────────────────────
+S1 (Problema + Contexto)      → S2 (Soluciones), S3 (Riesgos), S4 (Alcance de Ejecución)
+S2 (Solución Seleccionada)    → S3 (Riesgos), S4 (Alcance de Ejecución)
+S3 (Evaluación de Riesgos)    → S4 (Alcance de Ejecución)
+```
+
+## Proceso de Ejecución
+
+1. **Informar al usuario del alcance del impacto**: "Modificaste [paso]. Esto afecta [lista de pasos downstream]. Actualizaré cada uno."
+2. **Confirmar o auto-actualizar ítems downstream**:
+   - Si el cambio downstream es menor (ajustes de redacción) → Actualizar directamente y explicar qué cambió
+   - Si el cambio downstream es significativo (cambio de dirección) → Solicitar confirmación del usuario sobre la nueva dirección antes de actualizar
+3. **Re-integrar el Resumen de Spec de Producto**
+4. **Si ya se generó un reporte HTML o PRD**: Re-generarlo directamente y producir un snapshot de versión:
+
+```
+📋 Snapshot de Versión v[versión anterior] → v[nueva versión]
+Paso modificado: [Nombre del paso]
+Contenido clave antes de modificación: [1-3 oraciones]
+Contenido clave después de modificación: [1-3 oraciones]
+Actualizaciones downstream activadas: [Qué pasos también se ajustaron]
+```
+
+## Principios
+- Ninguna modificación ocurre en silencio — el alcance del impacto siempre debe comunicarse explícitamente
+- El usuario tiene el derecho de elegir "solo modificar este paso, dejar downstream como está por ahora." Claude debe marcar qué partes están desactualizadas (agregar etiqueta ⚠️ Necesita Actualización)
+- El historial de modificaciones permanece rastreable dentro de la conversación