Малое ядро и расширения

Tyapkin можно использовать с одной Machine. Для базового исполнения не нужны Flow, imports, protobuf, CEL, ContractStore, Allium или Backstage:

строгий Machine Feature → Machine IR → decide → Commitment/Trace → verify_trace

Опциональный Feature module profile позволяет собрать несколько строгих Scenario из нескольких Feature в тот же Machine IR. Runtime CAP от этого не меняется.

CAP kernel проверяет Machine, права Principal/Capability, допустимость Transition и целостность Trace. Capkin даёт закрытую Gherkin-совместимую нотацию Machine и компилятор. Внешний Guard evidence сообщает host; Output остаётся намерением до отдельного подтверждения исполнения.

Подключаемые возможности

Extension — версионированный модуль языка, проверки, исполнения или проекции. Package содержит проверенные декларации и pinned данные; он не загружает произвольный код в CAP kernel. Неизвестный обязательный profile блокирует исполнение соответствующего artifact. Опциональную документную проекцию можно пропустить без изменения решения и Trace.

Локальный tyapkin-extension-set-v1 resolver уже проверяет точную замкнутость профилей, capability, version и artifact SHA-256: отсутствие модуля, несовпадающий pin, конфликт владельца и цикл отклоняются. Host должен отдельно хешировать установленные bytes; descriptor сам по себе не доказывает их наличие. Resolver находится в optional cap-cli, CAP kernel от него не зависит. Его подключение к publication и consumer preflight для остальных package/host профилей остаётся отдельной задачей.

Отдельный opt-in tyapkin-feature-package-v4 уже использует resolver при публикации и чтении: требует exact protobuf TypeRef/import/Flow профили и проверяет field-copy либо CEL v1/v2 against pinned schema. Это локальная граница Feature package, а не универсальный loader и не изменение CAP core. Текущий независимый consumer bundle Allium собран до v4.

Flow расширяет композицию, а не Transition одной Machine. Каждая Machine сохраняет собственный Trace. CEL вычисляет ограниченное содержимое target Input; он не назначает Principal, trigger или следующий Transition. .proto описывает поля и RPC, Capkin — их смысловое использование; на один TypeRef выбирается один явный владелец структуры.

Где определены сущности

Базовый строгий machine-v1 Feature определяет поведение одной Machine. Опциональный feature-module-v1 собирает несколько Feature в одну Machine. Другие опциональные Flow/Type Features определяют свои закрытые профили. Manifest фиксирует imports, версии и digests: Gherkin не имеет стандартного import. Из проверенных исходников строятся IR и read-only представления. Человеческое назначение контракта пишется рядом с исходниками, а Allium добавляет продуктовые LayerPackage, ApplicationRelease, instances и адаптеры.

Kernel не пишет в TechDocs и не создаёт Backstage Entity. Опциональный Describe выдаёт проверенные факты, extension дополняет их собственным namespaced разделом, а отдельный адаптер готовит страницы и каталог. TechDocs и Backstage не участвуют в decide/verify_trace.

Это целевая граница, а не уже готовая система динамических plugins. Для опубликованной Feature теперь есть checked documentation snapshot и отдельный TechDocs source adapter. Он не регистрирует Backstage Entity. Существующие Machine/Flow/Type profiles, локальные hosts и ContractStore сохраняют старые форматы; resolver ещё не является единым publication или consumer gate, общий DescribePackage отсутствует. Полное решение и порядок перехода записаны в docs/architecture/tyapkin-small-core-extension-boundary.md.

См. также язык Capkin, Federation и Flow и границу Tyapkin и Allium. Экспорт TechDocs показывает структуру артефакта и ограничения доверия.