aiwf 0.3.8 → 0.3.12

package/claude-code/aiwf/ko/.aiwf/03_SPRINTS/CLAUDE.md

@@ -1,83 +0,0 @@
-# Sprint Management Instructions
-
-## Important Section - Always read
-
-- When updating Tasks Logs (Output Log) always fetch current date and time first
-- Update Output Log after every Subtask
-- Always be truthful in Logs. If you cannot complete a task for technical reasons, just write it down. Don't lie!
-- Only mark lines as done if you could acctually progress them.
-- Update the task file after every completed subtask and check Acceptance criteria as well if successful.
-
-## Sprint Structure
-
-Sprints are organized by milestone and sequence:
-
-- Folders follow pattern: `S<NN>_M<NN>_<Focus_Area>/` where:
-  - `S<NN>` is the sprint sequence number
-  - `M<NN>` directly references the milestone ID this sprint belongs to
-  - `<Focus_Area>` describes the sprint's main focus
-- Each sprint has a meta file: `S<NN>_sprint_meta.md`
-- Tasks use pattern: `T<NN>_S<NN>_<Description>.md`
-
-## Sprint Meta Files
-
-Sprint meta files define sprint goals and track status:
-
-```yaml
----
-sprint_id: S01
-milestone_id: M01
-status: in_progress # planning | in_progress | review | complete
----
-```
-
-Update status as progress occurs:
-
-- planning → in_progress → review → complete
-
-Always use the template at `.AIWF/99_TEMPLATES/sprint_template.md` when creating new sprint meta files.
-
-## Sprint Tasks
-
-Tasks within a sprint follow a standard format:
-
-- Status progression: open → in_progress → pending_review → done
-- When completing a task:
-  - Ask for user confirmation
-  - Update status to "done"
-  - Rename file from T... to TX... (e.g., `TX01_S01_Task_Name.md`)
-  - Update Output Log with final entry
-  - If GitHub issue is linked, update issue status
-
-Always use the template at `.AIWF/99_TEMPLATES/task_template.md` when creating new sprint tasks.
-
-### GitHub Issue Integration
-
-When working with tasks that have GitHub issues:
-
-1. **Creating Issues**: Use `/project:aiwf:issue_create {task_id}` to create a GitHub issue from a task
-2. **Linking Issues**: Add `github_issue: #123` to task frontmatter
-3. **Status Updates**: Update issue status when task status changes
-4. **Commit Integration**: Include `fixes #123` or `relates to #456` in commit messages
-5. **Pull Requests**: Use `/project:aiwf:pr_create {task_id}` to create PR with issue linking
-
-## Working with Sprint Tasks
-
-When executing a sprint task:
-
-1. Analyze task's Acceptance Criteria and Subtasks
-2. Check if task has a linked GitHub issue (look for `github_issue` in frontmatter)
-3. Update status to "in_progress" and update GitHub issue if linked:
-   ```bash
-   gh issue comment {issue_number} --body "🚀 Task work has started."
-   gh issue edit {issue_number} --add-label "in-progress"
-   ```
-4. Log activities in the Output Log with timestamps after every Subtask(!)
-5. Mark subtasks as completed using [x] only when they are really completed. If you were not able to complete them, don't mark them and tell the user.
-6. Reference architectural guidelines when implementing technical solutions
-7. Ensure the task follows the structure from the task template
-8. When task is complete, update GitHub issue if linked:
-   ```bash
-   gh issue comment {issue_number} --body "✅ Task has been completed."
-   gh issue edit {issue_number} --remove-label "in-progress" --add-label "completed"
-   ```

package/claude-code/aiwf/ko/.aiwf/03_SPRINTS/S01_M01_Initial_API/S01_sprint_meta.md

