Kiskin Expedition Onboarding

Это первый протокольный перенос Kiskin Office в CAP + Capkin. Цель не в том, чтобы отправить документы, видео и чаты в блокчейн. Цель в том, чтобы весь жизненный цикл стал проверяемой state machine:

State + Input + Capability + Guard
  -> State'
  -> Output
  -> Commitment
  -> Trace

Исходный Kiskin Office flow уже похож на живой contract board:

Ory/Kratos создает identity;
SimpleLogin/почта выдает readable aliases;
Paperless и Documenso собирают документы и подписи;
HR проверяет completeness board;
Grist фиксирует человека, команду, роль, доступы и документы;
Zulip, WorkAdventure, Jitsi, LiveKit, NetBird и Radicale дают рабочее присутствие;
Playwright/Bdd-сценарий KO-016 доказывает complete onboarding.

В CAP это становится не набором бизнес-слов в runtime, а доменным Capkin contract поверх маленького core vocabulary:

Machine
Principal
Capability
State
Input
Guard
Transition
Output
Commitment
Trace

Executable MVP Contract

Текущий compiler profile пока поддерживает один переход на сценарий. Поэтому первый исполняемый контракт сжимает complete board в один guard:

Feature: KiskinExpeditionOnboarding

# @registry:CAPKIN-KISKIN-001

  Background:
    Given machine KiskinExpeditionOnboarding
    And principal HR
    And principal Candidate
    And principal IdentityAdapter
    And principal DocumentAdapter
    And principal AccessAdapter
    And principal MeetingAdapter
    And principal RegistryAdapter
    And capability HR may commit ExpeditionOnboardingInput
    And capability HR may evaluate ExpeditionOnboardingInput
    And capability RegistryAdapter may commit ExpeditionMemberActivatedOutput

  Scenario: CAPKIN-KISKIN-001
    Given HR commits ExpeditionOnboardingInput
    When HR evaluates guard OnboardingBoardComplete
    Then the machine transitions from CollectingEvidence to MemberActivated
    And RegistryAdapter may commit ExpeditionMemberActivatedOutput
    And the trace proof verifies every commitment

Source file:

tests/bdd/features/kiskin/expedition-onboarding.feature

Run locally:

cargo run -p cap-cli --bin capkin -- compile --file tests/bdd/features/kiskin/expedition-onboarding.feature
cargo run -p cap-cli --bin capkin -- validate --file tests/bdd/features/kiskin/expedition-onboarding.feature

Domain Mapping

Kiskin Office term	CAP/Capkin role
Expedition	`Machine` boundary or machine family
HR	`Principal` with commit/evaluate capabilities
Candidate / Member	domain subject inside `Input`/`State`, not CAP principal unless they sign inputs
Ory/Kratos	`IdentityAdapter` principal that can commit identity evidence
Paperless / Documenso	`DocumentAdapter` principal that can commit document evidence
Grist registry	`RegistryAdapter` output owner
WorkAdventure / Zulip / NetBird	access/presence outputs
Jitsi / LiveKit / Radicale	meeting proof outputs
Complete board	`Guard` over collected evidence
Blockchain	anchoring target for trace commitments

Target Board

После расширения Capkin compiler до multi-transition saga этот же flow должен раскладываться на несколько машин или на одну длинную machine:

Draft
  -> IdentityRegistered
  -> DocumentsRequested
  -> DocumentsUploaded
  -> ContractSigned
  -> AccessGranted
  -> PresenceVerified
  -> MemberActivated

Возможные domain inputs:

IdentityRegisteredInput
ServiceAliasesProvisionedInput
DocumentsUploadedInput
AgreementSignedInput
AccessGrantInput
MeetingProofInput
RegistryActivationInput

Возможные guards:

IdentityBoundToOry
RequiredDocumentsComplete
AgreementAndNdaSigned
AccessMatrixApproved
MeetingProofObserved
OnboardingBoardComplete

Возможные outputs:

IdentityProvisionedOutput
DocumentVaultUpdatedOutput
AgreementAcceptedOutput
AccessGrantedOutput
MeetingProofCreatedOutput
ExpeditionMemberActivatedOutput

Правило остается тем же: Kiskin semantics живут в Capkin contracts, extensions, fixtures, adapters и projections. CAP runtime не узнает, что такое HR, Grist, Zulip, WorkAdventure или экспедиция.

Kiskin Expedition Onboarding

Kiskin Expedition Onboarding

Executable MVP Contract

Domain Mapping

Target Board

On this page