> Esta traducción se ofrece por comodidad. El texto normativo es el original en inglés. # Operación de agentes **Especificación del Meta-Universo** **ID del documento:** MU-V2-GUIDE-010 **Título:** Instrucciones de operación para agentes de IA que trabajan sobre un modelo conforme **Clase de documento:** informativo **Versión:** 2.0 (borrador) **Estado:** borrador de trabajo **Referencias normativas:** Model-Traversal-and-Layout, Data-Mastership, Validation **Referencias informativas:** AI-Agent-Guide, AI-Integration-Patterns, MMAS-Package, Overview **Copyright:** © Orkestron.AI **Licencia:** Apache-2.0 --- # 1. Propósito La [guía de agentes de IA](AI-Agent-Guide.md) explica cómo *construir* agentes sobre el estándar. Esta guía es más estrecha y más práctica: eres un agente al que acaban de apuntar hacia un **repositorio de modelo conforme** y le han pedido leerlo, responder a partir de él o cambiarlo. Estas son tus instrucciones de operación, destiladas en recetas a partir de las reglas normativas de [Model-Traversal-and-Layout](../02-architecture/Model-Traversal-and-Layout.md) (ARCH-017) y [Data-Mastership](../02-architecture/Data-Mastership.md) (ARCH-018). Las reglas existen para que equipos mixtos de personas y agentes puedan trabajar sobre el mismo conocimiento sin corromperlo desde ninguno de los dos lados. Cada receta de abajo es consecuencia de tres hechos: todo fichero tiene un significado declarado, todo conjunto de datos tiene exactamente un maestro y toda copia derivada es prescindible. --- # 2. Receta: arranque en frío (primer contacto con un modelo) 1. Lee **`BOOTSTRAP.md`**. Te dice cómo quiere ser leído este modelo en concreto, cuáles son sus convenciones locales y qué no debes tocar. Si además existe un fichero de entrada del ecosistema (`CLAUDE.md`, `AGENTS.md`), léelo después: ese lleva el estado de operación, BOOTSTRAP lleva la estructura. 2. Lee **`manifest.yaml`**: identidad, orden de los paquetes, reglas de clasificación, exclusiones. 3. Lee **`sources.yaml`**: qué conjuntos de datos se maestran aquí y cuáles son espejos de sistemas externos, con sus reglas de frescura y de conflicto. *Hazlo antes de leer contenido*, o no sabrás si lo que lees es autoritativo. 4. Recorre los paquetes **en el orden declarado** (primero los de fundamento), las capas en orden, el `README.md` de la capa antes que los registros. 5. Si hay un recorredor de cobertura (por convención `tools/mu-walk*`), ejecútalo. Un recorrido fallido significa que el propio mapa del modelo está roto: informa de eso antes de fiarte de nada más. Regla que ahorra tiempo: el orden de recorrido es el orden de dependencias. Aunque solo necesites un paquete, sigues leyendo primero los manifiestos y los README de los paquetes de fundamento: definen el vocabulario que hablan los paquetes posteriores. --- # 3. Receta: responder preguntas a partir de un modelo 1. Resuelve la respuesta hasta registros concretos; cítalos por ruta o por ID de registro. 2. Antes de apoyarte en cualquier hecho, comprueba su conjunto de datos en el registro: - **maestrado por el modelo** → el registro es la verdad; responde sin más. - **espejo con maestro externo** → comprueba la frescura. Dentro del límite de obsolescencia: responde nombrando al maestro ("según el espacio Ops de Confluence, recolectado el 2026-07-30"). Más allá: di que el espejo está rancio y prefiere volver a recolectar antes que adivinar. - **`status: declared`** → todavía no hay datos, solo una intención; nunca presentes un espejo declarado como un hecho. - **`status: retired`** → el sistema de origen ya no existe; el espejo es un archivo congelado. Responde en histórico ("a fecha de la exportación final"), nunca como estado actual. 3. Distingue los orígenes: una captura en `raw/` es evidencia de lo que dijo una fuente; un registro es la afirmación propia del modelo. Cuando discrepen, dilo; puede que el modelo sostenga a propósito una desviación anotada. --- # 4. Receta: escribir en un modelo 1. **Encuentra primero al maestro.** Busca el conjunto de datos en `sources.yaml`. Escribe solo en el maestro; escribir en una copia es corromper, por cómoda que resulte: - maestrado por el modelo → edita el registro en su sitio, siguiendo las convenciones de nombres y de registro del modelo. - maestrado externamente → la corrección pertenece al sistema externo. Si no puedes llegar a él, entrega la corrección a alguien que sí pueda (o anótala como una nota claramente marcada, maestrada por el modelo, *acerca del* espejo; nunca edites los bytes espejados). 2. **Respeta los orígenes.** Nunca edites a mano nada recolectado (`raw/`, espejos) ni generado (`artifacts/`). El arreglo va al sistema de origen o al generador. 3. **Mantén el recorrido verdadero.** Si añades, mueves o borras ficheros, vuelve a ejecutar el recorredor de cobertura y sube el informe fresco. Un fichero nuevo que ninguna regla clasifica es un huérfano: amplía las reglas del manifiesto (o coloca bien el fichero); no ignores el fallo. 4. **Mantén los registros verdaderos.** Conjunto de datos nuevo, canalización nueva, maestría cambiada → actualiza `sources.yaml` en el mismo cambio. Los cambios de maestría son sucesos versionados, no ediciones silenciosas. 5. Si el modelo alimenta proyecciones de vuelta (un sitio, una página de wiki), ejecuta su comprobación de deriva tras la edición y vuelve a publicar si informa de deriva. --- # 5. Receta: recolectar un sistema externo dentro de un modelo 1. Confirma la entrada del conjunto de datos en el registro (maestro, alcance, cadencia). Si no hay entrada → créala primero; recolectar sin maestría declarada es como nacen dos verdades. 2. Deposita la **captura sin modificar** bajo `raw///` con una ficha de procedencia al lado (fuente, alcance, hora de extracción, herramienta, recuento). 3. Aplica la transformación hacia la ubicación del espejo; nunca "mejores" hechos durante la transformación: el enriquecimiento es una capa aparte, maestrada por el modelo. 4. Actualiza los metadatos de frescura; vuelve a ejecutar el recorredor. ## Receta: publicar una proyección de vuelta 1. Genérala de los registros del modelo de forma mecánica; una proyección afinada a mano es una bifurcación, no una proyección. 2. Marca la copia: maestro, hora de generación, "no editar aquí", en la forma que admita el destino. 3. Haz detectable la deriva: un hash de contenido sobre la parte comparable, cotejado por un comando de comprobación, es el mínimo. 4. Prefiere automatizar la comprobación (un trabajo diario que avise a una persona ante la deriva), para que la divergencia la note la maquinaria y no la vergüenza. --- # 6. Cuándo negarse Niega la escritura y explícalo cuando: - no puedas determinar el maestro de un conjunto de datos (entrada de registro ausente o ambigua); - te pidan editar en su sitio un espejo, una captura cruda o un artefacto generado; - te pidan sortear el recorrido (añadir ficheros semánticos como "excluidos", ocultar contenido a la clasificación); - la comprobación de cobertura del modelo falle y el cambio pedido se apoyaría en la zona sin clasificar; - la regla de conflicto de un conjunto de datos propietario o restringido prohíba la divulgación pedida. Un agente que no puede decir qué le está permitido editar no debe editar. Esto es [ARCH-017 §11](../02-architecture/Model-Traversal-and-Layout.md) en la práctica. --- # 7. Etiqueta multiagente y de equipo humano - **Deja el recorrido en verde.** El recorredor es la invariante compartida entre sesiones y entre agentes: nunca entregues un recorrido en rojo. - **Registros antes que memoria.** Todo lo que una sesión futura deba saber sobre estructura o autoridad pertenece a BOOTSTRAP, al manifiesto o al registro, no a un historial de conversación. - **Cambios pequeños y declarados.** Prefiere añadir un registro a reescribir uno; prefiere ampliar una regla a hacer una excepción para un fichero; mantén estables los ID de registro. - **Procedencia en el trabajo derivado.** Si generaste o resumiste contenido a partir de fuentes, di de qué, con qué herramienta y cuándo: de ello depende la maquinaria de confianza del modelo (estado de validación, revisión del propietario). --- # 8. Cómo se ve en la realidad Dos modelos en producción ejercitan todas las recetas anteriores y merecen leerse como documentación ejecutable: el modelo de producto de Orkestron.AI (proyección de vuelta a un sitio público con comprobación de deriva por hash y una vigilancia diaria con avisos) y el modelo de la plataforma DevTeam.Games (espejos externos de código fuente, un sistema de registro retirado conservado como evidencia congelada, un conjunto de datos propietario que nunca se publica). Véase el [estudio de caso de Orkestron](../06-ecosystem/Case-Study-Orkestron-Ecosystem.md). --- # Declaración final Un modelo conforme te dice cómo leerlo, qué es cada cosa y de quién es cada verdad. Tu trabajo como agente es simétrico: lee en el orden declarado, escribe solo donde vive la verdad y deja las declaraciones tan verdaderas como las encontraste.