git:20261010.40a384f to git:20261015.1d79e9c

5 added, 5 removed. Audit A to A.

---

name: rnd-policy-research-orchestrator

description: "실제 정책연구를 수행하고 정책연구보고서를 작성하는 에이전트 팀 오케스트레이터. 연구주제·메모·기존자료를 받아 연구설계→설계검토 게이트→근거조사→집필→초안검수→한글 hwpx 변환까지 5인 팀(policy-research-designer, policy-research-investigator, policy-report-writer, policy-report-reviewer, hwpx-exporter)을 조율한다. OmO식 2단계 검증(집필 전 설계 게이트 + 집필 후 초안검수)이 핵심. 표준 보고서(50p+)와 단형 정책브리프(4~8p) 두 산출 모드를 지원한다. '정책연구', '정책연구보고서', '정책분석', '정책과제', '정책연구과제', '현안분석', '정책대안 연구', '정책 보고서 작성', '정책브리프', '이슈페이퍼', '단형 정책보고서', 'R&D Brief', '정책 이슈 브리프', '요약 브리프' 요청 시 반드시 사용. 후속 작업: 정책연구 수정, 부분 재실행, 업데이트, 보완, 다시 작성, 특정 장만 다시, 설계 다시, 목차 검토·승인, 분량 늘리기·줄이기, 브리프로 압축, 참고문헌 정리·출처 검증, 검수 다시, 근거 보강, 기존 보고서 초안·자료 기반 작성/개정, hwpx만 다시 생성, 이전 결과 기반 개선 요청 시에도 반드시 이 스킬을 사용. ※ 정부 R&D '제안서/연구개발계획서' 작성은 이 스킬이 아니라 rnd-proposal-orchestrator를 사용."

---

# 정책연구 오케스트레이터

실제 정책연구를 5인 에이전트 팀으로 수행해 정책연구보고서(.hwpx)를 산출한다. OmO(oh-my-openagent)의 핵심 패턴인 **2단계 검증 게이트**(집필 전 설계 검토 + 집필 후 초안 검수)를 이식했다.

## 실행 모드: 에이전트 팀

## 산출물 모드 — 표준 보고서 vs 단형 브리프

같은 5인 팀·같은 2단계 게이트를 쓰되, 산출물 규모에 따라 **두 모드**로 매개변수만 달리한다. Phase 1에서 사용자 요청·분량 단서로 모드를 판별한다.

| 구분 | 표준 보고서 모드 (기본) | 단형 브리프 모드 |

|------|------------------------|------------------|

| 트리거 | "정책연구보고서", 분량 명시 없음·"자세히" | "브리프", "이슈페이퍼", "R&D Brief", "단형", "요약", "4~8쪽", "짧게" |

| 분량 | 본문 최소 50p | 본문 4~8p (사용자 지정 우선) |

| 목차 | 서론→이론→해외→국내→대안→로드맵→제언→참고문헌(8장) | **압축 목차**: ① 배경·문제제기 → ② 핵심 현황·쟁점 진단 → ③ 핵심 근거(해외·국내 요점만) → ④ 정책제언(우선순위 3~5) → (요약 박스·참고문헌) |

| 설계 게이트 | 정식(의도 확인서 + reviewer 모드1 + 사용자 목차 승인) | **경량 게이트**: designer가 **경량 의도 확인서**(원문·의도 한 문장·용도/독자/결정·분기 질문 2개 이내)와 핵심 메시지·압축 목차만 설계, reviewer 모드1은 "핵심 쟁점·제언이 명확하고 근거가 확보 가능한가"만 빠르게 점검, 사용자 목차 승인 1회. **개정 라운드 없음** — 지적은 designer 재스폰 대신 리더가 집필 프롬프트에 직접 하달 |

| 조사 | 전면 조사(통계·문헌·해외·국내), 3~4분할 병렬 | 핵심 근거만 표적 조사(제언을 떠받칠 최소 근거 + 출처). **2분할 병렬 + 분할당 도구 호출 20회·출처 10건 상한** |

| 집필 | 장 배치 **병렬** 스폰 후 리더가 문체 통일 | 단일 스폰(분할 이득 없음) |

| 검수 | 5축 정식 검수, **축 분할 병렬** | 핵심 3축(논리·근거/출처·정책타당성) 압축 검수, [필수]만. **writer 수정 루프 없음** — 리더가 직접 Edit로 반영 |

| 참고문헌 | 정식 일괄 정리 | 핵심 출처만 간결 정리(본문 인용 1:1 유지) |

**핵심 원칙(공통):** 브리프 모드도 "근거 없는 주장 금지·출처 병기·제언은 실행 수준"은 그대로 지킨다. 짧다고 근거를 빼지 않는다 — 분량만 줄이고 밀도는 유지한다. 브리프는 결정자가 5분 안에 핵심과 제언을 잡도록 **두괄식·요약 박스 우선**으로 쓴다.

아래 워크플로우는 표준 모드 기준이며, 브리프 모드는 위 표대로 각 Phase의 분량·목차·게이트·검수 축을 경량화해 적용한다(에이전트 프롬프트에 "브리프 모드: 본문 N쪽, 압축 목차" 명시).

## 실행 프로파일 — 표준 vs 쾌속 (성능 폴백 장치)

산출물 모드(무엇을 낼 것인가)와 별개로 **실행 프로파일(얼마나 빨리 갈 것인가)**을 정한다. 무거운 세션 모델(opus급)로 전 단계를 돌리면 표준 보고서 한 편에 수 시간이 걸릴 수 있다. 이를 다루는 장치가 네 겹이다: ①단계별 모델 티어(상시 기본값) ②쾌속 프로파일(요청 시) ③지연 폴백 래더(런타임 감지) ④실패 시 업시프트(품질 역방향).

### ① 단계별 모델 티어 (상시 기본값)

| 단계 | 에이전트 | 기본 모델 | 근거 |

|------|----------|-----------|------|

**스폰 시 모델을 명시하지 않는다** — 에이전트 정의의 티어 기본값이 적용되도록 둔다. 스폰 프롬프트에 `model`을 적으면 에이전트 정의를 덮어써 티어가 무력화된다. 품질 우선일 때만 의도적으로 상위 모델을 명시해 되돌린다(예: 근거 판별이 까다로운 주제의 investigator). **reviewer는 어떤 프로파일·래더 단계에서도 모델을 낮추지 않는다** — 검증 게이트가 이 킷의 존재 이유다.

### ② 쾌속 프로파일

트리거: 사용자의 속도 단서("빨리", "쾌속", "시간 없어", "오늘까지" 등) 또는 폴백 래더 4단계에서 사용자가 선택. 산출물 규모와 게이트 구조는 유지하고 **실행 방식만** 경량화한다:

