Saltar a contenido

PDF-010O - B2B PostgreSQL Permissions DDL Retry Plan

Fecha: 2026-06-23

Estado: PERMISSIONS PREFLIGHT + DDL ADJUSTMENT PLAN / SIN DDL WRITE / NO-GO PARA REINTENTO INMEDIATO

portal_visible = yes

A. Que fallo en PDF-010N

PDF-010N intento ejecutar una sola vez el DDL candidate PDF-010K con ON_ERROR_STOP=1 y transaccion unica. PostgreSQL rechazo el primer statement:

text permission denied for database gestion_de_negocios_core

No se crearon tablas B2B, no se creo la vista, no se aplicaron grants, no se aplico RLS y no se ejecuto rollback candidate.

B. Safe Point

  • HEAD inicial esperado: a4d3186eca663b955ef5832c593dc5ea3428c89c
  • origin/main esperado: a4d3186eca663b955ef5832c593dc5ea3428c89c
  • Ultimo commit esperado: a4d3186 docs: record pdf-010n b2b ddl no-go
  • Repo inicial: limpio.

C. Documentacion revisada

  • PDF-010K-B2B-PERSISTENCE-CONTRACT-DDL-CANDIDATE.md
  • PDF-010L-B2B-DDL-EXECUTION-PREFLIGHT.md
  • PDF-010M-B2B-POSTGRESQL-REAL-READ-ONLY-PREFLIGHT.md
  • PDF-010N-B2B-CONTROLLED-DDL-EXECUTION.md
  • PDF-010K-B2B-PERSISTENCE-DDL-CANDIDATE.sql
  • PDF-010K-B2B-PERSISTENCE-ROLLBACK-CANDIDATE.sql
  • docs/PROJECT-STATE.md
  • docs/ROADMAP.md
  • docs/governance/ACTIVE-CONTEXT.md

D. Inspeccion PostgreSQL read-only

La inspeccion se ejecuto solo con SELECT y SHOW, dentro de transaccion READ ONLY, sin imprimir secretos.

  • current_user: openclaw_writer
  • current_database: gestion_de_negocios_core
  • PostgreSQL: 15.15
  • owner de database: postgres
  • owner de schema business_observer: postgres
  • objetos B2B de PDF-010K: ausentes
  • sql_write_executed=false
  • ddl_executed=false
  • secrets_printed=false

E. Resultado roles/permisos

Roles existentes:

  • openclaw_bo_admin
  • openclaw_bo_writer
  • openclaw_bo_reader

Roles ausentes:

  • business_observer_admin
  • business_observer_writer
  • business_observer_reader

Permisos observados:

  • openclaw_writer: CONNECT=true, CREATE sobre DB=false, USAGE sobre schema=true, CREATE sobre schema=false.
  • openclaw_bo_admin: CONNECT=true, CREATE sobre DB=false, USAGE sobre schema=false, CREATE sobre schema=false.
  • openclaw_bo_writer: CONNECT=true, CREATE sobre DB=false, USAGE sobre schema=false, CREATE sobre schema=false.
  • openclaw_bo_reader: CONNECT=true, CREATE sobre DB=false, USAGE sobre schema=false, CREATE sobre schema=false.
  • openclaw_writer no es miembro de openclaw_bo_admin, openclaw_bo_writer ni openclaw_bo_reader.

Lectura operativa: falta permiso de creacion para el usuario usado y falta alinear roles de grants antes de reintentar.

F. Analisis del DDL candidate PDF-010K

El DDL candidate incluye:

  • CREATE SCHEMA IF NOT EXISTS business_observer
  • tablas business_observer.b2b_customer_mapping, business_observer.b2b_product_price y business_observer.b2b_pricing_decision_log
  • vista business_observer.v_b2b_customer_effective_price
  • ALTER TABLE ... ENABLE ROW LEVEL SECURITY
  • grants hacia business_observer_reader, business_observer_writer y business_observer_admin

Ajustes requeridos antes de un nuevo gate:

  • remover o separar CREATE SCHEMA IF NOT EXISTS business_observer, porque el schema ya existe y el usuario observado no tiene CREATE sobre la DB.
  • reemplazar grants hacia business_observer_* por roles reales openclaw_bo_*, o provisionar aliases antes del DDL.
  • decidir usuario ejecutor: usar owner/admin autorizado en vez de openclaw_writer, o conceder permisos minimos aprobados antes del gate.
  • mantener tablas, constraints, indices, vista y RLS como candidate, pero validar ownership final y grants con post-check read-only.

G. Opciones de resolucion

Opcion A - adaptar DDL candidate a roles reales openclaw_bo_*.

  • Cambiar grants a openclaw_bo_reader, openclaw_bo_writer y openclaw_bo_admin.
  • Remover dependencia de roles business_observer_*.
  • Requiere ejecutar el DDL con un usuario que pueda crear objetos en el schema existente.

Opcion B - crear aliases business_observer_*.

  • Mantiene el DDL candidate con menos cambios textuales.
  • Agrega roles nuevos a la gobernanza actual.
  • Solo conviene si se decide que business_observer_* sera naming canonico.

Opcion C - ejecutar DDL con usuario admin/owner correcto y grants finales a openclaw_bo_*.

  • Usa el modelo real observado.
  • Evita ampliar openclaw_writer como usuario DDL.
  • Requiere credencial/admin aprobada y backup nuevo antes de ejecutar.

Opcion D - pedir grant minimo previo a openclaw_writer.

sql GRANT CREATE ON DATABASE gestion_de_negocios_core TO openclaw_writer; GRANT USAGE, CREATE ON SCHEMA business_observer TO openclaw_writer;

  • Es simple pero aumenta poder DDL del usuario operativo.
  • Solo debe considerarse con aprobacion explicita y auditoria.

H. Recomendacion unica

Recomendacion: combinar Opcion A + Opcion C.

Preparar un PDF-010P que ajuste el DDL a los roles reales openclaw_bo_reader, openclaw_bo_writer y openclaw_bo_admin, quite la dependencia de business_observer_*, trate business_observer como schema preexistente y ejecute el DDL con un usuario admin/owner aprobado.

Razones:

  • menor riesgo que ampliar permisos de openclaw_writer;
  • menor cambio de gobernanza que crear aliases nuevos;
  • mas alineado con roles reales ya existentes;
  • mas facil de auditar en post-check;
  • mas rapido para produccion porque evita reintentos con roles inexistentes.

I. GO/NO-GO para reintento

Estado: NO-GO PARA REINTENTO INMEDIATO.

Condicion para pasar a GO en gate posterior:

  • DDL candidate ajustado a openclaw_bo_*.
  • usuario ejecutor admin/owner aprobado.
  • backup real nuevo confirmado fuera de Git.
  • preflight read-only nuevo PASS.
  • post-check read-only preparado para roles reales.
  • autorizacion explicita para ejecutar DDL.

J. Proximo gate

Abrir PDF-010P como gate separado:

  • crear DDL retry candidate ajustado;
  • crear rollback candidate alineado;
  • validar estaticamente roles reales;
  • ejecutar nuevo preflight read-only;
  • solicitar autorizacion explicita antes de cualquier DDL.

K. Que NO se ejecuto

No se ejecuto DDL. No se ejecuto SQL write. No se crearon roles. No se modificaron permisos. No se crearon tablas. No se tocaron datos. No se toco WooCommerce API. No se modifico .env. No se imprimieron secretos. No se modifico runtime. No se ejecuto sync, scheduler, cron ni pipelines.