Identify Changes:

• Run git status to see the current state.
• Run git diff --name-only (or git diff --cached --name-only if changes are staged) to get the list of modified files.
• Focus on React components and logic files (.tsx, .ts, .jsx, .js).

Analyze Code (adaptive parallelism):

변경 파일 수에 따른 분석 전략:

3개 이하: 순차 분석 (기존 방식)

각 파일을 직접 git diff로 검사하고 Scorecard 프레임워크에 따라 평가합니다.

4개 이상: 병렬 분석

2-A: 파일 그룹화 변경된 파일들을 디렉토리/기능 영역별로 그룹화합니다:

• 같은 디렉토리의 파일들 → 하나의 그룹
• 관련 컴포넌트 + 훅 + 타입 → 하나의 그룹
• 독립적인 파일 → 개별 그룹

2-B: 병렬 분석 각 그룹을 Task sub-agent로 동시 분석합니다:

Task call:
  subagent_type: "general-purpose"
  model: "sonnet"
  description: "Analyze code quality for [그룹명]"
  run_in_background: true
  prompt: |
    You are a React Clean Code Inspector. Analyze the following files
    for code quality using the React Clean Code Scorecard framework.

    Files to analyze: [파일 목록]

    Run `git diff -- [파일]` for each file to see the changes.

    Evaluate strictly based on these metrics:
    - Cyclomatic Complexity (CC): branch count in JSX, nested ternaries
    - Component Responsibility Score (CRS): LoC + CC + State Count + Dependency Count
    - Cohesion (LCOM4): hook and state connectivity
    - Interface Quality: props count, boolean props, naming conventions
    - State Architecture: colocation, global state density

    For each file, provide:
    1. Per-metric scores with measured values
    2. Status (양호/주의/위험) for each metric
    3. Specific recommendations

    Output as structured markdown with the Scorecard table format.

모든 그룹 분석 Task가 완료될 때까지 대기한 후 결과를 수집합니다.

2-C: 결과 통합 오케스트레이터가 모든 그룹의 분석 결과를 통합하여 전체 Scorecard를 생성합니다:

• 그룹별 결과를 병합
• 크로스-파일 이슈 식별 (그룹 간 결합도, 공통 패턴 위반 등)
• 전체 종합 점수 산출

CRITICAL: You must evaluate the code strictly based on the “React Clean Code Scorecard” framework provided below. Do not use generic “clean code” advice; use these specific metrics.

<FRAMEWORK_START>

리액트 애플리케이션의 아키텍처 건전성 및 클린 코드 품질 평가를 위한 정량적 지표 프레임워크

1. 서론

주관적인 “클린 코드”가 아닌, 정량적이고 객관적인 엔지니어링 지표로 평가합니다.

2. 구조적 복잡도 (Structural Complexity)

• 순환 복잡도 (CC): 조건부 렌더링 경로, 분기 수 측정.
  • JSX 내 삼항 연산자 중첩 등 분기 폭발 확인.
  • 점수: 110(안전), 1120(주의), 21~50(위험), >50(불가).
• 인지 복잡도: 중첩된 훅/콜백, JSX 깊이(max-depth > 3~4 주의), 의존성 배열 크기(>5 위험).

3. 컴포넌트 책임 점수 (CRS)

• CRS = w1(LoC) + w2(CC) + w3(SC) + w4(DC)
• Line of Code (LoC): >200줄 위험, 100줄 이내 권장.
• State Count (SC): useState 개수. 03(건강), 46(주의), >6(위험).
• Dependency Count (DC): import 개수. >10개 주의.
• CRS ê²°ê³¼: <50(Atomic), 50-100(Boundary), >100(God Component – Refactor Alert).

4. 응집도(Cohesion)와 결합도(Coupling)

• Props Drilling: Depth > 3 이면 불필요한 결합.
• LCOM4 (React Hook Cohesion): 내부 상태와 메서드(Effect/Callback)간의 연결 그래프 분석.
  • LCOM4 > 1 이면 로직 분리 필요 (커스텀 훅 등으로).

5. 컴포넌트 인터페이스 품질

• Props 개수: <5(이상적), 5~7(허용), >7(Code Smell).
• Boolean Props: 다수의 boolean 대신 Enum/Status 문자열 사용 권장.
• Naming: on 접두사(Props) / handle 접두사(Implementation) 일관성.

6. 정적 분석 지표 (ESLint)

• react-hooks/rules-of-hooks: 0 위반
• max-lines-per-function: < 100
• no-console: 0 위반
• TypeScript noImplicitAny: 0%

7. 테스트 가능성 (Mutation Score)

• 비즈니스 로직 훅/유틸리티의 경우 Mutation Score > 80% 목표.

8. 상태 아키텍처

• State Colocation: 상태가 사용되는 곳과 얼마나 가까운가.
• Global State Density: ê¼­ 필요한 전역 상태인지 확인.

9. 종합 스코어카드

평가 결과는 아래 표 형식을 포함하여 정리해야 합니다.

<FRAMEWORK_END>

Generate Report:

• Create a file named clean-code-inspect-result.md in the project root.
• Language: Korean (한국어). All analysis, summaries, and recommendations must be written in Korean.
• Format: Markdown.
• Content:
  • Summary: High-level assessment of the changes.
  • Detailed Analysis: For each modified component, provide the CRS breakdown, complexity analysis, and specific metric violations.
  • Scorecard: The table defined in Section 9 of the framework.
  • Recommendations: Specific refactoring actions based on the “Quality Impact” guidance.
  • (병렬 분석 시) 분석 방식: 그룹 구성과 병렬 분석 ê²°ê³¼ 요약 포함.