184 lines
8.6 KiB
Markdown
184 lines
8.6 KiB
Markdown
# ETAPA 2F — Formulario: numeración visible + eliminar disclaimers por sección
|
||
|
||
## 1. Objetivo
|
||
Dos cambios cosméticos sobre el formulario que ve el respondente:
|
||
1. Mostrar el número de sección en su encabezado y el código de pregunta junto a cada pregunta.
|
||
2. Eliminar los disclaimers de "esta sección contiene preguntas sensibles" que aparecen
|
||
debajo del encabezado de cada sección. La encuesta se trata como un todo atómico:
|
||
la persona acepta responderla entera al inicio (los 2 checks ya implementados); no se
|
||
re-pide consentimiento por sección.
|
||
|
||
**Etapa Nivel 2 — cambio visible al usuario, sin tocar datos ni lógica.** No toca el
|
||
seed, ni las RPC, ni los componentes de captura, ni el componente de consentimiento.
|
||
|
||
---
|
||
|
||
## 2. Contexto previo
|
||
- Etapa 2E cerrada (refactor de dashboard alineado al instrumento real).
|
||
- El director observó visualmente el formulario y detectó dos puntos de fricción:
|
||
(a) las preguntas no muestran su código, lo que dificulta dar feedback con precisión;
|
||
(b) hay disclaimers por sección que crean fricción innecesaria.
|
||
- El consentimiento inicial con dos checks (operativo + macro) ya advierte de manera
|
||
general sobre el tratamiento de datos. Ese es el contrato — no se duplica por sección.
|
||
|
||
---
|
||
|
||
## 3. DECISIONES YA TOMADAS — no consultar de nuevo
|
||
|
||
### 3.1 Numeración de secciones
|
||
Cada encabezado de sección muestra el número antes del título.
|
||
Formato: **"Sección {N} · {Título}"** donde {N} es A, 1, 2, 3, 4, 5, 6 o 7.
|
||
|
||
Ejemplos finales:
|
||
- "Sección A · Datos Generales"
|
||
- "Sección 1 · Prevalencia: cuidado y discapacidad"
|
||
- "Sección 2 · Intensidad y rol del cuidado"
|
||
- "Sección 3 · Impacto económico del cuidado"
|
||
- "Sección 4 · Tiempo y descanso"
|
||
- "Sección 5 · Impacto en el trabajo"
|
||
- "Sección 6 · Conciencia organizacional"
|
||
- "Sección 7 · Para cerrar"
|
||
|
||
Los nombres de cada sección se toman literalmente de `SEED_SPEC.md` (sin reinterpretar
|
||
ni acortar).
|
||
|
||
### 3.2 Código de pregunta junto a cada pregunta
|
||
Cada pregunta muestra su código como tag/etiqueta pequeña antes del texto de la pregunta.
|
||
|
||
Especificaciones visuales:
|
||
- Color: `#43BBC8` (teal RE) o `#7A8FA0` (muted) — elegir el que dé mejor contraste sin
|
||
competir con el texto principal de la pregunta.
|
||
- Peso: bold o semibold (que el código se distinga visualmente del texto).
|
||
- Tamaño: ~0.8× del texto de la pregunta.
|
||
- Posición: en la misma línea que el inicio del texto, separado por un punto medio (·)
|
||
o por un espacio + tag con borde. Ejemplo: `1.1 · ¿Vos mismo/a vivís con alguna...?`
|
||
- Las preguntas dentro de bloques condicionales (1.2-1.5, 1.7-1.12, 1.14-1.16) muestran
|
||
su código tal cual está en el seed. Los saltos visibles (1.1 → 1.6 si no se dispara
|
||
el bloque) son intencionales — el respondente ve que existe lógica condicional.
|
||
|
||
### 3.3 Eliminación de disclaimers por sección
|
||
Eliminar TODO disclaimer que aparezca debajo del encabezado de una sección con texto del
|
||
estilo:
|
||
- "Esta sección contiene preguntas sensibles..."
|
||
- "Responder es voluntario..."
|
||
- Cualquier variante semánticamente equivalente.
|
||
|
||
El disclaimer confirmado a eliminar (visto en captura):
|
||
> "Esta sección contiene preguntas sensibles sobre salud o discapacidad. Responder es completamente voluntario."
|
||
|
||
**Verificar si existen disclaimers similares en OTRAS secciones** (ej: Sección 3 por
|
||
3.4 salario) y eliminarlos también. La eliminación es consistente: ninguna sección lleva
|
||
disclaimer propio.
|
||
|
||
### 3.4 NO tocar el componente de consentimiento
|
||
El `consent-screen.tsx` (o equivalente) con los dos checks (operativo + macro) **queda
|
||
intacto**. Esa es la advertencia que la persona acepta al inicio, y es suficiente
|
||
porque cubre el tratamiento de datos del formulario completo.
|
||
|
||
### 3.5 Backlog futuro (NO esta etapa)
|
||
El texto del consentimiento inicial debería ser editable cuando se construya el motor
|
||
de formularios (sprint futuro del builder). **Agregar como ítem al BACKLOG.md** (no a
|
||
TECH_DEBT, porque no es deuda — es feature pendiente):
|
||
|
||
```
|
||
[BACKLOG-XXX] Consentimiento inicial editable desde admin
|
||
- Estado: hoy el texto del consentimiento está hardcoded en consent-screen.tsx.
|
||
- Necesidad: cuando se construya el motor de formularios (builder), el texto del
|
||
consentimiento debe ser editable por encuesta desde la administración, para reflejar
|
||
cambios en política de privacidad o ajustes específicos por tipo de relevamiento.
|
||
- Bloquea: implementación del builder visual.
|
||
- Decisión cerrada: la edición es desde admin, no desde el código.
|
||
```
|
||
|
||
---
|
||
|
||
## 4. Tareas
|
||
|
||
### 4.1 Verificación previa (Patrón C.8)
|
||
Antes de tocar nada, verificar contra `SEED_SPEC.md`:
|
||
- Los 8 nombres exactos de las secciones (A, 1, 2, 3, 4, 5, 6, 7).
|
||
- Los códigos de pregunta de la sección A y de cada sección numérica.
|
||
|
||
Si encontrás discrepancias entre los nombres de las secciones en el código actual y los
|
||
del seed, **detenete y reportá** antes de aplicar (Patrón C.8). Aplica el aprendizaje
|
||
de la Etapa 2E: los códigos y nombres son del seed, no de archivos secundarios.
|
||
|
||
### 4.2 Localizar dónde se renderizan los encabezados de sección
|
||
`grep -rE "Prevalencia|Datos Generales|Intensidad y rol|Impacto económico|Tiempo y descanso|Impacto en el trabajo|Conciencia organizacional|Para cerrar"` en `components/` y `app/(survey)/` (o equivalente).
|
||
|
||
Encontrar el componente que renderiza el header de cada sección. Probablemente es uno
|
||
solo que recibe el nombre de sección como prop o lo deriva del seed.
|
||
|
||
### 4.3 Modificar el header de sección
|
||
Aplicar el formato **"Sección {N} · {Título}"** una sola vez en el componente, leyendo
|
||
el número desde una propiedad del seed o pasándolo como prop. Mantener el estilo
|
||
visual actual (color teal, tamaño, peso) — solo se agrega el prefijo "Sección {N} · ".
|
||
|
||
### 4.4 Modificar el componente de pregunta
|
||
Localizar el componente que renderiza el texto de cada pregunta. Agregar el tag con el
|
||
código de la pregunta antes del texto, según las especificaciones de la sección 3.2.
|
||
|
||
El código de cada pregunta ya está en la base de datos (`questions.code`) y debería
|
||
estar disponible en el objeto que recibe el componente. Si no está, propagarlo en una
|
||
prop (no agregarle un fetch).
|
||
|
||
### 4.5 Eliminar disclaimers por sección
|
||
Eliminar el bloque ámbar con "Esta sección contiene preguntas sensibles...". Buscar
|
||
todas las instancias:
|
||
```bash
|
||
grep -rn "preguntas sensibles\|Responder es completamente voluntario\|Responder es voluntario" \
|
||
components/ app/(survey)/ 2>/dev/null
|
||
```
|
||
Eliminar tanto el JSX como, si existe, el dato del seed/constante que las alimenta. Si
|
||
el disclaimer está condicionado por `is_sensitive=true` o similar, eliminar también esa
|
||
lógica de renderizado.
|
||
|
||
### 4.6 Backlog
|
||
Agregar el ítem BACKLOG-XXX descrito en la sección 3.5 a `BACKLOG.md` (crear el archivo
|
||
si no existe). Numerar según el siguiente correlativo disponible.
|
||
|
||
---
|
||
|
||
## 5. Entregables (DoD)
|
||
|
||
- [ ] Verificación C.8 ejecutada — nombres de secciones match SEED_SPEC.md.
|
||
- [ ] Los 8 encabezados de sección muestran el prefijo "Sección {N} · ".
|
||
- [ ] Cada pregunta muestra su código (1.1, A5, 6.2, etc.) antes del texto.
|
||
- [ ] `grep -rE "preguntas sensibles|Responder es .*voluntario"` retorna vacío.
|
||
- [ ] `consent-screen.tsx` (o equivalente) sin cambios — confirmar con `git diff`.
|
||
- [ ] BACKLOG.md actualizado con el ítem del consentimiento editable.
|
||
- [ ] Build sin errores (`next build`).
|
||
- [ ] `git diff --name-only HEAD` solo en componentes del formulario y BACKLOG.md.
|
||
- [ ] Captura del formulario en sección 1 mostrando: encabezado con "Sección 1 · ", al
|
||
menos 2 preguntas con sus códigos visibles, y SIN disclaimer ámbar.
|
||
|
||
## 6. Qué reportar
|
||
```
|
||
Verificado:
|
||
- Verificación C.8 (nombres de secciones vs SEED_SPEC.md): match
|
||
- Archivos modificados en diff: [lista]
|
||
- Headers de sección con "Sección {N} · ": confirmado
|
||
- Códigos de pregunta visibles: [ejemplo de 2-3]
|
||
- grep de disclaimers: vacío
|
||
- consent-screen.tsx intacto: confirmado
|
||
- BACKLOG.md actualizado: ítem [número]
|
||
- Build exitoso
|
||
|
||
Asumido:
|
||
- [si hay decisión cosmética sobre el estilo del tag de código]
|
||
|
||
Decisiones proactivas (Nivel 2):
|
||
- [si las hubo]
|
||
|
||
Conflictos de scope (Patrón C.8):
|
||
- [si los hubo, listarlos AQUÍ y detener]
|
||
```
|
||
|
||
## 7. Qué NO hacer
|
||
- ❌ No tocar `consent-screen.tsx` ni el componente de consentimiento de ninguna forma.
|
||
- ❌ No modificar el seed, las preguntas, ni `SEED_SPEC.md`.
|
||
- ❌ No tocar las RPCs ni la migración del dashboard.
|
||
- ❌ No cambiar la lógica condicional de los bloques (1.1→1.2-1.5, etc.).
|
||
- ❌ No renumerar preguntas — los códigos quedan tal cual están en el seed.
|
||
- ❌ No agregar dependencias npm.
|
||
- ❌ No resolver ítems de TECH_DEBT.md ni del BACKLOG salvo el ítem nuevo de esta etapa. |