moai-adk 0.3.0__py3-none-any.whl

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

@@ -0,0 +1,121 @@
+---
+id: PRODUCT-001
+version: 0.1.0
+status: active
+created: 2025-10-01
+updated: 2025-10-01
+authors: ["@project-owner"]
+---
+
+# {{PROJECT_NAME}} Product Definition
+
+## HISTORY
+
+### v0.1.0 (2025-10-01)
+- **INITIAL**: 프로젝트 제품 정의 문서 작성
+- **AUTHOR**: @project-owner
+- **SECTIONS**: Mission, User, Problem, Strategy, Success, Legacy
+
+---
+
+## @DOC:MISSION-001 핵심 미션
+
+**[프로젝트의 핵심 미션과 목표를 정의하세요]**
+
+### 핵심 가치 제안
+
+[이 프로젝트가 제공하는 핵심 가치를 설명하세요]
+
+## @SPEC:USER-001 주요 사용자층
+
+### 1차 사용자
+- **대상**: [주요 사용자층을 정의하세요]
+- **핵심 니즈**: [사용자가 해결하고자 하는 문제]
+- **핵심 시나리오**: [주요 사용 시나리오를 설명하세요]
+
+### 2차 사용자 (선택사항)
+- **대상**: [추가 사용자층이 있다면 정의하세요]
+- **핵심 니즈**: [추가 사용자의 요구사항]
+
+## @SPEC:PROBLEM-001 해결하는 핵심 문제
+
+### 우선순위 높음
+1. [해결하려는 주요 문제 1]
+2. [해결하려는 주요 문제 2]
+3. [해결하려는 주요 문제 3]
+
+### 우선순위 중간
+- [중요도가 중간인 문제들]
+
+### 현재 실패 사례들
+- [기존 솔루션의 한계나 실패 사례들]
+
+## @DOC:STRATEGY-001 차별점 및 강점
+
+### 경쟁 솔루션 대비 강점
+1. [주요 차별점 1]
+   - **발휘 시나리오**: [어떤 상황에서 이 강점이 드러나는지]
+
+2. [주요 차별점 2]
+   - **발휘 시나리오**: [구체적인 활용 시나리오]
+
+## @SPEC:SUCCESS-001 성공 지표
+
+### 즉시 측정 가능한 KPI
+1. [측정 지표 1]
+   - **베이스라인**: [목표값과 측정 방법]
+
+2. [측정 지표 2]
+   - **베이스라인**: [목표값과 측정 방법]
+
+### 측정 주기
+- **일간**: [일단위로 측정할 지표]
+- **주간**: [주단위로 측정할 지표]
+- **월간**: [월단위로 측정할 지표]
+
+## Legacy Context
+
+### 기존 자산 요약
+- [활용할 기존 자산이나 리소스]
+- [참고할 기존 프로젝트나 경험]
+
+## TODO:SPEC-BACKLOG-001 다음 단계 SPEC 후보
+
+1. **SPEC-001**: [첫 번째 구현할 기능]
+2. **SPEC-002**: [두 번째 구현할 기능]
+3. **SPEC-003**: [세 번째 구현할 기능]
+
+## EARS 요구사항 작성 가이드
+
+### EARS (Easy Approach to Requirements Syntax)
+
+SPEC 작성 시 다음 EARS 구문을 활용하여 체계적인 요구사항을 작성하세요:
+
+#### EARS 구문 형식
+1. **Ubiquitous Requirements**: 시스템은 [기능]을 제공해야 한다
+2. **Event-driven Requirements**: WHEN [조건]이면, 시스템은 [동작]해야 한다
+3. **State-driven Requirements**: WHILE [상태]일 때, 시스템은 [동작]해야 한다
+4. **Optional Features**: WHERE [조건]이면, 시스템은 [동작]할 수 있다
+5. **Constraints**: IF [조건]이면, 시스템은 [제약]해야 한다
+
+#### 적용 예시
+```markdown
+### Ubiquitous Requirements (기본 기능)
+- 시스템은 사용자 관리 기능을 제공해야 한다
+
+### Event-driven Requirements (이벤트 기반)
+- WHEN 사용자가 가입하면, 시스템은 환영 이메일을 발송해야 한다
+
+### State-driven Requirements (상태 기반)
+- WHILE 사용자가 로그인된 상태일 때, 시스템은 개인화된 대시보드를 표시해야 한다
+
+### Optional Features (선택적 기능)
+- WHERE 프리미엄 계정이면, 시스템은 고급 기능을 제공할 수 있다
+
+### Constraints (제약사항)
+- IF 계정이 잠긴 상태이면, 시스템은 로그인을 거부해야 한다
+```
+
+---
+
+_이 문서는 `/alfred:1-spec` 실행 시 SPEC 생성의 기준이 됩니다._

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

