Rebanadas que funcionan de punta a punta.

#Rebanadas, no capas

No se construye primero toda la base de datos, después toda la API y al final las pantallas. Se construye la primera rebanada del mapa de historias completa: pantalla, API, reglas, datos e integración mínima. Así hay algo usable pronto y los problemas de integración aparecen al principio, no al final.

La primera rebanada de la aprobación de compras: crear solicitud, calcular ruta, aprobar en bandeja, emitir la orden en el ERP. Sin plantillas ni tableros. Es delgada, pero ya elimina FRIC_031 y FRIC_033.

#El ciclo

• Esfuerzo fijo, alcance variable. El apetito del diseño es el límite. Cuando algo resulta más difícil de lo previsto, se recorta alcance, no se estira el plazo en silencio.
• Recortar el alcance es parte del trabajo. Para cada elemento se pregunta si es indispensable para que la rebanada elimine la fricción. Lo que no, se anota para después.
• Cortacircuitos. Si el ciclo termina sin terminar la rebanada, no se extiende automáticamente. Se regresa a la compuerta: ¿el problema era otro? ¿el diseño no funcionaba?
• Primero lo desconocido. Lo que puede salir mal (la integración, un dato dudoso) se ataca al principio del ciclo, no al final.
• Demo al cerrar cada rebanada con el dueño del proceso, con datos reales. Es la mejor forma de evitar sorpresas en la entrega.

#Criterios de aceptación

Cada historia se cierra con ejemplos concretos en formato Dado / Cuando / Entonces. Salen de las tablas de decisión y de los casos reales del prototipo, y se vuelven pruebas automáticas.

Escenario: compra sobre el umbral pasa por Finanzas
  Dado    una solicitud de compra del área Operaciones por $25,000
  Cuando  se envía
  Entonces la ruta es: Jefe de área → Finanzas
  Y       la regla R5 aparece como motivo ("$25,000 vs $20,000")

Escenario: compra justo en el umbral no pasa por Finanzas
  Dado    una solicitud de compra por $20,000
  Cuando  se envía
  Entonces la ruta es: Jefe de área

Los dos escenarios juntos documentan algo que suele quedar ambiguo: el umbral es “mayor que”, no “mayor o igual”.

#Decisiones de arquitectura

Cada decisión técnica importante se registra en un documento corto y numerado, guardado junto al código. Cuando alguien pregunte por qué, la respuesta ya está escrita.

# 0003 · La orden de compra se escribe en el ERP por API

Estado: aceptada

Contexto
El ERP permite crear órdenes por API (versión de pruebas verificada) o por
archivo de carga nocturna. Compras necesita la orden el mismo día.

Decisión
Escribir por API al aprobarse la solicitud, con reintentos. Si falla tres
veces, la solicitud queda en "Orden pendiente" y se avisa a Compras.

Consecuencias
Dependemos de la disponibilidad de la API del ERP. Se agrega conciliación
diaria entre solicitudes aprobadas y órdenes en el ERP.

Una decisión reemplazada no se borra: se marca como sustituida y se enlaza a la nueva.

#Calidad

• Pruebas por cada fila de las tablas de decisión: en el umbral, arriba y abajo.
• Los casos reales del prototipo corren como pruebas de regresión en cada cambio de reglas.
• Revisión de código por otra persona antes de integrar.
• Pruebas de volumen con el número de casos de un mes pico, no de un día tranquilo.
• Bitácora de cada cambio de estado: quién, cuándo, qué regla, por qué.

El detalle técnico (estructura del servicio, verificaciones automáticas, ambientes) está en Implementación.

#Migración de datos

1. Inventario: qué datos existen, dónde y con qué calidad. Ya se revisó en el diseño.
2. Limpieza con el dueño del dato: duplicados, formatos, registros huérfanos. La limpieza la decide el cliente, no la decidimos nosotros.
3. Carga de prueba en el ambiente de pruebas y revisión con quien conoce los datos.
4. Conciliación: conteos y totales iguales entre origen y destino.
5. Corte: fecha a partir de la cual lo nuevo entra solo por el sistema. Lo que estaba en curso se termina por el camino viejo o se migra, nunca las dos cosas.

#Corrida en paralelo

Antes de que el sistema decida, observa. Durante un periodo el proceso sigue como hoy y el sistema calcula en paralelo lo que habría decidido. Las diferencias se revisan cada día con el dueño del proceso. Cuando no quedan diferencias abiertas, el sistema pasa a decidir.

Con interruptores en el código, el cambio se hace por grupos: primero un área, después otra. Si algo sale mal, se apaga el interruptor y se regresa al proceso anterior sin desplegar de nuevo.

#Permisos y datos personales

• Cada rol ve y hace solo lo que le toca. Los permisos se prueban con usuarios de cada rol, no con la cuenta de administrador.
• Toda acción queda ligada a una persona. No hay cuentas compartidas.
• Si el sistema maneja datos personales (empleados, proveedores personas físicas), se revisa con el cliente qué exige la ley de protección de datos personales vigente: aviso de privacidad, finalidad, acceso y resguardo.
• Las credenciales de integraciones viven en la configuración del servidor, nunca en el código.

#Errores comunes

• Construir por capas y conectar todo al final.
• Dejar la integración para el final porque “es solo una API”.
• Estirar el plazo en silencio en lugar de recortar alcance.
• Probar con datos inventados y descubrir los reales en producción.
• Hacer el corte sin corrida en paralelo cuando las reglas deciden dinero.