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-universesigue como fuente de verdad para contratos, policies, catálogo, gates y evidencias.cognitive-suiteestá en modobidirectional-controlledy activo.atlantyqa-association-bootstrapvive enuniversecomo dominio operativo gobernado.asertiva-impact-osqueda definido como satélite privado recomendado para runtime (backend/frontend/k8s), gobernado desdeuniverse.
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¶
- OpenAPI mínima:
/api/v1/cfs/actors/api/v1/cfs/pipelines/api/v1/cfs/dashboard/direccion/api/v1/cfs/ledger/events/api/v1/cfs/public/membership-requests/api/v1/cfs/public/sponsorship-requestspipeline-event.schema.jsonversionado.- KPI obligatorios:
beneficiarios_activosbeneficiarios_evaluadostasa_insercion(cuando aplique)eventos_ledgerimporte_financiacionyejecucion_correcta- SLO mínimos declarados (
latencia,error_rate,availability).
Cómo "escucha" atlantyqa-universe (control-plane contractual + evidencias)¶
Escucha por eventos GitHub y PR gates:
repository_dispatchdesde satélites con tipos:satellite.contract.syncsatellite.evidence.syncsatellite.kpi.syncsatellite.release.syncsatellite.security.alert- workflow listener:
.github/workflows/aidlc-bot-control-plane-listener.yml- contrato del bot:
.github/contracts/aidlc-bot-capabilities.json- guarda de consistencia:
scripts/verify/aidlc_bot_capabilities_guard.py.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¶
- Sí: separar runtime pesado a repos satélite privados para mantener gobernable
atlantyqa-universe. - Sí: mantener en
universeel control-plane, los contratos y los gates. - No: promover a
mainsin evidencia + validación UI/UX + decisión humana explícita.
Checklist de segregación sin regresión¶
- Alta del satélite en
stack-tech-core/catalog/bidirectional-governance.tsv. - Mantener matriz viva en
stack-tech-core/catalog/universe-satellite-segmentation.tsv. - Definir
governance.ymlenstack-tech-core/projects/<satelite>/. - Activar test de contrato en ambos repos.
- Habilitar doble escritura de evidencia durante 1-2 sprints.
- Cortar runtime de
universecuando 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.