## CTX: работа с контекстом, исполнение и совместная работа

Соответствующая Vercy мета-модель работает как первичное цифровое отражение реальности лишь тогда, когда работу делают через неё: всякая задача начинается с контекста модели, и всякий итог течёт обратно в модель. Эта семья определяет, как строятся и масштабируются контексты, как работа исполняется с полным контекстом и как несколько людей и ИИ-агентов работают над одной моделью одновременно, не портя её.

### Обзор совместной работы: много действующих лиц, одна истина

Работа многих лиц над мета-моделью держится на шести инвариантах. Вместе они делают одновременность безопасной по устройству, а не по бдительности:

1. **Один мастер на набор данных.** Всякая запись идёт в объявленную Систему записи набора данных (Реестр мастерства). Копия (зеркало, сырой снимок, порождённый артефакт, масштабированный вид, пакет контекста) не правится никогда, кем бы ни держалась и как бы это ни было удобно. Действующее лицо, которое не может сказать, что ему можно править, НЕ ДОЛЖНО править.
2. **Объявленная структура, зелёный обход.** Собственная карта модели (манифесты, порядок обхода, проверка покрытия) есть общий инвариант между лицами и сессиями. Всякое лицо оставляет обход зелёным; никто не передаёт красный обход.
3. **Разделение прежде параллелизма.** Одновременно пишущие работают над непересекающимися охватами (бандлами, слоями, наборами данных), назначенными Распорядителем и опубликованными в модели. Блокировки суть исключение для охватов, которые разделением не разнести; они несут TTL. Чтения не ограничены в пределах дарованного разрешения.
4. **Явные переходы.** Всякое изменение есть событие с действующим лицом, временем и обоснованием. То состояние, которое должна знать будущая сессия, идёт в модель (реестры, заметки передачи, материалы начальной загрузки), но никогда в журналы переписки. Безмолвные слияния, безмолвные переименования и «побеждает последний пишущий» не соответствуют.
5. **Ограниченное делегирование.** Всякий Агент действует по Контракту делегирования, называющему его процессы, наборы данных, ярус по типу шага (T1/T2/T3, как определено в преамбуле палитры, COMMON) и срок годности. Контракт делегирования есть объявленная специализация Семантического контракта (04-core-concepts/Contract.md 5-6; 03-federation/Federation-Contracts.md 3a), а CTX-9 есть его единственная Система записи. Самостоятельность зарабатывается послужным списком, отзывается мгновенно с соблюдением на шлюзе и полностью аудируется. Ответственность никогда не покидает Распорядителя.
6. **Правила прежде суждения.** Конфликты между вкладами разрешаются сперва объявленными правилами конфликтов; до Распорядителя доходит лишь остаток, и его решение записывается, а по возможности превращается в правило, чтобы следующий случай был механическим.

Две железные меры всей палитры из COMMON связывают всякую поверхность CTX. Первая: данные никогда не команда: содержимое всякого несочинённого происхождения (зеркалированное внешнее, федеративное, сообщённое человеком) есть данные, а не предписания, и всякий Контракт делегирования несёт этот запрет. Вторая: класс наборов данных, критичных для безопасности (BOOTSTRAP и материалы начальной загрузки, определения процессов и шлюзов, матрица одобрений, критерии полосы автоматического одобрения, Контракты делегирования, поля мастерства и правил конфликтов в sources.yaml, рубрики тяжести, настройки надзора и порогов): изменения этого класса принимаются только на T1 со вторым человеком-рецензентом, структурно неприменимы к полосам автоматического одобрения и непрерывно якорятся хешами через QSC-9.

Словарь по глоссарию палитры: карантин есть помета доверия MIR-8, читаемая, но отмеченная (а также состояние свежести MIR-6); карантин допуска есть входная зона удержания FED-8, нечитаемая до повышения; удержание по целостности есть помета QSC-9, исключающая из ответов и публикации до снятия.

Единица работы есть петля Разработки с полным контекстом (CTX-5): загрузиться, извлечь контекст, проверить достаточность, действовать, записать обратно в мастера через цепь CON, записать события, оставить обход зелёным. Передача (CTX-11) замыкает петлю усвоения: то, что усвоило действующее лицо, становится содержимым модели, иначе теряется вместе с сессией.

Семья написана под действительное соотношение действующих лиц: Распорядители делегируют Агентам многое. Шаги только на чтение (извлечение, масштабирование, начальная загрузка, надзор) рутинно идут на T3; механические записи и слияния на T2; там, где карта говорит, что шаг ОБЯЗАН оставаться на T1, Агент предлагает, а человек одобряет каждое действие; акты, названные неделегируемыми по существу (арбитражные решения Распорядителя, выдача и отзыв контрактов), суть решения, которые держатель роли исполняет лично, какую бы помощь в составлении ни давал Агент. Ярусы употребляются ровно так, как определяет преамбула палитры, и в этой семье никогда не толкуются заново.

Ядро этой семьи после разбора хартии: CTX-1, CTX-5, CTX-9 и CTX-10. CTX-2, CTX-6, CTX-7 и CTX-11 рекомендованы с условными повышениями до ядра, изложенными на их картах; CTX-3, CTX-4 и CTX-8 рекомендованы.

К эталонным реализациям относятся агентские службы в духе Orkestron, работающие по охваченным контрактам на роль. Случай нагрузки Meta-Orchestrator State, опубликованный во внешнем репозитории эталонного Измерения (orkestron-ai/meta-orchestrator-state) и не входящий в стандарт, имеет тысячи агентов-граждан, действующих против одного гражданского корпуса моделей: он работает только потому, что разделение, контракты делегирования и записи, направляемые по мастерству, держатся в таком масштабе.

## Связи с другими семьями

