@@ -1,24 +1,44 @@
 # Base de datos Pescamar
 
-PostgreSQL/Neon es la fuente única para operaciones reales. `001_core.sql` crea el núcleo de proveedores, recepciones, liquidaciones, anticipos, recuperaciones, aprobaciones y operadores.
+PostgreSQL/Neon es la fuente única para operaciones reales. Las migraciones versionadas bajo `db/migrations/` son la fuente canónica del esquema.
 
-## Migraciones
+## Migraciones canónicas
 
-Para una instalación administrada manualmente, ejecutar en orden:
+Ejecutar siempre en orden:
 
 ```bash
 psql "$DATABASE_URL" -f db/migrations/001_core.sql
 psql "$DATABASE_URL" -f db/migrations/002_settlement_workflow.sql
 psql "$DATABASE_URL" -f db/migrations/003_operator_auth.sql
 psql "$DATABASE_URL" -f db/migrations/004_reception_plant_evidence.sql
 psql "$DATABASE_URL" -f db/migrations/005_auth_abuse_audit.sql
+psql "$DATABASE_URL" -f db/migrations/006_historical_production.sql
+psql "$DATABASE_URL" -f db/migrations/007_live_lot_memory.sql
+psql "$DATABASE_URL" -f db/migrations/008_dispatches_sales.sql
+psql "$DATABASE_URL" -f db/migrations/009_sales_orders_inventory_daily_close.sql
+psql "$DATABASE_URL" -f db/migrations/010_transformation_costs.sql
+psql "$DATABASE_URL" -f db/migrations/011_reception_evidence_files.sql
 ```
 
-`002_settlement_workflow.sql` incorpora peso guía, cálculo de liquidaciones y recuperación auditable de anticipos. `003_operator_auth.sql` agrega credenciales individuales, alcance por planta y sesiones. `004_reception_plant_evidence.sql` vincula cada nueva recepción a una planta y agrega evidencia documental trazable. `005_auth_abuse_audit.sql` incorpora límites de intentos y una bitácora mínima de autenticación sin almacenar IP ni correo en texto claro.
+No deben agregarse migraciones en otra carpeta. Cualquier cambio de esquema nuevo continúa la secuencia en `db/migrations/`.
 
-La migración 004 es aditiva. Las recepciones históricas pueden conservar `plant_id` nulo hasta que exista evidencia suficiente para asignarlas sin inventar procedencia. Por seguridad, esas filas heredadas sólo son visibles para Administración mientras no tengan planta confirmada.
+### Alcance
 
-Las funciones operacionales ejecutan compatibilidad idempotente mínima para las estructuras aditivas de 004 y 005 si aún no existen. Las migraciones versionadas siguen siendo la fuente canónica y deben aplicarse explícitamente en una operación de mantenimiento para instalar todos los constraints e índices documentados.
+- `001_core.sql`: núcleo operacional de proveedores, recepciones, créditos, liquidaciones, aprobaciones e importación.
+- `002_settlement_workflow.sql`: peso guía, liquidaciones y recuperación auditable de anticipos.
+- `003_operator_auth.sql`: credenciales individuales, alcance por planta y sesiones.
+- `004_reception_plant_evidence.sql`: planta y evidencia documental para recepción.
+- `005_auth_abuse_audit.sql`: límites de intentos y auditoría de autenticación sin IP/correo en texto claro.
+- `006_historical_production.sql`: producción histórica canónica.
+- `007_live_lot_memory.sql`: memoria/eventos vivos del lote.
+- `008_dispatches_sales.sql`: despachos y ventas trazables por lote.
+- `009_sales_orders_inventory_daily_close.sql`: órdenes, inventario y cierre diario.
+- `010_transformation_costs.sql`: ledger de costos reales de transformación por lote.
+- `011_reception_evidence_files.sql`: almacenamiento interno de archivos de evidencia de recepción.
+
+La migración 004 es aditiva. Las recepciones históricas pueden conservar `plant_id` nulo hasta que exista evidencia suficiente para asignarlas sin inventar procedencia; esas filas heredadas permanecen restringidas a Administración mientras no tengan planta confirmada.
+
+Las funciones operacionales pueden ejecutar compatibilidad idempotente mínima para estructuras aditivas, pero eso no sustituye las migraciones versionadas. Producción debe mantenerse alineada con esta secuencia canónica.
 
 ## Seguridad de acceso
 
@@ -32,9 +52,9 @@ La interfaz de acceso incluye **Activación inicial** para crear el primer admin
 
 - sólo funciona mientras no exista un administrador activo con credenciales;
 - aplica de forma idempotente el esquema de autenticación;
-- si falta el esquema 002, sólo lo completa automáticamente cuando recepciones, liquidaciones, anticipos, movimientos y aprobaciones están vacíos;
-- si detecta datos operacionales, se detiene y exige aplicar `002_settlement_workflow.sql` manualmente antes de continuar.
+- sólo completa automáticamente compatibilidad aditiva segura;
+- se detiene si una actualización estructural requiere una migración canónica explícita.
 
 Después de crear el primer administrador, `ADMIN_SETUP_TOKEN` deja de servir para la administración cotidiana. Altas y cambios de operadores requieren una sesión individual con rol Administrador.
 
-No existe un *seed*: el sistema inicia vacío y sólo recibe datos respaldados por la operación real o por una importación auditada de la planilla canónica.
+No existe un seed productivo: el sistema sólo recibe datos respaldados por operación real o por una importación auditada de la fuente canónica.