project-inceptionlisted

# project-inception — 아이디어를 설계 산출물로 새 프로젝트(또는 새 기능 영역)를 시작할 때, 아이디어를 ocul-pm 파일 체계에 **그대로 물리는** 4종 산출물로 바꿉니다. 성공 기준은 문서를 "만드는 것"이 아니라 — **기존 도구가 무수정으로 소비하는 것**입니다 (discussion→플래너 승격, EVALS→회고 추이, rules→에이전트 자동 로드). ## STAGE 0 — 문제 파악 (리서치 방향을 정할 만큼만) `.oculpm/` 이 없는 새 저장소라면 먼저 사용자에게 **"이 프로젝트를 ocul-pm 으로 추적할까요?"** 를 물어보고, 동의를 받으면 `project_init` 도구(confirm=true)로 초기화합니다 — 동의 없이/선제적으로 호출하지 않습니다. 도구가 없으면 ocul-pm 앱에서 프로젝트 추가를 안내하세요. **정보가 부족한 채 계획을 지어내지 마세요.** 단, 여기서는 리서치의 방향을 정하는 데 필요한 최소만 묻습니다 — 문제(누구의 어떤 문제), 완성의 정의(첫 데모 한 장면), 비목표, 플랫폼·강한 제약(기한·오프라인·보안). 아이디어에 이미 담긴 것은 다시 묻지 않습니다. 답을 받아 `.oculpm/agents/discussion-spec.md` 규격대로 `.oculpm/discussion/<slug>/discussion.md` 를 만들고 `## 문제 정의` 를 채웁니다. ## STAGE 1 — 환경 탐색 (웹 리서치) 사용자에게 더 묻기 **전에**, 웹 검색(WebSearch/WebFetch)으로 환경을 직접 조사합니다. 문제에 맞는 후보 스택 2~3개에 대해: - 현재 안정 버전과 권장 조합 (프레임워크 + 빌드 도구 + 테스트 러너) - 공��� 스캐폴드 명령·battle-tested 보일러플레이트 - 해당 도메인의 표준 라이브러리·베스트 프랙티스·흔한 함정 - 필요한 개발 환경 (런타임 버전, 패키지 매니저, 필수 CLI) 조사 결과를 discussion 의 `### 방안 {#opt-id}` 후보안에 **버전·출처와 함께** 기록합니다. 기억 속 버전을 단정하지 말 것 — 검색으로 확인한 것만 적습니다. ## STAGE 2 — 대화로 최적 사양 확정 리서치 근거를 들고 사용자와 대화해 사양을 함께 확정합니다. 질문은 기능 나열이 아니라 **제품 렌즈**로 팝니다 — 누가 쓰는가, 어떤 가치 가설인가, 안 만들면 사용자는 뭘 하는가(비사용 대안), 성공을 무엇으로 알아보는가. 남은 미결(선호 언어·프레임워크, 규모, 비용 허용치, 기존 자산)을 **리서치가 뒷받침하는 객관식**으로 한 번에 묻습니다 — "무엇을 쓸까요?"가 아니라 "A(버전·근거) vs B(버전·근거), 이 상황엔 A 추천"처럼. 모호한 답은 재질문하고, 추측으로 메꾸지 않습니다. 사용자가 방안을 고르면 `## 결론` 을 쓰고 status 를 resolved 로. **증거 게이트**: 결론·계획의 모든 주장에는 근거(조사 출처·사용자 답변·측정)를 병기합니다 — 근거 없는 수식어("