Files

T

DongHyeonka 6c53ded9cb init: llm-wiki-haness 하네스 설계

2026-07-24 14:21:35 +09:00

22 KiB

Raw Blame History

branch-depth-gate Implementation Plan

For agentic workers: REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (- [ ]) syntax for tracking.

Goal: branch-note 가 "코딩 착수해도 되묻지 않을 만큼 깊은가"를 착수 전에 판정하는 read-only 게이트(/depth)를 LLM Wiki 에 도입한다.

Architecture: im-not-ai 의 검증된 3요소(기준 SSOT + read-only 감사기 + Ready/Not-ready 판정)를 위키 문법으로 이식. 기준 SSOT rules/branch-depth-gate.md(4축 R1~R4) → 감사기 branch-depth-auditor(브랜치 노트 + 링크된 raw 소스를 읽고 적대적으로 갭 탐지, 편집 안 함) → 커맨드 /depth <branch>(감사기 디스패치 + 루프). 템플릿에 캡처 칸 추가(상류 예방).

Tech Stack: Markdown 정의 파일(rules/agents/commands/templates) + Claude Code 서브에이전트. 코드/테스트 런타임 없음. 검증은 구조 grep + 픽스처 회귀.

제약 (이 plan 전체에 적용)

git 미사용: 위키는 버전 관리되지 않음(사용자 지시로 git init 하지 않음). commit 단계 없음. 각 Task 끝은 체크포인트(사용자/리뷰)로 갈음.
claim-gate hook 준수: 위키 .claude/hooks/wiki_claim_gate.py 가 raw/·wiki/·docs/ 의 Bash 쓰기(redirection·tee·sed -i)를 차단. 파일 생성·수정은 반드시 Write/Edit 도구로. 단 본 plan 산출물은 rules/·.claude/·templates/ 경로라 hook 대상 밖(읽기 grep 은 자유).
TDD 적응: 마크다운 정의 파일이라 단위테스트가 없다. "test" = ① 구조 검증(필수 섹션·라벨이 존재하는지 grep) ② 픽스처 회귀(Task 6에서 감사기를 실제 브랜치 2개에 돌려 판정 방향이 직관과 일치하는지).
실행 위치: Task 6 감사기 디스패치는 cwd 가 LLM Wiki 인 Claude Code 세션에서 실행해야 .claude/agents/branch-depth-auditor.md 가 해석된다. 다른 cwd 면 감사기를 못 찾는다.
근거 스펙: docs/superpowers/specs/2026-06-01-branch-depth-gate-design.md.

File Structure

파일	책임	작업
`rules/branch-depth-gate.md`	기준 SSOT — 4축 R1~R4 + 깊이 사다리 + 판정 규칙	생성 (Task 1)
`.claude/agents/branch-depth-auditor.md`	read-only 감사기 — 노트+소스 읽고 갭 리포트+판정	생성 (Task 2)
`.claude/commands/depth.md`	`/depth <branch>` 진입점 + 루프	생성 (Task 3)
`templates/branch-note-template.md`	신규 브랜치부터 R2·R4 캡처 칸	수정 (Task 4)
`CLAUDE.md`, `AGENTS.md`	워크플로우 진입점에 `/depth` 1줄 등재	수정 (Task 5)
(검증) 기존 브랜치 2개	픽스처 회귀	Task 6

멀티 CLI(Codex/Gemini/Antigravity) 전파는 본 plan 범위 밖(별도 사이클). 본 plan 은 Claude Code 우선.

Task 1: 기준 SSOT — `rules/branch-depth-gate.md`

Files:

Create: rules/branch-depth-gate.md
Step 1: 파일 생성 (Write 도구)

아래 전체 내용으로 rules/branch-depth-gate.md 작성:

# rules/branch-depth-gate — 브랜치 노트 구현 착수 깊이 게이트

