GT-616 + GT-617: governance spans that can be switched on, and doc inventories derived from the code

.github/workflows/docs.yml

@@ -33,6 +33,14 @@ jobs:
       - name: Validate root cleanliness
         run: node .harness/scripts/validate-root-cleanliness.mjs
 
+      # GT-617 — los inventarios documentales se DERIVAN del código, no se mantienen a mano.
+      # Falla el build a proposito: la insignia de ADRs, el mapa de schemas y el listado de
+      # robots llevaban meses desfasados (30 vs 54 decisiones, 10 vs 8 schemas, 3 vs 12
+      # robots) y nadie lo noto, porque nada los contrastaba con la fuente. Corre en segundos
+      # y no necesita ni base de datos ni SDK.
+      - name: Documentation inventory must match the code
+        run: node .harness/scripts/doc-inventory.mjs --check
+
       - name: Check orphan bilingual files
         # El escalar plano de `run:` no puede contener ": " — rompia el parseo del workflow y
         # por eso este fichero nunca llego a ejecutarse (374 ejecuciones, 0 exitosas). Bloque

MASTER_INDEX.es.md

@@ -36,7 +36,7 @@ Bienvenido a la documentación del **Evolith Tracker**, repositorio satélite de
 | [Tracker Target Architecture](./reference/specs/design/tracker-target-architecture.md) | — | TAD maestro: bounded contexts, domain model, layer structure, integrations |
 | [NestJS Backend Design](./reference/specs/design/tracker-nestjs-backend-design.md) | — | Arquitectura NestJS: módulos, CQRS, repositories, guards, middleware |
 | [React Frontend Design](./reference/specs/design/tracker-react-frontend-design.md) | — | Arquitectura React: state management, routing, permission-driven UI |
-| [PostgreSQL Data Design](./reference/specs/design/tracker-postgresql-data-design.md) | — | Diseño de datos: 10 schemas, DDL, RLS, indexes, concurrency, migrations |
+| [PostgreSQL Data Design](./reference/specs/design/tracker-postgresql-data-design.md) | — | Diseño de datos: mapa de schemas (derivado del código), DDL, RLS, indexes, concurrency, migrations |
 | [UMS Authentication Integration](./reference/specs/design/tracker-ums-authentication-integration.md) | — | Integración AuthN/AuthZ con UMS SaaS: JWT, JWKS, permission guards |
 | [UMS Authorization Graph Design](./reference/specs/design/tracker-ums-authorization-graph-design.md) | — | ACL transformation: UMS graph → Tracker permissions, role hierarchy |
 | [Core Integration Design](./reference/specs/design/tracker-core-integration-design.md) | — | Integración con Evolith Core: rulesets, artifact schemas, taxonomy, caching |

MASTER_INDEX.md

@@ -37,7 +37,7 @@ Bienvenido a la documentación del **Evolith Tracker**, repositorio satélite de
 | [Platform Implementation](./reference/specs/design/tracker-platform-implementation.md) | Reporte de implementación: Ondas 1-4 (Fundación, PostgreSQL, Gobernanza, Integración Core) |
 | [NestJS Backend Design](./reference/specs/design/tracker-nestjs-backend-design.md) | Arquitectura NestJS: módulos, CQRS, repositories, guards, middleware |
 | [React Frontend Design](./reference/specs/design/tracker-react-frontend-design.md) | Arquitectura React: state management, routing, permission-driven UI |
