Architecture
How Kanbus is built
Kanbus is specified in Gherkin and implemented twice, in Python and in Rust, against the same specifications, so the two command lines behave the same.
The specifications are the source
Kanbus treats its Gherkin feature files as the highest-level source code. The specifications are authoritative, and the Python and Rust implementations are built to satisfy them. The specifications are not derived from the code; they define it.
Every change in behavior starts with a specification. Code exists to make the specifications pass, not the other way around.
One features folder, two implementations
Both implementations run the exact same feature files from a single features/ folder, so parity is checked at the level of behavior and the two cannot quietly drift apart.
Python
The kanbus command, built for quick iteration and for embedding Kanbus in Python tools and agents.
Rust
The kbs command and the kbsc board server, built for speed and reliability, and behaviorally identical to the Python build.
The pieces around the files
The CLI
Reads and writes issue files directly. Every command can print JSON, which is how agents and scripts use it.
The board
kbsc serves a board over the same files and updates as they change. The same React components power the hosted board and boards embedded in other apps.
Live updates
Changes are announced over a local socket or an MQTT broker, and an overlay cache shows them before git catches up. The files stay the source of truth.
The wiki
Markdown pages with templates that query the issue graph, so planning documents always show current status.
The issue router
Reads the board, dispatches eligible issues to coding agents within your limits and follows their pull requests.
The API
kanbus-api reuses the same models and workflow rules over S3 and DynamoDB for applications that embed a board.