inception - 전체 시스템 연쇄 의존성 맵 자동 갱신

00 general-pro의 전체 시스템(dev-rules, reusable-code, reusable-code-python, reusable-code-java, reusable-page, reusable-design, skills, agents, hooks)을 스캔하여 _COMPONENT_MAP.md와 CLAUDE.md를 최신 상태로 유지하는 자기 성찰(self-reflection) 스킬입니다.

인수 처리

사용자가 제공한 인수: $ARGUMENTS

기본 경로

BASE 결정 순서:
1. 환경변수 GENERAL_PRO_PATH
2. CWD가 00-general-pro* 내부이면 해당 루트
3. ~/{develop,dev}/00-general-pro-web 존재 탐색
4. 실패 시 AskUserQuestion: "00-general-pro-web 경로를 입력해주세요"

BASE = {결정된 경로}
COMPONENT_MAP = $BASE/docs/references/_COMPONENT_MAP.md
CLAUDE_MD = $BASE/CLAUDE.md
EXTRACTION_PATTERNS = $BASE/03-skills/inception/references/extraction-patterns.md
CHAIN_RULES = $BASE/03-skills/inception/references/chain-recommendation-rules.md
STATISTICS_FORMULA = $BASE/03-skills/inception/references/statistics-formula.md

Development Protocol 보호 정책

CLAUDE.md 갱신 시 개발 프로토콜 섹션(Development Protocol)의 무결성을 보장합니다.

보호 대상 정의

CLAUDE.md의 섹션을 다음 3등급으로 분류합니다:

CONDITIONAL 섹션 수정 규칙

CONDITIONAL 섹션을 수정할 때는 반드시 다음 절차를 따릅니다:

1. 수정 전 전체 CLAUDE.md 로드: Edit 전에 CLAUDE.md 전문을 Read하여 현재 구조를 완전히 파악
2. 영향 범위 교차 검증: 수정 대상 섹션이 다른 섹션과 상호 참조하는 부분이 있는지 확인
   • 예: 폴더 구조에 새 스킬 디렉토리 추가 → ## 주요 스킬 테이블에도 반영 필요
   • 예: 에이전트 추가 → 폴더 구조의 04-agents/ 하위에도 반영 필요
3. 종합적 일괄 수정: 연관된 모든 CONDITIONAL 섹션을 하나의 갱신 세트로 묶어 적용
   • 스킬 추가 시: 폴더 구조 + 스킬 테이블을 함께 갱신
   • 에이전트 추가 시: 폴더 구조 + 에이전트 테이블을 함께 갱신
4. 수정 후 무결성 검증: 갱신 완료 후 ABSOLUTE 섹션이 변경되지 않았는지 확인

프로토콜 변경이 필요한 경우

만약 ABSOLUTE 등급 섹션의 수정이 불가피한 상황이 감지되면 (예: 프로젝트 개요의 설명이 실제 구조와 심각하게 괴리):

1. 자동 수정하지 않음 — 절대 직접 수정하지 않음
2. 영향 분석 보고서 작성 — 어떤 섹션이 왜 수정이 필요한지, 관련된 모든 섹션을 나열
3. AskUserQuestion으로 사용자 판단 요청 — 선택지 제시:
   • "관련 섹션 전체를 검토하고 종합적으로 수정" → 사용자 승인 후 관련 전체를 읽고 일관성 있게 수정
   • "이번에는 건너뛰기" → 보고서만 기록하고 수정하지 않음

Phase 1: 인벤토리 스캔

전체 시스템 디렉토리를 스캔하여 현존 컴포넌트 목록을 수집합니다.

1.0 변경 범위 감지 (증분 최적화)

