Promote develop to main — the Core↔Tracker integration backend, closed end to end

.bmad-core/deliverables/prd.es.md

@@ -174,30 +174,48 @@ La CLI es una interfaz de primera clase — cada capacidad disponible en la Apli
 
 ### 5.3 Servidor MCP — Integración Directa de Agentes IA
 
-El Servidor MCP de Evolith Tracker es la superficie de integración que hace posible el SDLC AI-Native. Expone el Tracker como un conjunto de herramientas MCP que cualquier agente IA compatible con MCP (Claude Code, agentes BMAD personalizados) puede llamar directamente desde dentro de su contexto de ejecución.
+> [!IMPORTANT]
+> **Superado por [`T-052`](../../docs/adrs/T-052-gateway-consumes-core-single-mcp.es.md) (COH-006, COH-007).**
+> Esta sección describía un servidor MCP hospedado por el Tracker con seis tools `tracker_*`. Se
+> construyeron (`c5f3a50`), se recablearon al BFF (`293e3de`, `T-051`) y después se **eliminaron**
+> (`614ddff`) cuando `T-052` decidió que el `evolith-mcp` del Core es la única superficie MCP de
+> cara a agentes. La visión sigue siendo válida; la topología no. Se conserva el texto porque el
+> requisito que enuncia es real y el lector necesita saber dónde se sirve ahora.
+
+La superficie de integración que hace posible un SDLC AI-Native es un servidor MCP que cualquier
+agente compatible (Claude Code, agentes BMAD personalizados) pueda llamar desde su contexto de
+ejecución. **Ese servidor es el `evolith-mcp` del Core, no uno del Tracker.** El `tracker-gateway`
+lo reexpone como REST en `/api/core-mcp/tools` y `/api/core-mcp/call` para que un consumidor no
+tenga que hablar el protocolo MCP.
 
 **La Visión de Integración MCP:**
 
-Un Agente Arquitecto BMAD ejecutándose en Claude Code no necesita abrir un navegador ni cambiar de contexto para interactuar con Evolith Tracker. Se conecta al Servidor MCP del Tracker y puede:
+Un Agente Arquitecto BMAD ejecutándose en Claude Code no necesita abrir un navegador ni cambiar de
+contexto para interactuar con Evolith Tracker. Se conecta a la superficie MCP y puede:
 
 1. **Verificar su asignación actual** — ¿en qué iniciativa y fase está trabajando?
 2. **Leer la spec aprobada** — obtener la spec de Diseño actual y las restricciones de ADR upstream
 3. **Enviar un entregable** — subir un contrato OpenAPI o ADR al Tracker
 4. **Consultar el estado de compuerta** — ¿el entregable actual está aprobado o necesita revisión?
-5. **Recibir feedback** — obtener respuestas estructuradas de compuerta (aprobado/rechazado + razones) sin salir del contexto
+5. **Recibir feedback** — obtener respuestas estructuradas de compuerta sin salir del contexto
 
-**Categorías de Herramientas MCP:**
+**Dónde viven ahora esas cinco capacidades.** Cada una la sirve el BFF `tracker-api`, que posee el
+estado de Plano 1 que el Core no conoce —estado de compuerta, asignaciones, evidencia—, y el MCP del
+Core para todo lo upstream. Los seis nombres `tracker_*` de abajo son **históricos** y ya no
+resuelven: una petición a `POST /api/mcp/tracker_get_assignment` devuelve `404`.
 
-| Categoría de Herramienta | Propósito |
+| Tool retirada (`T-052`) | Capacidad, y dónde se sirve ahora |
 | :--- | :--- |
-| `tracker_get_assignment` | Devuelve la tarea asignada actual para un rol de agente dado |
-| `tracker_read_spec` | Devuelve los artefactos de spec relevantes para la fase actual |
-| `tracker_submit_deliverable` | Envía un artefacto entregable para evaluación de compuerta |
-| `tracker_get_gate_status` | Devuelve el estado de compuerta actual para una iniciativa y fase |
-| `tracker_log_activity` | Registra la actividad del agente para la pista de auditoría |
-| `tracker_get_upstream_constraints` | Devuelve los ADRs de Evolith Core activos aplicables a la fase actual |
-
-**Principio de Integración MCP:** El Tracker es la autoridad. El agente recibe instrucciones del Tracker, no al revés. Un agente no puede auto-asignarse, saltarse una compuerta ni anular una restricción upstream vía MCP.
+| `tracker_get_assignment` | Modelos de lectura de asignación en el BFF `tracker-api` |
+| `tracker_read_spec` | `/design/blueprints/*` y los modelos de lectura de evidencia |
+| `tracker_submit_deliverable` | Caminos de escritura de artefacto y evidencia en el BFF |
+| `tracker_get_gate_status` | `GET /gates/{sdlcExecutionId}/phase/{phase}` |
+| `tracker_log_activity` | El camino de escritura de la entrada de auditoría |
+| `tracker_get_upstream_constraints` | `GET /architecture/topologies`, fachada sobre el Core |
+
+**Principio de Integración MCP:** El Tracker es la autoridad sobre su propio plano. El agente recibe
+instrucciones del Tracker, no al revés. Un agente no puede auto-asignarse, saltarse una compuerta ni
+anular una restricción upstream.
 
 ---
 