@@ -1,49 +0,0 @@
----
-sprint_folder_name: S01_M01_Initial_API
-sprint_sequence_id: S01
-milestone_id: M01
-title: Initial API Development
-status: active # pending | active | completed | aborted
-goal: Implement the foundational API structure including user authentication, basic project endpoints, and the initial database models.
-last_updated: 2023-07-15
----
-
-# Sprint: Initial API Development (S01) (EXAMPLE)
-
-## Sprint Goal
-
-Implement the foundational API structure including user authentication, basic project endpoints, and the initial database models.
-
-## Scope & Key Deliverables
-
-1. Set up the project structure with Express.js and MongoDB
-2. Implement user registration and authentication endpoints
-3. Create basic project and task models
-4. Implement core API endpoints for projects and tasks
-5. Set up automated testing infrastructure
-
-## Sprint Backlog
-
-- [T01_S01_Setup_Project_Structure](./T01_S01_Setup_Project_Structure.md)
-- [T02_S01_Define_User_Model](./T02_S01_Define_User_Model.md)
-- [T03_S01_Implement_Auth_Endpoints](./T03_S01_Implement_Auth_Endpoints.md)
-- [T04_S01_Define_Project_Model](./T04_S01_Define_Project_Model.md)
-- [T05_S01_Implement_Project_Endpoints](./T05_S01_Implement_Project_Endpoints.md)
-
-## Definition of Done (for the Sprint)
-
-The sprint will be considered complete when:
-
-- All sprint tasks are completed and meet their acceptance criteria
-- All implemented endpoints pass their test cases
-- API documentation is updated to reflect implemented endpoints
-- Code has been reviewed and merged to the development branch
-
-## Notes / Context
-
-This is an example sprint document to demonstrate how sprints might be structured in a project using the AIWF framework. This simulates what a typical initial API development sprint might look like.
-
-## Related Documents
-
-- [Milestone M01: Backend Setup](../../02_REQUIREMENTS/M01_Backend_Setup/M01_milestone_meta.md)
-- [API Specifications V1](../../02_REQUIREMENTS/M01_Backend_Setup/SPECS_API_V1.md)

package/claude-code/aiwf/ko/.aiwf/03_SPRINTS/S01_M01_Initial_API/T01_S01_Setup_Project_Structure.md

@@ -1,60 +0,0 @@
----
-task_id: T01_S01
-sprint_sequence_id: S01
-status: in_progress # open | in_progress | pending_review | done | failed | blocked
-complexity: Medium # Low | Medium | High
-last_updated: 2023-07-15
----
-
-# Task: Setup Project Structure (EXAMPLE)
-
-## Description
-
-Set up the initial project structure for the backend API service, including directory organization, dependency installation, and basic configuration.
-
-**Note: This is an example task to demonstrate the structure of a task in the AIWF framework.**
-
-## Goal / Objectives
-
-- Create a well-organized, scalable project structure
-- Set up the Express.js application with middleware
-- Configure MongoDB connection
-- Implement basic error handling
-- Set up environment configuration
-- Initialize logging system
-
-## Acceptance Criteria
-
-- [ ] Project structure follows MVC pattern with clear separation of concerns
-- [ ] Express application is set up with necessary middleware (CORS, body-parser, etc.)
-- [ ] MongoDB connection is configured with error handling
-- [ ] Environment variables are properly managed (development vs production)
-- [ ] Logger is implemented for request/error tracking
-- [ ] Basic error handling middleware is implemented
-- [ ] Project runs without errors
-- [ ] Initial tests pass
-
-## Subtasks
-
-- [ ] Initialize Node.js project with package.json
-- [ ] Install core dependencies (express, mongoose, dotenv, etc.)
-- [ ] Create directory structure for routes, controllers, models, middleware
-- [ ] Set up Express application with basic middleware
-- [ ] Configure MongoDB connection
-- [ ] Implement environment-specific configurations
-- [ ] Set up logging system
-- [ ] Implement error handling middleware
-- [ ] Write basic tests to verify configuration
-
-## Output Log
-
-[2023-07-15 14:30:00] Started task
-[2023-07-15 14:45:22] Created files: package.json, .env.example
-[2023-07-15 15:10:05] Created directory structure and base files: app.js, server.js, config/db.js, config/env.js
-[2023-07-15 15:30:18] Created middleware: middleware/auth.js, middleware/error.js
-[2023-07-15 15:45:30] Created util files: utils/logger.js
-[2023-07-15 16:10:15] Created base routes: routes/index.js
-[2023-07-15 16:45:22] Implemented error handling in middleware/error.js
-[2023-07-15 17:20:10] Configured logging system in utils/logger.js
-[2023-07-15 18:20:45] Added Jest configuration and created sample tests
-[2023-07-15 18:35:30] Completed all subtasks, verified server starts successfully

