Saltar a contenido

PDF-003B Staging Target Definition

Fecha local: 2026-06-19

Estado: TARGET DEFINITION ONLY / PDF-004 SIGUE NO-GO / CERO CAMBIOS RUNTIME

portal_visible = yes

Scope: tenant

tenant_id: alpuntodeventa

Owner: Gabi / Carlos Canu

Fuente de verdad: docs/tenants/alpuntodeventa/business-observer/production/PDF-003B-STAGING-TARGET-DEFINITION.md

1. Problema detectado en PDF-003

PDF-003 confirmo que el unico PostgreSQL visible en el VPS fue:

text openclaw-postgres-sandbox

Hallazgos criticos:

  • openclaw_business_observer_staging = NO
  • openclaw_business_observer_prod = NO
  • roles staging esperados = NO
  • schema target business_observer en staging real = N/A
  • backup/restore especifico para la futura staging = AUSENTE / NO CERRADO

Conclusion:

  • hoy no existe un target real de staging-vps para Business Observer;
  • el entorno visible sigue siendo candidate-only / sandbox-visible;
  • por lo tanto PDF-004 no puede ejecutarse sobre el runtime observado.

2. Decision recomendada

Decision recomendada:

text NO USAR openclaw-postgres-sandbox COMO STAGING REAL

Definir una de estas dos salidas validas antes de cualquier DDL:

  1. crear un PostgreSQL dedicado para Business Observer staging; o
  2. gobernar explicitamente una instancia separada del sandbox como staging-vps real, con identidad, backups, restore, roles y acceso propios.

Recomendacion operativa:

  • opcion preferida: PostgreSQL dedicado para Business Observer staging;
  • opcion aceptable solo con gobierno explicito: reutilizar infraestructura existente pero nunca el sandbox tal como esta hoy;
  • PDF-004 sigue NO-GO hasta cerrar target real, backup, restore, roles, acceso y fingerprint.

3. Opciones evaluadas

Opcion Evaluacion Dictamen
1. PostgreSQL dedicado para Business Observer staging en VPS separa claramente sandbox vs staging, facilita backup/restore y reduce ambiguedad operacional RECOMENDADA
2. Usar PostgreSQL existente solo si deja de ser sandbox y queda gobernado como staging real viable solo si cambia formalmente su identidad, politica de acceso, backup/restore y ownership; hoy no cumple SOLO SI SE REFUNDA EXPLICITAMENTE
3. Mantener sandbox separado y crear staging real despues preserva el sandbox para pruebas aisladas y evita forzar una promocion prematura VALIDA Y PRUDENTE
4. Diferir staging hasta tener backup/restore/monitoring definidos documentalmente consistente y baja riesgo, pero retrasa PDF-004 VALIDA Y NECESARIA SI FALTA OPERACION MINIMA

4. Target staging recomendado

Target recomendado:

text staging-vps real separado del sandbox

Baseline recomendado:

  • ambiente: staging-vps
  • database target: openclaw_business_observer_staging
  • schema target: business_observer
  • roles target: openclaw_bo_staging_owner, openclaw_bo_staging_writer, openclaw_bo_staging_reader, openclaw_bo_staging_reporting_ro
  • PUBLIC: sin privilegios sobre DB y schema target
  • backup/restore: versionado y verificado para este target
  • acceso: principals separados de sandbox y de futuro prod

5. Prerequisitos antes de cualquier DDL

Antes de reintentar PDF-003 o abrir PDF-004 debe existir:

  1. target real de staging-vps definido por nombre y alcance;
  2. confirmacion de que el target no es openclaw-postgres-sandbox;
  3. naming final de DB y schema congelado;
  4. roles de grupo target congelados;
  5. politica de acceso y provision de secretos fuera de Git;
  6. backup previo obligatorio para el target real;
  7. runbook de restore versionado;
  8. observabilidad minima del target;
  9. fingerprint esperado exacto del target;
  10. nueva auditoria PDF-003 read-only contra el target real.

6. Fingerprint esperado a definir

El fingerprint futuro debe publicarse antes del nuevo PDF-003 e incluir como minimo:

