aiwf 0.3.8 → 0.3.12

package/claude-code/aiwf/ko/.claude/commands/aiwf/aiwf_project_review.md

@@ -1,261 +0,0 @@
-# 프로젝트 리뷰 - 탑 다운 실행
-
-아키텍처, 진행 상황, 기술 결정에 초점을 맞춘 포괄적인 프로젝트 수준 리뷰를 수행합니다.
-
-**중요사항:**
-
-- 이는 최근 변경 사항이 아닌 전체 프로젝트 상태에 대한 고수준 리뷰입니다.
-- 프로젝트 문서에 명확히 언급되지 않은 한, 타임라인과 일정은 관련이 없습니다
-
-## 정확히 다음 9개 항목으로 TODO 생성
-
-1. 리뷰 범위 및 타이밍 분석
-2. 테스트 인프라 상태 실행 및 평가
-3. 프로젝트 문서 정렬 평가
-4. 마일스톤 및 스프린트 진행 상황 검토
-5. 코드베이스 아키텍처 및 구조 분석
-6. 파일 구성 및 워크플로우 준수 감사
-7. 기술적 결정 및 복잡성 평가
-8. 구현 품질 비평 (John Carmack 관점)
-9. 권장 사항과 함께 포괄적인 평가 제공
-
-단계별로 진행하며 각 단계에 대한 다음 지침을 엄격히 준수하세요.
-
-## 모든 TODO 항목에 대한 세부사항
-
-### 1. 리뷰 범위 및 타이밍 분석
-
-확인: <$ARGUMENTS>
-
-비어있다면 전체 프로젝트 리뷰를 수행합니다. 그렇지 않으면 <$ARGUMENTS>를 해석하여 특정 초점 영역(마일스톤, 스프린트, 아키텍처 구성 요소 등)을 식별합니다. Argument에 명시되지 않은 한 `.aiwf/10_STATE_OF_PROJECT`의 이전 프로젝트 리뷰와 비교하지 마세요.
-
-**중요:** 이 리뷰는 최근 변경사항의 맥락에서 전체 프로젝트 상태를 살펴봅니다.
-
-**핵심:** `.aiwf/00_PROJECT_MANIFEST.md`를 **먼저** 읽어서 다음을 이해하세요:
-
-- 현재 마일스톤 및 스프린트 상태
-- 완료된 작업 vs 진행 중인 작업 vs 계획된 작업
-- 활성 스프린트 목표 및 결과물
-
-**맥락 확인:** 기능 평가 전에:
-
-- `.aiwf/03_SPRINTS/`로 이동하여 현재 스프린트 찾기
-- 스프린트 메타 파일을 읽어 범위 내에 있는 것 이해하기
-- 스프린트 내에서 완료된 태스크 vs 계획된 태스크 확인
-- 향후 스프린트가 제공할 내용 이해하기
-
-**리뷰 원칙:** 전체 마일스톤 범위가 아닌 현재 스프린트 결과물에 대해 평가합니다.
-
-### 2. 테스트 인프라 상태 실행 및 평가
-
-**핵심:** 테스트 인프라 상태는 스프린트/마일스톤 진행의 차단 기준입니다.
-
-- 전체 테스트 스위트 실행을 위해 test.md 명령 사용 (@.claude/commands/aiwf/aiwf_test.md)
-- 테스트 결과 분석: 통과/실패/건너뛴 개수 및 실패 카테고리
-- 테스트 상태 점수 계산 (0-10 스케일):
-  - 10: 100% 통과율, 인프라 문제 없음
-  - 8-9: >95% 통과율, 사소한 문제만 있음
-  - 6-7: 80-95% 통과율, 일부 비핵심 실패
-  - 4-5: 60-80% 통과율, 중대한 문제
-  - 0-3: <60% pass rate, critical infrastructure problems
-- CATEGORIZE failures:
-  - Infrastructure: Import errors, missing modules
-  - Configuration: Environment variables, database connections
-  - Logic: Assertion failures, actual bugs
-  - Flaky: Intermittent failures
-- DETERMINE blocking status:
-  - Score < 6: BLOCKS sprint progression
-  - Score < 8: BLOCKS milestone completion
-  - Score < 4: TRIGGERS emergency escalation
-- IDENTIFY root causes of any infrastructure failures
-- TRACK trend vs previous review (improvement/degradation)
-- ASSESS test strategy validity for scope of the project. Tests should be pragmatic and help assuring functionality but not get in the way of development progress too much.
-
-### 3. Assess project documentation alignment
-
-**USE PARALLEL AGENTS** to follow these steps:
-
-- READ all core documents in `.aiwf/01_PROJECT_DOCS/` especially ARCHITECTURE.md
-- READ current milestone requirements in `.aiwf/02_REQUIREMENTS/`
-- READ architecture decisions in `.aiwf/05_ARCHITECTURE_DECISIONS` as they might extend/contradict other documents
-- IDENTIFY any gaps between documentation and current implementation
-- CHECK if the project is still following the documented architecture vision
-- VERIFY that current code structure matches documented patterns
-
-**IMPORTANT:** Documentation is our source of truth. Any deviation needs justification.
-
-### 4. Review milestone and sprint progress
-
-**USE PARALLEL AGENTS** to follow these steps:
-
-- READ `.aiwf/00_PROJECT_MANIFEST.md` for current status
-- ANALYZE completed sprints in `.aiwf/03_SPRINTS/`
-- COMPARE actual progress against CURRENT SPRINT deliverables (not full milestone)
-- DISTINGUISH between sprint-level tasks vs milestone-level features
-- ASSESS if current sprint focus aligns with milestone goals
-
-### 5. Analyze codebase architecture and structure
-
-#
-
-**USE PARALLEL AGENTS** to follow these steps:
-
-- EXAMINE overall project structure and organization
-- ANALYZE import patterns and dependency relationships
-- REVIEW database models and API structure for consistency
-- CHECK for architectural patterns: are we following DDD, clean architecture, etc.?
-- IDENTIFY any architectural debt or inconsistencies
-
-**Focus areas:**
-
-- **Directory structure** — logical organization, separation of concerns
-- **Dependencies** — are we over-engineering? unnecessary libraries?
-- **Models/Schemas** — consistency, proper relationships, normalization
-- **APIs** — RESTful design, proper HTTP methods, consistent patterns
-- **Configuration** — environment management, secrets handling
-
-### 6. Audit file organization and workflow compliance
-
-**IMPORTANT:** Check for workflow discipline and architectural boundary violations.
-
-- **Root directory audit** — identify files that don't belong in project root
-- **Development scripts** — verify all dev scripts follow `run_dev.py` pattern
-- **Test file organization** — check tests are in `tests/` directory, not scattered
-- **Documentation placement** — verify docs are in proper locations
-- **Temporary/experimental files** — flag any `.py` files that look ad-hoc or experimental
-
-**File Organization Rules to Enforce:**
-
-- **Development scripts** — MUST go through `run_dev.py`, not standalone files
-- **Test files** — MUST be in `tests/` directory with proper naming (`test_*.py`)
-- **Documentation** — MUST be in `docs/` or `.aiwf/01_PROJECT_DOCS/`
-- **Configuration** — MUST follow established patterns (`.env.example`, `pyproject.toml`)
-- **Temporary files** — SHOULD NOT exist in committed code
-
-**Red Flags to Identify:**
-
-- Multiple scripts doing similar things (duplicate functionality)
-- Random `.py` files in root directory
-- Test files outside `tests/` directory
-- Development scripts bypassing `run_dev.py`
-- Unclear file purposes or experimental code
-
-**CRITICAL:** File proliferation indicates workflow breakdown. Flag for immediate cleanup task creation.
-
-### 7. Evaluate technical decisions and complexity
-
-- ASSESS complexity vs. business value ratio
-- REVIEW choice of frameworks, libraries, and tools
-- ANALYZE if current patterns will scale with project growth
-- IDENTIFY areas where we might be over-complicating simple problems
-- CHECK for premature optimization or under-optimization
-
-**IMPORTANT:** Think like an experienced developer. Are we solving the right problems the right way?
-
-### 8. Critique implementation quality (John Carmack perspective)
-
-Think as John Carmack would: focus on simplicity, performance, and maintainability, but keep the projects goal in mind. Especially long term vision as well. Don't over simplify.
-
-- **Simplicity:** Are we solving problems in the most straightforward way?
-- **Performance:** Are there obvious performance issues or bottlenecks?
-- **Maintainability:** Will a new developer understand this code in 6 months?
-- **Robustness:** How does the system handle edge cases and failures?
-- **Technical debt:** What shortcuts are we taking that will hurt us later?
-
-Be **brutally honest**. Carmack-level critique means no sugar-coating but still staying true to the project's reality.
-Be thorough and **go above and beyond** in your analysis - leave no stone unturned.
-
-### 9. Provide comprehensive assessment with recommendations
-
-**IMPORTANT:** Get current timestamp and create output file
-
-- Get current timestamp using system date command
-- Create filename: `YYYY-MM-DD-HH-MM-<judgment-slug>.md` in `.aiwf/10_STATE_OF_PROJECT/`
-- Judgment slug should be 2-3 words describing overall project health (e.g., "solid-progress", "needs-focus", "critical-issues", "doing-great", "on-track")
-
-**IMPORTANT:** Write full report to the timestamped file with this format:
-
-```markdown
-# Project Review - [YYYY-MM-DD HH:MM]
-
-## 🎭 Review Sentiment
-
-[3 emojis only - no explanations]
-
-## Executive Summary
-
-- **Result:** EXCELLENT | GOOD | NEEDS_WORK | CRITICAL_ISSUES
-- **Scope:** What areas were reviewed
-- **Overall Judgment:** [2-3 word assessment used in filename]
-
-## Test Infrastructure Assessment
-
-- **Test Suite Status**: [PASSING/FAILING/BLOCKED] (X/Y tests)
-- **Test Pass Rate**: X% (Y passed, Z failed)
-- **Test Health Score**: X/10
-- **Infrastructure Health**: [HEALTHY/DEGRADED/BROKEN]
-  - Import errors: [count]
-  - Configuration errors: [count]
-  - Fixture issues: [count]
-- **Test Categories**:
-  - Unit Tests: X/Y passing
-  - Integration Tests: X/Y passing
-  - API Tests: X/Y passing
-- **Critical Issues**:
-  - [List of blocking test infrastructure problems]
-  - [Module import mismatches]
-  - [Environment configuration failures]
-- **Sprint Coverage**: [% of sprint deliverables with passing tests]
-- **Blocking Status**: [CLEAR/BLOCKED - reason]
-- **Recommendations**:
-  - [Immediate fixes required]
-  - [Test infrastructure improvements needed]
-
-## Development Context
-
-- **Current Milestone:** [ID and status from manifest]
-- **Current Sprint:** [ID and focus]
-- **Expected Completeness:** [what SHOULD be done at this stage]
-
-## Progress Assessment
-
-- **Milestone Progress:** [percentage complete]
-- **Sprint Status:** [current sprint assessment]
-- **Deliverable Tracking:** [what's done vs planned]
-
-## Architecture & Technical Assessment
-
-- **Architecture Score:** 1-10 rating with explanation
-- **Technical Debt Level:** LOW | MEDIUM | HIGH with specific examples
-- **Code Quality:** [overall assessment with examples]
-
-## File Organization Audit
-
-- **Workflow Compliance:** GOOD | NEEDS_ATTENTION | CRITICAL_VIOLATIONS
-- **File Organization Issues:** [list any misplaced files, duplicate scripts, etc.]
-- **Cleanup Tasks Needed:** [specific file moves/deletions/consolidations required]
-
-## Critical Findings
-
-### Critical Issues (Severity 8-10)
-
-[Lists of must-fix problems headed with #### heading, one empty line and then list of details]
-
-### Improvement Opportunities (Severity 4-7)
-
-[List of recommended enhancements headed with #### heading, one empty line and then list of details]
-
-## John Carmack Critique 🔥
-
-[Top 3 brutally honest observations about technical decisions]
-
-## Recommendations
-
-Based on your findings recommend Action items - chose whatever fits your findings
-
-- **Important fixes:** What needs to be fixed immediately?
-- **Optional fixes/changes:** What would still be recommended though optional?
-- **Next Sprint Focus:** Can the user move to the next sprint?
-```
-
-**IMPORTANT:** Be specific with file paths and line numbers. This review should be actionable and permanently archived.