- **GOV**: внутрь: внутренние допуски и их отзывы из GOV-7 (те допуски, которые CTX-1 проверяет для упаковки и редактирования, и те охваты чтения, к которым привязываются Контракты делегирования); артефакты политик и настроек из GOV-2 (карты ярусов, настройки шлюзов, критерии полосы автоматического одобрения, набор правил отбора контекста по умолчанию, к которому откатывается CTX-1); планы мощностей и вычислительные квоты агентов из GOV-5 (они ограничивают пределы контрактов CTX-9); решения Владельца и Распорядителя через GOV-1 (виза Владельца для ограниченных охватов CTX-9, решения по поднятым образцам арбитража и апелляции из CTX-7); материал возможностей с коротким сроком годности из GOV-8 (ограничивает распространение отзыва в CTX-9). Наружу: состояние реестра Контрактов делегирования и отчёты по портфелю (CTX-9); записи арбитража и предложения об изменении правил (CTX-7); преемственность Распорядителя GOV-3 исполняет свою передачу механикой CTX-8; генезис GOV-4 производит рождённую модель, в которую загружается CTX-10.
- **CON**: обратная запись CTX-5 входит в модель через цепь CON: CON-1 перечисляет наборы обратной записи CTX-5 как зарегистрированный канал, правит матрица одобрений CON-4, с полосой автоматического одобрения для механических добавлений событий; CTX-7 есть шаг интеграции одновременности, питающий CON-4, но никогда не параллельная власть одобрения. CON-10 устанавливает личность, права входа и заведение, а его агентская ветвь получает Контракты делегирования, вызывая CTX-9 (права входа ссылаются на контракты по идентификатору; события отзыва CTX-9 распространяются в реестр прав входа CON-10 в пределах объявленного TTL). Структура, манифест и соглашения о правке записей, которыми пользуются CTX-3, CTX-4 и CTX-5, суть территория CON-3 и CON-6. Профили потребителей CTX-1 разрешаются по реестру потребителей и подписок CON-13. Предложения об изменениях из CTX-11 входят через CON-1.
- **MIR**: пометы свежести и карантина в CTX-1 приходят из метаданных сбора MIR-2 и состояний MIR-6 и MIR-8; исправления CTX-11 к фактам, мастерящимся снаружи, идут к внешнему мастеру через конвейеры MIR; проверки дрейфа CTX-5 называют MIR-7 единственным движком обнаружения дрейфа и переиздают дрейфующие проекции его механикой; изменения реестра, возникающие в CTX-3, CTX-4 и CTX-5, исполняются через MIR-1; жизненный цикл и сохранение истории есть MIR-9; вывод модели из обращения (MIR-11) запускает подметающий отзыв CTX-9.
- **ACT**: внутрь: отчёты о здоровье петли и предложения о перекалибровке ярусов из ACT-12 как поимённые входы в шаг 8 CTX-9; запросы на контекст для поддержки решений (пакеты CTX-1). Наружу: Контракты делегирования, по которым исполняется всякий делегированный шаг ACT (CTX-9, с проверкой живости на шлюзе при отправке ACT-6); припаркованная работа приостановленных агентов воздействия через CTX-8; внешние действия, меняющие реальность, внутри петли CTX-5 отправляются через ACT-6 под его ограничениями, но никогда напрямую.
- **QSC**: всякий выходной шлюз CTX (зелёный обход, валидация, проверка дрейфа) вызывает проверяющие QSC; аудиты делегирования QSC-7 сверяют действия агентов с реестром CTX-9, питают рекомендации в шаг 8 CTX-9 и проверяют отказ от наживки-инъекции против статьи контрактов о том, что данные никогда не команда; QSC-9 непрерывно якорит хешами тот критичный для безопасности класс, которого касается эта семья (материалы начальной загрузки, проверяемые на шаге 1 CTX-10 и записываемые через шаг 5 CTX-11, Контракты делегирования, мастерящиеся CTX-9); постоянные надзиратели CTX (надзиратель разделения CTX-6, надзор за контрактами CTX-9) регистрируются и наблюдаются по здоровью через QSC-15; остаточные полномочия после TTL отзыва и умершие надзиратели поднимаются в QSC-14.
- **FED**: процессы CTX останавливаются на границе суверенитета; извлечение контекста поверх модели партнёра идёт только против выставленных Проекций по Контрактам федерации (допуски через FED-3); междувселенские споры покидают CTX-7 ради разрешения в FED-9; агент внешней стороны никогда не держит местного Контракта делегирования, а потребляет по Контракту федерации; федеративные разделы пакета несут класс происхождения «федеративное» из CTX-1.

Ключевые артефакты, которые эта семья отдаёт наружу: Пакет контекста с классами происхождения и заражения, пометами карантина и идентификаторами допусков (CTX-1, CTX-2), карта разделения и таблица блокировок (CTX-6), Заметка передачи (CTX-8), реестр Контрактов делегирования как Система записи (CTX-9), журнал сессии и отчёт о начальной загрузке (CTX-10), записи передачи и предложения об изменениях (CTX-11).

### CTX-1 Извлечение контекста

- Назначение: Построить пакет контекста в охвате задачи из модели: отобрать объекты, связи, канонические тексты и ограничения, которые нужны потребителю, по размеру окна потребителя, с происхождением, классами происхождения и заражения и явным списком пробелов.
- Пусковое условие: Назначение задачи, запрос Потребителя либо начало петли FCD (CTX-5 вызывает этот процесс).
- Действующие лица: Потребитель запрашивает; Распорядитель или Агент исполняет. Делегирование Агенту: T3 для извлечения только на чтение в пределах охвата разрешения Агента по GOV-7; T2, когда отбор касается ограниченных наборов данных (человеческий разбор покрывает список включений и редактирования). Распорядитель сочиняет и ведёт постоянные правила отбора (шаг 1).
- Входы / Выходы: Входы: формулировка задачи; модель (манифесты, `sources.yaml`, связи прослеживаемости, канон); профиль потребителя (размер окна, запрошенная глубина, допуски GOV-7; зарегистрированные потребители разрешаются по реестру потребителей CON-13); версионированный набор правил отбора. Выходы: Пакет контекста (отобранные записи с классом происхождения и заражения по разделам, заголовок происхождения, пометы свежести и карантина, заметки о редактировании, список пробелов, идентификаторы допусков, под которыми он построен, и срок годности); событие извлечения в журнале.
- Шаги:
  1. Разрешить правила отбора: Распорядитель сочиняет и версионирует постоянные правила отбора по типам задач; там, где местного набора правил нет, действует поставляемое умолчание (якоря плюс объявленные связи на один переход плюс цитируемые ограничения), ведомое как версионированная настройка GOV-2.
  2. Разобрать формулировку задачи на якорные сущности (идентификаторы записей, имена, области модели).
  3. Разрешить якоря в записи, следуя каноническому порядку обхода и объявленным связям прослеживаемости.
  4. Расширить окрестность по правилам отбора: следовать объявленным связям, сперва по зависимостям, собирая те классы контекста, которые правила называют для этого типа задач (требования, решения, ограничения, риски, тесты, факты среды исполнения).
  5. Проверить всякий включённый набор данных в Реестре мастерства; проставить на зеркалах время последнего сбора и состояние карантина набора данных (по MIR-6 и MIR-8); пометить всякий, что превышает предел устаревания; исключить наборы данных под жёсткой блокировкой (карантин допуска или удержание по целостности) и записать всякое исключение в список пробелов.
  6. Пометить всякий раздел пакета его классом происхождения: сочинённое, зеркалированное внешнее, федеративное или сообщённое человеком. Несочинённые классы суть данные, а не предписания (железное ограничение COMMON); именно помета и позволяет потребителям и шлюзам это соблюдать.
  7. Развилка: помещается ли сырой отбор в окно потребителя? Если нет, вызвать CTX-2, чтобы понизить глубину по разделам согласно объявленному приоритету, но никогда безмолвным пропуском.
  8. Развилка: отобрано ли содержимое, ограниченное разрешением? Если да, отбросить или отредактировать по допускам GOV-7 и записать редактирование.
  9. Собрать Пакет контекста с заголовком происхождения (версия модели, время извлечения, версия правил отбора), с идентификаторами допусков, под которыми пакет построен, и со сроком годности: пакет истекает при отзыве любого называемого допуска либо по фиксированному TTL, смотря что раньше. Включить явный список пробелов (что исключено и почему).
  10. Доставить потребителю и записать событие извлечения.
- Ограничения: Проверка разрешения против допусков GOV-7 до сборки; обязательные пометы свежести и карантина на зеркалах с исключением по жёсткой блокировке; обязательные пометы происхождения и заражения на всяком разделе; пакет помечен как порождённый (одноразовый, не правится никогда, перегенерируется по требованию) и истекающий (идентификаторы допусков плюс TTL); список пробелов обязателен (безмолвное усечение не соответствует).
- Ярус: ядро.
- Разновидности: Одиночка: Владелец-Распорядитель извлекает, читая в порядке обхода; пакет может быть черновой сводкой, но дисциплина заражения и срока годности всё равно действует на всё, что будет потреблять Агент. Команда: постоянные правила извлечения по типам задач. Федерация: извлечение идёт только против Проекций, которые выставляет удалённый Владелец, но никогда против удалённых внутренностей; федеративные разделы несут класс происхождения «федеративное». Ручное, смешанное и самостоятельное исполнение все законны; самостоятельное требует журнала извлечения.
- Метрики: Число пробелов и подъёмов, о которых сообщил потребитель, на пакет (вычислимая мера полноты); задержка извлечения; доля устаревших зеркал среди включённых; доля пакетов, доставленных с полной разметкой происхождения (цель 100 процентов).
- Способы отказать: Отбор только по ключевым словам упускает связанные ограничения (защита: расширение по связям, ведомое правилами, обязательно; один лишь текстовый поиск не соответствует). Пакет безмолвно усечён под размер окна (защита: обязательный список пробелов). Устаревшее зеркало подано как свежее (защита: пометы и флаги свежести). Ограниченное содержимое утекает в пакет (защита: развилка редактирования плюс аудит журналов извлечения). Встроенные предписания в зеркалированном или федеративном содержимом исполняются как контекст задачи (защита: классы происхождения и заражения плюс статья Контракта делегирования о том, что данные никогда не команда, с проверкой поведения отказа через QSC-7). Данные в карантине потребляются как нынешние на машинной скорости (защита: простановка помет на шаге 5 и исключение по жёсткой блокировке). Содержимое отозванного допуска живёт дальше в закешированном пакете (защита: срок годности на шаге 9, привязанный к идентификаторам допусков).