if git 이력 있음 (Bash: git log -1 2>/dev/null):
    _COMPONENT_MAP.md에서 마지막 갱신 일자 추출:
      Grep: "최종 갱신" 또는 날짜 패턴 (YYYY-MM-DD) → last_update_date

    if last_update_date 존재:
      변경된 파일 = Bash: git diff --name-only {last_update_date}.. -- 03-skills/ 04-agents/

      if 변경된 파일 없음:
        → "스킬/에이전트 변경 없음. Phase 2 관계 추출을 건너뛰고 기존 맵을 재사용합니다." 표시
        → Phase 2 건너뜀 (Phase 1 인벤토리 + Phase 3 기존 맵 로드 + Phase 4 차이 분석만 수행)
      else:
        → changed_skills / changed_agents 목록 기록
        → Phase 2에서 변경된 스킬/에이전트만 관계 재추출, 나머지는 기존 맵 재사용
    else:
      → 전체 스캔 (기존 동작)
else:
    → 전체 스캔 (기존 동작)

1.1 개발 규칙 시스템

Glob: 01-dev-rules-system/*/

최상위 하위 디렉토리만 수집. 각 디렉토리명과 존재 여부 기록.

1.2 TypeScript/React 재사용 코드

Glob: 02-reusable-code/*/

카테고리 디렉토리 목록 수집. 각 카테고리의 하위 파일 수 함께 기록.

1.3 Python 재사용 코드

Glob: 02-reusable-code-python/*/

카테고리 디렉토리 목록 수집. README.md 존재 여부 함께 확인.

1.4 Java/Spring Boot 재사용 코드

Glob: 02-reusable-code-java/*/

카테고리 디렉토리 목록 수집. README.md 존재 여부 함께 확인.

1.5 페이지 레벨 재사용 컴포넌트

Glob: 02-reusable-page/*/

페이지 카테고리 디렉토리 목록 수집. 각 카테고리의 하위 파일 수 함께 기록.

1.6 디자인 자산 라이브러리

Glob: 02-reusable-design/*/

디자인 자산 카테고리 목록 수집. tokens, css-patterns, tailwind-configs, assets 등.

1.7 Hooks 확장

Glob: 06-hooks/*/

Hooks 디렉토리 목록 수집. 각 Hook의 README.md 존재 여부 확인.

1.7.1 아이디어·연구 저장소

Glob: 07-idea-vault/*/
Glob: 08-research-vault/*/

아이디어 vault: ideas/, plans/, archive/ 하위 파일 수 기록. 연구자료 vault: 주제별 폴더 목록 수집, 각 주제의 analyses/ 파일 수와 synthesis/ 존재 여부 함께 기록.

1.8 스킬

Glob: 03-skills/*/SKILL.md

SKILL.md가 존재하는 디렉토리만 유효한 스킬로 인식. 각 스킬의 frontmatter에서 name, description 추출.

1.8.1 스킬 건강 점검

각 스킬 SKILL.md에 대해 다음 항목을 검증합니다:

for each skill in scanned_skills:
  Read: 03-skills/{skill}/SKILL.md

  # frontmatter 검증
  if missing name or description: → HEALTH issue (HIGH)

  # references 정합성
  referenced_files = SKILL.md에서 `references/` 경로 추출
  for each ref_file:
    Glob: 03-skills/{skill}/references/{ref_file}
    if not exists: → HEALTH issue (MEDIUM)

  # phases 정합성
  referenced_phases = SKILL.md에서 `phases/` 경로 추출
  for each phase_file:
    Glob: 03-skills/{skill}/phases/{phase_file}
    if not exists: → HEALTH issue (MEDIUM)

건강 점검 결과는 Phase 4에서 HEALTH 분류로 보고됩니다.

1.9 에이전트

