R&D 제안서 작성 오케스트레이터

정부 R&D 과제 제안서 초안을 5인 에이전트 팀으로 작성해 한글 .hwpx로 산출한다. 2단계 검증 게이트(집필 전 설계 검토 + 집필 후 초안 검수)로 평가위원 감점 요인을 두 번 걸러낸다.

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

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

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

스폰 시 모델을 명시하지 않는다 — 에이전트 정의의 티어 기본값이 적용되도록 둔다. 스폰 프롬프트에 model을 적으면 에이전트 정의를 덮어써 티어가 무력화된다. 품질 우선일 때만 의도적으로 상위 모델을 명시해 되돌린다(예: 난해한 기술분야 공고의 investigator). 정해진 예외 하나 — 발주처 지정 양식이 있으면 exporter를 sonnet으로 명시해 스폰한다. 양식 준수는 자격 요건이고 양식 매핑은 이 파이프라인에서 가장 까다로운 변환이라, 가장 가벼운 모델에 먼저 맡기고 실패를 기다리지 않는다. reviewer는 어떤 프로파일·래더 단계에서도 모델을 낮추지 않는다 — 검증 게이트가 이 킷의 존재 이유다.

② 쾌속 프로파일

트리거: 사용자의 속도 단서("빨리", "쾌속", "마감 임박", "오늘까지" 등) 또는 폴백 래더 4단계에서 사용자가 선택. 제안서는 마감이 곧 자격 요건이라 이 프로파일이 특히 자주 쓰인다. 산출물 범위와 게이트 구조는 유지하고 실행 방식만 경량화한다:

• 조사 분할 병렬 — 시장·산업 / 기술·선행연구·특허 / 정책·법제 등 2~4분할로 동시 스폰, 03_evidence_market.md·03_evidence_tech.md 식으로 분할 저장.
• 집필 섹션 배치 분할 — 목차를 2~3배치로 나눠 순차 스폰, 배치마다 04에 이어붙여 체크포인트 확보(중단 시 완료 배치 보존). 배점 높은 섹션을 먼저 배치한다.
• 수정 루프 축소 — 게이트별 최대 2회 → 1회. 미해결 득점형은 잔여 리스크로 기록. 자격형([필수·자격])은 쾌속에서도 면제되지 않는다 — 사용자에게 올린다.
• writer 한 단계 하향 허용 — opus 세션이면 sonnet 스폰 가능(사용자에게 고지). reviewer는 유지.
• 출처 대조 표본 축소 — 검수의 출처 대조에서 전수 대상(고배점 항목·필수 요구 근거·직접인용·법령 인용)은 그대로 원문을 열고, 나머지 서술의 표본 비율만 2030% → 1015%(최소 3건)로 줄인다. 열어보지 못한 출처는 05에 〔미개봉〕 목록으로 명시한다(숨기지 않는다).

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

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

안내 예산(전체 제안서 기준): RFP분석+게이트 20분 / 조사 40분 / 집필 60분 / 검수+수정 40분 / 변환 20분. 담당 모듈 모드는 절반.

이 수치는 이 킷에서 잰 값이 아니라 설계 때 잡은 잠정치다. 모델·세션 속도·공고 분량에 따라 크게 달라진다. 첫 실행의 _run_log.md에서 단계별 실제 시간을 읽어 이 줄을 자기 환경의 값으로 고쳐 쓴다. 지금까지 잰 것은 한 건뿐이다 — 데모 규모 초안(약 7KB, 출처 4개)의 초안검수 1회차가 출처 대조를 포함해 약 10분(2026-10). 실측값으로 고치기 전에는 "2배 초과"를 기계적으로 적용하지 말고, 제출 마감이 있으면 마감 역산(남은 시간 < 남은 단계 예산의 합)을 발동 기준으로 삼는다.

1. 분할·병렬화 — 남은 조사를 분할 병렬로, 남은 집필을 섹션 배치로 (품질 무손실 수단 우선)
2. 모델 다운시프트 — 남은 조사 잔여분·변환을 haiku로, writer를 sonnet으로 (reviewer 제외)
3. 루프 축소 — 남은 수정 루프를 1회로
4. 범위 협상 (사용자 게이트) — 완료 산출물 경로·경과·남은 작업을 보고하고 선택지를 제시한다: 그대로 계속 / 쾌속 전환 / 저배점 섹션 요약 수준으로 축약 / 마크다운까지만(hwpx 보류). 무응답·자율 실행 상황이면 "쾌속 전환"을 기본값으로 진행하고 가정을 _run_log.md에 기록.

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

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

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

