chore(release): 4.27.2 [skip ci]

## [4.27.2](https://github.com/bmadcode/BMAD-METHOD/compare/v4.27.1...v4.27.2) (2025-07-07)

### Bug Fixes

* improve output ([a5ffe7b](a5ffe7b9b2))

CHANGELOG.md

@@ -1,3 +1,10 @@
+## [4.27.2](https://github.com/bmadcode/BMAD-METHOD/compare/v4.27.1...v4.27.2) (2025-07-07)
+
+
+### Bug Fixes
+
+* improve output ([a5ffe7b](https://github.com/bmadcode/BMAD-METHOD/commit/a5ffe7b9b209ae02a9d97adf60fe73c0bc9701e4))
+
 ## [4.27.1](https://github.com/bmadcode/BMAD-METHOD/compare/v4.27.0...v4.27.1) (2025-07-07)
 
 

bmad-core/templates/architecture-tmpl.yaml

@@ -629,7 +629,6 @@ sections:
       After completing the architecture:
       
       1. If project has UI components:
-      - Recommend engaging Design Architect agent
       - Use "Frontend Architecture Mode"
       - Provide this document as input
       
@@ -640,19 +639,12 @@ sections:
       
       3. Include specific prompts for next agents if needed
     sections:
-      - id: design-architect-prompt
-        title: Design Architect Prompt
+      - id: architect-prompt
+        title: Architect Prompt
         condition: Project has UI components
         instruction: |
-          Create a brief prompt to hand off to Design Architect for Frontend Architecture creation. Include:
+          Create a brief prompt to hand off to Architect for Frontend Architecture creation. Include:
           - Reference to this architecture document
           - Key UI requirements from PRD
           - Any frontend-specific decisions made here
           - Request for detailed frontend architecture
-      - id: developer-handoff
-        title: Developer Handoff
-        instruction: |
-          Create a brief prompt for developers starting implementation. Include:
-          - Reference to this architecture and coding standards
-          - First epic/story to implement
-          - Key technical decisions to follow

bmad-core/templates/prd-tmpl.yaml

@@ -194,9 +194,9 @@ sections:
   - id: next-steps
     title: Next Steps
     sections:
-      - id: design-architect-prompt
-        title: Design Architect Prompt
-        instruction: This section will contain the prompt for the Design Architect, keep it short and to the point to initiate create architecture mode using this document as input.
+      - id: ux-expert-prompt
+        title: UX Expert Prompt
+        instruction: This section will contain the prompt for the UX Expert, keep it short and to the point to initiate create architecture mode using this document as input.
       - id: architect-prompt
         title: Architect Prompt
         instruction: This section will contain the prompt for the Architect, keep it short and to the point to initiate create architecture mode using this document as input.

package-lock.json

@@ -1,12 +1,12 @@
 {
   "name": "bmad-method",
-  "version": "4.27.1",
+  "version": "4.27.2",
   "lockfileVersion": 3,
   "requires": true,
   "packages": {
     "": {
       "name": "bmad-method",
-      "version": "4.27.1",
+      "version": "4.27.2",
       "license": "MIT",
       "dependencies": {
         "@kayvan/markdown-tree-parser": "^1.5.0",

package.json

@@ -1,6 +1,6 @@
 {
   "name": "bmad-method",
-  "version": "4.27.1",
+  "version": "4.27.2",
   "description": "Breakthrough Method of Agile AI-driven Development",
   "main": "tools/cli.js",
   "bin": {

tools/installer/package.json

@@ -1,6 +1,6 @@
 {
   "name": "bmad-method",
-  "version": "4.27.1",
+  "version": "4.27.2",
   "description": "BMad Method installer - AI-powered Agile development framework",
   "main": "lib/installer.js",
   "bin": {

zoo/docs/architecture.md

@@ -0,0 +1,812 @@
+# TermTodo Architecture Document
+
+## Introduction
+
+This document outlines the overall project architecture for TermTodo, including backend systems, shared services, and non-UI specific concerns. Its primary goal is to serve as the guiding architectural blueprint for AI-driven development, ensuring consistency and adherence to chosen patterns and technologies.
+
+**Relationship to Frontend Architecture:**
+If the project includes a significant user interface, a separate Frontend Architecture Document will detail the frontend-specific design and MUST be used in conjunction with this document. Core technology stack choices documented herein (see "Tech Stack") are definitive for the entire project, including any frontend components.
+
+### Starter Template or Existing Project
+
+N/A - This is a greenfield Rust CLI project with no starter template.
+
+### Change Log
+
+| Date       | Version | Description                                | Author              |
+| ---------- | ------- | ------------------------------------------ | ------------------- |
+| 2025-07-07 | 1.0     | Initial architecture based on TermTodo PRD | Winston (Architect) |
+
+## High Level Architecture
+
+### Technical Summary
+
+TermTodo is a monolithic, single-binary CLI application built with Rust, utilizing embedded SQLite for ACID-compliant local storage. The architecture employs clean architecture principles with clear separation between CLI parsing, business logic, and data persistence layers. Performance-critical design choices including synchronous execution, prepared statement caching, and minimal dependencies ensure sub-100ms command execution. The system implements repository and command patterns to maintain testability while delivering a zero-configuration tool that integrates seamlessly into developer workflows.
+
+### High Level Overview
+
+**Architectural Style:** Monolithic Single Binary
+
+- All functionality compiled into one executable for instant startup
+- No network dependencies or service discovery overhead
+- Embedded SQLite database with local file storage
+
+**Repository Structure:** Monorepo
+
+- Single repository containing all code, tests, and documentation
+- Simplified dependency management and atomic commits
+- Unified CI/CD pipeline for all components
+
+**Service Architecture:** Monolith
+
+- Single process handling all operations
+- Synchronous execution model (no async runtime needed)
+- Direct database access without network layers
+
+**Primary Data Flow:**
+
+1. User invokes `todo` command with arguments
+2. CLI parser validates and routes to appropriate command handler
+3. Command handler orchestrates business logic operations
+4. Repository layer manages SQLite transactions
+5. Formatted output returned to terminal
+
+**Key Architectural Decisions:**
+
+- **Synchronous Model**: Eliminates async runtime overhead for faster cold starts
+- **Embedded Database**: Zero configuration, portable data storage
+- **Static Linking**: Single binary distribution with no runtime dependencies
+- **Clean Architecture**: Testable layers despite monolithic structure
+
+### High Level Project Diagram
+
+```mermaid
+graph TB
+    User[Terminal User]
+
+    subgraph "TermTodo Binary"
+        CLI[CLI Parser<br/>clap v4]
+        CMD[Command Handlers]
+        BL[Business Logic]
+        REPO[Repository Layer]
+        DB[(SQLite DB)]
+        CONFIG[Config Manager<br/>TOML]
+    end
+
+    subgraph "File System"
+        DBFILE[todo.db]
+        CFGFILE[config.toml]
+    end
+
+    User -->|todo add/list/etc| CLI
+    CLI -->|Parsed Commands| CMD
+    CMD -->|Operations| BL
+    BL -->|Data Access| REPO
+    REPO -->|SQL| DB
+    DB -.->|File I/O| DBFILE
+    CONFIG -.->|Read/Write| CFGFILE
+
+    style User fill:#e1f5fe
+    style CLI fill:#fff3e0
+    style CMD fill:#fff3e0
+    style BL fill:#f3e5f5
+    style REPO fill:#e8f5e9
+    style DB fill:#e8f5e9
+```
+
+### Architectural and Design Patterns
+
+- **Clean Architecture:** Separation of concerns with CLI, Application, Domain, and Infrastructure layers - _Rationale:_ Enables 80%+ test coverage requirement by isolating business logic from I/O operations
+
+- **Repository Pattern:** Abstract SQLite operations behind trait-based interfaces - _Rationale:_ Allows in-memory repositories for unit tests and potential future database migrations
+
+- **Command Pattern:** Each CLI subcommand as a discrete handler with execute method - _Rationale:_ Simplifies testing and follows clap's natural structure for maintainable command routing
+
+- **Builder Pattern:** Fluent interfaces for constructing complex queries and task filters - _Rationale:_ Provides readable API for combining multiple filter criteria while maintaining performance
+
+- **Result/Option Monads:** Explicit error handling using Rust's type system - _Rationale:_ Prevents runtime panics and enables graceful error messages as required by NFR13
+
+## Tech Stack
+
+This is the DEFINITIVE technology selection for TermTodo. All implementation must use these exact versions and technologies.
+
+### Cloud Infrastructure
+
+- **Provider:** Local-only (No cloud requirements)
+- **Key Services:** N/A
+- **Deployment Regions:** N/A
+
+### Technology Stack Table
+
+| Category               | Technology     | Version | Purpose                       | Rationale                                                                 |
+| ---------------------- | -------------- | ------- | ----------------------------- | ------------------------------------------------------------------------- |
+| **Language**           | Rust           | 1.78.0  | Primary development language  | Zero-cost abstractions, memory safety, single binary output               |
+| **Database**           | SQLite         | 3.45.0  | Embedded database             | ACID compliance, zero configuration, excellent performance                |
+| **CLI Framework**      | clap           | 4.5.4   | Command-line argument parsing | Automatic help generation, shell completion, strong typing                |
+| **ORM/Query Builder**  | sqlx           | 0.7.4   | Database operations           | Compile-time checked queries, async support (if needed later), migrations |
+| **Date Parsing**       | chrono         | 0.4.38  | Date/time handling            | Comprehensive timezone support, widely adopted                            |
+| **Human Date Parsing** | chrono-english | 0.1.7   | Natural language dates        | Parses "tomorrow", "next friday" as required                              |
+| **Serialization**      | serde          | 1.0.197 | JSON/CSV export               | De facto standard, excellent performance                                  |
+| **Configuration**      | toml           | 0.8.12  | Config file parsing           | Human-readable, simple for users                                          |
+| **Terminal Colors**    | termcolor      | 1.4.1   | Colored output                | Respects NO_COLOR, cross-platform                                         |
+| **Error Handling**     | anyhow         | 1.0.82  | Application errors            | Simplified error handling with context                                    |
+| **Error Types**        | thiserror      | 1.0.58  | Custom error types            | Derive macro for error enums                                              |
+| **Testing**            | built-in       | std     | Unit/integration tests        | Rust's excellent built-in test framework                                  |
+| **Benchmarking**       | criterion      | 0.5.1   | Performance testing           | Statistical benchmarking for CI regression detection                      |
+| **Logging**            | env_logger     | 0.11.3  | Debug logging                 | Simple, runtime-configurable via RUST_LOG                                 |
+
+## Data Models
+
+### Task
+
+**Purpose:** Core entity representing a single todo item with all associated metadata
+
+**Key Attributes:**
+
+- `id`: i64 - Unique identifier (SQLite ROWID)
+- `description`: String - Task description (up to 1000 chars)
+- `status`: TaskStatus - Enum (Incomplete/Complete)
+- `project`: Option<String> - Optional project grouping
+- `priority`: Priority - Enum (High/Medium/Low), defaults to Medium
+- `due_date`: Option<DateTime> - Optional due date with timezone
+- `created_at`: DateTime - Creation timestamp
+- `updated_at`: DateTime - Last modification timestamp
+- `completed_at`: Option<DateTime> - Completion timestamp
+
+**Relationships:**
+
+- Has many Tags (many-to-many via task_tags table)
+- Belongs to one Project (denormalized for performance)
+
+### Tag
+
+**Purpose:** Flexible categorization system for tasks
+
+**Key Attributes:**
+
+- `id`: i64 - Unique identifier
+- `name`: String - Tag name (alphanumeric + dash/underscore)
+- `created_at`: DateTime - First use timestamp
+
+**Relationships:**
+
+- Has many Tasks (many-to-many via task_tags table)
+- Cascade delete orphaned tags
+
+### TaskTag
+
+**Purpose:** Junction table for many-to-many task-tag relationship
+
+**Key Attributes:**
+
+- `task_id`: i64 - Foreign key to tasks
+- `tag_id`: i64 - Foreign key to tags
+
+**Relationships:**
+
+- Composite primary key (task_id, tag_id)
+- ON DELETE CASCADE for both foreign keys
+
+## Components
+
+### CLI Parser
+
+**Responsibility:** Parse command-line arguments, validate inputs, and route to appropriate command handlers
+
+**Key Interfaces:**
+
+- `parse_args()` - Main entry point parsing std::env::args()
+- `generate_completions()` - Shell completion script generation
+- Subcommand routing to handlers
+
+**Dependencies:** clap v4 for parsing, command handlers for execution
+
+**Technology Stack:** Pure Rust with clap derive macros for type-safe parsing
+
+### Command Handlers
+
+**Responsibility:** Orchestrate business logic for each CLI subcommand (add, list, complete, etc.)
+
+**Key Interfaces:**
+
+- `execute(&self, app: &Application) -> Result<()>` - Common trait for all commands
+- Command-specific structs with validated parameters
+- Output formatting for terminal display
+
+**Dependencies:** Application service layer, terminal output formatters
+
+**Technology Stack:** Rust structs implementing Command trait, termcolor for output
+
+### Application Service
+
+**Responsibility:** Core business logic and workflow orchestration independent of I/O concerns
+
+**Key Interfaces:**
+
+- `add_task(desc: &str, opts: AddOptions) -> Result<Task>`
+- `list_tasks(filters: FilterOptions) -> Result<Vec<Task>>`
+- `complete_tasks(ids: &[i64]) -> Result<usize>`
+- `search_tasks(query: &str) -> Result<Vec<Task>>`
+
+**Dependencies:** Repository interfaces (traits), domain models
+
+**Technology Stack:** Pure Rust business logic with Result-based error handling
+
+### Repository Layer
+
+**Responsibility:** Abstract data persistence operations with SQLite implementation
+
+**Key Interfaces:**
+
+- `TaskRepository` trait with CRUD operations
+- `TagRepository` trait for tag management
+- `Transaction` support for atomic operations
+- Migration runner for schema updates
+
+**Dependencies:** sqlx for database access, domain models
+
+**Technology Stack:** sqlx with compile-time checked queries, connection pooling
+
+### Configuration Manager
+
+**Responsibility:** Load, validate, and provide access to user configuration
+
+**Key Interfaces:**
+
+- `load_config() -> Result<Config>` - Load from XDG directory
+- `save_config(&Config) -> Result<()>` - Persist changes
+- `get_default_project()` - Typed config access
+
+**Dependencies:** toml for parsing, serde for serialization
+
+**Technology Stack:** TOML files with serde deserialization
+
+### Database Manager
+
+**Responsibility:** SQLite connection lifecycle, migrations, and performance optimization
+
+**Key Interfaces:**
+
+- `connect() -> Result<SqlitePool>` - Initialize connection pool
+- `run_migrations() -> Result<()>` - Apply schema updates
+- Prepared statement caching
+- PRAGMA optimizations
+
+**Dependencies:** sqlx SQLite driver, migration files
+
+**Technology Stack:** SQLite with WAL mode, connection pool size of 1
+
+### Component Diagram
+
+```mermaid
+graph LR
+    subgraph "Presentation Layer"
+        CLI[CLI Parser]
+        FMT[Output Formatter]
+    end
+
+    subgraph "Application Layer"
+        CMD[Command Handlers]
+        APP[Application Service]
+    end
+
+    subgraph "Domain Layer"
+        MODELS[Domain Models]
+        TRAITS[Repository Traits]
+    end
+
+    subgraph "Infrastructure Layer"
+        REPO[SQLite Repository]
+        CONFIG[Config Manager]
+        DB[Database Manager]
+    end
+
+    CLI --> CMD
+    CMD --> APP
+    CMD --> FMT
+    APP --> TRAITS
+    TRAITS --> REPO
+    REPO --> DB
+    APP --> MODELS
+    CONFIG --> APP
+
+    style CLI fill:#fff3e0
+    style CMD fill:#fff3e0
+    style APP fill:#f3e5f5
+    style REPO fill:#e8f5e9
+    style DB fill:#e8f5e9
+```
+
+## External APIs
+
+This project does not require any external API integrations. All operations are performed locally with no network dependencies.
+
+## Core Workflows
+
+### Add Task Workflow
+
+```mermaid
+sequenceDiagram
+    participant User
+    participant CLI
+    participant CMD as AddCommand
+    participant APP as Application
+    participant REPO as Repository
+    participant DB as SQLite
+
+    User->>CLI: todo add "Review PR" -p work -P high +review
+    CLI->>CMD: parse_add_command()
+    CMD->>CMD: validate_description_length()
+    CMD->>APP: add_task(desc, options)
+    APP->>APP: parse_tags_from_description()
+    APP->>REPO: begin_transaction()
+    REPO->>DB: BEGIN TRANSACTION
+    APP->>REPO: insert_task(task)
+    REPO->>DB: INSERT INTO tasks...
+    DB-->>REPO: task_id = 42
+    APP->>REPO: insert_tags(task_id, tags)
+    REPO->>DB: INSERT INTO tags...
+    REPO->>DB: INSERT INTO task_tags...
+    APP->>REPO: commit()
+    REPO->>DB: COMMIT
+    APP-->>CMD: Task { id: 42, ... }
+    CMD->>User: ✓ Added task #42
+```
+
+### List Tasks with Filters Workflow
+
+```mermaid
+sequenceDiagram
+    participant User
+    participant CLI
+    participant CMD as ListCommand
+    participant APP as Application
+    participant REPO as Repository
+    participant DB as SQLite
+    participant FMT as Formatter
+
+    User->>CLI: todo list -p work -P high --due
+    CLI->>CMD: parse_list_command()
+    CMD->>APP: list_tasks(filters)
+    APP->>REPO: find_tasks_with_filters(filters)
+    REPO->>REPO: build_query_with_filters()
+    REPO->>DB: SELECT ... WHERE project=? AND priority=? AND due_date IS NOT NULL
+    DB-->>REPO: Vec<TaskRow>
+    REPO->>REPO: load_tags_for_tasks(task_ids)
+    REPO->>DB: SELECT ... FROM task_tags WHERE task_id IN (...)
+    DB-->>REPO: Vec<TagRow>
+    REPO-->>APP: Vec<Task>
+    APP-->>CMD: Vec<Task>
+    CMD->>FMT: format_task_list(tasks)
+    FMT->>User: ID  Description           Project  Priority  Due        Tags<br/>42  Review PR            work     !!!       tomorrow   #review
+```
+
+### Complete Task with Toggle Workflow
+
+```mermaid
+sequenceDiagram
+    participant User
+    participant CLI
+    participant CMD as CompleteCommand
+    participant APP as Application
+    participant REPO as Repository
+    participant DB as SQLite
+
+    User->>CLI: todo complete 42 43
+    CLI->>CMD: parse_complete_command()
+    CMD->>APP: complete_tasks([42, 43])
+
+    loop For each task_id
+        APP->>REPO: find_task_by_id(task_id)
+        REPO->>DB: SELECT ... WHERE id = ?
+        DB-->>REPO: Task
+
+        alt Task exists
+            APP->>APP: toggle_status(task)
+            APP->>REPO: update_task_status(id, new_status)
+            REPO->>DB: UPDATE tasks SET status=?, completed_at=?
+            DB-->>REPO: 1 row affected
+        else Task not found
+            APP->>APP: record_error(task_id)
+        end
+    end
+
+    APP-->>CMD: CompletionResult { success: 2, failed: 0 }
+    CMD->>User: ✓ Completed tasks: #42, #43
+```
+
+## Database Schema
+
+```sql
+-- Enable foreign key constraints
+PRAGMA foreign_keys = ON;
+
+-- Enable Write-Ahead Logging for better concurrency
+PRAGMA journal_mode = WAL;
+
+-- Optimize for fast reads
+PRAGMA synchronous = NORMAL;
+PRAGMA temp_store = MEMORY;
+PRAGMA mmap_size = 30000000000;
+
+-- Tasks table: Core entity
+CREATE TABLE tasks (
+    id INTEGER PRIMARY KEY AUTOINCREMENT,
+    description TEXT NOT NULL CHECK(length(description) <= 1000),
+    status TEXT NOT NULL DEFAULT 'incomplete' CHECK(status IN ('incomplete', 'complete')),
+    project TEXT,
+    priority TEXT NOT NULL DEFAULT 'medium' CHECK(priority IN ('high', 'medium', 'low')),
+    due_date DATETIME,
+    created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
+    updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
+    completed_at DATETIME
+);
+
+-- Indexes for common query patterns
+CREATE INDEX idx_tasks_status ON tasks(status);
+CREATE INDEX idx_tasks_project ON tasks(project) WHERE project IS NOT NULL;
+CREATE INDEX idx_tasks_priority ON tasks(priority);
+CREATE INDEX idx_tasks_due_date ON tasks(due_date) WHERE due_date IS NOT NULL;
+CREATE INDEX idx_tasks_created_at ON tasks(created_at);
+
+-- Composite index for common filter combinations
+CREATE INDEX idx_tasks_filters ON tasks(status, project, priority);
+
+-- Tags table
+CREATE TABLE tags (
+    id INTEGER PRIMARY KEY AUTOINCREMENT,
+    name TEXT NOT NULL UNIQUE CHECK(name REGEXP '^[a-zA-Z0-9][a-zA-Z0-9_-]*$'),
+    created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP
+);
+
+-- Junction table for many-to-many relationship
+CREATE TABLE task_tags (
+    task_id INTEGER NOT NULL,
+    tag_id INTEGER NOT NULL,
+    PRIMARY KEY (task_id, tag_id),
+    FOREIGN KEY (task_id) REFERENCES tasks(id) ON DELETE CASCADE,
+    FOREIGN KEY (tag_id) REFERENCES tags(id) ON DELETE CASCADE
+);
+
+-- Index for tag lookups
+CREATE INDEX idx_task_tags_tag_id ON task_tags(tag_id);
+
+-- Full-text search virtual table
+CREATE VIRTUAL TABLE tasks_fts USING fts5(
+    description,
+    project,
+    content=tasks,
+    content_rowid=id
+);
+
+-- Triggers to keep FTS index in sync
+CREATE TRIGGER tasks_fts_insert AFTER INSERT ON tasks
+BEGIN
+    INSERT INTO tasks_fts(rowid, description, project)
+    VALUES (new.id, new.description, new.project);
+END;
+
+CREATE TRIGGER tasks_fts_update AFTER UPDATE ON tasks
+BEGIN
+    UPDATE tasks_fts
+    SET description = new.description, project = new.project
+    WHERE rowid = old.id;
+END;
+
+CREATE TRIGGER tasks_fts_delete AFTER DELETE ON tasks
+BEGIN
+    DELETE FROM tasks_fts WHERE rowid = old.id;
+END;
+
+-- Update trigger for updated_at timestamp
+CREATE TRIGGER tasks_update_timestamp AFTER UPDATE ON tasks
+BEGIN
+    UPDATE tasks SET updated_at = CURRENT_TIMESTAMP WHERE id = NEW.id;
+END;
+
+-- Migration tracking table
+CREATE TABLE IF NOT EXISTS schema_migrations (
+    version INTEGER PRIMARY KEY,
+    applied_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP
+);
+```
+
+## Source Tree
+
+```plaintext
+termtodo/
+├── Cargo.toml                 # Project manifest with dependencies
+├── Cargo.lock                # Locked dependency versions
+├── build.rs                   # Build script for embedding resources
+├── .github/
+│   └── workflows/
+│       ├── ci.yml            # Test, lint, build on all platforms
+│       └── release.yml       # Build and publish binaries on tag
+├── src/
+│   ├── main.rs              # Entry point, CLI setup
+│   ├── cli/
+│   │   ├── mod.rs           # CLI module exports
+│   │   ├── parser.rs        # Clap command definitions
+│   │   ├── commands/        # Command handlers
+│   │   │   ├── mod.rs
+│   │   │   ├── add.rs       # Add command implementation
+│   │   │   ├── list.rs      # List command with formatting
+│   │   │   ├── complete.rs  # Complete/uncomplete logic
+│   │   │   ├── delete.rs    # Delete command
+│   │   │   ├── search.rs    # Full-text search
+│   │   │   └── config.rs    # Config management commands
+│   │   └── output.rs        # Terminal output formatting
+│   ├── app/
+│   │   ├── mod.rs           # Application layer exports
+│   │   ├── service.rs       # Main application service
+│   │   ├── filters.rs       # Filter builder and logic
+│   │   └── errors.rs        # Application error types
+│   ├── domain/
+│   │   ├── mod.rs           # Domain model exports
+│   │   ├── task.rs          # Task entity and value objects
+│   │   ├── tag.rs           # Tag entity
+│   │   └── types.rs         # Enums (Status, Priority)
+│   ├── infra/
+│   │   ├── mod.rs           # Infrastructure exports
+│   │   ├── db/
+│   │   │   ├── mod.rs       # Database module
+│   │   │   ├── connection.rs # Connection pool setup
+│   │   │   ├── migrations.rs # Migration runner
+│   │   │   └── queries.rs   # SQL query constants
+│   │   ├── repos/
+│   │   │   ├── mod.rs       # Repository traits
+│   │   │   ├── task_repo.rs # Task repository impl
+│   │   │   └── tag_repo.rs  # Tag repository impl
+│   │   └── config/
+│   │       ├── mod.rs       # Config module
+│   │       └── manager.rs   # Config file handling
+│   └── utils/
+│       ├── mod.rs           # Utility exports
+│       ├── dates.rs         # Date parsing helpers
+│       └── result.rs        # Result extensions
+├── tests/
+│   ├── integration/         # Integration tests
+│   │   ├── cli_tests.rs     # End-to-end CLI tests
+│   │   ├── db_tests.rs      # Database integration
+│   │   └── helpers/         # Test utilities
+│   └── fixtures/            # Test data files
+├── benches/
+│   └── performance.rs       # Criterion benchmarks
+├── migrations/              # SQL migration files
+│   ├── 001_initial.sql
+│   └── 002_add_fts.sql
+└── docs/
+    ├── architecture.md      # This document
+    ├── prd.md              # Product requirements
+    └── README.md           # User documentation
+```
+
+## Infrastructure and Deployment
+
+### Infrastructure as Code
+
+- **Tool:** Not applicable (local application)
+- **Location:** N/A
+- **Approach:** Single binary deployment
+
+### Deployment Strategy
+
+- **Strategy:** Direct binary distribution
+- **CI/CD Platform:** GitHub Actions
+- **Pipeline Configuration:** `.github/workflows/release.yml`
+
+### Environments
+
+- **Development:** Local developer machine with debug builds
+- **Testing:** CI environment with all platforms (Linux, macOS, Windows)
+- **Production:** User's local machine with release binary
+
+### Environment Promotion Flow
+
+```text
+Development (local) -> CI Testing -> GitHub Release -> User Installation
+                         ↓
+                    Failed tests
+                         ↓
+                    Fix & retry
+```
+
+### Rollback Strategy
+
+- **Primary Method:** Previous version binary installation
+- **Trigger Conditions:** User-reported critical bugs, data corruption
+- **Recovery Time Objective:** < 5 minutes (download previous release)
+
+## Error Handling Strategy
+
+### General Approach
+
+- **Error Model:** Result<T, Error> for all fallible operations
+- **Exception Hierarchy:** anyhow::Error for applications, custom types for libraries
+- **Error Propagation:** ? operator with context via .context()
+
+### Logging Standards
+
+- **Library:** env_logger 0.11.3
+- **Format:** `[TIMESTAMP] [LEVEL] [MODULE] Message`
+- **Levels:** ERROR, WARN, INFO, DEBUG, TRACE
+- **Required Context:**
+  - Correlation ID: Not needed (single-user CLI)
+  - Service Context: Module path automatically included
+  - User Context: Never log user data or task content
+
+### Error Handling Patterns
+
+#### External API Errors
+
+- **Retry Policy:** No external APIs
+- **Circuit Breaker:** Not applicable
+- **Timeout Configuration:** Not applicable
+- **Error Translation:** Not applicable
+
+#### Business Logic Errors
+
+- **Custom Exceptions:**
+  - `TaskNotFound(id)`
+  - `InvalidTaskDescription(reason)`
+  - `DuplicateTag(name)`
+  - `ConfigError(path, reason)`
+- **User-Facing Errors:** Clear, actionable messages via Display trait
+- **Error Codes:** Not used - descriptive messages preferred
+
+#### Data Consistency
+
+- **Transaction Strategy:** Explicit transactions for multi-table operations
+- **Compensation Logic:** Not needed with ACID SQLite
+- **Idempotency:** Complete/uncomplete operations are naturally idempotent
+
+## Coding Standards
+
+These standards are MANDATORY for AI agents and define project-specific conventions.
+
+### Core Standards
+
+- **Languages & Runtimes:** Rust 1.78.0 (edition 2021)
+- **Style & Linting:** rustfmt with default config, clippy with pedantic lints
+- **Test Organization:** Unit tests in `#[cfg(test)]` modules, integration tests in tests/
+
+### Naming Conventions
+
+| Element   | Convention      | Example               |
+| --------- | --------------- | --------------------- |
+| Structs   | PascalCase      | `TaskFilter`          |
+| Functions | snake_case      | `parse_due_date`      |
+| Constants | SCREAMING_SNAKE | `MAX_DESCRIPTION_LEN` |
+| Modules   | snake_case      | `task_repo`           |
+
+### Critical Rules
+
+- **No unwrap() in production code:** Use expect() with clear message or proper error handling
+- **All public functions must have doc comments:** Include examples for complex APIs
+- **SQL queries must use parameterized statements:** Never concatenate user input
+- **Benchmark new features:** Add criterion benchmarks for any performance-critical code
+- **Check Task description length:** Enforce 1000 character limit at CLI parsing layer
+
+## Test Strategy and Standards
+
+### Testing Philosophy
+
+- **Approach:** Test-after development with comprehensive coverage
+- **Coverage Goals:** 80% overall, 90% for business logic
+- **Test Pyramid:** 70% unit, 25% integration, 5% e2e
+
+### Test Types and Organization
+
+#### Unit Tests
+
+- **Framework:** Rust built-in testing
+- **File Convention:** Tests in same file as code under `#[cfg(test)]` module
+- **Location:** Bottom of each source file
+- **Mocking Library:** Manual test doubles (traits make this easy)
+- **Coverage Requirement:** 90% for domain and app layers
+
+**AI Agent Requirements:**
+
+- Generate tests for all public methods
+- Cover edge cases and error conditions
+- Follow AAA pattern (Arrange, Act, Assert)
+- Mock all external dependencies
+
+#### Integration Tests
+
+- **Scope:** Database operations, CLI parsing, file I/O
+- **Location:** `tests/integration/`
+- **Test Infrastructure:**
+  - **Database:** In-memory SQLite for speed
+  - **File System:** tempfile crate for isolated testing
+  - **CLI:** assert_cmd for command execution tests
+
+#### End-to-End Tests
+
+- **Framework:** assert_cmd 2.0.14
+- **Scope:** Full command execution with real database
+- **Environment:** Isolated temp directory per test
+- **Test Data:** Fixtures in tests/fixtures/
+
+### Test Data Management
+
+- **Strategy:** Builder pattern for test objects
+- **Fixtures:** `tests/fixtures/` for import/export tests
+- **Factories:** TaskBuilder, TagBuilder in test modules
+- **Cleanup:** Automatic via tempfile cleanup
+
+### Continuous Testing
+
+- **CI Integration:** Run on every push (test, clippy, fmt)
+- **Performance Tests:** Criterion benchmarks with 5% regression threshold
+- **Security Tests:** cargo audit in CI pipeline
+
+## Security
+
+### Input Validation
+
+- **Validation Library:** Built-in Rust type system + manual checks
+- **Validation Location:** CLI parsing layer before any processing
+- **Required Rules:**
+  - All external inputs MUST be validated
+  - Validation at API boundary before processing
+  - Whitelist approach preferred over blacklist
+
+### Authentication & Authorization
+
+- **Auth Method:** Not applicable (local single-user application)
+- **Session Management:** Not applicable
+- **Required Patterns:**
+  - File permissions rely on OS user permissions
+  - XDG directory compliance for proper isolation
+
+### Secrets Management
+
+- **Development:** No secrets required
+- **Production:** No secrets required
+- **Code Requirements:**
+  - NEVER hardcode secrets
+  - Access via configuration service only
+  - No secrets in logs or error messages
+
+### API Security
+
+Not applicable - no network APIs exposed
+
+### Data Protection
+
+- **Encryption at Rest:** Relies on OS disk encryption
+- **Encryption in Transit:** Not applicable (local only)
+- **PII Handling:** Task descriptions may contain PII - never log
+- **Logging Restrictions:** Never log task content, only IDs and metadata
+
+### Dependency Security
+
+- **Scanning Tool:** cargo audit
+- **Update Policy:** Monthly dependency updates
+- **Approval Process:** Review changelog for breaking changes
+
+### Security Testing
+
+- **SAST Tool:** cargo clippy with security lints
+- **DAST Tool:** Not applicable
+- **Penetration Testing:** Not required for local CLI
+
+## Checklist Results Report
+
+To be completed after architecture review.
+
+## Next Steps
+
+### Developer Handoff
+
+Begin implementation with the following:
+
+- Reference this architecture document and coding standards throughout development
+- Start with Epic 1, Story 1.1: Project Setup and Infrastructure
+- Key technical decisions to follow:
+  - Use Rust 1.78.0 with 2021 edition
+  - Implement clean architecture layers as specified
+  - All commands must complete in < 100ms
+  - Use synchronous code (no async/await)
+  - Follow the defined error handling patterns

zoo/docs/brief.md

@@ -0,0 +1,253 @@
+# Project Brief: Terminal Todo App
+
+## Project Overview
+
+**Project Name:** TermTodo  
+**Version:** 1.0  
+**Date:** 2025-07-07  
+**Status:** Planning Phase
+
+### Executive Summary
+
+TermTodo is a lightweight, fast, and efficient terminal-based todo application designed for developers and power users who live in the command line. The application prioritizes speed, simplicity, and seamless integration with existing terminal workflows while providing robust task management capabilities.
+
+### Vision Statement
+
+To create the most efficient terminal todo app that enhances developer productivity by eliminating context switching between GUI applications and the command line environment.
+
+## Problem Statement
+
+### Current Pain Points
+
+- **Context Switching:** Developers lose focus switching between terminal and GUI todo apps
+- **Bloated Solutions:** Existing todo apps are feature-heavy and slow to load
+- **Poor CLI Integration:** Most todo apps don't integrate well with terminal workflows
+- **Sync Overhead:** Cloud-based solutions add unnecessary complexity for local task management
+
+### Target Opportunity
+
+Create a fast, local-first todo application that feels native to terminal users while providing essential productivity features without bloat.
+
+## Objectives & Success Metrics
+
+### Primary Objectives
+
+1. **Speed:** App launches and executes commands in <100ms
+2. **Simplicity:** Core functionality accessible through intuitive commands
+3. **Integration:** Seamless workflow integration with git, editors, and shell scripts
+4. **Reliability:** Zero data loss with robust local storage
+
+### Success Metrics
+
+- **Performance:** Sub-100ms command execution time
+- **Adoption:** 1000+ GitHub stars within 6 months
+- **Usage:** Daily active usage by 100+ developers
+- **Satisfaction:** 90%+ positive feedback on usability
+
+## Target Audience
+
+### Primary Users
+
+**Developer Power Users**
+
+- Daily terminal users
+- Prefer keyboard-driven workflows
+- Value speed and efficiency over visual polish
+- Work with multiple projects simultaneously
+
+**System Administrators**
+
+- Manage multiple servers and tasks
+- Need quick task tracking between systems
+- Prefer scriptable/automatable solutions
+
+### User Personas
+
+**"Terminal Tom" - Senior Developer**
+
+- 8+ years experience
+- Uses vim/emacs, tmux, custom shell setups
+- Manages 3-5 projects simultaneously
+- Values minimalism and efficiency
+
+**"DevOps Dana" - Infrastructure Engineer**
+
+- Manages CI/CD pipelines
+- Juggles multiple environments
+- Needs quick task capture during incidents
+- Prefers automation-friendly tools
+
+## Scope & Features
+
+### Core Features (MVP)
+
+1. **Basic Task Management**
+
+   - Add, edit, delete tasks
+   - Mark tasks as complete
+   - List tasks with filtering
+
+2. **Organization**
+
+   - Project-based task grouping
+   - Priority levels (high, medium, low)
+   - Due date support
+
+3. **Search & Filter**
+   - Text search across tasks
+   - Filter by status, priority, project
+   - Tag-based organization
+
+### Advanced Features (v2.0+)
+
+1. **Workflow Integration**
+
+   - Git branch integration
+   - Editor plugin support
+   - Shell completion
+
+2. **Automation**
+
+   - Recurring tasks
+   - Template tasks
+   - Bulk operations
+
+3. **Reporting**
+   - Productivity metrics
+   - Time tracking
+   - Export capabilities
+
+### Out of Scope
+
+- Web interface
+- Mobile applications
+- Cloud synchronization
+- Collaborative features
+- Complex project management
+
+## Technical Requirements
+
+### Technology Stack
+
+- **Language:** Rust (performance, single binary distribution)
+- **CLI Framework:** Clap (argument parsing)
+- **Storage:** SQLite (local, reliable, queryable)
+- **Configuration:** TOML files
+
+### Performance Requirements
+
+- **Startup Time:** <50ms cold start
+- **Command Execution:** <100ms for all operations
+- **Memory Usage:** <10MB resident memory
+- **Storage:** Efficient SQLite schema design
+
+### Platform Support
+
+- **Primary:** Linux, macOS
+- **Secondary:** Windows (WSL)
+- **Distribution:** Single binary, package managers
+
+## Implementation Strategy
+
+### Development Phases
+
+**Phase 1: Core MVP (4 weeks)**
+
+- Basic CRUD operations
+- SQLite storage layer
+- Command-line interface
+- Unit test coverage
+
+**Phase 2: Organization (3 weeks)**
+
+- Project grouping
+- Priority and due dates
+- Search and filtering
+- Integration testing
+
+**Phase 3: Polish (2 weeks)**
+
+- Shell completion
+- Configuration management
+- Documentation
+- Performance optimization
+
+### Risk Mitigation
+
+- **Technical Risk:** Rust learning curve → Start with simple CLI, iterate
+- **Market Risk:** Existing solutions → Focus on speed and terminal integration
+- **Adoption Risk:** Discoverability → Leverage dev community, GitHub
+
+## Timeline & Milestones
+
+### Key Milestones
+
+| Phase | Deliverable      | Timeline | Success Criteria               |
+| ----- | ---------------- | -------- | ------------------------------ |
+| 1     | MVP Release      | Week 4   | Core features functional       |
+| 2     | Beta Release     | Week 7   | Organization features complete |
+| 3     | v1.0 Release     | Week 9   | Production ready               |
+| 4     | Community Growth | Week 20  | 1000+ GitHub stars             |
+
+### Critical Path
+
+1. SQLite schema design
+2. Core command structure
+3. Performance optimization
+4. Documentation and examples
+
+## Team & Stakeholders
+
+### Core Team
+
+**Solo Developer** (Primary)
+
+- Full-stack development
+- Design and architecture
+- Testing and documentation
+
+### Advisory Stakeholders
+
+- **Developer Community:** Feedback and feature requests
+- **Beta Users:** Early testing and validation
+- **Open Source Community:** Contributions and maintenance
+
+## Budget & Resources
+
+### Development Resources
+
+- **Time Investment:** 20 hours/week for 9 weeks
+- **Infrastructure:** GitHub (free), domain name ($15/year)
+- **Tools:** Development environment, testing tools
+
+### Total Investment
+
+- **Development Time:** ~180 hours
+- **Direct Costs:** <$50
+- **Opportunity Cost:** Personal projects, learning time
+
+## Success Factors
+
+### Critical Success Factors
+
+1. **Performance First:** Every feature decision evaluated for speed impact
+2. **Developer Experience:** Intuitive commands that feel natural
+3. **Terminal Native:** Feels like a built-in shell command
+4. **Community Building:** Engage early adopters for feedback
+
+### Potential Risks
+
+- **Over-engineering:** Feature creep beyond core use cases
+- **Performance Degradation:** Complex features slowing core operations
+- **Adoption Challenges:** Difficulty reaching target developers
+
+## Next Steps
+
+1. **Technical Spike:** Rust CLI framework evaluation (Week 1)
+2. **Database Design:** SQLite schema and migration strategy
+3. **Core Architecture:** Command structure and data flow
+4. **MVP Development:** Begin core feature implementation
+
+---
+
+_This project brief will be reviewed and updated at each milestone to ensure alignment with objectives and market feedback._

zoo/docs/prd.md

@@ -0,0 +1,500 @@
+# TermTodo Product Requirements Document (PRD)
+
+## Goals and Background Context
+
+### Goals
+
+- Deliver a terminal todo app that executes all commands in under 100ms
+- Eliminate context switching for developers who live in the command line
+- Provide intuitive task management through simple, memorable commands
+- Enable seamless integration with existing terminal workflows (git, editors, scripts)
+- Achieve zero data loss with robust local SQLite storage
+- Build a tool that feels native to terminal power users
+- Create a maintainable single-binary distribution for easy installation
+
+### Background Context
+
+TermTodo addresses a critical gap in developer productivity tools. While numerous todo applications exist, they force developers to break their flow by switching between terminal and GUI applications. Current solutions are either bloated web applications with unnecessary features or simplistic command-line tools that lack essential task management capabilities. TermTodo strikes the balance by providing a fast, local-first solution that integrates naturally into terminal-based workflows.
+
+The application targets developers and system administrators who value speed and efficiency over visual polish. By focusing on sub-100ms execution times and keyboard-driven interactions, TermTodo eliminates the friction that prevents consistent task tracking in fast-paced development environments. The choice of Rust ensures performance goals are met while providing a single binary that's easy to distribute and install across Linux, macOS, and Windows (WSL) platforms.
+
+### Change Log
+
+| Date       | Version | Description                                 | Author   |
+| ---------- | ------- | ------------------------------------------- | -------- |
+| 2025-07-07 | 1.0     | Initial PRD creation based on Project Brief | PM Agent |
+
+## Requirements
+
+### Functional
+
+- FR1: The application must support adding tasks with a single command (e.g., `todo add "Complete code review"`)
+- FR2: Users must be able to mark tasks as complete/incomplete with toggle functionality
+- FR3: The application must support editing existing task descriptions
+- FR4: Users must be able to delete individual tasks or bulk delete completed tasks
+- FR5: The application must list tasks with configurable filtering by status, priority, project, and tags
+- FR6: Task organization must support project-based grouping with easy project switching
+- FR7: Each task must support priority levels (high, medium, low) with visual indicators in listings
+- FR8: Tasks must support optional due dates with human-readable input (e.g., "tomorrow", "next friday")
+- FR9: The application must provide full-text search across all task fields
+- FR10: Users must be able to add and remove tags from tasks for flexible categorization
+- FR11: The application must support task templates for recurring task patterns
+- FR12: Shell completion must be available for all commands and common parameters
+- FR13: The application must provide export functionality to common formats (JSON, CSV, Markdown)
+- FR14: Configuration must be manageable through TOML files with sensible defaults
+
+### Non Functional
+
+- NFR1: All commands must execute in under 100ms from invocation to completion
+- NFR2: Cold start time must be under 50ms on standard developer hardware
+- NFR3: Memory usage must not exceed 10MB during normal operation
+- NFR4: The application must be distributed as a single static binary with no runtime dependencies
+- NFR5: Data storage must use SQLite with ACID compliance for zero data loss
+- NFR6: The CLI must follow Unix conventions (stdin/stdout, exit codes, composability)
+- NFR7: All user-facing messages must be clear, concise, and actionable
+- NFR8: The application must support Linux and macOS as primary platforms, Windows via WSL
+- NFR9: Installation must be possible through major package managers (brew, apt, cargo)
+- NFR10: The codebase must maintain 80%+ test coverage for reliability
+- NFR11: All commands must be documented with man pages and --help output
+- NFR12: The application must handle 10,000+ tasks without performance degradation
+- NFR13: Error messages must provide clear guidance for resolution
+- NFR14: The application must support UTF-8 for international task descriptions
+
+## Technical Assumptions
+
+### Repository Structure: Monorepo
+
+Single repository containing all TermTodo code, tests, documentation, and build configurations. This simplifies development, testing, and distribution for a focused CLI tool.
+
+### Service Architecture
+
+**Monolith** - TermTodo will be built as a single, self-contained binary with all functionality compiled in. This architecture aligns with our performance goals (sub-50ms startup) and distribution requirements (single binary). The SQLite database will be embedded, and all operations will run in-process without network dependencies.
+
+### Testing Requirements
+
+**Full Testing Pyramid** - Given the critical nature of data integrity and performance requirements:
+
+- **Unit Tests**: Core business logic, data models, command parsing
+- **Integration Tests**: SQLite operations, file I/O, command execution flows
+- **E2E Tests**: Full command-line scenarios using the actual binary
+- **Performance Tests**: Automated benchmarks ensuring sub-100ms execution
+- **Manual Testing Helpers**: Debug commands and verbose modes for troubleshooting
+
+### Additional Technical Assumptions and Requests
+
+- **Language**: Rust (as specified in Project Brief) for performance and memory safety
+- **CLI Framework**: Clap v4+ for robust argument parsing and automatic help generation
+- **Database**: SQLite with schema migrations support (using sqlx or diesel)
+- **Error Handling**: Comprehensive error types with user-friendly messages using anyhow/thiserror
+- **Configuration**: TOML for human-readable config files, with XDG base directory compliance
+- **Build System**: Cargo with cross-compilation support for Linux/macOS/Windows targets
+- **Serialization**: Serde for JSON/CSV export functionality
+- **Date Parsing**: Chrono with chrono-english for human-readable date input
+- **Terminal Output**: Colored output using termcolor, respecting NO_COLOR environment variable
+- **Shell Completion**: Built-in completion generation for bash, zsh, fish, and PowerShell
+- **Packaging**: Release binaries via GitHub releases, plus cargo, brew tap, and AUR support
+- **Documentation**: Embedded man pages generated from clap, README with examples
+- **Logging**: Optional debug logging to file (not stdout) for troubleshooting
+- **Benchmarking**: Criterion.rs for performance regression testing in CI
+
+## Epic List
+
+- **Epic 1: Foundation & Core Task Management**: Establish project infrastructure, CI/CD, and implement basic CRUD operations for tasks with SQLite storage
+- **Epic 2: Organization & Filtering**: Implement project-based task grouping, priority levels, tags, and comprehensive filtering capabilities
+- **Epic 3: Advanced Features & Integration**: Add due dates, search functionality, shell completion, templates, and import/export capabilities
+
+## Epic 1: Foundation & Core Task Management
+
+Establish the foundational infrastructure for TermTodo including project setup, continuous integration, and core task CRUD operations. This epic delivers a functional but minimal todo application that can add, list, complete, and delete tasks with persistent SQLite storage, while meeting our aggressive performance requirements.
+
+### Story 1.1: Project Setup and Infrastructure
+
+As a developer,
+I want a properly structured Rust project with CI/CD pipelines,
+so that I can ensure code quality and automated releases from the start.
+
+#### Acceptance Criteria
+
+1: Repository initialized with Rust project structure and .gitignore
+2: Cargo.toml configured with project metadata and initial dependencies (clap, sqlx, tokio)
+3: GitHub Actions workflow for CI (test, lint, build) on all platforms
+4: GitHub Actions workflow for CD (release binaries) on tag push
+5: Basic README with project description and development setup instructions
+6: Pre-commit hooks configured for formatting (rustfmt) and linting (clippy)
+7: MIT License file added
+8: Makefile with common development commands (test, build, release)
+
+### Story 1.2: CLI Framework and Command Structure
+
+As a user,
+I want a well-structured command-line interface with help documentation,
+so that I can easily discover and use all available commands.
+
+#### Acceptance Criteria
+
+1: Main CLI entry point implemented with clap v4
+2: Subcommand structure established (add, list, complete, delete, etc.)
+3: Global flags implemented (--version, --help, --config)
+4: Auto-generated help text for all commands and subcommands
+5: Version information properly displayed from Cargo.toml
+6: Exit codes follow Unix conventions (0 for success, non-zero for errors)
+7: Basic error handling structure with user-friendly messages
+
+### Story 1.3: SQLite Database Layer
+
+As a developer,
+I want a robust database layer with schema management,
+so that I can reliably store and retrieve tasks with ACID compliance.
+
+#### Acceptance Criteria
+
+1: SQLite connection pool initialized with proper settings
+2: Initial schema migration creating tasks table (id, description, status, created_at, updated_at)
+3: Migration system implemented for future schema changes
+4: Database file created in XDG-compliant data directory
+5: Connection timeout and busy handling configured for concurrent access
+6: Basic database error handling with rollback support
+7: Database layer abstraction with trait for testability
+
+### Story 1.4: Add Task Functionality
+
+As a user,
+I want to quickly add new tasks from the command line,
+so that I can capture todo items without breaking my workflow.
+
+#### Acceptance Criteria
+
+1: "todo add <description>" command creates new task in database
+2: Task description supports UTF-8 and quotes/special characters
+3: Newly created task ID displayed on successful addition
+4: Task creation timestamp automatically recorded
+5: Performance requirement met: command completes in <100ms
+6: Error shown if description is empty or too long (>1000 chars)
+7: Success message confirms task was added
+
+### Story 1.5: List Tasks Functionality
+
+As a user,
+I want to see my current tasks in a clear format,
+so that I can review what needs to be done.
+
+#### Acceptance Criteria
+
+1: "todo list" command displays all incomplete tasks
+2: Output shows task ID, description, and age (e.g., "2 days ago")
+3: Tasks sorted by creation date (oldest first) by default
+4: Completed tasks hidden by default
+5: "--all" flag shows both complete and incomplete tasks
+6: Empty state message when no tasks exist
+7: Output formatted for terminal width with proper truncation
+
+### Story 1.6: Complete Task Functionality
+
+As a user,
+I want to mark tasks as complete,
+so that I can track my progress.
+
+#### Acceptance Criteria
+
+1: "todo complete <id>" marks specified task as complete
+2: Multiple IDs can be provided to complete multiple tasks
+3: Completion timestamp recorded in database
+4: Success message confirms which task(s) were completed
+5: Error shown for non-existent task IDs
+6: Already-completed tasks can be marked complete again (idempotent)
+7: Performance requirement met: command completes in <100ms
+
+### Story 1.7: Delete Task Functionality
+
+As a user,
+I want to delete tasks I no longer need,
+so that I can keep my task list clean and relevant.
+
+#### Acceptance Criteria
+
+1: "todo delete <id>" removes specified task from database
+2: Multiple IDs can be provided to delete multiple tasks
+3: Confirmation required by default (bypass with --force flag)
+4: Success message confirms which task(s) were deleted
+5: Error shown for non-existent task IDs
+6: "todo delete --completed" removes all completed tasks
+7: Deleted tasks cannot be recovered (documented in help)
+
+## Epic 2: Organization & Filtering
+
+Implement comprehensive task organization features including projects, priorities, tags, and filtering capabilities. This epic transforms the basic todo app into a powerful task management system that can handle complex workflows while maintaining simplicity and performance.
+
+### Story 2.1: Project-Based Task Grouping
+
+As a developer working on multiple projects,
+I want to organize tasks by project,
+so that I can focus on relevant tasks for my current context.
+
+#### Acceptance Criteria
+
+1: Tasks table schema updated to include optional project field
+2: "todo add -p <project> <description>" assigns task to project
+3: "todo list -p <project>" filters tasks by project
+4: "todo projects" lists all unique projects with task counts
+5: Default project configurable in TOML config file
+6: Project names validated (alphanumeric + dash/underscore)
+7: Tasks without project show under "default" in listings
+
+### Story 2.2: Priority Levels
+
+As a user,
+I want to assign priority levels to tasks,
+so that I can focus on what's most important.
+
+#### Acceptance Criteria
+
+1: Tasks table schema updated to include priority field (high/medium/low)
+2: "todo add -P high <description>" sets task priority
+3: Default priority is "medium" if not specified
+4: Priority shown in task listings with visual indicators (!, !!, !!!)
+5: "todo list --priority high" filters by priority level
+6: Tasks sorted by priority within date sorting
+7: Priority can be updated with "todo priority <id> <level>"
+
+### Story 2.3: Tag System
+
+As a user,
+I want to add tags to tasks for flexible categorization,
+so that I can create custom organizational schemes.
+
+#### Acceptance Criteria
+
+1: Tags table created with many-to-many relationship to tasks
+2: "todo add <description> +tag1 +tag2" adds tags during creation
+3: Tags parsed from description (+ prefix) and stored separately
+4: "todo tag <id> +tag" adds tags to existing tasks
+5: "todo tag <id> -tag" removes tags from tasks
+6: "todo list +tag" filters tasks by tag
+7: "todo tags" lists all tags with usage counts
+
+### Story 2.4: Advanced Filtering
+
+As a power user,
+I want to combine multiple filters when listing tasks,
+so that I can create precise views of my work.
+
+#### Acceptance Criteria
+
+1: Multiple filters can be combined (project AND priority AND tags)
+2: "todo list -p work -P high +urgent" shows filtered results
+3: Date range filtering with --since and --until flags
+4: Status filtering with --status (incomplete/complete/all)
+5: Inverse filters supported with --not-project, --not-tag
+6: Filter combinations can be saved as named views in config
+7: Performance maintained under 100ms even with complex filters
+
+### Story 2.5: Configuration Management
+
+As a user,
+I want to customize default behaviors and preferences,
+so that the tool works the way I prefer.
+
+#### Acceptance Criteria
+
+1: TOML config file created at XDG config location on first run
+2: Config supports: default project, default priority, date format
+3: Config supports: color preferences, list sort order
+4: "todo config" opens config file in $EDITOR
+5: "todo config --list" shows current configuration
+6: Invalid config shows clear error without crashing
+7: Config changes take effect immediately (no restart needed)
+
+## Epic 3: Advanced Features & Integration
+
+Add power-user features including due dates, full-text search, shell completion, templates, and data portability. This epic completes the feature set needed for TermTodo to become an indispensable part of a developer's workflow.
+
+### Story 3.1: Due Date Support
+
+As a user,
+I want to set due dates on tasks,
+so that I can manage time-sensitive work effectively.
+
+#### Acceptance Criteria
+
+1: Tasks table schema updated to include optional due_date field
+2: "todo add <description> due:tomorrow" sets due date with natural language
+3: Supported formats: "due:2024-12-31", "due:friday", "due:3d" (3 days)
+4: Due dates shown in task listings with urgency indicators
+5: "todo list --due" shows only tasks with due dates
+6: "todo list --overdue" shows past-due tasks highlighted
+7: Due date can be updated with "todo due <id> <date>"
+
+### Story 3.2: Full-Text Search
+
+As a user with many tasks,
+I want to search across all task fields,
+so that I can quickly find specific items.
+
+#### Acceptance Criteria
+
+1: "todo search <query>" searches description, project, and tags
+2: Search uses SQLite FTS5 for performance and features
+3: Results show matched tasks with search terms highlighted
+4: Search supports quoted phrases for exact matching
+5: Boolean operators AND/OR supported in queries
+6: Search results include context around matches
+7: Performance requirement met: search completes in <100ms
+
+### Story 3.3: Shell Completion
+
+As a command-line power user,
+I want shell completion for all commands and parameters,
+so that I can work more efficiently.
+
+#### Acceptance Criteria
+
+1: Completion scripts generated for bash, zsh, fish, PowerShell
+2: Command completion includes all subcommands and flags
+3: Project names completed for -p flag from existing projects
+4: Tag names completed after + prefix from existing tags
+5: Task IDs completed for complete/delete/update commands
+6: Installation instructions included in README
+7: Completion scripts included in distribution packages
+
+### Story 3.4: Task Templates
+
+As a user with recurring task patterns,
+I want to create templates for common tasks,
+so that I can quickly add similar tasks.
+
+#### Acceptance Criteria
+
+1: Templates stored in TOML config file with name and pattern
+2: "todo template create <name>" interactively creates template
+3: "todo template list" shows available templates
+4: "todo add --template <name>" creates task from template
+5: Templates support placeholders like {date}, {project}
+6: Templates can include default project, priority, tags
+7: "todo template delete <name>" removes unused templates
+
+### Story 3.5: Import/Export Functionality
+
+As a user,
+I want to export and import my tasks in common formats,
+so that I can backup data or integrate with other tools.
+
+#### Acceptance Criteria
+
+1: "todo export --format json" exports all tasks to JSON
+2: "todo export --format csv" exports tasks to CSV format
+3: "todo export --format markdown" creates Markdown task list
+4: Export supports filtering (only export filtered tasks)
+5: "todo import <file>" imports tasks from JSON format
+6: Import validates data and reports errors without corruption
+7: Export includes all fields: description, project, priority, tags, dates
+
+### Story 3.6: Performance Optimization
+
+As a developer using the tool hundreds of times per day,
+I want consistent sub-100ms performance,
+so that the tool never slows down my workflow.
+
+#### Acceptance Criteria
+
+1: Benchmark suite implemented using criterion.rs
+2: All commands benchmarked in CI to prevent regression
+3: Database indexes optimized for common query patterns
+4: Prepared statements cached for repeated queries
+5: Binary size optimized with release flags and LTO
+6: Cold start optimized to meet <50ms requirement
+7: Performance guide documented with optimization tips
+
+## Checklist Results Report
+
+### Executive Summary
+
+- **Overall PRD Completeness**: 95%
+- **MVP Scope Appropriateness**: Just Right
+- **Readiness for Architecture Phase**: Ready
+- **Most Critical Gaps**: None - PRD is comprehensive and well-structured
+
+### Category Analysis Table
+
+| Category                         | Status | Critical Issues          |
+| -------------------------------- | ------ | ------------------------ |
+| 1. Problem Definition & Context  | PASS   | None                     |
+| 2. MVP Scope Definition          | PASS   | None                     |
+| 3. User Experience Requirements  | PASS   | CLI-focused, appropriate |
+| 4. Functional Requirements       | PASS   | None                     |
+| 5. Non-Functional Requirements   | PASS   | None                     |
+| 6. Epic & Story Structure        | PASS   | None                     |
+| 7. Technical Guidance            | PASS   | None                     |
+| 8. Cross-Functional Requirements | PASS   | None                     |
+| 9. Clarity & Communication       | PASS   | None                     |
+
+### Top Issues by Priority
+
+**BLOCKERS**: None identified
+
+**HIGH**: None identified
+
+**MEDIUM**:
+
+- Consider adding explicit data migration strategy for future schema changes
+- May want to specify exact Rust version requirements
+
+**LOW**:
+
+- Could add more specific examples of shell script integration possibilities
+- Might benefit from explicit CI/CD tool preferences (GitHub Actions assumed)
+
+### MVP Scope Assessment
+
+**Scope Analysis**:
+
+- The MVP scope is appropriately minimal while delivering core value
+- Epic 1 provides a working todo app with essential CRUD operations
+- Epic 2 and 3 can be delivered incrementally based on user feedback
+- No features appear superfluous for the target audience
+
+**Timeline Realism**:
+
+- 9-week timeline is aggressive but achievable for a solo developer
+- Story sizing is appropriate for AI-assisted development
+- Performance requirements may require iteration but are well-defined
+
+### Technical Readiness
+
+**Clarity of Technical Constraints**:
+
+- Technology stack clearly defined (Rust, SQLite, Clap)
+- Performance requirements explicit and measurable
+- Distribution strategy well-planned
+
+**Identified Technical Risks**:
+
+- SQLite cold-start performance for <50ms requirement
+- Cross-platform shell completion complexity
+- Natural language date parsing edge cases
+
+**Areas Needing Architect Investigation**:
+
+- Optimal SQLite configuration for performance
+- Schema design for efficient filtering and search
+- Binary size optimization strategies
+
+### Recommendations
+
+1. **Proceed to Architecture Phase**: The PRD is comprehensive and ready
+2. **Early Performance Validation**: Create a spike to validate SQLite startup times
+3. **Schema Evolution Strategy**: Document migration approach early in development
+4. **User Testing Plan**: Consider early beta program for developer feedback
+
+### Final Decision
+
+**READY FOR ARCHITECT**: The PRD and epics are comprehensive, properly structured, and ready for architectural design. The document provides clear requirements, appropriate technical constraints, and a well-sequenced implementation plan suitable for the target developer audience.
+
+## Next Steps
+
+### Design Architect Prompt
+
+Review the TermTodo PRD and create a comprehensive UI/UX design specification for this CLI application, focusing on terminal-based interaction patterns, command syntax design, output formatting, and the overall developer experience.
+
+### Architect Prompt
+
+Analyze the TermTodo PRD and create a detailed technical architecture document including: database schema design, Rust module structure, performance optimization strategies, error handling patterns, and a concrete implementation plan for achieving sub-100ms execution times.

zoo/docs/stories/1.1.story.md

@@ -0,0 +1,278 @@
+# Story 1.1: Project Setup and Infrastructure
+
+## Status
+
+Draft
+
+## Story
+
+**As a** developer,
+**I want** a properly structured Rust project with CI/CD pipelines,
+**so that** I can ensure code quality and automated releases from the start.
+
+## Acceptance Criteria
+
+1. Repository initialized with Rust project structure and .gitignore
+2. Cargo.toml configured with project metadata and all required dependencies from tech stack
+3. GitHub Actions workflow for CI (test, lint, build) on all platforms
+4. GitHub Actions workflow for CD (release binaries) on tag push
+5. Basic README with project description and development setup instructions
+6. Pre-commit hooks configured for formatting (rustfmt) and linting (clippy)
+7. MIT License file added
+8. Makefile with common development commands (test, build, release)
+
+## Tasks / Subtasks
+
+- [ ] Task 1: Initialize Rust project structure (AC: 1)
+  - [ ] Create Cargo.toml with project metadata
+  - [ ] Set up proper .gitignore for Rust projects
+  - [ ] Initialize git repository if needed
+  - [ ] Create basic src/main.rs entry point
+- [ ] Task 2: Configure dependencies in Cargo.toml (AC: 2)
+  - [ ] Add clap v4.5.4 for CLI framework
+  - [ ] Add sqlx v0.7.4 for database operations
+  - [ ] Add anyhow v1.0.82 for error handling
+  - [ ] Add thiserror v1.0.58 for custom error types
+  - [ ] Add toml v0.8.12 for config file parsing
+  - [ ] Add termcolor v1.4.1 for colored output
+  - [ ] Add criterion v0.5.1 for benchmarking
+  - [ ] Add env_logger v0.11.3 for debug logging
+  - [ ] Add chrono v0.4.38 and chrono-english v0.1.7 for date parsing
+  - [ ] Add serde v1.0.197 for serialization
+- [ ] Task 3: Set up GitHub Actions CI workflow (AC: 3)
+  - [ ] Create .github/workflows/ci.yml
+  - [ ] Configure test, lint, and build jobs
+  - [ ] Set up matrix builds for Linux and macOS
+  - [ ] Add rustfmt and clippy checks
+  - [ ] Add security audit using cargo audit
+  - [ ] Add performance benchmarks with 5% regression threshold
+- [ ] Task 4: Set up GitHub Actions CD workflow (AC: 4)
+  - [ ] Create .github/workflows/release.yml
+  - [ ] Configure binary builds for release
+  - [ ] Set up artifact uploads for releases
+  - [ ] Configure triggering on tag push
+- [ ] Task 5: Create project documentation (AC: 5)
+  - [ ] Write README.md with project description
+  - [ ] Add development setup instructions
+  - [ ] Document build and test commands
+  - [ ] Include installation instructions
+- [ ] Task 6: Configure pre-commit hooks (AC: 6)
+  - [ ] Set up rustfmt pre-commit hook
+  - [ ] Set up clippy pre-commit hook
+  - [ ] Document hook setup in README
+- [ ] Task 7: Add MIT License (AC: 7)
+  - [ ] Create LICENSE file with MIT license text
+  - [ ] Add license field to Cargo.toml
+- [ ] Task 8: Create Makefile for development (AC: 8)
+  - [ ] Add test target
+  - [ ] Add build target (debug and release)
+  - [ ] Add lint target (rustfmt + clippy)
+  - [ ] Add clean target
+
+## Dev Notes
+
+### Previous Story Insights
+
+No previous story exists - this is the first story in the project.
+
+### Technical Architecture Context
+
+**Project Structure Requirements** [Source: architecture.md#source-tree]:
+
+- Follow the defined monorepo structure with clear separation of concerns
+- Implement clean architecture layers: CLI, Application, Domain, Infrastructure
+- Use the exact directory structure specified in the architecture document
+
+**Technology Stack Requirements** [Source: architecture.md#tech-stack]:
+
+- **Language**: Rust 1.78.0 (2021 edition)
+- **CLI Framework**: clap v4.5.4 for command-line parsing
+- **Database**: sqlx v0.7.4 for SQLite operations
+- **Error Handling**: anyhow v1.0.82 for application errors, thiserror v1.0.58 for custom types
+- **Configuration**: toml v0.8.12 for config file parsing
+- **Terminal Output**: termcolor v1.4.1 for colored output
+- **Testing**: criterion v0.5.1 for benchmarking
+- **Logging**: env_logger v0.11.3 for debug logging
+- **Date Parsing**: chrono v0.4.38, chrono-english v0.1.7
+- **Serialization**: serde v1.0.197 for JSON/CSV export
+
+**Performance Requirements** [Source: architecture.md#high-level-architecture]:
+
+- Sub-100ms command execution requirement
+- Cold start application startup < 50ms
+- Memory usage must not exceed 10MB during normal operation
+- Single binary distribution with no runtime dependencies
+- Synchronous execution model (no async runtime overhead)
+- Static linking required for zero runtime dependencies
+
+**Build and CI Requirements** [Source: architecture.md#infrastructure-and-deployment]:
+
+- GitHub Actions for CI/CD pipeline
+- Matrix builds for Linux and macOS platforms
+- Automated binary releases on tag push
+- Integration with cargo, rustfmt, and clippy
+- Security audit using cargo audit in CI pipeline
+- Performance benchmarks with 5% regression threshold
+- LTO enabled for release builds
+- Binary size optimization for releases
+
+### File Locations
+
+Based on the architecture document, the complete project structure should be:
+
+```
+termtodo/
+├── Cargo.toml                 # Project manifest with dependencies
+├── Cargo.lock                # Locked dependency versions
+├── build.rs                   # Build script for embedding resources
+├── .github/
+│   └── workflows/
+│       ├── ci.yml            # Test, lint, build on all platforms
+│       └── release.yml       # Build and publish binaries on tag
+├── src/
+│   ├── main.rs              # Entry point, CLI setup
+│   ├── cli/
+│   │   ├── mod.rs           # CLI module exports
+│   │   ├── parser.rs        # Clap command definitions
+│   │   └── commands/        # Command handlers
+│   ├── app/
+│   │   ├── mod.rs           # Application layer exports
+│   │   ├── service.rs       # Main application service
+│   │   └── errors.rs        # Application error types
+│   ├── domain/
+│   │   ├── mod.rs           # Domain model exports
+│   │   ├── task.rs          # Task entity
+│   │   └── types.rs         # Enums (Status, Priority)
+│   ├── infra/
+│   │   ├── mod.rs           # Infrastructure exports
+│   │   ├── db/             # Database module
+│   │   ├── repos/          # Repository implementations
+│   │   └── config/         # Config file handling
+│   └── utils/
+│       ├── mod.rs           # Utility exports
+│       ├── dates.rs         # Date parsing helpers
+│       └── result.rs        # Result extensions
+├── tests/
+│   ├── integration/         # Integration tests
+│   └── fixtures/            # Test data files
+├── benches/
+│   └── performance.rs       # Criterion benchmarks
+├── migrations/              # SQL migration files
+├── LICENSE                  # MIT license file
+├── Makefile                 # Development commands
+└── README.md               # Project documentation
+```
+
+### Testing Requirements
+
+**Testing Standards** [Source: architecture.md#test-strategy-and-standards]:
+
+- Use Rust built-in testing framework
+- Target 80% overall coverage, 90% for business logic
+- Unit tests in `#[cfg(test)]` modules within source files
+- Integration tests in `tests/integration/` directory
+- Performance tests using criterion benchmarks
+- Pre-commit hooks for formatting and linting validation
+
+### Technical Constraints
+
+**Coding Standards** [Source: architecture.md#coding-standards]:
+
+- Rust 1.78.0 with 2021 edition
+- rustfmt with default configuration
+- clippy with pedantic lints enabled
+- No unwrap() in production code
+- All public functions must have doc comments
+- Parameterized SQL statements only
+
+**Error Handling** [Source: architecture.md#error-handling-strategy]:
+
+- Result<T, Error> for all fallible operations
+- anyhow::Error for applications, custom types for libraries
+- Error propagation using ? operator with context
+
+### Database Configuration Requirements
+
+**SQLite PRAGMA Settings** [Source: architecture.md#database-requirements]:
+
+- foreign_keys=ON for referential integrity
+- journal_mode=WAL for performance
+- synchronous=NORMAL for balanced safety/performance
+- Connection pooling and prepared statement caching
+- Schema migration system with version tracking
+- Optimized indexes for common query patterns
+
+### Clean Architecture Layer Requirements
+
+**Layer Separation** [Source: architecture.md#clean-architecture]:
+
+- **CLI Layer**: Command parsing and output formatting only
+- **Application Layer**: Business logic orchestration
+- **Domain Layer**: Core entities and business rules
+- **Infrastructure Layer**: Database, config, external concerns
+- Repository pattern for data access abstraction
+- Command pattern for CLI subcommand handlers
+
+### Testing
+
+**Testing Standards** [Source: architecture.md#test-strategy-and-standards]:
+
+**Framework**: Rust built-in testing framework
+**Coverage Goals**:
+
+- 80% overall coverage minimum
+- 90% for business logic coverage minimum
+- Test pyramid: 70% unit, 25% integration, 5% e2e
+
+**Test Organization**:
+
+- Unit tests in `#[cfg(test)]` modules within source files
+- Integration tests in `tests/integration/` directory
+- End-to-end tests using assert_cmd for CLI testing
+- Performance tests using criterion benchmarks
+
+**Testing Infrastructure**:
+
+- Use tempfile crate for isolated file system testing
+- In-memory SQLite for database integration tests
+- Criterion benchmarks for performance regression testing
+- assert_cmd for CLI end-to-end testing
+
+**CI Requirements**:
+
+- Run tests on every push and pull request
+- Include rustfmt and clippy checks in CI pipeline
+- Performance benchmarks with 5% regression threshold
+- Security audit using cargo audit
+- Cross-platform testing (Linux and macOS)
+
+## Change Log
+
+| Date       | Version | Description                                                                                                          | Author                |
+| ---------- | ------- | -------------------------------------------------------------------------------------------------------------------- | --------------------- |
+| 2025-07-07 | 1.0     | Initial story creation                                                                                               | Bob (Scrum Master)    |
+| 2025-07-07 | 1.1     | Fixed validation issues: complete dependency list, template structure, performance requirements, source tree details | Sarah (Product Owner) |
+
+## Dev Agent Record
+
+_This section will be populated by the development agent during implementation_
+
+### Agent Model Used
+
+_To be filled by dev agent_
+
+### Debug Log References
+
+_To be filled by dev agent_
+
+### Completion Notes List
+
+_To be filled by dev agent_
+
+### File List
+
+_To be filled by dev agent_
+
+## QA Results
+
+_Results from QA Agent review will be populated here_