Production Data Foundation Intake 001¶

Fecha local: 2026-06-19

Estado: FOUNDATION DESIGN ONLY / STAGING-VPS PLANIFICADO / SIN CAMBIOS RUNTIME

Scope: tenant

tenant_id: alpuntodeventa

1. Objetivo de la etapa¶

Abrir formalmente la etapa Business Observer Production Data Foundation para definir la futura base staging-vps del tenant alpuntodeventa, con el fin de preparar una publicacion controlada y reversible de fuentes SGC en un entorno no local antes de cualquier decision de prod-vps.

Esta etapa es solo documental y de diseno.

2. Safe point¶

Control	Valor
workspace	`C:\APV\openclawai`
rama esperada	`main`
`HEAD/origin` declarado al iniciar	`33d28a11b66ce071a2a60b3f7662e4a358ee29f4`
ultimo commit declarado al iniciar	`docs: close source 003 mart local dev`
estado heredado `SOURCE-003 local-dev`	`RAW=1886`, `CORE=1886`, `MART=1/25/173/180`
decision	`SAFE POINT PASS / FOUNDATION DESIGN ONLY`

3. Alcance de esta etapa¶

Incluye:

definir ambientes local-dev, staging-vps y prod-vps futuro
fijar criterios minimos para llamar produccion a una base
ordenar la promocion futura de SOURCE-001, SOURCE-002, SOURCE-003 y fuentes posteriores
documentar dependencias, gates, permisos, backups, restore, rollback, idempotencia y observabilidad
proponer fases y safe points siguientes

No incluye:

tocar VPS OpenClaw
tocar PostgreSQL del VPS
crear bases, roles, schemas o tablas
ejecutar SQL
usar secretos, credenciales o conexiones runtime
deploy, push, scheduler o sync diaria
tocar La Directa, Docker, NPM, Portainer, runtime O4 o SGC productivo

4. Ambientes propuestos¶

Ambiente	Proposito	Escritura permitida hoy	Estado actual
`local-dev`	diseno, pruebas controladas y evidencia inicial	`NO` dentro de esta tarea	`SOURCE-003` cerrado con evidencia completa
`staging-vps`	validar DDL, permisos, cargas y operacion segura en entorno no local	`NO` hasta cerrar fases previas y autorizacion separada	`NO CREADO / SOLO PLANIFICADO`
`prod-vps futuro`	servir datos gobernados para consumo controlado	`NO` hasta cerrar staging, restore y observabilidad	`NO INICIADO`

5. Regla para no llamar produccion a un entorno incompleto¶

Un entorno no debe llamarse produccion si falta cualquiera de estos puntos:

backups verificables
restore documentado y probado
observabilidad minima operativa
idempotencia validada por pipeline
rollback gobernado por batch o ventana
control de permisos y secreto fuera de Git
evidencia de monitoreo y de recuperacion

Si falta alguno, el nombre correcto sigue siendo staging, pilot o candidate, nunca prod.

6. Modelo esperado en VPS¶

La base futura del Business Observer en VPS debe conservar el modelo RAW -> CORE -> MART.

RAW¶

replica controlada y trazable de fuentes SGC
carga por batch con sync_batch_id
write path idempotente
sin consumo analitico directo como interfaz principal

CORE¶

datos normalizados y listos para consumo analitico base
una fila por entidad/grano oficial de cada fuente
trazabilidad hacia RAW
politicas de deduplicacion y promocion por batch

MART¶

agregados gobernados para lectura ejecutiva y operacional
rebuild por batch o ventana
sin reemplazar CORE como fuente de trazabilidad

7. Fuentes SGC a promover por fases¶

Fase de promocion	Fuente	Objetivo inicial
`F1`	`SOURCE-003 Ventas`	llevar a `staging-vps` la fuente mas madura del flujo `RAW/CORE/MART`
`F2`	`SOURCE-001 Clientes`	incorporar maestro comercial y ownership asignado
`F3`	`SOURCE-002 Productos`	incorporar maestro de producto, listas, proveedor y capa economica base
`F4`	`futuras`	stock, vendedores, precios/costos/proveedor, snapshots y marts ejecutivos

8. Dependencias por fuente¶