- **조사 분할 병렬** — 국내 통계·현황 / 해외 사례 / 문헌·법제도 등 2~4분할로 동시 스폰, `03_evidence_domestic.md`·`03_evidence_intl.md` 식으로 분할 저장.

- **집필 장 배치 분할** — 목차를 2~3배치로 나눠 순차 스폰, 배치마다 `04`에 이어붙여 체크포인트 확보(중단 시 완료 배치 보존).

- **수정 루프 축소** — 게이트별 최대 2회 → 1회. 미해결은 잔여 리스크로 기록.

- **writer 한 단계 하향 허용** — opus 세션이면 sonnet 스폰 가능(사용자에게 고지). reviewer는 유지.

- **출처 검증 표본화** — 핵심 수치·핵심 주장의 출처는 여전히 **전수** 확인, 주변부 서술의 출처만 표본 확인. 열어보지 못한 출처는 `05`에 목록으로 명시한다(숨기지 않는다).

### ③ 지연 폴백 래더 (런타임)

Phase 1에서 `_workspace/_run_log.md`에 프로파일·산출물 모드·시작 시각을 기록하고, **각 Phase 종료 시와 단계 내 다중 스폰 사이**에 현재 시각(`date`)을 한 줄씩 덧붙인다. 어느 단계의 경과가 안내 예산의 2배를 넘거나 누적 경과가 예산 합을 넘으면, **남은 단계**에 아래를 순서대로 적용한다:

> **안내 예산** — 실측 완주 기록 기반. 환경 속도에 따라 배율 조정.

> | 단계 | 표준 50p | 브리프 4~8p |

> |---|---:|---:|

> | 설계+게이트 | 8분 | 4분 |

> | 조사 | 12분 | 6분 |

> | 집필 | 15분 | 7분 |

> | 검수+수정 | 12분 | 3분 |

> | 변환 | 5분 | 3분 |

> | **합계** | **52분** | **23분** |

> **이 예산은 분할 병렬을 전제한다** — 조사 2~4분할, 표준 집필 장 배치 병렬, 표준 검수 축 분할. 순차로 돌리면 2~3배가 되므로, 예산 초과의 첫 원인은 대개 병렬화를 안 한 것이다. 래더 2단계(다운시프트)로 넘어가기 전에 1단계(분할·병렬화)를 실제로 적용했는지 먼저 확인하라.

1. **분할·병렬화** — 남은 조사를 분할 병렬로, 남은 집필을 장 배치로 (가장 값싼 수단이므로 먼저 쓴다)

> **무손실은 아니다.** 설계 개정과 조사를 동시에 돌리면 **조사→설계 피드백 경로가 끊긴다** — 조사가 설계 전제를 반증해도 개정본은 그것을 모른 채 확정된다(실측 3건: 규제 전제 반증·해외 총평 무효화·수치 오독 위험). 병렬로 돌렸다면 **리더가 반증을 회수해 다음 단계 계약에 직접 실을 책임**을 진다. 판단 기준은 "목차·장 배정이 바뀌는가" — 바뀌면 재개정, 서술 정교화 수준이면 집필 계약으로 하달한다.

> **집필을 병렬로 나누면 집필가끼리 서로를 못 읽는다.** 서식 계약(계층·글머리·캡션 위치·강조)과 용어 통일 목록을 **모든 프롬프트에 같은 문면으로** 넣어라. 표·그림 번호는 설계가 장별로 배정해 두고 그대로 쓰게 한다(번호 충돌은 병렬 집필의 대표적 사고 지점이다).

- 2. **모델 다운시프트** — writer를 sonnet으로 (reviewer 제외). 조사·변환은 이미 sonnet이며 haiku로 더 낮추지 않는다(시범에서 haiku 집필·변환 모두 실패 — docs/model-guide.md)

+ 2. **모델 다운시프트** — writer를 sonnet으로 (reviewer 제외). 조사는 sonnet, 변환은 세션 모델을 유지하며 둘 다 haiku로 낮추지 않는다(시범에서 haiku 집필·변환 모두 실패 — docs/model-guide.md)

3. **루프 축소** — 남은 수정 루프를 1회로

4. **범위 협상 (사용자 게이트)** — 완료 산출물 경로·경과·남은 작업을 보고하고 선택지를 제시한다: 그대로 계속 / 쾌속 전환 / 브리프 전환 / 마크다운까지만(hwpx 보류). 무응답·자율 실행 상황이면 "쾌속 전환"을 기본값으로 진행하고 가정을 `_run_log.md`에 기록.

1~3단계는 리더 재량으로 즉시 적용하되 최종 보고에 적용 내역을 명시한다. 4단계는 산출물이 달라지므로 사용자 확인을 거친다. 산출물 파일 계약(`01`~`06`) 덕분에 어느 단계에서 멈춰도 완료분은 보존된다 — 래더는 "다시 시작"이 아니라 "남은 것만 가볍게"다.

### 실패 시 업시프트 (다운시프트의 역방향)

하위 모델 단계가 실패하면 한 단계 위 모델로 **1회** 재스폰한다:

- - exporter(sonnet)가 자체 검증 스위트(표 행수 대조·왕복 대조) 실패 또는 지정 양식 매핑 혼란 → inherit 재스폰 + 리더 보고.

+ - exporter(세션 모델)가 자체 검증 스위트(표 행수 대조·왕복 대조)에 실패하거나 지정 양식 매핑이 혼란스러우면 → 같은 모델로 1회 재스폰, 재실패 시 리더가 원인을 보고하고 마크다운 산출물을 유지한다.

- investigator(sonnet)가 출처 신뢰도 판별 불가 항목을 만나면 → 해당 항목만 상위 모델로 재조사하거나 [미확보]로 남겨 reviewer 검증에 위임.

업시프트도 `_run_log.md`에 기록한다.

## 에이전트 구성

| 팀원 | 타입 | 역할 | 스킬 | 출력 |

|------|------|------|------|------|

- 팀원 모델은 단계별 티어 기본값을 따른다 — designer·writer·reviewer `inherit`, investigator `sonnet`, hwpx-exporter `sonnet`(위 "실행 프로파일" 절). 스폰 시 `model`을 명시하지 않아야 이 기본값이 적용되며, 품질 우선일 때만 의도적으로 상위 모델로 올린다. 검토관(reviewer)은 파이프라인에서 **두 번** 등판한다(설계 후·초안 후).

+ 팀원 모델은 단계별 티어 기본값을 따른다 — designer·writer·reviewer `inherit`, investigator `sonnet`, hwpx-exporter `inherit`(위 "실행 프로파일" 절). 스폰 시 `model`을 명시하지 않아야 이 기본값이 적용되며, 품질 우선일 때만 의도적으로 상위 모델로 올린다. 검토관(reviewer)은 파이프라인에서 **두 번** 등판한다(설계 후·초안 후).

