PDF-002 Staging DB Roles Schemas DDL Candidate¶

Fecha local: 2026-06-19

Estado: CANDIDATE / NOT EXECUTED / STAGING-VPS ONLY

portal_visible = yes

Scope: tenant

tenant_id: alpuntodeventa

Owner: Gabi / Carlos Canu

Fuente de verdad: docs/tenants/alpuntodeventa/business-observer/production/PDF-002-STAGING-DB-ROLES-SCHEMAS-DDL-CANDIDATE.md

1. Objetivo¶

Disenar el DDL candidato para la futura base staging-vps del Business Observer, limitado a:

naming recomendado de DB;
roles esperados;
schema operativo esperado;
permisos minimos;
ownership y grants base;
prerequisitos para una futura ejecucion controlada.

Esta etapa es solo documental. No se ejecuto SQL, no se toco PostgreSQL, no se creo DB real, no se crearon roles reales, no se creo schema real y no se tocaron secretos ni runtime.

2. Safe point¶

Control	Valor
workspace	`C:\APV\openclawai`
rama esperada	`main`
`HEAD/origin` declarado al iniciar	`45aaa51a2ff85462a485b841863f0e28c2794dff`
ultimo commit declarado al iniciar	`docs: plan business observer production data foundation`
estado heredado `SOURCE-003 local-dev`	`RAW=1886`, `CORE=1886`, `MART=1/25/173/180`
decision	`SAFE POINT PASS / DDL CANDIDATE ONLY`

3. Naming recomendado¶

Database staging recomendada¶

text openclaw_business_observer_staging

Justificacion:

mantiene patron ya usado en local-dev;
hace explicito el ambiente;
evita mezclar staging-vps con prod-vps futuro;
deja espacio para politicas y backups independientes.

Database futura prod recomendada¶

text openclaw_business_observer_prod

Regla:

no reutilizar una misma DB para staging y prod;
no compartir ownership ni grants amplios entre ambos ambientes;
no llamar prod a staging por conveniencia.

4. Schema recomendado¶

Schema operativo recomendado:

text business_observer

Decision:

conservar el mismo schema funcional ya usado en local-dev;
mantener public como schema no operativo;
no mezclar objetos del tenant dentro de public.

5. Roles staging recomendados¶

Roles de grupo candidatos:

Rol	Tipo recomendado	Objetivo
`openclaw_bo_staging_owner`	`NOLOGIN`	ownership y DDL gobernado
`openclaw_bo_staging_writer`	`NOLOGIN`	futuras cargas controladas `RAW/CORE/MART`
`openclaw_bo_staging_reader`	`NOLOGIN`	lectura base de validacion y consumo acotado
`openclaw_bo_staging_reporting_ro`	`NOLOGIN`	lectura futura solo reporting si hiciera falta

Regla recomendada:

los roles anteriores deben ser roles de grupo NOLOGIN;
los usuarios LOGIN concretos, si algun dia se crean, deben provisionarse fuera de este SQL y fuera de Git;
cada ambiente debe tener principals distintos;
staging y prod no deben compartir principals LOGIN.

6. Politica de ownership¶

Ownership recomendado:

DB owner: openclaw_bo_staging_owner
schema owner: openclaw_bo_staging_owner
tablas futuras RAW/CORE/MART: openclaw_bo_staging_owner
secuencias futuras, si aparecen: openclaw_bo_staging_owner

Reglas:

writer, reader y reporting_ro no deben ser owners;
cambios DDL solo via owner o sesion administrativa autorizada;
el owner no debe ser usado como cuenta rutinaria de lectura o carga;
si en el futuro existe un login admin, debe ser miembro del role owner y no recibir privilegios mas amplios que los del role de grupo.

7. Permisos minimos recomendados¶

Database¶

Rol	Permisos minimos
`openclaw_bo_staging_owner`	ownership
`openclaw_bo_staging_writer`	`CONNECT`
`openclaw_bo_staging_reader`	`CONNECT`
`openclaw_bo_staging_reporting_ro`	`CONNECT`
`PUBLIC`	ninguno

No otorgar:

TEMP por defecto;
privilegios a PUBLIC;
privilegios cross-environment.

Schema `business_observer`¶

Rol	Permisos minimos
`openclaw_bo_staging_owner`	ownership
`openclaw_bo_staging_writer`	`USAGE`
`openclaw_bo_staging_reader`	`USAGE`
`openclaw_bo_staging_reporting_ro`	`USAGE`
`PUBLIC`	ninguno