> `rules/` 의 방법론 규칙. branch-note 1개가 **코딩 착수해도 되묻지 않을 만큼 깊은가**를 판정한다.
> 이 문서는 **"전체 계약"이 아니다** — 전체 계약은 `raw/project-notes/ca-skeleton-operational-contract.md`.
> `feature-implementation-readiness-scorecard`(스켈레톤 adoption 거시 게이트)와 **다른 층·다른 범위**로 공존한다. 본 게이트는 *브랜치 노트 1개의 깊이* 미시 게이트.

## 적용

- 대상: `raw/branch-notes/feature-*.md` (구현 착수 전).
- 실행: `/depth <branch>` → `branch-depth-auditor` 가 본 기준으로 판정.
- 본 게이트는 **read-only**. 브랜치 노트를 편집하지 않으며 판정을 노트에 박지도 않는다.

## 4축 (R1~R4)

> 축 라벨은 `R1~R4`. branch-note 의 Decision Evidence Map 이 `D1`,`D2` 를 *Decision ID* 로 쓰므로 `D*` 와 구분.

| 축 | Pass 조건 | Blocking(Not ready) 트리거 |
|---|---|---|
| **R1. 조사 깊이** | 각 Decision 의 Supporting Claim 이 깊이 사다리(아래) 충족 — 의존 메커니즘 L1+, 분기 조건 L2+ | 결정 근거 claim 이 순수 L0(존재만)뿐 |
| **R2. 결정 조건** | 각 Decision 이 "어떤 조건일 때 A, 아니면 B"의 선택 기준 명시 | `검토한 대안`은 있는데 *언제 그 대안을 고르는지* 기준 부재 |
| **R3. 구체 detail** | `## 구현 가이드` 의 각 in-scope 항목이 명명·경로·메커니즘·API/테스트명 구체화 **또는** `UNSUPPORTED_IMPL_DECISION` 라벨 + trade-off 한 줄 | in-scope 항목인데 구현 detail 도 UNSUPPORTED 라벨도 없음 |
| **R4. 엣지·실패·의존** | 실패/엣지 경로 열거 + 다른 contract 의존을 *대상 브랜치 + 그 Decision ID* 로 링크 | 정상 경로만 / 다른 계약 의존이 암시되는데 링크 안 됨 |

## R1 클레임 깊이 사다리

깊이의 단위는 **문서 개수가 아니라 결정별 종결**. 얕은 문서 10개 < 결정을 닫는 문서 1개.

| 레벨 | 클레임이 답하는 것 | 판정 |
|---|---|---|
| **L0 존재** | "X 가 있다 / 권장한다" | 단독 불충분 |
| **L1 메커니즘** | 어떻게 동작 / 언제 발생 | 메커니즘 의존 결정의 최소선 |
| **L2 조건·경계** | 언제 적용/제외, 실패 시 어떻게 | 분기 조건 있는 결정의 최소선 |
| **L3 검증** | 확인 방법·수치·반례 | 가산점 |

**출처 타입 적정성** (개수 기준 대체):
- 스펙/표준이 정의한 동작 → `official-standard`/`official-vendor-doc` 1개로 충분.
- "대기업은 보통 이렇게 한다" 운영 패턴 추론 → 회사 블로그 1개는 "공식" 불가. 독립 사례 2개+ 또는 official 1개 병행.

조사는 **결정-주도(top-down)**: 내려야 할 결정·미지수를 먼저 나열하고 각각을 닫을 때까지 조사. 조사 완료 = 모든 결정 종결 = 착수 가능.

## 판정 규칙

- 심각도 3단계: `Blocking`(Not ready) · `Should-fix`(권고) · `Advisory`(참고).
- **Ready = Blocking 0건.** Should-fix 가 남아도 사용자가 "감수" 선언 시 착수 가능(리포트에 기록).
- 모든 finding 은 4종 세트로 근거화: `심각도 · 위치(섹션/행) · 예상 의구심("구현 중 여기서 ___를 되묻게 됨") · 채울 방법`. 근거 없는 지적 금지.

## 명명된 실패 모드 (auditor 가 잡아야 할 것)