• 리더가 직접 돌린 검증기(verify_hwpx.py)가 종료 코드 1을 내거나 발주처 양식 매핑이 혼란스러우면 → exporter를 한 단계 위 모델로 재스폰(haiku → sonnet → inherit) → 재실패 시 리더 보고. 발동 조건은 변환가의 자기보고가 아니라 리더가 본 종료 코드다 — 가장 가벼운 모델이 스스로 실패를 알아차리기를 기다리지 않는다. 발주처 지정 양식은 자격 요건이라 여기서 물러서지 않는다.
• investigator(sonnet)가 출처 신뢰도 판별 불가 항목을 만나면 → 해당 항목만 상위 모델로 재조사하거나 [미확보]로 남겨 reviewer 검증에 위임.

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

실행 방식 — 리더가 순서대로 스폰한다

이 스킬을 읽는 메인 세션이 리더다. 리더가 Agent 도구로 각 에이전트를 단계 순서대로 스폰하고, 에이전트 사이의 전달은 전부 리더가 맡는다.

• 에이전트끼리 직접 주고받지 않는다. 입력은 _workspace/의 파일 경로로 주고, 검수관의 지적은 리더가 작성가의 다음 스폰 프롬프트에 판정 파일 경로로 넘긴다. 각 에이전트의 회신은 최종 응답 한 번이다.
• 스폰 프롬프트에 넣을 것: 담당 스킬명, _workspace/ 절대 경로, 읽을 파일과 쓸 파일, 모드(검수관), 프로파일(표준/쾌속), 이전 산출물이 있으면 그 경로. model은 적지 않는다("실행 프로파일" ①의 예외 제외).
• 서로 기다릴 필요가 없는 작업은 한 번에 여러 개 스폰한다 — 분할 조사, 대량 편집의 섹션 분할. 순서가 있는 작업(게이트 → 조사 → 집필 → 검수 → 변환)은 앞 산출물 파일이 생긴 것을 확인하고 다음을 스폰한다.
• 파일이 실제로 쓰였는지 리더가 확인한다. 에이전트가 "저장했다"고 답해도 파일의 존재·크기·수정 시각을 본다. 실행 환경이나 권한 설정에 따라 서브에이전트의 파일 쓰기가 거부되는 경우가 있다(백그라운드로 재개된 에이전트에서 보고된 적이 있으나 항상 재현되지는 않는다). 거부되면 그 단계만 전경 호출로 다시 스폰하거나, 에이전트가 응답으로 돌려준 내용을 리더가 파일로 쓴다.
• 같은 에이전트에게 이어서 시킬 일(수정 루프의 재확인, hwpx 재생성)은 새로 스폰하지 않고 SendMessage로 이어 부르면 앞 맥락이 남아 빠르다. SendMessage가 없으면 이전 산출물 경로를 주고 새로 스폰한다.

이 방식이 처음부터 끝까지 완주가 확인된 경로다. 에이전트 팀 API(TeamCreate 등, 실험 기능)로 돌리는 방법은 말미 "팀 API를 쓸 때"에 따로 적었다.

에이전트 구성

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

워크플로우

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

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

• _workspace/ 미존재 → 초기 실행. Phase 1로.
• _workspace/ 존재 + 부분 수정 요청 (예: "필요성만 다시", "설계 다시", "검수 다시", "hwpx만 재생성") → 부분 재실행. 해당 에이전트만 재호출하고 그 산출물만 갱신한다. 의존 산출물(예: 설계 변경 시 조사·집필·검수도)을 함께 갱신할지 판단한다.
• _workspace/ 존재 + 새 공고/새 입력 제공 → 새 실행. 기존 _workspace/를 _workspace_{YYYYMMDD_HHMMSS}/로 이동 후 Phase 1로.

부분 재실행 시 이전 산출물 경로를 해당 에이전트 프롬프트에 포함해, 기존 결과를 읽고 피드백을 반영하도록 지시한다.

