chore(lint): migra los tres guards de boundaries a la sintaxis v7

[beyondnetPeru]

Pull Request Summary

eslint-plugin-boundaries subió de 6.0.2 a 7.2.0 en #439. La aplicación de reglas seguía funcionando, pero v7 emitía dos deprecaciones en cada corrida de lint:boundaries, y una de ellas no era cosmética: las tres configs usaban mode: 'file' en todos sus descriptores de elemento, y sus propios comentarios ya advertían de que sin ese modo las reglas quedan en no-op silencioso. Cuando un mayor futuro elimine mode, los guards habrían pasado a aprobarlo todo saliendo con exit 0.

Migración (los tres ficheros, sin cambio de comportamiento):

• mode: 'file' + pattern: 'src/<capa>/**/*' → pattern: 'src/<capa>'. En v7 los descriptores de elemento son siempre de carpeta (@boundaries/elements/dist/index.d.ts:1811), así que el patrón apunta a la carpeta de la capa en vez de globear dentro de ella. Verificado con boundaries/no-unknown-files: los patrones de carpeta clasifican el mismo conjunto de ficheros que el viejo mode: 'file'.
• rules: → policies:
• selectores planos { type: X } → selectores de entidad { element: { type: X } }, en from y en allow.to.
• dependency: { kind: 'type' } se conserva: no está deprecado (lo están el importKind a nivel de regla y dependency.module), así que la excepción de imports type-only sigue igual.

La trampa que trae el cambio de modelo

Con elementos de carpeta cada import intra-capa pasa a ser interno, y los internos no se comprueban por defecto (checkInternals es false). Con los elementos de fichero de v6 cada fichero era su propio elemento, así que common → common sí se comprobaba — y core-domain lo prohíbe a propósito (allow: { to: { type: [] } }, "common: no internal imports"). La migración ingenua desactivaba esa regla en silencio. checkInternals: true en las tres configs restaura la semántica de v6.

Verificación

La config falla abierta, así que leerla no es evidencia. Monté una matriz de equivalencia que inyecta una violación para cada par ordenado de capas, con destino directo en la carpeta y anidado, en forma valor y import type, ejecutando la config vieja y la nueva en paralelo:

workspace	canarios	marcados (vieja)	marcados (nueva)	divergencias
core-domain	300	100	100	0
mcp-server	50	13	13	0
core-api	32	7	7	0

Esa matriz es la que cazó la regresión de common → common; el juego corto de 6 canarios pasaba sin verla.

Además: los 6 canarios de referencia se comportan igual que antes — 3 imports de valor salen con exit 1 y mensaje byte a byte idéntico, 3 type-only salen con exit 0. Y los tres npm run lint:boundaries salen 0 sin una sola línea [boundaries][warning].

Los canarios y las configs de sondeo se borraron; el árbol solo lleva los tres ficheros de config.

Fuera de alcance (preexistente)

mcp-server declara los tipos de elemento application y core para carpetas que no existen, mientras src/common, src/utils y src/test-doubles no tienen descriptor y quedan sin gobernar. Se comportaba idéntico antes de esta migración, así que lo dejé intacto para no mezclarlo con un cambio que preserva comportamiento.

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: this PR does not introduce a specific technology dependency into the agnostic Core reference — es una migración de sintaxis de una config de lint ya existente, sin dependencias nuevas.
• Bilingual: no apply — 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; conserva la que los guards ya aplicaban.
• Link to Issue: sigue a chore(deps-dev): bump eslint-plugin-boundaries from 6.0.2 to 7.2.0 #439 (bump de eslint-plugin-boundaries a 7.x)

🤖 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