## 워크플로우

### Phase 0: 컨텍스트 확인 (후속 작업 지원)

작업 디렉토리의 `_workspace/` 존재 여부로 실행 모드를 결정한다:

- **`_workspace/` 미존재** → 초기 실행. Phase 1로.

- **`_workspace/` 존재 + 부분 수정 요청** (예: "설계 다시", "5장만 다시", "근거 보강", "검수 다시", "hwpx만 재생성") → 부분 재실행. 해당 에이전트만 재호출하고 그 산출물만 갱신한다. 의존 산출물(설계 변경 시 → 조사·집필·검수도 영향)을 함께 갱신할지 판단한다.

- **`_workspace/` 존재 + 새 주제/새 입력 제공** → 새 실행. 기존 `_workspace/`를 `_workspace_{YYYYMMDD_HHMMSS}/`로 이동 후 Phase 1로.

부분 재실행 시 이전 산출물 경로를 해당 에이전트 프롬프트에 포함해, 기존 결과를 읽고 피드백을 반영하도록 지시한다. **후속 지시도 `_workspace/00_request.md` ⑤에 원문으로 추가한다** — 수정 요청이 처음 의도를 바꾸는 것인지(의도 확인서부터 갱신) 같은 의도 안의 손질인지(해당 산출물만 갱신)를 원장에서 대조해 판단한다.

### Phase 1: 준비 (입력 수집 + 자료 라우팅)

1. 사용자 입력 분석 — 연구 주제, 정책 맥락, 메모, **기존 보고서 초안·관련 자료·통계·논문**, 산출물 수준·분량(기본 **최소 50p**), 출력 경로, 지정 양식 유무, **속도 단서**("빨리"·마감 임박 → 쾌속 프로파일)를 파악한다.

2. `_workspace/` 생성 (새 실행이면 기존 것을 타임스탬프 디렉토리로 이동 후 재생성).

3. **요청 원문 원장 작성 — `_workspace/00_request.md`** (설계자의 1차 입력). 리더가 요청을 요약해 스폰 프롬프트에 옮기는 순간 의도가 한 번 깎인다. 낱말 선택·수식어("~중심으로")·쓰임 단서("~ 협의 전에")가 요약에서 먼저 사라지는데, 설계자가 의도를 읽어내는 재료가 바로 그것이다. 그래서 원문을 파일로 고정하고 설계자·검토관이 직접 읽게 한다.

- **① 최초 요청** — 사용자가 쓴 글자 그대로. 고치거나 줄이거나 다듬지 않는다. **접수 일자**를 함께 적는다("다음 달"·"내년" 같은 상대 시점을 설계자가 실제 날짜로 읽고 행정 일정에 비춰 볼 수 있게). **요청 글은 `> ` 인용 블록으로 적는다** — `check_intent.py`는 ① 아래 인용 블록을 최초 요청으로 읽는다. 일반 문단으로 적으면 "최초 요청을 찾지 못했다"는 [필수]가 난다(시범 실측).

- **② 같은 대화의 관련 발언** — 요청 앞뒤로 사용자가 한 말 가운데 목적·독자·기한·선호에 닿는 것을 원문으로 옮긴다.

- **③ 첨부 자료** — `00_input/_index.md` 참조로 갈음.

- **④ 리더 메모(해석 — 원문 아님)** — 리더가 읽어낸 맥락·모드 판별은 이 칸에만 적는다. 설계자는 이 칸을 〔추론〕의 단서로만 쓴다. ①·②에 리더의 해석을 섞지 않는다.

- **⑤ 이후 발언(추가 전용)** — 분기 질문 답변, 목차 수정 지시, 후속 요청을 시각과 함께 원문으로 덧붙인다. 지우거나 고쳐 쓰지 않는다. 대화가 압축되거나 세션이 바뀌어도 사용자가 실제로 한 말이 여기 남는다.

4. **입력 자료 저장 + 인덱싱** — 사용자가 준 모든 자료를 `_workspace/00_input/`에 저장하고, `_workspace/00_input/_index.md`에 "파일명 — 성격(초안/통계/논문/메모) — 어느 단계·에이전트가 쓸지"를 한 줄씩 기록한다. **이 인덱스가 라우팅의 핵심**: 오케스트레이터가 각 에이전트 스폰 프롬프트에 "읽을 입력 파일 경로 + 용도"를 명시해 배분한다.

- **자료 라우팅 규칙:** 정책 방향·범위 단서 → designer / 통계·문헌·사례·출처 → investigator / **기존 초안** → writer(베이스로 개정) + reviewer(검수 대상) / 양식 → hwpx-exporter.

- **양식이 있으면 designer·writer·reviewer에게도 준다.** 지금까지 양식은 변환가에게만 갔지만, 서식은 집필 단계에서 맞춰야 위계가 밀리지 않는다. 집필가에게는 서식 규격(계층·글머리·캡션 위치·강조 규율)을, 설계자에게는 장 골격과 목차 작성 단계를, 검수관에게는 축 6(양식 준수) 점검을 지시한다. **양식이 둘 이상이면 산출물 모드에 맞는 하나만 하달한다** — 글머리 체계가 서로 달라 섞이면 위계가 무너진다.

- **사용자가 기존 초안을 제공한 경우:** 백지 집필이 아니라 그 초안을 출발점으로 삼는다. designer는 초안의 구조를 분석해 목차를 역설계·보완하고, investigator는 초안 주장의 출처를 검증·보강하며, writer는 초안을 개정한다. 이 분기를 각 에이전트 프롬프트에 명시한다.

5. 주제가 막연해도 여기서 리더가 묻지 않는다. Phase 3의 설계자가 원문을 읽고 목차를 가르는 질문만 골라낼 것이므로, 여기서는 명백한 누락(자료가 첨부됐다는데 없음 등)만 짚는다.

6. `_workspace/_run_log.md`에 실행 프로파일(표준/쾌속)·산출물 모드·시작 시각을 기록한다 — 지연 폴백 래더의 기준점("실행 프로파일" 절).

### Phase 2: 팀 구성

1. `TeamCreate(team_name: "policy-research-team", members: [...])` — 위 5개 팀원을 각 에이전트 정의(custom type)로 스폰한다. **`model`은 지정하지 않는다** — 각 에이전트 정의의 단계별 티어가 적용되게 둔다. 각 프롬프트에 담당 스킬명·`_workspace/` 경로·입출력 파일·hwpx 입출력 경로(`04_report_draft.md`→`06_report.hwpx`)를 명시한다.