Fuente	Dependencias minimas antes de staging load	Dependencias adicionales antes de prod
`SOURCE-001 Clientes`	autoridad cerrada, mapping fisico, contrato `RAW/CORE`, DDL candidate, idempotencia, validacion de owner/grants	drift review, reconciliacion con ventas y monitoreo de freshness
`SOURCE-002 Productos`	autoridad cerrada, decisiones sobre listas `L1..L9`, proveedor/costos, contrato `RAW/CORE`, DDL candidate	estrategia de costo/precio historico, freshness y validacion de volumen
`SOURCE-003 Ventas`	evidencia `local-dev` cerrada, batch model, rollback candidate, DDL candidate `staging`, pipeline idempotente, gates de escritura	observabilidad de carga, restore drill y decision de sync controlada
`futuras`	autoridad documental, owner funcional, grain oficial, contrato de batch y calidad	validacion cruzada con fuentes ya promovidas y costo operativo aprobado

9. Matriz de fuentes¶

Fuente	Autoridad actual	Madurez local-dev	Primera promocion objetivo	Dependencia clave	Estado de staging
`SOURCE-001`	`CERRADA DOCUMENTALMENTE`	`SIN PIPELINE VPS`	`RAW -> CORE`	mapping fisico final y permisos	`PENDIENTE`
`SOURCE-002`	`CERRADA DOCUMENTALMENTE`	`SIN PIPELINE VPS`	`RAW -> CORE`	decisiones de listas/costos/proveedor	`PENDIENTE`
`SOURCE-003`	`CERRADA + EVIDENCIA LOCAL-DEV`	`RAW/CORE/MART COMPLETO EN LOCAL-DEV`	`RAW -> CORE -> MART`	staging DDL + idempotencia operativa	`PRIMER CANDIDATO`
`stock`	`FUTURA`	`NO INICIADA`	`RAW -> CORE`	definicion snapshot vs current	`NO INICIADA`
`vendedores`	`FUTURA`	`NO INICIADA`	`RAW -> CORE`	modelo assigned vs transactional	`NO INICIADA`
`precios/costos/proveedor`	`PARCIAL EN SOURCE-002`	`NO INICIADA COMO FUENTE PROPIA`	`CORE` especializado	historizacion y owner funcional	`NO INICIADA`
`snapshots`	`FUTURA`	`NO INICIADA`	`RAW/CURATED`	politica de retencion y rebuild	`NO INICIADA`
`marts ejecutivos`	`FUTURA`	`NO INICIADA`	`MART`	staging estable y observabilidad	`NO INICIADA`

10. Roles y permisos esperados¶

Sin crear nada todavia, el modelo esperado en staging-vps y prod-vps debe separar al menos:

owner/admin: ownership de objetos y cambios DDL controlados
writer-raw: insercion controlada en RAW, sin DELETE
writer-core: promocion RAW -> CORE, sin privilegios sobre MART fuera del flujo aprobado
writer-mart: rebuild controlado de marts, sin tocar RAW
reader-bi: lectura sobre CORE/MART segun contrato
readonly-audit: verificacion, conciliacion y post-checks

Reglas esperadas:

PUBLIC sin privilegios
principio de menor privilegio
sin credenciales compartidas entre ambientes
separacion entre credenciales de carga y de lectura

11. Politica de secretos¶

secretos y credenciales siempre fuera de Git
nunca embebidos en docs, scripts o mkdocs
un secreto por ambiente y por funcion
rotacion obligatoria si algun secreto se expone en evidencia o diff
toda documentacion debe referir politica y ubicacion logica, no contenido

12. Politica de backups y restore drill¶

Antes de cualquier escritura en staging-vps debe existir:

politica de backup previa a DDL y previa a cargas
evidencia de retencion minima definida
restore drill documentado sobre backup real o copia controlada
criterio PASS/FAIL de restore con tiempos objetivo

Antes de cualquier paso a prod-vps debe existir:

restore drill exitoso de staging-vps
runbook de backup/restore versionado
evidencia de que el restore conserva RAW, CORE, MART y permisos

13. Estrategia de rollback¶

rollback por fase y por batch
rollback de DDL separado del rollback de datos
rollback siempre documentado antes de la primera escritura de cada fuente
para MART, priorizar rebuild controlado por batch
para RAW/CORE, exigir abort si el rollback compromete batches no autorizados

14. Idempotencia obligatoria¶

Ninguna carga en staging-vps o prod-vps futuro debe habilitarse sin:

clave de batch o ventana claramente definida
precheck de filas ya existentes en destino
bloqueo antes de escribir ante colision no aprobada
post-check de rowcounts esperados
reintento controlado que termine PASS sin duplicar o BLOCKED sin escribir

15. Observabilidad minima requerida¶

Antes de cualquier escritura en staging-vps:

