Documentation Index
Fetch the complete documentation index at: https://mintlify.com/fulsomenko/kanban/llms.txt
Use this file to discover all available pages before exploring further.
Overview
Kanban is a terminal-based kanban/project management tool written in Rust, inspired by lazygit’s interface design. It follows SOLID principles with a clean, modular architecture using Cargo workspaces.Tech Stack
Language
Rust 2021 edition with full type safety
TUI Framework
ratatui + crossterm for terminal rendering
Async Runtime
Tokio for asynchronous operations
Development
Nix for reproducible builds
Workspace Structure
The project uses a Cargo workspace with six specialized crates:Dependency Flow
The architecture respects the dependency inversion principle: All layers depend on abstractions (traits), not concrete implementations.Crate Descriptions
kanban-core
Foundation Crate
Shared abstractions and utilities used across all other crates
KanbanError- Centralized error types usingthiserrorKanbanResult<T>- Standard result type aliasGraph<N, E>- Generic graph data structure for dependenciesInputState- Text input handlingAppConfig- Application configurationSelectionState- UI selection managementEditable- Trait for editable entities
- Error handling with
thiserror - Async traits with
async-trait - Type-safe graph operations
kanban-domain
Business Logic
Pure domain models with no infrastructure dependencies
Board- Top-level kanban board with columns and metadataColumn- Board columns with WIP limits and orderingCard- Task cards with priority, status, due dates, story pointsTag- Categorization tagsSprint- Sprint planning and trackingArchivedCard- Historical card data
- Rich domain models with behavior methods
- Command pattern for state mutations
- Card dependency graph with blocking relationships
- Search and filtering capabilities
- Export/import functionality
- History management for undo/redo
kanban-persistence
Data Layer
Progressive auto-save with conflict detection
- Progressive Auto-Save: Changes saved immediately after each operation
- Async Processing: Commands queued via bounded channel, processed by background worker
- Conflict Detection: Multi-instance changes detected via file metadata
- Format Versioning: Automatic V1→V2 migration with backup creation
- Atomic Writes: Crash-safe pattern (temp file → atomic rename)
- Own-Write Detection: Metadata-based filtering prevents false positives
notifyfor file watchingtempfilefor atomic writesserde_jsonfor serialization
kanban-tui
User Interface
Event-driven terminal UI with ratatui
app- Application state and main event loopui- Rendering components using ratatui widgetsevents- Keyboard and terminal event handlinginput- Input state managementdialog- Dialog interaction patternseditor- External editor integration
- Vim-like keyboard navigation (hjkl)
- Multiple view modes (board, list, task list)
- Context-aware shortcuts
- Modal dialogs for input
- External editor support
- Clipboard integration with
arboard - Markdown rendering with
pulldown-cmark
kanban-cli
CLI Entry Point
Command-line interface using clap
- Command parsing with
clap - Subcommand handlers (board, card, column, sprint, export)
- Tracing/logging initialization
- TUI coordination
- Shell completion generation
kanban-mcp
MCP Server
Model Context Protocol integration for LLMs
- Full read/write access to boards, cards, columns, sprints
- JSON-RPC over stdio using
rmcpSDK - Resource and tool endpoints
- Schema validation with
schemars
SOLID Principles
The architecture strictly follows SOLID principles:Single Responsibility Principle
Single Responsibility Principle
Each crate has one clear purpose:
kanban-core: Foundation utilitieskanban-domain: Business logickanban-persistence: Data storagekanban-tui: User interfacekanban-cli: Command-line interfacekanban-mcp: Protocol server
Open/Closed Principle
Open/Closed Principle
Domain models are extensible through methods without modifying existing code. New features add behavior without breaking existing functionality.
Liskov Substitution Principle
Liskov Substitution Principle
Types are consistent and predictable. All implementations of traits can be substituted without breaking behavior.
Interface Segregation Principle
Interface Segregation Principle
Traits are minimal and focused (e.g.,
Editable, GraphNode). No client is forced to depend on methods it doesn’t use.Dependency Inversion Principle
Dependency Inversion Principle
All layers depend on abstractions (traits), not concrete implementations. Higher-level modules don’t depend on lower-level modules directly.
Design Patterns
Command Pattern
All state mutations use the command pattern for undo/redo support:- Event Handler (TUI): Processes keyboard input
- Command: Encapsulates the mutation
- StateManager: Executes command via
CommandContext - Dirty Flag: Marks state as dirty
- Progressive Save: Auto-saves via async channel
Repository Pattern
Persistence layer abstracts data access:Observer Pattern
File watching for multi-instance conflict detection:Inspirations from lazygit
The TUI design follows lazygit’s proven patterns:Keyboard-Driven
Vim-like navigation with hjkl and modal interfaces
Panel-Based Layout
Multiple views (boards, columns, cards) with clear focus
Contextual Commands
Bottom panel shows available shortcuts for current context
Fast Navigation
Quick jumps, search, and efficient workflows
Type Safety
Leverage Rust’s type system for correctness:The newtype pattern prevents mixing IDs of different entity types at compile time.
Error Handling Strategy
Performance Considerations
- Minimal Allocations: Use
&stroverStringwhere possible - Async I/O: Tokio for non-blocking file operations
- Efficient Rendering: Only redraw changed UI components
- Lazy Loading: Load boards on-demand
- Release Profile: LTO, single codegen unit, strip symbols
Next Steps
Contributing
Learn how to contribute to the codebase
Domain Models
Explore domain models for boards, cards, columns, and sprints