@@ -0,0 +1,150 @@
+---
+id: STRUCTURE-001
+version: 0.1.0
+status: active
+created: 2025-10-01
+updated: 2025-10-01
+authors: ["@architect"]
+---
+
+# {{PROJECT_NAME}} Structure Design
+
+## HISTORY
+
+### v0.1.0 (2025-10-01)
+- **INITIAL**: 프로젝트 구조 설계 문서 작성
+- **AUTHOR**: @architect
+- **SECTIONS**: Architecture, Modules, Integration, Traceability
+
+---
+
+## @DOC:ARCHITECTURE-001 시스템 아키텍처
+
+### 아키텍처 전략
+
+**[프로젝트의 전체 아키텍처 접근법을 설명하세요]**
+
+```
+Project Architecture
+├── [Layer 1]          # [역할 설명]
+├── [Layer 2]          # [역할 설명]
+├── [Layer 3]          # [역할 설명]
+└── [Layer 4]          # [역할 설명]
+```
+
+**선택 이유**: [아키텍처 선택의 근거와 트레이드오프]
+
+## @DOC:MODULES-001 모듈별 책임 구분
+
+### 1. [주요 모듈 1]
+
+- **책임**: [모듈의 주요 책임]
+- **입력**: [처리하는 입력 데이터]
+- **처리**: [수행하는 주요 처리 과정]
+- **출력**: [생성하는 결과물]
+
+| 컴포넌트 | 역할 | 주요 기능 |
+|----------|------|-----------|
+| [컴포넌트1] | [역할] | [기능 목록] |
+| [컴포넌트2] | [역할] | [기능 목록] |
+
+### 2. [주요 모듈 2]
+
+- **책임**: [모듈의 주요 책임]
+- **입력**: [처리하는 입력 데이터]
+- **처리**: [수행하는 주요 처리 과정]
+- **출력**: [생성하는 결과물]
+
+## @DOC:INTEGRATION-001 외부 시스템 통합
+
+### [외부 시스템 1] 연동
+
+- **인증 방식**: [인증 방법]
+- **데이터 교환**: [데이터 형식과 프로토콜]
+- **장애 시 대체**: [fallback 전략]
+- **위험도**: [리스크 수준과 완화 방안]
+
+### [외부 시스템 2] 연동
+
+- **용도**: [사용 목적]
+- **의존성 수준**: [의존도와 대안]
+- **성능 요구사항**: [응답 시간, 처리량 등]
+
+## @DOC:TRACEABILITY-001 추적성 전략
+
+### TAG 체계 적용
+
+**TDD 완벽 정렬**: SPEC → 테스트 → 구현 → 문서
+- `@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` - 인프라, 데이터베이스, 외부 연동
+
+### TAG 추적성 관리 (코드 스캔 방식)
+
+- **검증 방법**: `/alfred:3-sync` 실행 시 `rg '@(SPEC|TEST|CODE|DOC):' -n`으로 코드 전체 스캔
+- **추적 범위**: 프로젝트 전체 소스코드 (.moai/specs/, tests/, src/, docs/)
+- **유지 주기**: 코드 변경 시점마다 실시간 검증
+- **CODE-FIRST 원칙**: TAG의 진실은 코드 자체에만 존재
+
+## Legacy Context
+
+### 기존 시스템 현황
+
+**[현재 시스템이나 기존 자산에 대한 설명]**
+
+```
+기존 구조/
+├── [기존 컴포넌트1]/     # [현재 상태]
+├── [기존 컴포넌트2]/     # [현재 상태]
+└── [기존 컴포넌트3]/     # [현재 상태]
+```
+
+### 마이그레이션 고려사항
+
+1. **[마이그레이션 항목 1]** - [계획과 우선순위]
+2. **[마이그레이션 항목 2]** - [계획과 우선순위]
+3. **[마이그레이션 항목 3]** - [계획과 우선순위]
+
+## TODO:STRUCTURE-001 구조 개선 계획
+
+1. **모듈 간 인터페이스 정의** - [계획 내용]
+2. **의존성 관리 전략** - [계획 내용]
+3. **확장성 확보 방안** - [계획 내용]
+
+## EARS 아키텍처 요구사항 작성법
+
+### 구조 설계에서의 EARS 활용
+
+아키텍처와 모듈 설계 시 EARS 구문을 활용하여 명확한 요구사항을 정의하세요:
+
+#### 시스템 아키텍처 EARS 예시
+```markdown
+### Ubiquitous Requirements (아키텍처 기본 요구사항)
+- 시스템은 계층형 아키텍처를 채택해야 한다
+- 시스템은 모듈 간 느슨한 결합을 유지해야 한다
+
+### Event-driven Requirements (이벤트 기반 구조)
+- WHEN 외부 API 호출이 실패하면, 시스템은 fallback 로직을 실행해야 한다
+- WHEN 데이터 변경 이벤트가 발생하면, 시스템은 관련 모듈에 통지해야 한다
+
+### State-driven Requirements (상태 기반 구조)
+- WHILE 시스템이 확장 모드일 때, 새로운 모듈을 동적으로 로드할 수 있어야 한다
+- WHILE 개발 모드일 때, 시스템은 상세한 디버그 정보를 제공해야 한다
+
+### Optional Features (선택적 구조)
+- WHERE 클라우드 환경이면, 시스템은 분산 캐시를 활용할 수 있다
+- WHERE 고성능이 요구되면, 시스템은 메모리 캐싱을 적용할 수 있다
+
+### Constraints (구조적 제약사항)
+- IF 보안 레벨이 높으면, 시스템은 모든 모듈 간 통신을 암호화해야 한다
+- 각 모듈의 복잡도는 15를 초과하지 않아야 한다
+```
+
+---
+
+_이 구조는 `/alfred:2-build` 실행 시 TDD 구현의 가이드라인이 됩니다._