logs estructurados de pipeline
rowcounts RAW/CORE/MART
duracion de corrida
estado PASS/FAIL/BLOCKED
deteccion de drift basica

Antes de cualquier decision prod-vps:

alertas de falla de pipeline
alertas de freshness
alerta de restore no verificado
evidencia de monitoreo de backups

16. Gates antes de cualquier escritura¶

Todo futuro write path en staging-vps debe exigir:

safe point Git limpio y commit base declarado
alcance documentado del ambiente y DB objetivo
backup previo confirmado
restore plan asociado
fingerprint del entorno esperado
DDL candidate y rollback candidate publicados
idempotencia definida por fuente
observabilidad minima lista
autorizacion explicita en tarea separada

17. Estrategia para no habilitar sync diaria¶

La sync diaria debe seguir BLOCKED hasta que:

staging-vps exista y quede cerrada documentalmente
SOURCE-003 staging load y SOURCE-003 staging review/idempotency resulten PASS
SOURCE-001 y SOURCE-002 tengan al menos contrato y pipeline de staging definidos
backups, restore y observabilidad esten probados
exista decision formal Production decision gate

Hasta entonces, cualquier carga sigue siendo manual, puntual y con safe point separado.

18. Fases propuestas¶

Fase	Nombre	Resultado esperado
`1`	`Foundation design`	intake y criterios rectores aprobados
`2`	`Staging DB roles/schemas DDL candidate`	paquete DDL candidato sin ejecutar
`3`	`Staging DDL preflight`	verificacion read-only del entorno objetivo
`4`	`Staging DDL execution`	DDL ejecutado con post-checks y rollback candidate
`5`	`SOURCE-003 staging load`	primera carga controlada `RAW/CORE/MART` en staging
`6`	`SOURCE-003 staging review/idempotency`	review, retry controlado y rollback candidate actualizado
`7`	`SOURCE-001 Clientes staging pipeline`	pipeline inicial de clientes en staging
`8`	`SOURCE-002 Productos staging pipeline`	pipeline inicial de productos en staging
`9`	`Observability + backups + restore`	monitoreo, backup y restore drill cerrados
`10`	`Production decision gate`	dictamen `GO/NO-GO` para `prod-vps futuro`

19. Criterios de salida de staging¶

staging-vps solo puede considerarse cerrada cuando:

SOURCE-003 demuestre carga y retry seguro
al menos SOURCE-001 y SOURCE-002 tengan camino de staging definido
backups y restore drill resulten PASS
observabilidad y alertas minimas esten activas
no haya secretos en Git ni permisos abiertos

20. Riesgos principales¶

riesgo de llamar produccion a un entorno sin restore real
riesgo de promover SOURCE-003 sin observabilidad fuera de local-dev
riesgo de mezclar fuentes maduras y no maduras en la misma primera carga
riesgo de abrir sync diaria antes de cerrar idempotencia en staging
riesgo de permisos excesivos si no se separan writers y readers

21. Cross-project scope¶

docs/governance/CROSS-PROJECT-OPERATIONS.md aplica solo como regla de prevencion: esta etapa queda completamente dentro de C:\APV\openclawai y no habilita cambios en otro repo ni en otro VPS.

22. Proximos safe points recomendados¶

SAFE-POINT-PDF-002: staging DB roles/schemas DDL candidate
SAFE-POINT-PDF-003: staging DDL preflight
SAFE-POINT-PDF-004: staging DDL execution
SAFE-POINT-PDF-005: SOURCE-003 staging load
SAFE-POINT-PDF-006: SOURCE-003 staging review/idempotency
SAFE-POINT-PDF-007: SOURCE-001 Clientes staging pipeline
SAFE-POINT-PDF-008: SOURCE-002 Productos staging pipeline
SAFE-POINT-PDF-009: observability + backups + restore
SAFE-POINT-PDF-010: production decision gate

23. Conclusion¶

text PRODUCTION DATA FOUNDATION INTAKE PASS STAGE = FOUNDATION DESIGN ONLY NEXT NON-LOCAL TARGET = STAGING-VPS SOURCE-003 = FIRST PROMOTION CANDIDATE SOURCE-001 AND SOURCE-002 = REQUIRED BEFORE CONTROLLED PRODUCTION RAW/CORE/MART MODEL = REQUIRED IN VPS BACKUPS + RESTORE + OBSERVABILITY + IDEMPOTENCY = MANDATORY DAILY SYNC = BLOCKED UNTIL STAGING CLOSES PROD-VPS = FUTURE DECISION, NOT CURRENT STATUS