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 44 preguntas (instrumento v2, Jun 2026) con el widget correcto por tipo (single_choice, multiple_choice, rating, text_long, text_short), 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í' (triggers: 1.1/1.6/1.13).
Tipos de widget: single_choice→radio, multiple_choice→checkbox, rating→escala 1-5, text_long→textarea, text_short→input de texto de una línea (A1/A2/A3).
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 44 preguntas leídas desde Supabase (no hardcodeadas).
Lógica condicional: 1.1/1.6/1.13 = "Sí" despliegan sus bloques; "No"/"Prefiero no decir" ocultan y limpian.
6.2 limita a 3 selecciones; rating (3.5/4.3) maneja formato objeto; A1/A2/A3 son text_short.
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.

3.4 KiB Raw Blame History