aiwf 0.3.7 → 0.3.12

package/.aiwf/06_FEATURE_LEDGERS/active/FL002_user_authentication_system.md

@@ -1,47 +0,0 @@
-# FL002: User Authentication System
-
-## 메타데이터
-
-- **Feature ID**: FL002
-- **제목**: User Authentication System
-- **상태**: active
-- **우선순위**: medium
-- **카테고리**: feature
-- **생성일**: 2025-07-10T02:37:15.881Z
-- **업데이트**: 2025-07-10T02:37:15.881Z
-
-## 설명
-
-(설명을 추가해주세요)
-
-## 진행 상황
-
-- **진행률**: 0%
-- **시작일**: 2025-07-10
-- **예상 완료일**: TBD
-
-## 마일스톤 & 스프린트
-
-- **마일스톤**: (미지정)
-- **스프린트**: (미지정)
-
-## 태스크
-
-- [ ] 초기 설계
-- [ ] 구현
-- [ ] 테스트
-- [ ] 문서화
-
-## 기술 스택
-
-(사용할 기술 스택을 명시해주세요)
-
-## 진행 내역
-
-- [2025-07-10] Feature 생성
-
-## 관련 링크
-
-- Git 브랜치: `feature/FL002-user_authentication_system`
-- PR: (미생성)
-- 이슈: (미생성)

package/.aiwf/07_AI_PERSONAS/architect/best_practices.md

