Calidad, observabilidad y reglas
Cómo se valida y opera el backend
La robustez del sistema depende tanto del diseño como de la forma en que se prueba, se monitorea y se gobierna técnicamente.
Estrategia de testing
- Unit: RBAC, pricing, descuentos y validación de comandos.
- Integration: PostgreSQL real para triggers, FKs compuestas, ledgers y recálculos.
- E2E backend: flujos completos sin frontend.
- Concurrency: sesiones, pagos duplicados, edición de órdenes y carreras de stock.
Escenarios mínimos obligatorios
- login -> open session -> create order -> pay -> close
- order -> inventory consumption
- PO -> receipt -> inventory entry
- receipt -> AP document -> AP payment -> apply
- duplicate sync command -> dedupe
Observabilidad
- Logs estructurados con request id y tenant id.
- Métricas de latencia, throughput y errores.
- Métricas de outbox pendiente.
- Métricas de dedupe y replay.
- Healthchecks de API, DB y worker.
Validaciones operativas que deben probarse
- Apertura única de sesión por terminal.
- Dedupe de pagos y comandos sincronizados.
- Stock no negativo bajo concurrencia.
- Recepción consistente con PO y proveedor.
- Aplicación AP dentro de saldo y monto disponible.
Reglas de licencias
| Permitidas | Bloqueadas |
|---|---|
| MIT, BSD-2, BSD-3, Apache-2.0, ISC, Zlib, Python-2.0, Unlicense | GPL, AGPL, LGPL, MPL, EPL, CDDL, SSPL, Commons Clause, BSL y licencias ambiguas |
Definition of done del backend v1
- Auth + RBAC completos.
- Configuración del negocio completa.
- Sesiones POS operativas.
- Órdenes con modifiers y descuentos.
- Pagos y reversas correctos.
- Inventario y costo consistentes.
- Compras y CxP integradas.
- AP con
open_amountconsistente. - Replay idempotente validado.
- Observabilidad y logs básicos operativos.