aiwf 0.3.7 → 0.3.12

package/claude-code/aiwf/en/.aiwf/CLAUDE.md

@@ -1,74 +0,0 @@
-# CLAUDE.md - AIWF Framework Structure Guide
-
-## Overview
-
-This is the root directory of the AIWF framework structure. It contains all project documentation, requirements, sprints, and organizational files.
-
-## Critical Files
-
-### Project Manifest
-
-**IMPORTANT**: The project manifest file MUST be named:
-
-```
-00_PROJECT_MANIFEST.md
-```
-
-**NOT**:
-
-- ❌ `MANIFEST.md`
-- ❌ `PROJECT_MANIFEST.md`
-- ❌ `project_manifest.md`
-
-The manifest is the central reference file that tracks:
-
-- Project name and status
-- Current milestone and sprint
-- Project metadata
-- Last updated timestamp
-
-## Directory Structure
-
-```
-.AIWF/
-├── 00_PROJECT_MANIFEST.md          # Central project reference (CORRECT NAME)
-├── 01_PROJECT_DOCS/                # General project documentation
-├── 02_REQUIREMENTS/                # Milestone-based requirements
-├── 03_SPRINTS/                     # Sprint execution folders
-├── 04_GENERAL_TASKS/               # Non-sprint tasks
-├── 05_ARCHITECTURAL_DECISIONS/     # ADR documentation
-├── 10_STATE_OF_PROJECT/            # Project review snapshots
-└── 99_TEMPLATES/                   # Document templates
-```
-
-## Naming Conventions Summary
-
-### Files
-
-- **Project Manifest**: `00_PROJECT_MANIFEST.md`
-- **Milestone Meta**: `M##_milestone_meta.md`
-- **Sprint Meta**: `S##_M##_sprint_meta.md`
-- **Task Files**: `TASK_##_*.md`
-- **ADR Files**: `ADR_###_*.md`
-
-### Folders
-
-- **Milestones**: `M##_Milestone_Name/`
-- **Sprints**: `S##_M##_Sprint_Name/`
-- **State Snapshots**: `YYYY-MM-DD_HH-MM_snapshot/`
-
-## Important Notes for Claude Code
-
-1. **Always create `00_PROJECT_MANIFEST.md`** when initializing a project
-2. **Use the templates** from `99_TEMPLATES/` for consistency
-3. **Follow the naming conventions exactly** - they enable proper sorting and navigation
-4. **Update the manifest** when creating milestones or sprints
-5. **Use underscores** for spaces in folder and file names
-
-## Common Initialization Mistakes
-
-- Creating `MANIFEST.md` instead of `00_PROJECT_MANIFEST.md`
-- Missing the leading zeros in numbered prefixes
-- Using hyphens instead of underscores
-- Creating files without using templates
-- Not updating the manifest after structural changes

package/claude-code/aiwf/en/.aiwf/README.md

@@ -1,97 +0,0 @@
-# AIWF Framework
-
-AIWF is a project management system designed to work with Claude Code's strengths and limitations. It provides structure for breaking down software projects into manageable, context-aware tasks.
-
-## Core Concept
-
-The fundamental challenge: AI context windows are limited and we can't control what information stays or leaves during long sessions. AIWF solves this by starting fresh for each task while providing rich, relevant context.
-
-## How AIWF Works
-
-### 1. Requirements First
-
-Projects begin with well-documented requirements and specifications:
-
-**In `01_PROJECT_DOCS/`:**
-
-- Architecture specifications (ARCHITECTURE.md is required)
-- Technical design documents
-- API specifications
-- Database schemas
-- Integration guides
-
-**In `02_REQUIREMENTS/`:**
-
-- Product Requirements Documents (PRDs) organized by milestone
-- Feature specifications
-- User stories and acceptance criteria
-
-Both directories work together to define what gets built and how.
-
-### 2. Structured Breakdown
-
-Work is organized hierarchically:
-
-- **Milestones** (M01, M02...) - Major project phases
-- **Sprints** (S01, S02...) - Focused work periods within milestones
-- **Tasks** (T01, T02...) - Atomic units of work
-
-### 3. Task Execution Flow
-
-Each task follows a strict workflow:
-
-1. Task selected from sprint or general tasks
-2. Status updated to `in_progress`
-3. Work performed following acceptance criteria
-4. Automatic code review against requirements
-5. Task marked `done` only after review passes
-6. File renamed with `TX` prefix to indicate completion
-
-### 4. Context Management
-
-For each task, AIWF provides:
-
-- The specific task description and criteria
-- Relevant sprint and milestone context
-- Architecture and requirements documentation
-- Project manifest for current state awareness
-
-This ensures Claude has exactly what's needed without information overload.
-
-### 5. Quality Control
-
-Built-in review processes maintain standards:
-
-- **Code Review**: Every task completion triggers requirement validation
-- **Project Review**: Regular health checks create timestamped snapshots
-- **Zero Tolerance**: Any deviation from specifications fails review
-
-## Directory Purpose
-
-- `00_PROJECT_MANIFEST.md` - Current project state and focus
-- `01_PROJECT_DOCS/` - Technical foundation (architecture, APIs, schemas)
-- `02_REQUIREMENTS/` - Business requirements organized by milestone
-- `03_SPRINTS/` - Sprint organization and task definitions
-- `04_GENERAL_TASKS/` - Non-sprint specific tasks
-- `05_ARCHITECTURE_DECISIONS/` - ADRs for key decisions
-- `10_STATE_OF_PROJECT/` - Project review history
-- `99_TEMPLATES/` - Standardized file templates
-
-## Commands Overview
-
-AIWF commands (`/project:AIWF:command`) automate the workflow:
-
-- Planning: `plan_milestone`, `create_sprint`
-- Execution: `create_task`, `do_task`, `code_review`
-- Maintenance: `commit`, `project_review`, `discuss_review`
-- Utilities: `initialize`
-
-## Key Principles
-
-1. **Fresh Context**: Each task starts with a clean slate
-2. **Focused Scope**: Tasks are sized for single-session completion
-3. **Rich Context**: Surrounding documentation guides development
-4. **Strict Validation**: Requirements are enforced, not suggested
-5. **Progressive Documentation**: Knowledge accumulates in structured form
-
-The result: Claude can always work confidently with full project awareness, regardless of session history.

