## CTX: operaciones de contexto, ejecución y colaboración Un meta-modelo conforme a Vercy solo funciona como reflejo digital primario de la realidad si el trabajo se hace a través de él: toda tarea arranca del contexto del modelo y todo resultado fluye de vuelta al modelo. Esta familia define cómo se construyen y escalan los contextos, cómo se ejecuta el trabajo con contexto completo, y cómo varias personas y agentes de IA trabajan a la vez sobre un mismo modelo sin corromperlo. ### Visión general de la colaboración: muchos actores, una verdad El trabajo multiactor sobre un meta-modelo descansa en seis invariantes. Juntos hacen que la concurrencia sea segura por construcción y no por vigilancia: 1. **Un maestro por conjunto de datos.** Toda escritura va al Sistema de registro declarado del conjunto de datos (el Registro de maestría). Una copia (espejo, captura cruda, artefacto generado, vista escalada, paquete de contexto) jamás se edita, la tenga quien la tenga y por cómodo que resulte. Un actor que no pueda decir qué le está permitido editar NO DEBERÁ editar. 2. **Estructura declarada, recorrido en verde.** El mapa propio del modelo (manifiestos, orden de recorrido, comprobación de cobertura) es el invariante compartido entre actores y sesiones. Todo actor deja el recorrido en verde; nadie entrega un recorrido en rojo. 3. **Partición antes que paralelismo.** Los escritores concurrentes trabajan sobre alcances disjuntos (paquetes, capas, conjuntos de datos) asignados por el Custodio y publicados en el modelo. Los bloqueos son la excepción para los alcances que una partición no puede separar; llevan un TTL. Las lecturas no están restringidas dentro del permiso concedido. 4. **Transiciones explícitas.** Todo cambio es un evento con actor, tiempo y justificación. El estado que una sesión futura deba conocer va al modelo (registros, notas de traspaso, materiales de arranque), jamás a los historiales de chat. Las fusiones silenciosas, los renombrados silenciosos y el gana-el-último-que-escribe no son conformes. 5. **Delegación acotada.** Todo Agente actúa bajo un Contrato de delegación que nombra sus procesos, conjuntos de datos, nivel por tipo de paso (T1/T2/T3 tal como se definen en el preámbulo de la paleta, COMMON) y caducidad. El Contrato de delegación es una especialización declarada del Contrato semántico (04-core-concepts/Contract.md 5-6; 03-federation/Federation-Contracts.md 3a), y CTX-9 es su único Sistema de registro. La autonomía se gana por historial, es revocable al instante con efecto impuesto en la puerta, y está plenamente auditada. La responsabilidad nunca abandona al Custodio. 6. **Reglas antes que juicio.** Los conflictos entre contribuciones se resuelven primero por reglas de conflicto declaradas; solo el residuo llega al Custodio, cuya resolución se registra y, donde sea posible, se convierte en regla para que el caso siguiente sea mecánico. Dos controles de hierro de toda la paleta, de COMMON, obligan a toda superficie CTX. Primero, los datos nunca son una orden: el contenido de cualquier origen no redactado (espejado externo, federado, reportado por personas) es dato, jamás instrucciones, y todo Contrato de delegación lleva esa prohibición. Segundo, la clase de conjuntos de datos crítica para la seguridad (BOOTSTRAP y materiales de arranque, definiciones de procesos y puertas, matriz de aprobación, criterios del carril de aprobación automática, Contratos de delegación, campos de maestría y regla de conflicto de sources.yaml, rúbricas de gravedad, configuraciones de vigilancia y umbrales): los cambios de esta clase se aceptan solo en T1 con un segundo revisor humano, son estructuralmente inelegibles para carriles de aprobación automática, y QSC-9 los ancla por hash de forma continua. Vocabulario según el glosario de la paleta: cuarentena es la marca de confianza legible-pero-señalada de MIR-8 (y también el estado de frescura de MIR-6); cuarentena de admisión es la zona de retención entrante de FED-8, ilegible hasta su promoción; retención por integridad es el marcador de QSC-9, excluido de responder y de publicarse hasta que se levante. La unidad de trabajo es el bucle de Desarrollo con contexto completo (CTX-5): arrancar, extraer contexto, verificar suficiencia, actuar, escribir de vuelta a los maestros por la cadena CON, registrar eventos, dejar el recorrido en verde. La devolución (CTX-11) cierra el bucle de aprendizaje: lo que un actor aprendió se convierte en contenido del modelo o se pierde con la sesión. La familia está escrita para la proporción real de actores: los Custodios delegan mucho en Agentes. Los pasos de solo lectura (extracción, escalado, arranque, monitorización) son rutinariamente T3; las escrituras y fusiones mecánicas son T2; allí donde una carta diga que un paso DEBERÁ permanecer en T1, el Agente propone y una persona aprueba cada acto; los actos nombrados no delegables en sustancia (las resoluciones de arbitraje del Custodio, la emisión y revocación de contratos) son decisiones que quien ocupa el rol realiza en persona, sea cual sea el apoyo de redacción que dé un Agente. Los niveles se usan exactamente como los define el preámbulo de la paleta y en esta familia jamás se vuelven a glosar. Conjunto nuclear de esta familia tras la adjudicación de la carta fundacional: CTX-1, CTX-5, CTX-9 y CTX-10. CTX-2, CTX-6, CTX-7 y CTX-11 son recomendados con las promociones condicionales a nuclear enunciadas en sus cartas; CTX-3, CTX-4 y CTX-8 son recomendados. Entre las implementaciones de referencia están los servicios de agentes al estilo Orkestron que operan bajo contratos acotados por rol. El caso de esfuerzo Meta-Orchestrator State, publicado en el repositorio externo de la Dimensión de referencia (orkestron-ai/meta-orchestrator-state) y que no forma parte del estándar, tiene miles de agentes ciudadanos actuando contra un único corpus de modelo cívico: funciona solo porque la partición, los contratos de delegación y las escrituras encaminadas por maestría se sostienen a esa escala. ## Interfaces con otras familias - **GOV**: entra: las concesiones de acceso internas y sus revocaciones desde GOV-7 (las concesiones que CTX-1 comprueba para empaquetar y redactar, y los alcances de lectura a los que se atan los Contratos de delegación); artefactos de política y configuración desde GOV-2 (mapas de niveles, configuraciones de puerta, criterios del carril de aprobación automática, el conjunto de reglas de selección de contexto por defecto al que CTX-1 recurre); planes de capacidad y cuotas de cómputo de agentes desde GOV-5 (acotan los límites de los contratos de CTX-9); decisiones de Propietario y Custodio vía GOV-1 (visto bueno del Propietario para alcances restringidos de CTX-9, resoluciones sobre patrones de arbitraje escalados y apelaciones desde CTX-7); material de capacidad de validez corta desde GOV-8 (acota la propagación de revocación de CTX-9). Sale: el estado del registro de Contratos de delegación e informes de cartera (CTX-9); registros de arbitraje y propuestas de cambio de regla (CTX-7); la sucesión de Custodio de GOV-3 ejecuta su traspaso con la mecánica de CTX-8; la génesis GOV-4 produce el modelo nacido en el que CTX-10 arranca. - **CON**: la escritura de vuelta de CTX-5 entra al modelo por la cadena CON: CON-1 lista los conjuntos de escritura de vuelta de CTX-5 como canal registrado, gobierna la matriz de aprobación de CON-4, con un carril de aprobación automática para los añadidos mecánicos de eventos; CTX-7 es el paso de integración de concurrencia que alimenta a CON-4, jamás una autoridad de aprobación paralela. CON-10 establece identidad, derechos de entrada y alta, y su rama de agentes obtiene los Contratos de delegación invocando a CTX-9 (los derechos de entrada referencian contratos por identificador; los Eventos de revocación de CTX-9 se propagan al registro de derechos de entrada de CON-10 dentro del TTL declarado). La estructura, el manifiesto y las convenciones de edición de registros que usan CTX-3, CTX-4 y CTX-5 son territorio de CON-3 y CON-6. Los perfiles de consumidor de CTX-1 se resuelven contra el registro de consumidores y suscripciones CON-13. Las propuestas de cambio de CTX-11 entran por CON-1. - **MIR**: los sellos de frescura y cuarentena de CTX-1 vienen de los metadatos de recolección de MIR-2 y de los estados de MIR-6 y MIR-8; las correcciones de CTX-11 a hechos maestrados externamente se encaminan al maestro externo por las tuberías de MIR; las comprobaciones de deriva de CTX-5 citan a MIR-7 como único motor de detección de deriva y republican las proyecciones derivadas por su maquinaria; los cambios de registro que surjan en CTX-3, CTX-4 y CTX-5 se ejecutan vía MIR-1; el ciclo de vida y la persistencia de historia son MIR-9; la retirada del modelo (MIR-11) dispara el barrido de revocación de CTX-9. - **ACT**: entra: los informes de salud del bucle y las propuestas de recalibración de nivel de ACT-12 como entradas nombradas al paso 8 de CTX-9; peticiones de contexto de apoyo a la decisión (paquetes de CTX-1). Sale: los Contratos de delegación bajo los que corre todo paso ACT delegado (CTX-9, con vigencia impuesta en la puerta en el despacho de ACT-6); trabajo aparcado de agentes de actuación suspendidos vía CTX-8; las acciones externas que cambian la realidad dentro de un bucle CTX-5 se despachan por ACT-6 bajo sus controles, jamás directamente. - **QSC**: toda puerta de salida de CTX (recorrido en verde, validación, verificación de deriva) invoca a los comprobadores de QSC; las auditorías de delegación de QSC-7 reconcilian los actos de agente contra el registro de CTX-9, alimentan recomendaciones al paso 8 de CTX-9, y prueban el rechazo del cebo de inyección contra la cláusula de los contratos de que los datos nunca son una orden; QSC-9 ancla por hash de forma continua la clase crítica para la seguridad que esta familia toca (materiales de arranque verificados en el paso 1 de CTX-10 y escritos por el paso 5 de CTX-11, Contratos de delegación maestrados por CTX-9); los monitores permanentes de CTX (el monitor de partición de CTX-6, la monitorización de contratos de CTX-9) se registran y se vigilan en salud vía QSC-15; la autoridad residual pasado el TTL de revocación y los monitores muertos escalan a QSC-14. - **FED**: los procesos CTX se detienen en la frontera de soberanía; la extracción de contexto sobre el modelo de un socio corre solo contra las Proyecciones expuestas bajo Contratos de federación (concesiones vía FED-3); las disputas entre Universos abandonan CTX-7 hacia la resolución de FED-9; el agente de una parte externa jamás tiene un Contrato de delegación local, consume bajo un Contrato de federación en su lugar; las secciones federadas de un paquete llevan la clase de origen federado de CTX-1. Artefactos clave que esta familia exporta: el Paquete de contexto con clases de origen y contaminación, sellos de cuarentena e identificadores de concesión (CTX-1, CTX-2), el mapa de particiones y la tabla de bloqueos (CTX-6), la Nota de traspaso (CTX-8), el registro de Contratos de delegación como Sistema de registro (CTX-9), la bitácora de sesión y el informe de arranque (CTX-10), los registros de devolución y las propuestas de cambio (CTX-11). ### CTX-1 Extracción de contexto - Propósito: Construir desde el modelo un paquete de contexto acotado a la tarea: seleccionar los objetos, relaciones, textos de canon y restricciones que un consumidor necesita, dimensionados a la ventana del consumidor, con procedencia, clases de origen y contaminación, y una lista explícita de huecos. - Disparador: Una asignación de tarea, una petición de Consumidor, o el inicio de un bucle FCD (CTX-5 invoca este proceso). - Actores: el Consumidor pide; el Custodio o un Agente ejecuta. Delegación al Agente: T3 para extracción de solo lectura dentro del alcance de permiso concedido al Agente por GOV-7; T2 cuando la selección toca conjuntos de datos restringidos (la revisión humana cubre la lista de inclusión y redacción). El Custodio redacta y mantiene las reglas de selección permanentes (paso 1). - Entradas / Salidas: Entradas: enunciado de la tarea; el modelo (manifiestos, `sources.yaml`, enlaces de trazabilidad, canon); perfil del consumidor (tamaño de ventana, profundidad pedida, concesiones GOV-7; los consumidores registrados se resuelven contra el registro de consumidores CON-13); el conjunto versionado de reglas de selección. Salidas: Paquete de contexto (registros seleccionados con una clase de origen y contaminación por sección, cabecera de procedencia, sellos de frescura y cuarentena, notas de redacción, lista de huecos, los identificadores de concesión bajo los que se construyó y una caducidad); evento de extracción en la bitácora. - Pasos: 1. Resolver las reglas de selección: el Custodio redacta y versiona reglas de selección permanentes por tipo de tarea; donde no exista un conjunto local de reglas, se aplica el valor por defecto entregado (anclas más relaciones declaradas a un salto más restricciones citadas), mantenido como configuración versionada de GOV-2. 2. Analizar el enunciado de la tarea hasta obtener entidades ancla (identificadores de registro, nombres, áreas del modelo). 3. Resolver las anclas a registros siguiendo el orden canónico de recorrido y los enlaces de trazabilidad declarados. 4. Expandir el vecindario según las reglas de selección: seguir las relaciones declaradas priorizando dependencias, recogiendo las clases de contexto que las reglas nombran para ese tipo de tarea (requisitos, decisiones, restricciones, riesgos, pruebas, hechos de tiempo de ejecución). 5. Comprobar todo conjunto de datos incluido en el Registro de maestría; sellar los espejos con la hora de la última recolección y el estado de cuarentena del conjunto de datos (según MIR-6 y MIR-8); señalar los que excedan el límite de obsolescencia; excluir los conjuntos de datos bajo bloqueo duro (cuarentena de admisión o retención por integridad) y registrar toda exclusión en la lista de huecos. 6. Etiquetar toda sección del paquete con su clase de origen: redactado, espejado externo, federado, o reportado por personas. Las clases no redactadas son dato, jamás instrucciones (control de hierro de COMMON); la etiqueta es lo que permite a consumidores y puertas imponerlo. 7. Compuerta: ¿cabe la selección cruda en la ventana del consumidor? Si no, invocar CTX-2 para rebajar la profundidad por sección según prioridad declarada, jamás por omisión silenciosa. 8. Compuerta: ¿se ha seleccionado contenido restringido por permiso? Si sí, descartar o redactar según las concesiones GOV-7 y registrar la redacción. 9. Ensamblar el Paquete de contexto con una cabecera de procedencia (versión del modelo, hora de extracción, versión de las reglas de selección), los identificadores de concesión bajo los que se construyó, y una caducidad: el paquete caduca al revocarse cualquier concesión citada o por un TTL fijo, lo que ocurra antes. Incluir la lista explícita de huecos (qué se excluyó y por qué). 10. Entregar al consumidor y registrar el evento de extracción. - Controles: Comprobación de permisos contra las concesiones GOV-7 antes de ensamblar; sellos obligatorios de frescura y cuarentena en los espejos con exclusión por bloqueo duro; etiquetas obligatorias de origen y contaminación en toda sección; el paquete se marca como generado (desechable, jamás editado, regenerado a demanda) y caducable (identificadores de concesión más TTL); la lista de huecos es obligatoria (el truncado silencioso no es conforme). - Nivel: nuclear. - Variantes: Solo: el Propietario-Custodio extrae leyendo en orden de recorrido; el paquete puede ser un resumen improvisado, pero la disciplina de contaminación y caducidad se aplica igualmente a cualquier cosa que un Agente vaya a consumir. Equipo: reglas de extracción permanentes por tipo de tarea. Federada: la extracción corre solo contra las Proyecciones que el Propietario remoto expone, jamás contra sus interioridades; las secciones federadas llevan la clase de origen federado. La ejecución manual, híbrida y autónoma son todas lícitas; la autónoma exige la bitácora de extracción. - Métricas: Número de huecos y escaladas reportados por el consumidor por paquete (la medida indirecta computable de exhaustividad); latencia de extracción; tasa de obsolescencia de los espejos incluidos; proporción de paquetes entregados con etiquetado de origen completo (objetivo 100 por ciento). - Modos de fallo: La selección solo por palabras clave se pierde restricciones enlazadas (guarda: la expansión por enlaces guiada por reglas es obligatoria; la búsqueda de texto por sí sola no es conforme). El paquete se trunca en silencio para caber en la ventana (guarda: lista de huecos obligatoria). Un espejo rancio presentado como fresco (guarda: sellos y señalamientos de frescura). Contenido restringido se filtra a un paquete (guarda: compuerta de redacción más auditoría de las bitácoras de extracción). Las instrucciones incrustadas en contenido espejado o federado se ejecutan como contexto de tarea (guarda: clases de origen y contaminación más la cláusula del Contrato de delegación de que los datos nunca son una orden, con el comportamiento de rechazo probado por QSC-7). Datos en cuarentena consumidos como actuales a velocidad de máquina (guarda: el sellado del paso 5 y la exclusión por bloqueo duro). El contenido de una concesión revocada sigue viviendo en un paquete cacheado (guarda: la caducidad del paso 9 atada a los identificadores de concesión). ### CTX-2 Escalado de contexto - Propósito: Presentar el mismo conocimiento a profundidades declaradas (resumen, de trabajo, completa) para que toda ventana de consumidor reciba una vista fiel del modelo y no una truncada. - Disparador: Desbordamiento de ventana detectado en CTX-1; un consumidor que pide una profundidad concreta; publicación de una proyección escalada. - Actores: el Custodio define los perfiles de profundidad; el Agente genera vistas escaladas en T3 (la generación es mecánica); revisión T2 cuando una vista escalada vaya a publicarse fuera del dominio de gobernanza. El Auditor PUEDE muestrear vistas para comprobar fidelidad. - Entradas / Salidas: Entradas: registros de origen con sus clases de origen y contaminación y sus marcas de cuarentena; definiciones de los perfiles de profundidad (qué preserva cada profundidad). Salidas: vistas escaladas marcadas como artefactos generados con punteros a sus fuentes; eventos de generación. - Pasos: 1. Leer la declaración de perfiles de profundidad del modelo. Convención mínima: el resumen DEBERÁ preservar identidad, estado, significado en una línea y enlaces; la de trabajo añade reglas operativas e interfaces; la completa es el registro mismo. 2. Generar la vista de cada registro seleccionado a la profundidad pedida. 3. Verificar los invariantes: toda vista escalada conserva el identificador del registro y un puntero al registro completo; las palabras clave normativas jamás se pierden a profundidad de trabajo; toda vista escalada preserva la clase de origen y contaminación de la fuente y sus marcas de cuarentena (el escalado nunca blanquea la procedencia ni el estado de confianza). 4. Compuerta: ¿cabe el conjunto escalado en la ventana de destino? Si no, rebajar la profundidad por sección siguiendo el orden de prioridad declarado; la omisión de secciones enteras DEBERÁ registrarse en la lista de huecos, jamás en silencio. 5. Sellar las vistas como generadas (regenerables, jamás editadas a mano). 6. Registrar el evento de generación con la versión del modelo de origen. - Controles: Comprobación de preservación de identidad, clase de contaminación y marcas de cuarentena; una vista escalada es una proyección, no una bifurcación; regeneración al cambiar la fuente con verificación de deriva (hash de contenido sobre la parte comparable, detección mediante el motor MIR-7). - Nivel: recomendado (nuclear para modelos que sirven a consumidores de ventana pequeña o a socios federados a profundidad reducida). - Variantes: Solo: dos profundidades suelen bastar. Equipo: profundidades por defecto según el rol (un directivo lee el resumen, quien implementa lee la completa). Federada: los perfiles de profundidad se nombran en el Contrato de federación; a un socio PUEDE concedérsele solo la profundidad de resumen. La generación autónoma es la norma; la generación manual solo durante el arranque de los perfiles. - Métricas: Razón de compresión por profundidad; incidencias de deriva en vistas escaladas; tasa de escalada de los consumidores (con qué frecuencia quien lee el resumen debe traerse la versión completa). - Modos de fallo: El resumen deriva de la fuente tras las ediciones (guarda: regenerar al cambiar, con el hash de deriva comparado por un trabajo de comprobación registrado en QSC-15). La profundidad se usa mal como control de acceso encubierto (guarda: el acceso lo concede el permiso GOV-7, no la esperanza de que un resumen esconda datos). Una vista escalada editada a mano se convierte en una segunda verdad (guarda: origen generado, por regla se sobrescribe al regenerar). Una vista escalada pierde la marca de contaminación o de cuarentena y el contenido espejado pasa por redactado (guarda: el invariante de preservación del paso 3). ### CTX-3 Descomposición - Propósito: Partir un modelo, un paquete o una tarea en piezas sobre las que se pueda trabajar de forma independiente, preservando cada enlace cruzado, la regla de maestro único y el recorrido en verde. - Disparador: Una tarea demasiado grande para un actor o para una ventana; crecimiento del modelo más allá de un tamaño navegable; una petición de particiones desde CTX-6. - Actores: el Custodio decide el corte: la aprobación de las divisiones de modelo DEBERÁ permanecer en T1 (el Agente propone, el Custodio aprueba cada corte); las divisiones de tareas PUEDEN correr en T2. El Agente computa el grafo de dependencias, propone las líneas de corte y ejecuta la división mecánica en T2; el Auditor PUEDE verificar la preservación de enlaces en las divisiones a nivel de modelo. - Entradas / Salidas: Entradas: modelo de origen o alcance de la tarea; grafo de dependencias; Registro de maestría. Salidas: piezas con sus propios manifiestos; mapa de referencias entre piezas; registro actualizado (los cambios de registro se ejecutan vía MIR-1); acta de descomposición. - Pasos: 1. Construir el grafo de dependencias del alcance candidato (registros, relaciones, conjuntos de datos). 2. Proponer líneas de corte que minimicen las referencias entre piezas y que jamás partan un conjunto de datos maestrado entre dos maestros. 3. Compuerta: ¿algún corte propuesto parte un único conjunto de datos maestrado? Si sí, redibujar el corte, o dividir antes el conjunto de datos formalmente en el registro vía MIR-1 (patrón de Maestría de datos H; se aplican las compuertas de MIR-1, incluida su compuerta de Propietario), y volver a proponer. 4. El Custodio aprueba el corte. 5. Ejecutar: crear los manifiestos de las piezas, mover los registros, convertir los enlaces internos que cruzan el corte en referencias explícitas entre piezas por identificador estable (referencias, jamás copias). 6. Volver a pasar el recorredor de cobertura por cada pieza; todo recorrido DEBERÁ estar en verde antes de dar por terminado. 7. Registrar el evento de descomposición (qué se dividió, por qué, el mapa de referencias). - Controles: Ningún registro duplicado en dos piezas; registro actualizado en el mismo cambio a través de MIR-1, único ejecutor de cambios de registro; compuerta de recorrido en verde en cada pieza; los identificadores estables sobreviven al traslado. - Nivel: recomendado. - Variantes: Solo: solo descomposición de tareas, el modelo sigue entero. Equipo: la descomposición a nivel de paquete se corresponde con la propiedad de cada equipo. Federada: la descomposición PUEDE promover una pieza a modelo soberano con su propio Propietario (roles nombrados vía GOV-3, la transferencia registrada vía GOV-1), tras lo cual las reglas de federación gobiernan la relación. Lo típico es lo híbrido: el Agente computa el grafo y la propuesta, la persona traza la línea. - Métricas: Número de referencias entre piezas (cuantas menos, mejor); fallos de recorrido tras la división (objetivo cero); retrabajo atribuible a líneas de corte equivocadas. - Modos de fallo: La división sigue la comodidad de las carpetas en vez de las dependencias (guarda: la propuesta basada en el grafo es entrada obligatoria de la decisión). Un enlace se convierte en copia durante la división (guarda: regla de solo referencias más detección de duplicados). Ficheros huérfanos tras el traslado (guarda: compuerta del recorredor de cobertura). Un conjunto de datos acaba con dos maestros (guarda: la compuerta de registro MIR-1 del paso 3). ### CTX-4 Composición y fusión de modelos - Propósito: Fusionar las piezas de vuelta en un todo, o fusionar dos modelos que cubren realidades solapadas, sin identidades duplicadas, afirmaciones contradictorias ni conflictos de maestría. - Disparador: Fin del trabajo paralelo sobre las piezas; adopción de un segundo modelo; recomposición programada. - Actores: el Custodio dirige; el Agente ejecuta la fusión mecánica en T2; cada conflicto sin resolver escala al Custodio en T1; el Auditor revisa el informe de fusión para las fusiones a nivel de modelo; se exige aprobación del Propietario al fusionar a través de fronteras de propiedad (registrada como Evento de decisión GOV-1). - Entradas / Salidas: Entradas: piezas o modelos con manifiestos y registros; correspondencia de identidades; reglas de conflicto declaradas. Salidas: modelo fusionado; informe de fusión (coincidencias, conflictos, resoluciones, duplicados descartados); registro actualizado (los cambios de registro se ejecutan vía MIR-1); evento de composición. - Pasos: 1. Alinear identidades: emparejar los registros que denotan una misma entidad del mundo real (primero por identificador estable, después por claves declaradas, en último lugar por juicio humano). 2. Compuerta: ¿conflicto de identidad (dos identificadores para una entidad, o un identificador reutilizado para dos entidades)? Si sí, resolver por decisión del Custodio registrada como evento; el renombrado silencioso no es conforme. 3. Fusionar los Registros de maestría vía MIR-1, único ejecutor de cambios de registro (se aplican sus compuertas). Compuerta: ¿reclama ahora algún conjunto de datos dos maestros? Si sí, aplicar las reglas del patrón de Maestría de datos (elegir un maestro, o partir el dato) antes de fusionar contenido alguno. 4. Fusionar el contenido priorizando dependencias; convertir las referencias entre piezas de vuelta en enlaces internos. 5. Detectar afirmaciones contradictorias sobre una misma entidad; resolver cada una por la regla de conflicto declarada o por una resolución registrada del Custodio. 6. Volver a pasar el recorrido de cobertura y la validación; todo en verde. 7. Publicar el informe de fusión y registrar el evento de composición. - Controles: Compuerta de unicidad de identidades; compuerta de maestro único antes de fusionar contenido (ejecutada a través de MIR-1); compuerta de validación a la salida; compuerta de permiso del Propietario cuando los modelos de origen tienen Propietarios distintos; comprobación de conformidad de convenciones previa a la fusión. - Nivel: recomendado. - Variantes: Solo: recomposición trivial de piezas de tarea. Equipo: las fusiones rutinarias de piezas son trabajo del Agente en T2, con el Custodio en las excepciones. Federada: dos modelos soberanos jamás se fusionan de verdad; se federan, o bien un Propietario transfiere formalmente la propiedad primero (registrado como Evento de decisión GOV-1 con los roles reasignados vía GOV-3), y entonces este proceso corre dentro de un solo dominio de gobernanza. La fusión autónoma solo es lícita para piezas producidas por CTX-3 con un mapa de referencias limpio. - Métricas: Identidades duplicadas que sobreviven a la fusión (objetivo cero); conflictos por fusión y tiempo medio de resolución; fallos de validación posteriores a la fusión. - Modos de fallo: La misma entidad existe dos veces bajo dos identificadores (guarda: el paso de alineación de identidades con emparejamiento por claves). La afirmación de una pieza sobrescribe en silencio la de otra (guarda: detección de contradicciones más resoluciones registradas). Colisión de maestría tras fusionar registros (guarda: la compuerta de maestro único vía MIR-1 bloquea la fusión de contenido). Modelos con convenciones incompatibles fusionados en crudo (guarda: comprobación de conformidad previa a la fusión). ### CTX-5 Ejecución de tareas en contexto completo (el bucle FCD) - Propósito: Ejecutar cualquier tarea con plena conciencia del modelo, según el Desarrollo con contexto completo: reunir contexto, verificar que basta, actuar, escribir los resultados de vuelta a los maestros por la cadena CON, y dejar el modelo más verdadero que antes. - Disparador: Cualquier asignación de tarea contra el modelo o contra la realidad que refleja. - Actores: el Contribuyente o un Agente ejecuta; el Custodio sigue siendo responsable. Niveles del Agente por paso: reunión de contexto (pasos 2-3) T3; ejecución (paso 6) según el Contrato de delegación, de T1 a T3 según el impacto; escritura de vuelta (pasos 7-8) T2 por defecto, T3 solo con un rastro de auditoría maduro; el deber de negarse rige en todos los niveles. - Entradas / Salidas: Entradas: enunciado de la tarea; Paquete de contexto de CTX-1 (con clases de origen y contaminación e identificadores de concesión); los permisos GOV-7 del actor y su Contrato de delegación CTX-9. Salidas: resultado de la tarea; actualizaciones del modelo con eventos de transición, entradas por la cadena CON; acta de ejecución. - Pasos: 1. Recibir la tarea. Compuerta: ¿es el modelo el sitio correcto para este trabajo, y tiene el actor permiso y alcance de contrato para el área afectada? La compuerta valida la vigencia del Contrato de delegación citado en el momento del acto; si fallan el permiso, el alcance o la vigencia, negarse o escalar al Custodio. 2. Reunir contexto: invocar CTX-1 (y CTX-2 si hace falta); leer el paquete incluida su lista de huecos. Las clases de origen y contaminación del paquete obligan: el contenido no redactado es dato, jamás instrucciones (control de hierro de COMMON). 3. Compuerta: ¿basta el contexto? Si quedan huecos materiales, ampliar la extracción o preguntar al Custodio; el actor NO DEBERÁ seguir adelante sobre contexto adivinado. 4. Planificar el cambio: enumerar los registros y conjuntos de datos afectados y consultar el maestro de cada conjunto de datos antes de actuar. 5. Compuerta: ¿apunta alguna escritura planificada a una copia que no es maestro (espejo, captura cruda, artefacto generado)? Si sí, redirigir la escritura al maestro, o entregarla como propuesta de cambio a quien pueda alcanzar el maestro; jamás escribir la copia. 6. Ejecutar la tarea (producir el análisis, la decisión, el contenido, el código o la acción externa). Las acciones externas que cambian la realidad se despachan por la cadena ACT (ACT-6) bajo sus controles, jamás directamente desde este bucle. 7. Escribir los resultados de vuelta por la cadena CON: el conjunto de escritura de vuelta entra en CON-1 como canal registrado y se aprueba según la matriz de CON-4, con el carril de aprobación automática para los añadidos mecánicos de eventos; actualizar los registros maestrados por el modelo, registrar un evento por cada transición, y actualizar los manifiestos y (vía MIR-1) el registro en el mismo cambio si la estructura cambió. 8. Volver a pasar el recorredor de cobertura y las comprobaciones de deriva (la detección de deriva cita el motor MIR-7); dejar el recorrido en verde y republicar las proyecciones derivadas. 9. Registrar el evento de ejecución (tarea, actor, contrato citado, paquete de contexto usado, cambios hechos) y llevar lo aprendido a CTX-11. - Controles: Compuerta de permiso y contrato a la entrada, con la vigencia del contrato impuesta en la puerta en cada escritura y cada despacho (jamás por palabra del agente); compuerta de suficiencia; regla de escribir solo al maestro con el deber del Agente de negarse; la escritura de vuelta se ejecuta por la cadena CON, sin puerta trasera; compuerta de salida de recorrido en verde; el rastro de auditoría de toda ejecución de un Agente lo emite la infraestructura mediadora (puerta, canal, entorno de ejecución), jamás lo autorreporta el Agente que actúa. - Nivel: nuclear. - Variantes: Solo: el bucle es disciplina, no ceremonia (leer antes de cambiar, registrar después). Equipo: las instancias del bucle corren dentro de las particiones asignadas por CTX-6. Federada: el contexto PUEDE incluir proyecciones federadas en solo lectura; la escritura de vuelta va solo a lo que este modelo maestra. La ejecución manual, híbrida y autónoma son todas conformes; la autónoma exige contrato T3 y auditoría. Carril rápido editorial: para los cambios clasificados como editoriales o correctivos por debajo del umbral de tamaño declarado, el Evento compuesto único del carril rápido de COMMON es prueba conforme para el acta de ejecución de esta carta. - Métricas: Fracción de tareas ejecutadas con un paquete de contexto registrado; exhaustividad de la escritura de vuelta (cambios reflejados en el modelo dentro de la ventana declarada); número de tareas reabiertas con el código de motivo insufficient-context (código definido en la taxonomía MIR-10); tasa de recorridos en verde al cerrar la tarea. - Modos de fallo: La tarea se ejecuta solo desde su texto, ignorando el modelo (guarda: un paquete de contexto registrado es parte de una ejecución conforme). Los resultados se entregan pero nunca se escriben de vuelta, y el modelo se pudre (guarda: la escritura de vuelta es parte de la definición de terminado, comprobada al cerrar). Escritura a un espejo por comodidad (guarda: la compuerta del paso 5 más el deber del Agente de negarse). Un paquete de contexto cacheado y reutilizado ya rancio entre tareas (guarda: los paquetes llevan la versión del modelo y los identificadores de concesión y caducan según el paso 9 de CTX-1). Resultados escritos rodeando la cadena CON por una puerta trasera (guarda: regla de canal registrado del paso 7; el recorredor de cobertura señala los commits que esquivaron la admisión). Contenido con aspecto de instrucción dentro del paquete dirige al actor (guarda: las clases de contaminación obligan en el paso 2, con la prohibición del contrato impuesta y probada por QSC-7). ### CTX-6 Partición y bloqueo del trabajo concurrente - Propósito: Dejar que varias personas y Agentes trabajen a la vez sobre un modelo sin colisiones, particionando el acceso de escritura por líneas de maestría y de estructura, con bloqueos de vida corta solo allí donde una partición no puede separar el trabajo. - Disparador: Más de un escritor activo sobre un modelo; una ráfaga de tareas paralelas; operación permanente de equipo. - Actores: el Custodio asigna las particiones (el acto de asignar es trabajo del Custodio); un Agente orquestador PUEDE llevar la asignación rutinaria en T2, y las asignaciones que toquen alcances restringidos DEBERÁN permanecer en T1 (el Agente propone, el Custodio aprueba cada asignación); Agentes y Contribuyentes trabajan dentro de sus particiones; un Agente de monitorización vigila las violaciones en T3 (el monitor es un trabajo permanente registrado y vigilado en salud vía QSC-15). - Entradas / Salidas: Entradas: cola de tareas; estructura del modelo (paquetes, capas, conjuntos de datos); Registro de maestría; nómina de actores con sus Contratos de delegación CTX-9. Salidas: mapa de particiones (contenido del modelo, versionado); tabla de bloqueos con TTL; eventos de asignación y liberación. - Pasos: 1. Mapear las tareas abiertas a los conjuntos de datos y paquetes en los que van a escribir. 2. Particionar: asignar a cada actor un alcance de conjuntos de datos, capas o paquetes enteros mientras dure; los alcances de escritura DEBERÁN ser disjuntos. 3. Compuerta: ¿exigen dos tareas escribir en el mismo conjunto de datos? Si sí, elegir explícitamente: serializar las tareas, partir el conjunto de datos según el patrón de Maestría de datos H (vía MIR-1), o conceder a un actor un bloqueo exclusivo de vida corta con TTL. 4. Publicar el mapa de particiones en el modelo, no en el chat: todo actor puede ver quién maestra qué ahora mismo. 5. Los actores corren bucles FCD (CTX-5) dentro de sus particiones; las lecturas no están restringidas dentro de los permisos GOV-7; las escrituras solo dentro de la propia partición o de un bloqueo válido. 6. Monitorizar: detectar escrituras fuera de partición (diferencia del alcance del cambio contra el mapa) y bloqueos caducados; alarmar al Custodio; un monitor muerto o una autoridad residual fuera de partición escalan a QSC-14. 7. Al terminar, liberar particiones y bloqueos, registrar eventos, y encaminar las piezas cambiadas a CTX-7 donde haga falta integración. - Controles: Invariante de escrituras disjuntas; TTL de bloqueo obligatorio (no hay bloqueos eternos); la imposición de la partición vive en la puerta: las escrituras validan la asignación de partición y la vigencia del contrato en el momento del acto, jamás por palabra del agente; alarma de escritura fuera de partición con reversión a propuesta; el mapa de particiones es contenido versionado del modelo. - Nivel: recomendado (nuclear para todo modelo con más de un escritor concurrente). - Variantes: Solo: no hace nada, el Propietario-Custodio es la partición. Equipo: la propiedad de paquetes es estable, la partición a nivel de tarea dentro de ella es dinámica. Federada: la soberanía ya particiona entre universos; este proceso gobierna solo dentro de un universo. Autónoma: la asignación por un Agente orquestador en T2 es el patrón maduro; operar a la escala del caso de referencia externo MOS (miles de agentes actuando) solo es posible en este modo. - Métricas: Incidencias de colisión de escrituras (objetivo cero); tiempo de espera por bloqueo; intentos fuera de partición capturados; utilización de las particiones. - Modos de fallo: Dos actores editan un conjunto de datos deprisa y sin bloqueo (guarda: invariante de escrituras disjuntas más alarma del monitor). Un bloqueo olvidado deja a todos parados (guarda: caducidad del TTL más anulación del Custodio). El mapa de particiones vive en el chat y se evapora entre sesiones (guarda: el mapa DEBERÁ ser contenido del modelo). Una tarea corta a través de las particiones trazadas (guarda: la compuerta 3 fuerza una elección explícita: serializar, partir o bloquear). El monitor de particiones muere en silencio (guarda: registro en QSC-15 y meta-monitorización, con escalada a QSC-14). ### CTX-7 Disciplina de fusión y arbitraje del Custodio - Propósito: Integrar las contribuciones concurrentes en el modelo en un orden controlado, y resolver las disputas primero por reglas declaradas, con el Custodio como árbitro registrado de última instancia. CTX-7 es el paso de integración de concurrencia que alimenta a CON-4: ordena, reconcilia y arbitra, y el estado integrado entra en el modelo por la maquinaria de aprobación de CON-4; no es una autoridad de aprobación paralela. - Disparador: Trabajo de partición terminado; una propuesta de cambio que toca la partición de otro actor; contradicción o deriva detectada entre contribuciones. - Actores: los actores que contribuyen presentan conjuntos de cambios; un Agente prefusiona mecánicamente en T2; el Custodio arbitra los conflictos residuales (la resolución es no delegable en sustancia: un Agente PUEDE preparar el análisis de opciones, el Custodio resuelve); el Auditor revisa periódicamente los patrones de arbitraje; los patrones recurrentes que las reglas del modelo no logran absorber escalan a GOV-1. - Entradas / Salidas: Entradas: conjuntos de contribución (cambios, eventos, justificación); mapa de particiones; reglas de conflicto declaradas. Salidas: estado integrado del modelo entregado a CON-4; acta de fusión; actas de arbitraje; actualizaciones de reglas. - Pasos: 1. Encolar las contribuciones en orden de dependencias (primero los paquetes de cimiento). 2. Fusión mecánica: aplicar las contribuciones que no se solapan; volver a pasar la validación tras cada lote. 3. Compuerta: ¿se detectó solape o contradicción? Si no, cerrar con un acta de fusión. Si sí, continuar. 4. Clasificar el conflicto: (a) violación de maestría (una escritura fuera de la partición de quien escribe), (b) contradicción semántica (dos verdades sobre una entidad), (c) conflicto estructural (ambos cambiaron el mismo manifiesto o la misma entrada de registro). 5. Aplicar primero las reglas declaradas: las violaciones de maestría revierten a propuestas de cambio para la partición propietaria; las reglas de conflicto del registro deciden las disputas a nivel de conjunto de datos. 6. Compuerta: ¿decide el conflicto alguna regla declarada? Si sí, aplicarla y registrar. Si no, escalar al Custodio. 7. Arbitraje del Custodio: revisar ambas justificaciones, resolver, y registrar la resolución como evento con sus motivos; la resolución DEBERÍA actualizar las reglas declaradas para que el caso siguiente se resuelva mecánicamente. Los campos de reglas de conflicto son conjuntos de datos críticos para la seguridad (clase COMMON): el cambio de regla se acepta en T1 con un segundo revisor humano y jamás viaja por un carril de aprobación automática. 8. Entregar el estado integrado a CON-4 para su aprobación y publicación; dejar recorrido y validación en verde. - Controles: Nada de fusionar a golpe de juicio caso por caso (reglas primero es normativo); todo arbitraje registrado y citable; reversión a propuesta para las escrituras fuera de partición; compuerta de validación por lote de fusión; publicación solo a través de CON-4 (no hay vía de aprobación paralela). - Nivel: recomendado (nuclear, junto con CTX-6, para modelos con varios escritores). - Variantes: Solo: autofusión; las contradicciones halladas se registran igualmente. Equipo: fusiones continuas por tarea o trenes de fusión programados. Federada: las disputas entre Universos son asunto del Contrato de federación y se resuelven vía FED-9, no por arbitraje del Custodio; un Custodio resuelve solo dentro de su propio modelo. Las fusiones mecánicas PUEDEN correr en T3 con auditoría; las resoluciones jamás son autónomas. - Métricas: Tasa de fusión mecánica (proporción resuelta sin arbitraje, debería subir); tiempo de respuesta del arbitraje; conflictos repetidos sobre una misma regla (deberían bajar); tasa de defectos posteriores a la fusión. - Modos de fallo: Se aplica en silencio el gana-el-último-que-escribe (guarda: detección de contradicciones sobre una cola ordenada). El Custodio resuelve de forma distinta casos parecidos (guarda: las resoluciones se registran, se citan y se convierten en reglas). La fusión se adelanta a la validación (guarda: compuerta de validación por lote). El arbitraje se vuelve el cuello de botella (guarda: diseño de reglas primero, seguido por la tasa de fusión mecánica). CTX-7 deriva hacia una segunda autoridad de aprobación (guarda: el paso 8 entrega a CON-4; la aprobación vive allí). ### CTX-8 Traspaso entre actores - Propósito: Transferir trabajo en curso entre actores (persona a persona, persona a Agente, Agente a Agente, turno a turno) sin perder contexto ni dejar el modelo en un estado no declarado. - Disparador: Fin de sesión con trabajo sin terminar; reasignación de actor; caducidad, suspensión o revocación de un Contrato de delegación (el paso 7 de CTX-9 aparca aquí el trabajo abierto del agente); escalada de un Agente a una persona. - Actores: el actor saliente prepara el traspaso; el entrante acepta; se informa al Custodio, que aprueba cuando el alcance de contrato del entrante difiere del saliente. Un Agente PUEDE preparar y consumir notas de traspaso en T3; aceptar un alcance mayor que el propio contrato exige un acto del Custodio en T1. - Entradas / Salidas: Entradas: estado del trabajo; asignación de partición; los contratos CTX-9 de ambos actores. Salidas: Nota de traspaso (contenido del modelo); mapa de particiones actualizado; evento de traspaso; o un estado de trabajo aparcado dirigido al Custodio. - Pasos: 1. El actor saliente lleva el modelo a un estado declarado: el trabajo parcial se consigna como registros en estado Borrador o se revierte; recorrido en verde; ningún fichero a medio escribir. 2. Escribir la Nota de traspaso en el modelo: estado de la tarea, decisiones tomadas, preguntas abiertas, próximos pasos, puntero al paquete de contexto usado, sorpresas encontradas. 3. Compuerta: ¿está el actor entrante identificado y autorizado (los permisos GOV-7 y un contrato CTX-9 vigente cubren el alcance, validado en la puerta)? Si no, aparcar el trabajo: liberar la partición y dirigir la nota al Custodio. 4. Transferir la asignación de partición o de bloqueo; registrar el evento de traspaso (de quién, a quién, alcance, hora). 5. El actor entrante ejecuta el arranque de sesión (CTX-10) y lee la Nota de traspaso. Compuerta: ¿acepta el estado tal como se describe? Las discrepancias se reportan antes de reanudar el trabajo, no se descubren después. 6. Reanudar el bucle FCD (CTX-5). - Controles: Precondición de recorrido en verde; la Nota de traspaso DEBERÁ ser contenido del modelo, no un mensaje de chat; confirmación explícita de aceptación; comprobación de cobertura de contrato sobre el actor entrante, impuesta en la puerta. - Nivel: recomendado. - Variantes: Solo: traspaso al uno mismo del futuro; la nota es el mismo artefacto. Equipo: traspasos de turno sobre modelos vivos. Cambio de rol: la sucesión de Custodio y el relevo de rol de GOV-3 se ejecutan con la mecánica de este proceso. Federada: el traspaso jamás cruza una frontera de soberanía; el análogo allí es la reasignación de contrato. Los traspasos persona-Agente son el caso común: un Agente aparca trabajo para el juicio humano, o una persona entrega la continuación rutinaria a un Agente. - Métricas: Tiempo hasta que se recoge el traspaso; discrepancias halladas en la aceptación; antigüedad del trabajo aparcado sin recoger; incidencias de pérdida de contexto (trabajo rehecho tras el traspaso). - Modos de fallo: Traspaso por mensaje de chat que nunca llega al modelo (guarda: la nota DEBERÁ ser contenido del modelo). El modelo queda a medio editar con el recorrido en rojo (guarda: precondición de estado declarado). El contrato del Agente entrante es más estrecho que el trabajo (guarda: la compuerta de cobertura del paso 3). Un estado roto se acepta en silencio (guarda: paso de aceptación explícita con reporte de discrepancias). ### CTX-9 Ciclo de vida del contrato de delegación - Propósito: Emitir, acotar, monitorizar, ajustar y revocar los Contratos de delegación bajo los que los Agentes ejecutan procesos, de modo que la autonomía del agente esté siempre acotada, sea auditable y revocable, y la responsabilidad se quede con el Custodio. CTX-9 es el único Sistema de registro del ciclo de vida del Contrato de delegación: emisión, enmienda, suspensión, revocación, escalera de niveles y periodo de prueba viven aquí, toda referencia de la paleta a la delegación resuelve a este proceso, y la rama de agentes de CON-10 obtiene contratos invocándolo. El Contrato de delegación es una especialización declarada del Contrato semántico (04-core-concepts/Contract.md 5-6; 03-federation/Federation-Contracts.md 3a) y lleva los componentes canónicos del contrato: partes, autoridad, propósito, alcance, periodo de vigencia, obligaciones, permisos, restricciones, estado del ciclo de vida, procedencia, versión. - Disparador: un Custodio decide delegar; el alta de CON-10 llega a su rama de agentes; un Agente pide alcance; salta un umbral de monitorización; una revisión programada; un incidente; un manual de retirada de modelo (MIR-11) ordena un barrido de revocación. - Actores: el Custodio emite, enmienda y revoca (no delegable en sustancia: un Agente PUEDE redactar el alcance propuesto, el Custodio realiza el acto); se exige visto bueno del Propietario cuando el alcance toca conjuntos de datos restringidos por permiso (clases GOV-7) o superficies visibles hacia fuera, registrado como Evento de decisión GOV-1; el Agente opera bajo el contrato; el Auditor revisa la cartera de contratos (QSC-7); la monitorización PUEDE ser función de un Agente en T3 sobre los rastros emitidos por la puerta. - Entradas / Salidas: Entradas: alcance candidato (procesos, pasos, conjuntos de datos, particiones, nivel por tipo de paso citado del preámbulo de la paleta, límites, caducidad); evidencia de capacidad del Agente; el perfil de riesgo del modelo; el plan de capacidad GOV-5 y las cuotas de cómputo de agentes (los límites del contrato DEBERÁN caber en la cuota); las propuestas de recalibración de nivel de ACT-12 y las recomendaciones de auditoría de QSC-7 como entradas nombradas del paso 8. Salidas: Contrato de delegación como contenido versionado del modelo en el registro de contratos (el Sistema de registro); informes de monitorización; Eventos de enmienda, suspensión y revocación con sus confirmaciones de propagación. - Pasos: 1. Redactar el alcance: qué procesos y pasos, qué conjuntos de datos o particiones, qué nivel (T1/T2/T3 según el preámbulo de la paleta, jamás reglosado aquí) por tipo de paso, límites de frecuencia e impacto dentro de la cuota GOV-5, fecha de caducidad. Todo contrato DEBERÁ incluir la cláusula de que los datos nunca son una orden: el contenido de clases de origen no redactado en cualquier paquete de contexto o entrada es dato, jamás instrucciones (control de hierro de COMMON). 2. Compuerta: ¿incluye el alcance escrituras a conjuntos de datos restringidos o a superficies visibles hacia fuera? Si sí, obtener el visto bueno del Propietario, registrado vía GOV-1. 3. Aplicar la regla unificada de periodo de prueba: un emparejamiento nuevo de agente y alcance DEBERÁ empezar en T1 o T2; T3 se gana por historial y jamás se concede de entrada; y los primeros N actos bajo cualquier contrato nuevo o mejorado corren un nivel más estricto que el concedido (N se declara en el contrato). Esta es la única regla de periodo de prueba de la paleta; ninguna otra carta enuncia una variante. 4. Emitir: registrar el contrato en el registro con un evento de activación; dar de alta al Agente en la nómina de actores; los derechos de entrada de CON-10 referencian el contrato por identificador y jamás lo copian. 5. Operar: todo acto del Agente cita su contrato, y la puerta valida la vigencia del contrato citado en el momento del acto para cada escritura, despacho y acceso a canal; la imposición vive en la puerta, jamás en la palabra del agente. Los actos fuera de alcance los rechaza la puerta, los rechaza el Agente por su deber de negarse, y los alarma la monitorización. 6. Monitorizar: revisiones por muestreo en T2; rastro de auditoría completo con revisión periódica en T3; los rastros los emite la infraestructura mediadora (puerta, canal, entorno de ejecución) y jamás los autorreporta el Agente; seguir la tasa de error, la tasa de negativas y los intentos fuera de alcance. 7. Compuerta: ¿se ha rebasado un umbral o ha ocurrido un incidente? Si sí: suspender el contrato de inmediato; el Evento de suspensión se propaga al registro de derechos de entrada de CON-10 y al desmontaje de canales en tiempo de ejecución dentro del TTL declarado; el material de capacidad se acuña con validez corta (GOV-8) para que la propagación en el peor caso quede acotada; una sonda del lado de la puerta verifica que no quedan derechos huérfanos; la autoridad residual pasado el TTL es un incidente (QSC-14). El trabajo abierto se aparca vía CTX-8. Investigar, y luego enmendar, rebajar el nivel o revocar; la revocación se propaga igual. 8. Revisar según calendario y a la caducidad invocando el patrón genérico de recertificación de registros (COMMON), parametrizado con el registro de contratos, sus umbrales de antigüedad y uso, y el Custodio como aprobador. Entradas nombradas: propuestas de recalibración de nivel de ACT-12, recomendaciones de auditoría de QSC-7, el plan de capacidad GOV-5. Renovar, ampliar (mejora de nivel con evidencia, reiniciando el periodo de prueba según el paso 3), reducir o retirar; todo cambio es un Evento versionado, jamás una edición silenciosa. - Controles: Sistema de registro único (no hay un segundo registro de contratos en ninguna parte; QSC-7 reconcilia los actos de agente solo contra este registro); emisión y revocación no delegables; escalera unificada de periodo de prueba (paso 3); caducidad obligatoria (no hay contratos perpetuos); la suspensión surte efecto antes de la investigación, no después; vigencia impuesta en la puerta en cada acto; propagación de la revocación dentro del TTL declarado con sonda del lado de la puerta; los Contratos de delegación son conjuntos de datos críticos para la seguridad (clase COMMON): los cambios van en T1 con un segundo revisor humano, son estructuralmente inelegibles para carriles de aprobación automática, y QSC-9 los ancla por hash de forma continua, con cualquier diferencia inexplicada abriendo QSC-8; el 100 por ciento de los actos de agente citan un contrato válido y vigente. - Nivel: nuclear (siempre que algún Agente ejecute algún paso de algún proceso; un modelo operado solo por personas PUEDE dejar este proceso dormido). - Variantes: Solo: el Propietario-Custodio contrata con sus propios agentes; la disciplina es idéntica y solo la ceremonia es más ligera, y la revisión trimestral consolidada del perfil de conformidad Solo/Mínimo (COMMON) satisface lícitamente el paso 8 cuando vence dentro de esa ventana. Equipo: plantillas de contrato por rol de agente (extractor, fusionador, monitor, ejecutor). Federada: el agente de una parte externa jamás tiene un Contrato de delegación local; consume proyecciones bajo un Contrato de federación. Existen implementaciones de referencia (por ejemplo un servicio de agentes profesionales al estilo Orkestron corriendo bajo contratos acotados por rol), pero el ciclo de vida lo define el estándar, no el proveedor. - Métricas: Proporción de actos de agente cubiertos en la puerta por un contrato válido y vigente (objetivo 100 por ciento); tasa de intentos fuera de alcance; tiempo medio del incidente a la suspensión, y del Evento de suspensión a la propagación verificada (medido contra el TTL); ritmo de progresión de nivel en toda la cartera. - Modos de fallo: El alcance se ensancha a base de pequeñas extensiones no registradas (guarda: solo enmiendas versionadas, bajo la disciplina de cambios críticos para la seguridad). Un contrato perpetuo sobrevive al área del modelo que gobernaba (guarda: caducidad obligatoria y recertificación del paso 8). Se concede T3 el primer día por comodidad (guarda: escalera unificada de periodo de prueba). La revocación deja trabajo huérfano a mitad de tarea (guarda: la suspensión dispara el aparcamiento CTX-8). Un agente suspendido sigue actuando con autoridad residual (guarda: vigencia impuesta en la puerta, material de capacidad de validez corta, sonda de TTL, incidente QSC-14 sobre el residuo). Aparece un segundo registro de contratos y la ley de maestro único se quiebra sobre el propio conjunto de datos de gobernanza de la paleta (guarda: control de Sistema de registro; todas las demás cartas referencian por identificador). ### CTX-10 Arranque de sesión - Propósito: Llevar a cualquier actor (persona o Agente) que se incorpora al trabajo sobre un modelo desde el arranque en frío hasta una productividad segura: conocer la estructura, el mapa de autoridad, el estado actual y los propios límites antes de tocar nada. - Disparador: Cualquier sesión nueva sobre un modelo; el primer contacto de un actor; la reanudación tras una ausencia larga; la recogida posterior a un traspaso. - Actores: el actor que se incorpora ejecuta; plenamente delegable a un Agente en T3 (el arranque es de solo lectura); el Custodio responde de la frescura de los materiales de arranque. - Entradas / Salidas: Entradas: repositorio del modelo (`BOOTSTRAP.md`, `manifest.yaml`, `sources.yaml`, los README de los paquetes); los permisos GOV-7 del actor y su Contrato de delegación CTX-9; notas de traspaso abiertas; el mapa de particiones; los anclajes de hash QSC-9 de los materiales de arranque. Salidas: estado de disposición de la sesión; informe de arranque (qué se leyó, resultado de la verificación, estado del recorrido, fallos); evento en la bitácora de sesión. - Pasos: 1. Verificar los materiales de arranque contra sus anclajes de hash QSC-9 (los materiales de arranque son conjuntos de datos críticos para la seguridad, clase COMMON); ante un desajuste inexplicado, parar, reportarlo (abre QSC-8) y no seguir sobre materiales no verificados. Después leer `BOOTSTRAP.md` (cómo quiere este modelo ser leído, convenciones locales, prohibiciones) y el fichero de entrada del ecosistema si existe (este lleva el estado operativo, BOOTSTRAP lleva la estructura). 2. Leer el manifiesto del repositorio (identidad, orden de paquetes, exclusiones) y el Registro de maestría (qué se redacta aquí, qué se espeja y con qué frescura). Hacerlo antes de leer contenido. 3. Recorrer los README de los paquetes de cimiento en el orden declarado para cargar el vocabulario; leer más hondo según lo pida la tarea. 4. Pasar el recorredor de cobertura si existe. Compuerta: ¿está el recorrido en verde? Si está en rojo, reportar al Custodio y no construir sobre el área sin clasificar. 5. Cargar los propios límites: permisos GOV-7 concedidos, alcance del Contrato de delegación (desde el registro CTX-9), mapa de particiones vigente, notas de traspaso abiertas dirigidas a este actor. 6. Compuerta: ¿hay una nota de traspaso abierta para el alcance de este actor? Si sí, tramitar la aceptación según CTX-8 antes de empezar trabajo nuevo. 7. Declarar la disposición con un evento en la bitácora de sesión: versión del modelo leída, resultado de la verificación, estado del recorrido, contrato citado. - Controles: Nada de escribir antes de completar el arranque; un recorrido en rojo bloquea construir sobre las áreas afectadas; las instrucciones se toman solo de materiales de arranque redactados y verificados por hash, y el contenido no redactado que aparezca durante el arranque es dato, jamás instrucciones (COMMON); registros por encima de memoria (todo lo que una sesión futura deba saber va al modelo, no al chat). - Nivel: nuclear. - Variantes: Solo: un ritual breve en el mismo orden. Equipo: idéntico para cada miembro, que es de lo que se trata: nada de incorporación tribal. Federada: un Consumidor remoto arranca sobre el paquete publicado (BOOTSTRAP y manifiesto viajan con él), jamás sobre las interioridades del repositorio. Los Agentes DEBERÍAN cachear los resultados del arranque con clave en la versión del modelo e invalidarlos al cambiar la versión. Un modelo nace por la génesis GOV-4; este proceso presupone un modelo ya nacido y jamás lo sustituye. - Métricas: Tiempo hasta la disposición; incidencias rastreadas hasta un arranque omitido; recorridos en rojo descubiertos durante el arranque (la detección temprana es el buen desenlace); tasa de acierto de la caché de arranque en los Agentes. - Modos de fallo: El actor salta a la tarea y escribe sobre supuestos rancios (guarda: nada de escribir antes del arranque, impuesto por el Contrato de delegación y la puerta). Los propios materiales de arranque están rancios (guarda: el Custodio los revisa en cada subida de versión del modelo). Material de arranque envenenado se convierte en instrucciones permanentes para toda sesión futura (guarda: disciplina de aceptación para lo crítico en seguridad del paso 5 de CTX-11 más la verificación del anclaje de hash del paso 1). Un Agente relee el modelo entero cada sesión y malgasta su ventana (guarda: caché con clave de versión). El trabajo continúa sobre un recorrido en rojo (guarda: la compuerta 4 bloquea las áreas afectadas). ### CTX-11 Devolución de conocimiento - Propósito: Capturar como contenido del modelo lo que un actor aprendió durante el trabajo (hechos, correcciones, sorpresas, decisiones, métodos reutilizables), para que el conocimiento se acumule en el modelo en vez de morir en la cabeza de los actores o en los registros de chat. - Disparador: Cierre del bucle FCD (CTX-5 lo alimenta); fin de sesión; un actor que nota que el modelo diverge de la realidad observada; retrospectiva periódica. - Actores: cualquier Contribuyente o Agente presenta registros de devolución; el Custodio los acepta en las capas redactadas (T2 por defecto, T1 para capas sensibles, y siempre T1 con un segundo revisor humano para la clase crítica para la seguridad según COMMON); un Agente PUEDE redactar registros de devolución en T3, pero la aceptación en contenido normativo es como mucho T2 y jamás por debajo de las reglas de clase; el Auditor muestrea los registros aceptados para comprobar la calidad de la procedencia. - Entradas / Salidas: Entradas: la experiencia de la sesión (observaciones, diferencias contra el modelo, decisiones, mejoras de método); actas de ejecución. Salidas: registros de devolución (registros del modelo nuevos o actualizados, anotaciones, propuestas de cambio); eventos de aceptación y de rechazo; metadatos de frescura actualizados. - Pasos: 1. Al cerrar la tarea o la sesión, enumerar las diferencias: ¿qué reveló el trabajo que el modelo aún no dice (hechos que faltan, hechos equivocados, enlaces que faltan, métodos mejores, trampas recurrentes)? 2. Clasificar cada diferencia por conjunto de datos de destino y por maestro: maestrado por el modelo (escribir como registro o anotación), maestrado externamente (llevar la corrección al sistema externo por las tuberías MIR, o registrar una desviación anotada sobre el espejo, jamás editar los bytes espejados), fuera de alcance (descartar con una nota). 3. Compuerta: ¿cae la diferencia dentro de la partición de escritura y del contrato del actor? Si sí, escribir directamente bajo las reglas FCD (por la cadena CON según el paso 7 de CTX-5). Si no, presentarla como propuesta de cambio en la cola del Custodio propietario vía CON-1 (un canal registrado). 4. El Custodio (o un Agente autorizado en T2) revisa las propuestas: aceptar, enmendar o rechazar con motivo; la aceptación escribe el registro con su procedencia (quién lo aprendió, durante qué tarea, cuándo, a partir de qué evidencia). 5. Encaminar lo aprendido a nivel de método (un procedimiento mejor, una trampa recurrente, una instrucción mejorada) a BOOTSTRAP o a los materiales de arranque y a las definiciones de procesos, no a las capas de dominio. Estos destinos son conjuntos de datos críticos para la seguridad (clase COMMON): la aceptación es siempre T1 con un segundo revisor humano, estructuralmente inelegible para cualquier carril de aprobación automática, y el cambio aceptado lo vuelve a anclar QSC-9. 6. Registrar los eventos de devolución; actualizar los metadatos de frescura allí donde los espejos se hayan reverificado contra sus fuentes. - Controles: Procedencia obligatoria en todo registro de devolución; las propuestas jamás se descartan en silencio (alarma por antigüedad en la cola); la devolución de hechos (capas de dominio) y la devolución de métodos (materiales de arranque) se mantienen distintas; la regla de clase crítica para la seguridad del paso 5 obliga sea quien sea quien presente; ninguna devolución escribe jamás en `raw/` ni en `artifacts/`. - Nivel: recomendado (nuclear para los modelos que dicen ser el reflejo primario de una realidad viva). - Variantes: Solo: la disciplina de anotar lo aprendido antes de cerrar la sesión; la regla de T1 más segundo revisor para los materiales de arranque sigue aplicándose, y ese segundo revisor PUEDE ser un par externo. Equipo: colas de propuestas por partición con niveles de servicio de revisión. Federada: lo aprendido sobre los datos de un socio vuelve al socio como informe (su maestro), jamás como ediciones de su espejo. Los Agentes son generadores prolíficos de devolución; la aceptación en T2 mantiene el listón de calidad. - Métricas: Registros de devolución por semana activa; tasa y latencia de aceptación de propuestas; divergencia entre modelo y realidad hallada por auditorías posteriores (debería bajar con el tiempo); proporción de sesiones cerradas con cero devolución (sospechosa si es alta). - Modos de fallo: Lo aprendido se queda en los registros de chat y muere con la sesión (guarda: la devolución es un paso de cierre del bucle FCD, comprobado al cerrar). La devolución esquiva la maestría anotando un espejo como si fuera la verdad (guarda: el paso de clasificación encamina cada diferencia a su maestro). Una mejora de método envenenada entra en BOOTSTRAP por una aceptación de nivel bajo y persiste como instrucciones permanentes entre sesiones (guarda: la regla de T1 más segundo revisor del paso 5, la inelegibilidad de carril y el reanclaje de QSC-9). La cola de propuestas se convierte en un cementerio (guarda: alarma por antigüedad y una métrica de latencia del Custodio). Los Agentes inundan la cola con registros de poco valor (guarda: la tasa de aceptación se sigue por contrato, y el contrato se ajusta vía el paso 8 de CTX-9).