83782ab6f8
11 RPCs de Mirada Empresa (E1-E10 + estrella Talento en riesgo) sobre instrumento v3, k≥5 en dos niveles, helper _dash_es_cuidador (criterio UNFPA). Fix de _dash_responses: A6/A7 → 2.5/2.7. Verificado contra 50 respuestas reales: métricas núcleo exactas, k-anonimato suprime segmentos n<5, umbral de la estrella parametrizable. Modalidad por JOIN (TECH-DEBT-010). Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
113 lines
5.2 KiB
Markdown
113 lines
5.2 KiB
Markdown
# TECH_DEBT.md — Deuda técnica registrada
|
|
|
|
> Ítems identificados durante el desarrollo. Cada ítem documenta qué falta, por qué
|
|
> no se hizo ahora, y qué trigger habilitaría su resolución.
|
|
|
|
---
|
|
|
|
## [TECH-DEBT-001] Ranking widget para 6.2
|
|
|
|
- **Estado:** 6.2 es actualmente `multiple_choice` max_select=3. El widget muestra
|
|
frecuencia simple (top 8).
|
|
- **Deuda:** cuando el tipo pase a `ranking` con JSONB `{rank1, rank2, rank3}`, el
|
|
widget debe reescribirse para mostrar ponderación por posición.
|
|
- **Trigger:** decisión del director sobre el tipo de 6.2 en próxima versión del
|
|
instrumento (anotada en SEED_SPEC.md § Decisiones pendientes).
|
|
|
|
---
|
|
|
|
## [TECH-DEBT-002] KPI NPS Cuidador
|
|
|
|
- **Estado:** el instrumento actual no tiene pregunta NPS. El KPI fue eliminado del
|
|
dashboard en Etapa 2E.
|
|
- **Para implementar:** agregar en próxima versión del instrumento:
|
|
"En una escala de 0 a 10, ¿qué tan probable es que recomiendes esta empresa a otra
|
|
persona cuidadora?"
|
|
- **Trigger:** decisión de incluir NPS en el instrumento v2.
|
|
|
|
---
|
|
|
|
## [TECH-DEBT-003] Brecha de políticas (oferta vs. demanda)
|
|
|
|
- **Estado:** el instrumento captura solo demanda (6.2 = apoyos que ayudarían).
|
|
No captura qué políticas la empresa ya ofrece. W6 muestra solo demanda.
|
|
- **Para implementar:** agregar en próxima versión del instrumento:
|
|
"¿Qué apoyos para el cuidado ofrece tu empresa hoy?" (multi-select con las mismas
|
|
opciones de 6.2 + "Ninguno" + "No lo sé").
|
|
- **Trigger:** decisión de agregar la pregunta de oferta al instrumento.
|
|
|
|
---
|
|
|
|
## [TECH-DEBT-004] Intención directa de salida laboral
|
|
|
|
- **Estado:** el instrumento no pregunta directamente por intención de dejar el
|
|
empleo. W8 usa indicador compuesto (4.3 + 5.1 + 5.2) renombrado a "Saturación".
|
|
- **Para implementar:** agregar en próxima versión:
|
|
"En los últimos 6 meses, ¿pensaste en dejar este empleo por razones relacionadas
|
|
al cuidado?" (Sí/Frecuentemente · Sí/A veces · No · Prefiero no decir).
|
|
- **Trigger:** validación metodológica de que el indicador compuesto no es suficiente
|
|
para medir intención de salida.
|
|
|
|
---
|
|
|
|
## [TECH-DEBT-005] qi_city / qi_country — migración pendiente
|
|
|
|
- **Estado:** A1 (Departamento) y A2 (Ciudad) se guardan en `answers`. Las columnas
|
|
`qi_city` y `qi_country` en `responses` son NULL. Sprint 3 las necesita para
|
|
segmentación avanzada.
|
|
- **Para implementar:** migration futura que agregue extracción de A1/A2 en el insert
|
|
y extienda la whitelist de `agg_segment`.
|
|
- **Trigger:** inicio de Sprint 3 (dashboard avanzado con filtros de ciudad).
|
|
|
|
---
|
|
|
|
## [TECH-DEBT-006] Ranking widget para 2.1
|
|
|
|
- **Estado:** Etapa 3I2 (Cambio 5) cambió 2.1 ("¿Quién es el/la responsable principal
|
|
del cuidado?") de `single_choice` a `multiple_choice`. Permite selección múltiple
|
|
pero sin orden de prioridad — pierde la noción de "responsable principal" cuando
|
|
el respondente marca más de una opción.
|
|
- **Deuda:** implementar widget de ranking para 2.1 con el orden:
|
|
Principal cuidador soy yo > secundario instituto > principal pagado > secundario
|
|
familiar (mismo patrón que TECH-DEBT-001 para 6.2).
|
|
- **Trigger:** decisión del director sobre el tipo de 2.1 en próxima versión del
|
|
instrumento.
|
|
|
|
---
|
|
|
|
## [TECH-DEBT-008] /admin/responses sin autenticación
|
|
|
|
- **Estado:** ABIERTO.
|
|
- **Descripción:** la vista de control `/admin/responses` no tiene auth. Por diseño
|
|
explícito, excluye preguntas `is_sensitive=true` (14 preguntas de salud/
|
|
discapacidad) y `text_long`. Para mostrar esas preguntas en la vista, primero
|
|
implementar un gate de autenticación para staff (Basic Auth con env var como
|
|
mínimo viable).
|
|
- **Impacto actual:** ninguno en producción — la URL no está publicada.
|
|
- **Bloqueante para:** ampliar visibilidad de datos en la vista de control.
|
|
|
|
---
|
|
|
|
## [TECH-DEBT-010] E9 lee modalidad por JOIN a `answers` en vez de `qi_modalidad`
|
|
|
|
- **Estado:** ABIERTO — decisión consciente, no un descuido.
|
|
- **Descripción:** `rpc_me_segmentacion` (E9, Mirada Empresa) segmenta por nivel
|
|
organizacional y por modalidad de trabajo. El nivel (`2.6`) sí se promovió a
|
|
`responses.qi_sector` en el submit (Etapa 4G) — E9 lee de ahí directo. La
|
|
modalidad (`2.7`) NO tiene una columna `qi_modalidad` equivalente — promoverla
|
|
hubiera significado reabrir `rpc_submit_response`, ya verificada contra
|
|
Postgres real en 4G. Para no reabrirla, E9 resuelve modalidad con un JOIN a
|
|
`answers`/`questions` por `code='2.7'` en tiempo de consulta.
|
|
- **Costo del JOIN vs. la columna:** una pasada extra por `answers`/`questions`
|
|
en cada llamada a E9 — aceptable para el volumen actual (decenas/cientos de
|
|
respuestas por encuesta), pero más lento que leer una columna denormalizada
|
|
si el dataset crece mucho o si la segmentación por modalidad se usa con
|
|
frecuencia en varios widgets.
|
|
- **Acción si se decide promover:** agregar `qi_modalidad text` a `responses`,
|
|
poblarla en `rpc_submit_response` (requiere re-verificar esa RPC contra
|
|
Postgres real, igual que se hizo en 4G), y migrar E9 a leerla directo —
|
|
mismo patrón que se usó para `qi_sector`.
|
|
- **Trigger:** evaluar si la Mirada País/Humana también necesitan segmentar por
|
|
modalidad con frecuencia — si varias RPCs repiten el mismo JOIN, conviene
|
|
promoverla de una vez en lugar de cada RPC reimplementando el JOIN.
|