-| [PostgreSQL Data Design](./reference/specs/design/tracker-postgresql-data-design.md) | Diseño de datos: 10 schemas, DDL, RLS, indexes, concurrency, migrations |
+| [PostgreSQL Data Design](./reference/specs/design/tracker-postgresql-data-design.md) | Diseño de datos: mapa de schemas (derivado del código), DDL, RLS, indexes, concurrency, migrations |
 | [UMS Authentication Integration](./reference/specs/design/tracker-ums-authentication-integration.md) | Integración AuthN/AuthZ con UMS SaaS: JWT, JWKS, permission guards |
 | [UMS Authorization Graph Design](./reference/specs/design/tracker-ums-authorization-graph-design.md) | ACL transformation: UMS graph → Tracker permissions, role hierarchy |
 | [Core Integration Design](./reference/specs/design/tracker-core-integration-design.md) | Integración con Evolith Core: rulesets, artifact schemas, taxonomy, caching |
@@ -73,7 +73,7 @@ Bienvenido a la documentación del **Evolith Tracker**, repositorio satélite de
 | Documento | Descripción |
 | :--- | :--- |
 | [Bounded Context Map (oficial)](./reference/specs/architecture/bounded-context-map.md) | **Mapa estratégico** de los 9 contexts: relaciones, patrones DDD, flujo de domain events |
-| [Domain Model & E/R Overview](./reference/specs/architecture/tracker-domain-model-overview.md) | **Síntesis consolidada**: modelo conceptual, agregados, value objects y E/R de los 10 schemas |
+| [Domain Model & E/R Overview](./reference/specs/architecture/tracker-domain-model-overview.md) | **Síntesis consolidada**: modelo conceptual, agregados, value objects y E/R de los schemas reales |
 | **Fase 0 — Strategic Intake** | |
 | [Intake Specifications](./reference/specs/intake/README.md) | Intake aggregate structures for Gate 0 |
 | [Phase 0 Intake Formats](./docs/artifacts/PHASE_0_INTAKE_FORMATS.md) | Manual UI templates and API JSON Schema contracts for Funnel 0 |

README.es.md