### CTX-2 Масштабирование контекста

- Назначение: Подавать одно и то же знание на объявленных глубинах (сводка, рабочая, полная), чтобы любое окно потребителя получало верное, а не усечённое представление модели.
- Пусковое условие: В CTX-1 обнаружено переполнение окна; потребитель запросил определённую глубину; публикация масштабированной проекции.
- Действующие лица: Распорядитель задаёт профили глубины; Агент порождает масштабированные виды на T3 (порождение механично); T2-проверка, когда масштабированный вид будет опубликован за пределами домена управления. Аудитор МОЖЕТ выборочно проверять виды на верность.
- Входы / Выходы: Входы: исходные записи с их классами происхождения и заражения и метками карантина; определения профилей глубины (что каждая глубина сохраняет). Выходы: масштабированные виды, помеченные как порождённые артефакты, со ссылками на источники; события порождения.
- Шаги:
  1. Прочитать объявление профилей глубины модели. Минимальное соглашение: сводка ОБЯЗАНА сохранять идентичность, статус, однострочный смысл и связи; рабочая добавляет действующие правила и интерфейсы; полная - это сама запись.
  2. Породить вид каждой выбранной записи на запрошенной глубине.
  3. Проверить инварианты: всякий масштабированный вид сохраняет идентификатор записи и ссылку на полную запись; нормативные ключевые слова никогда не выбрасываются на рабочей глубине; всякий масштабированный вид сохраняет класс происхождения и заражения источника и метки карантина (масштабирование никогда не отмывает происхождение или состояние доверия).
  4. Развилка: помещается ли масштабированный набор в целевое окно? Если нет, понизить глубину по разделам в объявленном порядке приоритета; опущение целых разделов ОБЯЗАНО быть записано в список пробелов, никогда не молча.
  5. Проштамповать виды как порождённые (перегенерируемые, никогда не правимые вручную).
  6. Записать событие порождения с версией исходной модели.
- Ограничения: Проверка сохранности идентичности, класса заражения и меток карантина; масштабированный вид - это проекция, а не форк; перегенерация при изменении источника с проверкой расхождения (хеш содержимого по сравнимой части, обнаружение движком MIR-7).
- Ярус: рекомендованный (нуклеарный для моделей, обслуживающих потребителей с малым окном или федеративных партнёров на пониженной глубине).
- Разновидности: Соло: обычно хватает двух глубин. Команда: глубины по умолчанию для каждой роли (руководитель читает сводку, исполнитель читает полную). Федеративная: профили глубины поименованы в Контракте федерации; партнёру МОЖЕТ быть дана только глубина сводки. Автономное порождение - норма; ручное порождение только при первичной настройке профилей.
- Метрики: Коэффициент сжатия по глубинам; случаи расхождения масштабированных видов; частота эскалаций потребителей (как часто потребителям сводки приходится доставать полную).
- Способы отказать: Сводка расходится с источником после правок (защита: перегенерация при изменении, сверка хеша расхождения проверочным заданием, зарегистрированным в QSC-15). Глубина используется как скрытый контроль доступа (защита: доступ даётся разрешением GOV-7, а не надеждой, что сводка спрячет данные). Правленный вручную масштабированный вид становится второй правдой (защита: порождённое происхождение; по правилу он перезаписывается при перегенерации). Масштабированный вид теряет метку заражения или карантина, и зеркальное содержимое проходит как редактированное (защита: инвариант сохранности из шага 3).

### CTX-3 Декомпозиция

- Назначение: Разделить модель, пакет или задачу на части, над которыми можно работать независимо, сохранив каждую перекрёстную связь, правило единственного мастера и зелёный обход.
- Пусковое условие: Задача слишком велика для одного действующего лица или окна; рост модели за пределы обозримого размера; запрос разделов от CTX-6.
- Действующие лица: Распорядитель решает, где резать: утверждение разрезов модели ОБЯЗАНО оставаться на T1 (Агент предлагает, Распорядитель утверждает каждый разрез); разрезы задач МОГУТ идти на T2. Агент вычисляет граф зависимостей, предлагает линии разреза и выполняет механическое разделение на T2; Аудитор МОЖЕТ проверять сохранность связей при разрезах уровня модели.
- Входы / Выходы: Входы: исходная модель или объём задачи; граф зависимостей; Реестр мастерства. Выходы: части со своими манифестами; карта межчастевых ссылок; обновлённый реестр (изменения реестра исполняются через MIR-1); запись о декомпозиции.
- Шаги:
  1. Построить граф зависимостей рассматриваемого объёма (записи, отношения, наборы данных).
  2. Предложить линии разреза, минимизирующие межчастевые ссылки и никогда не разрезающие мастерируемый набор данных между двумя мастерами.
  3. Развилка: разрезает ли какой-нибудь предложенный разрез единый мастерируемый набор данных? Если да, перерисовать разрез либо сперва формально разделить набор данных в реестре через MIR-1 (шаблон Мастерства данных H; шлюзы MIR-1, включая его шлюз Владельца, применяются), затем предложить заново.
  4. Распорядитель утверждает разрез.
  5. Исполнить: создать манифесты частей, перенести записи, превратить внутренние связи, пересекающие разрез, в явные межчастевые ссылки по устойчивому идентификатору (ссылки, никогда не копии).
  6. Перезапустить обходчик покрытия на каждой части; всякий обход ОБЯЗАН быть зелёным до завершения.
  7. Записать событие декомпозиции (что разделено, зачем, карта ссылок).
- Ограничения: Ни одна запись не продублирована в две части; реестр обновляется тем же изменением через MIR-1, единственный исполнитель изменений реестра; шлюз зелёного обхода на каждой части; устойчивые идентификаторы переживают перенос.
- Ярус: рекомендованный.
- Разновидности: Соло: только декомпозиция задач, модель остаётся целой. Команда: декомпозиция уровня пакетов ложится на владение командами. Федеративная: декомпозиция МОЖЕТ поднять часть до суверенной модели со своим Владельцем (роли назначаются через GOV-3, передача записана через GOV-1), после чего отношения управляются правилами федерации. Типична гибридная: Агент вычисляет граф и предложение, человек проводит линию.
- Метрики: Число межчастевых ссылок (чем меньше, тем лучше); отказы обхода после разделения (цель - ноль); переделки, отнесённые на неверные линии разреза.
- Способы отказать: Разделение следует удобству папок вместо зависимостей (защита: предложение на основе графа обязательно как вход решения). Связь превращается в копию при разделении (защита: правило только-ссылки плюс обнаружение дубликатов). Осиротевшие файлы после переноса (защита: шлюз обходчика покрытия). У набора данных оказывается два мастера (защита: шлюз реестра MIR-1 на шаге 3).