Phase 1: 준비

1. 사용자 입력 분석 — 공고문/RFP, 메모, 기존 문서·논문, 과제명, 출력 경로, 발주처 지정 양식 유무, 속도 단서(제출 마감일·"빨리" → 쾌속 프로파일)를 파악한다.
   • 범위 판별: 전체 제안서인가, 팀 공동 제안서의 담당 모듈만인가("내 파트는 여기야"). 모듈 모드면 팀원 원고(.hwp)를 문체 표본으로 확보하고, 집필·검수에 rnd-proposal-writing의 team-module-mode.md 적용을 명시한다.
   • 산출물 분리 원칙: 제안서 본문은 .hwpx, 부속 조사·동향자료는 별도 .docx(하이퍼링크 보존)로 분리 산출한다. 조사자료를 본문에 합본하지 않는다.
2. _workspace/ 생성 (새 실행이면 기존 것을 타임스탬프 디렉토리로 이동 후 재생성).
3. 입력 자료를 _workspace/00_input/에 저장(또는 경로 기록).
4. 입력이 부족하면(공고문 없음, 과제 방향 불명) 작성 착수 전에 사용자에게 짧게 질문한다.
5. _workspace/_run_log.md에 실행 프로파일(표준/쾌속)·산출물 범위·시작 시각·제출 마감을 기록한다 — 지연 폴백 래더의 기준점("실행 프로파일" 절).

Phase 2: 실행 계획

리더가 아래 순서를 계획으로 잡는다. 앞 단계의 조건이 채워지기 전에는 다음 단계를 스폰하지 않는다.

model은 지정하지 않는다 — 각 에이전트 정의의 단계별 티어(rfp-analyst·writer·reviewer inherit / investigator sonnet / exporter haiku)가 적용되게 둔다.

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

실행 방식: rfp-analyst ↔ reviewer(모드1) 피드백 루프(리더 중계) + 목차 사용자 승인

1. rfp-analyst가 공고를 분석해 필수 요구사항·평가지표·배점을 추출하고, 제안서 목차 + 평가대응표를 설계해 01_rfp_analysis.md에 정리한다.
2. 01이 저장된 것을 확인하고 리더가 reviewer를 모드1로 스폰한다.
3. reviewer(모드1)가 01을 검토해 02_design_gate.md에 판정(승인/조건부/반려)을 쓴다 — 필수 요구↔목차 매핑, 고배점 항목 커버리지, 평가대응표 구체성을 본다.
4. 반려·조건부면 리더가 rfp-analyst에게 02_design_gate.md 경로를 주어 01을 개정하게 하고 → reviewer가 재검토한다. 최대 2회. 2회 후에도 남은 득점형·권고는 "설계 잔여 리스크"로 기록하고 진행한다. 남은 자격형(필수 요구 매핑 누락·※단서 미배정·지정 서식 항목 누락)은 잔여 리스크로 흘리지 않고 02_design_gate.md의 "사용자 안건"에 적어 다음 단계의 목차 승인 게이트에서 사용자에게 직접 묻는다.
5. ★ 목차 사용자 승인 게이트 (필수) — 설계 게이트를 통과하면, 리더는 **목차(섹션) + 평가대응표 요약 + 설계 게이트의 "사용자 안건"(있으면)**을 사용자에게 제시하고 승인을 받는다. (검수관의 게이트는 "득점 가능성"을, 이 게이트는 "사용자 의도·전략 부합"을 본다.) 과제명·핵심 문안(제목/추진배경/목적 톤)이 미확정이면 이 시점에 **복수 후보(강조점 병기, 간결안 상위)**로 제시해 선택받는다.
   • 사용자가 목차를 수정·추가·삭제하면 rfp-analyst가 01에 반영 후 다시 제시한다.
   • 사용자 승인(또는 명시적 "그대로 진행") 전에는 Phase 4(조사)로 넘어가지 않는다. 목차 한 줄이 며칠치 조사·집필을 좌우한다. 응답을 기다리는 동안 리더는 목차에 의존하지 않는 준비(입력 자료 인덱싱, 지정 양식 파싱)만 한다.
   • 유일한 예외 — 무인 실행: 사용자가 사전에 "묻지 말고 끝까지 진행"을 지시했거나 응답 주체가 없는 예약·자율 실행일 때만, 설계 게이트를 통과한 목차를 가정으로 삼아 진행한다. 가정한 사실과 "사용자 안건"을 _run_log.md와 최종 보고 첫머리에 적고, 목차 변경 시의 부분 재실행을 안내한다. 대화형 세션에서 답이 늦는다는 이유로는 이 예외를 쓰지 않는다.
