orchestrating-myungjoo-developmentlisted

# myungjoo.dev 개발 오케스트레이션 ## 1. 목적과 핵심 원칙 개발 요청을 위험에 맞는 역할, 승인, 증거로 연결한다. 코드 양이나 파일 수가 아니라 난이도·범위·위험도의 최댓값으로 `lightweight`, `standard`, `high-risk`를 정한다. 보안, 외부 계약, 데이터, CI·배포, 전역 장애 영향은 변경량과 무관하게 `high-risk`다. 상세 판정과 역할은 [routing matrix](references/routing-matrix.md), 증거는 [quality gates](references/quality-gates.md), 역할 출력은 [handoff contracts](references/handoff-contracts.md)를 따른다. ## 2. 질문·상태 확인과 개발 작업 구분 설명, 현황 조회, 읽기 전용 보고처럼 변경 의도가 없는 요청은 전체 개발 workflow에서 제외한다. 파일·코드·설정·데이터·화면·GitHub 상태를 바꾸거나 변경안을 준비하면 개발 작업이다. 진단 요청은 읽기 전용으로 원인과 근거까지만 제시하며, 수정 권한을 추론하지 않는다. 작은 후속 작업과 리뷰 수정은 같은 세션에서 이어간다. 독립 마일스톤 완료, 이슈·저장소 전환 또는 맥락 품질 저하가 예상되면 새 세션을 제안하고 사용자 승인 후 handoff를 만든다. ## 3. 등급 판정과 세 번의 재판정 동일한 공식을 `요청 접수 시`, `구현 직전`, `리뷰 직전`에 반드시 다시 적용하고 판정 근거를 남긴다. 보안, 외부 계약, 데이터, CI·배포, 전역 장애 영향이나 승인된 완료 조건 밖의 범위를 발견하면 즉시 멈춘다. 이전 등���과 승인은 새 범위를 덮��� 않는다. 더 높은 등급으로 재판정하고 사용자에게 영향, 선택지, 권장안, 승인 경계를 다시 제시한다. ## 4. 최소 역할 라우팅 `lightweight`는 작업 오케스트레이터가 직접 처리하는 것을 기본으로 하고 필요할 때만 단일 Frontend Developer를 사용한다. `standard`는 Frontend Developer와 독립 Code Reviewer를 기본으로 한다. 나머지 역할은 작업의 실제 조건이 있을 때만 추가한다. `high-risk`는 전담 QA Engineer와 독립 Code Reviewer, 조건별 전문 역할과 복구 근거를 유지한다. 상세 조건은 [routing matrix](references/routing-matrix.md)를 따른다. ## 5. Superpowers 연결 **REQUIRED SUB-SKILL:** 기능·동작·설계 변경 전 `superpowers:brainstorming` **REQUIRED SUB-SKILL:** 기능·버그 ��현 전 `superpowers:test-driven-development` **REQUIRED SUB-SKILL:** 완료 주장 전 `superpowers:verification-before-completion` 버그나 예기치 않은 실패는 `superpowers