.bmad-core/deliverables/prd.md

@@ -224,30 +224,48 @@ The CLI is a first-class interface — every capability available in the Web App
 
 ### 5.3 MCP Server — AI Agent Direct Integration
 
-The Evolith Tracker MCP Server is the integration surface that makes AI-native SDLC possible. It exposes the Tracker as a set of MCP tools that any MCP-compatible AI agent (Claude Code, custom BMAD agents) can call directly from within their execution context.
+> [!IMPORTANT]
+> **Superseded by [`T-052`](../../docs/adrs/T-052-gateway-consumes-core-single-mcp.md) (COH-006, COH-007).**
+> This section described a Tracker-hosted MCP server exposing six `tracker_*` tools. They were
+> built (`c5f3a50`), rebound to the BFF (`293e3de`, `T-051`) and then **deleted** (`614ddff`)
+> when `T-052` decided the Core's `evolith-mcp` is the single agent-facing MCP surface. The
+> vision below still holds; the topology does not. Left in place rather than removed because the
+> requirement it states is real and the reader needs to know where it is now served.
+
+The integration surface that makes an AI-native SDLC possible is an MCP server that any
+MCP-compatible agent (Claude Code, custom BMAD agents) can call from inside its execution context.
+**That server is the Core's `evolith-mcp`, not a Tracker-hosted one.** The `tracker-gateway`
+re-exposes it over REST at `/api/core-mcp/tools` and `/api/core-mcp/call` so a consumer need not
+speak the MCP wire protocol.
 
 **The MCP Integration Vision:**
 
-A BMAD Architect Agent running in Claude Code does not need to open a browser or switch context to interact with Evolith Tracker. It connects to the Tracker's MCP Server and can:
+A BMAD Architect Agent running in Claude Code does not need to open a browser or switch context to
+interact with Evolith Tracker. It connects to the MCP surface and can:
 
 1. **Check its current assignment** — what initiative and phase is it working on?
 2. **Read the approved spec** — get the current Design spec and upstream ADR constraints
 3. **Submit a deliverable** — push an OpenAPI contract or ADR to the Tracker
 4. **Query gate status** — is the current deliverable approved or does it need revision?
 5. **Receive feedback** — get structured gate feedback (pass/fail + reasons) without leaving context
 
-**MCP Tool Categories:**
+**Where those five capabilities live now.** Each is served by the `tracker-api` BFF, which owns the
+Plane-1 state the Core has no concept of — gate status, assignments, evidence — and by the Core's
+MCP for everything upstream. The six `tracker_*` tool names below are **historical** and no longer
+resolve; a request to `POST /api/mcp/tracker_get_assignment` returns `404`.
 
-| Tool Category | Purpose |
+| Retired tool (`T-052`) | Capability, and where it is served now |
 | :--- | :--- |
-| `tracker_get_assignment` | Returns the current assigned task for a given agent role |
-| `tracker_read_spec` | Returns the relevant spec artifacts for the current phase |
-| `tracker_submit_deliverable` | Submits a deliverable artifact for gate evaluation |
-| `tracker_get_gate_status` | Returns the current gate status for an initiative and phase |
-| `tracker_log_activity` | Logs agent activity for audit trail |
-| `tracker_get_upstream_constraints` | Returns the active Evolith Core ADRs applicable to the current phase |
-
-**MCP Integration Principle:** The Tracker is authoritative. The agent receives instructions from the Tracker, not the reverse. An agent cannot self-assign, skip a gate, or override an upstream constraint via MCP.
+| `tracker_get_assignment` | Assignment read models on the `tracker-api` BFF |
+| `tracker_read_spec` | `/design/blueprints/*` and the evidence read models |
+| `tracker_submit_deliverable` | Artifact and evidence write paths on the BFF |
+| `tracker_get_gate_status` | `GET /gates/{sdlcExecutionId}/phase/{phase}` |
+| `tracker_log_activity` | The audit-entry write path |
+| `tracker_get_upstream_constraints` | `GET /architecture/topologies`, itself a facade over the Core |
+
+**MCP Integration Principle:** The Tracker is authoritative over its own plane. The agent receives
+instructions from the Tracker, not the reverse. An agent cannot self-assign, skip a gate, or
+override an upstream constraint.
 
 ---
 

.bmad-core/deliverables/ux-concept.es.md

@@ -2,6 +2,15 @@
 
 > **Bilingual Navigation:** [English Version](./ux-concept.md)
 
