Saltar a contenido

SOURCE-003 Core DDL Candidate Technical Review

Fecha local: 2026-06-15

Estado: REVISION TECNICA DOCUMENTAL / APTO PREFLIGHT LOCAL-DEV / NO EJECUTADO

portal_visible = yes

Scope: tenant

tenant_id: alpuntodeventa

Owner: Gabi / Carlos Canu

Fuente de verdad: docs/tenants/alpuntodeventa/business-observer/design/SOURCE-003-CORE-DDL-CANDIDATE-TECHNICAL-REVIEW.md

1. Objetivo

Revisar tecnicamente el paquete DDL CORE candidato de SOURCE-003 sin ejecutarlo, sin tocar PostgreSQL, sin crear objetos reales y sin modificar RAW, CORE, MART, Python, runners, CSV, Docker, VPS, OpenClaw, NPM ni Portainer.

Tabla candidata revisada:

text business_observer.core_source_003_sales_items

Batch piloto de referencia:

text 1827f887-9499-4579-b4f3-234d54f41f7f

2. Safe Point

Control Resultado
workspace C:\APV\openclawai
rama main
git status --short --branch inicial ## main...origin/main
git rev-parse HEAD inicial 0bf591134007d6fa2c5994895441f5dacf4869f9
ultimo commit inicial 0bf5911 docs: prepare source 003 core ddl candidate
decision SAFE POINT PASS

3. Archivos Revisados

  • SOURCE-003-CORE-DDL-CANDIDATE.md
  • sql/005_source_003_core_ddl_candidate_preflight.sql
  • sql/005_source_003_core_ddl_candidate_forward.sql
  • sql/005_source_003_core_ddl_candidate_rollback.sql
  • sql/005_source_003_core_ddl_candidate_post_checks.sql
  • SOURCE-003-CORE-LAYER-CONTRACT.md
  • SOURCE-003-IMPORTER-PROMOTE-CORE-PLAN.md
  • SOURCE-003-LOAD-RAW-LOCAL-DEV-POST-EXECUTION-REVIEW.md

4. Resultado de Revision

Control Resultado Observacion
Tabla candidata PASS El paquete apunta a business_observer.core_source_003_sales_items.
RAW no se modifica PASS El forward no contiene INSERT, UPDATE, DELETE ni COPY; RAW solo aparece como origen futuro y en preflight/post-checks de lectura.
Batch piloto PASS DOCUMENTAL El batch autorizado es 1827f887-9499-4579-b4f3-234d54f41f7f con 1886 filas esperadas segun evidencia RAW previa.
Columnas candidatas PASS Conteo estatico del forward: 66 columnas fisicas.
Constraints PASS Conteo estatico del forward: 22 constraints nombradas.
Indices PASS Conteo estatico del forward: 10 indices secundarios nombrados.
Clave tecnica PASS id uuid NOT NULL con PRIMARY KEY (id).
Trazabilidad minima PASS tenant_id, sync_batch_id, line_key y source_row_hash son obligatorios.
Owner PASS Schema, tabla e indices quedan orientados a openclaw_bo_admin.
Grants PASS writer recibe SELECT, INSERT, UPDATE; reader recibe SELECT; PUBLIC queda revocado.
writer sin DELETE PASS Hay REVOKE DELETE, TRUNCATE, REFERENCES, TRIGGER explicito sobre la tabla.
Rollback PASS Aborta si la tabla CORE existe y tiene filas; no usa TRUNCATE.
Post-check row count PASS Exige row_count = 0.
Riesgo channel_normalized PASS DOCUMENTAL Documentado como pendiente de catalogo aprobado.
Riesgo contribution_amount PASS DOCUMENTAL Documentado como valor candidato con semantica de margen pendiente.

5. Hallazgos Tecnicos

  1. El paquete esta bien separado por fases: preflight, forward, rollback y post_checks.
  2. El preflight es de lectura y valida DB esperada, schema, roles, RAW, ausencia de CORE, batch autorizado, campos criticos, duplicados y privilegios de PUBLIC.
  3. El forward crea la tabla CORE candidata vacia, define 66 columnas, 22 constraints, 10 indices, comments, owner y grants.
  4. El forward no carga datos y no modifica RAW. La unica referencia a RAW en ese archivo es documental como origen futuro.
  5. El rollback esta acotado a la tabla CORE candidata y sus indices; aborta si detecta filas.
  6. Los post_checks verifican owner, conteos estructurales, grants, ausencia de privilegios de PUBLIC, existencia de RAW y tabla CORE vacia.
  7. La clave tecnica id esta correctamente separada de la identidad logica tenant_id + line_key.
  8. La trazabilidad minima hacia RAW queda preservada por tenant_id, sync_batch_id, line_key, source_row_hash y raw_loaded_at.

6. Riesgos y Observaciones

  • El forward incluye CREATE SCHEMA IF NOT EXISTS business_observer; no es riesgoso si se respeta el preflight, porque este exige el schema existente y con owner correcto. No debe ejecutarse el forward de forma aislada.
  • id no tiene DEFAULT; el futuro promote-core debera generar o proveer el UUID de forma gobernada antes de insertar.
  • La unicidad tenant_id + line_key fuerza una politica clara de update, invalidacion o reemplazo para batches futuros. Esto es correcto para CORE, pero bloquea sync diaria hasta cerrar el gate de promocion.
  • channel_normalized no debe poblarse sin catalogo aprobado.
  • contribution_amount puede persistirse como valor candidato, pero no debe usarse como margen definitivo sin cierre funcional.
  • No hay RLS, particionado, estrategia productiva de backup/restore, monitoreo ni contrato de operacion para produccion.
  • Los grants de tabla estan cubiertos, pero cualquier politica futura de default privileges debe documentarse en un gate productivo separado.

7. Bloqueos Preservados

  • No se ejecuto SQL.
  • No se uso psql.
  • No se toco PostgreSQL.
  • No se creo tabla real.
  • No se modifico Python.
  • No se cargaron datos.
  • No se genero CSV.
  • No se ejecuto runner.
  • No se toco RAW/CORE/MART real.
  • No se uso VPS, Docker, OpenClaw, NPM ni Portainer.
  • No se hizo push ni deploy.

8. Conclusion

text APTO PARA PREFLIGHT LOCAL-DEV NO APTO PARA PRODUCCION NO APTO PARA SYNC DIARIA NO APTO PARA PROMOTE-CORE AUN

El paquete CORE candidato es tecnicamente consistente para abrir una tarea futura de preflight local-dev, bajo SAFE POINT nuevo y autorizacion explicita.

No queda habilitado el forward, no queda habilitada produccion, no queda habilitada sync diaria y no queda habilitado promote-core.