6. 설계 게이트 통과 + 사용자 목차 승인 후에만 Phase 4로 넘어간다.

Phase 4: 근거조사

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

1. 리더가 research-investigator를 스폰하면서 01의 평가대응표 "조사 필요 근거" 열을 조사 지시로 준다(배점 높은 항목 우선). 프롬프트에 **"수치마다 〔원문〕/〔계산: 산식〕/〔추정〕을 구분하고 URL을 붙일 것"**을 적는다.
2. research-investigator는 외부 조사(시장·기술·정책·선행연구) + 기존자료 분석을 수행해 03_evidence.md에 출처와 함께 정리한다. 미확보 항목은 명시한다.
3. 분할 병렬 스폰(쾌속 기본, 표준도 조사 범위가 넓으면 권장) — 시장·산업 / 기술·선행연구·특허 / 정책·법제 등 2~4분할로 동시 스폰하고 03_evidence_market.md·03_evidence_tech.md 식으로 나눠 저장한다. 이후 writer·reviewer 프롬프트에 모든 03_evidence*.md 경로를 명시한다.
4. 조사를 백그라운드로 위임한 동안 리더(또는 작성가)는 초안 골격을 〔조사 반영〕 슬롯과 함께 선작성해 두고, 조사 반환 시 통합한다. 조사 완료 알림은 사용자 승인 신호로 간주하지 않는다.
5. 03_evidence*.md가 저장된 것을 확인하고 Phase 5로 간다.

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

실행 방식: writer ↔ reviewer(모드2) 피드백 루프(리더 중계)

1. proposal-writer가 01(승인 목차·평가대응표)·03(근거)·사용자 메모를 종합해 04_proposal.md를 작성한다.
   • 섹션 배치 분할(쾌속 기본, 지연 래더 1단계에서도 적용): 목차를 2~3배치로 나눠 순차 스폰하고 배치마다 04에 이어붙인다. 배점 높은 섹션을 먼저 배치해 중단·지연 시 득점 핵심이 먼저 확보되게 한다. 배치 간 문체·용어 일관성을 위해 직전 배치 말미를 읽고 잇도록 프롬프트에 명시한다.
2. reviewer(모드2)가 04를 01·02·03과 교차검증하고 05_review.md에 수정 요청을 작성한다(요구사항 교차검증·평가지표 대응·논리/정량성·출처 원문 대조·교열). 지적은 [필수·자격]/[필수·득점]/[권고]/[선택]으로 등급을 단다.
3. 판정이 "수정 요청"이면 writer가 [필수·자격] → [필수·득점] → [권고] 순으로 반영해 04를 개정한다. 최대 2회 반복. 2회 뒤에도 남은 득점형·권고는 "잔여 리스크"로 기록하고 진행한다. 검수관이 첫 회차에 "작성가가 고칠 수 없는 자격형"을 따로 올리면, 리더는 수정 루프를 돌리는 동안 그 항목을 사용자에게 먼저 묻는다(답이 보강 자료면 다음 개정에 반영).
   • 리더는 writer에게 05_review.md 경로를 주어 개정하게 하고, 개정 뒤 04의 수정 시각이 바뀌었는지 확인한다("실행 방식"의 파일 쓰기 확인). 쓰기가 거부되는 환경이면 전경 호출로 바꾸거나, 검수관이 수정안까지 적어 준 비창작성 수정(출처 표기 교체·오탈자·수치 정정)은 리더가 직접 반영한다. 사용자 입력이 필요한 항목(예: 연구진 실적)은 [보강 필요]로 남긴다.