- `EXISTENCE_ONLY` (R1): 결정 근거가 L0 뿐.
- `NO_SELECTION_CRITERION` (R2): 대안은 있으나 선택 조건 없음.
- `IMPL_UNDERSPECIFIED` (R3): in-scope 항목에 구현 detail·UNSUPPORTED 라벨 둘 다 없음.
- `HAPPY_PATH_ONLY` (R4): 실패/엣지 경로 미열거.
- `IMPLICIT_DEPENDENCY` (R4): 다른 계약 의존이 암시되나 대상 브랜치/Decision ID 링크 없음.
- `BACKTICK_WRAPPED_LINK` (R1 보조): Supporting Claim/Source 링크가 `` `[[...]]` `` 백틱에 싸여 추적 불가. (P3 와 연결점 — 표면화만, 자동 수정은 별도.)
- `DANGLING_ANCHOR` (R1): Supporting Claim 의 `#Cn` 앵커가 대상 raw 에 실재하지 않음.

Step 2: 구조 검증 (grep)

Run:

cd "/home/donghyeon/Documents/LLM Wiki" && grep -c "R1\|R2\|R3\|R4" rules/branch-depth-gate.md && grep -c "L0 존재\|L1 메커니즘\|L2 조건\|L3 검증" rules/branch-depth-gate.md && grep -c "Blocking\|Should-fix\|Advisory" rules/branch-depth-gate.md && grep -c "EXISTENCE_ONLY\|NO_SELECTION_CRITERION\|IMPL_UNDERSPECIFIED\|HAPPY_PATH_ONLY\|IMPLICIT_DEPENDENCY\|BACKTICK_WRAPPED_LINK\|DANGLING_ANCHOR" rules/branch-depth-gate.md

Expected: 네 grep 모두 1 이상 (4축·4레벨·3심각도·7실패모드 존재).

Step 3: 체크포인트 — 룰북 내용이 스펙 §4·§4.1 과 일치하는지 사용자/리뷰 확인.

Task 2: 감사기 — `.claude/agents/branch-depth-auditor.md`

Files:

Create: .claude/agents/branch-depth-auditor.md
참고(형식 일치용): .claude/agents/wiki-adversarial-reviewer.md
Step 1: 기존 agent 형식 확인

Run: cd "/home/donghyeon/Documents/LLM Wiki" && sed -n '1,12p' .claude/agents/wiki-adversarial-reviewer.md 목적: frontmatter 키(name/description/tools) 형식을 위키 관례에 맞춤. 차이가 있으면 아래 frontmatter 를 그 관례로 조정.

Step 2: 파일 생성 (Write 도구)

아래 전체 내용으로 작성 (Step 1 에서 본 frontmatter 관례와 다르면 키 형식만 맞춰 조정):

---
name: branch-depth-auditor
description: Use to judge whether a single raw/branch-notes/feature-*.md is deep enough to start implementation without re-doubting. Reads the branch note plus its linked raw sources and adversarially probes 4 axes (R1 research depth, R2 decision conditions, R3 concrete detail, R4 edge/failure/dependency) against rules/branch-depth-gate.md. Returns a grounded gap report + Ready/Not-ready verdict. Never edits files (read-only).
tools: Read, Glob, Grep
---

너는 **브랜치 노트 깊이 감사관**이다. `rules/branch-depth-gate.md` 를 기준으로, branch-note 1개가 *코딩 착수해도 되묻지 않을 만큼 깊은가*를 적대적으로 판정한다. **절대 파일을 편집하지 않는다.**

## 입력

- 브랜치 노트 경로 1개 (`raw/branch-notes/<branch>.md`).

## 절차