package/claude-code/aiwf/ko/.aiwf/04_GENERAL_TASKS/CLAUDE.md

@@ -1,96 +0,0 @@
-# General Tasks Instructions
-
-## General Task Structure
-
-General tasks are standalone work items not tied to sprints:
-
-- Files follow pattern: `T<NNN>_<Description>.md`
-- Completed tasks: `TX<NNN>_<Description>.md`
-
-Always use the template at `.AIWF/99_TEMPLATES/task_template.md` when creating new general tasks.
-
-## Task Formatting
-
-General tasks use standardized YAML frontmatter and sections:
-
-```yaml
----
-task_id: T001
-status: open # open | in_progress | pending_review | done | failed | blocked
-complexity: Medium # Low | Medium | High
-last_updated: YYYY-MM-DD HH:MM
-github_issue: #123 # Optional: Link to GitHub issue
----
-```
-
-The full task structure with all sections is defined in the task template. Always maintain this structure.
-
-## Working with General Tasks
-
-When handling general tasks:
-
-1. Check if task has a linked GitHub issue (look for `github_issue` in frontmatter)
-2. Update the status field as you progress
-3. If GitHub issue is linked, update it when starting:
-   ```bash
-   gh issue comment {issue_number} --body "🚀 Task work has started."
-   gh issue edit {issue_number} --add-label "in-progress"
-   ```
-4. Record timestamps in this format (YYYY-MM-DD HH:MM)
-5. Log all significant actions in the Output Log section:
-
-   ```plaintext
-   [YYYY-MM-DD HH:MM] Started task
-   [YYYY-MM-DD HH:MM] Modified files: file1.js, file2.js
-   ```
-
-6. Mark subtasks as they're completed: `- [x] Completed subtask`
-7. Use the Acceptance Criteria as your primary completion checklist
-8. Ensure all sections from the task template are preserved
-
-## Task Completion Process
-
-When a task is complete:
-
-1. Update status to "done"
-2. Update all Acceptance Criteria with [x]
-3. Add final Output Log entry
-4. If GitHub issue is linked, update it:
-   ```bash
-   gh issue comment {issue_number} --body "✅ Task has been completed."
-   gh issue edit {issue_number} --remove-label "in-progress" --add-label "completed"
-   ```
-5. Rename file from T... to TX... (e.g., `TX001_Task_Name.md`)
-
-## GitHub Integration
-
-### Creating Issues from Tasks
-
-To create a GitHub issue from a general task:
-
-```bash
-/project:aiwf:issue_create {task_id}
-```
-
-### Linking Existing Issues
-
-Add to task frontmatter:
-
-```yaml
-github_issue: #123
-```
-
-### Commit Integration
-
-When committing changes for a task with a linked issue:
-
-- Use `fixes #123` to auto-close the issue
-- Use `relates to #123` to reference without closing
-
-### Pull Request Creation
-
-After task completion, create a PR:
-
-```bash
-/project:aiwf:pr_create {task_id}
-```

package/claude-code/aiwf/ko/.aiwf/04_GENERAL_TASKS/T002_API_Rate_Limiting.md

