fix(mcp-server): las capas del guard nombraban carpetas que no existen

[beyondnetPeru]

Pull Request Summary

El descriptor de elementos de mcp-server describía una arquitectura que no estaba en disco. Salió a la luz al migrar los guards a eslint-plugin-boundaries v7 (#653), y se separó a propósito para no mezclar un hallazgo con una migración que preservaba comportamiento.

Declaraba los tipos application y core apuntando a src/application y src/core, que no existen: sus patrones no casaban con nada, así que sus políticas eran letra muerta. A la vez src/common y src/utils — que sí existen, y de los que importan mcp (10 ficheros) y tools (7) — no tenían descriptor, así que sus ficheros quedaban sin clasificar (type: null) y boundaries/dependencies no gobernaba ni un solo import hacia ellos ni desde ellos.

Una capa nombrada que no es una carpeta no es una aspiración inofensiva: es una regla que no puede dispararse.

Qué cambia

• Fuera application y core — no existen.
• Dentro common y utils, cada uno permitido solo a sí mismo. Verificado: ninguno importa nada local fuera de su carpeta, solo relativos internos y paquetes externos (@nestjs/common, node:crypto, node:path, pino). La política describe la realidad en vez de aspirar a ella.
• mcp gana common; tools gana common y utils. resources y watcher no: hoy no importan de ahí, y el guard debe obligar a decidirlo conscientemente el día que haga falta.
• src/test-doubles no es una capa: está excluido del tsconfig y solo se cablea por el moduleNameMapper de jest, así que nunca entra en el grafo compilado. Pasa a la lista de ignorados, no a un tipo.

Medido, no razonado

Una config de boundaries mal puesta falla abierta: no reporta nada y sale 0. Así que la evidencia es una matriz sobre cada par ordenado de capas (destino directo en la carpeta y anidado, en forma valor y import type): 98 canarios, 32 pares que deben bloquear.

Config	Bloqueos observados	Divergencias vs lo declarado
anterior (la de main)	13 de 32	19
nueva (este PR)	32 de 32	0

Los 19 huecos involucraban todos a common o utils — exactamente las carpetas sin clasificar. Ejemplos que pasaban mudos: common → mcp, common → tools, watcher → common, resources → utils.

Además: el código real sigue verde (npm run lint:boundaries exit 0), y los únicos ficheros que quedan sin clasificar son los tres de arranque (app.module.ts, main.ts, tracing.ts) — la raíz de composición, que cablea todo por definición: darles una capa exigiría un allow-all que no aplicaría nada. Los canarios se borraron.

Before you submit

• Sign-off (DCO): my commits carry a Signed-off-by line.
• Conventional Commits: my PR title and commits follow Conventional Commits.
• Agnosticism: no introduce ninguna dependencia tecnológica — es una config de lint ya existente.
• Bilingual: no aplica — no toqué ninguno de los dieciséis documentos de la superficie de entrada.

Linked ADRs / Issues

• Link to ADR: n/a — no cambia ninguna decisión de arquitectura; hace que la que ya estaba escrita se pueda aplicar.
• Link to Issue: sale de chore(lint): migra los tres guards de boundaries a la sintaxis v7 #653 (migración de eslint-plugin-boundaries a v7), donde se detectó y se dejó fuera a propósito.

🤖 Generated with Claude Code

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

[github-actions]

📊 Bilingual Coverage Impact

PR Changes

• Paired EN/ES files modified: 0
• New EN files needing ES translation: 0

Repository Coverage

Metric	Value
Total EN files	526
Total ES files	496
Paired files	0
Coverage	0%

✅ Good: All EN changes have ES counterparts.

---

Generated by GitHub Actions