2. `TaskCreate`로 의존성 있는 작업을 등록한다:

- T1 연구설계 (designer)

- T2 **설계 검토 게이트** (reviewer 모드1) — `depends_on: [T1]`

- T3 근거조사 (investigator) — `depends_on: [T2 승인]` (승인된 목차의 필요근거를 조사)

- T4 집필 (writer) — `depends_on: [T2 승인, T3]`

- T5 초안검수 (reviewer 모드2) — `depends_on: [T4]`

- T6 hwpx 변환 (exporter) — `depends_on: [T5 승인]`

### Phase 3: 설계 + 게이트 (생성-검증 루프 ①)

**실행 방식:** designer ↔ reviewer(모드1) 피드백 루프

1. designer가 `00_request.md`(요청 원문)를 먼저 읽고 **의도 확인서** + RQ·분석틀·목차·연구방법을 설계해 `01_research_design.md`를 작성한다. **스폰 프롬프트에 요청을 요약해 넣지 않는다 — 원장 경로를 준다.** designer는 요약의 첫 줄에 의도 한 문장과 확신도를 돌려준다.

- **리더가 해석을 선점하지 않는다.** 실측에서 리더는 원문을 지우지 않았다 — 글자 그대로 넘겼다. 문제는 그 옆에 "중심 질문은 이것", "접근 각도 후보 세 가지", "브리프 8쪽"을 미리 정해 붙인 것이었다(원문을 직접 읽은 설계자들은 20~30쪽 보고서로 판단했다). 추론이라고 표시해도 설계자의 해석은 리더의 해석에 닻을 내린다. 리더의 읽기는 원장 ④에만 적고, 스폰 프롬프트에서 중심 질문·각도·목차 골격을 정해 주지 않는다. **산출물 모드도 잠정이다** — 원문의 분량 단서("길 필요 없다")가 모드 기본값과 어긋나면 리더가 쪽수를 정하지 말고 설계자가 분기 질문으로 올리게 한다.

- **의도 확인서의 양식을 스폰 프롬프트에 다시 풀어 쓰지 않는다.** 양식과 등급 이름(〔명시〕/〔추론〕/〔미상〕)은 `policy-research-design` 스킬이 정한다. 리더가 풀어 쓰면 용어가 어긋난다(실측: 리더가 〔명시〕를 〔확인〕으로 바꿔 적었다). 프롬프트에는 원장 경로·출력 경로·이번 실행에만 해당하는 계약(조사 항목 번호 고정, 표·그림 번호 장별 배정 등)만 싣는다.

- **리더가 글자 대조를 다시 돌린다.** designer가 돌아오면 `policy-research-design` 스킬 폴더의 `scripts/check_intent.py`를 리더가 직접 실행한다(`--request _workspace/00_request.md --design _workspace/01_research_design.md`, 브리프면 `--brief`). 설계자의 자기 점검 보고를 믿지 않는다. [필수]가 있으면 게이트로 보내지 않고 designer에게 되돌린다 — 〔명시〕 인용이 원문에 없거나 리더 메모에만 있는 것, 반영 위치가 빈 요구어, 기본 가정 없는 분기 질문, 수용 기준 누락이 여기서 걸린다. 결과는 검토관 프롬프트에 붙인다. 통과는 글자가 맞다는 뜻일 뿐이다.

- **확신도 '낮음'이면 게이트 전에 먼저 묻는다.** 리더는 의도 한 문장, 〔추론〕·〔미상〕 항목, 분기 질문(기본 가정 포함)을 사용자에게 보이고 답을 받는다. 해석이 바뀌면 목차가 통째로 바뀌므로 검토관 게이트를 돌린 뒤에 묻는 것보다 싸다. 답은 원장 ⑤에 원문으로 추가하고, designer가 **의도 확인서부터** 고친다.

- **확신도 '높음'이면 묻지 않고 게이트로 간다.** 분기 질문은 기본 가정을 단 채 5단계 목차 승인 때 함께 보인다. 요청이 이미 분명한데 되묻는 것도 비용이다.

- 무응답·자율 실행이면 기본 가정으로 진행하고 원장 ⑤에 "무응답 — 기본 가정 적용"을 적는다.

- **기다리는 동안 멈추지 않는다.** 사용자에게 물어 놓고 답을 기다리는 시간(확신도 '낮음'의 선확인, 5단계 목차 승인)에, 설계의 조사 항목 가운데 **〔공통〕 표시가 붙은 것만** 조사관에게 먼저 맡길 수 있다. 어느 답이 와도 버려지지 않는 일이다.

- 〔갈림〕 항목 조사와 집필은 사용자의 답과 승인 뒤에 한다. 6단계의 "승인 후에만 Phase 4"는 〔갈림〕 조사와 그 뒤 단계에 그대로 적용된다.

- 항목 번호는 설계의 것을 그대로 쓴다("번호는 바꾸지 말고 추가만"). 조사 상한도 그대로다.

- 선행 조사가 설계의 전제를 반증하거나 「확인할 전제」에 답을 주면, 리더가 그 결과를 회수해 사용자에게 보일 내용과 designer 개정에 싣는다(조사→설계 피드백을 리더가 잇는다).

- `_run_log.md`에 "선행 조사 시작 — 〔공통〕 n건"을 적는다. 사용자의 답으로 해석이 바뀌어 〔공통〕이라던 항목이 쓸모없어졌으면 그것도 적는다 — 설계자의 범위 표시가 틀린 것이다.

- **읽기가 틀렸으면 오독 사례로 남긴다.** 분기 질문의 답이 기본 가정과 달랐거나, 사용자가 의도 한 문장을 고쳤으면 `policy-research-design` 스킬 폴더의 `scripts/misreads.py add`로 한 건 적는다(요청 원문 구절 · 설계자의 읽기 · 사용자의 정정 원문 · 다음에 적용할 것). 다음 실행의 설계자가 이 파일을 읽는다.

2. designer가 reviewer에게 "설계 검토 요청"을 SendMessage로 보낸다.

3. reviewer(모드1)가 **`00_request.md`와 `01`을 함께** 읽어 판정(승인/조건부/반려)과 항목별 지적을 **최종 보고로 반환**하고, 리더가 이를 그대로 `02_design_review.md`에 저장한다(reviewer는 `disallowedTools`로 쓰기 도구가 제거된 읽기 전용 에이전트라 파일을 직접 쓰지 않는다). 검토관은 설계자의 의도 요약을 기준으로 삼지 않고 원문과 직접 대조한다(의도 충실성). 리더는 검토관 프롬프트에도 원장 경로를 준다.