@@ -1,104 +0,0 @@
-# Architect Best Practices
-
-## System Design Best Practices
-
-### 1. Architecture Patterns
-- **Microservices**: Use for complex, scalable systems with clear bounded contexts
-- **Monolithic**: Prefer for simple to medium complexity applications
-- **Event-Driven**: Implement for loose coupling and scalability
-- **Layered Architecture**: Apply for clear separation of concerns
-- **Hexagonal Architecture**: Use for testability and technology independence
-
-### 2. Design Principles
-- **Single Responsibility**: Each component should have one reason to change
-- **Open/Closed**: Open for extension, closed for modification
-- **Dependency Inversion**: Depend on abstractions, not concretions
-- **Interface Segregation**: Many specific interfaces are better than one general
-- **DRY (Don't Repeat Yourself)**: Avoid code duplication
-
-### 3. Scalability Patterns
-- **Horizontal Scaling**: Scale out rather than up when possible
-- **Caching Strategy**: Implement multi-level caching
-- **Database Sharding**: Distribute data across multiple databases
-- **Load Balancing**: Distribute traffic across multiple instances
-- **Circuit Breaker**: Prevent cascading failures
-
-## Technology Selection
-
-### 1. Evaluation Criteria
-- **Technical Fit**: Does it solve the problem well?
-- **Team Expertise**: Can the team effectively use it?
-- **Community Support**: Is there active community and documentation?
-- **Long-term Viability**: Will it be maintained and updated?
-- **Integration**: How well does it integrate with existing systems?
-
-### 2. Decision Documentation
-- Document all technology choices
-- Explain the reasoning behind decisions
-- Include alternatives considered
-- Define success criteria
-- Plan for review and reassessment
-
-## Performance Considerations
-
-### 1. Design for Performance
-- Identify performance bottlenecks early
-- Design with caching in mind
-- Consider data access patterns
-- Plan for monitoring and observability
-- Implement graceful degradation
-
-### 2. Optimization Strategy
-- Measure before optimizing
-- Focus on the biggest impact areas
-- Consider user experience impact
-- Balance performance with maintainability
-- Document performance requirements
-
-## Security Architecture
-
-### 1. Security by Design
-- Implement defense in depth
-- Use principle of least privilege
-- Secure data in transit and at rest
-- Implement proper authentication and authorization
-- Plan for security incident response
-
-### 2. Common Security Patterns
-- **Zero Trust**: Never trust, always verify
-- **API Gateway**: Centralized security enforcement
-- **OAuth 2.0/OpenID Connect**: Standard authentication protocols
-- **Encryption**: End-to-end encryption for sensitive data
-- **Audit Logging**: Comprehensive logging for security events
-
-## Operational Excellence
-
-### 1. Monitoring and Observability
-- Implement comprehensive logging
-- Set up application metrics
-- Use distributed tracing
-- Create meaningful dashboards
-- Establish alerting thresholds
-
-### 2. Deployment Strategy
-- Use infrastructure as code
-- Implement CI/CD pipelines
-- Plan for blue-green deployments
-- Consider canary releases
-- Prepare rollback procedures
-
-## Documentation Standards
-
-### 1. Architecture Documentation
-- Create architecture decision records (ADRs)
-- Maintain system context diagrams
-- Document API contracts
-- Keep deployment guides updated
-- Maintain troubleshooting guides
-
-### 2. Communication
-- Use C4 model for system documentation
-- Create clear data flow diagrams
-- Document integration points
-- Maintain glossary of terms
-- Regular architecture reviews

package/.aiwf/07_AI_PERSONAS/architect/context_rules.md

@@ -1,46 +0,0 @@
----
-persona_name: architect
-analysis_approach: 시스템 설계 중심
-design_principles:
-  - 확장성
-  - 유지보수성
-  - 성능
-  - 모듈화
-communication_style: 구조적이고 논리적
-key_focus_areas:
-  - 시스템 아키텍처
-  - 컴포넌트 설계
-  - 기술 스택 선택
-  - 인프라 구조
----
-
-# 아키텍트 페르소나 컨텍스트
-
-## 핵심 역할
-시스템 전체 구조를 설계하고 기술적 결정을 내리는 역할을 수행합니다. 비즈니스 요구사항을 기술적 설계로 변환하고, 장기적인 시스템 진화를 고려합니다.
-
-## 분석 접근법
-- **전체 시스템 관점**: 개별 컴포넌트보다 전체 시스템의 상호작용과 통합을 우선시
-- **계층적 사고**: 시스템을 논리적 계층으로 분해하여 분석
-- **패턴 기반 설계**: 검증된 아키텍처 패턴과 베스트 프랙티스 적용
-- **트레이드오프 분석**: 각 설계 결정의 장단점을 명확히 제시
-
-## 소통 스타일
-- **다이어그램 활용**: 시스템 구조를 시각적으로 표현
-- **단계별 설명**: 복잡한 개념을 순차적으로 설명
-- **기술적 근거 제시**: 모든 결정에 대한 명확한 이유 설명
-- **대안 제시**: 여러 접근 방법과 각각의 영향도 분석
-
-## 핵심 고려사항
-1. **확장성**: 시스템이 성장할 때 어떻게 대응할 것인가?
-2. **유지보수성**: 향후 변경과 업데이트가 얼마나 쉬운가?
-3. **성능**: 응답 시간, 처리량, 리소스 사용 최적화
-4. **보안**: 시스템 전반의 보안 아키텍처
-5. **복원력**: 장애 대응 및 복구 전략
-
-## 응답 패턴
-- 시스템 개요로 시작
-- 주요 컴포넌트와 그들의 책임 설명
-- 컴포넌트 간 상호작용과 데이터 흐름 제시
-- 기술 스택과 선택 이유 설명
-- 확장 및 진화 전략 포함

package/.aiwf/07_AI_PERSONAS/architect/knowledge_base.md

@@ -1,235 +0,0 @@
-# Architect Knowledge Base
-
-## Architecture Patterns Reference
-
-### 1. Microservices Architecture
-```
-┌─────────────────┐    ┌─────────────────┐    ┌─────────────────┐
-│   User Service  │    │  Order Service  │    │Product Service  │
-│                 │    │                 │    │                 │
-│  ┌───────────┐  │    │  ┌───────────┐  │    │  ┌───────────┐  │
-│  │    API    │  │    │  │    API    │  │    │  │    API    │  │
-│  └───────────┘  │    │  └───────────┘  │    │  └───────────┘  │
-│  ┌───────────┐  │    │  ┌───────────┐  │    │  ┌───────────┐  │
-│  │ Database  │  │    │  │ Database  │  │    │  │ Database  │  │
-│  └───────────┘  │    │  └───────────┘  │    │  └───────────┘  │
-└─────────────────┘    └─────────────────┘    └─────────────────┘
-```
-
-**Use Cases**:
-- Large, complex applications
-- Independent team development
-- Different technology stacks per service
-- High scalability requirements
-
-### 2. Hexagonal Architecture
-```
-┌─────────────────────────────────────────────────────────────┐
-│                    Adapters (Ports)                        │
-│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐        │
-│  │     Web     │  │     API     │  │     CLI     │        │
-│  │  Interface  │  │  Interface  │  │  Interface  │        │
-│  └─────────────┘  └─────────────┘  └─────────────┘        │
-│         │                 │                 │              │
-│  ┌─────────────────────────────────────────────────────────┐ │
-│  │                Application Core                         │ │
-│  │  ┌─────────────────────────────────────────────────┐   │ │
-│  │  │             Business Logic                      │   │ │
-│  │  └─────────────────────────────────────────────────┘   │ │
-│  │                                                         │ │
-│  └─────────────────────────────────────────────────────────┘ │
-│         │                 │                 │              │
-│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐        │
-│  │  Database   │  │  External   │  │  Message    │        │
-│  │   Adapter   │  │   Service   │  │   Queue     │        │
-│  └─────────────┘  └─────────────┘  └─────────────┘        │
-└─────────────────────────────────────────────────────────────┘
-```
-
-### 3. Event-Driven Architecture
-```
-┌─────────────┐    ┌─────────────┐    ┌─────────────┐
-│   Service   │    │    Event    │    │   Service   │
-│      A      │───▶│    Bus      │───▶│      B      │
-└─────────────┘    └─────────────┘    └─────────────┘
-                          │
-                          ▼
-                   ┌─────────────┐
-                   │   Service   │
-                   │      C      │
-                   └─────────────┘
-```
-
-## Technology Stack Recommendations
-
-### 1. Web Applications
-```yaml
-Frontend:
-  SPA: React, Vue.js, Angular
-  SSR: Next.js, Nuxt.js, SvelteKit
-  Mobile: React Native, Flutter
-  
-Backend:
-  API: Node.js (Express, Fastify), Python (FastAPI, Django)
-  Enterprise: Java (Spring Boot), C# (.NET Core)
-  
-Database:
-  Relational: PostgreSQL, MySQL
-  NoSQL: MongoDB, Redis
-  Search: Elasticsearch
-  
-Infrastructure:
-  Container: Docker, Kubernetes
-  Cloud: AWS, Azure, Google Cloud
-  CI/CD: GitHub Actions, GitLab CI
-```
-
-### 2. Data Processing
-```yaml
-Batch Processing:
-  - Apache Spark
-  - Apache Airflow
-  - AWS Batch
-  
-Stream Processing:
-  - Apache Kafka
-  - Apache Pulsar
-  - AWS Kinesis
-  
-Analytics:
-  - Apache Superset
-  - Grafana
-  - Tableau
-```
-
-## Performance Optimization Strategies
-
-### 1. Caching Layers
-```
-┌─────────────┐    ┌─────────────┐    ┌─────────────┐
-│   Browser   │    │     CDN     │    │   Server    │
-│   Cache     │    │   Cache     │    │   Cache     │
-└─────────────┘    └─────────────┘    └─────────────┘
-       │                   │                   │
-       ▼                   ▼                   ▼
-┌─────────────┐    ┌─────────────┐    ┌─────────────┐
-│ Application │    │ Application │    │  Database   │
-│   Server    │    │   Server    │    │   Server    │
-└─────────────┘    └─────────────┘    └─────────────┘
-```
-
-### 2. Database Optimization
-- **Indexing Strategy**: Create indexes for frequent queries
-- **Query Optimization**: Use EXPLAIN plans to optimize queries
-- **Connection Pooling**: Manage database connections efficiently
-- **Read Replicas**: Distribute read operations
-- **Partitioning**: Split large tables for better performance
-
-### 3. Scalability Patterns
-```
-Load Balancer
-      │
-   ┌──┴──┐
-   │     │
-   ▼     ▼
-App     App
-Server  Server
-   │     │
-   └──┬──┘
-      │
-   Database
-```
-
-## Security Architecture Patterns
-
-### 1. Zero Trust Architecture
-```
-┌─────────────────────────────────────────────────────────────┐
-│                     Security Layer                         │
-│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐        │
-│  │ Identity &  │  │   Device    │  │   Network   │        │
-│  │   Access    │  │   Security  │  │   Security  │        │
-│  └─────────────┘  └─────────────┘  └─────────────┘        │
-└─────────────────────────────────────────────────────────────┘
-                          │
-                          ▼
-┌─────────────────────────────────────────────────────────────┐
-│                   Application Layer                        │
-│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐        │
-│  │    API      │  │    Web      │  │   Mobile    │        │
-│  │   Gateway   │  │   Portal    │  │     App     │        │
-│  └─────────────┘  └─────────────┘  └─────────────┘        │
-└─────────────────────────────────────────────────────────────┘
-```
-
-### 2. API Security
-- **Authentication**: OAuth 2.0, JWT tokens
-- **Authorization**: Role-based access control (RBAC)
-- **Rate Limiting**: Prevent abuse and DDoS
-- **Input Validation**: Sanitize all inputs
-- **HTTPS**: Encrypt all communications
-
-## Monitoring and Observability
-
-### 1. Three Pillars of Observability
-```
-┌─────────────┐    ┌─────────────┐    ┌─────────────┐
-│   Metrics   │    │    Logs     │    │   Traces    │
-│             │    │             │    │             │
-│ • CPU Usage │    │ • App Logs  │    │ • Request   │
-│ • Memory    │    │ • Error     │    │   Flow      │
-│ • Response  │    │   Logs      │    │ • Latency   │
-│   Time      │    │ • Access    │    │   Tracking  │
-│             │    │   Logs      │    │             │
-└─────────────┘    └─────────────┘    └─────────────┘
-```
-
-### 2. Alerting Strategy
-- **SLA-based Alerts**: Monitor service level agreements
-- **Anomaly Detection**: Detect unusual patterns
-- **Escalation Policies**: Define who gets notified when
-- **Runbook Integration**: Link alerts to resolution procedures
-
-## Common Anti-Patterns to Avoid
-
-### 1. Architecture Anti-Patterns
-- **Big Ball of Mud**: Lack of clear structure
-- **Spaghetti Code**: Tangled dependencies
-- **Golden Hammer**: Using one solution for everything
-- **Premature Optimization**: Optimizing before measuring
-- **Vendor Lock-in**: Over-dependence on specific vendors
-
-### 2. Design Anti-Patterns
-- **God Object**: One class doing everything
-- **Tight Coupling**: Components too dependent on each other
-- **Circular Dependencies**: Components depending on each other
-- **Interface Bloat**: Too many methods in interfaces
-- **Singleton Abuse**: Overusing singleton pattern
-
-## Migration Strategies
-
-### 1. Strangler Fig Pattern
-```
-┌─────────────────────────────────────────────────────────────┐
-│                    Legacy System                           │
-│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐        │
-│  │   Module    │  │   Module    │  │   Module    │        │
-│  │      A      │  │      B      │  │      C      │        │
-│  └─────────────┘  └─────────────┘  └─────────────┘        │
-└─────────────────────────────────────────────────────────────┘
-                          │
-                          ▼ (Gradual Migration)
-┌─────────────────────────────────────────────────────────────┐
-│                    New System                              │
-│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐        │
-│  │  Service    │  │  Service    │  │  Service    │        │
-│  │      A      │  │      B      │  │      C      │        │
-│  └─────────────┘  └─────────────┘  └─────────────┘        │
-└─────────────────────────────────────────────────────────────┘
-```
-
-### 2. Database Migration
-- **Dual Write**: Write to both old and new systems
-- **Event Sourcing**: Capture all changes as events
-- **Blue-Green Deployment**: Switch between environments
-- **Canary Releases**: Gradual rollout to users