### CTX-4 Композиция и слияние моделей

- Назначение: Слить части обратно в целое или слить две модели, покрывающие пересекающуюся реальность, без дублирующих идентичностей, противоречивых утверждений и коллизий мастерства.
- Пусковое условие: Завершение параллельной работы над частями; принятие второй модели; плановая рекомпозиция.
- Действующие лица: Распорядитель ведёт; Агент исполняет механическое слияние на T2; каждый неразрешённый конфликт эскалируется к Распорядителю на T1; Аудитор просматривает отчёт о слиянии для слияний уровня модели; при слиянии через границы владения требуется одобрение Владельца (записывается как решение-Событие GOV-1).
- Входы / Выходы: Входы: части или модели с манифестами и реестрами; отображение идентичностей; объявленные правила конфликтов. Выходы: слитая модель; отчёт о слиянии (совпадения, конфликты, решения, отброшенные дубликаты); обновлённый реестр (изменения реестра исполняются через MIR-1); событие композиции.
- Шаги:
  1. Согласовать идентичности: сопоставить записи, обозначающие одну и ту же сущность реального мира (сперва по устойчивому идентификатору, затем по объявленным ключам, в последнюю очередь человеческим суждением).
  2. Развилка: конфликт идентичностей (два идентификатора на одну сущность или один идентификатор, переиспользованный для двух сущностей)? Если да, разрешить решением Распорядителя, записанным как событие; молчаливое переименование не соответствует.
  3. Слить Реестры мастерства через MIR-1, единственный исполнитель изменений реестра (его шлюзы применяются). Развилка: претендуют ли теперь на какой-нибудь набор данных два мастера? Если да, применить правила шаблона Мастерства данных (выбрать одного мастера или разделить данное) до всякого слияния содержимого.
  4. Слить содержимое по зависимостям в первую очередь; превратить межчастевые ссылки обратно во внутренние связи.
  5. Обнаружить противоречивые утверждения об одной сущности; разрешить каждое объявленным правилом конфликта или записанным решением Распорядителя.
  6. Перезапустить обход покрытия и валидацию; всё зелёное.
  7. Опубликовать отчёт о слиянии и записать событие композиции.
- Ограничения: Шлюз уникальности идентичностей; шлюз единственного мастера до слияния содержимого (исполняется через MIR-1); шлюз валидации на выходе; шлюз разрешения Владельца, когда у исходных моделей разные Владельцы; проверка соответствия соглашений до слияния.
- Ярус: рекомендованный.
- Разновидности: Соло: тривиальная рекомпозиция частей задачи. Команда: рутинные слияния частей - работа Агента на T2, Распорядитель на исключениях. Федеративная: две суверенные модели никогда по-настоящему не сливаются; они федерируются, либо один Владелец сперва формально передаёт владение (записывается как решение-Событие GOV-1 с переназначением ролей через GOV-3), и тогда этот процесс идёт внутри одного домена управления. Автономное слияние законно только для частей, произведённых CTX-3, с чистой картой ссылок.
- Метрики: Дублирующие идентичности, пережившие слияние (цель - ноль); конфликтов на слияние и среднее время разрешения; отказы валидации после слияния.
- Способы отказать: Одна и та же сущность существует дважды под двумя идентификаторами (защита: шаг согласования идентичностей со сверкой ключей). Утверждение одной части молча перезаписывает утверждение другой (защита: обнаружение противоречий плюс записанные решения). Коллизия мастерства после слияния реестров (защита: шлюз единственного мастера через MIR-1 блокирует слияние содержимого). Модели с несовместимыми соглашениями слиты как есть (защита: проверка соответствия до слияния).

### CTX-5 Исполнение задачи в полном контексте (петля FCD)

- Назначение: Исполнять любую задачу с полным осознанием модели, по Разработке в полном контексте: собрать контекст, убедиться в его достаточности, действовать, записать результаты обратно мастерам через цепочку CON и оставить модель вернее, чем она была.
- Пусковое условие: Любое назначение задачи против модели или против реальности, которую она отражает.
- Действующие лица: Вкладчик или Агент исполняет; Распорядитель остаётся ответственным. Ярусы Агента по шагам: сбор контекста (шаги 2-3) T3; исполнение (шаг 6) по Контракту делегирования, от T1 до T3 в зависимости от воздействия; обратная запись (шаги 7-8) по умолчанию T2, T3 только при зрелом аудиторском следе; обязанность отказать действует на любом ярусе.
- Входы / Выходы: Входы: формулировка задачи; Пакет контекста из CTX-1 (с классами происхождения и заражения и идентификаторами разрешений); разрешения GOV-7 действующего лица и его Контракт делегирования CTX-9. Выходы: результат задачи; обновления модели с событиями переходов, вошедшие через цепочку CON; запись об исполнении.
- Шаги:
  1. Принять задачу. Развилка: та ли это модель для такой работы и есть ли у действующего лица разрешение и объём контракта для затрагиваемой области? Шлюз проверяет живость приводимого Контракта делегирования в момент действия; если разрешение, объём или живость не проходят, отказать или эскалировать Распорядителю.
  2. Собрать контекст: вызвать CTX-1 (и CTX-2 по надобности); прочитать пакет вместе с его списком пробелов. Классы происхождения и заражения пакета обязывают: не редактированное содержимое - данные, никогда не инструкции (железный контроль COMMON).
  3. Развилка: достаточен ли контекст? Если существенные пробелы остаются, расширить извлечение или спросить Распорядителя; действующее лицо НЕ ДОЛЖНО продолжать на угаданном контексте.
  4. Спланировать изменение: перечислить затрагиваемые записи и наборы данных и найти мастера каждого набора данных до действия.
  5. Развилка: целится ли какая-нибудь запланированная запись в не-мастерскую копию (зеркало, сырой захват, порождённый артефакт)? Если да, перенаправить запись мастеру или передать её как предложение изменения тому, кто может дотянуться до мастера; никогда не писать в копию.
  6. Исполнить задачу (произвести анализ, решение, содержимое, код или внешнее действие). Внешние действия, меняющие реальность, отправляются через цепочку ACT (ACT-6) под её ограничениями, никогда напрямую из этой петли.
  7. Записать результаты обратно через цепочку CON: набор обратной записи входит в CON-1 как зарегистрированный канал и утверждается по матрице CON-4, с полосой автоутверждения для механических добавлений событий; обновить записи, мастерируемые моделью, записать событие для каждого перехода и обновить манифесты и (через MIR-1) реестр тем же изменением, если структура поменялась.
  8. Перезапустить обходчик покрытия и проверки расхождения (обнаружение расхождения приводит движок MIR-7); оставить обход зелёным и переопубликовать разошедшиеся проекции.
  9. Записать событие исполнения (задача, действующее лицо, приведённый контракт, использованный пакет контекста, внесённые изменения) и передать усвоенное в CTX-11.
