beyondnetcode · beyondnetPeru · Jul 27, 2026 · Jul 27, 2026 · Jul 27, 2026 · Jul 27, 2026
@@ -7802,3 +7802,16 @@ Serie histórica de gaps registrada en el antiguo `gap-analysis-core.es.md`, pre
 - **Procedencia:** Diagnóstico de producto de Evolith, 2026-07-26 (https://github.com/beyondnetcode/why-architecture/blob/main/docs/evolith-diagnostico-es.md) — cinco evaluadores por componente. Los hallazgos se cruzaron contra el tablero y éste no estaba mapeado. Cada fila declara si se verificó aquí contra el código o si se registra tal como lo reporta el diagnóstico.
 - **Criterios de aceptación:**
   - [ ] El defecto descrito ya no es reproducible, demostrado por un test que falla sin el arreglo.
+
+#### GT-622
+
+**Título:** Ochenta y dos análisis huérfanos de code scanning hacen que cada PR avise de una configuración muerta en junio
+
+- **Propósito:** Que ningún PR arrastre un check rojo permanente que no describe un defecto — y que el rojo vuelva a significar algo.
+- **Evidencia:** **Cada pull request arrastra un check `CodeQL` en rojo que dice "1 configuration not found", y no es un hallazgo de seguridad — es contabilidad huérfana.** GitHub conserva **82 análisis de code scanning** en `refs/heads/main` bajo la clave `.github/workflows/ci.yml:codeql`. Esa configuración existió de verdad: el commit `87f50ce3` añadió un job `codeql` a `ci.yml`, y `f50030cd` lo quitó el 2026-06-06 al vaciar ese workflow — el último análisis bajo esa clave es de ese mismo día. Como la configuración sigue *registrada* en `main` pero nada la produce, GitHub la reporta como ausente en cada PR. Lleva así 51 días. Verificado: `code-scanning/analyses?ref=refs/heads/main` devuelve tres claves — `ci.yml:codeql` (82, último 2026-06-06), `sdk-cli-ci.yml:codeql-analysis` (159, al día) y `sdk-cli-ci.yml:trivy-scan` (159, al día). El escaneo que importa está sano; `CodeQL SAST` pasa y es check requerido. **El workflow muerto ya está eliminado** (corría un job `Disabled` que sólo hacía `echo`, en cada PR y push a `main` y `develop`); borrar el fichero NO limpia la configuración registrada, y por eso existe esta fila. **La acción restante queda deliberadamente sin automatizar:** eliminar los 82 análisis vía `DELETE /repos/{owner}/{repo}/code-scanning/analyses/{id}` es irreversible y destruye historial de code scanning de una rama protegida. Su valor histórico es nulo —describen una configuración muerta desde junio— pero tirar historial de escaneo de seguridad es decisión del dueño, no de la herramienta. **Por qué importa más allá del ruido:** un check permanentemente rojo enseña a los revisores a descontar los checks rojos, y `CodeQL SAST` —que comparte el nombre CodeQL y SÍ es requerido— es precisamente el check que nadie se puede permitir aprender a ignorar.
+- **Componente:** `Infra` · **Criticidad:** P2 · **Complejidad:** XS
+- **Procedencia:** Diagnosticado el 2026-07-27 al revisar por qué `CodeQL` salía rojo en el PR #217. La parte reversible (borrar el workflow muerto `.github/workflows/ci.yml`) se hizo en ese mismo commit; la irreversible se registra aquí en vez de ejecutarse.
+- **Criterios de aceptación:**
+  - [ ] `gh pr checks` sobre un PR nuevo no muestra ningún check `CodeQL` reportando "configuration not found".
+  - [ ] Las únicas claves de análisis en `refs/heads/main` son las dos que produce `sdk-cli-ci.yml`.
+  - [ ] `CodeQL SAST` sigue pasando y sigue siendo check requerido — la limpieza no debe tocar el escaneo que funciona.
@@ -7897,3 +7897,16 @@ Historical gap series tracked in the former `gap-analysis-core.md`, preserved fo
 - **Provenance:** Evolith product diagnostic, 2026-07-26 (https://github.com/beyondnetcode/why-architecture/blob/main/docs/evolith-diagnostico-es.md) — five per-component evaluators. Findings were cross-mapped against this board and this one was not covered. Each row states whether it was verified here against the code or is recorded as the diagnostic reports it.
 - **Acceptance criteria:**
   - [ ] The described defect is no longer reproducible, demonstrated by a test that fails without the fix.
+
+#### GT-622
+
+**Title:** Eighty-two orphaned code-scanning analyses keep every PR warning about a configuration that died in June
+
+- **Purpose:** Stop every PR carrying a permanently red check that describes no defect — and make red mean something again.
+- **Evidence:** **Every pull request carries a red `CodeQL` check reading "1 configuration not found", and it is not a security finding — it is orphaned bookkeeping.** GitHub still has **82 code-scanning analyses** on `refs/heads/main` under the analysis key `.github/workflows/ci.yml:codeql`. That configuration was real: commit `87f50ce3` added a `codeql` job to `ci.yml`, and `f50030cd` removed it on 2026-06-06 while gutting that workflow — the last analysis under the key is from that same day. Because the configuration is still *recorded* on `main` but nothing produces it, GitHub reports it missing on every PR. It has done so for 51 days. Verified: `code-scanning/analyses?ref=refs/heads/main` returns three analysis keys — `ci.yml:codeql` (82, last 2026-06-06), `sdk-cli-ci.yml:codeql-analysis` (159, current) and `sdk-cli-ci.yml:trivy-scan` (159, current). The scanning that matters is healthy; `CodeQL SAST` passes and is a required check. **The dead workflow itself is already deleted** (it ran a no-op `Disabled` job on every PR and push to `main` and `develop`); deleting the file does NOT clear the recorded configuration, which is why this row exists. **The remaining action is deliberately not automated:** removing the 82 analyses via `DELETE /repos/{owner}/{repo}/code-scanning/analyses/{id}` is irreversible and destroys code-scanning history on a protected branch. Their historical value is nil — they describe a configuration dead since June — but discarding security-scan history is an owner decision, not a tooling one. **Why it matters beyond the noise:** a permanently red check trains reviewers to discount red checks, and `CodeQL SAST` — which shares the CodeQL name and IS required — is exactly the check nobody can afford to learn to ignore.
+- **Component:** `Infra` · **Criticality:** P2 · **Complexity:** XS
+- **Provenance:** Diagnosed on 2026-07-27 while investigating why `CodeQL` was red on PR #217. The reversible half (deleting the dead `.github/workflows/ci.yml`) landed in that same commit; the irreversible half is registered here instead of executed.
+- **Acceptance criteria:**
+  - [ ] `gh pr checks` on a fresh PR shows no `CodeQL` check reporting "configuration not found".
+  - [ ] The only analysis keys on `refs/heads/main` are the two produced by `sdk-cli-ci.yml`.
+  - [ ] `CodeQL SAST` still passes and is still a required check — the cleanup must not touch the scanning that works.
@@ -13,6 +13,7 @@ Este tablero es la única fuente de verdad para deuda técnica, gaps, oportunida
 
 | ID | Gap | Qué significa | Ejemplo | Componente | Fase | Criticidad | Complejidad | Estado |
 |---|---|---|---|:---:|:---:|:---:|:---:|:---:|
+| [`GT-622`](./gap-reference-catalog.es.md#gt-622) | **Cada pull request arrastra un check `CodeQL` en rojo que dice "1 configuration not found", y no es un hallazgo de seguridad — es contabilidad huérfana.** GitHub conserva **82 análisis de code scanning** en `refs/heads/main` bajo la clave `.github/workflows/ci.yml:codeql`. Esa configuración existió de verdad: el commit `87f50ce3` añadió un job `codeql` a `ci.yml`, y `f50030cd` lo quitó el 2026-06-06 al vaciar ese workflow — el último análisis bajo esa clave es de ese mismo día. Como la configuración sigue *registrada* en `main` pero nada la produce, GitHub la reporta como ausente en cada PR. Lleva así 51 días. Verificado: `code-scanning/analyses?ref=refs/heads/main` devuelve tres claves — `ci.yml:codeql` (82, último 2026-06-06), `sdk-cli-ci.yml:codeql-analysis` (159, al día) y `sdk-cli-ci.yml:trivy-scan` (159, al día). El escaneo que importa está sano; `CodeQL SAST` pasa y es check requerido. **El workflow muerto ya está eliminado** (corría un job `Disabled` que sólo hacía `echo`, en cada PR y push a `main` y `develop`); borrar el fichero NO limpia la configuración registrada, y por eso existe esta fila. **La acción restante queda deliberadamente sin automatizar:** eliminar los 82 análisis vía `DELETE /repos/{owner}/{repo}/code-scanning/analyses/{id}` es irreversible y destruye historial de code scanning de una rama protegida. Su valor histórico es nulo —describen una configuración muerta desde junio— pero tirar historial de escaneo de seguridad es decisión del dueño, no de la herramienta. **Por qué importa más allá del ruido:** un check permanentemente rojo enseña a los revisores a descontar los checks rojos, y `CodeQL SAST` —que comparte el nombre CodeQL y SÍ es requerido— es precisamente el check que nadie se puede permitir aprender a ignorar. |  |  | `Infra` | Cross | P2 | XS | `PENDIENTE` |
 | [`GT-609`](./gap-reference-catalog.es.md#gt-609) | **Fuga de autorización en la superficie de descubrimiento.** `mcp-cache.service.ts:8` declara `toolsList: 'mcp:tools:list'` — una única clave literal, sin principal, tenant ni scope — y la lista se cachea ANTES de aplicar el filtro de scope. Así que el primer llamador que calienta la caché decide el inventario que ven todos los siguientes durante el TTL: un admin que la caliente publica el inventario con capacidad de escritura a los lectores. **Verificado aquí contra el código.** Fix: indexar la caché por principal (hash de scopes + tenant), o eliminarla — una superficie de descubrimiento que responde con la vista de otro principal es peor que una sin caché. Origen: hallazgo 4.2 del diagnóstico de producto (https://github.com/beyondnetcode/why-architecture/blob/main/docs/evolith-diagnostico-es.md). |  |  | `MCP Server` | Cross | P0 | S | `PENDIENTE` |
 | [`GT-610`](./gap-reference-catalog.es.md#gt-610) | **La peor clase de fallo posible para un producto de auditoría: la acción correcta, registrada, ejecutada con las entradas equivocadas.** Los tres motores rellenan `proposedArguments` — `swarms-agent.adapter.ts:99`, `hermes-agent.adapter.ts:98`, `stub-agent-engine.adapter.ts:46` — y el servicio lee sólo `plan.proposedTool` (`agent-runtime.service.ts:168-169`). Los argumentos propuestos se calculan, cruzan el puerto y se tiran; la skill se ejecuta con lo que hubiera en `request.parameters`. **Verificado aquí contra el código.** Fix: fusionar los argumentos propuestos con revalidación contra el contrato de entrada declarado por la skill antes de ejecutar, y registrar en la traza qué conjunto se usó. Origen: hallazgo 5.5 del diagnóstico de producto (https://github.com/beyondnetcode/why-architecture/blob/main/docs/evolith-diagnostico-es.md). |  |  | `agent-runtime` | Cross | P0 | S | `PENDIENTE` |
 | [`GT-611`](./gap-reference-catalog.es.md#gt-611) | **Más amplio de lo que reportó el diagnóstico, y más amplio de lo que arregló GT-571.** Los prompts no viven en cada comando: pasan por el `src/sdk/cli/src/infrastructure/prompts/prompt.service.ts` compartido, que consumen `init`, `validate`, `upgrade`, `phase-advance`, `adr`, `waiver`, `chat`, `enforce`, `agents` y más (`profile.command.ts` importa `@clack/prompts` directamente). **Verificado aquí contra el código.** GT-571 le dio a `init` un contrato no-interactivo definido — un stdin cerrado no pregunta, el fallo fija exit code distinto de cero, `--format json` emite un envelope parseable y nada más — y dejó a los demás consumidores como estaban. Un paso de CI que canalice cualquiera de ellos a `jq` sigue recibiendo un menú ANSI y leyendo exit 0. Fix: imponer el contrato máquina en la frontera del `PromptService` y no comando a comando, de modo que un stdin no-TTY no pueda producir un prompt en ningún sitio, y añadir un test de superficie que lo asserte para cada comando registrado. Origen: hallazgo 3.1 del diagnóstico de producto (https://github.com/beyondnetcode/why-architecture/blob/main/docs/evolith-diagnostico-es.md). |  |  | `Evolith CLI` | Cross | P1 | M | `PENDIENTE` |
@@ -636,7 +637,7 @@ Este tablero es la única fuente de verdad para deuda técnica, gaps, oportunida
 | [`GT-246`](./gap-reference-catalog.es.md#gt-246) | Implementar experimentos Chaos Mesh/Litmus |  |  | `QA` | Cross | P3 | L | `COMPLETADO` |
 
 
-**Progreso:** 561 / 621 completados · 9 en progreso · 47 pendientes · 4 diferidos
+**Progreso:** 561 / 622 completados · 9 en progreso · 48 pendientes · 4 diferidos
 
 **Oleada 2026-06-23 (auditoría profunda de Winston III):** Añadidos 14 gaps nuevos `GT-212`…`GT-225` del Winston Audit Playbook que cubren: higiene de estado ADR (GT-212), metadata + presupuestos operativos + corpus de guías por topología (GT-213, GT-217, GT-219), observabilidad + OpenAPI en controladores REST (GT-214, GT-215), paridad de input-schemas OPA + densidad de tests por topología (GT-216, GT-222), plantillas de rollback + on-call de Fase 05 (GT-218), cobertura de ramas CLI + paridad de envelope --format + limpieza de skip-list (GT-220, GT-224, GT-225), audit logging HTTP de MCP (GT-221), y tests e2e de paridad cross-surface (GT-223).
 

@@ -13,6 +13,7 @@ This board is the single source of truth for technical debt, gaps, opportunities
 
 | ID | Gap | What it means | Example | Component | Phase | Criticality | Complexity | Status |
 |---|---|---|---|:---:|:---:|:---:|:---:|:---:|
+| [`GT-622`](./gap-reference-catalog.md#gt-622) | **Every pull request carries a red `CodeQL` check reading "1 configuration not found", and it is not a security finding — it is orphaned bookkeeping.** GitHub still has **82 code-scanning analyses** on `refs/heads/main` under the analysis key `.github/workflows/ci.yml:codeql`. That configuration was real: commit `87f50ce3` added a `codeql` job to `ci.yml`, and `f50030cd` removed it on 2026-06-06 while gutting that workflow — the last analysis under the key is from that same day. Because the configuration is still *recorded* on `main` but nothing produces it, GitHub reports it missing on every PR. It has done so for 51 days. Verified: `code-scanning/analyses?ref=refs/heads/main` returns three analysis keys — `ci.yml:codeql` (82, last 2026-06-06), `sdk-cli-ci.yml:codeql-analysis` (159, current) and `sdk-cli-ci.yml:trivy-scan` (159, current). The scanning that matters is healthy; `CodeQL SAST` passes and is a required check. **The dead workflow itself is already deleted** (it ran a no-op `Disabled` job on every PR and push to `main` and `develop`); deleting the file does NOT clear the recorded configuration, which is why this row exists. **The remaining action is deliberately not automated:** removing the 82 analyses via `DELETE /repos/{owner}/{repo}/code-scanning/analyses/{id}` is irreversible and destroys code-scanning history on a protected branch. Their historical value is nil — they describe a configuration dead since June — but discarding security-scan history is an owner decision, not a tooling one. **Why it matters beyond the noise:** a permanently red check trains reviewers to discount red checks, and `CodeQL SAST` — which shares the CodeQL name and IS required — is exactly the check nobody can afford to learn to ignore. |  |  | `Infra` | Cross | P2 | XS | `PENDING` |
 | [`GT-609`](./gap-reference-catalog.md#gt-609) | **Authorization leak in the discovery surface.** `mcp-cache.service.ts:8` declares `toolsList: 'mcp:tools:list'` — a single literal key, with no principal, tenant or scope in it — and the list is cached BEFORE the scope filter runs. So the first caller to warm the cache decides the inventory every subsequent caller sees for the TTL: an admin warming it publishes the write-capable inventory to readers. **Verificado aquí contra el código.** Fix: key the cache by principal (a hash of scopes + tenant), or delete the cache — a discovery surface that answers from another principal's view is worse than an uncached one. Origin: finding 4.2 of the product diagnostic (https://github.com/beyondnetcode/why-architecture/blob/main/docs/evolith-diagnostico-es.md). |  |  | `MCP Server` | Cross | P0 | S | `PENDING` |
 | [`GT-610`](./gap-reference-catalog.md#gt-610) | **The worst failure class available to an audit product: the right action, recorded, executed with the wrong inputs.** All three engines populate `proposedArguments` — `swarms-agent.adapter.ts:99`, `hermes-agent.adapter.ts:98`, `stub-agent-engine.adapter.ts:46` — and the service reads only `plan.proposedTool` (`agent-runtime.service.ts:168-169`). The proposed arguments are computed, carried across the port, and dropped on the floor; the skill then runs with whatever `request.parameters` held. **Verificado aquí contra el código.** Fix: merge the proposed arguments with revalidation against the skill's declared input contract before execution, and record which set was used in the trace. Origin: finding 5.5 of the product diagnostic (https://github.com/beyondnetcode/why-architecture/blob/main/docs/evolith-diagnostico-es.md). |  |  | `agent-runtime` | Cross | P0 | S | `PENDING` |
 | [`GT-611`](./gap-reference-catalog.md#gt-611) | **Broader than the diagnostic reported, and broader than what GT-571 fixed.** Prompts do not live in individual commands: they go through the shared `src/sdk/cli/src/infrastructure/prompts/prompt.service.ts`, which is consumed by `init`, `validate`, `upgrade`, `phase-advance`, `adr`, `waiver`, `chat`, `enforce`, `agents` and more (`profile.command.ts` imports `@clack/prompts` directly). **Verificado aquí contra el código.** GT-571 gave `init` a defined non-interactive contract — closed stdin does not prompt, failure sets a non-zero exit code, `--format json` emits a parseable envelope and nothing else — and left every other consumer as it was. A CI step that pipes any of them into `jq` still receives an ANSI menu and reads exit 0. Fix: enforce the machine contract at the `PromptService` boundary rather than per command, so a non-TTY stdin can never produce a prompt anywhere, and add a surface-wide test that asserts it for every registered command. Origin: finding 3.1 of the product diagnostic (https://github.com/beyondnetcode/why-architecture/blob/main/docs/evolith-diagnostico-es.md). |  |  | `Evolith CLI` | Cross | P1 | M | `PENDING` |
@@ -636,7 +637,7 @@ This board is the single source of truth for technical debt, gaps, opportunities
 | [`GT-246`](./gap-reference-catalog.md#gt-246) | Implement Chaos Mesh/Litmus experiments |  |  | `QA` | Cross | P3 | L | `DONE` |
 
 
-**Progress:** 561 / 621 done · 9 in progress · 47 pending · 4 deferred
+**Progress:** 561 / 622 done · 9 in progress · 48 pending · 4 deferred
 
 **Wave 2026-06-23 (Winston deep audit III):** Added 14 new gaps `GT-212`…`GT-225` from the Winston Audit Playbook covering: ADR status hygiene (GT-212), topology manifest metadata + operational budgets + guidance corpus (GT-213, GT-217, GT-219), REST controller observability + OpenAPI (GT-214, GT-215), OPA input-schema parity + per-topology test density (GT-216, GT-222), SDLC Phase 05 rollback + on-call templates (GT-218), CLI branch coverage + envelope format coverage + skip-list cleanup (GT-220, GT-224, GT-225), MCP HTTP audit logging (GT-221), and cross-surface parity e2e tests (GT-223).