Tyapkin и Allium
Где заканчивается CAP + Capkin и начинается платформа для сборки приложений из слоёв.
Tyapkin и Allium
Allium by 11F36, based on Tyapkin. Это два разных продукта. Tyapkin
определяет протокол и язык; Allium собирает и эксплуатирует приложения из
совместимых слоёв. Локальные Git checkout разделены; публикация внешнего Tyapkin SDK ещё
предстоит. Полная карта находится в
docs/architecture/tyapkin-allium-boundary.md.
Allium: free text → Business Feature → automatic Feature check
→ draft per-layer Capkin → LayerPackage registry → ApplicationRelease
→ рабочий UI и API → host → адаптеры, данные, Observation
│
▼
Tyapkin: Capkin → CAP Machine IR → decide → Commitment/Trace → verifyFeature на входе Allium — русское описание желаемого поведения. Его
автоматическая проверка может вернуть вопросы или разрешить генерацию
черновиков; она не доказывает предметный факт. Feature: внутри строгого
Capkin означает MachineId, а не весь сквозной Feature приложения. В целевой
модели Tyapkin компилирует Machine и generic причинный Flow между их
смысловыми портами; Allium проверяет состав release и исполняет маршрут.
В Allium уже работает структурный Feature check и хранится черновое typed
mapping части шагов. Генерация всех строгих per-Machine Capkin sources и
семантическая готовность полного Feature ещё не достигнуты.
| Вопрос | Tyapkin | Allium |
|---|---|---|
| Что задаёт? | Общую семантику Machine, Principal, Capability, State, Input, Guard, Transition, Output, Commitment, Trace. | Бизнес-слои, их сборку, политику публикации и операционное приложение. |
| Что хранит? | Сам по себе не владеет бизнес-заказами и каталогом; текущий SQLite — reference host. | Неизменяемые LayerPackage, собранные release, instances, справочники и локальные/внешние observations. |
| Что исполняет? | Детерминированное решение и проверку Trace по переданным утверждениям. | Actor/Guard evidence, команды, адаптеры, UI, API и жизненный цикл эффектов. |
| Что доказывает? | Структуру перехода и целостность commitments относительно доверенного checkpoint; opt-in kernel также проверяет причинную связь evidence/receipts. | Источник и значение предметных фактов только в пределах собственных адаптеров и receipts. |
В целевой модели Tyapkin не знает, что такое кандидат, кофемашина, печать, подбор, лендинг или
AI builder. Он не утверждает, что локальное уведомление доставлено. Allium
может вызывать его как библиотеку, локальный процесс или сервис. Rust
decide/verify_trace и локальный versioned process bridge проверены;
удалённый kernel service API пока не реализован.
Что такое слой
LayerPackage в Allium закрепляет ID, version и digest опубликованных байтов,
Machine source, типы/порты, требования к адаптерам, UI-проекции и QA cases.
ApplicationRelease закрепляет версии и digest нескольких слоёв и их связи.
Секреты, адреса внешних систем и оперативный каталог лежат отдельно. CAP IR
digest описывает только Machine; package digest описывает весь опубликованный
пакет. Составное приложение хранит ссылки на Trace своих слоёв, не объявляя
их одним общим доказательством.
Локальный ContractStore Tyapkin хранит exact bytes generic контрактного
пакета по ID/version/digest. Он отличается от Allium LayerPackage
registry: не собирает приложение и не удостоверяет семантическую
компиляцию. Opt-in v2 import resolver может читать его exact bytes.
Опциональный Capkin Flow profile переносит generic
семантику причинного Output → Input в Tyapkin; imports, типы и federation
подключаются отдельными возможностями. Их граница описана в
решении о малом ядре.
Внешние .proto схемы дают структуру payload/RPC через pinned descriptors;
binding отделяет смысловой порт от имени метода. Allium будет выбирать и
исполнять проверенные версии Flow contracts в своём release. Локальные
compile-time checks и reference FlowRuntime реализованы; product activation,
реальный transport и hosted CI gate остаются отдельной приёмкой.
Legacy aggregation-package-v3 и matching-service находятся в отдельном
Allium checkout. Опубликованные coffee@2.0.0, printing@2.0.0 и
coffee@3.0.0 сохраняют свои байты, digest и старые replay readers. Tyapkin
содержит generic Capkin compiler и cap-kernel-bridge; его compiler/core/host
не имеют кофейной ветки. Allium потребляет локальный Rust API 0.1.0 и
tyapkin-kernel-bridge-v1 в одном направлении.
На 2026-10-09 отдельный opt-in путь Allium закрепил независимый Tyapkin
consumer bundle 0.1.0+ad61c318f8ae в release v4. Локальная проверка
проводит две Machine через pinned Flow, replay двух Trace и read-only сверку
конкретного Output → Input result перед статусом LOCAL_APPLIED. Внешняя
доставка остаётся NOT_OBSERVED. Это отдельный Feature release; ProCoffee
Demo пока использует прежний checked State/Flow контракт или legacy
full-service путь. Детали запуска и точные digests — в
runbook consumer bundle.
Локальный ApplicationRegistry в Allium проверяет неизменяемые LayerPackage,
порты, adapter contracts и состав ApplicationRelease. Для ProCoffee есть
локальные многослойные probes и отдельные пилоты, но они не образуют
принятый MVP release. Внешние trust roots и реальные adapters потребуют
отдельной приёмки. Срез состояния ProCoffee
показывает реестры, тесты и открытые gates; подробный план ведётся в Allium.
Opt-in kernel уже поддерживает generic evidence ports, составные Guards и несколько Output intentions. Публикация независимого SDK и внешний conformance остаются следующей протокольной работой.