Tyapkin
Capkin

Capkin Compiler

Pipeline Gherkin/Capkin source -> CAP IR -> protobuf contract -> runtime trace.

Capkin Compiler

Compiler is part of the MVP. The minimal machine-v1 Rust compiler now lives in capkin-machine; the existing CLI delegates to it. Its checked Machine can call CAP decide/verify_trace without optional profiles. See Библиотека одной Machine.

Capkin .feature
  -> closed Machine syntax and semantic checks
  -> Capkin Step Expressions
  -> Semantic Binder
  -> CAP IR
  -> protobuf MachineContract / ScenarioContract
  -> compiler backends

Local commands:

cargo run -p cap-cli --bin capkin -- compile --file tests/bdd/features/protocol/capkin-dex-compliance.feature
cargo run -p cap-cli --bin capkin -- validate --file tests/bdd/features/protocol/capkin-dex-compliance.feature

The minimal compiler supports the narrow Machine grammar used by the DEX + compliance fixture. This is a controlled profile, not natural language parsing. Every Rust .feature compiler now calls the shared check_gherkin_syntax before its closed semantic parser. The pinned Rust Gherkin parser checks syntax, while the official @cucumber/gherkin AST checks the supported corpus independently. Legacy semantic parsers and IR bytes remain versioned. Machine, Principal and Capability declarations are parsed from Gherkin steps in Background, so the source keeps a normal Gherkin shape while every step remains CAP-typed. In this machine-v1 profile, Feature must equal the declared machine ID; Scenario must equal a bound CAPKIN-* registry ID. Free-form prose belongs in docs and UI, not in the executable source. The exact proof phrase compiles to a typed VerifyEveryCommitment obligation, and an omitted proof step is rejected. Steps from one profile cannot silently become no-op text in another profile; the compiler rejects them when there is no runtime binding.

Semantic Binder

The Semantic Binder is the boundary between readable text and executable protocol contract. It validates:

  • unknown Principal;
  • missing Capability;
  • unknown State;
  • Guard without input binding;
  • output not allowed by current transition;
  • trace expectation that runtime cannot verify;
  • ambiguous or unsupported step text.

This is the layer that ordinary Cucumber/Gherkin tools do not provide. They can match step text; Capkin must prove that the matched text is a valid CAP machine.

Output

The first output is JSON IR with:

  • feature;
  • machine;
  • principals;
  • capabilities;
  • scenario;
  • proof_expectation;
  • states;
  • guards;
  • inputs;
  • outputs;
  • ordered steps.

The protobuf target is represented by:

  • proto/cap/v1/machine.proto;
  • proto/cap/v1/capkin.proto;
  • proto/cap/v1/trace.proto.

Compiler Backends

CAP IR is the source for portable outputs:

capkin-backend-protobuf
capkin-backend-rust-fixtures
capkin-backend-markdown
capkin-backend-cucumber-js
capkin-backend-behave-py
capkin-backend-reqnroll
capkin-backend-karate
capkin-backend-gauge

Karate and Gauge are not the canonical source of truth. They are useful execution/reporting targets generated from Capkin or CAP IR.

On this page