Pendientes y decisiones diferidas

Este es mi tablero de cosas por resolver más adelante. No todo lo que aparece en el camino se puede —o conviene— cerrar en el momento: hay decisiones que dependen de plata, de hardware que todavía no existe, o de una confirmación del cliente que aún no llegó. En vez de dejar eso suelto en la cabeza o enterrado en alguna entrada vieja de la bitácora, lo junto acá.

La idea es que sea una sola vista de "qué falta", viva, que voy tachando a medida que avanzo. Cada ítem trae tres cosas: qué es, por qué quedó para después y qué lo destraba —la condición concreta que tiene que cumplirse para poder agarrarlo—. Cuando algo se resuelve lo marco con [x] y le dejo la fecha; si deja de tener sentido, lo saco y lo cuento en la bitácora del día.

De dónde sale esto

Los pendientes no nacen acá: van apareciendo en el PRD (lo que quedó fuera de alcance), en el RFC (las limitaciones que asumí a conciencia), en el plan y, sobre todo, en la bitácora, donde los registro el día que surgen. Esta página solo los reúne para poder mirarlos de un saque.

Despliegue e infraestructura

• [ ] Aprobación manual antes de producción. Quiero que cada despliegue al servidor del cliente pase por un visto bueno mío, aunque el push a la rama principal lo dispare solo. Quedó diferido porque la regla de revisor requerido sobre entornos protegidos de GitHub pide un plan pago cuando el repositorio es privado, y hoy la cuenta es gratuita. Destraba: o contrato el plan, o resuelvo la pausa con un mecanismo equivalente (un disparo manual del flujo en lugar de automático). No urge: el despliegue está dormido de todos modos.
• [ ] Ejecutor on-premise dentro de la VPN de Zavidoro. El sistema corre en el servidor central del cliente, detrás de su VPN, así que el despliegue automático necesita un ejecutor instalado adentro de esa red. Diferido porque ese servidor todavía no está disponible para mí. Destraba: registrar el ejecutor (con sus etiquetas) y prender la bandera DEPLOY_ENABLED. Hasta entonces el paso de despliegue se saltea limpio.
• [ ] Pasos reales del despliegue. Hoy el trabajo de despliegue está escrito como un esqueleto; falta el Dockerfile de la aplicación, el archivo de orquestación de producción y el endpoint de salud. Diferido a propósito: corresponde a la Task 10 del Milestone 1. Destraba: llegar a esa tarea del plan.
• [ ] Entorno de pruebas (staging) separado. Por ahora trabajo con dos entornos: desarrollo en mi máquina y producción on-premise. Un tercero, intermedio, para probar contra algo parecido a producción sin tocar al cliente, me vendría bien. Diferido porque todavía no tengo dónde alojarlo. Destraba: conseguir un lugar donde montarlo.
• [ ] Protección de rama vs. el filtro de documentación. La rutina de integración ignora a propósito los cambios que tocan solo documentación, para no gastar corridas de más. Si más adelante activo protección de rama exigiendo que el chequeo de integración pase sí o sí antes de integrar, una propuesta de cambio solo-documentación no generaría ese chequeo y podría quedar trabada sin poder mergear. No aplica hoy: no hay protección de rama y soy la única que trabaja en el repositorio. Destraba: revisarlo el día que active esa protección.

Integración con QUICK POS

• [ ] Toda la integración REST con QUICK POS. El corazón funcional del sistema —consolidar ajustes de inventario y empujarlos a QUICK POS vía su API— es trabajo de una fase posterior. Diferido por la secuencia del proyecto: es el Milestone 4. Destraba: terminar los milestones previos (acceso/administración, captura de auditoría, conciliación).

Decisiones de negocio por confirmar

• [ ] Origen del remito de ingreso. Para los remitos de ingreso por ajuste voy a usar provisionalmente el valor "sin origen". Quedó pendiente porque depende de cómo esté configurado el QUICK POS de cada tienda, y eso lo define quien administra ese sistema del lado del cliente. Destraba: confirmarlo con esa persona antes de cerrar el milestone de integración.

Deuda técnica y escala

• [ ] Cache de sesión asume un solo backend. El cache que evita reconsultar la whitelist en cada request vive en memoria del proceso, por diseño: ni base de datos ni store externo. Es una limitación asumida a conciencia, válida mientras corra una sola instancia del backend —que es el escenario real on-premise. Destraba: si algún día se escala a varias instancias, mover ese cache a un store compartido. Hoy sería resolver un problema que no tengo.
• [ ] Lógica de despacho por temporada. El código de despacho de los remitos usa por ahora un valor por defecto fijo. Diferido porque una lógica más fina, que varíe según la temporada, es una mejora y no un requisito bloqueante. Destraba: que el negocio pida ese nivel de detalle.

Convención

Marco [x] y agrego la fecha cuando un pendiente queda resuelto, así la página también sirve de registro de qué se fue destrabando y cuándo. Lo que se resuelve del todo se cuenta además en la bitácora del día correspondiente.