4. 판정에 따른 분기
   • 승인 / 조건부 승인(자격형 0건) → Phase 6으로 간다.
   • 보류(자격형이 루프 한도 뒤에도 미해소) → ★ 자격형 사용자 게이트. 리더는 변환으로 넘어가지 않고 사용자에게 항목·사유·선택지를 제시한다: ①보강 자료를 제공한다 ②해당 내용을 삭제하거나 방향성 서술로 낮춘다 ③위험을 알고 그대로 진행한다. 답을 05_review.md의 "사용자 판단 기록"에 남긴 뒤에 Phase 6으로 간다. ①·②면 writer가 반영하고 reviewer가 그 항목만 재확인한다.
   • 무인 실행(Phase 3의 예외와 같은 조건)에서 보류가 나면 변환까지 진행하되 산출물 파일명에 _미승인을 붙이고, 최종 보고 첫 줄에 미해소 자격형을 적는다. 검수관이나 리더가 사용자를 대신해 위험을 수용하지 않는다.

Phase 6: 변환

실행 방식: 승인 후 변환

1. hwpx-exporter가 승인된 04_proposal.md를 입력으로 받는다. 변환은 리더가 직접 하지 않고 서브에이전트에 맡긴다(파일을 읽어 변환·검증 후 결과만 회신 — 리더 컨텍스트 보호).
2. 00_input/에 발주처 지정 양식이 있으면 폼 채우기 방식, 없으면 표준 생성 방식으로 .hwpx를 만든다.
3. 변환가는 전처리본(04b_for_hwpx.md)을 _workspace/에 남기고 검증기를 돌려 종료 코드와 출력을 보고한다. 리더가 같은 명령을 직접 한 번 더 실행한다: python3 <rnd-hwpx-export 스킬 디렉토리>/scripts/verify_hwpx.py _workspace/04b_for_hwpx.md _workspace/06_proposal.hwpx (지정 양식 경로는 --no-tables). 종료 코드 0이어야 통과다. 1이면 재변환·업시프트("실행 프로파일" ④), 2면 경로를 바로잡아 재실행한다. 검증기가 세어 준 남은 [보강 필요] 표시와 분량·양식 제약을 함께 점검한다.
4. 최종 산출물을 사용자 지정 경로에, 사본을 _workspace/06_proposal.hwpx에 저장한다.
5. 부속 조사자료 docx는 하이퍼링크를 보존해 생성하고 링크 개수를 검증한다(예: "하이퍼링크 80개 클릭 가능"). URL의 ?utm_source= 류 꼬리는 제거한다.
6. 재생성 시 동일 변환가 재호출: hwpx 재생성 요청은 새 에이전트가 아니라 이전 변환 방법을 아는 기존 변환가를 SendMessage로 이어 불러 처리한다(방법 재학습 비용 제거). 이어 부를 수 없으면 직전 변환 보고(쓴 옵션·전처리 내역)를 프롬프트에 붙여 새로 스폰한다.

Phase 7: 정리·보고

1. 아직 돌고 있는 서브에이전트가 없는지 확인한다.
2. _workspace/는 보존한다 (사후 검증·재실행용).
3. 사용자에게 요약 보고: 최종 hwpx 경로, 평가대응 요약, 초안검수 판정과 출처 대조 결과(✅/⚠️/❌/〔미개봉〕 건수, 열어본 범위), 자격형에 대한 사용자 판단 기록, 설계·초안 잔여 리스크·[보강 필요] 항목, 입력 자료 한계.
4. 피드백을 요청한다 ("수정하거나 보완할 부분이 있나요?").

데이터 흐름

[리더] 단계 순서대로 스폰 — 아래 화살표의 전달은 모두 리더가 중계
  rfp-analyst ──01_rfp_analysis.md (목차·평가대응표)──┐
       ▲  │ 설계 검토 요청                            │
  (개정,최대2회) ▼                                    ▼
  proposal-reviewer(모드1) ──02_design_gate.md (게이트)
       │ "설계 승인" → ★ 목차 사용자 승인
       ▼  (승인 후에만 진행)
  research-investigator ──03_evidence.md──┐
                                          ▼
                          proposal-writer ──04_proposal.md──┐
                                ▲  │                               │
                         수정요청 │ (최대 2회 루프)            ▼
                          proposal-reviewer(모드2) ──05_review.md
                 "초안 승인" │ (보류면 ★ 자격형 사용자 게이트)   │
                                ▼                                  │
                          hwpx-exporter ◀───────────04 승인본───────┘
                                │
                                ▼
                          06_proposal.hwpx → 사용자 지정 경로