text environment=<staging-vps> host=<hostname o alias aprobado> runtime_identity=<container/service/instance name> endpoint=<host:port o via interna aprobada> current_database=openclaw_business_observer_staging schema_target=business_observer server_version=<postgres version> roles_expected=openclaw_bo_staging_owner|writer|reader|reporting_ro public_privileges=none on target db/schema backup_policy_id=<runbook o referencia> restore_runbook_id=<runbook o referencia>

Regla:

  • mientras ese fingerprint no exista y no sea validable, PDF-003 no puede dar GO para PDF-004.

7. Politica de acceso y secretos

  • ningun secreto o password en Git;
  • principals LOGIN separados por ambiente;
  • staging y prod no comparten credenciales;
  • el owner no se usa como cuenta rutinaria de carga o lectura;
  • provision de credenciales solo fuera de repo y fuera de docs publicas;
  • toda evidencia documental refiere ubicacion logica y politica, nunca el valor del secreto;
  • si el target nace nuevo, la provison de acceso debe cerrarse antes de cualquier DDL.

8. Politica backup/restore minima

Minimo obligatorio para llamar staging al target:

  • backup previo a cualquier DDL;
  • backup previo a cualquier carga;
  • retencion minima definida;
  • runbook de restore versionado;
  • restore drill documentado sobre copia controlada o backup real;
  • criterio PASS/FAIL del restore con tiempos objetivo;
  • evidencia de que el restore preserva DB, schema, permisos y objetos del tenant.

9. Observabilidad minima

Minimo obligatorio para el target real:

  • identificacion clara del target en logs;
  • logs estructurados de preflight y de futuras cargas;
  • rowcounts por capa RAW/CORE/MART;
  • duracion de corrida;
  • estado PASS/FAIL/BLOCKED;
  • evidencia de backup previo;
  • evidencia de restore runbook disponible;
  • deteccion basica de drift de grants, DB o schema target.

10. Rollback/restore esperado

Antes de cualquier PDF-004 debe quedar definido:

  • rollback de DDL a nivel conceptual y operativo;
  • criterio de aborto si el target ya contiene objetos no contemplados;
  • restore desde backup previo si el rollback no es suficiente;
  • separacion entre rollback de objetos y restauracion de datos;
  • ventana o procedimiento para volver al estado previo sin tocar sandbox ni prod.

11. Checklist GO para volver a intentar PDF-003

El nuevo PDF-003 solo puede abrirse con GO si todo esto esta PASS:

  1. target real documentado;
  2. target distinto de openclaw-postgres-sandbox;
  3. DB target creada o provisionada fuera de esta tarea;
  4. fingerprint esperado publicado;
  5. backup policy minima cerrada;
  6. restore runbook versionado;
  7. observabilidad minima definida;
  8. roles target definidos;
  9. politica PUBLIC = none on target db/schema definida;
  10. politica de secretos y acceso definida;
  11. nueva auditoria read-only ejecutable contra ese target.

12. Por que PDF-004 sigue NO-GO

PDF-004 sigue NO-GO porque hoy faltan simultaneamente:

  • target real de staging-vps;
  • DB target openclaw_business_observer_staging;
  • roles staging reales;
  • fingerprint final validable;
  • backup previo especifico;
  • restore runbook/versionado;
  • observabilidad minima del target;
  • garantia de no estar ejecutando sobre sandbox.

Mientras uno solo de esos puntos siga abierto, PDF-004 debe permanecer bloqueado.

13. Proximos safe points

Safe points recomendados desde este documento:

  • SAFE-POINT-PDF-003B: definicion documental del target real staging
  • SAFE-POINT-PDF-003C: backup/restore/observability baseline del target
  • SAFE-POINT-PDF-003D: nuevo preflight read-only contra target real
  • SAFE-POINT-PDF-004: DDL execution solo si PDF-003D = GO

14. Conclusion

text PDF-003B PASS AS DOCUMENTAL TARGET DEFINITION RECOMMENDED TARGET = REAL STAGING SEPARATE FROM SANDBOX openclaw-postgres-sandbox = NOT ACCEPTED AS REAL STAGING PDF-004 = STILL NO-GO REQUIRED NEXT GATES = TARGET + BACKUP + RESTORE + ROLES + ACCESS + FINGERPRINT ZERO RUNTIME CHANGES CONFIRMED