@@ -1,54 +0,0 @@
----
-task_id: T002
-status: in_progress # open | in_progress | pending_review | done | failed | blocked
-complexity: Medium # Low | Medium | High
-last_updated: 2023-07-25T09:15:00Z
----
-
-# Task: API Rate Limiting (EXAMPLE)
-
-## Description
-
-Implement rate limiting for the API to prevent abuse and ensure fair usage across all clients. This task involves adding middleware to track and limit requests based on client IP or API key.
-
-**Note: This is an example general task to demonstrate how non-sprint-specific tasks might be structured in the AIWF framework.**
-
-## Goal / Objectives
-
-- Protect API endpoints from abuse and excessive requests
-- Implement configurable rate limits based on client authentication
-- Track usage statistics for billing and monitoring
-- Provide clear feedback to clients when limits are exceeded
-- Ensure minimal performance impact on normal API operation
-
-## Acceptance Criteria
-
-- [ ] Rate limiting is applied to all public API endpoints
-- [ ] Different rate limits are configurable based on client tier/authentication
-- [ ] Response headers include rate limit information (limit, remaining, reset)
-- [ ] When limit is exceeded, a 429 status code is returned with appropriate error message
-- [ ] Rate limiting can be temporarily disabled for specific clients if needed
-- [ ] Implementation has minimal impact on response times (<10ms overhead)
-- [ ] Usage statistics are collected for monitoring and analysis
-
-## Subtasks
-
-- [x] Research rate limiting strategies and best practices
-- [x] Evaluate libraries (express-rate-limit, rate-limiter-flexible, etc.)
-- [x] Design rate limit tiers for different client types
-- [ ] Implement rate limiting middleware
-- [ ] Add custom response headers
-- [ ] Create storage adapter for distributed rate limiting
-- [ ] Implement override mechanism for special cases
-- [ ] Add monitoring and alerts for rate limit events
-- [ ] Document rate limiting behavior for API consumers
-
-## Output Log
-
-_(This section is populated as work progresses on the task)_
-
-[2023-07-23 10:30:00] Started task
-[2023-07-23 13:45:22] Completed research on rate limiting strategies
-[2023-07-24 09:15:30] Evaluated rate-limiter-flexible and express-rate-limit libraries
-[2023-07-24 15:50:15] Decided on rate-limiter-flexible for implementation
-[2023-07-25 09:15:00] Designed rate limit tiers for different client authentication levels

package/claude-code/aiwf/ko/.aiwf/04_GENERAL_TASKS/TX001_Refactor_Logging_Module.md

@@ -1,58 +0,0 @@
----
-task_id: T001
-status: done # open | in_progress | pending_review | done | failed | blocked
-complexity: Medium # Low | Medium | High
-last_updated: 2023-07-22T16:45:00Z
----
-
-# Task: Refactor Logging Module (EXAMPLE)
-
-## Description
-
-The current logging implementation is basic and needs to be enhanced to provide better visibility and monitoring capabilities. This task involves refactoring the logging module to add structured logging, log rotation, and improved error tracking.
-
-**Note: This is an example general task to demonstrate how non-sprint-specific tasks might be structured in the AIWF framework.**
-
-## Goal / Objectives
-
-- Implement structured JSON logging for better parsing by log analysis tools
-- Add log rotation to prevent log files from growing too large
-- Enable different log levels based on environment
-- Add request ID tracking for tracing requests through the system
-- Improve error logging with stack traces and contextual information
-
-## Acceptance Criteria
-
-- [x] Logs are output in structured JSON format
-- [x] Log files are rotated based on size and/or date
-- [x] Different log levels are used appropriately (debug, info, warn, error)
-- [x] Each request has a unique ID that is logged with every related log entry
-- [x] Error logs include stack traces and relevant request information
-- [x] Performance impact of logging is minimal
-- [x] Documentation is updated to reflect new logging capabilities
-
-## Subtasks
-
-- [x] Evaluate and select appropriate logging libraries and tools
-- [x] Design the structured log format with required fields
-- [x] Implement log rotation configuration
-- [x] Add request ID middleware for request tracking
-- [x] Enhance error logging with more contextual information
-- [x] Update logging throughout the application to use new formats
-- [x] Write tests for logging functionality
-- [x] Document the new logging system
-
-## Output Log
-
-_(This section is populated as work progresses on the task)_
-
-[2023-07-15 10:30:00] Started task
-[2023-07-15 11:15:22] Researched logging libraries: winston, pino, bunyan
-[2023-07-15 13:45:30] Created prototype with winston for structured JSON logging
-[2023-07-15 15:20:15] Implemented log rotation with winston-daily-rotate-file
-[2023-07-15 16:40:05] Added request ID middleware
-[2023-07-15 17:30:18] Enhanced error logging with stack traces and context
-[2023-07-16 09:15:40] Updated application code to use new logging format
-[2023-07-18 14:22:10] Wrote tests for logging functionality
-[2023-07-20 11:05:33] Updated documentation with logging guidelines
-[2023-07-22 16:45:00] Task completed

