aiwf 0.1.0 → 0.3.0

package/claude-code/{simone/.simone/CLAUDE.MD → aiwf/en/.aiwf/CLAUDE.md}

@@ -1,30 +1,36 @@
-# CLAUDE.md - Simone Framework Structure Guide
+# CLAUDE.md - AIWF Framework Structure Guide
 
 ## Overview
-This is the root directory of the Simone framework structure. It contains all project documentation, requirements, sprints, and organizational files.
+
+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
+
 ```
-.simone/
+.AIWF/
 ├── 00_PROJECT_MANIFEST.md          # Central project reference (CORRECT NAME)
 ├── 01_PROJECT_DOCS/                # General project documentation
 ├── 02_REQUIREMENTS/                # Milestone-based requirements
@@ -38,6 +44,7 @@ The manifest is the central reference file that tracks:
 ## Naming Conventions Summary
 
 ### Files
+
 - **Project Manifest**: `00_PROJECT_MANIFEST.md`
 - **Milestone Meta**: `M##_milestone_meta.md`
 - **Sprint Meta**: `S##_M##_sprint_meta.md`
@@ -45,6 +52,7 @@ The manifest is the central reference file that tracks:
 - **ADR Files**: `ADR_###_*.md`
 
 ### Folders
+
 - **Milestones**: `M##_Milestone_Name/`
 - **Sprints**: `S##_M##_Sprint_Name/`
 - **State Snapshots**: `YYYY-MM-DD_HH-MM_snapshot/`
@@ -58,8 +66,9 @@ The manifest is the central reference file that tracks:
 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
+- Not updating the manifest after structural changes

package/claude-code/{simone/.simone → aiwf/en/.aiwf}/README.md

@@ -1,12 +1,12 @@
-# Simone Framework
+# AIWF Framework
 
-Simone 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.
+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. Simone solves this by starting fresh for each task while providing rich, relevant context.
+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 Simone Works
+## How AIWF Works
 
 ### 1. Requirements First
 
@@ -49,7 +49,7 @@ Each task follows a strict workflow:
 
 ### 4. Context Management
 
-For each task, Simone provides:
+For each task, AIWF provides:
 
 - The specific task description and criteria
 - Relevant sprint and milestone context
@@ -79,7 +79,7 @@ Built-in review processes maintain standards:
 
 ## Commands Overview
 
-Simone commands (`/project:simone:command`) automate the workflow:
+AIWF commands (`/project:AIWF:command`) automate the workflow:
 
 - Planning: `plan_milestone`, `create_sprint`
 - Execution: `create_task`, `do_task`, `code_review`

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

@@ -0,0 +1,276 @@
+# 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

@@ -0,0 +1,82 @@
+# 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

@@ -0,0 +1,88 @@
+# 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