sg-implement-minimal-changelisted

# Implement Minimal Change 요구와 안전 조건을 온전히 만족하는 가장 작은 검증된 변경을 만든다. 줄 수나 파일 수를 먼저 줄이지 말고, 문제를 이해한 뒤 불필요한 구현과 장기 소유 비용을 줄인다. ## 우선순위와 적용 경계 1. 사용자에게 약속한 결과, 저장소 지침, 권한과 공개 계약을 최소화보다 우선한다. 2. 보안, 개인정보, 신뢰 경계의 입력 검증, 데이터 손실 방지 오류 처리, 접근성과 실제 환경의 calibration을 축소하지 않는다. 3. 사용자가 명시한 기능을 YAGNI라는 이유로 거부하거나 반복해서 재논의하지 않는다. 요구 안의 선택적·추측성 범위만 근거와 함께 생략할 수 있다. 4. 아키텍처 평가·정책 검사, 서비스 역공학, dead code·미사용 의존성 정리나 문서 작성이 작업의 주목적이면 해당 전문 절차를 우선한다. 전문 Skill이 없으면 이 Skill의 범위를 억지로 넓히지 말고 필요한 분석 범위를 알린다. ## 변경 전 판단 1. 원하는 관찰 가능한 동작, 대표 실패 상태, 호환성·성능·운영 제약과 완료 조건을 확인한다. 안전하게 추론할 수 없는 선택이 결과를 바꾸면 구현 전에 묻는다. 2. 관련 entrypoint, 실제 호출·데이터 흐름, caller, 공개 표면과 가까운 테스트를 읽는다. 작은 diff를 위해 이해 범위를 줄이지 않는다. 3. 저장소에서 같은 문제를 해결한 helper, type, pattern과 이미 신뢰하는 품질 관문을 먼저 찾는다. 4. 다음 후보 중 실제 요구를 완전히 만족하는 것을 비교한다. - 새 구현 없이 기존 동작이나 설정으로 해결 - 저장소의 기존 구현 재사용 - 표준 라이브러리 또는 native platform 기능 사용 - 이미 설치된 의존성 사용 - 필요한 최소 custom code 작성 - 복잡한 공통 기능에서 직접 구현보다 총복잡도와 안정성을 개선하는 유지보수되는 새 라이브러리 사용 5. 둘 이상의 후보가 충분하면 정확성, 안전, 공개 표면, 변경 파일·의존성, 가독성, 검증 가능성과 장기 소유 비용을 비교해 가장 작은 변경 표면을 고른다. 한 줄 구현이나 최소 LOC는 이 조건들이 같을 때만 tie-breaker로 사용한다. 후보 탐색을 별도 연구 프로젝트로 만들지 않는다. 관련 경로, 기존 manifest와 의존성의 문서·타입에서 판단할 근거가 확보되면 선택하고 진행한다. ## 구현 - 결함이 공유 지점에서 발생하면 caller마다 방어 코드를 더하지 말고 root cause를 한 번 고친다. 공유 원인이 없는데 새 공통화를 만들지는 않는다. - 두 번째 실제 사용 사례가 없는 interface·factory·설정, 미래를 위한 scaffold, 쓰이지 않는 호환 계층·fallback과 불필요한 간접 계층을 추가하지 않는다. - 가장 적은 수의 응집된 파일에서 저장소의 기존 구조와 명명 관례를 따른다. 짧지만 숨은 동작이 있는 표현보다 평범하고 읽을 수 있는 구현을 택한다. - 새 의존성을 고