moai-adk 0.4.0__py3-none-any.whl → 0.4.4__py3-none-any.whl

moai_adk/templates/.moai/project/product.md

@@ -13,149 +13,149 @@ priority: high
 ## HISTORY
 
 ### v0.1.3 (2025-10-17)
-- **UPDATED**: 템플릿 버전 동기화 (v0.3.8)
+- **UPDATED**: Template version synced (v0.3.8)
 - **AUTHOR**: @Alfred
-- **SECTIONS**: Mission (12개 에이전트 최종 확인: Alfred + 11개 전문 에이전트)
-  - implementation-planner, tdd-implementer, quality-gate 추가
-  - code-builder → implementation-planner + tdd-implementer + quality-gate 분해
+- **SECTIONS**: Mission (finalized team of 12 agents: Alfred + 11 specialists)
+  - Added implementation-planner, tdd-implementer, quality-gate
+  - Split code-builder into implementation-planner + tdd-implementer + quality-gate
 
 ### v0.1.2 (2025-10-17)
-- **UPDATED**: 에이전트 수 갱신 (9개 → 11개)
+- **UPDATED**: Agent count adjusted (9 → 11)
 - **AUTHOR**: @Alfred
-- **SECTIONS**: Mission (Alfred SuperAgent 팀 구성 업데이트)
+- **SECTIONS**: Mission (updated Alfred SuperAgent roster)
 
 ### v0.1.1 (2025-10-17)
-- **UPDATED**: 템플릿 기본값을 실제 MoAI-ADK 프로젝트 내용으로 갱신
+- **UPDATED**: Template defaults aligned with the real MoAI-ADK project
 - **AUTHOR**: @Alfred
-- **SECTIONS**: Mission, User, Problem, Strategy, Success 실제 내용 반영
+- **SECTIONS**: Mission, User, Problem, Strategy, Success populated with project context
 
 ### v0.1.0 (2025-10-01)
-- **INITIAL**: 프로젝트 제품 정의 문서 작성
+- **INITIAL**: Authored the product definition document
 - **AUTHOR**: @project-owner
 - **SECTIONS**: Mission, User, Problem, Strategy, Success, Legacy
 
 ---
 
-## @DOC:MISSION-001 핵심 미션
+## @DOC:MISSION-001 Core Mission
 
-> **"SPEC이 없으면 CODE도 없다."**
+> **"No SPEC, no CODE."**
 
-{{PROJECT_NAME}}는 **SPEC-First TDD 방법론**을 통해 플랑켄슈타인 코드를 근본적으로 방지하는 프로젝트입니다.
+{{PROJECT_NAME}} combats Frankenstein code at the root by enforcing a **SPEC-first TDD methodology**.
 
-### 핵심 가치 제안
+### Core Value Proposition
 
-#### 4가지 핵심 가치
+#### Four Key Values
 
-1. **일관성 (Consistency)**: SPEC → TDD → Sync 3단계 파이프라인으로 개발 품질 보장
-2. **품질 (Quality)**: TRUST 5원칙 (Test First, Readable, Unified, Secured, Trackable) 자동 적용
-3. **추적성 (Traceability)**: @TAG 시스템 (`@SPEC → @TEST → @CODE → @DOC`)으로 완벽한 이력 추적
-4. **범용성 (Universality)**: 다양한 언어 및 프레임워크 지원
+1. **Consistency**: A three-step SPEC → TDD → Sync pipeline safeguards delivery quality.
+2. **Quality**: TRUST principles (Test First, Readable, Unified, Secured, Trackable) apply automatically.
+3. **Traceability**: The @TAG system (`@SPEC → @TEST → @CODE → @DOC`) preserves end-to-end lineage.
+4. **Universality**: Supports diverse programming languages and frameworks.
 
 #### Alfred SuperAgent
 