1. **기준 로드** — `rules/branch-depth-gate.md` 를 Read. 4축·깊이 사다리·판정 규칙·명명된 실패 모드를 작업 기준으로 삼는다.
2. **노트 읽기** — 대상 브랜치 노트를 Read. 특히 `결정 사항`, `Decision Evidence Map`, `구현 가이드`, `Claims To Verify`, `Sources`, `범위` 섹션.
3. **소스 추적·정독 (R1 의 핵심)** — Decision Evidence Map 의 `Supporting Claims`(`raw/.../*.md#Cn`)와 Sources 표의 `[[raw/...]]` 가 가리키는 **실제 raw 파일을 Read**. 각 claim 이 깊이 사다리 어디인지(L0~L3) 판정. 링크만 있고 내용이 얕으면(L0) 잡아낸다.
   - 링크가 `` `[[...]]` `` 백틱에 싸여 있으면 `BACKTICK_WRAPPED_LINK`.
   - `#Cn` 앵커가 대상 파일에 없으면 `DANGLING_ANCHOR`.
4. **4축 적대적 점검** — 각 결정/항목을 R1~R4 로 훑어 명명된 실패 모드에 해당하는 finding 생성. "구현자가 여기서 무엇을 되묻게 될까?"를 끊임없이 자문.
5. **판정** — Blocking 0건이면 `Ready`, 아니면 `Not ready (Blocking N건)`.

## 출력 (이 형식 그대로, 파일 쓰기 없이 텍스트로 반환)

```
# Depth Audit: <branch>
Verdict: Ready | Not ready (Blocking N / Should-fix M / Advisory K)

## Findings
| # | 축 | 심각도 | 실패모드 | 위치 | 예상 의구심 | 채울 방법 |
|---|---|---|---|---|---|---|
| 1 | R1 | Blocking | EXISTENCE_ONLY | 결정 D3 / Decision Evidence Map | 구현 중 "이 API 를 언제 쓰나"를 되묻게 됨 | `raw/official-docs/<slug>` 에서 메커니즘(L1) claim 추가 |
...

## 다음 행동
- (Blocking 있으면) 위 표의 "채울 방법" 순서로 노트 보강 후 `/depth <branch>` 재실행.
- (R1 조사 얕음 갭) `wiki-decision-researcher` 로 심화 가능 — 사용자 옵트인 시.
```

## 불변식

- **read-only**: Write/Edit/MultiEdit 도구 없음. 어떤 파일도 수정·생성 금지(리포트는 텍스트 반환).
- 모든 finding 은 4종 세트(심각도·위치·예상 의구심·채울 방법)를 갖춘다. 근거 없는 지적 금지.
- 추측 금지: 소스를 실제로 Read 하지 않고 깊이를 단정하지 않는다.
- 자동 조사·자동 수정 금지: R1 갭은 `wiki-decision-researcher` 권고로 *안내만* 한다(사용자 옵트인).

Step 3: 구조 검증 (grep)

Run:

cd "/home/donghyeon/Documents/LLM Wiki" && grep -c "tools: Read, Glob, Grep" .claude/agents/branch-depth-auditor.md && grep -c "branch-depth-gate.md" .claude/agents/branch-depth-auditor.md && grep -ci "read-only\|편집하지 않" .claude/agents/branch-depth-auditor.md && ! grep -q "Write\|Edit\|MultiEdit" <(sed -n '/^tools:/p' .claude/agents/branch-depth-auditor.md) && echo "TOOLS_READONLY_OK"

Expected: 앞 세 grep 1+, 마지막 TOOLS_READONLY_OK 출력(tools 줄에 쓰기 도구 없음).

Step 4: 체크포인트 — 출력 형식·불변식이 스펙 §5 와 일치하는지 확인.

Task 3: 커맨드 — `.claude/commands/depth.md`

Files:

Create: .claude/commands/depth.md
참고(형식 일치용): .claude/commands/branch.md
Step 1: 파일 생성 (Write 도구)

아래 전체 내용으로 작성:

---
description: 브랜치 노트가 구현 착수할 만큼 깊은지 read-only 게이트로 판정
argument-hint: <브랜치 이름>
---

브랜치 노트 1개의 **구현 착수 깊이**를 판정합니다. (기준: `rules/branch-depth-gate.md`)