package/claude-code/aiwf/ko/.aiwf/05_ARCHITECTURAL_DECISIONS/ADR001_Chosen_Database_System.md

@@ -1,119 +0,0 @@
-# ADR 001: Chosen Database System (EXAMPLE)
-
-## Status
-
-Accepted
-
-## Date
-
-2023-07-05
-
-## Context
-
-The backend system needs a database to store user accounts, projects, tasks, and other application data. The choice of database system will impact performance, scalability, development speed, and maintenance requirements.
-
-**Note: This is an example Architecture Decision Record to demonstrate how ADRs might be structured in the AIWF framework.**
-
-We evaluated several options including:
-
-- Relational databases (PostgreSQL, MySQL)
-- Document databases (MongoDB, CouchDB)
-- Key-value stores (Redis, DynamoDB)
-
-## Decision
-
-We will use **MongoDB** as the primary database for this project.
-
-## Rationale
-
-The decision was based on the following factors:
-
-1. **Schema Flexibility**: The project requirements are expected to evolve rapidly during development. MongoDB's flexible schema allows us to iterate quickly without needing migrations for every model change.
-
-2. **JSON-Native Data Model**: Our API communicates in JSON, and MongoDB's BSON format aligns well with our data structures. This reduces the object-relational impedance mismatch.
-
-3. **Scalability**: MongoDB's horizontal scaling capabilities via sharding will support our growth projections.
-
-4. **Developer Productivity**: The team has prior experience with MongoDB and Mongoose ODM, which will accelerate development.
-
-5. **Performance**: For our read-heavy workloads with relatively simple query patterns, MongoDB offers good performance characteristics.
-
-6. **Ecosystem**: The robust Node.js ecosystem around MongoDB with libraries like Mongoose provides tools for validation, middleware, and other features that align with our development approach.
-
-Some concerns were raised about:
-
-- Lack of ACID transactions across multiple documents (though MongoDB does support multi-document transactions now)
-- Potential for data duplication in document model
-
-We determined these concerns were manageable for our use case and outweighed by the benefits.
-
-## Alternatives Considered
-
-### PostgreSQL
-
-Pros:
-
-- Mature, proven technology with strong ACID compliance
-- Excellent for complex relational data and joins
-- Support for JSON data types provides some schema flexibility
-
-Cons:
-
-- Schema migrations could slow development velocity
-- Object-relational mapping adds complexity
-- Less natural fit for our document-oriented data model
-
-### DynamoDB
-
-Pros:
-
-- Fully managed service with automatic scaling
-- Predictable performance with guaranteed low-latency
-- Strong consistency options
-
-Cons:
-
-- Less flexible query capabilities
-- AWS lock-in
-- Potentially higher cost for our access patterns
-- Less familiar to the development team
-
-## Consequences
-
-### Positive
-
-- Faster initial development due to schema flexibility
-- Easier object mapping between API and database
-- Good performance for our expected read-heavy workloads
-- Simplified deployment with MongoDB Atlas
-
-### Negative
-
-- Will require care when modeling relationships between data
-- May need supplementary systems (like Redis) for certain use cases
-- Need to handle eventual consistency in some parts of the application
-
-### Neutral
-
-- Team will need to follow MongoDB best practices for schema design
-- We'll use Mongoose ODM to provide schema validation and middleware
-
-## Implementation Notes
-
-- We will use MongoDB Atlas as the managed service for all environments
-- Mongoose will be our ODM of choice
-- Initial indexes will be created for user email, project names, and task status
-- We will implement soft deletion for most entities
-- Data validation will happen at both the Mongoose schema level and API input level
-
-## Related Decisions
-
-- ADR002: API Authentication Method
-- ADR004: Caching Strategy (pending)
-
-## References
-
-- [MongoDB Documentation](https://docs.mongodb.com/)
-- [Mongoose Documentation](https://mongoosejs.com/docs/)
-- MongoDB vs PostgreSQL comparison analysis (internal document)
-- Performance benchmark results (internal document)

package/claude-code/aiwf/ko/.aiwf/05_ARCHITECTURAL_DECISIONS/ADR002_API_Authentication_Method.md

@@ -1,124 +0,0 @@
-# ADR 002: API Authentication Method (EXAMPLE)
-
-## Status
-
-Accepted
-
-## Date
-
-2023-07-08
-
-## Context
-
-Our API requires a secure authentication mechanism to identify users, protect resources, and control access to endpoints. We needed to select an approach that balances security, usability, and compatibility with our chosen tech stack.
-
-**Note: This is an example Architecture Decision Record to demonstrate how ADRs might be structured in the AIWF framework.**
-
-Several authentication strategies were considered:
-
-- Session-based authentication with cookies
-- JWT (JSON Web Tokens)
-- OAuth 2.0
-- API keys
-- Combinations of the above
-
-## Decision
-
-We will use **JWT (JSON Web Tokens)** as our primary authentication method, with OAuth 2.0 support for social logins.
-
-## Rationale
-
-Our decision was based on the following factors:
-
-1. **Statelessness**: JWTs are self-contained and don't require server-side session storage, aligning well with our API-first, potentially distributed architecture.
-
-2. **Performance**: Token validation can happen without database lookups for each request, improving API response times.
-
-3. **Cross-domain compatibility**: JWTs work well across different domains and in mobile applications, supporting our multi-client strategy.
-
-4. **Security feature support**: JWTs support expiration, audience validation, and can be cryptographically signed to ensure integrity.
-
-5. **OAuth Integration**: For social logins (Google, GitHub), we can still issue JWTs after OAuth authentication, maintaining a consistent authorization approach.
-
-6. **Client-side storage**: JWTs can be securely stored in client-side mechanisms like localStorage or HTTP-only cookies, giving us flexibility in implementation.
-
-7. **Industry standard**: JWT is widely adopted, well-documented, and has strong library support in our tech stack.
-
-We acknowledged some concerns with JWT:
-
-- Token revocation requires additional mechanisms (blacklisting or short expiration with refresh tokens)
-- Token size can be larger than simple session IDs
-- Token payload is encoded, not encrypted (sensitive data shouldn't be included)
-
-## Alternatives Considered
-
-### Session-based Authentication
-
-Pros:
-
-- Well-established, traditional approach
-- Easy to implement and understand
-- Simple to revoke (delete the session)
-
-Cons:
-
-- Requires session storage on the server
-- Can be problematic in distributed/scaled environments
-- Typically relies on cookies which have cross-domain limitations
-
-### API Keys
-
-Pros:
-
-- Very simple to implement
-- Good for service-to-service communication
-- No expiration management needed
-
-Cons:
-
-- Not suitable for user authentication
-- Limited granularity for permissions
-- No built-in standard for claims or payload
-
-## Consequences
-
-### Positive
-
-- Simplified server architecture with no session storage requirements
-- Improved performance for authentication checks
-- Enhanced cross-domain and mobile app support
-- Ability to include standard claims (exp, iat, sub, etc.) in the token
-
-### Negative
-
-- Need to implement token refresh mechanism for long-lived sessions
-- Need for a token blacklist/revocation strategy
-- More complex client-side token management compared to cookies
-
-### Neutral
-
-- Need to carefully design token payload to balance size and information needs
-- Will use short-lived access tokens (15 minutes) with longer-lived refresh tokens (7 days)
-- Client applications must properly handle token storage and renewal
-
-## Implementation Notes
-
-- We will use the `jsonwebtoken` library for token creation and validation
-- Tokens will be signed with RS256 (asymmetric) algorithm
-- Access tokens will have a 15-minute expiration
-- Refresh tokens will have a 7-day expiration and be single-use
-- We will implement a token blacklist using Redis for immediate revocation when needed
-- Social login (OAuth) will use Passport.js strategies
-- Authentication middleware will validate tokens on protected routes
-
-## Related Decisions
-
-- ADR001: Chosen Database System
-- ADR003: API Security Measures (pending)
-
-## References
-
-- [JWT.io](https://jwt.io/)
-- [IETF RFC 7519 - JSON Web Token](https://tools.ietf.org/html/rfc7519)
-- [Auth0: JWTs vs Sessions](https://auth0.com/blog/cookies-vs-tokens-definitive-guide/)
-- [OWASP: JSON Web Token Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/JSON_Web_Token_for_Java_Cheat_Sheet.html)