Saltar a contenido

Governance Control Tower

Lectura ejecutiva al 2026-06-03.

Estado

  • Governance: 96% - v2 extendida con operaciones, seguridad, lenguaje humano y gate documental de updates ya propagado a politica operativa y fichas
  • Knowledge Graph: 97% - relaciones explicitas agregadas entre servicios, redes, volumenes, dominios, backups, tests, operacion y seguridad
  • Tests: 100% - catalogo ampliado a 32 pruebas; 32 PASS, 0 WARNING, 0 PENDIENTE, alineado con docs/governance/VALIDATION-STATE.md
  • Catalogos: 97% - catalogos base, validacion, operacion y seguridad alineados
  • Servicios: VERDE - svc-openclaw, svc-nginx-proxy-manager, svc-portainer, svc-observability-o4, svc-scalar-sandbox
  • Backups: VERDE - artefactos, hashes y copia externa evidenciados
  • Restore: VERDE - staging no destructivo validado
  • DR: VERDE - certificado al 2026-05-31
  • Operations: VERDE - evidencia real de backup reciente, capacidad, salud y gate Ubuntu pre-change cerrados
  • Security: VERDE - SSL, puertos publicos, exposicion y revision formal de riesgo cerrados sin hallazgo critico nuevo; Portainer queda reconciliado en el baseline documental vigente detras de NPM, sin 8000/9443 publicados al host
  • Monitoring: VERDE - baseline viva, disco, RAM, swap, load y contenedores revalidados con evidencia actual, drills O3.1 cerrados y alertas base controladas
  • Observability O4: VERDE EN VPS - arquitectura real Grafana -> Thanos Query -> Prometheus/Thanos corriendo con historico local en obs_thanos_objectstore_data
  • Alertas O4: VERDE OPERATIVO - reglas, runtime y fallback local-null activos; SMTP externo reclasificado como mejora futura opcional no prioritaria
  • AI Administration: VERDE - preguntas, rutas y respuestas base documentadas
  • Knowledge Platform O6: VERDE - infraestructura viva navegable, auditada contra realidad y preparada para drill-down
  • Knowledge Population O8: VERDE - fichas atomicas nuevas para observabilidad, Docker, runtime real, DNS/TLS, runtime host e integracion OpenAI comprobada
  • Knowledge Portal O9: VERDE PUBLICADO - portal MkDocs Material activo en https://doc.alpuntodeventa.com.ar/
  • Knowledge Portal O9.2: VERDE - sync desde Git validado sobre checkout real del VPS
  • Knowledge Portal O9.3: VERDE - deploy key read-only aceptada, checkout Git real activo y deploy validado sobre origin/main
  • Service Access O9.4: VERDE - Grafana, Portainer, OpenClaw y Knowledge Portal validados por HTTPS; Prometheus, Alertmanager y Thanos Query siguen sin exposicion publica directa
  • Git Sync O9.5: VERDE - causa raiz del git pull remoto cerrada; el portal vuelve a actualizarse por git pull --ff-only origin main
  • Executive Board O9.6: VERDE - tablero provisionado en Grafana usando solo Thanos, con lectura ejecutiva de VPS, servicios, SSL, targets y alertas
  • Future Platform Foundation 9.9: VERDE DOCUMENTAL - vision futura oficial congelada en docs/FUTURE-PLATFORM-ROADMAP.md sin mutar la infraestructura actual ni abrir todavia Multi-Tenant Foundation
  • Multi-Tenant Foundation 10: VERDE DOCUMENTAL - contrato oficial, estructura de docs/global y docs/tenants, tenants iniciales y estandar documental ya publicados en el portal sin tocar runtime productivo
  • Data Foundation 14: VERDE DOCUMENTAL - base oficial de datos multi-tenant documentada en docs/architecture/DATA-FOUNDATION.md con estrategia inicial, dominios, fuentes, lineage y seguridad futura sin implementar todavia PostgreSQL ni capas runtime nuevas
  • API Platform 15: VERDE DOCUMENTAL - capa oficial de APIs multi-tenant documentada en docs/architecture/API-PLATFORM.md con arquitectura, contrato, seguridad futura, catalogo inicial y OpenAPI obligatorio sin publicar endpoints reales todavia
  • PostgreSQL Sandbox 15.2: SANDBOX VALIDADO EN VPS - primera base multi-tenant privada definida en infra/data-foundation/postgres-sandbox/ y documentada en docs/governance/operations/POSTGRESQL-SANDBOX-MULTI-TENANT.md, con RLS, datos ficticios, validacion de aislamiento por rol y sin exposicion publica
  • PostgREST Sandbox 15.3: SANDBOX INTERNO IMPLEMENTADO - capa REST privada definida en infra/data-foundation/postgrest-sandbox/ y documentada en docs/governance/operations/POSTGREST-SANDBOX-MULTI-TENANT.md, con validacion inicial de RLS, REST y OpenAPI sobre red Docker interna y sin publicacion por NPM ni puertos de host
  • Tenant Security Sandbox 15.4: SANDBOX INTERNO JWT + SCOPE ENFORCEMENT - seguridad multi-tenant documentada en docs/governance/operations/TENANT-SECURITY-SANDBOX.md, con runtime unico, claims tenant_id, role, scope, enforcement granular por recurso, secreto fuera de Git y RLS reforzada, sin exposicion publica y sin usar todavia developers.alpuntodeventa.com.ar Revalidacion runtime 2026-06-02: PortBindings {}, red solo pg-sandbox-internal, / con token valido 200, rechazos 403 por scope insuficiente o iss invalido y rechazos 401 para token invalido o expirado
  • OpenAPI Refinement Sandbox 15.5: CONTRATO REFINADO Y VALIDADO EN VPS - diagnostico, contrato objetivo, metadata SQL humana y politica de no exportar JSON con host interno documentadas en docs/governance/operations/OPENAPI-REFINEMENT-SANDBOX.md, manteniendo PostgREST interno, sin instalar Scalar y sin usar todavia developers.alpuntodeventa.com.ar
  • API Documentation Platform 16: VERDE SANDBOX PUBLICADO - capa oficial de documentacion de APIs ya visible en https://developers.alpuntodeventa.com.ar con Scalar, contratos sanitizados versionados, PostgREST interno preservado y publicacion solo por NPM
  • Developer Portal Hardening 15.6b: VERDE - stash remoto previo a Scalar revisado y preservado, HTTP -> HTTPS revalidado, /clientes publico en 404, OpenAPI publico sin indicadores inseguros y probe publico agregado
  • Codex Efficiency Operating Gate: VERDE DOCUMENTAL - ACTIVE-CONTEXT queda como router operativo corto y GATE-CODEX-EFFICIENCY como gate formal para tareas grandes, reduciendo lectura por defecto sin debilitar SAFE POINT ni governance
  • Blueprint Governance Model: VERDE DOCUMENTAL - auditoria documental, constitucion minima, jerarquia documental y carpeta de blueprints formalizadas; primer CUSTOMER-BLUEPRINT funcional creado para APV sin tocar runtime, VPS, Docker, queries, tablas, migraciones ni codigo