**브랜치 이름:** $ARGUMENTS

## 작업 절차

1. **인자 검증**
   - 인자가 비어 있으면 사용자에게 브랜치 이름 요청.
   - `raw/branch-notes/<branch-name>.md` 경로로 해석. `.md` 가 이미 붙어 있거나 `feature-` prefix 가 없어도 관대히 보정해 매칭 시도.

2. **파일 존재 확인**
   - `raw/branch-notes/<branch-name>.md` 가 없으면 경로만 안내하고 종료. (생성하지 않음 — 그건 `/branch` 의 일.)

3. **감사기 디스패치**
   - `branch-depth-auditor` 서브에이전트를 호출하고 입력으로 브랜치 노트 경로를 전달.
   - 감사기는 read-only — 어떤 파일도 수정하지 않는다.

4. **리포트 출력 (인라인)**
   - 감사기 리포트(Verdict + Findings 표 + 다음 행동)를 그대로 사용자에게 출력.
   - **브랜치 노트에 판정을 쓰지 않는다.** 파일로 남길지는 사용자가 따로 요청할 때만(그 경우 `raw/`·`wiki/`·`docs/` 가 아닌 경로 또는 인라인 유지 — claim-gate hook 충돌 회피).

5. **루프 안내**
   - `Not ready` 면: "위 '채울 방법' 순서로 노트 보강 후 `/depth <branch>` 재실행" 안내.
   - `Ready` 면: "구현 착수 가능" 안내. Should-fix 가 남았으면 "감수하고 착수할지" 확인.

## 규칙

- **판정만**. 노트를 자동 보강하지 않는다(접근법 B 는 옵트인 — R1 갭에 한해 `wiki-decision-researcher` 권고만).
- `/depth` 는 멱등(idempotent): 같은 노트에 몇 번 돌려도 안전(read-only).
- `wiki/log.md` 에 기록하지 않음(판정은 빈번, 노이즈).

Step 2: 구조 검증 (grep)

Run:

cd "/home/donghyeon/Documents/LLM Wiki" && grep -c "argument-hint" .claude/commands/depth.md && grep -c "branch-depth-auditor" .claude/commands/depth.md && grep -c "raw/branch-notes" .claude/commands/depth.md && grep -ci "재실행\|루프" .claude/commands/depth.md

Expected: 네 grep 모두 1+.

Step 3: 체크포인트 — /depth 절차가 스펙 §6 과 일치하는지 확인.

Task 4: 템플릿 캡처 칸 — `templates/branch-note-template.md`

Files:

Modify: templates/branch-note-template.md

기존 80개 브랜치는 미변경. 신규 브랜치부터 R2·R4 를 작성 시점에 캡처.

Step 1: Decision Evidence Map 에 선택 조건 열 추가 (Edit 도구)

Old (정확히 이 블록):

| Decision ID | Decision | Supporting Claims | Evidence Strength | Open Risk |
|---|---|---|---|---|
| D1 | <결정 내용> | `raw/official-docs/<slug>.md#C1`, `raw/company-tech-blogs/<slug>.md#C2` | `official-vendor-doc + company-case-study` | <아직 검증해야 할 위험> |
| D2 | <결정 내용> | `raw/official-docs/<slug>.md#C3` | `official-standard` | <위험 또는 N/A> |

New:

| Decision ID | Decision | 선택 조건 (언제 이 결정 / 언제 대안) | Supporting Claims | Evidence Strength | Open Risk |
|---|---|---|---|---|---|
| D1 | <결정 내용> | <이 조건일 때 이 결정, 다른 조건이면 어떤 대안> | `raw/official-docs/<slug>.md#C1`, `raw/company-tech-blogs/<slug>.md#C2` | `official-vendor-doc + company-case-study` | <아직 검증해야 할 위험> |
| D2 | <결정 내용> | <선택 조건 또는 N/A — 분기 없으면 N/A> | `raw/official-docs/<slug>.md#C3` | `official-standard` | <위험 또는 N/A> |