package/claude-code/aiwf/en/.claude/CLAUDE_BE.md

@@ -1,276 +0,0 @@
-# CLAUDE.md
-
-IMPORTANT: These are my development preferences and guidelines. YOU MUST follow them when working on my projects.
-site: https://github.com/wcygan/dotfiles
-
-## Code Style & Workflow
-
-### Testing
-
-- **ALWAYS** write clear, descriptive test names for better readability
-- **ALWAYS** prefer running single tests over the whole test suite for performance
-- Use `deno test --filter="test name"` or framework-specific single test runners
-
-### Language & Framework Preferences
-
-#### Backend Programming
-
-IMPORTANT: I am primarily a backend developer and prefer these languages and frameworks:
-
-- **Go**: Use [ConnectRPC](https://github.com/connectrpc/connect-go) for RPC services
-- **Rust**: Use [axum](https://github.com/tokio-rs/axum) for web services
-- **Java**: Use [Spring Boot](https://spring.io/projects/spring-boot) with [Quarkus](https://quarkus.io/)
-
-#### Scripting & Automation
-
-**YOU MUST** use Deno for all scripting tasks instead of Bash or Python:
-
-- Create `deno.json` in project root with tasks for common operations
-- Use JSR imports: `import { walk } from "@std/fs";` NOT `https://deno.land/...`
-- Use [Dax](https://github.com/dsherret/dax) for cross-platform shell operations
-- Example deno.json imports: `"@std/fs": "jsr:@std/fs@^1.0.17"`
-
-#### Web Development
-
-Use [Deno Fresh](https://fresh.deno.dev/) with these practices:
-
-- Built-in test runner: `Deno.test()`
-- Organize tests: `/tests/unit/`, `/tests/component/`, `/tests/e2e/`
-- Mock external dependencies for fast, reliable tests
-- Use fresh-testing-library for component/handler testing
-
-## Infrastructure Choices
-
-IMPORTANT: I run a Talos Linux Kubernetes Cluster. Use these modern alternatives:
-
-- **Database**: Postgres (NOT MySQL)
-- **Cache**: DragonflyDB (NOT Redis)
-- **Streaming**: RedPanda (NOT Kafka)
-- **NoSQL**: ScyllaDB (NOT Cassandra)
-
-## Modern Development Tools
-
-### Preferred Command-Line Tools
-
-**ALWAYS** prefer these modern, fast alternatives:
-
-- **ripgrep (rg)**: Use instead of grep for searching code
-- **fd**: Use instead of find for finding files
-- **fzf**: Use for interactive fuzzy finding
-- **bat**: Use instead of cat for syntax-highlighted file viewing
-- **exa/eza**: Use instead of ls for better file listings
-- **delta**: Use for better git diffs
-- **zoxide**: Use instead of cd for smarter directory navigation
-- **duf**: Use instead of df for disk usage
-- **htop/btop**: Use instead of top for process monitoring
-- **jq**: Use for JSON processing and manipulation
-- **yq**: Use for YAML processing and manipulation
-- **hexyl**: Use for hex viewing of binary files
-
-### Output Format Preferences
-
-**ALWAYS** prefer JSON output for parsing when available:
-
-- Use `-o json` or `--json` flags when available (e.g., `kubectl get nodes -o json`)
-- Parse structured JSON output instead of text formats for reliability
-- Use `jq` for JSON processing in scripts
-- Examples:
-  - `kubectl get pods -o json | jq '.items[].metadata.name'`
-  - `docker inspect container-name | jq '.[0].State.Status'`
-  - `aws ec2 describe-instances --output json | jq '.Reservations[].Instances[]'`
-
-### Common Commands
-
-```bash
-# Modern tool usage
-rg "pattern" --type rust        # Search Rust files
-fd ".rs$" src/                   # Find all Rust files
-bat src/main.rs                  # View file with syntax highlighting
-eza -la --git                    # List files with git status
-delta                            # Better git diff viewer
-
-# Deno development
-deno task dev          # Start development server
-deno task test         # Run all tests
-deno test --filter="specific test"  # Run single test
-deno task build        # Build project
-deno check            # Type check
-deno fmt              # Format code
-deno lint             # Lint code
-
-# Project setup
-deno task init        # Initialize / configure the project for a new environment
-deno task deps        # Update dependencies
-
-# Git worktree (for multi-agent workflows)
-git worktree add ../project-feature feature-branch
-git worktree list
-git worktree remove ../project-feature
-```
-
-## Development Workflow
-
-1. **ALWAYS** run type checking/linting after code changes (e.g., `deno check`, `go vet`, `cargo check`)
-2. **ALWAYS** format code before committing using project's formatter
-3. **ALWAYS** run relevant tests before pushing changes
-4. **NEVER** commit without running pre-commit checks
-5. **ALWAYS** use semantic commit messages (feat:, fix:, docs:, refactor:, test:, chore:)
-
-### AI-Assisted Development Pattern
-
-1. **WRITE** failing tests first (test-driven development)
-2. **GENERATE** implementation with AI assistance
-3. **VERIFY** code meets requirements and security standards
-4. **REFACTOR** at appropriate checkpoints, not continuously
-5. **LOG** extensively for debugging AI-generated code
-
-### Context Management
-
-- **PROVIDE** clear, specific requirements to minimize context gaps
-- **INCLUDE** relevant project context in prompts
-- **DOCUMENT** assumptions and decisions in code comments
-
-## Security & Code Verification
-
-### AI-Generated Code Review
-
-- **ALWAYS** review and understand AI-generated code before accepting
-- **NEVER** commit code you don't fully understand
-- **RUN** security scanning on all generated code
-- **VERIFY** all third-party dependencies suggested by AI
-- **TEST** edge cases and error handling thoroughly
-
-### Sensitive Data Protection
-
-- **NEVER** share API keys, credentials, or proprietary code with AI
-- **USE** environment variables or secret management tools
-- **SANITIZE** logs and debug output before sharing
-
-## Project Planning & Coordination
-
-### PLAN.md Adherence
-
-When a `PLAN.md` file exists in the project root, **YOU MUST**:
-
-1. **READ** the PLAN.md file at the start of each session to understand current tasks and priorities
-2. **FOLLOW** the task breakdown and execution strategy defined in the plan
-3. **RESPECT** task dependencies and join points for multi-agent coordination
-4. **UPDATE** task status in the plan as work progresses
-5. **COORDINATE** with other agents at defined synchronization points
-6. **USE** the TodoWrite tool to track individual tasks from the plan
-
-### Multi-Agent Workflow
-
-When working as part of a multi-agent team:
-
-- **CHECK** `/tmp/{project-name}/project-status.md` or coordination files for shared state
-- **WORK** only on assigned tasks to avoid conflicts
-- **COMMUNICATE** progress through PR comments or status files
-- **WAIT** at join points until all parallel work is complete
-- **MERGE** work carefully following the plan's integration strategy
-- **USE** git worktrees to work on separate branches without conflicts
-- **CREATE** status files in `/tmp/{project-name}/claude-scratch/` for inter-agent communication
-- **COORDINATE** using shared JSON status files for structured updates in project-specific directories
-
-## Performance & Optimization
-
-### Token Efficiency
-
-- **OPTIMIZE** prompts for clarity and brevity
-- **BATCH** related operations in single requests
-- **USE** structured outputs (JSON) for parsing efficiency
-- **CACHE** common patterns and solutions locally
-
-### Parallel Development
-
-- **USE** Docker containers for isolated AI agent environments
-- **IMPLEMENT** clear synchronization points for multi-agent work
-- **MAINTAIN** shared state files in `/tmp/{project-name}/`
-
-## Task Management
-
-Use the task management system for tracking work items:
-
-- **Location**: Tasks are stored in `/tasks/` directory with `status.json` index
-- **Commands**: Use `/task-create`, `/task-update`, `/task-list`, `/task-show`, `/task-log`, `/task-search`, `/task-archive`
-- **Format**: Tasks are markdown files with structured metadata
-- **Integration**: Active tasks sync with TodoWrite for session tracking
-
-## File Organization
-
-- `/src/` - Source code
-- `/tests/` - Test files organized by type
-- `/scripts/` - Deno automation scripts
-- `/tasks/` - Task management files (markdown + status.json)
-- `deno.json` - Project configuration and tasks
-- `import_map.json` - Import mappings (if needed)
-
-## Documentation Style
-
-### README Files
-
-**KEEP README FILES CONCISE AND SCANNABLE:**
-
-- **Maximum 50 lines** for most projects
-- **No excessive emojis** or decorative elements
-- **Essential sections only**: Purpose, Quick Start, Key Commands
-- **No verbose explanations** - let code and comments speak
-- **Single quick start command** when possible
-- **Brief feature lists** without detailed descriptions
-- **Minimal project structure** - only if complex
-- **Essential links only** - avoid resource dumps
-
-**Example concise README:**
-
-````markdown
-# Project Name
-
-Brief one-line description of what it does.
-
-## Quick Start
-
-```bash
-deno task init && deno task dev
-```
-````
-
-## Key Commands
-
-- `deno task test` - Run tests
-- `deno task build` - Build project
-
-## Features
-
-- Core feature 1
-- Core feature 2
-- Core feature 3
-
-```
-**Avoid:**
-- Long feature descriptions
-- Extensive project structure diagrams
-- Multiple installation methods
-- Verbose technical explanations
-- Marketing-style language
-- Detailed configuration options in main README
-
-## Claude Code Features
-
-### Thinking Modes
-- `think` - Standard mode (4,000 tokens)
-- `think hard` - Enhanced analysis
-- `think harder` - Deep computation
-- `ultrathink` - Maximum analysis (31,999 tokens)
-
-### Effective Usage
-- **USE** thinking modes for complex architectural decisions
-- **AVOID** over-thinking simple tasks
-- **BALANCE** computation time with task complexity
-
-## IMPORTANT Notes
-
-- **YOU MUST** follow these guidelines exactly as written
-- **ALWAYS** ask for clarification if requirements conflict
-- **NEVER** use deprecated patterns or old import styles
-- **ALWAYS** prioritize performance and type safety
-```

package/claude-code/aiwf/en/.claude/commands/aiwf/aiwf_changelog.md

@@ -1,82 +0,0 @@
-# Generate Changelog from Git Commit History
-
-Analyzes git commit history to generate a structured changelog.
-
-## Work Steps
-
-### 1. Analyze Git History
-- Analyze recent commits to understand changes
-- Check tag information (if available)
-- Parse conventional commit format from commit messages
-
-### 2. Categorize Changes
-Classify commits into the following categories:
-- ✨ Features (feat)
-- 🐛 Bug Fixes (fix)
-- 📝 Documentation (docs)
-- 🎨 Code Style (style)
-- ♻️ Refactoring (refactor)
-- ⚡ Performance (perf)
-- ✅ Tests (test)
-- 🔧 Build/Config (build, chore)
-
-### 3. Generate Changelog
-- Create or update CHANGELOG.md file
-- Organize sections by version (based on tags)
-- Group changes by category
-- Display with commit SHA
-
-### 4. Usage
-```bash
-# Basic execution (full history)
-/project:aiwf:changelog
-
-# Specify commit range
-/project:aiwf:changelog v1.0.0..HEAD
-
-# Recent commits with count
-/project:aiwf:changelog -n 50
-```
-
-### 5. Example Output
-```markdown
-# Changelog
-
-## [Unreleased]
-
-### ✨ Features
-- feat(auth): add social login functionality (abc1234)
-- feat(api): implement RESTful API v2 (def5678)
-
-### 🐛 Bug Fixes
-- fix(ui): correct mobile responsive layout (ghi9012)
-
-### 📝 Documentation
-- docs(readme): update installation guide (jkl3456)
-```
-
-## Implementation Details
-
-1. Parse Git Log:
-```bash
-git log --pretty=format:"%h|%s|%an|%ad" --date=short
-```
-
-2. Conventional Commit Pattern Matching:
-```regex
-^(feat|fix|docs|style|refactor|perf|test|build|chore)(\(.+\))?:\s+(.+)$
-```
-
-3. Utilize Tag Information:
-```bash
-git describe --tags --abbrev=0
-```
-
-4. Apply changelog template and generate file
-
-5. Merge appropriately if existing CHANGELOG.md exists
-
-## Notes
-- Commits not following Conventional Commit format are classified as "Other Changes"
-- Merge commits are excluded by default
-- Generated changelog can be manually edited after review

package/claude-code/aiwf/en/.claude/commands/aiwf/aiwf_code_review.md

@@ -1,88 +0,0 @@
-# Code Review - Top-Down Execution
-
-Use the following instructions from top to bottom to execute a Code Review.
-
-## Create a TODO with EXACTLY these 6 Items
-
-1. Analyze the Scope given
-2. Find code changes within Scope
-3. Find relevant Specification and Documentation
-4. Compare code changes against Documentation and Requirements
-5. Analyze possible differences
-6. Provide PASS/FAIL verdict with details
-
-Follow step by step and adhere closely to the following instructions for each step.
-
-## DETAILS on every TODO item
-
-### 1. Analyze the Scope given
-
-check: <$ARGUMENTS>
-
-If empty, use default, otherwise interpret <$ARGUMENTS> to identify the scope of the Review. Only continue if you can find meaningful changes to review.
-
-**CONTEXT:** Before reviewing code changes:
-
-- Read `.aiwf/00_PROJECT_MANIFEST.md` to understand current sprint and milestone context
-- Use the manifest to identify which sprint is active and what work is in scope
-- Only evaluate against requirements appropriate for the current sprint's deliverables
-
-### 2. Find code changes within Scope
-
-With the identified Scope use `git diff` (on default: `git diff HEAD~1`) to find code changes.
-
-### 3. Find relevant Specifications and Documentation
-
-- FIND the Task, Sprint and Milestone involved in the work that was done and output your findings
-- Navigate to `.aiwf/03_SPRINTS/` to find the current sprint directory
-- READ the sprint meta file to understand sprint objectives and deliverables
-- If a specific task is in scope, find and READ the task file in the sprint directory
-- IDENTIFY related requirements in `.aiwf/02_REQUIREMENTS/` for the current milestone
-- READ involved Documents especially in `.aiwf/01_PROJECT_DOCS/` and `.aiwf/02_REQUIREMENTS/`
-- **IMPORTANT:** Focus on current sprint deliverables, not future milestone features
-
-### 4. Compare code changes against Documentation and Requirements
-
-- Use DEEP THINKING to compare changes against found Requirements and Specs.
-- Compare especially these things:
-  - **Data models / schemas** — fields, types, constraints, relationships.
-  - **APIs / interfaces** — endpoints, params, return shapes, status codes, errors.
-  - **Config / environment** — keys, defaults, required/optional.
-  - **Behaviour** — business rules, side-effects, error handling.
-  - **Quality** — naming, formatting, tests, linter status.
-
-**IMPORTANT**:
-
-- Deviations from the Specs is not allowed. Not even small ones. Be very picky here!
-- If in doubt call a **FAIL** and ask the User.
-- Zero tolerance on not following the Specs and Documentation.
-
-### 5. Analyze the differences
-
-- Analyze any difference found
-- Give every issue a Severity Score
-- Severity ranges from 1 (low) to 10 (high)
-- Remember List of issues and Scores for output
-
-### 6. Provide PASS/FAIL verdict with details
-
-- Call a **FAIL** on any differences found.
-  - Zero Tolerance - even on well meant additions.
-  - Leave it on the user to decide if small changes are allowed.
-- Only **PASS** if no discrepancy appeared.
-
-#### IMPORTANT: Output Format
-
-- Output the results of your review to the task's **## Output Log** section in the task file
-- Find the task file in `.aiwf/03_SPRINTS/` or `.aiwf/04_GENERAL_TASKS/` based on the scope
-- Append the review results to the existing Output Log with timestamp
-- Output Format:
-  ```
-  [YYYY-MM-DD HH:MM]: Code Review - PASS/FAIL
-  Result: **FAIL/PASS** Your final decision on if it's a PASS or a FAIL.
-  **Scope:** Inform the user about the review scope.
-  **Findings:** Detailed list with all Issues found and Severity Score.
-  **Summary:** Short summary on what is wrong or not.
-  **Recommendation:** Your personal recommendation on further steps.
-  ```
-- Also output a brief result summary to the console for immediate feedback