Gaps abiertos

  • queda pendiente sostener la auditoria periodica reality vs docs para que O6 no se degrade
  • quedan fuera de O8 solo decisiones operativas pendientes sobre portainer_data y portainer2_default; el canal externo de alertas SMTP queda reclasificado como mejora futura opcional no prioritaria
  • la contradiccion historica sobre exposicion directa de Portainer queda cerrada a nivel documental a favor del baseline vigente detras de NPM; si se quiere recertificar esa superficie desde runtime, corresponde una nueva auditoria reality vs docs, clasificada por ahora como control futuro no bloqueante
  • queda como mejora menor seguir endureciendo el flujo del portal si en el futuro se quiere reemplazar tambien el script staged en /root, aunque el runtime actual ya sincroniza desde origin/main
  • owners humanos formales de alpuntodeventa y ladirecta: Gabi / Carlos Canu, pendiente documental cerrado
  • queda pendiente abrir la implementacion real de PostgreSQL, RLS y syncs multi-tenant cuando se aprueben etapas runtime posteriores
  • queda pendiente consolidar el sandbox PostgREST con autenticacion real, JWT por tenant_id, OpenAPI publicado y policy de exposicion segura de la API Platform
  • queda pendiente decidir si el sandbox PostgreSQL sigue como stack temporal, se mueve a ubicacion operativa persistente o se reintegra a un checkout remoto con permisos Git corregidos
  • queda pendiente definir si en el futuro habra tokens sandbox interactivos, mocks ejecutables o pruebas controladas desde la UI
  • queda pendiente decidir cuando pasar del portal documental actual a una capa de APIs controladas con auth, auditoria y rate limiting

Bloqueantes

  • ninguno para la operacion actual del portal publicado
  • ninguno especifico para O9.2/O9.3/O9.4/O9.5/O9.6
  • para Governance Fully Certified antes de tocar runtime, el unico bloqueo fuerte remanente siguen siendo los 4 tests UPDATE pendientes

Proximo paso unico

  • mantener congelada la arquitectura tecnologica cerrada hasta que se apruebe formalmente abrir O10
  • mantener como regla operativa que todo update, upgrade, mantenimiento relevante o cambio operativo pase por docs/governance/CHANGE-GATES.md y docs/governance/runbooks/UPDATE-SERVICE.md
  • usar docs/FUTURE-PLATFORM-ROADMAP.md como contrato oficial antes de abrir cualquier capa futura de negocio o multi-tenant
  • usar docs/architecture/MULTI-TENANT-FOUNDATION.md y docs/architecture/DATA-FOUNDATION.md y docs/architecture/API-PLATFORM.md y docs/architecture/API-DOCUMENTATION-PLATFORM.md y docs/governance/standards/MULTI-TENANT-DOCUMENTATION-STANDARD.md como gate obligatorio antes de crear activos, datos o integraciones por tenant
  • usar docs/governance/PROJECT-CONSTITUTION.md y docs/governance/documentation/DOCUMENT-HIERARCHY.md antes de crear blueprints funcionales