# Anatomía de un repositorio de modelo *Construir un meta-modelo · lección 1 de 6 · ~15 min* ## Qué aprenderá La forma canónica de un repositorio de modelo conforme: cada ubicación reservada, qué le corresponde y por qué la forma misma es un contrato. ## El árbol canónico ```text meta-model/ ├── README.md # human landing ├── BOOTSTRAP.md # operating instructions: how to read this model (read first) ├── LICENSE ├── CHANGELOG.md ├── manifest.yaml # walk declaration: bundle order, classification, exclusions ├── sources.yaml # Data Mastership Register: who masters each dataset │ ├── bundles/ # the model data: bundles → layers → records ├── canon/ # source texts this model treats as ground truth ├── raw/ # unprocessed harvested captures (never hand-edited) ├── artifacts/ # generated, regenerable outputs (never authored) ├── imports/ ├── mappings/ # external standards and alignments to them ├── schemas/ ├── examples/ ├── diagrams/ ├── docs/ └── tools/ ``` Cada ubicación lleva un significado fijo, de modo que un lector (persona o agente) nunca adivina qué es un archivo por intuición. ## Los dos puntos de entrada **`BOOTSTRAP.md`** es para mentes: cómo leer este modelo, en qué orden, cuáles son las convenciones locales, qué no debe tocar. **`manifest.yaml`** es para máquinas: identidad, orden de los paquetes, reglas de clasificación de archivos, exclusiones. Todo lo demás es alcanzable desde esos dos. Si su ecosistema ya tiene un archivo de entrada (`CLAUDE.md`, `AGENTS.md`), consérvelo, pero haga que apunte a BOOTSTRAP: una sola fuente estructural de verdad. ## Los cuatro temperamentos del contenido Todo lo que hay en un modelo tiene uno de cuatro temperamentos, y nunca se mezclan: 1. Contenido **de autoría** (paquetes, políticas, documentos): escrito por personas o por agentes en calidad de autores, editado en su sitio, revisado como el código. 2. Textos **canónicos** (`canon/`): documentos *sobre* los que trata el modelo o que lo vinculan: una doctrina, una decisión adoptada, la especificación del meta-modelo al que se ajusta. Las capas referencian el canon; nunca lo parafrasean. Si un registro y un texto canónico entran en conflicto, gana el canon. 3. Evidencia **recolectada** (`raw/`): capturas de sistemas externos: exportaciones, volcados, rastreos. Organizada como `raw///`, cada una con un archivo lateral de procedencia (fuente, alcance, hora de extracción, herramienta). Editar a mano una captura destruye su valor probatorio: las correcciones ocurren en la fuente (y luego se vuelve a recolectar) o como registros anotados del modelo. 4. Salidas **generadas** (`artifacts/`): vistas calculadas, informes, resultados de recorridos. La prueba de un `artifacts/` sano: bórrelo entero, regenérelo, no se ha perdido nada de valor. ## Ejemplo real: un modelo de plataforma El modelo de DevTeam.Games muestra la forma absorbiendo una realidad desordenada: su `_raw/` (un nombre heredado, mapeado en el manifiesto) guarda una exportación de ClickUp congelada en el momento de retirar el gestor, investigación de competencia y capturas de diseño; `00-meta/` guarda un espejo vendorizado del canon AISMM con archivos de procedencia; el código fuente real de la plataforma está adjunto como clones git externos, presentes en disco pero declarados como espejos cuyo maestro está en otra parte. 2613 archivos, todos clasificados. Las disposiciones heredadas no hubo que renombrarlas: el manifiesto mapea los nombres antiguos a significados reservados. ## Ideas clave - Dos puntos de entrada: BOOTSTRAP.md para mentes, manifest.yaml para máquinas. - Cuatro temperamentos (autoría, canon, recolectado, generado) con hogares reservados; nunca se mezclan. - Las disposiciones heredadas sobreviven: mapear es mejor que renombrar. ## Profundizar - [MMAS-Package: estructura de repositorio y paquete](/spec/#02-architecture/MMAS-Package.md) - [Recorrido del modelo y ubicaciones conocidas](/spec/#02-architecture/Model-Traversal-and-Layout.md) Siguiente: [Paquetes, capas, registros](02-records.md)