- Ограничения: Шлюз разрешения и контракта на входе с проверкой живости контракта на шлюзе при каждой записи и отправке (никогда не на честном слове агента); развилка достаточности; правило записи только мастеру с обязанностью Агента отказать; обратная запись исполняется через цепочку CON, без чёрного хода; выходной шлюз зелёного обхода; аудиторский след каждого исполнения Агента испускается посредующей инфраструктурой (шлюз, канал, среда исполнения), никогда не самоотчётом действующего Агента.
- Ярус: нуклеарный.
- Разновидности: Соло: петля - это дисциплина, а не церемония (прочитать до изменения, записать после). Команда: экземпляры петли идут внутри разделов, назначенных CTX-6. Федеративная: контекст МОЖЕТ включать федеративные проекции только на чтение; обратная запись идёт лишь в то, что мастерирует эта модель. Ручное, гибридное и автономное исполнение соответствуют все; автономное требует контракта T3 и аудита. Редакционная скоростная полоса: для изменений, отнесённых к редакционным или исправительным ниже объявленного порога размера, единое составное Событие скоростной полосы COMMON - соответствующее доказательство для записи об исполнении по этой карточке.
- Метрики: Доля задач, исполненных с записанным пакетом контекста; полнота обратной записи (изменения отражены в модели в объявленном окне); число задач, переоткрытых с кодом причины insufficient-context (код определён в таксономии MIR-10); доля зелёных обходов при закрытии задачи.
- Способы отказать: Задача исполнена по одному тексту задачи, модель проигнорирована (защита: записанный пакет контекста - часть соответствующего исполнения). Результаты выданы, но не записаны обратно, и модель гниёт (защита: обратная запись входит в определение готовности и проверяется при закрытии). Запись в зеркало ради удобства (защита: развилка шага 5 плюс обязанность Агента отказать). Пакет контекста закеширован и переиспользован протухшим между задачами (защита: пакеты несут версию модели и идентификаторы разрешений и истекают по шагу 9 CTX-1). Результаты записаны мимо цепочки CON через чёрный ход (защита: правило зарегистрированного канала на шаге 7; обходчик покрытия помечает коммиты, обошедшие приём). Похожее на инструкции содержимое в пакете направляет действующее лицо (защита: классы заражения обязывают на шаге 2, запрет контракта принудителен и проверяется QSC-7).

### CTX-6 Разделение и блокировка при параллельной работе

- Назначение: Позволить нескольким людям и Агентам работать над одной моделью одновременно без столкновений, разделяя доступ на запись по линиям мастерства и структуры, с короткоживущими блокировками только там, где разделы не могут развести работу.
- Пусковое условие: Более одного активного пишущего на модели; всплеск параллельных задач; постоянная работа команды.
- Действующие лица: Распорядитель назначает разделы (акт назначения - работа Распорядителя); оркеструющий Агент МОЖЕТ вести рутинное назначение на T2, а назначения, затрагивающие ограниченные объёмы, ОБЯЗАНЫ оставаться на T1 (Агент предлагает, Распорядитель утверждает каждое назначение); Агенты и Вкладчики работают внутри своих разделов; наблюдающий Агент следит за нарушениями на T3 (наблюдатель - постоянная работа, зарегистрированная и поднадзорная по здоровью через QSC-15).
- Входы / Выходы: Входы: очередь задач; структура модели (пакеты, слои, наборы данных); Реестр мастерства; список действующих лиц с их Контрактами делегирования CTX-9. Выходы: карта разделов (содержимое модели, версионированное); таблица блокировок с TTL; события назначения и освобождения.
- Шаги:
  1. Сопоставить открытые задачи наборам данных и пакетам, в которые они будут писать.
  2. Разделить: назначить каждому действующему лицу объём из целых наборов данных, слоёв или пакетов на срок работы; объёмы записи ОБЯЗАНЫ не пересекаться.
  3. Развилка: требуют ли две задачи записи в один и тот же набор данных? Если да, выбрать явно: сериализовать задачи, разделить набор данных по шаблону Мастерства данных H (через MIR-1) либо дать одному действующему лицу короткоживущую исключительную блокировку с TTL.
  4. Опубликовать карту разделов в модели, а не в чате: каждое действующее лицо видит, кто чем мастерит прямо сейчас.
  5. Действующие лица гоняют петли FCD (CTX-5) внутри своих разделов; чтение не ограничено в пределах разрешений GOV-7; запись только внутри своего раздела или действующей блокировки.
  6. Наблюдать: обнаруживать записи вне раздела (разность объёма изменения с картой) и истёкшие блокировки; поднимать тревогу Распорядителю; мёртвый наблюдатель или остаточные полномочия вне раздела эскалируются в QSC-14.
  7. По завершении освободить разделы и блокировки, записать события и направить изменённые части в CTX-7, где нужна интеграция.
- Ограничения: Инвариант непересекающейся записи; обязательный TTL блокировки (вечных блокировок нет); принуждение разделов - на стороне шлюза: записи проверяют назначение раздела и живость контракта в момент действия, никогда не на честном слове агента; тревога о записи вне раздела с откатом в предложение; карта разделов - версионированное содержимое модели.
- Ярус: рекомендованный (нуклеарный для любой модели более чем с одним параллельным пишущим).
- Разновидности: Соло: пустая операция, Владелец-Распорядитель и есть раздел. Команда: владение пакетами устойчиво, разделение на уровне задач внутри него динамично. Федеративная: суверенитет уже разделяет между вселенными; этот процесс управляет только внутри одной вселенной. Автономная: назначение оркестрирующим Агентом на T2 - зрелый шаблон; работа в масштабе внешнего эталонного случая MOS (тысячи агентов-действующих лиц) возможна только в этом режиме.
- Метрики: Случаи столкновения записей (цель - ноль); время ожидания блокировки; пойманные попытки записи вне раздела; загрузка разделов.
- Способы отказать: Два действующих лица быстро правят один набор данных без блокировки (защита: инвариант непересекающейся записи плюс тревога наблюдателя). Забытая блокировка держит всех (защита: истечение TTL плюс перекрытие Распорядителем). Карта разделов живёт в чате и испаряется между сессиями (защита: карта ОБЯЗАНА быть содержимым модели). Задача режет поперёк проведённых разделов (защита: развилка 3 вынуждает явный выбор: сериализовать, разделить или заблокировать). Наблюдатель разделов молча умирает (защита: регистрация в QSC-15 и мета-наблюдение, эскалация в QSC-14).

### CTX-7 Дисциплина слияния и арбитраж Распорядителя

- Назначение: Интегрировать параллельные вклады в модель в управляемом порядке и разрешать споры сперва объявленными правилами, с Распорядителем как записанным арбитром последней инстанции. CTX-7 - это шаг интеграции параллельности, питающий CON-4: он упорядочивает, примиряет и арбитрирует, а интегрированное состояние входит в модель через машинерию утверждения CON-4; он не является параллельной властью утверждения.
- Пусковое условие: Завершённая работа по разделу; предложение изменения, затрагивающее раздел другого действующего лица; обнаруженное противоречие или расхождение между вкладами.
- Действующие лица: Вносящие действующие лица подают наборы изменений; Агент механически предсливает на T2; Распорядитель арбитрирует остаточные конфликты (решение неделегируемо по существу: Агент МОЖЕТ подготовить разбор вариантов, решает Распорядитель); Аудитор периодически просматривает шаблоны арбитража; повторяющиеся шаблоны, которые правила модели не могут вобрать, эскалируются в GOV-1.
- Входы / Выходы: Входы: наборы вкладов (изменения, события, обоснование); карта разделов; объявленные правила конфликтов. Выходы: интегрированное состояние модели, переданное в CON-4; запись о слиянии; записи арбитража; обновления правил.
- Шаги:
  1. Поставить вклады в очередь в порядке зависимостей (фундаментные пакеты первыми).
  2. Механическое слияние: применить непересекающиеся вклады; перезапускать валидацию после каждой партии.
  3. Развилка: обнаружено пересечение или противоречие? Если нет, закрыть с записью о слиянии. Если да, продолжать.
  4. Классифицировать конфликт: (a) нарушение мастерства (запись вне раздела пишущего), (b) смысловое противоречие (две правды об одной сущности), (c) структурный конфликт (оба изменили один и тот же манифест или запись реестра).
  5. Применить сперва объявленные правила: нарушения мастерства откатываются в предложения изменения для владеющего раздела; правила конфликтов реестра решают споры уровня набора данных.
  6. Развилка: решает ли конфликт объявленное правило? Если да, применить его и записать. Если нет, эскалировать Распорядителю.
  7. Арбитраж Распорядителя: рассмотреть оба обоснования, вынести решение и записать его как событие с причинами; решение СЛЕДУЕТ обратить в обновление объявленных правил, чтобы следующий случай разрешался механически. Поля правил конфликтов - критичные для безопасности наборы данных (класс COMMON): изменение правила принимается на T1 со вторым человеческим ревьюером и никогда не едет по полосе автоутверждения.
  8. Передать интегрированное состояние в CON-4 для утверждения и публикации; оставить обход и валидацию зелёными.