- **검토관은 먼저 혼자 읽는다** — `01`을 열기 전에 원문만 읽고 의도 한 문장을 따로 써 둔 뒤 설계자의 것과 견준다. 리더는 검토관 프롬프트에 설계자의 의도 한 문장을 **옮겨 적지 않는다**(옮기면 독립 독해가 무너진다). 두 문장이 갈려 검토관이 확신도를 '낮음'으로 내리면, 리더는 5단계 승인 화면 맨 위에 두 독해를 나란히 보이고 사용자가 고르게 한다. 설계자의 확신도는 자기 평가여서 후하게 나온다.

4. 반려·조건부면 designer가 `01`을 개정 → 재검토. **최대 2회.** 2회 후에도 미승인 항목은 "설계 잔여 리스크"로 기록하고 진행한다.

- **개정이 의도를 깎으면 드러낸다.** 게이트는 실행 가능성 쪽으로 설계를 민다 — RQ를 낮추고 장을 덜어낸다. 그 결과 의도 한 문장이 약해졌으면 designer가 `01` §1 「의도 대비 달라진 점」에 적고, 리더가 5단계에서 사용자에게 보인다. 조용히 낮추지 않는다.

- **브리프 모드는 개정 라운드를 돌지 않는다.** 게이트는 그대로 수행하되(품질 장치는 유지) designer를 재스폰하는 대신, 리더가 `02`의 [필수] 지적을 **조사·집필 프롬프트에 계약으로 직접 하달**한다. 설계 문서에 남아야 하는 항목(조사 목록 추가 등)만 리더가 `01`에 직접 Edit로 반영한다. 4~8쪽 산출물에서 설계 개정 왕복은 반영 효과 대비 시간 비용이 크고, 실측상 [필수] 지적 대부분은 집필 계약으로 넣어도 같은 효과를 낸다. 리더가 하달하면서 범위를 낮췄으면 「의도 대비 달라진 점」도 리더가 적는다.

5. **★ 목차 사용자 승인 게이트 (필수)** — 설계 게이트를 통과하면, 리더는 아래 순서로 사용자에게 제시하고 승인을 받는다. (검토관의 내부 게이트는 "실행 가능성"과 "원문 대비 충실성"을, 이 게이트는 사용자 본인의 확인을 받는다.)

1. **의도 한 문장** — "이렇게 이해했습니다". 목차만 보이면 사용자가 목차에서 의도를 거꾸로 짐작해야 한다. 이해한 바를 먼저 보이면 오독이 한 줄에서 잡힌다.

2. **분기 질문 → 확인할 전제 → ★ 가정 → 나머지 추론·가정** — 분기 질문(기본 가정 · 답이 다르면 바뀌는 곳), 요청문의 사실관계 가운데 어긋나 보이는 전제, 틀리면 결론·핵심 수치가 바뀌는 ★ 가정을 먼저 보이고, 나머지 〔추론〕 항목과 가정은 목록으로 붙인다.

3. **목차(장·절·분량) + 핵심 RQ + 분석틀 요약** — 장마다 의도 연결 한 구절.

4. **수용 기준(A1…)** — 초안이 나왔을 때 "의도를 수행했다"고 판정할 문장. 사용자가 고치거나 더하면 그것이 검수의 기준이 된다.

5. **의도 대비 달라진 점** — 게이트 개정으로 낮아지거나 빠진 것. 없으면 "없음".

- **한 화면에 담는다.** 사용자가 실제로 검토할 수 있는 양이 이 게이트의 용량이다. 위 다섯 가지만 보이고, 요소 표·요구어 대조·대응표·조사 목록은 `01` 경로로 안내한다. 설계 문서 전문(실측 260~300줄)을 그대로 붙이면 승인은 형식이 된다.

- 사용자의 답·수정 지시는 원장 ⑤에 원문으로 추가한다. 사용자가 목차를 수정·추가·삭제하면 designer가 `01`에 반영 후 다시 제시한다.

- **방향 자체가 뒤집히면 부분 개정하지 않는다.** 의도 해석이 바뀐 것이므로 designer가 의도 확인서부터 다시 쓰고 게이트를 다시 돈다. 무엇을 어떻게 잘못 읽었는지 `misreads.py add`로 남긴다.

- **사용자 승인(또는 명시적 "그대로 진행") 전에는 Phase 4(조사)로 넘어가지 않는다.** 50p급 보고서는 목차 한 줄이 며칠치 조사·집필을 좌우하므로 이 게이트가 비싼 헛작업을 막는다.

6. **설계 게이트 통과 + 사용자 목차 승인 후에만** Phase 4로 넘어간다. 예외는 하나다 — 답을 기다리는 동안 〔공통〕 항목만 먼저 조사하는 것(1단계 「기다리는 동안 멈추지 않는다」). 〔갈림〕 조사와 집필은 승인 뒤다.

### Phase 4: 근거조사

**실행 방식:** investigator 단독 (병렬 조사 가능)

1. designer가 승인 목차의 항목별 "조사 우선순위·필요근거"를 investigator에게 전달한다. **조사관 프롬프트에도 의도 카드**(의도 한 문장·독자·수용 기준)를 싣는다 — 조사 상한 안에서 무엇부터 팔지는 의도의 무게중심이 정한다.

2. investigator가 통계·문헌·국내외사례·정책배경을 조사해 `03_evidence.md`에 출처와 함께 정리한다. 미확보 항목은 명시한다.

3. **분할 병렬 스폰 — 기본값이다(안내 예산이 이를 전제한다).** 국내 통계·현황 / 해외 사례 / 문헌·법제도 등으로 나눠 동시 스폰하고 `03_evidence_domestic.md`·`03_evidence_intl.md` 식으로 저장한다. 표준 3~4분할, 브리프 2분할. 이후 writer·reviewer 프롬프트에 모든 `03_evidence*.md` 경로를 명시한다.

- **조사 상한(브리프 필수, 표준 권장)** — 분할당 **도구 호출 20회·출처 10건**을 프롬프트에 명시한다. 상한 없이 두면 4쪽 브리프에도 분할당 60회를 쓴다(실측). 상한에 걸려 못 판 항목은 `[미확보]`가 아니라 **"상한 도달 — 추가 조사 가능"**으로 구분해 기록한다. 둘을 섞으면 "자료가 없다"와 "안 찾았다"가 구별되지 않는다.

- **상한이 핵심 항목에서 바닥나면 리더가 그 항목만 한 번 더 판다.** 조사관이 돌아오면, 의도 한 문장의 핵심 동사(예: "실제로 어떻게 돌아가고 있는지")나 수용 기준에 걸린 항목 가운데 "상한 도달"·"미발견"이 있는지 본다. 있으면 집필 전에 그 항목만 표적 보강 조사(도구 15회, 기준일 직전 6개월의 보도·기관 공지·국회 자료 우선)를 한 번 돌린다. 시범 실측: 브리프 국내 조사가 상한 20회에 걸려 운영 실태 수치(상담 건수·확인 요청 건수·기관 자체 판정 사례)를 놓쳤고, 같은 요청에 도구 47회를 쓴 순정 Claude Code가 그 수치를 찾아 블라인드 감사에서 "회의에 낼 판"으로 뽑혔다. 상한은 헛조사를 막는 장치이지 핵심 질문을 굶기는 장치가 아니다.

