Quality-Driven Development

Structured development methodology inspired by MoAI-ADK's TRUST 5 framework. Automatically selects TDD or DDD based on project state, enforces quality gates, and produces tested, documented code.

Core Philosophy

"바이브 코딩의 목적은 빠른 생산성이 아니라 코드 품질이다."

Logging Strategy

All code must include meaningful logs. Logs are the first line of defense for debugging production issues.

Log Levels

Log Placement Rules

반드시 로그를 넣어야 하는 곳:

• API 엔드포인트 진입 (INFO: 요청 파라미터 요약)
• 외부 서비스 호출 전/후 (INFO: 호출 대상, 응답 상태)
• 에러/예외 catch 블록 (ERROR: 에러 메시지 + 컨텍스트)
• 비즈니스 로직 분기점 (DEBUG: 어떤 분기로 갔는지)
• 상태 변경 (INFO: before → after)
• 배치/스케줄러 시작/완료 (INFO: 처리 건수, 소요 시간)

로그 작성 원칙:

• 운영에서 INFO만으로 흐름 추적이 가능해야 한다
• DEBUG는 부담 없이 자유롭게 — 운영에선 출력 안 됨
• 민감 정보(비밀번호, 토큰, 개인정보) 절대 로그에 포함 금지
• 로그 메시지에 컨텍스트 포함 (ID, 파라미터 등) — "처리 실패" ❌ → "주문 처리 실패 [orderId=123, reason=재고부족]" ✅

Workflow

Phase 0: Project Analysis

Before any coding, analyze the project:

1. Check if test framework exists (jest, vitest, pytest, go test, etc.)
2. Measure current test coverage (run coverage command if available)
3. Detect language, framework, and project structure
4. Identify logging framework (slf4j, winston, pino, logback, print/console.log etc.) — if none exists, recommend and set up one
5. Select methodology automatically:

Coverage >= 10% OR new project → TDD (default)
Coverage < 10% AND existing project → DDD

Report the analysis result and selected methodology to the user before proceeding.

Phase 1: SPEC Document

Create a SPEC document before implementation:

# SPEC-{ID}: {Title}

## Goal
One sentence describing what this change achieves.

## Acceptance Criteria
- [ ] Criterion 1 (testable)
- [ ] Criterion 2 (testable)
- [ ] Criterion 3 (testable)

## Scope
- **In scope:** What will be changed
- **Out of scope:** What will NOT be changed

## Technical Approach
Brief description of implementation strategy.

## Log Points
Key locations where logs will be added (level + message summary).

## TRUST 5 Checklist
- [ ] **Tested:** All acceptance criteria have corresponding tests
- [ ] **Readable:** Code is self-documenting with clear naming
- [ ] **Unified:** Follows existing project conventions
- [ ] **Secured:** No new vulnerabilities introduced
- [ ] **Trackable:** Changes are documented and linked to this SPEC

Phase 2A: TDD Execution (New Projects / Coverage >= 10%)

Follow RED → GREEN → REFACTOR strictly: