Architecture
Taskulus 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
Taskulus 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
Taskulus 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.