-**Alfred**는 12개 AI 에이전트 팀 (Alfred + 11개 전문 에이전트)을 조율하는 중앙 오케스트레이터입니다:
-- **spec-builder** 🏗️: SPEC 작성 (EARS 방식) - Sonnet
-- **implementation-planner** 📋: SPEC 분석 및 구현 전략 수립 - Sonnet
-- **tdd-implementer** 🔬: TDD RED-GREEN-REFACTOR 전문 구현 - Sonnet
-- **quality-gate** 🛡️: TRUST 원칙 통합 검증 - Haiku
-- **doc-syncer** 📖: 문서 동기화 (Living Document) - Haiku
-- **tag-agent** 🏷️: TAG 시스템 관리 - Haiku
-- **git-manager** 🚀: Git 워크플로우 자동화 - Haiku
-- **debug-helper** 🔍: 런타임 오류 진단 - Sonnet
-- **trust-checker** ✅: TRUST 원칙 검증 - Haiku
-- **cc-manager** 🛠️: Claude Code 설정 관리 - Sonnet
-- **project-manager** 📂: 프로젝트 초기화 - Sonnet
+**Alfred** coordinates a team of 12 AI agents (Alfred + 11 specialists):
+- **spec-builder** 🏗️: Authors SPECs (EARS pattern) – Sonnet
+- **implementation-planner** 📋: Analyzes SPECs and derives implementation plans – Sonnet
+- **tdd-implementer** 🔬: Executes RED–GREEN–REFACTOR cycles – Sonnet
+- **quality-gate** 🛡️: Enforces TRUST principles – Haiku
+- **doc-syncer** 📖: Maintains living documentation – Haiku
+- **tag-agent** 🏷️: Manages the TAG system – Haiku
+- **git-manager** 🚀: Automates Git workflows – Haiku
+- **debug-helper** 🔍: Diagnoses runtime issues – Sonnet
+- **trust-checker** ✅: Verifies TRUST compliance – Haiku
+- **cc-manager** 🛠️: Configures Claude Code – Sonnet
+- **project-manager** 📂: Bootstraps projects – Sonnet
 
-## @SPEC:USER-001 주요 사용자층
+## @SPEC:USER-001 Primary Users
 
-### 1차 사용자
-- **대상**: [주요 사용자층을 정의하세요]
-- **핵심 니즈**: [사용자가 해결하고자 하는 문제]
-- **핵심 시나리오**: [주요 사용 시나리오를 설명하세요]
+### Primary Audience
+- **Who**: [Describe your main user segment]
+- **Core Needs**: [Explain the problems they want solved]
+- **Critical Scenarios**: [Outline their primary usage scenarios]
 
-### 2차 사용자 (선택사항)
-- **대상**: [추가 사용자층이 있다면 정의하세요]
-- **핵심 니즈**: [추가 사용자의 요구사항]
+### Secondary Audience (Optional)
+- **Who**: [Describe any secondary user group]
+- **Needs**: [Capture their requirements]
 
-## @SPEC:PROBLEM-001 해결하는 핵심 문제
+## @SPEC:PROBLEM-001 Problems to Solve
 
-### 우선순위 높음
-1. [해결하려는 주요 문제 1]
-2. [해결하려는 주요 문제 2]
-3. [해결하려는 주요 문제 3]
+### High Priority
+1. [Top problem to resolve]
+2. [Second critical problem]
+3. [Third critical problem]
 
-### 우선순위 중간
-- [중요도가 중간인 문제들]
+### Medium Priority
+- [Problems with moderate urgency]
 
-### 현재 실패 사례들
-- [기존 솔루션의 한계나 실패 사례들]
+### Current Failure Cases
+- [Limitations or failure patterns in existing solutions]
 
-## @DOC:STRATEGY-001 차별점 및 강점
+## @DOC:STRATEGY-001 Differentiators & Strengths
 
-### 경쟁 솔루션 대비 강점
-1. [주요 차별점 1]
-   - **발휘 시나리오**: [어떤 상황에서 이 강점이 드러나는지]
+### Strengths Versus Alternatives
+1. [Primary differentiator]
+   - **When it matters**: [Scenario where the strength shines]
 