- **항목 번호 계약을 명시하라** — 설계 개정과 조사를 병렬로 돌리면 조사 목록 번호가 어긋나 산출물이 서로 안 맞는다. 각 조사관·개정자 프롬프트에 "설계 §6의 항목 번호는 바꾸지 말고 추가만"을 넣는다(실측 확인된 사고 지점).

4. 완료 시 writer에게 알린다.

### Phase 5: 집필 + 검수 (생성-검증 루프 ②)

**실행 방식:** writer ↔ reviewer(모드2) 피드백 루프

1. writer가 `01`(승인 설계)·`03`(근거)·`00_input/`의 사용자 자료(기존 초안 있으면 베이스로)를 종합해 `04_report_draft.md`를 작성한다.

- **의도 카드를 집필 프롬프트 맨 위에 싣는다** — `01` §1에서 의도 한 문장·독자·필수/금기·수용 기준·사용자가 쓴 핵심 낱말을 옮긴다(병렬 배치면 모든 배치에 같은 문면으로). 설계 단계에서 읽어낸 의도가 집필에 전달되지 않으면, 목차는 맞는데 독자가 이미 아는 것에 지면을 쓰는 초안이 나온다.

- **표준 목차:** 1.서론 → 2.이론적 배경 → 3.해외 동향 분석 → 4.국내 현황 분석 → 5.정책 대안 → 6.정책 우선순위·추진 로드맵 → 7.정책제언·결론 → **참고문헌**(말미). (사용자 승인 목차가 우선)

- **분량: 본문 최소 50p.** 분량 미달 시 각 장 심도를 보강한다(분야별 심화·근거 추가·대안 정교화). 빈 말로 늘리지 말고 근거·분석으로 채운다.

- **참고문헌 필수:** 본문에서 인용한 모든 출처를 말미에 일관 형식(기관·문서명·연도·URL/페이지)으로 정리하고, 본문 인용과 1:1 대응시킨다.

- **장 배치 분할 — 표준은 병렬, 브리프는 단일 스폰.** 표준 모드는 목차를 2~3배치로 나눠 **동시 스폰**하고 `04_batch1.md`·`04_batch2.md`로 각각 저장한 뒤, 리더가 순서대로 이어붙이고 **문체·용어 통일 패스를 한 번** 돌린다(용어 흔들림·중복 정의·중복 표 제거). 순차 스폰은 배치 수만큼 시간이 곱해지므로 **지연 래더가 발동한 뒤에만** 쓴다. 브리프는 7,000자 수준이라 분할 이득이 없어 단일 스폰이 기본이다.

- 병렬 배치 프롬프트에는 **공통 계약**(자수 배분·표 규격·인용 형식·금지 사항)을 동일하게 넣고, 각 배치에 "다른 배치가 맡은 장은 쓰지 마라 / 상호참조는 장 번호로만"을 명시한다. 중단·지연 시 완료 배치는 파일로 보존되므로 남은 배치만 재개한다.

- **집필 프롬프트에 규율 파일 경로를 준다** — "집필 전 `policy-report-writing/references/clarity-rules.md`를 읽어라". 규칙을 프롬프트에 다시 풀어 쓰지 않는다(옮겨 적다 문구가 바뀐다).

- **리더가 명료성 점검기를 돌린다.** writer가 돌아오면(병렬 배치면 이어붙이고 통일 패스를 마친 뒤) `policy-report-writing` 스킬 폴더의 `scripts/check_clarity.py _workspace/04_report_draft.md --report _workspace/04c_clarity.md`를 리더가 직접 실행한다. 집필가의 자기 점검 보고를 믿지 않는다. '높음'이면 검수 전에 걸린 자리를 고친다 — 표준은 writer에게 되돌리고, 브리프는 리더가 직접 Edit한다(작업 태그 삭제·대시 꼬리 독립 문장화·비유를 대상으로 바꾸기 같은 비창작성 수정이다). '주의' 이하면 결과를 검토관 프롬프트에 붙여 축 4의 근거로 쓰게 한다. 점검기 통과는 기계가 보는 신호가 없다는 뜻일 뿐, 명료하다는 판정이 아니다.

2. reviewer(모드2)가 `04`를 `01`·`03`과 교차검증해 **5축(논리/근거/정책타당성/정량성 + 참고문헌·출처 검증)**으로 수정 요청을 **최종 보고로 반환**하고, 리더가 이를 그대로 `05_draft_review.md`에 저장한다.

- **출처 검증:** 본문 인용 ↔ 참고문헌 목록 일치, 각 출처의 실재·접근가능성, 인용 수치와 출처 내용 일치, 미검증·불일치 출처 플래그. 분량 50p 충족 여부도 점검한다.

- **의도 수행 점검:** 논리 축에서 `01` §1의 **수용 기준별로 충족/일부/미충족**을 판정한다. RQ에는 답했는데 쓰임에 못 미치는 초안을 여기서 잡는다. 검수관 프롬프트에 `00_request.md` 경로를 함께 준다. 기준을 다 충족했는데도 쓰임에 못 미치면 `기준 외` 지적으로 올라오고, 리더가 그것을 수용 기준에 추가한다 — 기준은 결과물을 보면서 다듬어진다. 초안을 본 사용자의 "이게 아닌데"도 같은 방식으로 원장 ⑤와 수용 기준에 더하고, 설계 단계의 읽기가 틀린 탓이면 오독 사례로도 남긴다.

- **표준 모드는 축 분할 병렬** — 5축을 2~3 에이전트로 나눠 동시 스폰(예: ①논리·정책타당성 / ②근거·정량성 / ③참고문헌·출처 전수)하고 리더가 `05`로 병합한다. 출처 전수 검증은 도구 호출이 많아 단독 축으로 떼는 편이 빠르다. 브리프는 3축 단일 스폰.

- **집필가에게 준 금지 목록이 곧 집필가의 자기검사 범위가 된다**(실측 확인 — 자기보고는 전 항목 재현됐는데 [필수] 지적은 전부 목록 밖에서 나왔다). 검수관 프롬프트에 "금지 목록 준수를 재현 검증하되 **목록 밖 영역**(표와 본문의 정합, 각주·참조 무결성, 근거 셀과 논지의 크기 일치)을 별도로 훑어라"를 명시한다.

