diff --git a/.claude/loop.md b/.claude/loop.md
index 7e027dc..91aa0bd 100644
--- a/.claude/loop.md
+++ b/.claude/loop.md
@@ -1,5 +1,9 @@
 # PR 피드백 순환 처리
 
+> **ℹ️ 수동 보조 수단**: 이 루프는 `gh pr create` 직후 자동으로 cron 등록되지 **않는다** (이슈 #84 로 폐지).
+> PR 피드백의 기본 경로는 작업 세션 안에서 `Monitor` 로 처리하는 것이다 (공통 `~/.claude/rules/06-pr-feedback.md`).
+> 사용자가 로컬 세션에서 반복 처리를 원해 `/loop` 로 명시적으로 요청할 때만 이 절차를 쓴다.
+
 ## 대상
 현재 브랜치에 연결된 열린 PR의 CI 상태와 리뷰 코멘트를 처리한다.
 
diff --git a/.claude/rules/07-workflow.md b/.claude/rules/07-workflow.md
index 5ee938f..bbe84c7 100644
--- a/.claude/rules/07-workflow.md
+++ b/.claude/rules/07-workflow.md
@@ -1,304 +1,97 @@
-# AI 작업 진행 규약
+# AI 작업 진행 규약 — 본 프로젝트 전용 사항
 
-이 문서는 Claude / Copilot 등 AI 협업 도구가 본 프로젝트에서 작업을 진행할 때 따라야 하는
-**workflow 규약** 입니다. 작업 도중 사용자 승인을 빈번히 요청하여 흐름이 끊기는 문제를
-해소하고, AI 의 자율성과 안전성의 균형을 명문화합니다.
+공통 규약은 사용자 레벨 하네스 **`~/.claude/rules/`** 가 기본값이다 (2026-10-11 이관, 이슈 #84).
+이 문서는 본 저장소에만 있는 값과 공통 규약과 다르게 하는 점만 적는다. 코드 자체의 규약은 [01-architecture.md](01-architecture.md) ~
+[06-code-style.md](06-code-style.md).
 
-본 규약은 코드 스타일 / 아키텍처 / 테스트 등 **무엇을 만드느냐** 가 아니라, **어떻게
-진행하느냐** 를 다룹니다. 코드 자체의 규약은 [01-architecture.md](01-architecture.md) ~
-[06-code-style.md](06-code-style.md) 참조.
+> `~/.claude` 가 없는 환경 (CI 등) 에는 공통 규약이 로드되지 않는다. 그 환경에서는 [CLAUDE.md](../../CLAUDE.md) 의 "반드시 지킬 규칙" (CI 강제) 과
+> 이 문서, 저장소 규칙 01~06 이 적용되고, 서브 에이전트 위임은 하지 않는다.
 
 <br>
 
-## 핵심 6 규약
+## 구 규약 번호 → 공통 하네스 대응표
 
-### 1. 이슈 먼저 (issue-first) 생성 정책
+기존 이슈 · PR · 문서 · 스크립트 주석 (`scripts/gh-meta.sh` 등) 이 "규약 N" 으로 참조한다. 번호는 그대로 쓴다.
 
-사용자 작업 지시가 도착하면 **코드 수정 시작 전에 GitHub 이슈를 먼저 생성** 한다.
-
-#### 원칙
-
-- 모든 작업은 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 단위로 `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 직전에 이슈 만드는 패턴 차단 (closing reference 가 필요해서 PR 직전 즉흥 sub-issue 생성하는 안티 패턴)
-- 메인 이슈와 sub-issue 의 계층 관계가 GitHub 상에서 명확히 link
-
-#### 예외
-
-- 사용자가 명시적으로 **"이슈 없이 진행해"** / **"단발 hotfix"** 라고 지시한 경우
-- 1줄 typo 수정 / 명백한 작은 chore (사용자 동의 없이 진행해도 손실 적음 — 단, PR 타이틀 규약 준수를 위해 작업 시작 전 이슈 생성)
-
-#### 판단 모호 시
-
-규모가 작아 보이더라도 **이슈 1개 생성** — 작업 끝난 후 PR 본문 정리할 때 추가 비용 거의 없음.
-"이거 큰가?" 가 50/50 이면 **메인 + sub-issue 분할 쪽** 으로 보수 분류.
-
-#### Sub-issue 등록 명령
-
-```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"
-```
+| 구 규약 | 내용 | 공통 하네스 (`~/.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` | 도구 · `loop.md` 의 위치 |
+| 5 | 권한 최소화 | `01-workflow.md` 5절 | Python 의존성 |
+| 6 | Label · Issue Type · 접두사 3분리 | `03-conventions.md` | `scripts/gh-meta.sh` |
+| — | 결정 기록 (ADR) | `07-decisions.md` | 저장 위치 (아래) |
+| — | 오케스트레이션 · 역할 군 · 티어 | `02-orchestration.md`, 역할 정의 `~/.claude/agents/` | PR 작업 분배 표 |
 
 <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 가 불명확한 경우 — 진행 전 구체화 질문 |
-
-#### 자율 진행 영역 (승인 불필요 — 즉시 실행)
+## 규약 2 — 자율 진행 영역 추가 항목
 
-- 코드 작성 / 수정 / 리팩토링 / 삭제
-- 테스트 추가 / 갱신
-- 새 파일 / 디렉토리 생성
-- DB migration 작성 (단 `DROP` 류는 예외 — 위 destructive 영역)
-- 의존성 추가 (`pip install` / `pyproject.toml` 갱신) — 단 신규 외부 패키지는 규약 5 적용
-- Branch 생성, 정상 push (force-push 아닌)
-- Commit 단위 결정 및 실행
-- PR 본문 작성
-- **`scripts/` 하위 스크립트 실행** — 프로젝트 도구는 경로 확인 없이 실행
-- **이슈 / PR Label · Type 부여** — `scripts/gh-meta.sh` 활용, 별도 승인 불필요
-- **lint / fmt / test** — `make` 또는 `scripts/lint.sh` (ruff + nbqa) 실행, 경로 확인 불필요
+공통 목록에 더해 다음도 확인 없이 한다:
 
-#### 판단 모호 시
-\"이게 destructive 영역인가?\" 가 50/50 이면 **사용자 확인 쪽으로 보수 분류**. 단,
-이미 자율 진행 영역으로 열거된 항목은 50/50 이 아니다 — 확인 없이 진행한다.
+- `scripts/` 하위 도구 실행, `make` · `scripts/lint.sh` (ruff + nbqa) 실행.
+- 의존성 추가 (`pyproject.toml` 갱신, `uv`) — 단 신규 외부 패키지는 사전 확인 (규약 5).
+- 노트북 출력 셀 정리 `make nb-clean`.
 
 <br>
 
-### 3. Commit-per-TODO 정책
+## 규약 3 — 노트북 커밋
 
-별다른 사용자 언급이 없으면, 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 (가상의 feature/#15 PR commit 시퀀스)
-a1b2c3d [DOCS]: GraphEncoder docstring 추가 (en+ko)
-e4f5g6h [FEAT]: GCN baseline forward 단위 테스트 추가
-i7j8k9l [FEAT]: GraphEncoder 구현 — in/hidden/out dim 설정
-m0n1o2p [REFAC]: TrainConfig 를 frozen dataclass 로 변경
-q3r4s5t [CHORE]: pyproject.toml ruff 규칙 ICN001 추가
-```
+- 노트북 (`.ipynb`) 은 **`make nb-clean` 후 커밋** 한다. 출력 셀이 diff 를 폭주시킨다.
+- 로직은 `src/graphlm/`, 실험 흐름은 `notebooks/` — 한 커밋에 둘을 섞지 않는다 ([01-architecture.md](01-architecture.md)).
 
 <br>
 
-### 4. PR 자동 생성 정책
-
-작업 완료 직후 (별다른 언급 없으면) AI 는 **PR 을 자동 생성** 한다.
-
-#### 컨벤션 + 템플릿 준수
-
-- **PR 타이틀**: `[카테고리#이슈번호] 제목` 정규식 (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 생성 직후 자동 동작
+## 규약 4 · 6 — 도구
 
-[CLAUDE.md](../../CLAUDE.md#pr-생성-후-자동-동작) 의 자동 동작 — `@.claude/loop.md`
-3분 cron 등록. 본 규약은 그 동작이 자동 발동되도록 PR 생성을 보장.
-
-#### 예외
-
-- 작업이 이슈와 무관한 단발성 chore (예: 작은 hotfix, 운영 스크립트) — 사용자가 \"이슈 없이
-  PR 올려줘\" 또는 \"이슈 먼저 만들어줘\" 명시
-- 작업이 PR 단위가 아닌 운영 명령 (예: migration 적용, log 분석) 만 요청한 경우
+| 용도 | 수단 | 비고 |
+|---|---|---|
+| 이슈 Label + Issue Type | `scripts/gh-meta.sh issue <N>` | title prefix 로 자동 판정. 수동 `gh api graphql` 금지. Issue Type 은 `GRAPHLM_*_TYPE_ID` 환경변수가 설정된 경우에만 부여 — 조회 방법은 `scripts/gh-meta.sh` 상단 주석 |
+| PR Label | `scripts/gh-meta.sh pr <N>` | 닫는 이슈의 Label 과 동기화 |
+| 리뷰 코멘트 처리 완료 표시 | `scripts/pr-resolve-comments.sh <PR> <comment_id...>` | 👀 + resolve 일괄 |
+| sub-issue 연결 | `gh api graphql` `addSubIssue` (공통 `03-conventions.md` 의 명령) | 스크립트 없음 — 직접 호출 허용 |
+| Notion PR 동기화 | `.github/workflows/notion-pr-sync.yml` | 자동. 손으로 행을 만들지 않는다 |
+
+### PR 생성 후 피드백 (하네스 기본값으로 전환, 이슈 #84)
+
+- **세션이 살아 있으면** `Monitor` 로 CI · 코멘트를 감시하고 그 세션에서 처리한다 (공통 `06-pr-feedback.md`).
+- **`gh pr create` 직후 `.claude/loop.md` 를 3분 cron 으로 자동 등록하던 구 동작은 폐지** 됐다. 새 세션이 diff 만 보고
+  맥락을 잃고, 토큰이 누적되고, 자체 상태 기계가 필요했다. 사용자가 명시적으로 요청하지 않는 한 `CronCreate` 를 호출하지 않는다.
+- [`.claude/loop.md`](../loop.md) 는 삭제하지 않고 **수동 보조 수단** 으로 남긴다 — 사용자가 `/loop` 로 요청할 때만 쓴다.
+- [`.claude/pr-feedback.md`](../pr-feedback.md) (신규 PR 자동 리뷰 루프, `scripts/pr-feedback.sh`) 는 PR 생성과 무관한 별도 자동화다.
+  사용자가 직접 등록할 때만 돈다.
+- **세션을 닫은 뒤** 의 피드백은 사용자가 처리한다 — 본 저장소에는 `@claude` 멘션용 `claude.yml` 이 없다. 도입 여부는 별도 결정.
 
 <br>
 
-### 5. 권한 사용 최소화
-
-자율 진행 시, **꼭 필요한 경우가 아니면 이미 허용된 권한 범위 내에서만 동작** 한다.
+## 규약 5 — Python 의존성
 
-#### 원칙
-
-- 새 `Bash(...)` permission 요청은 작업 완수에 불가피한 경우에만
-- 동등 효과를 낼 수 있는 기존 허용 도구가 있으면 그것을 우선 사용 — 새 외부 도구 설치 X,
-  기존 `gh` / `python` / `git` / `make` / `ruff` 등 활용
-- `WebFetch` / `WebSearch` 도 새 도메인은 작업 명시적 필요 시에만
-- 신규 외부 의존성 (Python package / system package) 추가는 **규약 2 의 "모호 영역"** 으로 간주
-  → 사용자 사전 확인
-
-#### 이유
-
-- 누적 권한이 늘어날수록 `.claude/settings.local.json` 의 entries 가 비대해져 정리 비용 증가
-- 잘못된 도구 도입은 보안 노출 위험 증가 (예: 토큰 노출, 시스템 파괴 명령)
+- 신규 외부 패키지 (`pyproject.toml` · 시스템 패키지) 추가는 모호 영역 → 사용자 사전 확인. 명시 PR 로 분리한다 ([01-architecture.md](01-architecture.md)).
+- 무거운 의존성 (torch 등) 은 이미 있는 것을 쓴다. 대체 라이브러리 도입은 결정 기록 대상.
 
 <br>
 
-### 6. 이슈 / PR 분류 메타데이터 정책 — Label · Issue Type
-
-이슈 / PR 생성 시 **항상 Label 부여** (필수). 이슈는 추가로 **Issue Type 부여** (필수).
-분류·필터링·자동화 (예: hotfix 라벨로 우선순위 알림) 가 누락되지 않도록 일관 매핑 적용.
-
-#### 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#15] docstring 정정` | GitHub Actions PR Title Lint |
-| **Issue title** | **`[FEATURE]` / `[FIX]` / `[REFACTOR]` / `[DOCS]` / `[CHORE]` / `[HOTFIX]`** (full-word, 콜론 없음) | `[FEATURE] GCN baseline 추가` | (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 는 `scripts/gh-meta.sh` 상수로 관리한다 (변경 시 스크립트 갱신 필요).
-
-#### 부여 명령 예시
-
-> **`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 \
-  --title "[DOCS] 제목" \
-  --body "..."
-
-# Label + Issue Type 일괄 부여 (이슈 번호 지정)
-scripts/gh-meta.sh issue <ISSUE_NUMBER>
-```
-
-다른 issue prefix 예: `[FEATURE] 새 baseline 모델`, `[REFACTOR] data loader 분리`, `[HOTFIX] eval 시 dim mismatch`.
-
-**PR 생성 후 Label 부여**:
-```bash
-gh pr create --title "[DOCS#N] 제목" --body "..."
-
-# PR Label 부여 (닫는 이슈의 Label 과 자동 동기화)
-scripts/gh-meta.sh pr <PR_NUMBER>
-```
-
-#### 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` 로 표준화
+본 저장소에는 Notion ADR 데이터베이스가 없다. 공통 `07-decisions.md` 의 우선순위에 따라 **PR 본문 "결정" 섹션** 에 ADR 형식으로 적고,
+핵심 패러다임 수준의 결정은 [CLAUDE.md](../../CLAUDE.md) "핵심 패러다임" 과 프로젝트 메모리에 반영한다.
+전용 저장소 (`docs/decisions.md` 또는 Notion DB) 도입 여부는 별도 결정.
 
 <br>
 
-## 적용 흐름 (요약)
+## 오케스트레이션 보충
 
-사용자 요청 도착 →
-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. **작업 진행** — sub-issue 단위로 branch / 논리 단위마다 commit (규약 3)
-6. **작업 완료 → PR 자동 생성 + Label 부여** (규약 4 + 규약 6) — `Closes #<sub-issue>` 명시, 마지막 sub-issue PR 에서 메인 이슈도 close → cron 자동 등록
+- 역할 군 · 티어 · 모델 매핑 · 브리프 · 검수는 공통 `02-orchestration.md` 가 단일 출처. 역할 정의는 `~/.claude/agents/`.
+- 서브 에이전트 브리프의 "제약" 에 넣는 포인터: 테스트 위치 · 마커 [05-testing.md](05-testing.md), NaN · 결정론 [04-error-handling.md](04-error-handling.md),
+  스타일 [06-code-style.md](06-code-style.md), 코드/노트북 분리 [01-architecture.md](01-architecture.md). 실험 노트북을 서브 에이전트에 맡길 때는 커널 · 시드 고정 조건을 명시.
+- 검수 재실행 명령: `make fmt` · `make lint` · `make test` (· `make nb-clean`).
+- PR 템플릿에 "작업 분배" 섹션이 없으므로 "구현 내용" 아래에 표를 추가한다. 서브 에이전트를 쓰지 않았으면 "없음".
 
 <br>
 
 ## 참고 자료
 
-- 관련 규약:
-  - [06-code-style.md](06-code-style.md) — commit/PR 메시지 컨벤션
-  - [05-testing.md](05-testing.md) — 작업 단위 테스트 기준
-- 관련 문서: [.github/PULL_REQUEST_TEMPLATE.md](../../.github/PULL_REQUEST_TEMPLATE.md)
+- 관련 규약: [06-code-style.md](06-code-style.md) — commit/PR 메시지 컨벤션 / [05-testing.md](05-testing.md) — 작업 단위 테스트 기준
+- 관련 문서: [.github/PULL_REQUEST_TEMPLATE.md](../../.github/PULL_REQUEST_TEMPLATE.md), [docs/ci/conventions.md](../../docs/ci/conventions.md)
+- 이슈 #84 — 공통 규약을 `~/.claude/rules/` 로 이관, cron 자동 등록 폐지
diff --git a/.claude/rules/README.md b/.claude/rules/README.md
index 1cdf3fc..c428b6b 100644
--- a/.claude/rules/README.md
+++ b/.claude/rules/README.md
@@ -19,7 +19,7 @@
 | [04-error-handling.md](04-error-handling.md) | 예외 타입 / 로깅 / NaN 감지 / 결정론 |
 | [05-testing.md](05-testing.md) | pytest 패턴 / fixture / 마커 / 커버리지 |
 | [06-code-style.md](06-code-style.md) | PEP 8 / ruff / 네이밍 / docstring / 커밋 컨벤션 |
-| [07-workflow.md](07-workflow.md) | AI 자율 진행 / commit-per-TODO / PR 자동 / Label/Type |
+| [07-workflow.md](07-workflow.md) | AI 작업 규약의 **프로젝트 전용 사항** — 공통 규약 (이슈 먼저 / 자율 진행 / commit-per-TODO / PR / Label·Type / 결정 기록 / 오케스트레이션) 은 사용자 레벨 하네스 `~/.claude/rules/` |
 
 > **참고**: 본 프로젝트는 production 크롤러/파이프라인이 아닌 연구 프로젝트입니다.
 > 기존 ruleset 중 도메인 특화 문서(`02-crawler-implementation.md`,
@@ -32,11 +32,11 @@
 1. 진입점: 루트 [`CLAUDE.md`](../../CLAUDE.md) (목차)
 2. 아키텍처 이해: [01-architecture.md](01-architecture.md)
 3. 코드 스타일: [06-code-style.md](06-code-style.md)
-4. AI 협업 워크플로: [07-workflow.md](07-workflow.md)
+4. AI 협업 워크플로: 공통 하네스 `~/.claude/rules/01-workflow.md` · `02-orchestration.md`, 전용 사항은 [07-workflow.md](07-workflow.md)
 
 **작업 시작 시:**
 
-- 새 기능 → [07-workflow.md](07-workflow.md) 의 issue-first 정책 → [06-code-style.md](06-code-style.md) + [05-testing.md](05-testing.md)
+- 새 기능 → 공통 하네스 `~/.claude/rules/01-workflow.md` 의 issue-first 정책 (전용 사항은 [07-workflow.md](07-workflow.md)) → [06-code-style.md](06-code-style.md) + [05-testing.md](05-testing.md)
 - 버그 수정 → [04-error-handling.md](04-error-handling.md) + 회귀 테스트
 - 노트북 실험 → [01-architecture.md](01-architecture.md) 의 코드/노트북 분리 원칙 준수
 
@@ -46,7 +46,7 @@
 2. **단순성** — 연구 코드는 읽기 쉬워야 한다. 과도한 추상화 금지
 3. **분리** — 로직은 `src/graphlm/`, 실험 흐름은 `notebooks/`
 4. **테스트** — 패키지 코드는 pytest 로 검증. 노트북은 정적 lint 만
-5. **컨벤션** — 커밋·PR·이슈 prefix 3분리 체계 ([07-workflow.md](07-workflow.md) 규약 6)
+5. **컨벤션** — 커밋·PR·이슈 prefix 3분리 체계 (공통 하네스 `~/.claude/rules/03-conventions.md`, 구 [07-workflow.md](07-workflow.md) 규약 6)
 
 ## CI 게이트
 
diff --git a/CLAUDE.md b/CLAUDE.md
index 8df28d5..915db4b 100644
--- a/CLAUDE.md
+++ b/CLAUDE.md
@@ -39,7 +39,7 @@ GraphLM 의 graph 는 **데이터를 graph 로 보는** (data-as-graph) 방향
 | 에러 처리 | `.claude/rules/04-error-handling.md` | 예외 타입, 재시도, 로깅 필드 |
 | 테스트 작성 | `.claude/rules/05-testing.md` | `tests/` 디렉토리 구조, 커버리지 70% |
 | 아키텍처 이해 | `.claude/rules/01-architecture.md` | 모듈 레이아웃, 데이터 흐름, 노트북 구성 |
-| **AI 작업 진행** | `.claude/rules/07-workflow.md` | **자율 진행 / commit-per-TODO / PR 자동 / 권한 최소화** |
+| **AI 작업 진행** | 공통 하네스 `~/.claude/rules/` + `.claude/rules/07-workflow.md` | **공통: 이슈 먼저 / 자율 진행 / commit-per-TODO / PR / 권한 / Label · Type / 결정 기록 / 오케스트레이션 — 전용: 스크립트 · 노트북 · loop.md** |
 | CI/머지 게이트 | `docs/ci/conventions.md` | Required checks, CODEOWNERS, Ruleset |
 | Status check 이름 | `docs/ci/status-checks.md` | 단일 소스, 변경 절차 |
 | 논문/레퍼런스 요약 | `docs/papers/README.md` | 디렉토리 구조, 파일명/frontmatter 규칙, 추가 절차 |
@@ -92,27 +92,12 @@ docs/papers/    → 논문/레퍼런스 요약 (md, frontmatter 규칙 + 주제
 
 ## AI 작업 진행 규약
 
-상세는 [`.claude/rules/07-workflow.md`](.claude/rules/07-workflow.md). 핵심 6 규약:
+공통 규약 (이슈 먼저 · 자율 진행 경계 · commit-per-TODO · PR 자동 · 권한 최소화 · Label/Type · 결정 기록 · 오케스트레이션 · PR 피드백) 은
+사용자 레벨 하네스 `~/.claude/CLAUDE.md` · `~/.claude/rules/` 가 기본값이다 (2026-10-11 이관, 이슈 #84). 프로젝트 규칙이 다르게 정하면 프로젝트가 우선한다.
+본 저장소 전용 사항과 구 규약 번호 대응표는 [`.claude/rules/07-workflow.md`](.claude/rules/07-workflow.md). 요점:
 
-1. **이슈 먼저 생성** — 코드 수정 시작 전 GitHub 이슈 생성. 큰 작업은 메인 + sub-issue N개로 분할 후 모두 사전 생성 (Sub-issue Relation 활성화). PR 직전 ad-hoc 이슈 금지.
-2. **자율 진행** — 시스템 변경 / destructive 권한 / 외부 영향 / 모호 영역만 사용자 확인. 그 외는 쿼리 의도 기반 자율 진행.
-3. **Commit-per-TODO** — 별 언급 없으면 논리적 변경 단위마다 commit (메시지 컨벤션 준수).
-4. **PR 자동 생성** — 작업 완료 직후 컨벤션 + 템플릿 준수해서 `Closes #<sub-issue>` 포함 PR 자동 생성. 마지막 sub-issue PR 에서 메인 이슈도 close.
-5. **권한 사용 최소화** — 새 permission / 외부 도구 / 의존성은 작업 완수에 불가피한 경우에만.
-6. **Label · Issue Type 부여 필수** — 이슈는 **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` 대신 항상 이 스크립트 사용**. 표기 체계 3분리 (commit `[FEAT]:` / PR `[FEAT#N]` / issue `[FEATURE]`) 는 [규약 6](.claude/rules/07-workflow.md) 참조.
-
-## PR 생성 후 자동 동작
-
-`gh pr create` 가 성공한 직후 사용자가 별도 지시하지 않아도 다음을 자동 수행한다:
-
-1. **`@.claude/loop.md` 를 3분 주기 cron 으로 등록** — `CronCreate` 호출
-   - cron 표현식: `*/3 * * * *`
-   - prompt: `@.claude/loop.md 절차에 따라 PR #N 의 CI 와 코멘트를 점검하고 처리해줘.` (N = 방금 생성한 PR 번호)
-   - recurring: `true`
-2. 사용자에게 한 줄 보고 — cron job ID 와 본 PR url 포함
-
-자동 등록 예외:
-- 사용자가 명시적으로 "loop 등록하지 마" 라고 지시하면 생략
-- draft PR 등 후속 polling 이 무의미한 케이스가 명백하면 사용자에게 묻고 진행
-
-자동 종료는 `.claude/loop.md` 의 "자동 중단 (CI 완료 후 2회 연속 무동작 시)" 섹션이 처리한다.
+- Label 은 `scripts/gh-meta.sh issue <N>` / `pr <N>` 으로 부여. Issue Type 은 `GRAPHLM_*_TYPE_ID` 환경변수가 설정된 경우에만 부여된다 (조회 방법은 스크립트 상단 주석)
+- 노트북 (`.ipynb`) 은 `make nb-clean` 후 커밋
+- 설계 변경 · 의사 결정은 PR 본문 "결정" 섹션에 ADR 형식으로 (전용 저장소 없음)
+- PR 후 피드백은 세션 안에서 `Monitor` 로 처리하고 `scripts/pr-resolve-comments.sh` 로 완료 표시. `gh pr create` 직후 `.claude/loop.md` 를 cron 으로 자동 등록하던 동작은 폐지 — `loop.md` 는 사용자가 `/loop` 로 요청할 때만 쓰는 수동 보조 수단, `.claude/pr-feedback.md` 는 별도 자동화. 세션 종료 후 피드백은 사용자가 처리 (`@claude` 워크플로 없음)
+- `~/.claude` 가 없는 환경 (CI) 에는 공통 규약이 로드되지 않는다 — 위 "반드시 지킬 규칙" 과 07-workflow.md 만 적용
diff --git a/docs/ko/README.md b/docs/ko/README.md
index b09d8bf..4b0ac97 100644
--- a/docs/ko/README.md
+++ b/docs/ko/README.md
@@ -114,12 +114,12 @@ uv run jupyter nbconvert --to notebook --execute notebooks/01-experiments/<파
 ## 개발 워크플로 (AI 협업 포함)
 
 본 프로젝트는 AI(Claude, Copilot 등)와의 협업을 전제로 설계되었습니다.
-모든 워크플로 규약은 [.claude/rules/07-workflow.md](../../.claude/rules/07-workflow.md) 에서 정의합니다.
+공통 워크플로 규약은 사용자 레벨 하네스 `~/.claude/rules/` 에, 본 저장소 전용 사항은 [.claude/rules/07-workflow.md](../../.claude/rules/07-workflow.md) 에 있습니다.
 
-핵심 6 규약:
+핵심 규약:
 
 1. **이슈 먼저** — 코드 수정 전 GitHub 이슈 생성
-2. **자율 진행** — destructive / 시스템 / 외부 영향만 사용자 확인
+2. **자율 진행** — destructive / 시스템 / 외부 영향 / 모호한 범위만 사용자 확인
 3. **Commit-per-TODO** — 논리적 변경 단위마다 commit
 4. **PR 자동 생성** — 작업 완료 직후 컨벤션 준수 PR 생성
 5. **권한 최소화** — 새 의존성 / 도구는 명시적 사전 확인