-2. [주요 차별점 2]
-   - **발휘 시나리오**: [구체적인 활용 시나리오]
+2. [Second differentiator]
+   - **When it matters**: [Concrete usage example]
 
-## @SPEC:SUCCESS-001 성공 지표
+## @SPEC:SUCCESS-001 Success Metrics
 
-### 즉시 측정 가능한 KPI
-1. [측정 지표 1]
-   - **베이스라인**: [목표값과 측정 방법]
+### Immediately Measurable KPIs
+1. [Metric 1]
+   - **Baseline**: [Target value and measurement approach]
 
-2. [측정 지표 2]
-   - **베이스라인**: [목표값과 측정 방법]
+2. [Metric 2]
+   - **Baseline**: [Target value and measurement approach]
 
-### 측정 주기
-- **일간**: [일단위로 측정할 지표]
-- **주간**: [주단위로 측정할 지표]
-- **월간**: [월단위로 측정할 지표]
+### Measurement Cadence
+- **Daily**: [Metrics tracked daily]
+- **Weekly**: [Metrics tracked weekly]
+- **Monthly**: [Metrics tracked monthly]
 
 ## Legacy Context
 
-### 기존 자산 요약
-- [활용할 기존 자산이나 리소스]
-- [참고할 기존 프로젝트나 경험]
+### Existing Assets
+- [Reusable assets or resources]
+- [Relevant past projects or experience]
 
-## TODO:SPEC-BACKLOG-001 다음 단계 SPEC 후보
+## TODO:SPEC-BACKLOG-001 Next SPEC Candidates
 
-1. **SPEC-001**: [첫 번째 구현할 기능]
-2. **SPEC-002**: [두 번째 구현할 기능]
-3. **SPEC-003**: [세 번째 구현할 기능]
+1. **SPEC-001**: [First feature to implement]
+2. **SPEC-002**: [Second feature to implement]
+3. **SPEC-003**: [Third feature to implement]
 
-## EARS 요구사항 작성 가이드
+## EARS Requirement Authoring Guide
 
 ### EARS (Easy Approach to Requirements Syntax)
 
-SPEC 작성 시 다음 EARS 구문을 활용하여 체계적인 요구사항을 작성하세요:
+Use these EARS patterns to keep SPEC requirements structured:
 
-#### EARS 구문 형식
-1. **Ubiquitous Requirements**: 시스템은 [기능]을 제공해야 한다
-2. **Event-driven Requirements**: WHEN [조건]이면, 시스템은 [동작]해야 한다
-3. **State-driven Requirements**: WHILE [상태]일 때, 시스템은 [동작]해야 한다
-4. **Optional Features**: WHERE [조건]이면, 시스템은 [동작]할 수 있다
-5. **Constraints**: IF [조건]이면, 시스템은 [제약]해야 한다
+#### EARS Patterns
+1. **Ubiquitous Requirements**: The system shall provide [capability].
+2. **Event-driven Requirements**: WHEN [condition], the system shall [behaviour].
+3. **State-driven Requirements**: WHILE [state], the system shall [behaviour].
+4. **Optional Features**: WHERE [condition], the system may [behaviour].
+5. **Constraints**: IF [condition], the system shall enforce [constraint].
 
-#### 적용 예시
+#### Sample Application
 ```markdown
-### Ubiquitous Requirements (기본 기능)
-- 시스템은 사용자 관리 기능을 제공해야 한다
+### Ubiquitous Requirements (Foundational)
+- The system shall provide user management capabilities.
 
-### Event-driven Requirements (이벤트 기반)
-- WHEN 사용자가 가입하면, 시스템은 환영 이메일을 발송해야 한다
+### Event-driven Requirements
+- WHEN a user signs up, the system shall send a welcome email.
 
-### State-driven Requirements (상태 기반)
-- WHILE 사용자가 로그인된 상태일 때, 시스템은 개인화된 대시보드를 표시해야 한다
+### State-driven Requirements
+- WHILE a user remains logged in, the system shall display a personalized dashboard.
 
-### Optional Features (선택적 기능)
-- WHERE 프리미엄 계정이면, 시스템은 고급 기능을 제공할 수 있다
+### Optional Features
+- WHERE an account is premium, the system may offer advanced features.
 
-### Constraints (제약사항)
-- IF 계정이 잠긴 상태이면, 시스템은 로그인을 거부해야 한다
+### Constraints
+- IF an account is locked, the system shall reject login attempts.
 ```
 
 ---
 
