# 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.