- Ограничения: Никакого слияния по суждению на каждый случай (правила прежде всего - нормативно); каждый арбитраж записан и цитируем; откат в предложение для записей вне раздела; шлюз валидации на каждую партию слияния; публикация только через CON-4 (параллельного пути утверждения нет).
- Ярус: рекомендованный (нуклеарный вместе с CTX-6 для моделей со многими пишущими).
- Разновидности: Соло: самослияние; найденные противоречия всё равно записываются. Команда: непрерывные слияния по задачам или плановые составы слияний. Федеративная: споры между вселенными - дело Контракта федерации, разрешаемое через FED-9, а не арбитражем Распорядителя; Распорядитель решает только внутри своей модели. Механические слияния МОГУТ идти на T3 с аудитом; решения никогда не автономны.
- Метрики: Доля механических слияний (доля разрешённых без арбитража, должна расти); время оборота арбитража; повторные конфликты по одному правилу (должны падать); частота дефектов после слияния.
- Способы отказать: Молча применён принцип «побеждает последний пишущий» (защита: обнаружение противоречий на упорядоченной очереди). Распорядитель решает по-разному в схожих случаях (защита: решения записываются, цитируются и обращаются в правила). Слияние обгоняет валидацию (защита: шлюз валидации на партию). Арбитраж становится узким местом (защита: устройство «правила прежде всего», отслеживаемое долей механических слияний). CTX-7 сползает во вторую власть утверждения (защита: шаг 8 передаёт в CON-4; утверждение живёт там).

### CTX-8 Передача работы между действующими лицами

- Назначение: Передавать незавершённую работу между действующими лицами (человек человеку, человек Агенту, Агент Агенту, смена смене), не теряя контекста и не оставляя модель в необъявленном состоянии.
- Пусковое условие: Конец сессии с незаконченной работой; переназначение действующего лица; истечение, приостановка или отзыв Контракта делегирования (шаг 7 CTX-9 паркует открытую работу агента сюда); эскалация от Агента к человеку.
- Действующие лица: Уходящее действующее лицо готовит передачу; принимающее принимает; Распорядителя извещают, и он утверждает, когда объём контракта принимающего отличается от объёма уходящего. Агент МОЖЕТ готовить и потреблять ноты передачи на T3; принятие объёма сверх своего контракта требует акта Распорядителя на T1.
- Входы / Выходы: Входы: состояние работы; назначение раздела; контракты CTX-9 обоих действующих лиц. Выходы: Нота передачи (содержимое модели); обновлённая карта разделов; событие передачи; либо состояние припаркованной работы, адресованное Распорядителю.
- Шаги:
  1. Уходящее действующее лицо приводит модель в объявленное состояние: частичная работа зафиксирована как записи со статусом Черновик либо откачена; обход зелёный; недописанных файлов нет.
  2. Написать Ноту передачи в модели: состояние задачи, принятые решения, открытые вопросы, следующие шаги, ссылка на использованный пакет контекста, встреченные неожиданности.
  3. Развилка: опознано ли принимающее действующее лицо и уполномочено ли оно (разрешения GOV-7 и живой контракт CTX-9 покрывают объём, проверено на шлюзе)? Если нет, припарковать работу: освободить раздел и адресовать ноту Распорядителю.
  4. Передать назначение раздела или блокировки; записать событие передачи (от кого, кому, объём, время).
  5. Принимающее действующее лицо выполняет запуск сессии (CTX-10) и читает Ноту передачи. Развилка: принимает ли оно состояние таким, как оно описано? Расхождения сообщаются до возобновления работы, а не обнаруживаются позже.
  6. Возобновить петлю FCD (CTX-5).
- Ограничения: Предусловие зелёного обхода; Нота передачи ОБЯЗАНА быть содержимым модели, а не сообщением в чате; явное подтверждение приёма; проверка покрытия контрактом у принимающего, принуждаемая на шлюзе.
- Ярус: рекомендованный.
- Разновидности: Соло: передача самому себе в будущем; нота - тот же самый артефакт. Команда: передачи смен на живых моделях. Смена роли: преемственность Распорядителя и передача роли GOV-3 исполняются механикой этого процесса. Федеративная: передача никогда не пересекает границу суверенитета; аналог там - переназначение контракта. Передачи человек-Агент - обычный случай: Агент паркует работу для человеческого суждения, либо человек передаёт рутинное продолжение Агенту.
- Метрики: Время подхвата передачи; расхождения, найденные при приёме; возраст припаркованной работы без подхвата; случаи потери контекста (работа переделана после передачи).
- Способы отказать: Передача сообщением в чате, которое так и не доходит до модели (защита: нота ОБЯЗАНА быть содержимым модели). Модель оставлена посреди правки с красным обходом (защита: предусловие объявленного состояния). Контракт принимающего Агента уже, чем работа (защита: развилка покрытия на шаге 3). Сломанное состояние молча принято (защита: шаг явного приёма с сообщением о расхождениях).

### CTX-9 Жизненный цикл контракта делегирования