Glob: 04-agents/*.md

README.md를 제외한 모든 .md 파일. 파일명에서 에이전트 이름 추출.

1.10 수집 결과 형식

## 인벤토리 스캔 결과

| 시스템 | 컴포넌트 수 | 목록 |
|--------|-----------|------|
| 01-dev-rules-system | N개 | dir1, dir2, ... |
| 02-reusable-code | N개 | cat1, cat2, ... |
| 02-reusable-code-python | N개 | cat1, cat2, ... |
| 02-reusable-code-java | N개 | cat1, cat2, ... |
| 02-reusable-page | N개 | cat1, cat2, ... |
| 02-reusable-design | N개 | cat1, cat2, ... |
| 03-skills | N개 | skill1, skill2, ... |
| 04-agents | N개 | agent1, agent2, ... |
| 06-hooks | N개 | hook1, hook2, ... |

Phase 2: 관계 추출

각 스킬 SKILL.md와 에이전트 .md 파일을 Read하여 관계를 추출합니다.

상세 추출 패턴은 references/extraction-patterns.md 참조.

2.1 스킬 관계 추출

각 스킬 SKILL.md에서:

1. YAML frontmatter 파싱: name, description, allowed-tools 추출
2. 디렉토리 경로 참조 탐지: 02-reusable-code/, 01-dev-rules-system/, docs/ 등 경로 언급 검색
3. 관계 유형 분류:
   • Read: 파일/디렉토리를 읽는 관계 (확인, 참조, 로드, 비교)
   • Write: 파일/디렉토리를 생성/수정하는 관계 (저장, 생성, 기록, 갱신)
   • Trigger: 자동으로 다른 스킬/에이전트를 발동 (──자동──→)
   • Invoke: 명시적으로 다른 스킬/에이전트를 호출
   • Recommend: 사용자에게 다른 스킬 사용을 추천 (──추천──→)
   • Ref: 기준/규칙을 참조 (──참조──→)
4. ## 관련 스킬 섹션 파싱: 테이블에서 연관 스킬/에이전트 + 연동 시나리오 추출
5. 연쇄 화살표 패턴 탐지: ──자동──→, ──추천──→, ──참조──→, ──선택──→ 등

2.2 에이전트 관계 추출

각 에이전트 .md에서:

1. 에이전트명(파일명 기반) 및 설명 추출
2. 스킬 참조/호출 관계 탐지
3. 다른 에이전트와의 관계 탐지
4. 코드 라이브러리/문서 참조 관계

2.3 추출 결과 형식

## 관계 추출 결과

### 코드 라이브러리 관계
| 스킬/에이전트 | 방향 | 대상 | 용도 |
|-------------|------|------|------|
| kdyextract | Read | 02-reusable-code/ | 기존 패키징 확인 |
| kdyextract | Write | 02-reusable-code/ | 추출 코드 저장 |

### 스킬 간 연쇄
| 출발 | 화살표 | 도착 | 트리거 조건 |
|------|--------|------|-----------|
| kdyweb (init) | ──자동──→ | kdyweb (verify) | init 완료 시 |

### 에이전트-스킬 교차
| 에이전트 | 스킬 | 방향 | 연계 방식 |
|---------|------|------|---------|
| code-reviewer | kdyextract | ← 참조됨 | Phase 4-A 기준 |

Phase 3: 기존 맵 로드

_COMPONENT_MAP.md와 CLAUDE.md를 파싱하여 현재 문서화된 관계를 수집합니다.

3.1 _COMPONENT_MAP.md 파싱

7개 섹션에서 정보 추출:

3.2 CLAUDE.md 파싱

3개 영역에서 정보 추출:

Phase 4: 차이 분석

Phase 2(디스크 실제 관계)와 Phase 3(문서 기록 관계)를 비교합니다.

4.1 분류 기준

4.2 비교 항목

1. 컴포넌트 존재 여부: 스킬/에이전트/카테고리가 추가/삭제되었는지
2. 관계 변경: Read/Write/Trigger/Invoke 관계가 추가/삭제/변경되었는지
3. CLAUDE.md 테이블: 스킬/에이전트 테이블 항목이 최신인지
4. 폴더 구조: CLAUDE.md의 폴더 구조 트리가 실제와 일치하는지
5. 연결 통계: 재계산된 통계와 기록된 통계 비교
6. 체인 유효성: 연쇄 발동 체인의 양방향 참조 정합성 (4.3 참조)

4.3 체인 유효성 검증

_COMPONENT_MAP.md의 "스킬 간 연쇄 발동" 섹션에 기록된 모든 체인을 양방향 검증합니다.

증분 최적화: Phase 1.0에서 changed_skills가 감지된 경우, 변경된 스킬이 관여하는 체인만 우선 검증합니다. 변경되지 않은 스킬 간의 체인은 기존 검증 결과를 재사용합니다.

if changed_skills 존재:
  target_chains = 모든 체인 중 출발 또는 도착이 changed_skills에 포함되는 것
  기존_chains = 나머지 → 기존 검증 결과 재사용 (VALID 유지)
else:
  target_chains = 모든 체인 (전체 검증)

검증 대상: 자동 연쇄, 조건부 연쇄, 수동 연쇄의 모든 A ──→ B 관계

검증 방법:

1. 출발측 검증: 스킬 A의 SKILL.md에서 스킬 B를 호출/참조하는 코드가 존재하는지 확인
   • ## 관련 스킬 테이블에 B가 등록되어 있는지
   • Phase/워크플로우에서 B 호출이 명시되어 있는지
2. 도착측 검증: 스킬 B의 SKILL.md에서 스킬 A로부터 호출받는 관계가 인지되어 있는지
   • ## 관련 스킬 테이블에 A가 등록되어 있는지
3. 존재 검증: 체인에 등장하는 모든 스킬/에이전트가 실제 디스크에 존재하는지

Grep: pattern="{스킬B 이름}", path="03-skills/{스킬A}/SKILL.md"
Grep: pattern="{스킬A 이름}", path="03-skills/{스킬B}/SKILL.md"

판정 분류:

순환 의존성 감지: 모든 연쇄 체인에서 DFS로 순환 경로를 탐지합니다. 발견 시 CIRCULAR로 분류하고 순환 경로를 명시합니다.

암묵적 의존성 분석: 같은 파일/디렉토리를 Read하는 스킬과 Write하는 스킬 간에 암묵적 의존성이 존재할 수 있습니다. Phase 2에서 추출한 Read/Write 관계를 교차 분석하여 명시적 체인에 등록되지 않은 잠재적 충돌 관계를 식별합니다.

implicit_deps = []
for each file/dir in all_targets:
  writers = 해당 경로를 Write하는 스킬 집합
  readers = 해당 경로를 Read하는 스킬 집합
  if writers ∩ readers 간 명시적 체인 없음:
    implicit_deps.append({target, writers, readers})

출력 형식:

### 체인 유효성 검증
| 체인 | 출발→도착 | 상태 | 상세 |
|------|----------|------|------|
| kdygenesis→kdysetting | A→B 양방향 | VALID | - |
| kdyweb(init)→kdypick | A→B 편방향 | ONE_WAY | kdypick에 kdyweb 역참조 없음 |

4.4 체인 필요성 추천 (Semantic Chain Recommendation)

기존 체인의 정합성만 검증하는 4.3과 달리, 각 스킬의 시맨틱 프로파일(역할, 산출물, 입력)을 분석하여 누락된 체인을 능동적으로 추천합니다.

상세 규칙은 references/chain-recommendation-rules.md 참조.

4.4.1 시맨틱 프로파일 구축

Phase 2에서 추출한 관계 데이터를 바탕으로 각 스킬에 태그를 부여합니다.

for each skill in scanned_skills:
  profile = {
    role: [],      # PRODUCER, VALIDATOR, TRANSFORMER, ORCHESTRATOR, SYNCER, ANALYZER, BOOTSTRAPPER, SESSION
    output: [],    # OUT:CODE, OUT:DOCS, OUT:CONFIG, OUT:MAP, OUT:REPORT, OUT:SKILL, OUT:TEST, OUT:CHECKPOINT, OUT:LIBRARY
    input: [],     # IN:CODE, IN:DOCS, IN:LIBRARY, IN:SKILL, IN:RULES, IN:REFS, IN:CHECKPOINT, IN:INTEL
  }

  # 역할 태그 판별
  if skill.category in CAT-7: profile.role += ORCHESTRATOR
  if skill.category in CAT-6: profile.role += SYNCER
  if skill.category in CAT-5: profile.role += ANALYZER
  if skill.category in CAT-4: profile.role += VALIDATOR
  if skill.category in CAT-3: profile.role += TRANSFORMER
  if skill.category in CAT-2: profile.role += BOOTSTRAPPER
  if skill.category in CAT-1: profile.role += SESSION
  if skill.write_targets에 src|app|lib|components 포함: profile.role += PRODUCER
  if skill.trigger_count >= 3: profile.role += ORCHESTRATOR (추가)

  # 산출물 태그 판별
  if skill.write_targets에 src|app|lib 포함: profile.output += OUT:CODE
  if skill.write_targets에 docs/ 포함: profile.output += OUT:DOCS
  if skill.write_targets에 .mcp.json|CLAUDE.md|.github/ 포함: profile.output += OUT:CONFIG
  if skill.write_targets에 _COMPONENT_MAP|CLAUDE.md 테이블 포함: profile.output += OUT:MAP
  if skill.write_targets에 docs/intel/|docs/logs/ 포함: profile.output += OUT:REPORT
  if skill.write_targets에 03-skills/|04-agents/ 포함: profile.output += OUT:SKILL
  if skill.write_targets에 e2e/|tests/ 포함: profile.output += OUT:TEST
  if skill.write_targets에 _CHECKPOINT_ 패턴 포함: profile.output += OUT:CHECKPOINT
  if skill.write_targets에 02-reusable-code 포함: profile.output += OUT:LIBRARY

  # 입력 태그 판별 (Read 관계 기반, 유사 로직)
  ...

4.4.2 규칙 적용 엔진

Read: references/chain-recommendation-rules.md (규칙 카탈로그 로드)

recommendations = []

for each rule in rules:
  for each skill in scanned_skills:
    if skill matches rule.IF:
      expected_chain = rule.THEN에 명시된 대상 스킬

      # 직접 체인 존재 확인
      direct_exists = (skill → expected_chain) in existing_chains

      # 경유 체인 존재 확인 (A→C→B 패턴)
      indirect_exists = false
      for each intermediate in all_skills:
        if (skill → intermediate) in existing_chains AND (intermediate → expected_chain) in existing_chains:
          indirect_exists = true
          break

      # 오케스트레이터 경유 확인
      orchestrator_covers = false
      for each orch in [kdygenesis, kdynext, kdyswarm]:
        if (orch → skill) in existing_chains AND (orch → expected_chain) in existing_chains:
          orchestrator_covers = true
          break

      if rule.제외 조건에 해당:
        continue  # SKIP

      if not direct_exists AND not indirect_exists AND not orchestrator_covers:
        confidence = calculate_confidence(rule.강도, direct_exists, indirect_exists)
        recommendations.append({
          rule: rule.ID,
          source: skill,
          target: expected_chain,
          confidence: confidence,
          reason: rule.근거,
          suggested_type: rule.THEN의 화살표 유형
        })

4.4.3 산출물→소비자 교차 분석

Phase 2에서 추출한 Write/Read 관계를 교차하여, 4.3의 암묵적 의존성 분석을 확장합니다.

# 4.3 암묵적 의존성: 같은 파일을 R/W하는 충돌 관계
# 4.4 산출물→소비자: 출력이 다른 스킬의 입력이 되는 흐름 관계

flow_recommendations = []

for each write_target in all_write_relations:
  writer_skill = write_target.skill
  target_path = write_target.path

  for each read_relation in all_read_relations:
    reader_skill = read_relation.skill
    read_path = read_relation.path

    if writer_skill == reader_skill: continue  # 자기 참조 제외
    if writer_skill in [inception, kdyupdate]: continue  # 범용 동기화 제외

    # 경로 매칭 (정확 매칭 또는 상위 디렉토리 매칭)
    if target_path == read_path OR target_path startswith read_path OR read_path startswith target_path:
      if (writer_skill → reader_skill) not in existing_chains:
        flow_recommendations.append({
          rule: "R-FLOW-01",
          source: writer_skill,
          target: reader_skill,
          confidence: "MEDIUM" if exact_match else "LOW",
          reason: f"{writer_skill}이 {target_path}에 쓰고, {reader_skill}이 같은 경로를 읽음",
          write_path: target_path,
          read_path: read_path
        })

4.4.4 추천 결과 출력 형식

### 체인 필요성 추천 (Semantic Recommendation)

#### 프로파일 요약
| 스킬 | 역할 | 산출물 | 입력 |
|------|------|--------|------|
| kdyweb | BOOTSTRAPPER, PRODUCER | OUT:CODE, OUT:DOCS | IN:REFS, IN:RULES |
| kdyextract | TRANSFORMER | OUT:LIBRARY | IN:CODE, IN:LIBRARY |
| ... | ... | ... | ... |

#### 누락 체인 추천
| 신뢰도 | 규칙 | 출발 | → | 도착 | 근거 |
|--------|------|------|---|------|------|
| [HIGH] | R-QUALITY-01 | kdyweb | ──추천──→ | kdyconvention | 코드 생성 스킬은 컨벤션 검증 필요 |
| [HIGH] | R-SYNC-01 | kdyselfreflection | ──추천──→ | inception | 스킬 생성/수정 후 맵 동기화 필요 |
| [MEDIUM] | R-FLOW-01 | kdyintel | ──추천──→ | kdynotebook | intel 보고서를 notebook이 참조 |
| [LOW] | R-QUALITY-04 | kdyweb | ──추천──→ | kdye2e | 페이지 생성 후 E2E 검증 권장 |

#### 추천 통계
| 신뢰도 | 건수 |
|--------|------|
| HIGH | N건 |
| MEDIUM | N건 |
| LOW | N건 |
| SKIP (제외) | N건 |

4.4.5 추천 결과 활용

추천 결과는 Phase 5에서 사용자에게 표시되며, 승인 시 Phase 6에서 다음과 같이 처리됩니다:

4.5 출력 형식

## 차이 분석 결과

### NEW (디스크에만 존재)
| 유형 | 항목 | 상세 |
|------|------|------|
| 스킬 | inception | 03-skills/inception/ |
| 카테고리 | 13-testing-patterns | 02-reusable-code/13-testing-patterns/ |

### REMOVED (문서에만 존재)
| 유형 | 항목 | 위치 |
|------|------|------|
| (없음) | | |

### CHANGED (내용 변경)
| 유형 | 항목 | 문서 내용 | 실제 내용 |
|------|------|----------|----------|
| 스킬 설명 | kdyweb | "웹 구조 관리" | "웹 페이지 구조 관리 (6모드)" |

### HEALTH (스킬 건강 점검)
| 스킬 | 심각도 | 항목 | 상세 |
|------|--------|------|------|
| inception | LOW | 관련 스킬 섹션 | 존재함 |
| example-skill | HIGH | frontmatter | name 필드 누락 |

### 통계 변경
| 분류 | 기존 | 새로 계산 |
|------|------|----------|
| 총 상호 연결 | 45+ | 48+ |

Phase 5: 사용자 확인

차이 분석 결과를 보여주고 갱신 범위를 선택받습니다.

5.1 표시 내용

1. 스캔 요약 (시스템별 컴포넌트 수)
2. NEW / REMOVED / CHANGED 테이블
3. 체인 유효성 검증 결과 (4.3)
4. 체인 필요성 추천 결과 (4.4) — 프로파일 요약 + 누락 체인 추천 테이블
5. 통계 변경 비교
6. 갱신 대상 파일 목록

5.2 선택지

AskUserQuestion으로 다음 중 선택:

5.3 --fix 모드

--fix 인수가 있으면 자동 해결 가능 항목을 Phase 5 확인 없이 즉시 적용합니다.

자동 해결 가능 항목:

• 카테고리 메타데이터 스킬 수 불일치 (카운트 재계산)
• 연결 통계 수량 불일치 (재계산 적용)
• NEW 분류 중 단순 행 추가 (매트릭스, 문서참조 등)
• _SYNERGY_ANALYSIS.md 연결 통계 동기화

수동 확인 필요 항목 (--fix에서도 건너뜀):

• REMOVED 분류 (삭제는 항상 수동 확인)
• CHANGED 분류 (내용 변경은 수동 확인)
• BROKEN/PHANTOM 체인 (구조적 수정 필요)
• 체인 추천 (4.4 결과) — 수락/무시/거부 선택 필수
• ASCII 다이어그램 변경

5.4 --scan-only 모드

--scan-only 인수가 있으면 Phase 5에서 리포트만 출력하고 종료합니다. 사용자 확인 없이 Phase 1~4 결과를 보여줍니다.

Phase 6: 적용 및 보고

승인된 변경 사항을 파일에 반영합니다.

6.1 _COMPONENT_MAP.md 갱신

갱신 대상 섹션:

생명주기 다이어그램 정책:

• ASCII 다이어그램(## 전체 생명주기 다이어그램)은 기본적으로 자동 재생성하지 않음 (깨짐 위험)
• --update-diagram 플래그 사용 시:
  1. 현재 스캔 결과 기반 제안형 다이어그램을 최종 보고에 포함
  2. 기존 HTML 주석 플래그를 정리
  3. 사용자 승인 후에만 실제 파일에 적용
• --update-diagram 미사용 시: 새 컴포넌트 발견 시 다이어그램 아래에 HTML 주석으로 플래그만 남김:

  <!-- [inception] 새 컴포넌트 발견: {name}. 다이어그램 수동 업데이트 필요. -->
  

• 테이블 형태 섹션(매트릭스, 통계)은 자동 갱신

6.1.1 _COMPONENT_MAP.json 기계 판독 출력

_COMPONENT_MAP.md와 동일 디렉토리에 _COMPONENT_MAP.json을 자동 생성합니다. 다른 스킬이 Markdown 재파싱 없이 관계 데이터를 직접 로드할 수 있게 합니다.

{
  "version": "1.0",
  "generated": "YYYY-MM-DD",
  "categories": { "CAT-1": { "name": "세션 생명주기", "skills": ["cs", ...] }, ... },
  "skills": { "kdyweb": { "read": [...], "write": [...], "chains": [...] }, ... },
  "agents": { "code-reviewer": { "skills": [...], "direction": "..." }, ... },
  "statistics": { "total": N, "breakdown": { ... } }
}

이 파일은 --scan-only 모드에서도 생성됩니다 (읽기 전용 출력).

6.1.2 _SYNERGY_ANALYSIS.md 연결 통계 동기화

_COMPONENT_MAP.md의 ## 연결 통계 → 총 상호 연결 값을 추출하여 _SYNERGY_ANALYSIS.md의 총 상호 연결 셀을 동일 값으로 갱신합니다.

new_total = _COMPONENT_MAP.md에서 "총 상호 연결" 값 추출
old_total = _SYNERGY_ANALYSIS.md에서 "총 상호 연결" 값 추출

if new_total != old_total:
  Edit: _SYNERGY_ANALYSIS.md → "총 상호 연결" 셀을 new_total로 갱신
  Edit: _SYNERGY_ANALYSIS.md → "최종 갱신" 섹션에 날짜 + "연결 통계 {old}→{new} 자동 동기화" 추가

범위 제한: 연결 통계 숫자만 갱신. 시너지 분석 본문·다이어그램은 절대 자동 수정하지 않음.

6.2 CLAUDE.md 갱신

Development Protocol 보호 정책을 반드시 준수합니다.

6.2.0 사전 검증 (필수)

Read: $CLAUDE_MD (전문 로드)

1. ABSOLUTE 섹션 위치를 식별하고 해시/줄 수를 기록 (갱신 후 비교용)
2. CONDITIONAL 섹션만 갱신 대상으로 확정
3. 연관 갱신 세트를 구성:
   • 스킬 변경 발견 시 → ## 폴더 구조 (03-skills 하위) + ## 주요 스킬 테이블을 하나의 세트로
   • 에이전트 변경 발견 시 → ## 폴더 구조 (04-agents 하위) + ## 에이전트 테이블을 하나의 세트로

6.2.1 갱신 대상 영역 (CONDITIONAL만)

6.2.2 갱신 후 무결성 검증

Read: $CLAUDE_MD (갱신 후 재로드)

1. ABSOLUTE 섹션의 줄 수/내용이 갱신 전과 동일한지 확인
2. 불일치 발견 시 → 즉시 경고 + AskUserQuestion으로 복구 여부 확인
3. CONDITIONAL 섹션 간 상호 참조 일관성 확인 (예: 스킬 테이블의 항목 수 = 폴더 구조의 스킬 디렉토리 수)

6.3 최종 보고

## inception 갱신 완료

### 갱신 통계
| 항목 | 수량 |
|------|------|
| 새로 추가된 항목 | N개 |
| 제거된 항목 | N개 |
| 수정된 항목 | N개 |
| 갱신된 파일 | N개 |

### 갱신된 파일
- [x] docs/references/_COMPONENT_MAP.md
- [x] CLAUDE.md

### 체인 유효성 검증 결과
| 상태 | 건수 |
|------|------|
| VALID | N개 |
| ONE_WAY | N개 |
| BROKEN | N개 |
| PHANTOM | N개 |

### 체인 필요성 추천 결과
| 신뢰도 | 건수 | 수락 | 무시 | 거부 |
|--------|------|------|------|------|
| HIGH | N건 | N건 | N건 | N건 |
| MEDIUM | N건 | N건 | N건 | N건 |
| LOW | N건 | N건 | N건 | N건 |

수락된 추천: N건 → 스킬 SKILL.md {N}개 수정, _COMPONENT_MAP.md 체인 {N}건 추가

### 수동 확인 필요 항목
- [ ] ASCII 생명주기 다이어그램에 {새 컴포넌트} 반영 필요
- [ ] {스킬명}의 관계 추출이 모호 → 수동 검증 권장
- [ ] BROKEN/PHANTOM 체인 {N}건 → 해당 스킬 SKILL.md 수정 필요
- [ ] 체인 추천 중 무시된 {N}건 → 다음 실행 시 재추천

### 연결 통계 (갱신 후)
| 분류 | 수량 |
|------|------|
| 스킬 → 코드 라이브러리 | Xn개 |
| 스킬 → 스킬 연쇄 | Xn개 |
| ...  | ... |
| **총 상호 연결** | **XX+개** |

주의사항

1. Development Protocol 보호: CLAUDE.md의 ABSOLUTE 등급 섹션(프로젝트 개요, 확장 리소스, 추출 이력, 세션 관리, 관련 문서)은 절대 자동 수정하지 않음. CONDITIONAL 섹션도 연관 섹션 전체를 교차 검증 후 종합적으로 수정
2. 비파괴적 갱신: 기존 내용의 순서와 형식을 최대한 보존
3. ASCII 다이어그램 보호: 자동으로 ASCII 아트를 재생성하지 않음
4. 사용자 확인 필수: Phase 5에서 반드시 승인 후 쓰기 (--scan-only 제외)
5. 자기 참조: inception 자체도 의존성 맵에 등록해야 함
6. 멱등성: 같은 상태에서 여러 번 실행해도 동일한 결과
7. 종합적 수정 원칙: 하나의 변경이 여러 섹션에 영향을 줄 때, 개별 섹션만 수정하지 않고 관련된 모든 섹션을 하나의 갱신 세트로 묶어 일괄 적용
8. 체인 추천 보수성: 추천 엔진은 오탐보다 미탐이 낫다는 원칙. 확실하지 않은 추천은 LOW로 분류하고, 사용자가 거부한 추천은 규칙 제외 조건에 자동 반영

사용 예시

# 전체 스캔 + 갱신
/inception

# 스캔만 (변경 없이 차이 리포트)
/inception --scan-only

# 특정 컴포넌트만 분석
/inception --component kdyweb

# 단순 수정 자동 적용 (카운트, 행 추가 등)
/inception --fix

# 다이어그램 제안 포함
/inception --update-diagram

# 체인 추천 없이 기존 검증만
/inception --no-recommend

관련 스킬