PDF-003F Blocker Staging Target Operational Handoff¶

Fecha local: 2026-06-19

Estado: HANDOFF / NO RUNTIME CHANGE / PDF-003F SIGUE BLOCKED / PDF-004 SIGUE NO-GO

portal_visible = yes

Scope: tenant

tenant_id: alpuntodeventa

Owner: Gabi / Carlos Canu

Fuente de verdad: docs/tenants/alpuntodeventa/business-observer/production/PDF-003F-BLOCKER-STAGING-TARGET-OPERATIONAL-HANDOFF.md

1. Objetivo¶

Dejar un handoff operativo y un checklist seguro para completar fuera de Git la definicion real del target staging-vps de Business Observer.

Este documento no toca VPS, no toca PostgreSQL, no ejecuta SQL, no usa secretos y no habilita runtime.

2. Safe point¶

Control	Valor
workspace	`C:\APV\openclawai`
rama esperada	`main`
`HEAD/origin` declarado al iniciar	`fdae53fcd446cb7ce33ae918aa8d8f213ee680ea`
ultimo commit declarado al iniciar	`docs: prepare business observer staging backup restore runbook`
decision	`SAFE POINT PASS / HANDOFF ONLY`

3. Por que PDF-003F sigue bloqueado¶

PDF-003F sigue bloqueado porque todavia no existe una definicion operativa cerrada y no sensible del target real de staging-vps.

Faltantes vigentes:

target real elegido y distinguible del sandbox
fingerprint real publicable sin secretos
acceso seguro cerrado fuera de Git
baseline operativa minima de backup/restore
responsable operativo y ventana de cambio
monitoreo minimo para el target correcto

Regla vigente:

text openclaw-postgres-sandbox NO DEBE USARSE COMO STAGING REAL

4. Que debe definirse fuera de Git¶

Debe definirse fuera de Git, fuera de ChatGPT y fuera de cualquier diff trackeado:

target real elegido
host real o identidad real del servicio
puerto o metodo de acceso real cuando sea sensible
usuarios LOGIN reales si aplican
passwords
connection strings
tokens o secretos equivalentes
ubicacion operativa real de backups
evidencia operativa real de restore drill

En Git solo deben quedar nombres logicos, alias no sensibles, politicas, checklists y criterios GO/NO-GO.

5. Formulario seguro para completar fuera del repo¶

Completar fuera del repo, en vault, ticket privado o documento operativo controlado:

Campo	Completar fuera de Git
target elegido	`<staging-vps dedicado / servicio separado / otra opcion aprobada>`
host o service alias no sensible	`<alias publicable o etiqueta operativa no sensible>`
puerto o metodo de acceso publicable	`<5432 / tunel / socket / bastion / no publicable>`
DB name	`openclaw_business_observer_staging` o nombre aprobado
roles logicos	`owner/admin`, `writer`, `reader`, `reporting_ro`
responsable operativo	`<owner operativo del cambio>`
ventana de cambio	`<fecha y franja aprobada>`
ubicacion de backup	`<alias o referencia operativa sin ruta sensible>`
restore drill target	`<alias del destino de restore separado>`
monitoreo minimo	`<backup age, restore drill age, size, status, disponibilidad>`

6. Que NO debe pegarse en ChatGPT ni en Git¶

No pegar:

passwords
connection strings
tokens
usuarios LOGIN reales si son sensibles
IPs privadas si se consideran sensibles
hosts reales si son sensibles
rutas reales de backups si son sensibles
capturas o logs con secretos visibles

7. Checklist para volver con datos no sensibles¶

Volver solo con datos no sensibles y publicables:

nombre logico del target elegido
confirmacion explicita de que no es openclaw-postgres-sandbox
alias no sensible del host o servicio
nombre final de la DB
roles logicos aprobados
confirmacion de acceso seguro fuera de Git
responsable operativo definido
ventana de cambio definida
alias no sensible de backup location definido
alias del restore drill target definido
monitoreo minimo definido
confirmacion de que no se compartiran secretos en la siguiente tarea

8. Criterio para abrir PDF-003F¶

PDF-003F puede abrirse como preflight read-only real solo si:

el target real ya fue elegido fuera de Git
existe alias no sensible publicable del target
la DB target final esta confirmada
los roles logicos estan cerrados
existe responsable operativo
existe ventana de cambio
existe acceso seguro fuera de Git
existe baseline minima de backup/restore definida
existe monitoreo minimo definido
se confirma por escrito que el sandbox no se usara como staging real

9. Criterio para mantener NO-GO¶

Debe mantenerse NO-GO si ocurre cualquiera de estos puntos:

el target real sigue indefinido
solo existe referencia al sandbox
no hay alias publicable no sensible
no hay acceso seguro cerrado
no hay responsable operativo
no hay ventana de cambio
no hay baseline de backup/restore
no hay restore drill target definido
no hay monitoreo minimo
la siguiente tarea depende de secretos pegados en chat o Git

10. Relacion con PDF-002 a PDF-003E¶

Documento	Relacion con este handoff
`PDF-002`	deja preparado el `DDL` candidato, pero no puede avanzar sin target real
`PDF-003`	audito solo el sandbox visible y confirmo que no habia staging real
`PDF-003B`	definio que el sandbox no debe usarse como staging real
`PDF-003C`	fijo prerequisitos de acceso, backup, restore y observabilidad
`PDF-003D`	registro la decision documental de provisioning separado
`PDF-003E`	preparo el runbook candidato de backup/restore
`PDF-003F`	toma todo lo anterior y lo convierte en handoff operativo para completar fuera de Git

11. Proximos safe points¶

Safe points recomendados despues de este handoff:

PDF-003F-A: recepcion de datos no sensibles del target real
PDF-003F-B: publicacion del fingerprint no sensible del target real
PDF-003F-C: preflight read-only contra el target correcto
PDF-003G: evidencia de backup real solo con autorizacion separada
PDF-003H: evidencia de restore drill real solo con autorizacion separada
PDF-004: DDL execution solo despues de GO

12. Conclusion¶

text PDF-003F HANDOFF PREPARADO STATE = HANDOFF / NO RUNTIME CHANGE TARGET REAL = TODAVIA PENDIENTE DE DEFINICION FUERA DE GIT SECRETS = EXCLUIDOS SANDBOX = NOT ACCEPTED AS REAL STAGING NEXT ACTION = VOLVER SOLO CON DATOS NO SENSIBLES PDF-003F = STILL BLOCKED PDF-004 = STILL NO-GO