-_이 문서는 `/alfred:1-spec` 실행 시 SPEC 생성의 기준이 됩니다._
+_This document serves as the baseline when `/alfred:1-plan` runs._

moai_adk/templates/.moai/project/structure.md

@@ -13,144 +13,144 @@ priority: medium
 ## HISTORY
 
 ### v0.1.1 (2025-10-17)
-- **UPDATED**: 템플릿 버전 동기화 (v0.3.8)
+- **UPDATED**: Template version synced (v0.3.8)
 - **AUTHOR**: @Alfred
-- **SECTIONS**: 메타데이터 표준화 (author 필드 단수형, priority 추가)
+- **SECTIONS**: Metadata standardization (single `author` field, added `priority`)
 
 ### v0.1.0 (2025-10-01)
-- **INITIAL**: 프로젝트 구조 설계 문서 작성
+- **INITIAL**: Authored the structure design document
 - **AUTHOR**: @architect
 - **SECTIONS**: Architecture, Modules, Integration, Traceability
 
 ---
 
-## @DOC:ARCHITECTURE-001 시스템 아키텍처
+## @DOC:ARCHITECTURE-001 System Architecture
 
-### 아키텍처 전략
+### Architectural Strategy
 
-**[프로젝트의 전체 아키텍처 접근법을 설명하세요]**
+**[Describe the end-to-end architectural approach for the project]**
 
 ```
 Project Architecture
-├── [Layer 1]          # [역할 설명]
-├── [Layer 2]          # [역할 설명]
-├── [Layer 3]          # [역할 설명]
-└── [Layer 4]          # [역할 설명]
+- [Layer 1]          # [Describe its responsibilities]
+- [Layer 2]          # [Describe its responsibilities]
+- [Layer 3]          # [Describe its responsibilities]
+- [Layer 4]          # [Describe its responsibilities]
 ```
 
-**선택 이유**: [아키텍처 선택의 근거와 트레이드오프]
+**Rationale**: [Explain the trade-offs behind the chosen architecture]
 
-## @DOC:MODULES-001 모듈별 책임 구분
+## @DOC:MODULES-001 Module Responsibilities
 
-### 1. [주요 모듈 1]
+### 1. [Primary Module 1]
 
-- **책임**: [모듈의 주요 책임]
-- **입력**: [처리하는 입력 데이터]
-- **처리**: [수행하는 주요 처리 과정]
-- **출력**: [생성하는 결과물]
+- **Responsibilities**: [Key duties of the module]
+- **Inputs**: [Data it consumes]
+- **Processing**: [Core processing steps]
+- **Outputs**: [Produced artifacts]
 
-| 컴포넌트 | 역할 | 주요 기능 |
-|----------|------|-----------|
-| [컴포넌트1] | [역할] | [기능 목록] |
-| [컴포넌트2] | [역할] | [기능 목록] |
+| Component     | Role   | Key Capabilities |
+| ------------- | ------ | ---------------- |
+| [Component 1] | [Role] | [Feature list]   |
+| [Component 2] | [Role] | [Feature list]   |
 
-### 2. [주요 모듈 2]
+### 2. [Primary Module 2]
 
-- **책임**: [모듈의 주요 책임]
-- **입력**: [처리하는 입력 데이터]
-- **처리**: [수행하는 주요 처리 과정]
-- **출력**: [생성하는 결과물]
+- **Responsibilities**: [Key duties of the module]
+- **Inputs**: [Data it consumes]
+- **Processing**: [Core processing steps]
+- **Outputs**: [Produced artifacts]
 