moai_adk/templates/.moai/project/tech.md

@@ -0,0 +1,221 @@
+---
+id: TECH-001
+version: 0.1.0
+status: active
+created: 2025-10-01
+updated: 2025-10-01
+authors: ["@tech-lead"]
+---
+
+# {{PROJECT_NAME}} Technology Stack
+
+## HISTORY
+
+### v0.1.0 (2025-10-01)
+- **INITIAL**: 프로젝트 기술 스택 문서 작성
+- **AUTHOR**: @tech-lead
+- **SECTIONS**: Stack, Framework, Quality, Security, Deploy
+
+---
+
+## @DOC:STACK-001 언어 & 런타임
+
+### 주 언어 선택
+
+- **언어**: [선택한 주 언어]
+- **버전**: [지원 버전 범위]
+- **선택 이유**: [선택 근거와 트레이드오프]
+- **패키지 매니저**: [사용할 패키지 매니저]
+
+### 멀티 플랫폼 지원
+
+| 플랫폼 | 지원 상태 | 검증 도구 | 주요 제약 |
+|--------|-----------|-----------|-----------|
+| **Windows** | [지원여부] | [검증방법] | [제약사항] |
+| **macOS** | [지원여부] | [검증방법] | [제약사항] |
+| **Linux** | [지원여부] | [검증방법] | [제약사항] |
+
+## @DOC:FRAMEWORK-001 핵심 프레임워크 & 라이브러리
+
+### 1. 주요 의존성
+
+```json
+{
+  "dependencies": {
+    "[라이브러리1]": "[버전]",
+    "[라이브러리2]": "[버전]",
+    "[라이브러리3]": "[버전]"
+  }
+}
+```
+
+### 2. 개발 도구
+
+```json
+{
+  "devDependencies": {
+    "[개발도구1]": "[버전]",
+    "[개발도구2]": "[버전]",
+    "[개발도구3]": "[버전]"
+  }
+}
+```
+
+### 3. 빌드 시스템
+
+- **빌드 도구**: [선택한 빌드 도구]
+- **번들링**: [번들러와 설정]
+- **타겟**: [빌드 타겟 (브라우저, Node.js 등)]
+- **성능 목표**: [빌드 시간 목표]
+
+## @DOC:QUALITY-001 품질 게이트 & 정책
+
+### 테스트 커버리지
+
+- **목표**: [커버리지 목표 %]
+- **측정 도구**: [사용할 도구]
+- **실패 시 대응**: [커버리지 미달 시 처리]
+
+### 정적 분석
+
+| 도구 | 역할 | 설정 파일 | 실패 시 조치 |
+|------|------|-----------|--------------|
+| [린터] | [역할] | [설정파일] | [조치방법] |
+| [포매터] | [역할] | [설정파일] | [조치방법] |
+| [타입체커] | [역할] | [설정파일] | [조치방법] |
+
+### 자동화 스크립트
+
+```bash
+# 품질 검사 파이프라인
+[테스트명령어]                    # 테스트 실행
+[린트명령어]                     # 코드 품질 검사
+[타입체크명령어]                 # 타입 검증
+[빌드명령어]                     # 빌드 검증
+```
+
+## @DOC:SECURITY-001 보안 정책 & 운영
+
+### 비밀 관리
+
+- **정책**: [비밀 관리 방식]
+- **도구**: [사용할 도구나 서비스]
+- **검증**: [자동 검증 방법]
+
+### 의존성 보안
+
+```json
+{
+  "security": {
+    "audit_tool": "[보안감사도구]",
+    "update_policy": "[업데이트정책]",
+    "vulnerability_threshold": "[허용수준]"
+  }
+}
+```
+
+### 로깅 정책
+
+- **로그 수준**: [로그 레벨 정의]
+- **민감정보 마스킹**: [마스킹 규칙]
+- **보존 정책**: [로그 보존 기간]
+
+## @DOC:DEPLOY-001 배포 채널 & 전략
+
+### 1. 배포 채널
+
+- **주 채널**: [주요 배포 경로]
+- **릴리스 절차**: [배포 프로세스]
+- **버전 정책**: [버전 관리 전략]
+- **rollback 전략**: [롤백 방법]
+
+### 2. 개발 설치
+
+```bash
+# 개발자 모드 설정
+[로컬설치명령어]
+[의존성설치명령어]
+[개발환경구축명령어]
+```
+
+### 3. CI/CD 파이프라인
+
+| 단계 | 목적 | 사용 도구 | 성공 조건 |
+|------|------|-----------|-----------|
+| [단계1] | [목적] | [도구] | [조건] |
+| [단계2] | [목적] | [도구] | [조건] |
+| [단계3] | [목적] | [도구] | [조건] |
+
+## 환경별 설정
+
+### 개발 환경 (`dev`)
+
+```bash
+export PROJECT_MODE=development
+export LOG_LEVEL=debug
+[개발환경명령어]
+```
+
+### 테스트 환경 (`test`)
+
+```bash
+export PROJECT_MODE=test
+export LOG_LEVEL=info
+[테스트환경명령어]
+```
+
+### 프로덕션 환경 (`production`)
+
+```bash
+export PROJECT_MODE=production
+export LOG_LEVEL=warning
+[프로덕션명령어]
+```
+
+## @CODE:TECH-DEBT-001 기술 부채 관리
+
+### 현재 기술 부채
+
+1. **[기술부채1]** - [설명과 우선순위]
+2. **[기술부채2]** - [설명과 우선순위]
+3. **[기술부채3]** - [설명과 우선순위]
+
+### 개선 계획
+
+- **단기 (1개월)**: [즉시 해결할 항목]
+- **중기 (3개월)**: [점진적 개선 항목]
+- **장기 (6개월+)**: [장기적 업그레이드 계획]
+
+## EARS 기술 요구사항 작성법
+
+### 기술 스택에서의 EARS 활용
+
+기술적 의사결정과 품질 게이트 설정 시 EARS 구문을 활용하여 명확한 기술 요구사항을 정의하세요:
+
+#### 기술 스택 EARS 예시
+```markdown
+### Ubiquitous Requirements (기본 기술 요구사항)
+- 시스템은 TypeScript 타입 안전성을 보장해야 한다
+- 시스템은 크로스 플랫폼 호환성을 제공해야 한다
+
+### Event-driven Requirements (이벤트 기반 기술)
+- WHEN 코드가 커밋되면, 시스템은 자동으로 테스트를 실행해야 한다
+- WHEN 빌드가 실패하면, 시스템은 개발자에게 즉시 알림을 보내야 한다
+
+### State-driven Requirements (상태 기반 기술)
+- WHILE 개발 모드일 때, 시스템은 hot-reload를 제공해야 한다
+- WHILE 프로덕션 모드일 때, 시스템은 최적화된 빌드를 생성해야 한다
+
+### Optional Features (선택적 기술)
+- WHERE Docker 환경이면, 시스템은 컨테이너 기반 배포를 지원할 수 있다
+- WHERE CI/CD가 구성되면, 시스템은 자동 배포를 수행할 수 있다
+
+### Constraints (기술적 제약사항)
+- IF 의존성에 보안 취약점이 발견되면, 시스템은 빌드를 중단해야 한다
+- 테스트 커버리지는 85% 이상을 유지해야 한다
+- 빌드 시간은 5분을 초과하지 않아야 한다
+```
+
+---
+
+_이 기술 스택은 `/alfred:2-build` 실행 시 TDD 도구 선택과 품질 게이트 적용의 기준이 됩니다._