sg-prune-build-bloatlisted

# Prune Build Bloat 새 분석기를 도입하는 것부터 시작하지 말고, 저장소가 이미 신뢰하는 검사와 빌드 흐름을 찾아 부족한 부분만 보완한다. 정적 분석 결과를 사용 사실로 단정하지 말고 공개 계약과 동적 경계를 확인한 뒤 작은 단위로 정리한다. ## 프로젝트 판별 1. 대상 root, revision, dirty 상태와 사용자 변경을 확인한다. 기존 변경을 덮어쓰거나 정리 범위에 섞지 않는다. 2. `pyproject.toml`, Python lockfile, `requirements*.txt`, `package.json`, JavaScript lockfile, `tsconfig*.json`과 실제 소스 분포를 함께 조사한다. manifest가 있는 각 workspace를 독립적인 분석 단위로 기록한다. 3. Git이 무시하는 경로와 생성물, vendor, cache, virtual environment, dependency 설치 디렉터리, build 출력을 언어 판별과 후보 집계에서 제외한다. 4. Python이 있으면 [Python 연결 지침](references/python.md)을 읽고, JavaScript 또는 TypeScript가 있으면 [JavaScript/TypeScript 연결 지침](references/javascript-typescript.md)을 읽는다. 혼합 저장소에서는 둘 다 읽되 workspace 경계를 유지한다. ## 기존 관문 조사와 브리핑 1. package script, task runner, lint, typecheck, dependency 검사, dead-code 검사, pre-commit과 로컬 build 진입점을 조사한다. 이름만 보고 충분하다고 판단하지 말고 실제 명령, 설정, 대상 경로와 workspace coverage를 확인한다. 2. manifest, lockfile, 설정과 프로젝트 환경에서 사용 가능한 실행 파일을 대조해 설치된 도구만 식별한다. 도구 탐색을 위해 프로젝트의 install 또는 build script를 실행하지 않는다. 3. 변경 전에 다음을 브리핑한다. - 감지한 언어, framework, workspace, package manager와 build 진입점 - 기존 검사, 실행 위치, 대상 범위와 빠진 범위 - 실행할 진단 명령, 중복 검사와 미설치 도구 - 동적 import, plugin, reflection, code generation, framework entrypoint와 공개 API 등 오탐 위험 4. 일반적인 보수적 정리는 브리핑 뒤 계속한다. 도구 설치, 공개 계약 제거, 동적 사용 여부가 불명확한 변경은 근거와 선택지를 제시하고 승인을 기다린다. ## 진단과 분류 1. 저장소가 이미 제공하는 명령과 설정을 먼저 사용한다. 같은 범위를 검사하는 새 도구나 병렬 관문을 추가하지 않는다. 2. 모든 검사를 수정 없는 진단 모드로 먼저 실행하고 명령, 도구 버전, 작업 디렉터리, 종료 코드와 검사 범위를 기록한다