-## @DOC:INTEGRATION-001 외부 시스템 통합
+## @DOC:INTEGRATION-001 External Integrations
 
-### [외부 시스템 1] 연동
+### [External System 1] Integration
 
-- **인증 방식**: [인증 방법]
-- **데이터 교환**: [데이터 형식과 프로토콜]
-- **장애 시 대체**: [fallback 전략]
-- **위험도**: [리스크 수준과 완화 방안]
+- **Authentication**: [Method used]
+- **Data Exchange**: [Formats and protocols]
+- **Failure Handling**: [Fallback strategy]
+- **Risk Level**: [Risk profile and mitigation]
 
-### [외부 시스템 2] 연동
+### [External System 2] Integration
 
-- **용도**: [사용 목적]
-- **의존성 수준**: [의존도와 대안]
-- **성능 요구사항**: [응답 시간, 처리량 등]
+- **Purpose**: [Why it is used]
+- **Dependency Level**: [Degree of reliance and alternatives]
+- **Performance Requirements**: [Latency, throughput, etc.]
 
-## @DOC:TRACEABILITY-001 추적성 전략
+## @DOC:TRACEABILITY-001 Traceability Strategy
 
-### TAG 체계 적용
+### Applying the TAG Framework
 
-**TDD 완벽 정렬**: SPEC → 테스트 → 구현 → 문서
-- `@SPEC:ID` (.moai/specs/) → `@TEST:ID` (tests/) → `@CODE:ID` (src/) → `@DOC:ID` (docs/)
+**Full TDD Alignment**: SPEC → Tests → Implementation → Documentation
+- `@SPEC:ID` (`.moai/specs/`) → `@TEST:ID` (`tests/`) → `@CODE:ID` (`src/`) → `@DOC:ID` (`docs/`)
 
-**구현 세부사항**: @CODE:ID 내부 주석 레벨
-- `@CODE:ID:API` - REST API, GraphQL 엔드포인트
-- `@CODE:ID:UI` - 컴포넌트, 뷰, 화면
-- `@CODE:ID:DATA` - 데이터 모델, 스키마, 타입
-- `@CODE:ID:DOMAIN` - 비즈니스 로직, 도메인 규칙
-- `@CODE:ID:INFRA` - 인프라, 데이터베이스, 외부 연동
+**Implementation Detail Levels**: Annotation within `@CODE:ID`
+- `@CODE:ID:API` – REST APIs, GraphQL endpoints
+- `@CODE:ID:UI` – Components, views, screens
+- `@CODE:ID:DATA` – Data models, schemas, types
+- `@CODE:ID:DOMAIN` – Business logic, domain rules
+- `@CODE:ID:INFRA` – Infrastructure, databases, integrations
 
-### TAG 추적성 관리 (코드 스캔 방식)
+### Managing TAG Traceability (Code-Scan Approach)
 
-- **검증 방법**: `/alfred:3-sync` 실행 시 `rg '@(SPEC|TEST|CODE|DOC):' -n`으로 코드 전체 스캔
-- **추적 범위**: 프로젝트 전체 소스코드 (.moai/specs/, tests/, src/, docs/)
-- **유지 주기**: 코드 변경 시점마다 실시간 검증
-- **CODE-FIRST 원칙**: TAG의 진실은 코드 자체에만 존재
+- **Verification**: Run `/alfred:3-sync`, which scans with `rg '@(SPEC|TEST|CODE|DOC):' -n`
+- **Coverage**: Full project source (`.moai/specs/`, `tests/`, `src/`, `docs/`)
+- **Cadence**: Validate whenever the code changes
+- **Code-First Principle**: TAG truth lives in the source itself
 
 ## Legacy Context
 
-### 기존 시스템 현황
+### Current System Snapshot
 
