motor-de-encuestas/OBSERVATIONS.md

OBSERVATIONS.md — Observaciones y breaking changes

Registro de cambios al instrumento que rompen compatibilidad con datos existentes o que requieren atención del director antes/después de re-seedear. No bloquean el trabajo del agente — se documentan para que el director decida qué hacer con los datos ya capturados.

---

Etapa 3I2 — Revisión del instrumento v2.1 (feedback equipo médico)

1. Eliminación de "Prefiero no decir" (Cambio 1)

Afecta: A5, A6, 1.1, 1.5, 1.6, 1.13, 2.5, 3.1, 3.4.

Si existen respuestas guardadas con el valor "Prefiero no decir" en alguna de estas preguntas, esos valores quedan huérfanos: ya no aparecen como opción en el formulario ni en seed.sql, pero permanecen en responses.answers tal cual fueron guardados. No se borran ni se migran automáticamente.

Impacto en triggers (1.1, 1.6, 1.13): estas preguntas ahora tienen solo 2 opciones (Sí/No). La lógica condicional (incluyendo el nuevo salto-triple, Cambio 4a) solo reacciona a "Sí". Una respuesta histórica "Prefiero no decir" en un trigger se trataría como "no Sí" a efectos de la lógica condicional si se re-evaluara, pero no hay re-evaluación retroactiva de respuestas ya enviadas.

2. 2.1 cambia de single_choice a multiple_choice (Cambio 5)

Respuestas existentes para 2.1 están guardadas como un string único ("Yo soy el/la principal", etc.). El formulario nuevo espera un array de strings para preguntas multiple_choice. Las respuestas históricas de 2.1 quedan en formato de string, inconsistente con el nuevo esquema esperado para esa pregunta.

Ver TECH_DEBT.md → TECH-DEBT-006 (deuda de ranking pendiente sobre esta misma pregunta).

3. Eliminación de la pregunta 2.4 (Cambio 6)

"¿Contás con apoyo de otras personas para el cuidado?" se elimina del seed por ser similar/redundante con 2.1 (feedback del equipo médico).

El DELETE FROM public.questions WHERE survey_id = ... al inicio de seed.sql borra la fila de la pregunta 2.4 (id 40000000-0000-0000-0000-000000000027). Si existen filas en responses cuyo answers referencian question_id = 2.4 (por question_id, no por código embebido en JSON — depende del esquema de responses), esas referencias quedan apuntando a un question_id que ya no existe en questions tras el re-seed.

No re-seedear la base de producción sin que el director confirme que no hay respuestas reales que dependan de 2.4, o decidir conservar la fila de 2.4 marcada como archived/inactiva en lugar de borrarla (cambio de diseño — Nivel 3, no ejecutado en esta etapa).

4. Cambio de texto en opción de 3.3 (Cambio 8)

"Es difícil sostenerlo con mis ingresos" → "No puedo sostenerlo con mis ingresos".

Respuestas existentes que eligieron la opción anterior quedan guardadas con el texto literal "Es difícil sostenerlo con mis ingresos", que ya no coincide con ninguna opción del seed actual. Cualquier agregación por valor exacto de opción debe contemplar ambos strings como equivalentes para no perder esos datos en reportes.

5. División de la primera franja salarial en 3.4 (Cambio 9)

"Sueldo mínimo – Gs. 5.000.000" se reemplaza por dos opciones nuevas: "Sueldo mínimo" y "Gs. 3.000.000 a 5.000.000".

Respuestas existentes con el valor "Sueldo mínimo – Gs. 5.000.000" quedan con ese valor, que ya no existe como opción. No hay forma automática de reasignar esas respuestas a una de las dos franjas nuevas (la franja exacta del respondente no se puede inferir del valor agregado anterior).

6. Cambio de texto en última opción de 6.1 (Cambio 10)

"No, nunca se ha hablado del tema" → "No, no se puede hablar del tema".

Respuestas existentes con el valor anterior quedan con ese texto literal, que ya no coincide con ninguna opción del seed actual.

---

Resumen para el director

• Ningún cambio de esta etapa borra datos directamente, salvo el DELETE estándar de questions por survey_id (mecanismo de idempotencia ya existente en seed.sql, no nuevo de esta etapa) — pero ese DELETE ahora también elimina la fila de 2.4.
• Los cambios 1, 8, 9 y 10 dejan valores de texto huérfanos en respuestas históricas (ya no matchean ninguna opción vigente). No afecta el funcionamiento del formulario hacia adelante, pero sí cualquier reporte/agregación que dependa de matchear el string exacto de la opción.
• El cambio 5 (2.1) deja respuestas históricas en un formato (string) distinto al que el formulario nuevo produce (array). Si se construye un reporte sobre 2.1, debe manejar ambos formatos o normalizarse en una migración de datos aparte.
• No se ejecutó ningún re-seed sobre la base real — esto aplica solo cuando el director apruebe re-seedear con seed.sql v2.1.