Retrospectiva + Auditoría de Producto — Soterex
Fecha: 2026-07-29 · Rol: Product Owner · Estado: Para revisión de Carlos
1. Retrospectiva — qué hicimos hasta ahora
Línea de tiempo
| Hito | Fecha | Resultado |
|---|---|---|
| Definición funcional MVP1 + ADRs (Vue 3/Vite, Laravel 13/PHP 8.5, Aurora PG) | jul 2026 | Stack cerrado, sin re-discusiones posteriores ✅ |
| Mejoras UX pre-staging (Auditoría a Operación, motivo de cancelación, comisión oculta al counter con enforcement backend, sección Documentación) | 2026-07-25 | Validadas con screenshots Playwright ✅ |
| Consenso infra/DevOps (dockerignore, tags, alarmas, WAF, migraciones en pipeline, escaneo secretos) | 2026-07-25 | Documentado en doc/architecture/infra-consensus.md, 2 riesgos aceptados explícitos ✅ |
Staging live https://soterex.stag.cislatam.net | 2026-07-25/26 | Deploy de cero, con 8+ problemas reales resueltos y documentados como lecciones ✅ |
| Diseño pantalla "Pago" Backoffice (4 iteraciones: brutalist → terminal → light + sidebar → tokens reales) | 2026-07-28 | backoffice-home-final.html aprobado ✅ |
| Presentación MVP1 al negocio (Mariano, Magaly, Teresa, Alessandro) | 2026-07-28 | Luz verde de Soterex, contrato en camino, informe PDF + mail distribuidos ✅ |
| Plan v2 (E1–E7) con 18 decisiones de Caja cerradas | 2026-07-28 | En ejecución en Claude Code ✅ |
Qué funcionó bien (mantener)
- Diseño primero, código después: las 4 iteraciones del mockup HTML costaron horas; iterar eso en Vue hubiera costado días. Repetir para Caja y wizard.
- Decisiones numeradas como "ley": las 18 decisiones citables evitaron ambigüedad en Claude Code.
- Enforcement backend, no solo UI (comisión oculta): el patrón correcto quedó instalado como principio.
- Lecciones de infra documentadas en el momento (ASCII en SGs, Aurora 16.13, OIDC por ID, config:cache en entrypoint): cero re-tropiezos.
- Deliverables de negocio con el formato de la casa (membrete, tablas): la presentación salió sin fricción.
Qué casi nos descarrila (corregir)
- Dos fuentes de verdad divergentes. El plan v2 se cerró con lo definido en este chat, pero la reunión de presentación del mismo día generó compromisos que nunca entraron al plan (detalle en §3). Claude Code está ejecutando un plan incompleto respecto a lo prometido al negocio.
- Terminología: HIPOS/EPOS apareció dos veces (plan y PDF). Ya corregido, pero indica que hace falta un glosario canónico en el repo.
- Dependencias externas sin dueño en el plan: el plan v2 no rastrea lo que CIS-EC y Soterex deben entregar (tabla de comisiones, especificación de caja de Operaciones, credenciales de API, doc formal de las 4 APIs). Si eso no llega, E4/E5 se construyen sobre supuestos.
2. Auditoría de producto — alineación Plan v2 ↔ Compromisos de la reunión 28/07
Alcance de esta auditoría: se hace desde documentación, informes y decisiones (este entorno no tiene el repo). La verificación código-contra-decisiones se ejecuta con el "paquete de auditoría" de §5 en Claude Code.
🔴 Brechas críticas — comprometido al negocio, ausente del plan v2
| # | Compromiso (informe 28/07) | Estado en plan v2 | Riesgo |
|---|---|---|---|
| G1 | Bloque de datos de cumplimiento/regulador: bloque editable de "datos propios" en la ficha de la transacción que Operaciones completa al pagar (teléfono, dirección, correo, parroquia, provincia, etc.) | No existe | Prioridad Alta comprometida a CIS-EC; el regulador es stakeholder duro |
| G2 | Motor de comisiones por tramo de monto (CIS calcula e informa monto + fee; tabla de tramos la provee CIS-EC) | Posible contradicción: la decisión 10 del plan dice "valor fijo por unidad, editable por país". La reunión habla de tabla por tramos de monto | Si E4 implementa comisión plana y el negocio espera tramos, hay retrabajo en el corazón del módulo de dinero |
| G3 | Estado "incompleta" de la transacción cuando el checklist documental no está completo | E5 tiene los steps pero no el estado ni el checklist visible | Cambia el modelo de estados de la transacción — mejor ahora que después |
| G4 | Pestaña/indicador de última actualización de la ingesta | No existe (prioridad Media) | Chico, pero comprometido |
| G5 | Comportamiento ante modificaciones de Soterex + bloqueo de cambios sobre transacciones pagadas | No existe — depende de definición de Soterex, pero el bloqueo del lado nuestro es implementable ya | Integridad de datos pagados; también es hallazgo de seguridad |
🟡 Dependencias externas sin tracking en el plan
- CIS-EC: columnas del reporte regulador (bloquea G1), tabla de comisiones (bloquea G2/E4), especificación escrita del módulo de caja, formato de ejemplo de papeleta (bloquea E5.3 fino), flujo de documentos (bloquea E5.1 fino).
- Soterex: URL/credenciales API prueba y producción, documentación formal de las 4 APIs, esquema de comisiones confirmado, comportamiento ante modificaciones.
- Riesgo de proceso: E4/E5 pueden arrancar con las 18 decisiones, pero los detalles finos (tramos, papeleta, flujo documental) tienen dueño externo. Sin gate explícito, Claude Code va a "rellenar con supuestos razonables" — exactamente el descarrilamiento a evitar.
🟢 Verificado consistente
- Las 18 decisiones de Caja del plan v2 coinciden con lo hablado en la reunión de avances (doble saldo, comisión solo del prefondeo, doble usuario en apertura, cierre a cero, TC con historial, 58 mm, membrete CIS, foto opcional, sin aprobación de supervisor).
- Scoping del Backoffice (E2) coincide con la "vista restringida del operador" comprometida.
- Riesgos aceptados de infra siguen vigentes y documentados.
3. Re-análisis del plan — propuesta de ajustes (v3)
El esqueleto E1–E7 sigue siendo correcto. No hay que tirar nada; hay que agregar y condicionar:
- Nueva entrega E2.5 — Compromisos de la presentación (paralela, sin dependencias de Caja):
- G1 Bloque de datos de cumplimiento en la ficha (editable por Operaciones al pagar; campos configurables por país si el reporte del regulador difiere).
- G4 Indicador de última ejecución/resultado de la ingesta.
- G5 Bloqueo de modificaciones entrantes sobre transacciones en estado PAID (rechazo + evento de auditoría), con el comportamiento fino a revisar cuando Soterex defina el suyo.
- Modificar E4 (comisiones): cambiar decisión 10 a "motor de comisiones: tabla por tramos de monto con valor fijo por tramo, editable por país" ⚠️ pendiente de confirmación de Carlos + tabla real de CIS-EC. Diseñar la tabla
commission_tiersdesde el día uno aunque arranque con un solo tramo (equivale al valor único actual y no rompe nada). - Modificar E5: agregar el checklist documental visible + estado "incompleta" de la transacción hasta completar los pasos obligatorios.
- Agregar tabla de dependencias externas al plan con dueño, fecha y qué entrega bloquea. Regla para Claude Code: si una tarea depende de un insumo externo no recibido, se implementa detrás de una interfaz/config y se marca el supuesto en el PR — nunca se inventa el detalle de negocio.
- Gate de alineación por entrega: antes de mergear cada PR, checklist "¿contradice alguna de las decisiones numeradas o compromisos del informe 28/07?" (lo corre
code-reviewercon ambos documentos como contexto). - Glosario canónico en
doc/glosario.md(EPOS, MTCN, PDV/estación, prefondeo, papeleta, tramo) — 15 minutos que evitan otro HIPOS.
4. Manejo de usuarios (E3)
Confirmado como bien encaminado según lo reportado ("está hermosa"). Ajuste solicitado por Carlos pendiente de especificación — no se toca nada de E3 hasta definirlo. Candidatos típicos a revisar cuando lo defina: permisos de los módulos nuevos de Caja en la matriz, asignación de estaciones/PDV al usuario, restricciones de quién crea/edita usuarios, o comportamiento de los overrides.
5. Paquete de auditoría para Claude Code (verificación código-contra-decisiones)
Correr en el repo, en una sesión limpia, este prompt:
Actuá como auditor con los skills code-reviewer y security. Leé:
- doc/plans/2026-07-28-cierre-mvp1-y-caja.md (las 18 decisiones + entregas)
- doc/architecture/infra-consensus.md
- El informe de la reunión del 28/07 si está en doc/
Auditá el estado actual del código contra esos documentos y generá
doc/audits/2026-07-29-auditoria-alineacion.md con:
1. Por cada entrega E1–E5: qué está implementado, qué a medias, qué no.
2. Por cada una de las 18 decisiones: cumplida / parcial / violada / no aplica aún,
con archivo y línea de evidencia.
3. Verificaciones específicas: (a) el scoping del Backoffice es backend-enforced,
con test de IDOR; (b) la comisión NUNCA descuenta de la caja (si Caja ya arrancó);
(c) permisos: imposible auto-escalación; (d) el rol Backoffice no accede al
endpoint de dashboard; (e) transacciones PAID no son modificables por la ingesta.
4. Deuda técnica y desvíos del plan detectados, con severidad.
No corrijas nada en esta sesión: solo informe.Con ese informe en mano, cerramos la v3 del plan con datos reales del código y no solo documentación.
6. Acciones inmediatas propuestas (en orden)
- Carlos confirma o corrige el modelo de comisiones (tramos vs valor único) — bloquea E4.
- Carlos especifica el ajuste de manejo de usuarios — bloquea el cierre de E3.
- Correr el paquete de auditoría en Claude Code (§5).
- Actualizar el plan a v3 con E2.5, cambios de E4/E5, tabla de dependencias y gate de alineación.
- Reclamar a CIS-EC/Soterex los insumos de la tabla de dependencias (ya están pedidos en el mail del 28/07 — hacer seguimiento).