package/claude-code/aiwf/ko/.claude/commands/aiwf/aiwf_test.md

@@ -1,124 +0,0 @@
-# 테스트 실행 및 일반적인 문제 수정
-
-다음 지시사항을 위에서 아래로 순서대로 따르세요.
-
-## 정확히 다음 4개 항목으로 TODO 생성
-
-1. 테스트 스위트 실행
-2. 결과 분석 및 문제 식별
-3. 발견된 일반적인 문제 수정
-4. 테스트 요약 제공
-
----
-
-## 1 · 테스트 스위트 실행
-
-### 먼저 프로젝트의 테스트 러너 감지:
-
-1. **Python 프로젝트:**
-
-   - `[tool.poetry]`가 있는 `pyproject.toml`이 존재하면: `poetry run pytest` 시도
-   - `setup.py` 또는 `requirements.txt`가 있으면: `pytest` 또는 `python -m pytest` 시도
-   - 커스텀 테스트 스크립트 존재시 (예: `run_tests.py`, `run_dev.py`): 해당 스크립트 사용
-   - 일반적인 플래그 추가: pytest용 `--tb=short`
-
-2. **JavaScript/TypeScript 프로젝트:**
-
-   - `package.json`이 존재하면: "scripts" 섹션에서 "test" 명령어 확인
-   - 일반적인 명령어: `npm test`, `npm run test`, `yarn test`, `pnpm test`
-   - 프레임워크별: `jest`, `vitest`, `mocha`
-
-3. **기타 언어:**
-   - Rust: `cargo test`
-   - Go: `go test ./...`
-   - Java: `mvn test` 또는 `gradle test`
-   - Ruby: `bundle exec rspec` 또는 `rake test`
-   - PHP: `composer test` 또는 `phpunit`
-
-### 감지된 테스트 명령어 실행:
-
-- 적절한 테스트 명령어 실행
-- 오류를 포함한 전체 출력 캡처
-- 실행 시간 및 테스트 개수 기록
-
-**테스트 러너를 찾을 수 없는 경우:** 사용자에게 보고하고 올바른 테스트 명령어 요청
-
-## 2 · 결과 분석 및 문제 식별
-
-다음 순서로 일반적인 문제 확인:
-
-### 언어별 문제:
-
-**Python:**
-
-- **__init__.py** 파일 누락 (import 오류, 테스트 미발견)
-- Import 경로 문제
-- Fixture 문제 (pytest)
-- 가상 환경 문제
-
-**JavaScript/TypeScript:**
-
-- 모듈 해결 오류
-- node_modules의 의존성 누락
-- Jest/Vitest 구성 문제
-- TypeScript 컴파일 오류
-
-**모든 언어 공통:**
-
-- 환경 변수 문제 (구성 누락)
-- 데이터베이스/외부 서비스 연결 오류
-- 파일 경로 문제 (절대 경로 vs 상대 경로)
-- 권한 문제
-
-## 3 · 발견된 일반적인 문제 수정
-
-**오직** 다음 특정 문제들만 자동으로 수정:**
-
-### Python 전용 수정:
-
-- 필요한 곳에 빈 `__init__.py` 파일 생성
-- 간단한 import 경로 문제 수정
-- 필요한 경우 Python 경로에 누락된 테스트 디렉토리 추가
-
-### JavaScript/TypeScript 수정:
-
-- node_modules가 누락된 경우 `npm install` 실행
-- jest.config.js의 간단한 모듈 해결 문제 수정
-- 누락된 테스트 설정 파일 생성
-
-### 일반 수정:
-
-- 누락된 테스트 디렉토리 생성
-- 가능한 경우 파일 권한 수정
-- 누락된 환경 변수 식별 및 사용자에게 알림
-
-**수정하지 않을 것:**
-
-- 실제 테스트 로직 실패
-- 비즈니스 로직 버그
-- 복잡한 구성 문제
-- 데이터베이스 스키마 문제
-- 외부 서비스 의존성
-
-## 4 · 테스트 요약 제공
-
-간단한 요약 생성:
-
-```
-테스트 결과:
-- 총 개수: X개 테스트
-- 통과: Y개 (Z%)
-- 실패: A개
-- 건너뜀: B개
-- 시간: C초
-
-수정된 문제:
-- [적용된 수정사항 목록]
-
-발견된 문제 (수동 수정 필요):
-- [주의가 필요한 문제 목록]
-
-상태: PASSING | FAILING | BLOCKED
-```
-
-**중요:** 간결하게 유지하세요. 이 명령어는 빠르고 테스트 실행에 집중해야 하며, 상세한 분석에 집중하지 않아야 합니다.