@@ -7,7 +7,9 @@
 [![Estado](https://img.shields.io/badge/Estado-Activo-brightgreen?style=for-the-badge)]()
 [![Plataforma](https://img.shields.io/badge/.NET_10_%7C_PostgreSQL_%7C_React_19-informational?style=for-the-badge)]()
 [![Arquitectura](https://img.shields.io/badge/Evolith-Satélite-blueviolet?style=for-the-badge)](https://github.com/beyondnetcode/evolith_arch32)
-[![ADRs](https://img.shields.io/badge/ADRs-30_decisiones-orange?style=for-the-badge)](./DECISIONS.md)
+<!-- BEGIN GENERATED: adr-count — derivado por .harness/scripts/doc-inventory.mjs; NO editar a mano -->
+[![ADRs](https://img.shields.io/badge/ADRs-54_decisiones-orange?style=for-the-badge)](./DECISIONS.md)
+<!-- END GENERATED: adr-count -->
 [![Licencia](https://img.shields.io/badge/Licencia-Dual_License-informational?style=for-the-badge)](./LICENSE)
 
 <br/>

README.md

@@ -7,7 +7,9 @@
 [![Status](https://img.shields.io/badge/Status-Active-brightgreen?style=for-the-badge)]()
 [![Platform](https://img.shields.io/badge/.NET_10_%7C_PostgreSQL_%7C_React_19-informational?style=for-the-badge)]()
 [![Architecture](https://img.shields.io/badge/Evolith-Satellite_Product-blueviolet?style=for-the-badge)](https://github.com/beyondnetcode/evolith_arch32)
-[![ADRs](https://img.shields.io/badge/ADRs-30_decisions-orange?style=for-the-badge)](./DECISIONS.md)
+<!-- BEGIN GENERATED: adr-count — derivado por .harness/scripts/doc-inventory.mjs; NO editar a mano -->
+[![ADRs](https://img.shields.io/badge/ADRs-54_decisions-orange?style=for-the-badge)](./DECISIONS.md)
+<!-- END GENERATED: adr-count -->
 [![License](https://img.shields.io/badge/License-Dual_License-informational?style=for-the-badge)](./LICENSE)
 
 <br/>

product/infra/helm/evolith-tracker-api/templates/configmap.yaml

@@ -20,3 +20,10 @@ data:
   Authentication__Ums__Issuer: {{ .Values.auth.ums.issuer | quote }}
   Authentication__Ums__RequireHttpsMetadata: {{ .Values.auth.ums.requireHttpsMetadata | quote }}
   Cors__Origins__0: {{ .Values.cors.origins | quote }}
+  {{- if .Values.otlp.endpoint }}
+  # T-049 / GT-616 — solo se emite cuando hay colector. Emitirlo vacio seria equivalente a no
+  # emitirlo (la app hace retorno temprano), pero dejaria una clave en el configmap que sugiere
+  # que las trazas estan configuradas cuando no lo estan.
+  Otlp__Endpoint: {{ .Values.otlp.endpoint | quote }}
+  Otlp__ServiceName: {{ .Values.otlp.serviceName | quote }}
+  {{- end }}

product/infra/helm/evolith-tracker-api/values.yaml

@@ -74,6 +74,23 @@ auth:
 cors:
   origins: "http://localhost:4200"
 
+# T-049 / GT-616 — trazas distribuidas por push OTLP.
+#
+# `endpoint` VACIO = trazas apagadas, y ese sigue siendo el valor por defecto: `T-049` decidio no
+# entregarlas encendidas porque un exportador que no alcanza a nadie reintenta para siempre y ata
+# la disponibilidad del producto a la de un sumidero de telemetria.
+#
+# Lo que GT-616 arregla no es el valor por defecto sino que NO HABIA INTERRUPTOR: el configmap no
+# emitia `Otlp__Endpoint` en absoluto, asi que un operador CON colector no tenia forma soportada de
+# encenderlas — solo inyectarla a mano por `extraEnv`, que es exactamente el tipo de configuracion
+# no declarada que este chart evita en todo lo demas.
+#
+# Ponlo al colector del cluster para encenderlas, p. ej.:
+#   otlp.endpoint=http://opentelemetry-collector.observability:4317
+otlp:
+  endpoint: ""
+  serviceName: evolith-tracker-api
+
 # EF Core migrations: run as a pre-install/pre-upgrade Job using the embedded
 # `dotnet ef migrations bundle` shipped in the image at /app/efbundle/efbundle.
 migrations:

reference/specs/architecture/README.es.md

@@ -21,7 +21,7 @@
 | Documento | Descripción | Propósito | Tipo |
 |---|---|---|---|
 | [Bounded Context Map](./bounded-context-map.es.md) | Mapa estratégico oficial de los 9 contextos: cadena Customer-Supplier, Partnership, Conformist, ACLs y el flujo de eventos de dominio | Saber dónde termina la responsabilidad de cada contexto y quién depende de quién | DDD estratégico |
-| [Visión del Modelo de Dominio y E/R](./tracker-domain-model-overview.es.md) | Síntesis consolidada: modelo conceptual, agregados, value objects y diseño E/R de los 10 schemas | Punto de entrada único a todo el diseño de dominio sin leer 9 modelos separados | Síntesis |
+| [Visión del Modelo de Dominio y E/R](./tracker-domain-model-overview.es.md) | Síntesis consolidada: modelo conceptual, agregados, value objects y diseño E/R de los schemas reales | Punto de entrada único a todo el diseño de dominio sin leer 9 modelos separados | Síntesis |
 
 </details>
 

reference/specs/architecture/README.md

@@ -21,7 +21,7 @@
 | Document | Description | Purpose | Type |
 |---|---|---|---|
 | [Bounded Context Map](./bounded-context-map.md) | Official strategic map of the 9 contexts: Customer-Supplier chain, Partnership, Conformist, ACLs, and the domain-event flow | Know where each context's responsibility ends and who depends on whom | Strategic DDD |
-| [Domain Model & E/R Overview](./tracker-domain-model-overview.md) | Consolidated synthesis: conceptual model, aggregates, value objects, and E/R design across the 10 schemas | Single entry point to the whole domain design without reading 9 separate models | Synthesis |
+| [Domain Model & E/R Overview](./tracker-domain-model-overview.md) | Consolidated synthesis: conceptual model, aggregates, value objects, and E/R design across the real schemas | Single entry point to the whole domain design without reading 9 separate models | Synthesis |
 
 </details>
 

reference/specs/architecture/c4-macro-topology-phase1.es.md

@@ -113,7 +113,7 @@ C4Component
     }
 
     Container(api_gateway, "Governance API", "Nginx", "Llamadas entrantes (REST)")
-    ContainerDb(single_db, "Relational Database", "PostgreSQL", "10 schemas aislados")
+    ContainerDb(single_db, "Relational Database", "PostgreSQL", "schema-per-context (T-047)")
 
     Rel(api_gateway, discovery_module, "Ruta tráfico", "REST")
     Rel(api_gateway, integration_module, "Ruta tráfico", "REST")

reference/specs/architecture/c4-macro-topology-phase1.md

@@ -113,7 +113,7 @@ C4Component
     }
 
     Container(api_gateway, "Governance API", "Nginx", "Llamadas entrantes (REST)")
-    ContainerDb(single_db, "Relational Database", "PostgreSQL", "10 schemas aislados")
+    ContainerDb(single_db, "Relational Database", "PostgreSQL", "schema-per-context (T-047)")
 
     Rel(api_gateway, discovery_module, "Ruta tráfico", "REST")
     Rel(api_gateway, integration_module, "Ruta tráfico", "REST")

reference/specs/architecture/scale-out-strategy.es.md

@@ -6,7 +6,7 @@ Este documento detalla la ruta de migración desde el **Monolito de Despliegue 
 
 ## 1. El Estado Inicial (Fase 1)
 - **Topología:** Un solo servicio Backend corriendo en un solo pod/servidor.
-- **Base de Datos:** Un solo cluster físico segregado en 5 esquemas (`discovery_schema`, `qa_schema`, etc.).
+- **Base de Datos:** Un solo cluster físico segregado por schema-per-context (el mapa vigente lo deriva `.harness/scripts/doc-inventory.mjs` en `reference/specs/design/tracker-postgresql-data-design.md` §1.1).
 - **Comunicación Interna:** Llamadas a interfaces a través del *In-Memory Event Bus* (CQRS nativo en memoria).
 - **Frontend:** Microfrontends ya segregados por dominio (aprobado en T-002).
 

reference/specs/architecture/scale-out-strategy.md

@@ -6,7 +6,7 @@ Este documento detalla la ruta de migración desde el **Monolito de Despliegue 
 
 ## 1. El Estado Inicial (Fase 1)
 - **Topología:** Un solo servicio Backend corriendo en un solo pod/servidor.
-- **Base de Datos:** Un solo cluster físico segregado en 5 esquemas (`discovery_schema`, `qa_schema`, etc.).
+- **Base de Datos:** Un solo cluster físico segregado por schema-per-context (the live map is derived by `.harness/scripts/doc-inventory.mjs` into `reference/specs/design/tracker-postgresql-data-design.md` §1.1).
 - **Comunicación Interna:** Llamadas a interfaces a través del *In-Memory Event Bus* (CQRS nativo en memoria).
 - **Frontend:** Microfrontends ya segregados por dominio (aprobado en T-002).
 

reference/specs/architecture/tracker-domain-model-overview.es.md

@@ -13,7 +13,7 @@
 
 ## 1. Propósito
 
-Este documento es la **vista única consolidada** del diseño de dominio de Evolith Tracker: el modelo conceptual, los 9 bounded contexts, sus agregados y value objects, y el diseño entidad-relación a través de los 10 schemas PostgreSQL (T-008).
+Este documento es la **vista única consolidada** del diseño de dominio de Evolith Tracker: el modelo conceptual, los 9 bounded contexts, sus agregados y value objects, y el diseño entidad-relación a través de los schemas PostgreSQL reales (`T-047`; el mapa vigente lo deriva del código `.harness/scripts/doc-inventory.mjs` y vive en `reference/specs/design/tracker-postgresql-data-design.es.md` §1.1).
 
 Sintetiza — nunca reemplaza — las fuentes canónicas:
 
@@ -139,7 +139,7 @@ Toda tabla (según [PostgreSQL Data Design §2](../design/tracker-postgresql-dat
 - Concurrencia optimista vía `xmin` (columna `version` explícita donde se requiera)
 - **Sin foreign keys entre schemas.** Las referencias entre contextos son UUIDs validados en la capa de aplicación — preservando la autonomía de cada contexto y habilitando la extracción a servicios en Fase 2.
 
-### 6.2 Cadena Core (5 schemas de compuertas)
+### 6.2 Cadena Core (5 schemas de compuertas) <!-- doc-inventory:ignore -->
 
 Líneas sólidas = FK intra-schema. Líneas punteadas = referencia UUID cross-schema (sin FK).
 

reference/specs/design/README.es.md

@@ -32,7 +32,7 @@
 
 | Documento | Descripción | Propósito | Tipo |
 |---|---|---|---|
-| [Modelo de Dominio Consolidado y E/R](../architecture/tracker-domain-model-overview.es.md) | El diseño DDD único y consolidado: modelo conceptual propuesto, los 9 bounded contexts, agregados, value objects y el diseño E/R de los 10 schemas | Fuente única del diseño de dominio propuesto — el detalle táctico por contexto se navega desde aquí | DDD |
+| [Modelo de Dominio Consolidado y E/R](../architecture/tracker-domain-model-overview.es.md) | El diseño DDD único y consolidado: modelo conceptual propuesto, los 9 bounded contexts, agregados, value objects y el diseño E/R de los schemas | Fuente única del diseño de dominio propuesto — el detalle táctico por contexto se navega desde aquí | DDD |
 
 </details>
 
@@ -46,7 +46,7 @@
 | [Arquitectura Objetivo (TAD)](./tracker-target-architecture.es.md) | Arquitectura técnica maestra: bounded contexts, modelo de dominio, CQRS, capas, despliegue | Referencia única para entender cómo se construye toda la aplicación Tracker | Arquitectura |
 | [Diseño Backend NestJS](./tracker-nestjs-backend-design.es.md) | Blueprint del backend: módulos, buses CQRS, repositorios, guards, middleware | Guiar a los desarrolladores backend al implementar cualquier bounded context | Backend |
 | [Diseño Frontend React](./tracker-react-frontend-design.es.md) | Blueprint del frontend: shell Module Federation + 7 remotes, estado Zustand/TanStack, routing | Guiar a los desarrolladores frontend al construir o extender un microfrontend | Frontend |
-| [Diseño de Datos PostgreSQL](./tracker-postgresql-data-design.es.md) | Diseño físico de datos: 10 schemas, DDL completo, políticas RLS, índices, control de concurrencia | Implementar o migrar la base de datos exactamente como fue aprobada | Datos |
+| [Diseño de Datos PostgreSQL](./tracker-postgresql-data-design.es.md) | Diseño físico de datos: mapa de schemas derivado, DDL completo, políticas RLS, índices, control de concurrencia | Implementar o migrar la base de datos exactamente como fue aprobada | Datos |
 
 </details>
 

reference/specs/design/README.md

@@ -32,7 +32,7 @@
 
 | Document | Description | Purpose | Type |
 |---|---|---|---|
-| [Consolidated Domain Model & E/R](../architecture/tracker-domain-model-overview.md) | The single consolidated DDD design: proposed conceptual model, the 9 bounded contexts, aggregates, value objects, and the E/R design across the 10 schemas | Single source for the proposed domain design — per-context tactical detail is navigated from here | DDD |
+| [Consolidated Domain Model & E/R](../architecture/tracker-domain-model-overview.md) | The single consolidated DDD design: proposed conceptual model, the 9 bounded contexts, aggregates, value objects, and the E/R design across the schemas | Single source for the proposed domain design — per-context tactical detail is navigated from here | DDD |
 
 </details>
 
@@ -46,7 +46,7 @@
 | [Target Architecture (TAD)](./tracker-target-architecture.md) | Master technical architecture: bounded contexts, domain model, CQRS, layers, deployment | Single reference to understand how the whole Tracker application is built | Architecture |
 | [NestJS Backend Design](./tracker-nestjs-backend-design.md) | Backend blueprint: module layout, CQRS buses, repositories, guards, middleware | Guide backend developers implementing any bounded context | Backend |
 | [React Frontend Design](./tracker-react-frontend-design.md) | Frontend blueprint: Module Federation shell + 7 remotes, Zustand/TanStack state, routing | Guide frontend developers building or extending a microfrontend | Frontend |
-| [PostgreSQL Data Design](./tracker-postgresql-data-design.md) | Physical data design: 10 schemas, full DDL, RLS policies, indexes, concurrency control | Implement or migrate the database exactly as approved | Data |
+| [PostgreSQL Data Design](./tracker-postgresql-data-design.md) | Physical data design: derived schema map, full DDL, RLS policies, indexes, concurrency control | Implement or migrate the database exactly as approved | Data |
 
 </details>
 

reference/specs/design/tracker-implementation-roadmap.es.md

@@ -69,7 +69,7 @@ Establecer el monorepo, pipeline CI/CD, primitivas de dominio compartidas e infr
 - [ ] Bootstrap de app API NestJS con TypeScript strict mode
 - [ ] App Web React con Vite + TanStack Query + Zustand
 - [ ] `libs/domain` compartido con clases base (`AggregateRoot`, `BaseDomainEvent`, `Result`)
-- [ ] 10 esquemas PostgreSQL creados con migraciones DDL
+- [ ] Esquemas PostgreSQL creados con migraciones DDL (el mapa vigente lo deriva `.harness/scripts/doc-inventory.mjs` en `reference/specs/design/tracker-postgresql-data-design.md` §1.1)
 - [ ] Políticas RLS configuradas para multi-tenancy
 - [ ] Pipeline CI GitHub Actions (lint, typecheck, test)
 - [ ] Docker Compose para desarrollo local

reference/specs/design/tracker-platform-implementation.es.md

@@ -109,7 +109,7 @@ Se crearon 7 archivos de migración en `src/apps/tracker-api/src/migrations/`:
 
 | Migración | Schemas/Tablas | Características Clave |
 |-----------|---------------|----------------------|
-| `0001-create-schemas.sql` | 10 schemas | `tracker_discovery`, `tracker_design`, `tracker_construction`, `tracker_qa`, `tracker_release`, `tracker_governance`, `tracker_artifacts`, `tracker_metrics`, `tracker_integration`, `tracker_audit` |
+| `0001-create-schemas.sql` | schemas | `tracker_discovery`, `tracker_design`, `tracker_construction`, `tracker_qa`, `tracker_release`, `tracker_governance`, `tracker_artifacts`, `tracker_metrics`, `tracker_integration`, `tracker_audit` |
 | `0002-create-governance-tables.sql` | 5 tablas | `satellite_products`, `sdlc_executions`, `phase_gate_states`, `exception_requests`, `outbox_messages` |
 | `0003-create-artifacts-tables.sql` | 3 tablas | `artifact_definitions`, `artifact_instances`, `evidence_records` |
 | `0004-create-integration-tables.sql` | 4 tablas | `core_evaluation_transactions`, `integration_endpoints`, `sync_records`, `acl_adapters` |