No otorgar:

CREATE a writer/reader/reporting;
USAGE o CREATE a PUBLIC.

Objetos futuros¶

Rol	Permisos minimos recomendados
`openclaw_bo_staging_writer`	`SELECT`, `INSERT`, `UPDATE`
`openclaw_bo_staging_reader`	`SELECT`
`openclaw_bo_staging_reporting_ro`	`SELECT`

Prohibiciones explicitas:

writer sin DELETE, TRUNCATE, REFERENCES, TRIGGER;
reader y reporting_ro sin INSERT, UPDATE, DELETE, TRUNCATE, REFERENCES, TRIGGER;
PUBLIC sin privilegios.

8. Politica de seguridad de roles¶

Propiedades recomendadas para todos los roles de grupo publicados en PDF-002:

NOSUPERUSER
NOCREATEDB
NOCREATEROLE
NOLOGIN

Justificacion:

evita que el SQL candidate dependa de passwords;
separa identidad de personas/procesos del modelo de permisos;
reduce riesgo de grants peligrosos;
deja la provision de credenciales como paso separado y gobernado.

9. Politica de extensiones¶

Politica recomendada en esta fase:

ninguna extension en PDF-002;
no crear uuid-ossp, pgcrypto u otras extensiones dentro de este candidate;
si una extension fuera realmente necesaria en PDF-004 o posterior, debe documentarse en tarea separada con:
justificacion tecnica;
impacto en restore;
compatibilidad con staging y prod;
owner responsable de instalarla.

10. Separacion staging-vps vs prod-vps futuro¶

Separacion obligatoria:

DB distinta por ambiente;
roles de grupo distintos por ambiente;
usuarios LOGIN distintos por ambiente;
backups distintos por ambiente;
restore drill distinto por ambiente;
grants y miembros revisados por ambiente.

Naming recomendado futuro para prod:

openclaw_bo_prod_owner
openclaw_bo_prod_writer
openclaw_bo_prod_reader
openclaw_bo_prod_reporting_ro

Regla:

no reciclar roles staging dentro de prod.

11. Prerequisitos antes de ejecutar cualquier DDL¶

Antes de cualquier PDF-003 o PDF-004 debe existir:

autorizacion explicita de la tarea;
safe point Git limpio y declarado;
DB objetivo confirmada como staging-vps, nunca prod;
backup previo confirmado;
restore plan asociado y visible;
fingerprint esperado del entorno documentado;
confirmacion de que no hay secretos en repo ni en SQL;
revision humana del candidate y del rollback conceptual;
ventana operativa acordada si la ejecucion deja objetos persistidos.

12. Fingerprint esperado para validar en PDF-003¶

PDF-003 debe validar como minimo:

text environment = staging-vps current_database = openclaw_business_observer_staging schema_target = business_observer db_prod_name = not current_database roles_expected = openclaw_bo_staging_owner / writer / reader / reporting_ro public_privileges = none on target db/schema extensions_required = none for PDF-002

Checks minimos esperados:

DB correcta y distinta de cualquier DB prod;
roles requeridos existentes o explicitamente ausentes antes de ejecutar;
schema business_observer ausente o presente segun el gate;
PUBLIC sin privilegios sobre DB objetivo y schema objetivo;
sin grants peligrosos heredados;
sin principals LOGIN compartidos con prod.

13. SQL candidate publicado¶

Archivo SQL candidato:

text docs/tenants/alpuntodeventa/business-observer/production/sql/PDF-002-staging-db-roles-schemas-candidate.sql

Marcado obligatorio:

CANDIDATE / NOT EXECUTED
STAGING-VPS ONLY
NO PASSWORDS
REQUIRES EXPLICIT AUTHORIZATION

El candidate:

no incluye passwords;
define roles de grupo NOLOGIN;
revoca privilegios de PUBLIC;
fija owner y schema recomendados;
deja default privileges para objetos futuros del schema.

14. Rollback candidate conceptual¶

Este PDF-002 no publica rollback ejecutable. Solo define rollback conceptual:

revocar membresias LOGIN futuras si existieran;
revocar grants sobre objetos del schema objetivo;
abortar si el schema contiene tablas/datos/objetos no contemplados;
dropear schema solo si esta vacio y autorizado;
dropear roles solo si no tienen miembros ni objetos dependientes;
nunca usar rollback ciego contra una DB que ya tenga datos cargados.