Estado: Aceptado Fecha: 2026-05-24 Responsable de Decisión: Arquitectura
Los monorepos empresariales frecuentemente sufren de bloating en el directorio raíz. Con el tiempo, directorios de tests (tests/), scripts (scripts/), archivos de configuración (NuGet.Config), y artículos de conocimiento dispersos (knowledge/) se acumulan en el workspace raíz. Esto crea sobrecarga cognitiva para nuevos ingenieros y oscurece los puntos de entrada primarios (README.md, docs/MASTER_INDEX.md).
En UMS, la falta de una taxonomía raíz estricta permitió que concerns técnicos y de gobernanza se mezclaran en el nivel superior, creando una experiencia de desarrollador subóptima y empujando documentación crítica debajo del fold en la interfaz web de GitHub.
Adoptar el patrón arquitectónico “Lean Root” (o Clean Root), enforce una dicotomía binaria estricta en la raíz del repositorio: el Technical Engine (src/) versus el Knowledge Hub (docs/).
src/ (Technical Engine): Todo el código ejecutable, tests, scripts de load testing, migraciones de base de datos, scripts de utilidad CI/CD, y configuraciones específicas de lenguaje (ej., NuGet.Config) DEBE residir dentro de src/ o sus subdirectorios.docs/ (Knowledge Hub): Toda la documentación empresarial, blueprints arquitectónicos, requerimientos, y READMEs traducidos (README.es.md) DEBE residir dentro de docs/.AGENTS.md) y archivos estándar open-source (CHANGELOG.md, LICENSE, README.md) son las ÚNICAS excepciones permitidas para permanecer en la raíz, cumpliendo estrictamente con los estándares estructurales de la metodología BMAD.src/) vs. teoría (docs/).README.md del repositorio y los links de navegación se muestran prominentemente “above the fold” en GitHub sin requerir scrolling past docenas de carpetas.src/ o actualizar sus paths de comando.NuGet.Config) deben ser explícitamente targeted o dependerse vía mecanismos de herencia estándar desde dentro de src/.src/ vs docs/.