-**[현재 시스템이나 기존 자산에 대한 설명]**
+**[Describe the existing system or assets]**
 
 ```
-기존 구조/
-├── [기존 컴포넌트1]/     # [현재 상태]
-├── [기존 컴포넌트2]/     # [현재 상태]
-└── [기존 컴포넌트3]/     # [현재 상태]
+Current System/
+├── [Component 1]/     # [Current state]
+├── [Component 2]/     # [Current state]
+└── [Component 3]/     # [Current state]
 ```
 
-### 마이그레이션 고려사항
+### Migration Considerations
 
-1. **[마이그레이션 항목 1]** - [계획과 우선순위]
-2. **[마이그레이션 항목 2]** - [계획과 우선순위]
-3. **[마이그레이션 항목 3]** - [계획과 우선순위]
+1. **[Migration item 1]** – [Plan and priority]
+2. **[Migration item 2]** – [Plan and priority]
+3. **[Migration item 3]** – [Plan and priority]
 
-## TODO:STRUCTURE-001 구조 개선 계획
+## TODO:STRUCTURE-001 Structural Improvements
 
-1. **모듈 간 인터페이스 정의** - [계획 내용]
-2. **의존성 관리 전략** - [계획 내용]
-3. **확장성 확보 방안** - [계획 내용]
+1. **Define module interfaces** – [Plan details]
+2. **Dependency management strategy** – [Plan details]
+3. **Scalability roadmap** – [Plan details]
 
-## EARS 아키텍처 요구사항 작성법
+## EARS for Architectural Requirements
 
-### 구조 설계에서의 EARS 활용
+### Applying EARS to Architecture
 
-아키텍처와 모듈 설계 시 EARS 구문을 활용하여 명확한 요구사항을 정의하세요:
+Use EARS patterns to write clear architectural requirements:
 
-#### 시스템 아키텍처 EARS 예시
+#### Architectural EARS Example
 ```markdown
-### Ubiquitous Requirements (아키텍처 기본 요구사항)
-- 시스템은 계층형 아키텍처를 채택해야 한다
-- 시스템은 모듈 간 느슨한 결합을 유지해야 한다
+### Ubiquitous Requirements (Baseline Architecture)
+- The system shall adopt a layered architecture.
+- The system shall maintain loose coupling across modules.
 
-### Event-driven Requirements (이벤트 기반 구조)
-- WHEN 외부 API 호출이 실패하면, 시스템은 fallback 로직을 실행해야 한다
-- WHEN 데이터 변경 이벤트가 발생하면, 시스템은 관련 모듈에 통지해야 한다
+### Event-driven Requirements
+- WHEN an external API call fails, the system shall execute fallback logic.
+- WHEN a data change event occurs, the system shall notify dependent modules.
 
-### State-driven Requirements (상태 기반 구조)
-- WHILE 시스템이 확장 모드일 때, 새로운 모듈을 동적으로 로드할 수 있어야 한다
-- WHILE 개발 모드일 때, 시스템은 상세한 디버그 정보를 제공해야 한다
+### State-driven Requirements
+- WHILE the system operates in scale-out mode, it shall load new modules dynamically.
+- WHILE in development mode, the system shall provide verbose debug information.
 
-### Optional Features (선택적 구조)
-- WHERE 클라우드 환경이면, 시스템은 분산 캐시를 활용할 수 있다
-- WHERE 고성능이 요구되면, 시스템은 메모리 캐싱을 적용할 수 있다
+### Optional Features
+- WHERE the deployment runs in the cloud, the system may use distributed caching.
+- WHERE high performance is required, the system may apply in-memory caching.
 
-### Constraints (구조적 제약사항)
-- IF 보안 레벨이 높으면, 시스템은 모든 모듈 간 통신을 암호화해야 한다
-- 각 모듈의 복잡도는 15를 초과하지 않아야 한다
+### Constraints
+- IF the security level is elevated, the system shall encrypt all inter-module communication.
+- Each module shall keep cyclomatic complexity under 15.
 ```
 
 ---
 
-_이 구조는 `/alfred:2-build` 실행 시 TDD 구현의 가이드라인이 됩니다._
+_This structure informs the TDD implementation when `/alfred:2-run` runs._