Модуль XIV — внутренний каталог и маркетплейс

Модуль XIV — это внутренний каталог организации — курируемый, управляемый реестр агентов, MCP-серверов, навыков, шаблонов, моделей и сторонних коннекторов, которые были одобрены для повторного использования по всей компании. Он существует, чтобы estate стандартизировался на проверенных, версионированных возможностях вместо разовых копий, и чтобы «одобрено» означало нечто проверяемое, а не слово в вики. Он находится в слое Intelligence и не имеет поверхности воздействия: он курирует и записывает, тогда как снабжение происходит в другом месте.

Что это такое

Каталог — это реестр, а не хранилище документов. Запись — это одно курируемое, версионированное определение переиспользуемой возможности вида agent, mcp, skill, template, model или connector. Каждая (kind, slug, version) — это собственный неизменяемый артефакт: публикация новой версии создаёт новую запись, а одобрение и подписание происходят по версии. Запись проходит через фиксированный жизненный цикл:

draft → pending → approved → deprecated

Изменяем только draft; одобрение замораживает его. Спецификация записи — это авторское определение оператора — ссылки на транспорт, модель и промпт, область и ссылки на секреты — никогда значение учётных данных. Путь create/approve отклоняет спецификацию, несущую встроенные учётные данные, так что модуль хранит определения, ссылки и метаданные управления, но никогда секреты или полезные нагрузки.

Версионирование, заморозка и подписание

Одобрение — это место, где «одобрено» становится проверяемым:

Хеш содержимого. При одобрении запись привязывается хешем содержимого SHA-256 над её канонической, детерминированно сериализованной предобразной формой. Покрывается каждое авторское поле оператора, так что любая последующая мутация одобренной записи обнаружима — подделку можно выявить даже без подписи.
Аттестация в журнале. Одобрение записывается в только-добавляемый, хеш-сцепленный аудиторский журнал, атрибутированное реальному принципалу, который его одобрил.
Подпись Ed25519. Когда снабжён ключ подписи каталога, одобрение также производит отделённую подпись Ed25519 над хешем содержимого, несущую открытый ключ и короткий отпечаток — «одобрено = проверяемо». Ключ подписи загружается или чеканится при загрузке под швом ключей движка с отказом по умолчанию, независимо от ключа аудиторского журнала; модуль владеет своим ключом каталога и никогда не дотягивается до внутреннего подписанта аудита движка, сохраняя границу доверия чистой.

Проверка пересчитывает хеш и, когда ключ настроен на узле, рассматривает подпись как якорь доверия: снятая подпись (понижение) или сделанная любым другим ключом (подмена) сообщается как не проверена. GET …/pubkey сообщает, включено ли подписание; по-записи состояние verified / signed / signed_by возвращается маршрутами записи и проверки.

Проверенные сторонние коннекторы

Запись connector курирует выпущенный плагин стороннего коннектора — собранный бинарь или OCI-артефакт. Её спецификация записывает, что она курирует: sha256 артефакта (artifact_digest), ссылку на релиз/OCI, издателя и имя дескриптора коннектора. Запись — это обращённая к арендатору запись сертификации экосистемы внешних коннекторов: «одобрено» можно сделать означающим «его аттестация цепочки поставок была проверена», а не просто «кто-то нажал одобрить».

Поток зеркалит пару допуска MCP-записи, со своими собственными записями политики и вердикта (свидетельства считаются по виду, так что вердикты коннекторов никогда не делят таблицы с вердиктами MCP):

GET/PUT …/connector-admission/policy — корень доверия по арендатору: require_signed, опциональный require_subject_digest, пины идентичности/издателя Sigstore, голые открытые ключи, корни CA и in-toto список разрешённых предикатов (по умолчанию provenance SLSA v1/v0.2 и SBOM SPDX/CycloneDX — формы provenance и SBOM, потому что коннектор — это собранный артефакт, а не веса модели). Отсутствие политики означает режим наблюдения — ничего не гейтится, пока арендатор не подключится явно, и эндпоинт политики честно об этом говорит.
POST …/entries/{id}/admit — один общий маршрут, диспетчеризуемый по виду записи (mcp или connector): проверяет предоставленный оператором пакет аттестации Sigstore и записывает один вердикт заявлено-против-проверено по записи. Когда запрос не пинит expected_digest, привязка по умолчанию берётся из spec.artifact_digest записи — запись называет артефакт, который курирует, так что допуск привязывается к этому артефакту, если только явно не переопределён. Некорректный пакет — это 400; корректный пакет, не прошедший проверку, — это записанный отрицательный вердикт, а не ошибка.
GET …/connector-admissions — записанные вердикты, фильтруемые по записи (entry_ref) и ограничиваемые проверенными вердиктами (verified=true).
Гейт одобрения с отказом по умолчанию. При включённом require_signed запись коннектора может быть одобрена (и таким образом перечислена как проверенный коннектор) только с проверенным вердиктом допуска provenance/SBOM, привязанным к дайджесту, который запись курирует сейчас (spec.artifact_digest); при включённом require_subject_digest эта привязка к артефакту сама должна быть подтверждена. Редактирование курируемого дайджеста после допуска аннулирует гейт — требуется повторный допуск против нового артефакта.

Управляемое самообслуживаемое создание экземпляров

Экземпляр — это самообслуживаемый запрос на создание экземпляра одобренной записи — только одобренная запись может быть инстанцирована. Модуль записывает запрос, его происхождение (из какой версии записи он пришёл), его цель и его статус управления и обеспечивает разумную машину состояний (requested → approved/rejected → active). Он не решает, кто может одобрять, и не снабжает: решение об одобрении принадлежит управлению, а фактическое снабжение — развёртыванию. Одобрение, устаревание, подписание и создание экземпляров — это привилегированные, ограниченные RBAC и самоаудируемые действия к реальному принципалу.

Нет воздействия, нет снабжения. Модуль XIV записывает и управляет запросом; он никогда не поднимает возможность. Решение об одобрении принадлежит управлению, а связка — развёртыванию, и живой apply/retire там сам является швом с отказом по умолчанию (503, пока не снабжён исполнитель). См. Честность и ограничения.
Подписание реально, но зависит от ключа. Подписание Ed25519 реализовано, и ключ подписи снабжается при загрузке, включённый по умолчанию. На узле без настроенного ключа (или с недействительным ключом) одобренная запись привязана по хешу и аттестована в журнале, но не подписана — API честно об этом говорит через signing_enabled/signed, а не подразумевая существование подписи.
Курировано, не наблюдаемо. Каталог не подписывается на шину событий и не эмитирует в неё; он наполняется людьми через свой API, а не выводится из живых наблюдений. Он утверждает то, что организация одобрила для повторного использования, а не то, что сейчас работает.
Модуль не принуждает политику одобрения. Он принуждает машину состояний и уровни глаголов RBAC; кто может одобрять и при каких условиях — решает управление.

Связанное

Каталог модулей — где находится модуль XIV и разделение govern/observe против actuate.
Управление и одобрение — поток одобрения с human-in-the-loop.
Обзор архитектуры — движок, слои и общая модель данных, в которую записи объявляются.
Справочник шины событий — шина, которую этот модуль намеренно не потребляет.
Честность и ограничения — поза воздействия по всему продукту.