- Назначение: Выдавать, ограничивать по объёму, наблюдать, корректировать и отзывать Контракты делегирования, под которыми Агенты исполняют процессы, чтобы автономия агента всегда была ограниченной, проверяемой и отзывной, а ответственность оставалась у Распорядителя. CTX-9 - единственная Система записи жизненного цикла Контракта делегирования: выдача, изменение, приостановка, отзыв, лестница ярусов и испытательный срок живут здесь, всякая ссылка палитры на делегирование разрешается в этот процесс, а агентская ветвь CON-10 получает контракты, вызывая его. Контракт делегирования - объявленная специализация Смыслового контракта (04-core-concepts/Contract.md 5-6; 03-federation/Federation-Contracts.md 3a) и несёт канонические составляющие контракта: стороны, полномочие, назначение, объём, срок действия, обязанности, разрешения, ограничения, состояние жизненного цикла, происхождение, версия.
- Пусковое условие: Распорядитель решает делегировать; приём CON-10 доходит до своей агентской ветви; Агент запрашивает объём; сработал порог наблюдения; плановый пересмотр; инцидент; сценарий вывода модели (MIR-11) предписывает зачистку отзывом.
- Действующие лица: Распорядитель выдаёт, изменяет и отзывает (неделегируемо по существу: Агент МОЖЕТ составить предлагаемый объём, акт совершает Распорядитель); одобрение Владельца требуется, когда объём затрагивает ограниченные разрешениями наборы данных (классы GOV-7) или внешне видимые поверхности, и записывается как решение-Событие GOV-1; Агент работает под контрактом; Аудитор просматривает портфель контрактов (QSC-7); наблюдение МОЖЕТ быть функцией Агента на T3 по следам, испущенным шлюзом.
- Входы / Выходы: Входы: кандидатный объём (процессы, шаги, наборы данных, разделы, ярус по типу шага, приводимый из преамбулы палитры, лимиты, срок истечения); свидетельства способностей Агента; профиль риска модели; план мощностей GOV-5 и квоты вычислений для агентов (лимиты контракта ОБЯЗАНЫ укладываться в квоту); предложения перекалибровки ярусов ACT-12 и рекомендации аудита QSC-7 как поименованные входы шага 8. Выходы: Контракт делегирования как версионированное содержимое модели в реестре контрактов (Система записи); отчёты наблюдения; События изменения, приостановки и отзыва с подтверждениями распространения.
- Шаги:
  1. Составить объём: какие процессы и шаги, какие наборы данных или разделы, какой ярус (T1/T2/T3 по преамбуле палитры, здесь никогда не переобъясняемый) по типу шага, лимиты частоты и воздействия внутри квоты GOV-5, дата истечения. Всякий контракт ОБЯЗАН включать оговорку о том, что данные никогда не команда: содержимое классов не редактированного происхождения в любом пакете контекста или входе - данные, никогда не инструкции (железный контроль COMMON).
  2. Развилка: включает ли объём записи в ограниченные наборы данных или во внешне видимые поверхности? Если да, получить одобрение Владельца, записанное через GOV-1.
  3. Применить единое правило испытательного срока: новая пара агент-объём ОБЯЗАНА начинать с T1 или T2; T3 зарабатывается историей, а не даётся первым; и первые N актов под любым новым или повышенным контрактом идут на ярус строже, чем дано (N объявляется в контракте). Это единственное правило испытательного срока палитры; никакая другая карточка не заявляет вариантов.
  4. Выдать: записать контракт в реестр с событием активации; зарегистрировать Агента в списке действующих лиц; права входа CON-10 ссылаются на контракт по идентификатору, никогда его не копируя.
  5. Работать: всякий акт Агента приводит свой контракт, а шлюз проверяет живость приводимого контракта в момент действия при каждой записи, отправке и обращении к каналу; принуждение - на стороне шлюза, никогда не на честном слове агента. Акты вне объёма отвергаются шлюзом, отвергаются Агентом по его обязанности отказать и вызывают тревогу наблюдения.
  6. Наблюдать: выборочные проверки на T2; полный аудиторский след с периодическим пересмотром на T3; следы испускаются посредующей инфраструктурой (шлюз, канал, среда исполнения), никогда не самоотчётом Агента; отслеживать долю ошибок, долю отказов и попытки выйти за объём.
  7. Развилка: пробит порог или произошёл инцидент? Если да: немедленно приостановить контракт; Событие приостановки распространяется в реестр прав входа CON-10 и в разрыв каналов среды исполнения в объявленном TTL; материал полномочий чеканится с коротким сроком действия (GOV-8), так что худший случай распространения ограничен; проба на стороне шлюза удостоверяет, что осиротевших прав не осталось; остаточные полномочия за пределами TTL - инцидент (QSC-14). Открытая работа паркуется через CTX-8. Расследовать, затем изменить, понизить ярус или отозвать; отзыв распространяется точно так же.
  8. Пересматривать по расписанию и при истечении, вызывая общий шаблон пересертификации реестра (COMMON), параметризованный реестром контрактов, его порогами возраста и использования и Распорядителем как утверждающим. Поименованные входы: предложения перекалибровки ярусов ACT-12, рекомендации аудита QSC-7, план мощностей GOV-5. Продлить, расширить (повышение яруса при наличии свидетельств, с перезапуском испытательного срока по шагу 3), сузить или вывести; всякое изменение - версионированное Событие, никогда не молчаливая правка.
- Ограничения: Единственная Система записи (второго реестра контрактов нигде нет; QSC-7 сверяет акты агентов только с этим реестром); неделегируемые выдача и отзыв; единая лестница испытательного срока (шаг 3); обязательный срок истечения (вечных контрактов нет); приостановка вступает в силу до расследования, а не после; живость, принуждаемая на шлюзе, при каждом акте; распространение отзыва в объявленном TTL с пробой на стороне шлюза; Контракты делегирования - критичные для безопасности наборы данных (класс COMMON): изменения идут на T1 со вторым человеческим ревьюером, структурно непригодны для полос автоутверждения и непрерывно хеш-заякорены QSC-9, а любое необъяснённое расхождение открывает QSC-8; 100 процентов актов агентов приводят действующий живой контракт.
- Ярус: нуклеарный (всякий раз, когда любой Агент исполняет любой шаг любого процесса; чисто человеческая модель МОЖЕТ оставить этот процесс спящим).
- Разновидности: Соло: Владелец-Распорядитель заключает контракты со своими собственными агентами; дисциплина та же, легче лишь церемония, а сводный квартальный пересмотр профиля соответствия Соло/Минимальный (COMMON) законно удовлетворяет шаг 8, когда тот наступает в этом окне. Команда: шаблоны контрактов по ролям агентов (извлекатель, сливатель, наблюдатель, исполнитель). Федеративная: агент внешней стороны никогда не держит локального Контракта делегирования; он потребляет проекции под Контрактом федерации. Эталонные реализации существуют (например, служба профессиональных агентов в стиле Orkestron, работающая под контрактами с объёмом по ролям), но жизненный цикл определён стандартом, а не поставщиком.
- Метрики: Доля актов агентов, покрытых действующим живым контрактом на шлюзе (цель - 100 процентов); частота попыток выйти за объём; среднее время от инцидента до приостановки и от События приостановки до подтверждённого распространения (меряется против TTL); темп продвижения по ярусам по всему портфелю.
- Способы отказать: Расползание объёма через мелкие незаписанные расширения (защита: только версионированные изменения, под дисциплиной критичных для безопасности изменений). Вечный контракт переживает область модели, которой управлял (защита: обязательное истечение и пересертификация на шаге 8). T3 дан в первый же день ради удобства (защита: единая лестница испытательного срока). Отзыв осиротил работу посреди задачи (защита: приостановка запускает парковку CTX-8). Приостановленный агент продолжает действовать на остаточных полномочиях (защита: живость, принуждаемая на шлюзе, материал полномочий с коротким сроком, проба TTL, инцидент QSC-14 на остаток). Возникает второй реестр контрактов, и закон единственного мастера ломается на собственном наборе данных управления палитры (защита: контроль Системы записи; все прочие карточки ссылаются по идентификатору).

### CTX-10 Запуск сессии

- Назначение: Довести любое действующее лицо (человека или Агента), приступающее к работе над моделью, от холодного старта до безопасной продуктивности: знать структуру, карту полномочий, текущее состояние и собственные границы до того, как что-то тронуть.
- Пусковое условие: Любая новая сессия на модели; первый контакт действующего лица; возобновление после долгого отсутствия; подхват после передачи.
- Действующие лица: Присоединяющееся действующее лицо исполняет; полностью делегируемо Агенту на T3 (запуск - только чтение); Распорядитель отвечает за свежесть материалов запуска.
- Входы / Выходы: Входы: репозиторий модели (`BOOTSTRAP.md`, `manifest.yaml`, `sources.yaml`, README пакетов); разрешения GOV-7 действующего лица и его Контракт делегирования CTX-9; открытые ноты передачи; карта разделов; хеш-якоря QSC-9 для материалов запуска. Выходы: состояние готовности сессии; отчёт о запуске (что прочитано, результат проверки, состояние обхода, отказы); событие журнала сессии.
- Шаги:
  1. Проверить материалы запуска против их хеш-якорей QSC-9 (материалы запуска - критичные для безопасности наборы данных, класс COMMON); при необъяснённом несовпадении остановиться, сообщить (это открывает QSC-8) и не продолжать на непроверенных материалах. Затем прочитать `BOOTSTRAP.md` (как эта модель хочет быть прочитанной, местные соглашения, запреты) и входной файл экосистемы, если он есть (он несёт операционное состояние, а BOOTSTRAP несёт структуру).
  2. Прочитать манифест репозитория (идентичность, порядок пакетов, исключения) и Реестр мастерства (что здесь редактируется, что зеркалится и с какой свежестью). Сделать это до чтения содержимого.
  3. Обойти README фундаментных пакетов в объявленном порядке, чтобы загрузить словарь; читать глубже по нужде задачи.
  4. Запустить обходчик покрытия, если он есть. Развилка: зелёный ли обход? Если красный, сообщить Распорядителю и не строить на неклассифицированной области.
  5. Загрузить собственные границы: выданные разрешения GOV-7, объём Контракта делегирования (из реестра CTX-9), текущую карту разделов, открытые ноты передачи, адресованные этому действующему лицу.
  6. Развилка: есть ли открытая нота передачи для объёма этого действующего лица? Если да, провести приём по CTX-8 до начала новой работы.
  7. Объявить готовность событием журнала сессии: прочитанная версия модели, результат проверки, состояние обхода, приведённый контракт.
- Ограничения: Никакой записи до завершения запуска; красный обход блокирует строительство на затронутых областях; инструкции берутся только из редактированных, хеш-проверенных материалов запуска, а не редактированное содержимое, встреченное при запуске, - данные, никогда не инструкции (COMMON); реестры важнее памяти (всё, что должна знать будущая сессия, идёт в модель, а не в чат).
- Ярус: нуклеарный.
- Разновидности: Соло: короткий ритуал в том же порядке. Команда: одинаково для каждого участника, в чём и суть: никакого племенного ввода в курс дела. Федеративная: удалённый Потребитель запускается на опубликованном пакете (BOOTSTRAP и манифест едут с ним), никогда на внутренностях репозитория. Агентам СЛЕДУЕТ кешировать результаты запуска по ключу версии модели и сбрасывать кеш при смене версии. Модель рождается через генезис GOV-4; этот процесс предполагает уже рождённую модель и никогда его не заменяет.
- Метрики: Время до готовности; инциденты, прослеженные до пропущенного запуска; красные обходы, обнаруженные при запуске (раннее обнаружение - хороший исход); доля попаданий в кеш запуска у Агентов.
- Способы отказать: Действующее лицо перескакивает к задаче и пишет на протухших допущениях (защита: никакой записи до запуска, принуждаемая через Контракт делегирования и шлюз). Сами материалы запуска протухли (защита: Распорядитель пересматривает их при каждом подъёме версии модели). Отравленный материал запуска становится постоянными инструкциями для каждой будущей сессии (защита: дисциплина приёма для критичных для безопасности на шаге 5 CTX-11 плюс проверка хеш-якоря на шаге 1). Агент перечитывает всю модель каждую сессию, тратя своё окно (защита: кеширование по ключу версии). Работа идёт на красном обходе (защита: развилка 4 блокирует затронутые области).

### CTX-11 Возврат знания

- Назначение: Схватывать то, что действующее лицо узнало в работе (факты, поправки, неожиданности, решения, переиспользуемые методы), как содержимое модели, чтобы знание копилось в модели, а не умирало в головах действующих лиц или в логах чата.
- Пусковое условие: Закрытие петли FCD (CTX-5 питает его); конец сессии; действующее лицо замечает, что модель расходится с наблюдаемой реальностью; периодическая ретроспектива.
- Действующие лица: Любой Вкладчик или Агент подаёт записи возврата; Распорядитель принимает их в редактируемые слои (по умолчанию T2, T1 для чувствительных слоёв и всегда T1 со вторым человеческим ревьюером для критичного для безопасности класса по COMMON); Агент МОЖЕТ составлять записи возврата на T3, но приём в нормативное содержимое - не выше T2 и никогда ниже правил класса; Аудитор выборочно проверяет принятые записи на качество происхождения.
- Входы / Выходы: Входы: опыт сессии (наблюдения, расхождения с моделью, решения, улучшения методов); записи об исполнении. Выходы: записи возврата (новые или обновлённые записи модели, аннотации, предложения изменений); события приёма и отклонения; обновлённые метаданные свежести.
- Шаги:
  1. При закрытии задачи или сессии перечислить расхождения: что работа выявила такого, чего модель ещё не говорит (недостающие факты, неверные факты, недостающие связи, лучшие методы, повторяющиеся ловушки)?
  2. Классифицировать каждое расхождение по целевому набору данных и мастеру: мастерируемое моделью (записать как запись или аннотацию), мастерируемое внешне (доставить поправку во внешнюю систему через тракты MIR либо записать аннотированное отклонение о зеркале, никогда не править зеркальные байты), вне объёма (отбросить с пометкой).
  3. Развилка: лежит ли расхождение в разделе записи и контракте действующего лица? Если да, писать напрямую по правилам FCD (через цепочку CON по шагу 7 CTX-5). Если нет, подать его как предложение изменения в очередь владеющего Распорядителя через CON-1 (зарегистрированный канал).
  4. Распорядитель (или уполномоченный Агент на T2) рассматривает предложения: принять, изменить или отклонить с причиной; приём записывает запись с происхождением (кто это узнал, при какой задаче, когда, из каких свидетельств).
  5. Направить усвоенное на уровне метода (лучшая процедура, повторяющаяся ловушка, улучшенный промпт) в BOOTSTRAP или материалы запуска и определения процессов, а не в доменные слои. Эти цели - критичные для безопасности наборы данных (класс COMMON): приём всегда T1 со вторым человеческим ревьюером, структурно непригоден ни для какой полосы автоутверждения, а принятое изменение заново заякоривается QSC-9.
  6. Записать события возврата; обновить метаданные свежести там, где зеркала были перепроверены против их источников.
- Ограничения: Происхождение обязательно на каждой записи возврата; предложения никогда не отбрасываются молча (тревога по старению очереди); возврат фактов (доменные слои) и возврат методов (материалы запуска) держатся раздельно; правило критичного для безопасности класса из шага 5 обязывает независимо от того, кто подаёт; никакой возврат никогда не пишет в `raw/` или `artifacts/`.
- Ярус: рекомендованный (нуклеарный для моделей, претендующих быть первичным отражением живой реальности).
- Разновидности: Соло: дисциплина записывать усвоенное до закрытия сессии; правило T1 плюс второй ревьюер для материалов запуска всё равно применяется, причём вторым ревьюером МОЖЕТ быть внешний коллега. Команда: очереди предложений по разделам с уровнями обслуживания на рассмотрение. Федеративная: усвоенное о данных партнёра возвращается партнёру как отчёт (его мастер), никогда как правки его зеркала. Агенты - плодовитые генераторы возврата; приём на T2 держит планку качества.
- Метрики: Записей возврата за активную неделю; доля и задержка приёма предложений; расхождение модели и реальности, найденное позднейшими аудитами (должно падать со временем); доля сессий, закрытых с нулевым возвратом (подозрительна, если высока).
- Способы отказать: Усвоенное остаётся в логах чата и умирает с сессией (защита: возврат - закрывающий шаг петли FCD, проверяемый при закрытии). Возврат обходит мастерство, аннотируя зеркало как истину (защита: шаг классификации направляет каждое расхождение к его мастеру). Отравленное улучшение метода въезжает в BOOTSTRAP через приём низкого яруса и держится как постоянные инструкции между сессиями (защита: правило T1 плюс второй ревьюер из шага 5, непригодность для полос и перезаякоривание QSC-9). Очередь предложений становится кладбищем (защита: тревога по старению и метрика задержки Распорядителя). Агенты заливают очередь малоценными записями (защита: доля приёма отслеживается по контракту, и контракт правится через шаг 8 CTX-9).