Terminado sprint 2A

sprints/sprint-2/BRIEF.md

@@ -0,0 +1,50 @@
+# BRIEF — Sprint 2: Formulario funcional
+
+> Brief versionado (Patrón A.1). Enmarca el sprint completo; el detalle ejecutable de cada etapa va
+> en su `ETAPA_*_PROMPT.md`.
+
+## Objetivo (una frase)
+Que un respondente pueda abrir un link, ver la encuesta de cuidadores renderizada desde el esquema,
+responderla con su lógica condicional, y enviarla — primero el motor del formulario (2A), luego el
+consentimiento y la persistencia (2B).
+
+## Por qué este sprint, y por qué partido
+Es la primera pieza de cara al usuario real: permite **probar UX, lógica condicional, accesibilidad y
+mobile, y dar feedback** antes de invertir en lo demás. Se parte en dos porque mezclan dos riesgos
+distintos y conviene auditarlos por separado:
+- **2A = riesgo de UX/funcionalidad** (¿se ve bien?, ¿la condicional anda?, ¿es accesible y mobile?).
+- **2B = riesgo legal/privacidad** (consentimiento versionado inmutable, texto honesto, escritura del dato sensible).
+
+## Alcance
+- **Etapa 2A — Motor del formulario:** lee la encuesta live desde Supabase (anon key), renderiza las
+  34 preguntas con el widget correcto por tipo, ejecuta la lógica condicional, valida, mobile-first,
+  WCAG AA, resiliencia lite. **Al enviar muestra un resumen; NO escribe en la base.**
+- **Etapa 2B — Consentimiento + persistencia:** pantalla de consentimiento granular versionado
+  (ADR-003) con texto honesto sobre anonimato y no-revocación, que crea el `consent_record` y recién
+  ahí escribe `response` + `answers`, con dedup por `ip_hash`.
+
+## Fuera de alcance (Sprint 2)
+- Dashboard / reportes (Sprint 3).
+- Builder visual de encuestas (post-validación del caso fijo).
+- Login de cliente / multi-tenant (org_admin queda inerte; ver `DATA_MODEL.md`).
+- Integración LLM, Modo B, Nivel 3.
+
+## Decisiones ya tomadas (no renegociar — ver ADRs y CLAUDE.md)
+- Supabase como backend (ADR-002): el cliente habla directo a Supabase vía SDK + RLS.
+- El formulario corre como **`anon`** (sin login). `service_role` NUNCA en el cliente (regla 9).
+- El respondente nunca se ata a un IdP (regla 10 / ADR-004).
+- `options`: array para `single_choice`/`multiple_choice`, objeto `{min,max,min_label,max_label}` para `rating`.
+- Condicionales en la pregunta dependiente; disparador value `'Sí'` (B1/C1/D1).
+- WCAG 2.2 AA es pilar (el sujeto es la discapacidad), no checkbox.
+- El mockup `formulario_mapeo.html` es el **contrato visual** (look y flujo ya aprobados); 2A lo
+  replica pero data-driven desde el esquema, no hardcodeado.
+
+## Criterios de éxito (Etapa 2A)
+- [ ] Renderiza las 34 preguntas leídas desde Supabase (no hardcodeadas).
+- [ ] Lógica condicional: B1/C1/D1 = "Sí" despliega sus bloques; "No"/"Prefiero no decir" los oculta y limpia.
+- [ ] H1 limita a 3 selecciones; `rating` (F3/G4) maneja el formato objeto.
+- [ ] Mobile-first fluido + navegable solo con teclado + WCAG AA base.
+- [ ] Refresh no pierde lo cargado (resiliencia lite).
+- [ ] Enviar muestra resumen; no escribe en la base.
+- [ ] Build limpio; sin `service_role` en variables del cliente.
+- [ ] **Validación humana (P2):** el director lo abre en desktop y mobile y lo clickea de punta a punta.