Brainstorming (구현 전 설계 확정)

아이디어를 자연스러운 대화로 완성된 설계로 만든 뒤에만 구현에 들어간다.

HARD GATE: 설계를 제시하고 사용자 승인을 받기 전에는 코드 작성·스캐폴딩·구현 착수 금지. "너무 단순해서 설계가 필요 없다"는 함정이다 — 단순한 프로젝트일수록 검증 안 된 가정이 재작업을 만든다. 설계는 몇 문장이어도 되지만 반드시 제시하고 승인받는다.

프로세스

1. 프로젝트 컨텍스트 파악 — 파일, 문서, 최근 커밋 확인
2. 범위 판단 — 독립적인 서브시스템 여러 개를 묶은 요청이면 세부 질문 전에 분해부터 제안. 서브 프로젝트별로 spec → plan → 구현 사이클
3. 질문은 한 번에 하나씩 — 목적, 제약, 성공 기준을 파악. 가능하면 객관식
4. 접근법 2~3개 제안 — 트레이드오프와 함께, 추천안을 먼저 제시하고 이유 설명. YAGNI 원칙으로 불필요한 기능은 모든 안에서 제거
5. 설계 제시 — 섹션별로 복잡도에 맞는 분량(단순하면 몇 문장). 아키텍처·컴포넌트·데이터 흐름·에러 처리·테스트를 다루고 섹션마다 확인받기
6. 설계 문서 저장 — {project}/docs/design-docs/[날짜]-[주제].md (기존 하네스의 execute-plans와 연결)
7. 셀프 리뷰 — TBD/placeholder, 섹션 간 모순, 중의적 요구사항, 범위 적정성 검사 후 즉시 수정
8. 사용자 스펙 검토 요청 → 승인 후 /plan 으로 구현 계획 수립

설계 원칙

• 각 유닛은 하나의 명확한 목적 + 잘 정의된 인터페이스 + 독립 테스트 가능
• 유닛마다 답할 수 있어야 함: 무엇을 하나 / 어떻게 쓰나 / 무엇에 의존하나
• 내부를 읽지 않고 역할을 이해할 수 없거나, 내부 변경이 소비자를 깨뜨리면 경계 설계가 잘못된 것
• 기존 코드베이스에서는 기존 패턴을 따르고, 현재 작업에 영향을 주는 문제만 targeted 개선 포함 (무관한 리팩토링 제안 금지)