에러 핸들링

테스트 시나리오

정상 흐름

1. 사용자가 공고문(.hwpx) + 과제 아이디어 메모 + 참고 논문 2편 제공
2. Phase 1: _workspace/ 생성, 입력 저장
3. Phase 2: 실행 계획(T1~T6, 설계 게이트·사용자 승인 조건 포함) 수립
4. Phase 3: rfp-analyst가 평가배점 추출·목차·평가대응표 설계 → reviewer 모드1이 "고배점 '추진체계' 항목 분량 부족" 지적 → analyst 개정 → 승인 → 사용자 목차 승인
5. Phase 4: research-investigator가 시장근거·선행연구 조사
6. Phase 5: writer 초안 → reviewer 모드2 수정요청 2건 → writer 반영 → 승인
7. Phase 6: 지정 양식에 채워 hwpx 생성(exporter는 sonnet으로 스폰) → 리더가 verify_hwpx.py --no-tables 실행, 종료 코드 0
8. Phase 7: 사용자 지정 경로에 <과제명>_제안서.hwpx + 평가대응 요약 보고
9. 예상 결과: 지정 경로에 hwpx 생성, _workspace/에 01~06 산출물 보존

에러 흐름

1. Phase 3에서 reviewer 모드1이 "필수 요구(국제협력 계획)가 어느 섹션에도 매핑 안 됨"을 반려 → analyst가 목차에 섹션 추가 → 승인
2. Phase 4에서 research-investigator가 웹 접근 실패로 시장 근거 일부 미확보 → 03_evidence.md에 미확보 항목 기록
3. writer가 해당 부분을 [보강 필요]로 표시하고 진행
4. Phase 5 검수에서 확인 — 미확보 근거가 득점형이면 잔여 리스크로 기록하고 진행. 필수 요구의 근거가 [보강 필요]로 남았으면 자격형이므로 판정 "보류" → 사용자가 ①보강 ②삭제·하향 ③위험 수용 중 선택, 답을 05에 기록
5. 검수의 출처 대조에서 핵심 수치 1건이 원문과 다름(❌) → writer가 원문대로 정정 → reviewer가 그 항목만 재확인
6. 최종 보고에 "시장 근거 일부 미확보 — 추가 조사 권장", 출처 대조 건수, 사용자 판단 기록 명시

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

• 에이전트 이름 네임스페이스 — 플러그인으로 설치하면 에이전트 타입이 <플러그인명>:<에이전트명>(예: rnd-proposal-kit:rfp-analyst)으로 표시될 수 있다. 이 문서의 에이전트명은 접미 이름 기준이며, 실제 스폰 시에는 현재 세션의 에이전트 목록에 표시되는 이름을 그대로 쓴다.
• 팀 API를 쓸 때 (선택) — 에이전트 팀 API(TeamCreate/TaskCreate/팀 SendMessage, 실험 기능)가 켜진 환경이면 5명을 한 팀으로 만들고 Phase 2의 표를 작업 의존성으로 등록해 돌릴 수 있다. 이때는 에이전트들이 서로 직접 메시지를 주고받는다(각 에이전트 정의의 "팀 통신 프로토콜"). Phase 순서와 산출물 파일 계약, 게이트 규칙은 같다. 다만 이 경로는 끝까지 완주한 검증 기록이 없고 API의 호출 형식도 버전에 따라 바뀐다. 사용자 게이트 두 곳(목차 승인, 자격형 판단)은 팀 모드에서도 리더가 직접 사용자에게 묻는다 — 에이전트끼리의 합의로 대신하지 않는다.
• 모델 — 단계별 티어 기본값: rfp-analyst·writer·reviewer inherit, research-investigator sonnet, hwpx-exporter haiku. 품질을 우선하려면 스폰 시 상위 모델을 명시한다(업시프트). 속도·지연 대응은 "실행 프로파일 — 표준 vs 쾌속" 절의 쾌속 프로파일과 지연 폴백 래더를 따른다.
• 한글(.hwpx) 변환 의존성 — hwpx 산출은 kordoc MCP(제3자, npx kordoc@latest mcp)에 의존한다. 미설치 환경에서는 마크다운/docx 산출까지 진행하고 변환 단계만 보류하면 된다.