3. writer가 [필수]·[권고] 지적을 반영해 `04`를 개정한다. **최대 2회 반복.** 동일 항목 2회 미해결은 "잔여 리스크"로 기록하고 진행.

- **브리프 모드는 writer 재스폰을 하지 않는다.** [필수] 지적 대부분은 비창작성 수정(수치 정의 정정, 근거 셀 교체, 단정→추정 어법, 출처 보정)이므로 **리더가 직접 Edit로 반영**하고, 새 문단·새 논증이 필요한 항목만 writer를 부른다. 재스폰 1회가 브리프 전체 시간의 5분의 1을 먹는다(실측 17분 45초).

- **개정 자체가 2차 결함을 만든다** — 표 셀을 고치면 그 셀이 달고 있던 각주가 고아가 된다. 각주·참고문헌 참조 무결성을 개정 후 상시 점검 항목으로 둔다. 개정 후에는 자기보고를 믿지 말고 **리더가 전수 grep으로 재현 검증**한다(금지 수치 잔존·내부 식별자 노출·표시 개수).

> **운영 유의(검증된 사항):** 백그라운드로 재개(SendMessage)된 서브에이전트는 Write/Edit 권한이 거부될 수 있다. 따라서 writer 수정 루프는 **전경(foreground) Agent 호출**로 실행하거나, reviewer가 승인한 비창작성 수정안을 **오케스트레이터(리더)가 직접 Edit로 반영**한다. 사용자 입력이 필요한 항목(예: 미확보 통계)은 `[보강 필요]`로 남긴다.

4. 검수 통과 시 reviewer가 "초안 승인"을 리더와 hwpx-exporter에게 알린다.

### Phase 6: 변환

**실행 방식:** 승인 후 변환

1. hwpx-exporter가 승인된 `04_report_draft.md`를 입력으로 받는다.

2. `00_input/`에 지정 양식이 있으면 폼 채우기, 없으면 표준 생성으로 .hwpx를 만든다.

3. 변환 후 재파싱 자체검증, 분량·양식 점검.

- **리더가 변환 결과를 직접 다시 잰다.** 변환가의 "무손실" 보고를 믿지 않는다 — 원고와 hwpx의 표별 행×열, 본문 왕복 유사도(XML 문자 표기 `"` 등은 풀고 비교)를 리더가 따로 계산한다. 시범 실측: haiku 변환가가 유사도 0.70(본문 약 45% 소실)인 파일을 "0.999+, 제출 가능"으로 보고했다.

4. 최종 산출물을 사용자 지정 경로에, 사본을 `_workspace/06_report.hwpx`에 저장한다.

### Phase 7: 정리·보고

1. 팀원에게 종료 요청(SendMessage) 후 `TeamDelete`.

2. `_workspace/`는 보존한다 (사후 검증·재실행용).

3. 사용자에게 요약 보고: 최종 hwpx 경로, **의도 한 문장 대비 달성 여부**(수용 기준별 충족/일부/미충족 · 진행 중 가정으로 처리한 분기 질문과 ★ 가정), RQ에 대한 답 요약, 핵심 정책제언, 잔여 리스크·`[보강 필요]`·미확보 근거, 입력 자료 한계.

4. 피드백을 요청한다 ("수정하거나 보완할 부분이 있나요?").

5. 이번 실행에서 오독 사례를 남겼으면 `misreads.py summary`를 돌린다. 같은 유형이 두 번 쌓여 **승격 후보**로 뜨면 사용자에게 알린다 — 사례 파일에 두지 말고 설계 스킬 본문의 규칙으로 올릴 때다. 올린 뒤에는 회귀 세트(`scripts/regress.py`)로 확인한다.

## 데이터 흐름

```

[리더] 00_request.md (요청 원문 원장 — designer·reviewer가 직접 읽음, 사용자 발언은 추가 전용)

[리더] TeamCreate + TaskCreate

policy-research-designer ──01_research_design.md──┐ (§1 의도 확인서 → 확신도 낮음이면 사용자 선확인)

▲ │ SendMessage(설계 검토 요청) │

(개정,최대2회) ▼ ▼

policy-report-reviewer(모드1) ──02_design_review.md (게이트)

│ "설계 승인"

▼ (승인 후에만 진행)

policy-research-investigator ──03_evidence.md──┐

▼

policy-report-writer ──04_report_draft.md──┐

▲ │ │

SendMessage(수정요청) │ (최대 2회 루프) ▼

policy-report-reviewer(모드2) ──05_draft_review.md

│ "초안 승인" │

▼ │

hwpx-exporter ◀──────────04 승인본───────────┘

│

▼

06_report.hwpx → 사용자 지정 경로

```

## 에러 핸들링

| 상황 | 전략 |

|------|------|

| 팀원 1명 실패/중지 | 리더가 감지 → SendMessage로 상태 확인 → 재시작. 실패 시 해당 산출물 없이 진행하고 보고서에 누락 명시 |

| 설계 게이트 무한 반려 | 동일 항목 2회 초과 미해결 → "설계 잔여 리스크"로 기록 후 진행(완전 차단 방지) |

| 근거 미확보 | investigator가 "미확보"로 명시 → writer가 `[보강 필요]` 표시 → 보고서·최종보고에 명시 |

| 초안 검수 무한 루프 | 동일 항목 2회 초과 미해결 → 잔여 리스크로 기록 후 진행 |

| 상충 근거 | 출처 병기, 삭제 금지. reviewer가 판단·권고 |

| 사용자 확인 질문 미응답 | 분기 질문에 달린 기본 가정으로 진행. 원장 ⑤에 "무응답 — 기본 가정 적용"을 적고 최종 보고에 가정 목록을 다시 보인다 |

| **요청 원문 원장 누락·요약본만 있음** | designer를 스폰하기 전에 리더가 대화에서 원문을 찾아 `00_request.md`를 만든다. 원문을 복원할 수 없으면(세션 교체 등) 원장 ①에 "원문 미확보 — 리더 기억 기반"이라 적어 설계자가 전부 〔추론〕 등급으로 다루게 한다 |

| **목차 승인에서 방향이 뒤집힘** | 부분 개정하지 않는다. 사용자 발언을 원장 ⑤에 추가 → designer가 의도 확인서부터 재작성 → 설계 게이트 재실행. 뒤집힌 원인(어느 〔추론〕이 틀렸는가)을 `misreads.py add`로 오독 사례에 남긴다 |

| **글자 대조 [필수]가 되돌려도 남음** | 2회 되돌려도 [필수]가 남으면 리더가 직접 고친다(인용 정정·반영 위치 기입은 비창작성 수정). 점검 스크립트가 틀렸다고 판단되면 그 줄을 `_run_log.md`에 적고 진행한다 — 통과할 수 없는 게이트를 끄지 말고 오탐을 기록한다 |