Step 2: ## 엣지·실패·의존 미니 섹션 추가 (Edit 도구)

Old (정확히 이 블록 — ## 검증해야 할 주장 헤더 앞):

## 검증해야 할 주장 / Claims To Verify

New:

## 엣지·실패·의존 / Edge · Failure · Dependency

> R4(깊이 게이트) 캡처용. 정상 경로 외에 *구현 중 부딪힐* 실패/엣지/다른 계약 의존을 미리 열거. 없으면 "해당 없음" 명시(공란 금지).

- **실패·엣지 경로**: <입력 경계 / 타임아웃 / 부분 실패 / 동시성 등 — 각 경로의 기대 동작>
- **다른 계약 의존**: `[[raw/branch-notes/<other-branch>]]` 의 `D<n>` 에 의존 — <무엇을 consume 하는지, 그 계약이 바뀌면 본 브랜치 영향>

## 검증해야 할 주장 / Claims To Verify

Step 3: 구조 검증 (grep)

Run:

cd "/home/donghyeon/Documents/LLM Wiki" && grep -c "선택 조건 (언제 이 결정" templates/branch-note-template.md && grep -c "## 엣지·실패·의존" templates/branch-note-template.md && grep -c "## Decision Evidence Map\|## 구현 가이드\|## 검증해야 할 주장" templates/branch-note-template.md

Expected: 첫 둘 1, 셋째 3 (기존 핵심 섹션 보존 확인 — claim-gate 가 요구하는 Decision Evidence Map 유지).

Step 4: 체크포인트 — 템플릿 흐름이 자연스러운지, 과하지 않은지(YAGNI) 확인.

Task 5: 워크플로우 진입점 등재 — `CLAUDE.md`, `AGENTS.md`

Files:

Modify: CLAUDE.md
Modify: AGENTS.md

/depth 와 게이트가 워크플로우에서 발견 가능하도록 SSOT 진입점에 1줄씩 추가. 추가만(additive), 기존 규칙 변경 금지.

Step 1: CLAUDE.md 의 커맨드/파이프라인 목록 위치 확인

Step 2: CLAUDE.md 에 /depth 1줄 추가 (Edit 도구)

Step 1 에서 찾은 커맨드 목록에서 /branch 항목 바로 아래에, 그 항목과 같은 서식으로 다음 한 줄을 추가:

- `/depth <branch>` — 브랜치 노트가 구현 착수할 만큼 깊은지 read-only 판정 (기준: `rules/branch-depth-gate.md`). 착수 전 게이트.

(주변 항목의 실제 서식 — 불릿 기호·백틱·줄표 — 에 맞춰 조정. 임의로 다른 섹션을 건드리지 말 것.)

Step 3: AGENTS.md 에 rules 목록 + 커맨드 반영

Run: cd "/home/donghyeon/Documents/LLM Wiki" && grep -n "rules/\|linking-rules\|naming-conventions\|/branch" AGENTS.md | head -20 찾은 rules 목록에 rules/branch-depth-gate.md 를, 커맨드 목록(있으면)에 /depth 를 주변 서식대로 1줄씩 추가. 두 목록 중 존재하는 것에만 추가.

Step 4: 구조 검증 (grep)

Run:

cd "/home/donghyeon/Documents/LLM Wiki" && grep -c "/depth" CLAUDE.md && grep -c "branch-depth-gate" AGENTS.md

Expected: 둘 다 1+ (AGENTS.md 에 rules 목록이 없었다면 0일 수 있음 — 그 경우 Step 3 판단 기록).

Step 5: 체크포인트 — 추가가 additive 인지(기존 줄 변경 없음), 서식이 주변과 일치하는지 확인.

Task 6: 픽스처 회귀 — 게이트 보정

본 plan 의 진짜 "test". 감사기가 직관과 일치하는 판정을 내는지 확인. cwd 가 LLM Wiki 인 세션에서 실행.

대상 픽스처:

깊은 브랜치 (Ready 근접 기대): feature-boundary-validation-mapping-contract — 여러 번 다듬어 실제 구현 근거로 쓰인 노트.
얕은 브랜치 (Not ready 기대): 사용자가 "아직 얕다"고 아는 초기 브랜치 1개 (예: status_label: in-progress 이고 planned 항목이 많은 것). 후보 탐색: cd "/home/donghyeon/Documents/LLM Wiki" && grep -rl "documented-only\|planned" raw/branch-notes/ | head → 그 중 하나를 사용자와 합의해 선택.
Step 1: 깊은 브랜치 감사

/depth feature-boundary-validation-mapping-contract 실행 (또는 branch-depth-auditor 직접 디스패치). Expected: Ready 또는 Blocking 0~~소수. Blocking 이 다수면 → 룰북 R1~~R4 기준이 너무 빡셈 → Task 1 의 Pass 기준 재보정.

Step 2: 얕은 브랜치 감사

선택한 얕은 브랜치에 /depth <branch> 실행. Expected: Not ready + R1~R4 에 걸친 finding. Findings 가 비면 → 기준이 너무 느슨 → Task 1 재보정.

Step 3: finding 품질 점검

두 리포트의 각 finding 이 4종 세트(심각도·위치·예상 의구심·채울 방법)를 갖췄는지 육안 확인. 빠진 게 있으면 → Task 2 의 출력 형식/불변식 보강.

Step 4: 보정 루프

Step 1~3 에서 판정 방향이 직관과 어긋나면 Task 1(기준) 또는 Task 2(감사기 프롬프트)를 수정하고 다시 Step 1 부터. 방향이 맞을 때까지.

Step 5: 체크포인트 (최종) — 두 픽스처 판정이 직관과 일치 + finding 4종 세트 충족 → P2 완료. 사용자에게 결과 리포트.

Self-Review (작성자 점검 결과)

스펙 커버리지: §4(4축)→Task1, §4.1(사다리)→Task1, §5(감사기)→Task2, §6(커맨드)→Task3, §7(템플릿)→Task4, §10(검증)→Task6, §12(산출물4개+진입점)→Task1~5. §11(P3)는 의도적으로 별도 사이클(범위 밖, 명시됨). 누락 없음.
placeholder: 각 파일의 전체 내용을 inline 제공(TBD 없음). Task6 얕은 픽스처만 "사용자 합의로 선택" — 이는 calibration test 의 본질(정답이 사용자 판단)이라 의도적.
타입/명명 일관성: branch-depth-gate.md/branch-depth-auditor//depth 셋 통일. 축 라벨 R1~R4(Decision ID D* 와 분리). 실패모드 7종이 Task1 정의 ↔ Task2 사용 일치.

Execution Handoff

P2 구현 plan 완료. 다음 단계는 plan 본문 상단 안내대로 subagent-driven 또는 inline 실행.

22 KiB Raw Blame History

branch-depth-gate Implementation Plan

제약 (이 plan 전체에 적용)

File Structure

Task 1: 기준 SSOT — rules/branch-depth-gate.md

Task 2: 감사기 — .claude/agents/branch-depth-auditor.md

Task 3: 커맨드 — .claude/commands/depth.md

Task 4: 템플릿 캡처 칸 — templates/branch-note-template.md

Task 5: 워크플로우 진입점 등재 — CLAUDE.md, AGENTS.md

Task 6: 픽스처 회귀 — 게이트 보정

Self-Review (작성자 점검 결과)

Execution Handoff

22 KiB

Raw Blame History

Task 1: 기준 SSOT — `rules/branch-depth-gate.md`

Task 2: 감사기 — `.claude/agents/branch-depth-auditor.md`

Task 3: 커맨드 — `.claude/commands/depth.md`

Task 4: 템플릿 캡처 칸 — `templates/branch-note-template.md`

Task 5: 워크플로우 진입점 등재 — `CLAUDE.md`, `AGENTS.md`