# Варианты использования (/docs/guide/use-cases)



## Три способа применить Тяпкин [#три-способа-применить-тяпкин]

У Тяпкина одна роль: проверить допустимость перехода и сохранить проверяемую
историю. Предметный смысл, интерфейс и интеграции остаются у вашего продукта.

### 01 / Приложения из связанных возможностей [#01--приложения-из-связанных-возможностей]

**Пример — Allium.** Сервисная заявка, планирование визита и учёт оборудования
могут иметь отдельные Machine. Их входы, состояния и полномочия описываются
явно; приложение связывает проверенные версии и управляет исполнением.

Человеческий сценарий: сотрудник регистрирует поломку, система проверяет
условия принятия, затем приложение создаёт задачу следующему участнику.
Каждая Machine сохраняет свою Trace.

Allium — отдельный продукт, который потребляет Tyapkin. Локальный срез с двумя
Machine, причинным Flow и restart/replay проверен; это не подтверждение всех
внешних интеграций или активации production release.

[Граница Tyapkin и Allium](/docs/architecture/tyapkin-allium-boundary) ·
[Проверенный consumer bundle](/docs/runbooks/tyapkin-consumer-bundle)

### 02 / Разработка от сценариев и тестов [#02--разработка-от-сценариев-и-тестов]

**Начните с поведения.** До реализации договоритесь, кто подаёт Input,
какие условия проверяются, какой State допустим и какой Output ожидается.
Capkin использует строгий Gherkin-совместимый профиль.

Человеческий сценарий: команда описывает приём заявки, затем добавляет случаи
«нет полномочий», «условия не выполнены» и «повторный запрос». Эти примеры
становятся основой проверки контракта и реализации.

Компилятор проверяет допустимый язык и структуру. Проверка Trace показывает
соответствие конкретной истории контракту. Покрытие всех бизнес-ситуаций
нужно отдельно подтвердить тестами приложения.

[Feature и Machine](/docs/capkin/feature-ownership) ·
[Язык Capkin](/docs/capkin/language)

### 03 / Контролируемые действия агента [#03--контролируемые-действия-агента]

**Возможное применение — GAD3000.** Агент предлагает действие, а детерминированные
правила определяют, можно ли его выполнить. Например, команда на изменение
размещения проходит проверку полномочий и условий до передачи адаптеру.

Человеческий сценарий: оператор видит предложенную команду, правила её допуска
и зафиксированное решение. Результат внешнего исполнения приходит отдельно
и связывается с намерением.

Это сценарий проектирования. Готовая интеграция Tyapkin с GAD3000 здесь не
подтверждается; нужен отдельный контракт, адаптер и проверка полного пути.
Суждение модели само по себе не предоставляет Capability и не доказывает факт.

[Как принимается решение](/guide/how-it-works) ·
[Граница evidence и внешних эффектов](/docs/runtime/kernel-vnext)