package/claude-code/aiwf/ko/.claude/commands/aiwf/aiwf_testing_review.md

@@ -1,198 +0,0 @@
-# 테스팅 리뷰 - 탑 다운 실행
-
-아키텍처, 진행 상황, 기술 결정에 초점을 맞춘 포괄적인 프로젝트 수준 리뷰를 수행합니다.
-
-## 전제조건 확인
-
-**먼저**, 테스팅 전략 문서가 존재하는지 확인하세요:
-
-- `.aiwf/01_PROJECT_DOCS/TESTING_STRATEGY.md` 확인
-- 찾을 수 없는 경우, 사용자에게 알립니다: "테스팅 전략 문서가 없습니다. 새로 만들어드릴까요, 아니면 일반적인 테스트 품질 검토로 진행할까요?"
-- 사용자가 전략 없이 진행하려는 경우, 일반적인 테스트 품질 원칙에 초점을 맞춰 검토를 조정합니다
-
-## 정확히 다음 7개 항목으로 TODO 생성
-
-1. 테스팅 전략 문서 로드 (또는 검토 기준 정의)
-2. 테스트 구현 구조 분석
-3. 테스트-코드 정렬 평가
-4. 잘못 정렬되거나 불필요한 테스트 식별
-5. 핵심 기능 커버리지 평가
-6. 수정 권장사항 생성
-7. 정렬 보고서 생성
-
-단계별로 따라가며 각 단계에 대한 다음 지침을 엄격히 준수하세요.
-
-## 모든 TODO 항목에 대한 세부사항
-
-### 1. 테스팅 전략 문서 로드 (또는 검토 기준 정의)
-
-**옵션 A - 전략 문서가 존재하는 경우:**
-
-- `.aiwf/01_PROJECT_DOCS/TESTING_STRATEGY.md` 로드
-- 주요 원칙과 우선순위 추출
-- 테스트해야 할 것과 하지 말아야 할 것 식별
-- 커버리지 기대치와 품질 게이트 주목
-- 테스팅 철학 이해
-
-**옵션 B - 전략 문서가 없는 경우:**
-검토 기준으로 일반적인 모범 사례를 사용:
-
-- 테스트는 구현이 아닌 동작에 초점을 맞춰야 함
-- 핵심 경로에는 커버리지가 있어야 함
-- 테스트는 유지보수 가능하고 명확해야 함
-- 단순한 getter/setter 과도 테스트 피하기
-- 커버리지와 유지보수 부담 간의 균형
-
-이 검토에 사용되는 접근법을 **문서화**하세요.
-
-### 2. 테스트 구현 구조 분석
-
-현재 테스트 코드베이스를 **검토**하세요:
-
-- 테스트 실행을 위해 test.md 명령 사용 (@.claude/commands/aiwf/aiwf_test.md)
-- 테스트 디렉토리 구조와 조직 탐색
-- 테스트 카테고리와 그 목적 식별
-- 테스트 명명 규칙과 패턴 확인
-- 테스트 인프라나 유틸리티 주목
-
-**개수 세기가 아닌 존재하는 것을 이해하는 데 집중하세요.**
-
-### 3. 테스트-코드 정렬 평가
-
-테스트를 실제 구현과 **비교**하세요:
-
-- 각 주요 구성요소에 대해 테스트가 기능과 일치하는지 확인
-- 동작 대 구현 세부사항을 테스트하는 테스트 식별
-- 과도한 설정이나 모킹이 있는 테스트 찾기
-- 리팩토링 시 자주 깨지는 테스트 찾기
-- 테스트 복잡성이 코드 복잡성과 일치하는지 확인
-
-**핵심 질문:** 테스트가 사용자가 중요하게 여기는 것을 검증하는가?
-
-### 4. 잘못 정렬되거나 불필요한 테스트 식별
-
-가치를 제공하지 않는 테스트를 **검색**하세요:
-
-**전략 문서를 사용하는 경우:**
-
-- 전략에서 "건너뛰기"로 표시된 영역의 테스트
-- 정의된 범위를 벗어난 테스트
-- 전략 가이드라인에 따라 과도하게 명시된 테스트
-
-**일반 원칙을 사용하는 경우:**
-
-- 단순한 기능에 대한 과도하게 설계된 테스트
-- 모든 리팩토링에서 깨지는 테스트
-- 중요하지 않은 기능의 에지 케이스 테스트
-- 과도한 모킹/설정이 있는 테스트
-- 성능 요구사항 없는 성능 테스트
-
-**수정하거나 제거할 특정 테스트 목록을 생성하세요.**
-
-### 5. 핵심 기능 커버리지 평가
-
-필수 기능에 적절한 테스트가 있는지 **검증**하세요:
-
-**전략 문서를 사용하는 경우:**
-
-- 전략에서 정의된 높은 우선순위 영역의 커버리지 확인
-- 전략별 요구사항이 테스트되는지 검증
-
-**모든 검토에 대해:**
-
-- 핵심 경로 테스트의 차이 식별
-- 해당되는 경우 인증/권한 확인
-- 중요한 작업의 오류 처리 검증
-- 필요한 곳에 데이터 무결성 테스트 존재 보장
-- 통합 지점이 테스트되는지 확인
-
-**해결이 필요한 특정 차이를 기록하세요.**
-
-### 6. 수정 권장사항 생성
-
-구체적이고 실행 가능한 권장사항을 **생성**하세요:
-
-각 발견사항에 대해:
-
-- 테스트 파일과 함수 명시
-- 수정이 필요한 이유 설명
-- 구체적인 변경사항 제안 (제거, 단순화, 추가)
-- 도움이 된다면 개선된 접근법의 예시 제공
-
-**형식:**
-
-```
-파일: tests/test_example.py::test_function_name
-문제: [문제점]
-조치: [해야 할 일]
-이유: [전략과 일치하는 이유]
-```
-
-### 7. 정렬 보고서 생성
-
-테스트-전략 정렬에 대한 집중된 보고서를 **생성**하세요:
-
-- 시스템 날짜 명령을 사용하여 현재 타임스탬프 가져오기
-- `.aiwf/10_STATE_OF_PROJECT/YYYY-MM-DD-HH-MM-test-alignment.md`에 보고서 생성
-
-**보고서 구조:**
-
-```markdown
-# 테스트-전략 정렬 검토 - [YYYY-MM-DD HH:MM]
-
-## 정렬 요약
-
-테스팅 전략과의 전반적인 정렬: [우수 | 양호 | 개선 필요 | 부족]
-
-주요 발견사항:
-
-- [테스트 스위트 건강상태에 대한 주요 발견사항]
-- [커버리지에 대한 주요 발견사항]
-- [유지보수 부담에 대한 주요 발견사항]
-
-## 수정이 필요한 테스트
-
-### 제거 (과도하게 설계되었거나 범위를 벗어남)
-
-[이유와 함께 특정 테스트 목록]
-
-### 단순화 (목적에 비해 너무 복잡함)
-
-[단순화 접근법과 함께 특정 테스트 목록]
-
-### 추가 (핵심 격차)
-
-[핵심 경로에 대한 특정 누락된 테스트 목록]
-
-## 권장 조치
-
-### 즉시 (차단 문제)
-
-- [ ] [파일/테스트 참조와 함께 구체적인 조치]
-
-### 단기 (품질 개선)
-
-- [ ] [파일/테스트 참조와 함께 구체적인 조치]
-
-### 장기 (기술 부채)
-
-- [ ] [파일/테스트 참조와 함께 구체적인 조치]
-
-## 테스트 건강 지표
-
-- 테스트가 코드 목적과 일치: [예 | 부분적으로 | 아니오]
-- 핵심 경로 커버됨: [예 | 부분적으로 | 아니오]
-- 유지보수 부담 합리적: [예 | 부분적으로 | 아니오]
-- 테스트가 개발 속도 지원: [예 | 부분적으로 | 아니오]
-
-## 구현 예시
-
-[필요한 경우, 테스트 개선의 전후 예시 표시]
-
-## 다음 검토
-
-권장 검토 시기: [X주/스프린트]
-다음 검토 집중 영역: [모니터링할 특정 영역]
-```
-
-**중요:** 메트릭이 아닌 정렬과 균형에 초점을 맞추세요. 목표는 프로젝트의 실제 요구를 충족하는 테스트입니다.