+> [!NOTE]
+> **Los nombres de tools de abajo son históricos (`T-052`, COH-006/COH-007).** Las seis tools MCP
+> `tracker_*` se eliminaron cuando [`T-052`](../../docs/adrs/T-052-gateway-consumes-core-single-mcp.es.md)
+> convirtió el `evolith-mcp` del Core en la única superficie MCP de cara a agentes; el
+> `tracker-gateway` la reexpone en `/api/core-mcp/*`. Las capacidades descritas son reales y las
+> sirve el BFF `tracker-api`: lo que desapareció es el transporte. Se conserva el texto para que el
+> requisito no se pierda.
+
+
 > **Documento BMAD:** Visión UX Conceptual · Entregable del PM/PO
 > **Estado:** Aprobado para Revisión de Arquitectura
 > **Entrada:** [PRD](./prd.es.md)

.bmad-core/deliverables/ux-concept.md

@@ -2,6 +2,14 @@
 
 > **Bilingual Navigation:** [Versión en Español](./ux-concept.es.md)
 
+> [!NOTE]
+> **Tool names below are historical (`T-052`, COH-006/COH-007).** The six `tracker_*` MCP tools
+> were deleted when [`T-052`](../../docs/adrs/T-052-gateway-consumes-core-single-mcp.md) made the
+> Core's `evolith-mcp` the single agent-facing MCP surface; the `tracker-gateway` re-exposes it at
+> `/api/core-mcp/*`. The capabilities described here are real and served by the `tracker-api` BFF —
+> only the transport named below is gone. Kept rather than deleted so the requirement survives.
+
+
 > **BMAD Document:** UX Conceptual Vision · PM/PO Deliverable
 > **Status:** Approved for Architecture Review
 > **Input:** [PRD](./prd.md)

.github/workflows/ci.yml

@@ -235,3 +235,35 @@ jobs:
 
       - name: Board y catalogo deben contar lo mismo
         run: python3 .harness/scripts/check-gap-registry.py
+
+      # GT-435 — hasta el 2026-08-02 este repositorio publicaba TRES Dockerfiles y CERO
+      # imagenes: ningun workflow los construia, mientras los charts referenciaban
+      # `evolith-tracker-api:0.0.1`, `...-web:0.0.1` y `evolith-tracker-gateway:local`, este
+      # ultimo un tag que ningun registro puede servir. El camino de despliegue no estaba sin
+      # probar: estaba sin cablear. Nada habia tirado nunca de esas imagenes, asi que ningun
+      # CI en verde podia revelarlo.
+      - name: Los charts piden imagenes que este repositorio produce
+        run: node .harness/scripts/check-deployable-images.mjs
+
+      # El paso anterior contrasta ademas el REGISTRO, la tercera superficie, anadida el
+      # 2026-08-01: board y catalogo llevaban sincronizados desde que existe el guard y
+      # nadie miraba el registro, que comparte el mismo espacio de ids. De los 34 ids
+      # comunes, CINCO se contradecian. Estas pruebas son negativas: comprueban que el
+      # contraste se pone rojo cuando debe, no que exista.
+      - name: Self-tests for the board/registro contrast
+        run: python3 .harness/scripts/check-gap-registry.test.py
+
+      # Las fichas del board recogen hallazgos de auditoria y nada las vuelve a
+      # contrastar con el codigo, asi que envejecen en silencio mientras siguen
+      # dirigiendo prioridades. El 2026-08-01 se encontraron CINCO reclamando trabajo ya
+      # hecho. Este guard re-comprueba las afirmaciones que una maquina puede falsar.
+      #
+      # No lee la prosa de las filas, a proposito: el `50-validate-gap-claim` del Core ya
+      # probo esa via, produjo nueve atribuciones falsas en un dia y enseno a los autores
+      # a borrar frases verdaderas. Aqui solo se comprueba lo que alguien escribio como
+      # DATO en `falsifiable-claims.json`.
+      - name: Board claims still hold against the code
+        run: node .harness/scripts/check-falsifiable-claims.mjs
+
+      - name: Self-tests for the falsifiable-claim guard
+        run: node --test .harness/scripts/check-falsifiable-claims.test.mjs

.github/workflows/docs.yml

@@ -30,6 +30,18 @@ jobs:
       - name: Check bilingual parity
         run: node .harness/scripts/check-bilingual-parity.mjs
 
+      # `check-bilingual-parity` compara que el par EXISTA y que las cabeceras cuadren.
+      # Ninguna de las dos cosas ve el IDIOMA, asi que un fichero copiado, reetiquetado
+      # «English (this document)» y dejado en castellano lo pasa — que es exactamente el
+      # estado que describen GAP-011 y GAP-017, y por eso ambas filas seguian siendo
+      # ciertas con la paridad en verde. Medido el 2026-08-01: 9 de 151, incluidos
+      # DECISIONS.md y MASTER_INDEX.md.
+      #
+      # Va como TRINQUETE: los nueve estan declarados con su motivo en
+      # `untranslated-allowlist.json`, asi que hoy pasa; el decimo falla.
+      - name: English-labelled documents actually read as English
+        run: node .harness/scripts/check-translation-language.mjs
+
       - name: Validate root cleanliness
         run: node .harness/scripts/validate-root-cleanliness.mjs