sg-review-archlisted

# Assess Software Architecture 현재 구조의 사실과 목표 구조에 대한 판단을 분리한다. 인기 있는 패턴을 정답으로 두지 말고 제품 콘셉트, 품질 목표와 예상 변화에 맞는 구조인지 평가한다. 전체 코드를 순서대로 읽지 말고 기계 분석으로 범위를 좁힌다. ## 시작 1. 소스 저장소 루트, 프로젝트·manifest 루트, 배포 단위, 분석 루트, package root, revision, dirty 상태와 접근 제한을 구분해 기록한다. 같은 경로가 여러 의미를 가져도 용어를 합치지 않는다. 2. 제품 가치와 actor, 초기 제품 콘셉트, 중요한 품질 목표 최대 3개, 대표 변경 시나리오를 확인한다. 자료가 없으면 추론과 질문을 분리해 기록한다. 3. 동일 revision의 `docs/reverse-engineering/` 자료가 있으면 증거로 재사용하되 현재 source digest 또는 commit과 다르면 갱신 전까지 stale로 표시한다. 4. 평가 기준이 필요하면 [평가 루브릭](references/assessment-rubric.md)을 읽는다. 보고서를 만들거나 갱신하기 전에는 [문서 계약](references/document-contract.md)을 읽는다. ## 기계 분석으로 읽기 범위 줄이기 1. 임시 디렉터리를 만든다. 2. Windows에서는 `scripts/analyze-architecture.ps1 -Root <repo> -Output <temp>/architecture-facts.json -EvidenceOutput <target>/docs/architecture-evidence.md`, macOS·Linux에서는 `scripts/analyze-architecture.sh --root <repo> --output <temp>/architecture-facts.json --evidence-output <target>/docs/architecture-evidence.md`를 실행한다. 3. wrapper는 sibling `sg-reverse-engineer-service`의 `discover`, 구조 요약기와 결정적 Markdown renderer를 차례로 실행한다. 의존 Skill이나 런타임이 없으면 자동 설치하지 않는다. 4. 저장할 기계 증거 Markdown의 snapshot, capability, scope, diagnostics, boundary, cycle, change coupling과 `read_set`을 먼저 검토한다. 원시 module·edge 전체나 임시 JSON을 대화 컨텍스트에 복사하지 않는다. 5. manifest, README, ADR과 `read_set`의 파일·symbol 범위만 우선 읽는다. package 하위 경로가 root면 `ancestor-context-discovery`가 제시한 가장 가까운 manifest·README·tests도 제품 context로만 확인하고 구조 graph 범위와 섞지 않는다. 경계가 불명확할 때만 다음 후보를 추가한다.