Skip to content

Mapa de Gobierno: Atlantyqa-Universe y Repos Satélite

Objetivo

Pintar y reevaluar el flujo de trabajo y gobierno entre atlantyqa-universe (control-plane) y los repos satélite, con ruta de promoción segura hacia main.

Estado reevaluado (2026-04-03)

  • atlantyqa-universe sigue como fuente de verdad para contratos, policies, catálogo, gates y evidencias.
  • cognitive-suite está en modo bidirectional-controlled y activo.
  • atlantyqa-association-bootstrap vive en universe como dominio operativo gobernado.
  • asertiva-impact-os queda definido como satélite privado recomendado para runtime (backend/frontend/k8s), gobernado desde universe.

Diagrama 1 — Topología de gobierno

graph TD
    U[atlantyqa-universe<br/>control-plane] --> C[Contratos + Policies + Gates]
    U --> K[Catálogo bidireccional<br/>stack-tech-core/catalog]
    U --> E[Evidencias + Bitácora + Contexto]
    U --> A1[atlantyqa-labs/cognitive-suite<br/>satélite activo]
    U --> A2[asertiva-impact-os<br/>satélite privado recomendado]

    A1 --> U
    A2 --> U

    C --> M[main protegido]
    E --> M
    K --> M

Diagrama 2 — Sync bidireccional controlado

graph LR
    UA[Flujo A: Universe -> Satélite<br/>contrato/policy/version pin] --> SG[PR en satélite]
    SG --> SC[Checks contrato + tests]
    SC --> SH[Gate humano triada]
    SH --> SR[Release satélite]

    SB[Flujo B: Satélite -> Universe<br/>evidencia/KPI/changelog] --> UP[PR en universe]
    UP --> UC[Checks no humanos + guardas]
    UC --> UH[Decisión humana triada]
    UH --> UM[main universe]

Diagrama 3 — Pipeline anti-regresión de misión

graph TD
    T0[Unit tests] --> T1[Integración]
    T1 --> T2[Contrato API consumer/provider]
    T2 --> T3[E2E misión<br/>captación -> ejecución -> justificación]
    T3 --> T4[KPI/DoD mínimo]
    T4 --> G{Triada aprueba?}
    G -->|Sí| R[mergeable]
    G -->|No| B[blocked o needs-small-fix]

Contrato mínimo recomendado para satélites runtime

  1. OpenAPI mínima:
  2. /api/v1/cfs/actors
  3. /api/v1/cfs/pipelines
  4. /api/v1/cfs/dashboard/direccion
  5. /api/v1/cfs/ledger/events
  6. /api/v1/cfs/public/membership-requests
  7. /api/v1/cfs/public/sponsorship-requests
  8. pipeline-event.schema.json versionado.
  9. KPI obligatorios:
  10. beneficiarios_activos
  11. beneficiarios_evaluados
  12. tasa_insercion (cuando aplique)
  13. eventos_ledger
  14. importe_financiacion y ejecucion_correcta
  15. SLO mínimos declarados (latencia, error_rate, availability).

Cómo "escucha" atlantyqa-universe (control-plane contractual + evidencias)

Escucha por eventos GitHub y PR gates:

  1. repository_dispatch desde satélites con tipos:
  2. satellite.contract.sync
  3. satellite.evidence.sync
  4. satellite.kpi.sync
  5. satellite.release.sync
  6. satellite.security.alert
  7. workflow listener:
  8. .github/workflows/aidlc-bot-control-plane-listener.yml
  9. contrato del bot:
  10. .github/contracts/aidlc-bot-capabilities.json
  11. guarda de consistencia:
  12. scripts/verify/aidlc_bot_capabilities_guard.py
  13. .github/workflows/aidlc-bot-capabilities-gate.yml

Resultado: el control-plane recoge evidencia normalizada en: outputs/control-plane/bot-events/*.json

Decisión operativa recomendada

  • : separar runtime pesado a repos satélite privados para mantener gobernable atlantyqa-universe.
  • : mantener en universe el control-plane, los contratos y los gates.
  • No: promover a main sin evidencia + validación UI/UX + decisión humana explícita.

Checklist de segregación sin regresión

  1. Alta del satélite en stack-tech-core/catalog/bidirectional-governance.tsv.
  2. Mantener matriz viva en stack-tech-core/catalog/universe-satellite-segmentation.tsv.
  3. Definir governance.yml en stack-tech-core/projects/<satelite>/.
  4. Activar test de contrato en ambos repos.
  5. Habilitar doble escritura de evidencia durante 1-2 sprints.
  6. Cortar runtime de universe cuando KPI y E2E de misión estén estables.

Fronteras por rol (referencia canon)

La matriz de responsabilidad humana/bot se mantiene en:

  • docs/internal/policies/role-responsibility-boundary-matrix-policy.md

Uso recomendado: - citar esta política en PRs de gobernanza/satélites; - verificarla junto a la segmentación técnica (universe-satellite-segmentation.tsv) antes de cambios estructurales.