Architecture

Kanbus treats Gherkin as high-level source code and treats implementation code as generated artifacts.

Spec-Driven Design

Gherkin features are treated as high-level source code.

Gherkin as Source Code

Kanbus treats its Gherkin features as high-level source code. The specifications are authoritative, and implementations are generated artifacts that must conform to them.

This is an extreme form of behavior-driven design: the Gherkin code is not derived from the implementation, it defines it.

Single Source of Truth

A shared features directory keeps behavior in lockstep.

One Shared Features Folder

Kanbus maintains a single features/ directory for behavior specifications. Both the Python and Rust implementations consume the exact same feature files.

This keeps parity at the specification level and prevents behavior drift between languages.

Multi-Target Implementations

Multiple languages, identical behavior.

Python

The Python implementation is designed for fast iteration and agent integration while remaining fully constrained by the shared behavior specifications.

Rust

The Rust implementation targets performance and reliability while staying behaviorally identical to the Python build through the same Gherkin specs.

Operational Implications

How spec-driven design shapes development.

Feature Work Starts With Gherkin

Every behavior change begins with a specification update. Code exists to satisfy specs, not the other way around.

Parity Is Non-Negotiable

Shared specifications plus parity checks ensure behavior remains identical across implementations.