diff --git a/.claude/rules/07-workflow.md b/.claude/rules/07-workflow.md
index edc112bc..85274037 100644
--- a/.claude/rules/07-workflow.md
+++ b/.claude/rules/07-workflow.md
@@ -1,586 +1,85 @@
-# AI 작업 진행 규약
+# AI 작업 진행 규약 — 본 프로젝트 전용 사항
 
-이 문서는 Claude / Copilot 등 AI 협업 도구가 본 프로젝트에서 작업을 진행할 때 따라야 하는
-**workflow 규약** 입니다. 작업 도중 사용자 승인을 빈번히 요청하여 흐름이 끊기는 문제를
-해소하고, AI 의 자율성과 안전성의 균형을 명문화합니다 (이슈 #152).
+공통 규약은 사용자 레벨 하네스 **`~/.claude/rules/`** 가 기본값이다 (2026-10-11 이관, 이슈 #672).
+본 저장소의 구 규약 1~8 (이슈 #152 · #199 · #210 · #212 · #665 · #667 · #669) 이 그 원형이다.
+이 문서는 본 저장소에만 있는 값과 공통 규약과 다르게 하는 점만 적는다.
 
-본 규약은 코드 스타일 / 아키텍처 / 테스트 등 **무엇을 만드느냐** 가 아니라, **어떻게
-진행하느냐** 를 다룹니다. 코드 자체의 규약은 [01-architecture.md](01-architecture.md) ~
-[06-code-style.md](06-code-style.md) 참조.
+> `~/.claude` 가 없는 환경 — GitHub Action [`claude.yml`](../../.github/workflows/claude.yml) 은 저장소만 체크아웃한다 — 에는 공통 규약이
+> 로드되지 않는다. 그 환경에서는 [CLAUDE.md](../../CLAUDE.md) 의 "반드시 지킬 규칙" (CI 강제) 과 이 문서, 저장소 규칙 01~06 이 적용되고,
+> 서브 에이전트 위임은 하지 않는다. 하네스를 Action 에 체크아웃할지는 별도 결정 (이슈 #672 TODO).
 
 <br>
 
-## 핵심 8 규약
+## 구 규약 번호 → 공통 하네스 대응표
 
-### 1. 이슈 먼저 (issue-first) 생성 정책
+기존 이슈 · PR · 문서 · 스크립트 주석이 "규약 N" 으로 참조한다. 번호는 그대로 쓴다.
 
-사용자 작업 지시가 도착하면 **코드 수정 시작 전에 GitHub 이슈를 먼저 생성** 한다 (이슈 #199).
-
-#### 원칙
-
-- 모든 작업은 GitHub 이슈로 추적 — branch / commit / PR 모두 그 이슈를 참조
-- **이슈 생성 시 Label · Issue Type 부여 필수** (규약 6 매핑 표 참조)
-- **규모가 PR 1개로 reviewable diff 안 되면 메인 이슈 + sub-issue N개로 분할** 하여 모두 사전에 생성
-  - 메인 이슈 본문에 전체 그림 + sub-issue 목록 + 완료 조건 명시
-  - **GitHub 의 Sub-issue 기능 + Relation 적극 활용** — `gh api graphql` 의 `addSubIssue` mutation 으로 메인 ↔ sub 관계 활성화하여 GitHub UI 에서 계층 명시
-  - 본문 link (`Parent: #<메인>`) 만으로 표기하던 기존 방식은 보조용. native sub-issue 가 우선
-  - **제약: sub-issue 는 부모를 1개만 가진다.** 이미 다른 메인 이슈의 sub 인 이슈를 새 메타에
-    붙이려 하면 `Sub issue may only have one parent` 로 거부됩니다. 이 경우 기존 부모를 유지하고
-    새 메타 본문에서 **참조만** 하세요 (표에 "기존 — 부모 #N 유지, 본 메타는 참조만" 표기).
-    부모를 옮기는 것은 기존 계층을 바꾸는 일이라 사용자 확인 대상입니다.
-- 각 sub-issue 단위로 `branch → 작업 → commit → PR` 사이클 반복
-- PR closing reference 는 그 sub-issue (`Closes #<sub>`). 메인 이슈는 모든 sub-issue 가 close 될 때까지 OPEN 유지하고 마지막 sub-issue PR 에서 함께 close
-
-#### Why
-
-- 작업 진입 전 사용자와 scope 합의가 강제됨 → 작업 도중 방향 이탈 / scope creep 회피
-- ad-hoc 으로 PR 직전에 이슈 만드는 패턴 차단 (기존 사례: PR #181 / #183 / #189 / #191 — closing reference 가 필요해서 PR 직전 즉흥 sub-issue 생성)
-- 메인 이슈와 sub-issue 의 계층 관계가 GitHub 상에서 명확히 link
-
-#### 예외
-
-- 사용자가 명시적으로 **"이슈 없이 진행해"** / **"단발 hotfix"** 라고 지시한 경우
-- 1줄 typo 수정 / 명백한 작은 chore (사용자 동의 없이 진행해도 손실 적음 — 단, PR 타이틀 규약 준수를 위해 작업 시작 전 이슈 생성)
-
-#### 판단 모호 시
-
-규모가 작아 보이더라도 **이슈 1개 생성** — 작업 끝난 후 PR 본문 정리할 때 추가 비용 거의 없음.
-"이거 큰가?" 가 50/50 이면 **메인 + sub-issue 분할 쪽** 으로 보수 분류.
-
-#### Sub-issue 등록 명령
-
-> 규약 6 의 "`gh api graphql` 직접 호출은 사용하지 않는다" 는 **Label · Issue Type 부여** 에
-> 대한 규칙입니다 (그쪽은 `scripts/gh-meta.sh` 가 대체). sub-issue relation 은 아직 스크립트가
-> 없어 아래 graphql 호출을 그대로 사용합니다 — 두 규약은 충돌하지 않습니다.
-
-
-```bash
-# 메인 이슈에 sub-issue 등록 (Relation 자동 활성화)
-MAIN_ID=$(gh issue view <MAIN_NUMBER> --json id --jq .id)
-SUB_ID=$(gh issue view <SUB_NUMBER> --json id --jq .id)
-
-gh api graphql -f query='
-mutation($issueId: ID!, $subIssueId: ID!) {
-  addSubIssue(input: {issueId: $issueId, subIssueId: $subIssueId}) {
-    issue { number }
-    subIssue { number }
-  }
-}' -f issueId="$MAIN_ID" -f subIssueId="$SUB_ID"
-```
-
-<br>
-
-### 2. 자율 진행 정책 — 승인 요청 최소화
-
-쿼리의 의도가 명확하면 AI 는 **사용자 승인 없이 진행** 한다. 
-> **핵심 원칙 1**: 아래 "자율 진행 영역"에 해당하는 작업은 **절대 사용자 확인을 요청하지 않는다.**
-> 스크립트 실행, 파일 수정, 커밋, 브랜치 생성 등은 묻지 않고 즉시 실행한다.
-> 이미 허용된 도구(`Bash`, `Edit`, `Write`, `gh`, `git`, `make` 등)는 추가 승인 없이 사용한다.
-> **핵심 원칙 2**: 최대한 자율적으로 진행하되, "예외 영역"에 해당하는 작업은 반드시 사용자 확인을 받는다.
-다음 4가지 영역만 예외로
-사용자 확인을 받는다:
-
-#### 예외 영역 (반드시 사용자 확인)
-
-| 영역 | 예시 |
-|---|---|
-| **시스템 자체 변경** | OS / 패키지 / 글로벌 환경 변경 (`apt-get install`, `sudo systemctl`, 시스템 서비스 enable 등) |
-| **언급 없는 destructive 권한** | `git push --force`, branch 삭제, DB `DROP TABLE`, `git reset --hard`, 무인 PR merge |
-| **외부 시스템 영향** | PR merge / issue close / 배포 트리거 / 외부 API 비용 결제 / 외부 DM 발송 |
-| **모호한 작업 범위** | 사용자 의도가 다중 해석 가능하거나 scope 가 불명확한 경우 — 진행 전 구체화 질문 |
-
-#### 자율 진행 영역 (승인 불필요 — 즉시 실행)
-
-- 코드 작성 / 수정 / 리팩토링 / 삭제
-- 테스트 추가 / 갱신
-- 새 파일 / 디렉토리 생성
-- DB migration 작성 (단 `DROP` 류는 예외 — 위 destructive 영역)
-- 의존성 추가 (`go get`) — 단 신규 외부 모듈은 규약 4 적용
-- Branch 생성, 정상 push (force-push 아닌)
-- Commit 단위 결정 및 실행
-- **구조 변경 시 `make harness-check` 통과 확인** — cmd 추가/삭제, 디렉토리 이동, Go 버전 변경,
-  CI 임계값 변경 등은 규약 문서도 같이 고쳐야 한다 (이슈 #539). 문서가 낡으면 다음 세션의 AI 가
-  잘못된 전제를 받는다.
-- PR 본문 작성
-- **`scripts/` 하위 스크립트 실행** — 프로젝트 도구는 경로 확인 없이 실행
-- **이슈 / PR Label · Type 부여** — `scripts/gh-meta.sh` 활용, 별도 승인 불필요
-- **lint / fmt / test / build** — `make` 또는 `scripts/lint.sh` 실행, 경로 확인 불필요
-- **서브 에이전트 spawn** — 규약 8 의 티어 · 동시 상한 안에서는 확인 불필요
-
-#### 판단 모호 시
-\"이게 destructive 영역인가?\" 가 50/50 이면 **사용자 확인 쪽으로 보수 분류**. 단,
-이미 자율 진행 영역으로 열거된 항목은 50/50 이 아니다 — 확인 없이 진행한다.
-
-<br>
-
-### 3. Commit-per-TODO 정책
-
-별다른 사용자 언급이 없으면, AI 는 작업을 **논리적 변경 단위 (TODO)** 마다 commit 한다.
-
-> **금지**: 작업을 모두 완료한 뒤 한 번에 몰아서 커밋하는 것은 **절대 허용하지 않는다.**
-> 논리적 변경 단위가 완성되는 즉시 커밋한다. 커밋을 뒤로 미루지 않는다.
-
-#### 원칙
-
-- 논리적 변경 단위 완성 → **즉시 커밋** (다음 단위 작업 시작 전)
-- 큰 PR 도 reviewable diff 단위로 분할 commit
-- 각 commit 메시지는 [06-code-style.md](06-code-style.md) 의 컨벤션 준수:
-  - **Prefix 는 다섯 가지 중 택 1**: `[FEAT]:` / `[FIX]:` / `[REFAC]:` / `[DOCS]:` / `[CHORE]:`
-  - 이후 한국어 + 변경 의도
-  - 단일 commit 이 너무 큰 변경을 담지 않도록
-- 빌드 그린 유지 — 각 commit 이 컴파일 + 테스트 통과 가능한 상태
-
-#### 잘못된 패턴 (금지)
-
-```text
-# BAD — 작업 완료 후 모아서 한 번에 커밋
-[파일 A 수정] → [파일 B 수정] → [파일 C 수정] → 커밋 하나로 묶음
-```
-
-#### 올바른 패턴
-
-```text
-# GOOD — 논리 단위마다 즉시 커밋
-[파일 A 수정 — 기능 X 구현] → 커밋
-[파일 B 수정 — 기능 Y 구현] → 커밋
-[파일 C 수정 — 테스트 추가] → 커밋
-```
-
-#### 예외
-
-- 사용자가 명시적으로 \"한 번에 묶어줘\" / \"squash 해줘\" 요청 시 단일 commit
-- 사용자가 \"단일 fix 만 해줘\" 등 명백한 단일 변경을 지시한 경우
-
-#### 예시
-
-```bash
-git log --oneline (refactor/#148 PR 의 5 commits 패턴)
-fc95aec [FIX]: 피드백 반영, all-pass 모드 PathPrefixes 검증 + discovery vs fallback 명확 구분
-2a063e8 [FIX]: 피드백 반영, LinkDiscoveryConfig 주석 + migration 008 주석 일관성
-6491d20 [REFAC]: MaxLinksPerPage 정책 변경 — same-origin 무제한 + cross-origin random sample
-4cfc9a4 [FEAT]: migration 008 — 운영 사이트 list rules all-pass 모드 + ExcludePatterns 강화
-9f7cbb6 [FEAT]: discovery 테스트 갱신 — all-pass 모드 케이스 추가
-```
-
-<br>
-
-### 4. PR 자동 생성 정책
-
-작업 완료 직후 (별다른 언급 없으면) AI 는 **PR 을 자동 생성** 한다.
-
-#### 컨벤션 + 템플릿 준수
-
-- **PR 타이틀**: `[카테고리#이슈번호] 제목` 정규식 (이슈 #121, CI 강제)
-- **본문**: [.github/PULL_REQUEST_TEMPLATE.md](../../.github/PULL_REQUEST_TEMPLATE.md) 의 모든 섹션 채움
-  - 연관 이슈 (`Closes #N` — closing reference 명시)
-  - 구현 내용
-  - CI / 머지 게이트 점검
-  - 변경 영향 범위 + 위험도
-  - 롤백 계획
-- **이슈 링크**: PR 본문 또는 Development sidebar 에 closing reference
-- **Label 부여 필수**: 규약 6 매핑 표에 따라 PR 에도 동일 label 부여 (`gh pr create --label <label>` 또는 생성 직후 `gh pr edit --add-label`)
-
-#### PR 생성 직후 피드백 대응 (이슈 #548 — 구 #129 cron 방식 폐지)
-
-[CLAUDE.md](../../CLAUDE.md#pr-생성-후-피드백-대응-이슈-548--구-129-cron-방식-폐지) 참조. 요약:
-
-- **세션이 살아있으면** `Monitor` 로 CI·코멘트를 감시하고 그 세션에서 처리 — 작업 맥락 보존
-- **세션을 닫은 뒤 / 타인 리뷰** 는 `@claude` 멘션 → [`.github/workflows/claude.yml`](../../.github/workflows/claude.yml) (이슈 #549). write 권한 보유자만 트리거 가능, 봇은 기본 차단
-- **cron 자동 등록 금지** — 사용자가 명시적으로 요청하지 않는 한 `CronCreate` 를 호출하지 않는다
-
-구 규약은 `gh pr create` 직후 loop.md (현재 삭제됨) 를 3분 cron 으로 자동 등록했다. cron 이 띄우는
-새 세션은 PR diff 만 보고 판단해 "왜 그렇게 구현했는지" 를 잃고, 토큰이 누적되며, 자체 상태
-기계를 유지해야 했다. 세션 내 처리와 GitHub Action 두 경로로 대체됐다.
-
-#### 예외
-
-- 작업이 이슈와 무관한 단발성 chore (예: 작은 hotfix, 운영 스크립트) — 사용자가 \"이슈 없이
-  PR 올려줘\" 또는 \"이슈 먼저 만들어줘\" 명시
-- 작업이 PR 단위가 아닌 운영 명령 (예: migration 적용, log 분석) 만 요청한 경우
+| 구 규약 | 내용 | 공통 하네스 (`~/.claude/rules/`) | 본 프로젝트 전용 (아래 절) |
+|---|---|---|---|
+| 1 | 이슈 먼저 · sub-issue 분할 | `01-workflow.md` 1절, `03-conventions.md` Sub-issue 연결 | — |
+| 2 | 자율 진행 · 예외 4영역 | `01-workflow.md` 2절 | 자율 영역 추가 항목 |
+| 3 | Commit-per-TODO | `01-workflow.md` 3절 | — |
+| 4 | PR 자동 생성 · 생성 후 피드백 | `01-workflow.md` 4절, `06-pr-feedback.md` | 도구 · `claude.yml` |
+| 5 | 권한 최소화 | `01-workflow.md` 5절 | — |
+| 6 | Label · Issue Type · 접두사 3분리 | `03-conventions.md` | `scripts/gh-meta.sh` · Issue Type ID |
+| 7 | 설계 변경 · 의사 결정 기록 (ADR) | `07-decisions.md` | Notion DB |
+| 8 | 오케스트레이션 · 역할 군 · 티어 | `02-orchestration.md`, 역할 정의 `~/.claude/agents/` | operator 범위 · PR 작업 분배 표 |
 
 <br>
 
-### 5. 권한 사용 최소화
+## 규약 2 — 자율 진행 영역 추가 항목
 
-자율 진행 시, **꼭 필요한 경우가 아니면 이미 허용된 권한 범위 내에서만 동작** 한다.
+공통 목록에 더해 다음도 확인 없이 한다:
 
-#### 원칙
-
-- 새 `Bash(...)` permission 요청은 작업 완수에 불가피한 경우에만
-- 동등 효과를 낼 수 있는 기존 허용 도구가 있으면 그것을 우선 사용 — 새 외부 도구 설치 X,
-  기존 `gh` / `go` / `git` / `make` 등 활용
-- `WebFetch` / `WebSearch` 도 새 도메인은 작업 명시적 필요 시에만
-- 신규 외부 의존성 (Go module / system package) 추가는 **규약 1 의 \"모호 영역\"** 으로 간주
-  → 사용자 사전 확인
-
-#### 이유
-
-- 누적 권한이 늘어날수록 `.claude/settings.local.json` 의 entries 가 비대해져 정리 비용 증가
-- 정리 사례: 86 entries → 30 entries (이슈 #152 작업 직전 정리)
-- 잘못된 도구 도입은 보안 노출 위험 증가 (예: 토큰 노출, 시스템 파괴 명령)
+- **구조 변경 시 `make harness-check` 통과 확인** — cmd 추가/삭제, 디렉토리 이동, Go 버전 변경, CI 임계값 변경 등은
+  규약 문서도 같이 고쳐야 한다 (이슈 #539). 문서가 낡으면 다음 세션의 AI 가 잘못된 전제를 받는다.
+  harness-check 자체를 고쳤으면 `make harness-selftest` 로 검출력을 확인한다 (이슈 #565) — "경고 0건" 은 통과가 아니다.
+- `scripts/` 하위 도구 실행, `make` · `scripts/lint.sh` 실행.
+- 의존성 추가 `go get` — 단 신규 외부 모듈은 사전 확인 (규약 5).
 
 <br>
 
-### 6. 이슈 / PR 분류 메타데이터 정책 — Label · Issue Type
-
-이슈 / PR 생성 시 **항상 Label 부여** (필수). 이슈는 추가로 **Issue Type 부여** (필수).
-분류·필터링·자동화 (예: hotfix 라벨로 우선순위 알림) 가 누락되지 않도록 일관 매핑 적용.
+## 규약 4 · 6 — 도구
 
-#### Prefix 표기 체계 (commit / PR / 이슈 — 3 분리 설계)
-
-본 repo 는 commit / PR / 이슈 제목의 prefix 를 **의도적으로 다른 표기** 로 운용한다.
-
-| 위치 | 형식 | 예시 | 강제 |
-|---|---|---|---|
-| Commit message | `[FEAT]:` / `[FIX]:` / `[REFAC]:` / `[DOCS]:` / `[CHORE]:` (축약 + 콜론) | `[FIX]: 인덱스 누락 보정` | GitHub Actions Commit Lint |
-| PR title | `[FEAT#N]` / `[FIX#N]` / `[REFAC#N]` / `[DOCS#N]` / `[CHORE#N]` (commit 카테고리 + #이슈번호, 콜론 없음) | `[DOCS#212] 규약 6 정정` | GitHub Actions PR Title Lint |
-| **Issue title** | **`[FEATURE]` / `[FIX]` / `[REFACTOR]` / `[DOCS]` / `[CHORE]` / `[HOTFIX]`** (full-word, 콜론 없음) | `[FEATURE] 새 크롤러 추가` | (lint 미강제, 규약 6 운영) |
-
-**핵심 차이**: 이슈 prefix 는 commit prefix 의 축약형이 아니라 **원본 단어** 를 그대로 쓴다. 또한 commit/PR 에는 없는 `[HOTFIX]` 가 이슈 prefix 에만 존재 — 배포 중 긴급 대응이라는 별도 카테고리. 이 표기 차이는 의도된 설계이며, 본 규약 6 의 매핑 표는 **이슈 prefix → Label/Type** 매핑이다.
-
-#### Label 매핑 (이슈 prefix 기준)
-
-| Issue prefix | 기본 Label | 추가 Label (조건부) |
+| 용도 | 수단 | 비고 |
 |---|---|---|
-| `[FEATURE]` | `enhancement` | — |
-| `[REFACTOR]` | `refactor` | — |
-| `[CHORE]` | `chore` | — |
-| `[DOCS]` | `documentation` | — |
-| `[FIX]` (일반 에러 이슈) | `bug` | — |
-| `[HOTFIX]` (배포 중 긴급) | `bug` | + `hotfix` |
-
-PR 의 Label 은 그 PR 이 닫는 이슈 (`Closes #N`) 의 Label 과 동일하게 부여한다.
-
-#### Issue Type 매핑 (이슈 전용)
-
-GitHub Issue Type 은 라벨과 별개의 native 분류 — `gh api graphql` 의 `updateIssueIssueType` mutation 으로 부여.
-
-| Issue prefix | Issue Type |
-|---|---|
-| `[FEATURE]` | `Feature` |
-| `[FIX]` / `[HOTFIX]` | `Bug` |
-| `[REFACTOR]` / `[CHORE]` / `[DOCS]` | `Task` |
-
-본 repo 의 Issue Type ID:
-- `Feature` → `IT_kwDODsDQh84By0jb`
-- `Bug` → `IT_kwDODsDQh84By0ja`
-- `Task` → `IT_kwDODsDQh84By0jZ`
-
-#### 부여 명령 예시
-
-> **`scripts/gh-meta.sh` 를 사용한다** — title prefix 기반으로 Label · Issue Type 을 자동 부여하는 전용 스크립트. 수동 `gh api graphql` 호출 대신 항상 이 스크립트를 사용한다.
-> - **이슈**: Label + Issue Type 동시 부여 (`scripts/gh-meta.sh issue <N>`)
-> - **PR**: Label 만 부여 (`scripts/gh-meta.sh pr <N>`) — PR 에는 Issue Type 없음
-
-**이슈 생성 시 Label + Type 부여 (생성 직후)**:
-```bash
-# 이슈 생성 (--label 은 생략 가능 — gh-meta.sh 가 title prefix 로 자동 판단)
-gh issue create --repo EinSofINTEREST/IssueTracker \
-  --title "[DOCS] 제목" \
-  --body "..."
-
-# Label + Issue Type 일괄 부여 (이슈 번호 지정)
-scripts/gh-meta.sh issue <ISSUE_NUMBER>
-```
-
-다른 issue prefix 예: `[FEATURE] 새 크롤러`, `[REFACTOR] 모듈 분리`, `[HOTFIX] 배포 직후 데드락`.
-
-**PR 생성 후 Label 부여**:
-```bash
-gh pr create --title "[DOCS#N] 제목" --body "..."
+| 이슈 Label + Issue Type | `scripts/gh-meta.sh issue <N>` | title prefix 로 자동 판정. 수동 `gh api graphql` 금지 (이슈 #243) |
+| PR Label | `scripts/gh-meta.sh pr <N>` | 닫는 이슈의 Label 과 동기화 |
+| 리뷰 코멘트 처리 완료 표시 | `scripts/pr-resolve-comments.sh <PR> <comment_id...>` | 👀 + resolve 일괄 — 개별 `gh api` 호출 회피 |
+| sub-issue 연결 | `gh api graphql` `addSubIssue` (공통 `03-conventions.md` 의 명령) | 스크립트 없음 — 직접 호출 허용. 규약 6 의 "graphql 직접 호출 금지" 는 Label · Type 에 한정 |
+| 세션 종료 후 피드백 | 이슈 · PR 코멘트에 `@claude` → [`claude.yml`](../../.github/workflows/claude.yml) | write 권한 보유자만, 봇은 차단 (이슈 #549) |
 
-# PR Label 부여 (닫는 이슈의 Label 과 자동 동기화)
-scripts/gh-meta.sh pr <PR_NUMBER>
-```
+Issue Type ID (본 repo): `Feature` → `IT_kwDODsDQh84By0jb` / `Bug` → `IT_kwDODsDQh84By0ja` / `Task` → `IT_kwDODsDQh84By0jZ`.
+`scripts/gh-meta.sh` 상수로 관리한다 — 변경 시 스크립트 갱신.
 
-#### Why
-
-- Label 누락 시 GitHub Issues / PR 필터링이 무력화 — `is:issue label:bug` 같은 운영 쿼리가 불완전
-- Issue Type 은 native 분류로, label 보다 강한 시멘틱 (Project Roadmap 의 Type 컬럼 자동 반영)
-- `hotfix` 라벨은 배포 게이트 우선순위 알림 / Slack 라우팅 트리거에 활용 가능
-
-#### How to apply
-
-- **이슈 생성 직후** `scripts/gh-meta.sh issue <N>` 호출 — Label + Type 동시 부여, 까먹지 않도록 생성 직후 같은 회차에서 처리
-- **PR 생성 직후** `scripts/gh-meta.sh pr <N>` 호출 — 닫는 이슈의 Label 과 자동 동기화
-- 매핑이 모호하면 (예: refactor 인데 bug 도 같이 잡는 PR) 가장 큰 변경 의도 prefix 기준으로 분류 + 보조 label 추가 가능
-- `gh api graphql` 직접 호출은 사용하지 않는다 — `gh-meta.sh` 로 표준화
-
-### 7. 설계 변경·의사 결정 기록 정책 — Notion ADR
-
-설계 변경과 의사 결정은 **전부** Notion `설계 결정 기록` 데이터베이스에 기록한다 (이슈 #665).
-한 행 = 결정 하나. 이슈·PR 본문의 근거 서술은 그대로 두고, Notion 은 **결정만 모아 보는 색인** 이다.
-
-- 데이터베이스: [설계 결정 기록](https://app.notion.com/p/90f54429790347b3942b1e13ea34b145) — `최근 PR` 과 같은 `IssueTracker` 페이지 아래
-- data source id: `8f5b163d-397a-4182-8b14-2546ffb4a16b` (스크립트 기본값 · `NOTION_DECISION_DS_ID` 로 override)
-
-#### 기록 대상
-
-| 기록한다 | 기록하지 않는다 |
-|---|---|
-| 아키텍처 · 모듈 경계 변경 | 버그 수정 (원인·수정이 이슈에 있다) |
-| 외부 의존성 · 서비스 채택 / 폐기 | 이름 · 파일 위치 같은 국소 판단 |
-| 데이터 흐름 · 스키마 정책 변경 | 규약을 그대로 따른 결과 |
-| 규약 자체의 추가 / 변경 | |
-| 되돌리기 어려운 운영 정책 (재시도 상한 · DLQ · 보존 기간 · 기본 bind) | |
-| **"두 안 중 하나를 고른" 모든 경우** — 다른 안이 합리적이었을수록 반드시 | |
-
-50/50 이면 **기록하는 쪽**. 한 행 쓰는 비용은 작고, 빠진 결정은 나중에 복원할 수 없다.
-
-#### 언제
-
-- **결정이 내려진 즉시.** PR 생성 전 — PR 본문에 Notion 행 링크를 넣는다
-- 사용자 승인이 필요한 결정 (규약 2 예외 영역) 은 **승인 직후**, 결정자 = `사용자` 또는 `AI 제안 · 사용자 승인`
-- 규약 안에서 AI 가 스스로 고른 결정은 결정자 = `AI 자율 (규약 내)` — 사용자가 사후에 볼 수 있게
-- 결정이 뒤집히면 새 행을 만들고 **기존 행의 상태를 `폐기` / `대체됨` 으로 바꾼다.** 기존 행을 지우지 않는다
-
-#### 어떻게
-
-- **AI 세션**: Notion MCP 로 직접 기록 (`notion-create-pages`, parent = data source `8f5b163d-397a-4182-8b14-2546ffb4a16b`)
-- **토큰이 있는 환경** (사람의 로컬 셸): `scripts/notion-decision.py add ...` — `notion_pr_sync.py` 와 같은 요청 헬퍼·재시도 정책 (이슈 #563).
-  CI `@claude` 경로는 [`claude.yml`](../../.github/workflows/claude.yml) 이 `NOTION_API_TOKEN` 을 step `env` 로 넘기지 않아 **현재는 기록할 수 없다** — 넘길지는 별도 결정 (secret 등록 + 워크플로 변경)
-- 두 경로는 같은 DB 에 같은 형식으로 쓴다. 수동 `curl` 은 쓰지 않는다 (이슈 #243 과 같은 원칙)
-
-#### 형식
-
-속성: `제목` · `날짜` (결정한 날, 기록한 날 아님) · `유형` (설계 변경 / 의사 결정 / 규약 / 기술 선택 / 운영 정책) ·
-`상태` (제안 / 채택 / 폐기 / 대체됨) · `영역` · `관련 이슈` (`#번호`, 메인 이슈 앞에) · `PR` · `결정자` · `요약` (한 줄 — 무엇을 골랐고 무엇을 버렸는지)
-
-본문은 ADR 구성을 따른다. 여섯 항목 중 **"검토한 대안"** 을 빼먹지 않는다 — 결정의 가치는 버린 안에 있다.
-
-```
-## 맥락        왜 이 결정이 필요해졌나
-## 결정        무엇을 하기로 했나 (번호 목록)
-## 근거        왜 그 안인가 — 기존 패턴·이슈 번호로
-## 검토한 대안  버린 안과 버린 이유
-## 결과·영향   무엇이 바뀌고, 무엇이 미결로 남나
-## 되돌리기    어떻게 원복하나
-```
-
-#### Why
-
-- 근거는 이슈 · PR 에 적어 왔지만 **결정만 모아 보는 곳이 없었다.** "왜 이렇게 됐지" 를 알려면 이슈 수백 개를 뒤져야 했다
-- 결정 하나가 이슈 여러 개에 걸치고 (#603 / #648 의 재시도 상한), 이슈가 닫히면 결정도 묻힌다
-- 규약 문서에 있어야 매 세션 AI 가 전제로 받는다 — 문서 밖의 관행은 세션이 바뀌면 사라진다
+cron loop 는 폐지됐다 (이슈 #548, 구 #129). 폐지된 자산 (`loop.md` · `pr-feedback.md` · `pr-feedback.sh`) 이 되살아나거나
+규약이 cron 등록을 지시하면 `make harness-check` 7절이 FAIL 한다.
 
 <br>
 
-### 8. 오케스트레이션 정책 — 메인 세션 · 서브 에이전트 · 모델 차등 배분
-
-메인 세션은 **오케스트레이터** 다. 사용자와 소통하고, 설계·결정·통합 같은 고차원 작업을 직접 하고,
-하위 작업은 서브 에이전트에 위임한 뒤 그 산출물을 **검수** 한다 (이슈 #667). 하위 작업은
-**난이도 × 중요도** 로 분류하고, 분류에 따라 모델을 차등 배분한다.
-
-#### 역할 분리
-
-| 메인 세션이 직접 한다 | 서브 에이전트에 위임한다 | 절대 위임하지 않는다 |
-|---|---|---|
-| 사용자 소통 — 질문 · 확인 · 보고 | 범위가 닫힌 구현 — 함수 · 패키지 · 테스트 단위 | 규약 2 예외 영역의 판단 (destructive · 시스템 · 외부 영향 · 모호) |
-| 작업 분해 — 이슈 / sub-issue 설계, 티어 배분 | 넓은 코드베이스 탐색 — "어디서 X 를 하나" 류 | 결정 — "두 안 중 하나" 는 메인이 고르고 규약 7 로 기록 |
-| 설계 · 아키텍처 · 규약 결정 (규약 7) | 독립 리뷰 — 메인의 결론을 주지 않고 코드만 넘긴다 | 커밋 · push · PR · 이슈 생성 · Notion 기록 |
-| 통합 — 위임 결과를 합치고 충돌을 푼다 | 기계적 변경 — rename · 포맷 · 로그 필드 정리 · 문서 동기화 | 최종 검수 — 서브 에이전트의 자기 검수로 대체하지 않는다 |
-| 검수 · 커밋 · PR · CI 대응 (이슈 #548) | 반복 작업 — 같은 패턴을 N개 파일에 적용 | |
-
-서브 에이전트는 **작업 트리를 바꾸고 보고한다.** 그 변경을 커밋하는 것은 검수를 마친 메인이다 —
-규약 3 (논리 단위마다 즉시 커밋) 은 그대로다. "검수 통과" 가 커밋 시점이 된다.
-
-#### 분류 — 난이도 × 중요도 → 티어
-
-- **난이도 신호**: 판단 분기 수 / 걸치는 패키지 수 / 따라 쓸 선례 (기존 패턴) 유무 / 틀렸을 때 디버깅 비용 /
-  동시성 · 락 · 버스 · 스키마에 닿는지
-- **중요도 신호**: 되돌리기 비용 / 운영 영향 (데이터 손실 · 외부 호출 · 비용) / 다른 하위 작업의 선행 조건인지 /
-  규약 2 예외 영역에 닿는지
-
-| | 중요도 낮음 | 중요도 높음 |
-|---|---|---|
-| **난이도 낮음** | **T3** 경량 | **T2** 중위 — 검수는 전수 |
-| **난이도 높음** | **T2** 중위 | **T1** 상위 — 설계 판단이 섞이면 **T0** 메인 직접 |
-
-50/50 이면 **상위 티어**. 티어를 내리면 비용이 줄지만, 틀린 결과를 검수하고 재지시하는 비용이 더 크다.
-
-#### 모델 선정 기준 — 티어 판정
-
-매트릭스의 "낮음 / 높음" 은 아래 기준으로 판정한다. 한 티어의 기준을 **하나라도** 넘으면 그 티어 이상이다.
-
-| 티어 | 판단의 성격 | 범위 | 선례 | 틀렸을 때 | 전형적 작업 |
-|---|---|---|---|---|---|
-| **T3** | 판단이 거의 없다 — 정답이 하나로 정해져 있고 결과를 기계적으로 검증할 수 있다 (`gofmt` · grep · 목록 대조) | 파일 수 개, 패키지 1개 | 불필요 | 재실행 비용 분 단위, 운영 영향 없음 | 탐색 · 목록화 · rename · 포맷 · 로그 필드 정리 · 문서 오타 · 결과 요약 |
-| **T2** | 판단은 "선례를 어디까지 적용하나" 수준 — 저장소 안에 따라 쓸 패턴이 있고 완료 조건을 테스트로 확인할 수 있다 | 패키지 1 ~ 2개 | 저장소 안에 있다 | 테스트가 잡는다. 디버깅 비용 분 ~ 수십 분 | repository · worker 추가, 테스트 작성, 선례 따른 리팩토링, 문서 동기화, 같은 패턴 N개 반복 |
-| **T1** | 선례가 없거나 여러 선례가 충돌한다 — 접근을 골라야 하고, 틀린 선택이 테스트를 통과할 수 있다 | 패키지 여러 개에 걸침 | 없거나 충돌 | 디버깅 비용 시간 단위, 운영 영향 가능 (데이터 · 외부 호출 · 비용) | 동시성 · 락 · 버스 · 스키마 변경, 원인 불명 디버깅, 독립 코드 리뷰, 성능 작업 |
-| **T0** | 설계 · 규약 · "두 안 중 하나" · 사용자와의 합의가 필요한 판단, 또는 규약 2 예외 영역 | 전체 | — | 되돌리기 어렵다 | 아키텍처 · 규약 변경 · 모호한 범위 · 검수 · 통합 |
-
-- "전형적 작업" 열은 **전형** 이지 정의가 아니다 — 같은 "테스트 작성" 이라도 동시성 테스트는 T1 이다
-- 기준이 두 티어에 걸치면 (예: 범위는 T2, 틀렸을 때는 T1) **위쪽** 으로 판정한다 — 50/50 규칙과 같다
-
-#### 기준은 기준이다 — 한 단계 조정
+## 규약 7 — 결정 기록 위치
 
-난이도와 중요도는 **작업 전 추정** 이고 유동적이다. 작업 중 신호가 바뀌면 티어를 **한 단계** 위나 아래로
-조정할 수 있다.
-
-| 올린다 (T3 → T2, T2 → T1, T1 → T0) | 내린다 (T1 → T2, T2 → T3) |
-|---|---|
-| 브리프를 쓰다 보니 판단 분기가 늘었다 / 선례가 맞지 않는다 | 메인이 범위를 더 좁게 잘라 판단을 제거했다 |
-| 검수에서 결함이 나왔다 (실패 경로 ②) | 선례가 사실상 그대로 옮기는 수준이다 |
-| 다른 하위 작업의 선행 조건이라 틀리면 뒤가 전부 막힌다 | 같은 패턴을 상위 티어가 한 번 성공해 패턴이 확정됐다 — 반복 N개의 2번째부터 |
-| 사용자가 중요도를 올려 말했다 | 산출물이 읽기 전용 (탐색 · 요약) 이고 메인이 전수 검수한다 |
-
-- **한 번에 한 단계.** 두 단계가 필요하면 분류가 틀린 것이다 — 다시 분류하고 브리프를 다시 쓴다
-- T0 로 올리는 것은 "위임하지 않는다" 는 뜻이다. T0 에서 내리는 것은 없다 — 설계 · 규약 · 결정은 위임 대상이 아니다
-- 조정하면 PR "작업 분배" 표에 `T2 → T1 (사유)` 처럼 적는다. 이 기록이 쌓여야 기준 자체를 고칠 근거가 된다
-- 조정은 **그 작업 한 건** 에만 적용된다. 같은 종류의 작업이 반복해서 조정되면 기준이 틀린 것이다 — 기준을 고친다
-  (규약 변경, 규약 7 기록)
-
-#### 티어 → 모델 매핑 (단일 출처)
-
-| 티어 | 역할 | 모델 (Agent tool `model` 인자) | 예 |
-|---|---|---|---|
-| **T0** | 메인 세션 직접 | 세션 기본 모델 — 위임 없음 | 설계 · 규약 · 사용자 소통 · 검수 · 통합 |
-| **T1** | 상위 서브 에이전트 | `opus` | 동시성 · 버스 · 락 · 스키마 변경 구현, 원인 불명 디버깅, 독립 코드 리뷰 |
-| **T2** | 중위 서브 에이전트 | `sonnet` | 선례 있는 구현 (repository · worker · 테스트 추가), 리팩토링, 문서 동기화 |
-| **T3** | 경량 서브 에이전트 | `haiku` | 탐색 (`Explore`), 목록화, rename · 포맷 · 로그 필드 정리, 결과 요약 |
-
-- 모델 이름은 바뀐다. 매핑은 **이 표 한 곳에서만** 고치고, 다른 문서는 티어 이름 (T0 ~ T3) 으로만 말한다
-- `model` 을 생략하면 세션 모델을 상속한다 — T1 로 부족하다고 판단한 일에만. 대개 그 일은 T0, 메인이 직접 할 일이다
-- 역할 정의 파일 (`.claude/agents/<역할>.md`) 은 아직 없다 — 호출 시점에 `model` 인자로 티어를 지정한다.
-  같은 역할이 반복되어 정착하면 그때 파일로 고정하고, 그 파일의 `model` 은 이 표와 일치해야 한다.
-  파일명은 아래 역할 군 표의 영문 역할명이다
-
-#### 역할 군 — 서브 에이전트에 맡길 수 있는 역할
-
-하위 작업은 아래 역할 중 **하나** 로 위임한다 (이슈 #669). 역할은 "무엇을 하나", 티어는 "어떤 모델로 하나" —
-독립된 두 축이다. 역할별 기본 티어는 아래 "역할별 기본 티어" 표에서 시작하고, 위의 한 단계 조정 규칙이 그대로 적용된다.
-
-| 역할 (영문) | 책임 | 산출물 | 위임 |
-|---|---|---|---|
-| **오케스트레이터** (orchestrator) | 사용자 소통 · 작업 분해 · 역할/티어 배분 · 검수 · 통합 · 커밋 · PR · CI 대응 | 브리프 · 검수 결과 · 커밋 · PR | **불가** — 메인 세션 전용, 세션당 하나 |
-| **아키텍트** (architect) | 모듈 경계 · 데이터 흐름 · 인터페이스 설계, 대안 비교, 규약 영향 분석 | 설계 메모 · 인터페이스 시그니처 · ADR 초안 (맥락 · 대안 · 트레이드오프) | 분석 · 초안은 가능. **결정은 메인** (규약 7 기록) |
-| **기획** (planner) | 요구 정리 · 이슈/sub-issue 분해안 · 완료 조건 · 범위 경계 · 작업 순서 | 이슈 본문 초안 · 작업 분해 표 · 완료 조건 목록 | 초안은 가능. 범위 합의와 이슈 생성은 메인 |
-| **자료조사** (researcher) | 코드베이스 탐색 · 선례 수집 · 외부 문서/라이브러리 조사 · 비교표 작성 | 조사 보고 (출처 · 파일:라인 포함) · 선례 목록 · 비교표 | 가능 — 읽기 전용. 결론을 미리 주지 않는다 |
-| **디자인** (designer) | 스키마 · API · 설정 구조 · 프롬프트 자산 · 문서 구조의 설계 초안 (본 저장소에는 UI 가 없다 — UI 가 생기면 그때 범위를 넓힌다) | 스키마 초안 · 시그니처 · 프롬프트 초안 · 다이어그램 | 초안은 가능. 채택은 메인 |
-| **코더** (coder) | 범위가 닫힌 구현 · 리팩토링 · migration 작성 (`DROP` 류 제외) | 작업 트리 변경 · 변경 파일 목록 · 실행한 검증과 결과 | 가능 — 커밋 · push 금지 |
-| **테스터** (tester) | 테스트 작성 · 재현 케이스 · 커버리지 보강 · 벤치마크 | `test/` 아래 테스트 파일 · 실행 결과 · 커버리지 수치 | 가능 — 구현을 고치지 않는다, 결함은 보고 |
-| **QA** (qa) | 독립 코드 리뷰 · 규약 대조 (04 로깅 · 05 테스트 위치 · 06 스타일) · 결함 탐색 · 이웃 결함 감사 | 발견 목록 (파일:라인 · 심각도 · 재현 · 근거) — **수정은 하지 않는다** | 가능 — 결론을 미리 주지 않는다. **같은 변경의 코더와 다른 에이전트** |
-| **디버거** (debugger) | 원인 불명 결함 재현 · 가설 검증 · 근본 원인 보고 | 재현 절차 · 근본 원인 · 수정안 (수정은 코더에게) | 가능 |
-| **문서화** (writer) | 규약 · `docs/architecture` 동기화 · README · GoDoc · 주석 | 문서 diff · 드리프트 목록 | 가능 — `make harness-check` 통과를 산출물에 포함 |
-| **운영** (operator) | migration 적용 · DLQ 확인 · 로그 분석 · admin 도구 실행 | 실행 로그 · 상태 보고 | **변경은 불가** — 규약 2 예외 영역. 조회만 위임 |
-| **기타** (other) | 위 표에 없는 역할 — 브리프에 역할 이름과 책임을 **직접 정의** 한다 | 브리프에 명시 | 가능. 같은 역할이 **3회 이상** 반복되면 표에 추가 (규약 변경 → 규약 7 기록) |
-
-#### 역할별 기본 티어
-
-역할을 정하면 티어는 아래 표의 **기본값에서 시작** 한다. 매트릭스 판정과 한 단계 조정 규칙은 그 위에 적용된다 —
-기본값은 "이 역할의 전형적 작업이 보통 어느 티어인가" 이고, 개별 작업의 난이도 · 중요도가 다르면 한 단계 움직인다.
-
-| 역할 | 기본 티어 | 한 단계 올리는 전형 신호 | 한 단계 내리는 전형 신호 |
-|---|---|---|---|
-| **오케스트레이터** | **T0** | — | — (내리지 않는다) |
-| **아키텍트** | **T1** | 규약 · 외부 의존성 · 스키마에 닿는 설계 → T0 메인 직접 | 선례가 있는 인터페이스 확장 → T2 |
-| **기획** | **T1** | 범위가 여러 메인 이슈에 걸침 → T0 메인 직접 | 단일 sub-issue 의 완료 조건 정리 → T2 |
-| **자료조사** | **T3** | 외부 문서 · 라이브러리 비교, 출처 간 충돌 판정 → T2 | — |
-| **디자인** | **T1** | 되돌리기 어려운 스키마 · 프롬프트 계약 변경 → T0 메인 직접 | 기존 구조의 필드 추가 수준 → T2 |
-| **코더** | **T2** | 동시성 · 버스 · 락 · 스키마 · 외부 호출 → T1 | 선례를 그대로 옮기는 수준, 반복 N개의 2번째부터 → T3 |
-| **테스터** | **T2** | 동시성 · 통합 테스트, 재현이 어려운 결함 → T1 | 기존 테이블 테스트에 케이스 추가 → T3 |
-| **QA** | **T1** | — | 규약 체크리스트 대조만 (스타일 · 로그 필드 · 테스트 위치) → T2 |
-| **디버거** | **T1** | 재현 불가 · 운영 데이터 관련 → T0 메인 직접 | 테스트가 이미 재현하는 결함의 원인 추적 → T2 |
-| **문서화** | **T2** | 규약 문서의 의미 변경 → T1 (채택은 메인) | 동기화 · 오타 · 링크 수정 → T3 |
-| **운영** | **T0** | — | 읽기 전용 조회 (DLQ 개수 · 로그 검색) → T3 위임 |
-| **기타** | **T2** | 매트릭스가 난이도 높음 · 중요도 높음 → T1 | 매트릭스가 난이도 낮음 · 중요도 낮음 → T3 |
-
-- 이 표가 역할별 기본 티어의 **단일 출처** 다. 위 역할 표와 CLAUDE.md 는 티어를 적지 않는다
-- 기본 티어에서 두 단계가 필요해 보이면 역할 선택이 틀린 것이다 — 역할을 다시 고른다 (예: "코더" 로 맡기려던 일이
-  실은 설계라면 아키텍트)
-- 티어 → 모델은 위 "티어 → 모델 매핑" 표를 따른다. 이 표에는 모델 이름을 적지 않는다
-
-운용 규칙:
-
-- **한 브리프 = 한 역할.** 역할을 섞으면 (코더 + QA) 자기 검수가 되어 검수의 의미가 사라진다. 코더와 그 변경의
-  QA 는 반드시 다른 에이전트다 — 메인의 검수 (아래) 는 그 위에 더해지는 것이지 QA 를 대체하지 않는다
-- **초안 역할 (아키텍트 · 기획 · 디자인) 은 결정하지 않는다.** 대안과 트레이드오프를 가져오고, 고르는 것은 메인이다.
-  초안에 "권고안" 을 적는 것은 허용하되 메인은 그것을 결론이 아니라 입력으로 다룬다
-- **보고 역할 (자료조사 · QA · 디버거 · 테스터) 은 고치지 않는다.** 발견은 파일:라인과 근거를 붙여 보고하고, 수정은
-  코더 브리프로 분리한다 — 그래야 수정의 범위가 검수 가능하다
-- 브리프 첫 줄에 역할 이름을 적고, PR "작업 분배" 표에 **역할 열** 로 남긴다
-- 역할명은 영문 소문자 하나다 — 나중에 만들 `.claude/agents/<역할>.md` 의 파일명이 된다 (`coder.md` · `qa.md` …)
-
-#### 위임 브리프
-
-서브 에이전트는 **브리프에 적힌 것만 안다.** 브리프가 명확히 써지지 않으면 위임할 만큼 이해하지 못한
-것이다 — 메인이 먼저 파악한다.
-
-```text
-## 역할        역할 군 표의 이름 하나 (coder · qa · researcher …). 기타면 역할 이름과 책임을 여기 정의
-## 목표        한 문장. 완료 조건 포함 ("X 가 Y 를 반환하고 테스트 Z 가 통과")
-## 범위        수정 가능한 파일 · 패키지 / 건드리지 않는 영역
-## 선행 지식   읽을 파일 · 규약 문서 포인터 / 이미 배제한 안과 그 이유
-## 제약        커밋 · push 금지 / 새 의존성 금지 / 테스트 위치 (05-testing) / 로그 메시지 영어 (04-error-handling)
-## 산출물      변경 파일 목록 / 실행한 검증과 결과 / 미해결 · 판단이 필요했던 지점 / 발견한 범위 밖 결함
-```
-
-- 리뷰를 위임할 때는 **결론을 주지 않는다** — 가설을 넘기면 가설이 확인돼 돌아온다
-- 범위 밖 결함은 **고치지 말고 보고** 하게 한다 — 이웃 결함을 이슈로 분리할지는 메인이 판단한다
-
-#### 검수 — 메인 세션의 의무
-
-서브 에이전트의 보고는 틀려도 같은 어조로 온다. **보고가 아니라 결과물을 검수한다.**
-
-1. **diff 전수 재독** — 요약을 믿지 않는다. "조용히 동작하지 않는" 결함 (호출되지 않는 코드 · 잡히지 않는
-   에러 · 항상 거짓인 조건) 은 CI 를 통과하므로 재독만이 잡는다
-2. **검증 재실행** — 서브 에이전트가 돌렸다는 `make fmt / lint / test / harness-check` 를 메인이 다시 돌린다
-   (로컬에서 불가하면 CI 결과로)
-3. **브리프 대조** — 범위 밖 변경 · 빠진 완료 조건 · 금지 제약 위반
-4. **결정 회수** — 산출물 안에 "두 안 중 하나" 가 있으면 메인이 다시 판단하고 규약 7 로 기록한다.
-   서브 에이전트의 선택을 그대로 채택하는 것도 결정이다
-5. **검수 통과 → 즉시 커밋** (규약 3). 검수 전 커밋 금지
-
-검수 깊이는 티어에 비례하지 않는다 — T3 결과라도 **코드 변경이면 전수.** 샘플 확인은 읽기 전용 산출물
-(탐색 결과 · 요약) 에만 허용한다.
-
-실패 시 경로: ① 같은 에이전트에 `SendMessage` 로 피드백 (맥락 유지) → ② 2회 실패면 티어 상향
-(T3 → T2 → T1) 또는 브리프 재작성 → ③ T1 도 실패면 T0, 메인 직접. 같은 브리프를 세 번 보내지 않는다.
-
-#### 병렬화 · 비용
-
-- **독립 작업만 병렬.** 같은 파일을 두 에이전트가 만지지 않도록 범위를 나눈다. 나눌 수 없으면
-  `isolation: worktree` 로 격리하고 메인이 합친다
-- 동시 실행 상한 **3**. 토큰이 사용자가 요청하지 않은 속도로 소모된다 — 넘기려면 사용자 확인 (규약 2 의 외부 비용)
-- **위임하지 않는 경우**: 도구 호출 몇 번으로 끝나는 일 / 위치를 이미 아는 조회 / 브리프 쓰는 비용이 직접 하는
-  비용보다 큰 일. 위임은 작업 비용에 handoff 비용 (브리프 작성 + 보고 해석 + 검수) 을 더한다
-- **중복 금지** — 위임한 일을 메인이 동시에 하지 않는다. 결과를 기다린다
-- 다중 에이전트 orchestration 도구 (`Workflow`) 는 **사용자가 명시적으로 요청한 경우만** — 수십 에이전트가 뜬다.
-  규약 5 의 "새 권한" 과 같은 취급
-- 서브 에이전트 spawn 자체 (상한 내 · 티어 내) 는 **자율 진행 영역** — 사용자 확인 없이 한다 (규약 2)
-
-#### 기록
-
-PR 본문의 "작업 분배" 섹션에 하위 작업 · 역할 · 티어 · 검수 결과를 적는다
-([PR 템플릿](../../.github/PULL_REQUEST_TEMPLATE.md) 의 선택 섹션). 사용자가 배분이 적절했는지 사후에 볼 수
-있어야 배분 기준이 조정된다. 서브 에이전트를 쓰지 않은 PR 은 "없음" 으로 적는다.
-
-#### Why
-
-- 세션 하나가 전부 하면 컨텍스트가 비대해져 뒷부분의 판단 품질이 떨어진다. 위임하면 메인은 "왜" 를 유지하고
-  서브는 "어떻게" 에 집중한다
-- 모델 차등은 비용이자 품질이다 — 기계적 변경에 최상위 모델은 낭비, 동시성 버그에 경량 모델은 재작업
-- 검수 없는 위임은 결함을 **같은 어조로** 들여온다. 위임이 늘수록 검수 규약이 없으면 위험이 그만큼 늘어난다
-- 결정 권한을 메인에 모아야 규약 7 (기록) 이 성립한다 — 서브 에이전트가 흩어져 내린 결정은 기록되지 않는다
-
-#### 예외
-
-- 사용자가 "전부 직접 해" / "서브 에이전트 쓰지 마" 라고 지시하면 T0 만 사용
-- 사용자가 특정 모델을 지정하면 그 지시가 표보다 우선 — 그 세션 한정. 표 자체를 고치는 것은 규약 변경이라
-  규약 7 로 기록한다
+- 데이터베이스: [설계 결정 기록](https://app.notion.com/p/90f54429790347b3942b1e13ea34b145) — `최근 PR` 과 같은 `IssueTracker` 페이지 아래 (이슈 #665)
+- data source id: `8f5b163d-397a-4182-8b14-2546ffb4a16b` (`scripts/notion-decision.py` 기본값 · `NOTION_DECISION_DS_ID` 로 override)
+- **AI 세션**: Notion MCP 로 직접 (`notion-create-pages`, parent = 위 data source)
+- **토큰이 있는 환경** (사람의 로컬 셸): `scripts/notion-decision.py add ...` — `notion_pr_sync.py` 와 같은 요청 헬퍼 · 재시도 정책 (이슈 #563)
+- CI `@claude` 경로는 `claude.yml` 이 `NOTION_API_TOKEN` 을 step `env` 로 넘기지 않아 **현재는 기록할 수 없다** — 넘길지는 별도 결정 (secret 등록 + 워크플로 변경)
+- 두 경로는 같은 DB 에 같은 형식으로 쓴다. 수동 `curl` 은 쓰지 않는다 (이슈 #243 과 같은 원칙)
+- 속성 · 본문 형식 (ADR 여섯 항목) 은 공통 `07-decisions.md`. `영역` 값은 저장소 구조를 따른다 — 파이프라인 stage (fetcher / parser / validate / enrich) · storage · bus · llm · agent · ci · 규약
 
 <br>
 
-## 적용 흐름 (요약)
+## 규약 8 — 오케스트레이션 보충
 
-사용자 요청 도착 →
-1. **의도가 명확한가?** Yes → 진행 / No → 구체화 질문 (규약 2 의 모호 영역)
-2. **이슈 생성 + Label/Type 부여** (규약 1 + 규약 6) — 단발은 이슈 1개 / 큰 작업은 메인 + sub-issue N개로 분할 후 모두 사전 생성 (sub-issue Relation 활성화). 모든 이슈에 Label · Issue Type 부여. "이슈 없이 진행해" 명시 시 skip
-3. **destructive / 시스템 / 외부 영향?** Yes → 사용자 확인 / No → 진행
-4. **새 권한 / 외부 의존성 필요?** Yes → 사용자 확인 / No → 진행 (규약 5)
-5. **작업 진행** — 하위 작업을 난이도 × 중요도로 티어 배분해 위임하고 메인이 검수 (규약 8) → sub-issue 단위로 branch / 검수 통과한 논리 단위마다 commit (규약 3). 작업 중 결정이 내려지면 다음 단계를 기다리지 않고 **그 즉시** 기록한다 (규약 7)
-6. **결정이 내려지면 즉시 Notion 에 기록** (규약 7) — 아키텍처 · 의존성 · 정책 · "두 안 중 하나". PR 본문에 행 링크
-7. **작업 완료 → PR 자동 생성 + Label 부여** (규약 4 + 규약 6) — `Closes #<sub-issue>` 명시, 마지막 sub-issue PR 에서 메인 이슈도 close → 세션 내 `Monitor` 로 CI·코멘트 감시 (이슈 #548)
+- 역할 군 · 티어 판정 · 티어 → 모델 매핑 · 브리프 · 검수 · 동시 상한은 공통 `02-orchestration.md` 가 **단일 출처** 다.
+  역할 정의 파일은 `~/.claude/agents/<역할>.md`. 이 저장소에 같은 이름의 역할 파일을 두면 그쪽이 우선한다 — 지금은 없다.
+- **operator** 역할의 본 저장소 범위: migration 적용 (`cmd/migrate` · `cmd/migrate-down`), DLQ 확인, 로그 분석, `cmd/admin` 도구 실행.
+  변경은 위임하지 않는다 (규약 2 예외 영역). 읽기 전용 조회 (DLQ 개수 · 로그 검색) 만 T3 로 위임한다.
+- 서브 에이전트 브리프의 "제약" 에 반드시 넣는 포인터: 테스트 위치 [05-testing.md](05-testing.md), 로그 메시지 영어
+  [04-error-handling.md](04-error-handling.md), 스타일 [06-code-style.md](06-code-style.md).
+- 검수 재실행 명령: `make fmt` · `make lint` · `make test` · `make harness-check`.
+- PR 본문의 "작업 분배" 섹션은 [PR 템플릿](../../.github/PULL_REQUEST_TEMPLATE.md) 에 있다. 서브 에이전트를 쓰지 않았으면 "없음".
+- 도입 배경: 이슈 #667 (티어 · 검수), #669 (역할 군).
 
 <br>
 
@@ -597,8 +96,11 @@ PR 본문의 "작업 분배" 섹션에 하위 작업 · 역할 · 티어 · 검
   - 이슈 #199 — 이슈 먼저 (issue-first) 워크플로 명문화 (규약 1 도입)
   - 이슈 #210 — Label · Issue Type · Sub-issue Relation 정책 명문화 (규약 6 도입)
   - 이슈 #212 — 규약 6 의 prefix 표기 체계 3분리 (commit / PR / 이슈) 명문화
+  - 이슈 #243 — `scripts/gh-meta.sh` 표준화
+  - 이슈 #539 / #565 — `make harness-check` 드리프트 게이트와 selftest
   - 이슈 #665 — 설계 변경·의사 결정 Notion 기록 (규약 7 도입)
   - 이슈 #563 — Notion PR 동기화 (규약 7 이 재사용하는 요청 헬퍼)
   - 이슈 #667 — 메인 세션 오케스트레이션 · 서브 에이전트 모델 차등 배분 (규약 8 도입)
-  - 이슈 #669 — 서브 에이전트 역할 군 (오케스트레이터 · 아키텍트 · 기획 · 자료조사 · 디자인 · 코더 · 테스터 · QA · 디버거 · 문서화 · 운영 · 기타) 명시 (규약 8 보완)
+  - 이슈 #669 — 서브 에이전트 역할 군 명시 (규약 8 보완)
+  - 이슈 #672 — 공통 규약을 사용자 레벨 하네스 `~/.claude/rules/` 로 이관, 본 문서를 전용 사항으로 재구성
 - 관련 문서: [.github/PULL_REQUEST_TEMPLATE.md](../../.github/PULL_REQUEST_TEMPLATE.md)
diff --git a/.claude/rules/README.md b/.claude/rules/README.md
index e8b3b2ea..ba0e9c12 100644
--- a/.claude/rules/README.md
+++ b/.claude/rules/README.md
@@ -126,16 +126,18 @@ Essential for:
 - Code review efficiency
 
 ### [07-workflow.md](07-workflow.md)
-**AI Workflow Conventions** (이슈 #152)
-
-Covers:
-- Autonomous progression policy — when AI proceeds without user approval
-- Exception zones (system changes / destructive perms / external impact / ambiguous scope)
-- Commit-per-TODO policy
-- PR auto-creation policy with template + closing reference
-- Least-privilege permission usage
-- Design-decision recording — every design change / decision goes to the Notion ADR database (규약 7, 이슈 #665)
-- Orchestration — main session communicates / designs / integrates / **reviews**, sub-tasks are delegated to sub-agents with model tiers by difficulty × importance (규약 8, 이슈 #667)
+**AI Workflow Conventions — project-specific part** (이슈 #152, #672)
+
+The common workflow rules (issue-first, autonomous progression and its four exception zones,
+commit-per-TODO, PR auto-creation, least privilege, label / issue-type mapping, decision records,
+sub-agent orchestration with model tiers) now live in the user-level harness `~/.claude/rules/`.
+This file keeps only what the harness delegates to the project:
+
+- Mapping table: legacy "규약 N" numbers → harness files (existing issues / PRs cite the numbers)
+- Project tools — `scripts/gh-meta.sh`, `scripts/pr-resolve-comments.sh`, `make harness-check`, `claude.yml`
+- Issue Type IDs of this repository
+- Notion ADR database for 규약 7 (이슈 #665) and the `scripts/notion-decision.py` path
+- `operator` role scope and the PR "작업 분배" section for 규약 8 (이슈 #667, #669)
 
 Essential for:
 - AI-assisted development efficiency
diff --git a/CLAUDE.md b/CLAUDE.md
index 2f119294..3aa374be 100644
--- a/CLAUDE.md
+++ b/CLAUDE.md
@@ -19,7 +19,7 @@
 | 에러 처리 | `.claude/rules/04-error-handling.md` | 에러 타입, 재시도, 로깅 필드 |
 | 테스트 작성 | `.claude/rules/05-testing.md` | test/ 디렉토리 구조, 커버리지 (CI 게이트 40%) |
 | 아키텍처 이해 | `.claude/rules/01-architecture.md` | 레이어, 디렉토리, 데이터 흐름 |
-| **AI 작업 진행** | `.claude/rules/07-workflow.md` | **자율 진행 / commit-per-TODO / PR 자동 / 권한 최소화 / 결정 기록(Notion) / 오케스트레이션(모델 차등)** |
+| **AI 작업 진행** | 공통 하네스 `~/.claude/rules/` + `.claude/rules/07-workflow.md` | **공통: 이슈 먼저 / 자율 진행 / commit-per-TODO / PR / 권한 / Label · Type / 결정 기록 / 오케스트레이션 — 전용: 스크립트 · Notion DB · harness-check** |
 | CI/머지 게이트 | `docs/ci/conventions.md` | Required checks, CODEOWNERS, Ruleset |
 | Status check 이름 | `docs/ci/status-checks.md` | 단일 소스, 변경 절차 |
 
@@ -61,73 +61,14 @@ docs/ci/        → CI 운영 규약, status check 단일 소스
 - [ ] 커밋 메시지가 `[카테고리]: 한국어 설명` 형식인가?
 - [ ] `make fmt && make lint && make test` 를 로컬에서 통과했는가?
 
-## AI 작업 진행 규약 (이슈 #152, #199, #210, #665, #667)
+## AI 작업 진행 규약
 
-상세는 [`.claude/rules/07-workflow.md`](.claude/rules/07-workflow.md). 핵심 8 규약:
+공통 규약 (이슈 먼저 · 자율 진행 경계 · commit-per-TODO · PR 자동 · 권한 최소화 · Label/Type · 결정 기록 · 오케스트레이션 · PR 피드백) 은
+사용자 레벨 하네스 `~/.claude/CLAUDE.md` · `~/.claude/rules/` 가 기본값이다 (2026-10-11 이관, 이슈 #672). 프로젝트 규칙이 다르게 정하면 프로젝트가 우선한다.
+본 저장소 전용 사항과 구 규약 번호 대응표는 [`.claude/rules/07-workflow.md`](.claude/rules/07-workflow.md). 요점:
 
-1. **이슈 먼저 생성** — 코드 수정 시작 전 GitHub 이슈 생성. 큰 작업은 메인 + sub-issue N개로 분할 후 모두 사전 생성 (Sub-issue Relation 활성화). PR 직전 ad-hoc 이슈 금지 (이슈 #199).
-2. **자율 진행** — 시스템 변경 / destructive 권한 / 외부 영향 / 모호 영역만 사용자 확인. 그 외는 쿼리 의도 기반 자율 진행.
-3. **Commit-per-TODO** — 별 언급 없으면 논리적 변경 단위마다 commit (메시지 컨벤션 준수).
-4. **PR 자동 생성** — 작업 완료 직후 컨벤션 + 템플릿 준수해서 `Closes #<sub-issue>` 포함 PR 자동 생성. 마지막 sub-issue PR 에서 메인 이슈도 close.
-5. **권한 사용 최소화** — 새 permission / 외부 도구 / 의존성은 작업 완수에 불가피한 경우에만.
-6. **Label · Issue Type 부여 필수** (이슈 #210, #212) — 이슈는 **issue prefix** 기준 Label + Type (`[FEATURE]→enhancement/Feature`, `[REFACTOR]→refactor/Task`, `[CHORE]→chore/Task`, `[DOCS]→documentation/Task`, `[FIX]→bug/Bug`, `[HOTFIX]→bug+hotfix/Bug`). PR Label 은 그 PR 이 닫는 이슈의 Label 과 동일. **부여 수단: `scripts/gh-meta.sh issue <N>` / `scripts/gh-meta.sh pr <N>` — 수동 `gh api graphql` 대신 항상 이 스크립트 사용** (이슈 #243). 표기 체계 3분리 (commit `[FEAT]:` / PR `[FEAT#N]` / issue `[FEATURE]`) 는 [규약 6](.claude/rules/07-workflow.md) 참조.
-7. **설계 변경·의사 결정은 전부 Notion 에 기록** (이슈 #665) — 아키텍처 · 외부 의존성 · 데이터 흐름/스키마 정책 · 규약 변경 · 되돌리기 어려운 운영 정책 · **"두 안 중 하나를 고른" 모든 경우**. 결정이 내려진 **즉시**, PR 생성 전에 [설계 결정 기록](https://app.notion.com/p/90f54429790347b3942b1e13ea34b145) DB 에 한 행 (ADR: 맥락 → 결정 → 근거 → 검토한 대안 → 결과 → 되돌리기). AI 세션은 Notion MCP 로 직접, 토큰 환경은 `scripts/notion-decision.py`. 뒤집힌 결정은 지우지 않고 상태를 `폐기`/`대체됨` 으로. 상세는 [규약 7](.claude/rules/07-workflow.md).
-8. **메인 세션은 오케스트레이터, 하위 작업은 서브 에이전트에 모델 차등 배분** (이슈 #667) — 메인은 사용자 소통 · 설계 · 결정 · 통합 · **검수** 를 직접, 범위가 닫힌 구현 · 탐색 · 기계적 변경은 위임. 하위 작업을 **난이도 × 중요도** 로 T0 (메인 직접) / T1 (상위) / T2 (중위) / T3 (경량) 티어에 배분하고 50/50 은 상위 티어. 티어별 선정 기준 (판단의 성격 · 범위 · 선례 · 틀렸을 때 비용) 은 규약 8 의 표를 따르되 **기준일 뿐** — 난이도 · 중요도는 유동적이라 작업 중 신호에 따라 **한 단계** 위·아래로 조정할 수 있고, 조정 사유는 PR 작업 분배 표에 적는다. 위임은 **역할 군** (오케스트레이터 · 아키텍트 · 기획 · 자료조사 · 디자인 · 코더 · 테스터 · QA · 디버거 · 문서화 · 운영 · 기타, 이슈 #669) 중 하나로 — 한 브리프 = 한 역할, 초안 역할은 결정하지 않고 보고 역할은 고치지 않으며, 코더와 그 변경의 QA 는 다른 에이전트. 역할별 기본 티어는 규약 8 의 "역할별 기본 티어" 표가 단일 출처 — 다른 문서에는 적지 않는다. 서브 에이전트는 커밋 · push · PR · 이슈 · Notion 기록을 하지 않는다 — 메인이 **diff 전수 재독 + 검증 재실행** 으로 검수한 단위만 커밋. 동시 실행 상한 3, `Workflow` 도구는 사용자 명시 요청 시만. 티어 → 모델 매핑은 [규약 8](.claude/rules/07-workflow.md) 의 표가 **단일 출처** — 이 파일을 포함한 다른 문서에는 모델 이름을 적지 않는다.
-
-## PR 생성 후 피드백 대응 (이슈 #548 — 구 #129 cron 방식 폐지)
-
-PR 을 만든 뒤 CI 결과와 리뷰 코멘트를 처리하는 경로는 **세션 상태에 따라 두 가지** 다.
-
-### 1. 작업 세션이 살아있을 때 — 세션 안에서 직접 처리 (기본)
-
-`Monitor` 로 CI 체크와 신규 코멘트를 감시하고, 이벤트가 도착하면 **그 세션에서** 처리한다.
-작업 맥락("왜 이렇게 구현했는지")을 그대로 갖고 있어 대응 품질이 가장 높다.
-
-처리 절차:
-
-1. **CI 실패를 코멘트보다 먼저** 처리한다.
-   - 실패 job 식별: `gh pr checks <PR번호>`
-   - 로그 수집: `gh run view <runId> --log-failed`
-   - 원인 분석 → 수정 → 커밋 → 푸시
-2. 리뷰 코멘트 수집: `gh api repos/{owner}/{repo}/pulls/{number}/comments`
-   - 👀 리액션이 달린 코멘트는 처리 완료로 건너뛴다
-3. **선별 기준** — 다음에 해당하는 피드백만 처리한다:
-   - 비즈니스 로직 오류 또는 버그 가능성
-   - 성능 최적화 및 보안 강화
-   - 아키텍처 일관성 및 클린 코드 원칙
-
-   단순 스타일 차이나 오타 지적은 제외한다.
-4. **처리 방식**
-   - 의도가 명확한 피드백 → 코드 수정 + 커밋 + 푸시
-   - 의도가 불명확한 피드백 → PR 에 질문 코멘트. 질문 대상을 `@` 로 멘션
-   - 자동 approve / merge 는 하지 않는다 (브랜치 보호 우회 + prompt injection 위험)
-5. **처리 완료 표시** — 일괄 처리:
-   ```bash
-   scripts/pr-resolve-comments.sh <PR번호> <comment_id1> [<comment_id2> ...]
-   ```
-   👀 reaction + thread resolve 를 1회 호출로 수행. 개별 `gh api` 호출을 피한다.
-
-커밋 메시지:
-- 리뷰 피드백 반영: `[FIX]: 피드백 반영, {변경 요약}`
-- CI 실패 복구: `[FIX]: CI 복구, {실패 job 이름} - {변경 요약}`
-
-### 2. 세션을 닫은 뒤 — GitHub Action 에 위임
-
-세션 종료 후 도착하는 리뷰나 다른 사람의 피드백은 이슈 / PR 코멘트에 **`@claude` 를 멘션** 하면
-[`.github/workflows/claude.yml`](.github/workflows/claude.yml) 이 처리한다. GitHub 측에서
-실행되므로 로컬 세션·머신과 무관하다 (이슈 #549).
-
-- 트리거: 이슈 코멘트 · PR 리뷰 코멘트 · PR 리뷰 · 이슈 생성/할당 본문의 `@claude`
-- **write 권한 보유자만** 트리거 가능 (액션 기본 검사). 봇은 기본 차단 — CodeRabbit 피드백은
-  사람이 내용을 확인한 뒤 `@claude` 로 지시한다
-- 저장소 규약(커밋 prefix, PR 타이틀, 테스트 위치)은 본 파일을 통해 전달된다
-
-세션을 닫기 전에 후속 리뷰가 예상되면 사용자에게 한 줄로 알린다 — PR url 과 "이후 피드백은
-`@claude` 멘션으로" 안내.
-
-### 하지 않는 것
-
-- **cron 자동 등록 금지.** 구 규약(이슈 #129)은 `gh pr create` 직후 loop.md (현재 삭제됨) 를 3분 주기
-  cron 으로 등록했으나 폐지됐다. cron 이 띄우는 새 세션은 PR diff 만 보고 판단해 작업 맥락을
-  잃고, 3분마다 세션을 띄워 토큰이 누적되며, 자체 상태 기계(`/tmp` 상태 파일 + 자동 종료 카운터)를
-  유지해야 했다. 사용자가 명시적으로 요청하지 않는 한 `CronCreate` 를 호출하지 않는다.
+- Label · Issue Type 은 `scripts/gh-meta.sh issue <N>` / `pr <N>` 으로 부여 — 수동 graphql 금지 (이슈 #243)
+- 설계 변경 · 의사 결정은 [설계 결정 기록](https://app.notion.com/p/90f54429790347b3942b1e13ea34b145) Notion DB 에 결정 즉시 기록 (이슈 #665)
+- 구조 변경 (cmd · 디렉토리 · Go 버전 · CI 임계값) 시 `make harness-check` 통과 (이슈 #539)
+- PR 후 피드백은 세션 안에서 `Monitor` 로 처리하고 `scripts/pr-resolve-comments.sh` 로 완료 표시. 세션 종료 후는 이슈 · PR 코멘트에 `@claude` 멘션 → [`.github/workflows/claude.yml`](.github/workflows/claude.yml) (이슈 #548 · #549). cron 자동 등록 금지 (구 #129 폐지)
+- `~/.claude` 가 없는 환경 (`claude.yml`) 에는 공통 규약이 로드되지 않는다 — 위 "반드시 지킬 규칙" 과 07-workflow.md 만 적용