| **선행 조사한 〔공통〕 항목이 답 뒤에 쓸모없어짐** | 조사 결과는 `03`에 남기되 본문에 쓰지 않는다. `_run_log.md`에 "범위 표시 오류"로 적는다. 반복되면 설계자가 〔공통〕을 넓게 잡는 것이므로 설계 스킬의 기준을 좁힌다 |

| 지정 양식 파싱 실패 | 표준 hwpx 생성으로 전환, 수동 확인 권장 안내 |

| 백그라운드 Write/Edit 거부 | writer 수정 루프를 전경 호출로 전환 또는 리더가 직접 Edit 반영(위 Phase 5 유의 참조) |

| 단계 지연(안내 예산 2배 초과) | 지연 폴백 래더 순차 적용: 분할·병렬화 → 모델 다운시프트 → 루프 축소 → (사용자 확인) 범위 협상 |

| 하위 모델 단계 실패(변환 검증 실패 등) | 한 단계 위 모델로 1회 재스폰(업시프트). 재실패 시 대안 산출물(마크다운 유지 등) 제시 |

| **인프라 장애**(네트워크·API 오류로 에이전트 중단) | 에이전트 실패와 **구분해 다루라**. 연결을 먼저 확인하고 **같은 프롬프트로 재스폰**한다 — 프롬프트·모델을 손볼 이유가 없다. **지연 래더를 발동하지 마라**: 느려진 게 아니라 멈춘 것이라 다운시프트·분할이 무의미하다. 손실 시간은 `_run_log.md`에 장애로 별기해 예산 초과 원인과 섞지 않는다 |

| **런 간 에이전트 이름 충돌** | 에이전트 이름은 런이 아니라 **세션 범위**이고 `SendMessage`는 동명일 때 최신 등록 우선으로 라우팅한다. 연속 실행 시 앞 런의 동명 에이전트로 통지가 새어 들어간다. 이름에 런 식별자를 붙이고(`writer-std`), **에이전트 간 통지에 산출물을 의존시키지 마라** — 리더가 스폰 프롬프트에 모든 입력 파일 경로를 명시하면 통지가 유실돼도 산출물은 무사하다(파일 계약의 부수 효과) |

## 테스트 시나리오

### 정상 흐름

1. 사용자가 "청년 1인가구 주거비 부담 완화 정책 연구" 주제 + 메모 제공

2. Phase 1: `_workspace/` 생성, 요청 원문을 `00_request.md`에 그대로 기록, 입력 저장

3. Phase 2: 5인 팀 + 6개 작업(게이트 의존성 포함) 등록

4. Phase 3: designer가 원문을 읽고 의도 확인서(용도·독자 〔미상〕, 확신도 낮음, 분기 질문 2개) + RQ 2개·분석틀(현황→쟁점→대안 비교)·목차 설계 → 리더가 분기 질문을 사용자에게 먼저 확인, 답을 원장에 추가 → designer가 의도 확인서 갱신 → reviewer 모드1이 원문 대조 후 "3장 근거 확보 난이도" 지적 → designer 개정 → 승인 → 사용자에게 의도 한 문장·가정·목차 순으로 제시해 승인

5. Phase 4: investigator가 주거실태조사·RIR 지표·해외사례(독일·일본) 조사

6. Phase 5: writer 초안 → reviewer 모드2가 [필수]2·[권고]3 지적 → writer 반영 → 승인

7. Phase 6: 표준 hwpx 생성, 재파싱 검증 통과

8. Phase 7: 데스크탑에 `청년주거_정책연구보고서.hwpx` + RQ 답·핵심 제언 보고

9. 예상 결과: 지정 경로에 hwpx, `_workspace/`에 01~06 산출물 보존

### 에러 흐름

1. Phase 3에서 설계 게이트가 "RQ가 너무 광범위"로 조건부 승인 → designer가 RQ 범위 축소 → 승인

2. Phase 4에서 investigator가 2024년 잠정통계 미공표로 일부 미확보 → `03`에 "미확보" 기록

3. writer가 해당 부분 `[보강 필요]` 표시 후 진행

4. Phase 5 검수에서 해당 항목 확인, 잔여 리스크로 수용

5. 최종 보고에 "2024년 잠정치 미확보 — 공표 후 갱신 권장" 명시

## 공개판 실행 노트 (플러그인 배포판)

- **에이전트 이름 네임스페이스** — 플러그인으로 설치하면 에이전트 타입이 `<플러그인명>:<에이전트명>`(예: `policy-research-kit:policy-research-designer`)으로 표시될 수 있다. 이 문서의 에이전트명은 접미 이름 기준이며, 실제 스폰 시에는 현재 세션의 에이전트 목록에 표시되는 이름을 그대로 쓴다.

- **팀 API 폴백 (중요)** — `TeamCreate`/`TaskCreate`/팀 `SendMessage`(에이전트 팀 실험 기능)가 없는 환경에서는 같은 파이프라인을 **전경(foreground) `Agent` 호출의 순차 실행**으로 수행한다. Phase 순서(설계→게이트→조사→집필→검수→변환)와 산출물 파일 계약은 동일하며, 이 폴백은 실전 검증된 방식이다. 특히 수정 루프는 전경 실행을 권장한다(백그라운드로 재개된 서브에이전트는 Write/Edit가 거부될 수 있음 — 이 경우 리더가 승인된 수정안을 직접 반영).

- - **모델** — 단계별 티어 기본값: designer·writer·reviewer `inherit`, investigator `sonnet`, hwpx-exporter `sonnet`. 권장 세션 모델과 단계별 실측은 `docs/model-guide.md`. 품질을 우선하려면 스폰 시 상위 모델을 명시한다(업시프트). 속도·지연 대응은 "실행 프로파일 — 표준 vs 쾌속" 절의 쾌속 프로파일과 지연 폴백 래더를 따른다.

+ - **모델** — 단계별 티어 기본값: designer·writer·reviewer `inherit`, investigator `sonnet`, hwpx-exporter `inherit`. 권장 세션 모델과 단계별 실측은 `docs/model-guide.md`. 품질을 우선하려면 스폰 시 상위 모델을 명시한다(업시프트). 속도·지연 대응은 "실행 프로파일 — 표준 vs 쾌속" 절의 쾌속 프로파일과 지연 폴백 래더를 따른다.

- **한글(.hwpx) 변환 의존성** — hwpx 산출은 kordoc MCP(제3자, `npx kordoc@latest mcp`)에 의존한다. 미설치 환경에서는 마크다운/docx 산출까지 진행하고 변환 단계만 보류하면 된다.