@tienne/gestalt 0.84.0 → 0.84.2

package/CLAUDE.md

@@ -82,6 +82,7 @@ src/knowledge-base/— KB 생성·시맨틱 검색·동기화 (ges_generate_kb/g
 src/memory/        — Memory 피드백 루프 (ProjectMemoryStore, UserProfileStore)
 src/llm/           — 멀티 프로바이더 LLM 어댑터 (frugal/standard/frontier 티어 라우팅)
 src/review/        — Code Review 파이프라인 (agent-matcher, context-collector, report-generator)
+src/harness-review/— 하네스 PR 참조 후보 수집, 연관 PR 탐색, 세 상태 판정, approve 게이트 (gestalt harness-refs, gestalt review-loop approve-gate 백엔드)
 src/agent/         — AgentRegistry, RoleAgentRegistry (tier→모델 해석은 MCP 핸들러가 담당)
 src/mcp/           — MCP 서버 + 툴 핸들러
 src/events/        — EventStore (SQLite)

package/dist/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@tienne/gestalt",
-  "version": "0.84.0",
+  "version": "0.84.2",
   "description": "TypeScript AI Development Harness - Gestalt psychology-driven requirement clarification",
   "repository": {
     "type": "git",

package/dist/plugin/skills/review/SKILL.md

@@ -1303,6 +1303,22 @@ ges_execute {
 
 **그 67KB를 통째로 딸려 보내지도 않습니다.** 윤문에 넘기기 전에 먼저 스캔을 돌려 이번 리포트에서 실제로 걸린 룰만 처방과 함께 프롬프트에 싣습니다. 걸린 게 서너 개인데 예순 개가 넘는 룰북을 라운드마다 펼치면 모델이 나눠 쓰는 주의가 안 걸린 룰까지 흩어집니다. `ship`이 이 파이프라인을 라운드로 돌리는 자리라 그 낭비가 라운드마다 되풀이됩니다.
 
+#### 4.7단계 코멘트 작성과 함께 띄우기
+
+**`prTarget`이 `github`이나 `local`이면 이 윤문과 4.7단계 코멘트 본문 작성을 한 메시지에 담아 병렬로 돌립니다.** 두 호출은 서로의 산출물을 받지 않습니다. `humanize-monolith`는 `review_consensus`가 돌려준 리포트와 사전 스캔 출력만 받습니다. `code-review-writer`는 `mergedIssues`와 `audience`만 받습니다. 윤문한 리포트는 코멘트의 입력이 아니고 코멘트도 리포트의 입력이 아니라서 차례로 기다릴 이유가 없습니다. consensus 뒤 구간이 이 스킬에서 제일 오래 걸리는 자리이고(2026-09-24 이후 게시까지 간 리뷰의 중앙값이 10분이었습니다) 그 안에서 에이전트 하나를 통째로 기다리던 시간이 여기서 빠집니다. 이 프롬프트에 코멘트 본문을 싣거나 코멘트 프롬프트에 윤문한 리포트를 싣는 변경은 이 전제와 부딪힙니다.
+
+띄우기 전에 메인이 끝내 두는 일이 있습니다. 전부 셸 호출 한두 번이라 에이전트를 기다리는 시간에 비하면 짧습니다.
+
+1. 아래 `사전 스캔`을 돌립니다. 그 출력이 윤문 프롬프트에 들어갑니다.
+2. 4.7단계 `consensus 일치 검사`를 합니다. stale이면 둘 다 띄우지 않고 그 절이 정한 대로 1단계부터 다시 돌립니다. 낡은 consensus로 리포트와 코멘트를 둘 다 만들고 나서 버리게 됩니다.
+3. 4.7단계 `게시 준비`의 PR 확인과 `audience` 확인을 합니다.
+
+**게시 확인은 두 결과가 다 돌아온 뒤에 받습니다.** 4.7단계 `게시 확인` 절의 자리입니다. 사용자가 게시를 거절하면 `code-review-writer` 결과는 버립니다. 거절하는 일은 드뭅니다. 그 낭비보다 사용자가 확인 뒤에 에이전트를 한 번 더 기다리지 않게 하는 쪽이 낫습니다.
+
+**두 어투 검사도 한 메시지에서 함께 돌립니다.** 아래 `리포트 어투 검사`와 4.7단계 `어투 검사`는 register가 다르고 파일도 따로 씁니다. 합쳐서 한 번에 부르지 않습니다(각 절에 근거가 있습니다). 한쪽만 걸리면 그쪽 에이전트만 다시 부릅니다.
+
+`prTarget`이 `none`이면 윤문만 띄웁니다. 대화 도중 게시만 따로 요청받은 경로는 이 단계를 안 거치므로 4.7단계를 적힌 순서대로 따릅니다.
+
 #### 사전 스캔 (필수)
 
 `review_consensus`가 돌려준 리포트를 윤문에 넘기기 전에 먼저 스캔합니다. 이 스캔의 출력이 아래 윤문 프롬프트의 입력이 됩니다.
@@ -1329,6 +1345,8 @@ gestalt humanize-scan --file "$scanTmp/consensus.md" --register report
 
 #### 윤문 위임
 
+`prTarget`이 `github`이나 `local`이면 이 호출을 4.7단계 `코멘트 본문 작성`의 호출과 같은 메시지에 담습니다.
+
 ```
 Agent {
   subagent_type: "Explore",
@@ -1391,7 +1409,7 @@ gestalt humanize-scan --file "$scanTmp/report.md" --register report
 
 `--register report`입니다. 리포트는 서술체 문서라 룰북이 `report`에서 함께 보는 평서체와 합니다체의 혼용 검사까지 봐야 합니다. 코드펜스 안쪽은 register와 무관하게 항상 스캔에서 빠집니다. **`>` 블록인용 제외는 `chat`에서만 켜지므로 여기서는 함께 스캔됩니다** — 리포트가 이슈 원문이나 PR 본문을 인용하는 자리에서 그 원문이 걸릴 수 있습니다. 걸리면 인용 표시는 유지한 채로 `humanize-monolith`가 그 문장만 다시 씁니다.
 
-윤문된 리포트를 사용자에게 표시합니다. 그다음 `prTarget`이 `github`이나 `local`이면 4.7단계로 넘어갑니다. `none`이면 결과 표시로 넘어갑니다.
+윤문된 리포트를 사용자에게 표시합니다. 그다음 `prTarget`이 `github`이나 `local`이면 4.7단계 `게시 확인`으로 넘어갑니다. 함께 띄운 코멘트 작성과 그 어투 검사도 여기까지 끝내 둡니다. `none`이면 결과 표시로 넘어갑니다.
 - `approved: true` → 리뷰 통과. 리포트를 보여줍니다.
 - `approved: false` → critical/high 이슈가 남아 Block 상태입니다.
 
@@ -1407,7 +1425,7 @@ gestalt humanize-scan --file "$scanTmp/report.md" --register report
 
 #### consensus 일치 검사 (stale이면 게시 금지)
 
-게시 직전에, 게시하려는 consensus가 **현재 diff와 일치하는지** 반드시 확인합니다. 리뷰를 끝낸 뒤 코드가 바뀌었거나(커밋 추가·로컬 수정), 애초에 활성 리뷰 세션이 없으면 그 consensus는 stale이므로 **그대로 올리지 않습니다.**
+코멘트를 쓰기 전에, 게시하려는 consensus가 **현재 diff와 일치하는지** 반드시 확인합니다. 4.5단계에서 윤문과 함께 띄우는 흐름이면 두 에이전트를 띄우기 전에 합니다. 리뷰를 끝낸 뒤 코드가 바뀌었거나(커밋을 더했거나 로컬에서 고쳤거나), 애초에 활성 리뷰 세션이 없으면 그 consensus는 stale이므로 **그대로 올리지 않습니다.**
 
 ```bash
 # 리뷰 시점 대비 작업트리가 바뀌었는지 확인 — 대상과 무관하게 공통
@@ -1427,7 +1445,7 @@ gestalt pr --json show <id>   # headSha 필드로 비교
 
 인라인 코멘트는 **언제 요청받든 항상 "현재 diff 기준 consensus + code-review-writer voice"** 로만 게시됩니다. 옛 리뷰 메모리를 그대로 옮겨 적거나 Claude가 손으로 코멘트를 짜는 경로는 없습니다.
 
-#### 게시 준비 (PR 식별, audience 확인, 게시 확인)
+#### 게시 준비 (PR 식별, audience 확인)
 
 **PR 식별.** 대상 판별은 1단계 직후에 이미 끝났습니다. 여기서는 그때 보관한 `prTarget`과 PR 식별자를 그대로 씁니다. **같은 조회를 다시 하지 않습니다.**
 
@@ -1445,10 +1463,10 @@ gestalt pr --json show <id> 2>/dev/null
 
 **`audience` 확인이 남았는지 봅니다.** 1.05단계를 안 거치고 이 단계로 바로 들어온 경로(대화 도중 "이제 PR에 코멘트 남겨줘")가 있습니다. `audience`가 `junior`인데 `prTarget`이 `local`이고 그 확인을 받은 기록이 없으면 여기서 먼저 묻습니다 — 1.05단계와 같은 문구입니다.
 
-**게시 확인.** PR이 식별되면 사용자에게 한 번 확인합니다: **"발견된 이슈 N개를 PR #<number 또는 로컬 PR id>에 인라인 코멘트로 게시할까요?"** N은 `mergedIssues` 수입니다. 3.7단계에서 뺀 이슈는 세지 않습니다. 동의하지 않으면 리포트만 보여주고 종료합니다.
-
 #### 코멘트 본문 작성 (code-review-writer)
 
+4.5단계를 거쳐 온 흐름이면 이 호출은 4.5단계 `윤문 위임`의 호출과 같은 메시지에 담깁니다. 게시만 따로 요청받은 경로에서는 혼자 띄웁니다.
+
 **서브에이전트에 위임합니다.** 이 에이전트는 본문 18.8KB에 `author-voice.md` 23KB를 딸고 오는, 이 스킬에서 제일 무거운 자리입니다.
 
 **`author-voice.md`는 읽고 `ai-tell-quick-rules.md`는 첫 판에 안 엽니다.** 앞의 것은 코멘트를 쓰는 기준이라 없으면 쓰기 자체가 안 됩니다. 뒤의 것은 다 쓴 뒤에 무엇이 걸렸는지 보는 기준입니다. 그 답은 아래 `어투 검사`가 걸린 룰의 처방까지 붙여 돌려줍니다. 44KB를 미리 펼쳐 놓고 그중 서너 줄을 쓰는 대신, 걸린 자리의 처방만 재작성 판에 실어 보냅니다.
@@ -1568,6 +1586,12 @@ find "$scanTmp" -maxdepth 1 -name '*.md' | sort | sed 's/^/--file /' \
 
 **큰따옴표로 감싼 평문은 형태로 못 가릅니다.** 한국어에서 큰따옴표는 인용만이 아니라 강조로도 쓰여서요. 룰북 Do-NOT 목록이 "큰따옴표 안 직접 인용"을 예외로 두지만 그건 사람과 모델이 판단하는 자리의 기준입니다. 자동 스캔은 위 셋만 뺍니다. 원문을 가리켜야 하면 백틱이나 블록인용을 씁니다.
 
+#### 게시 확인
+
+코멘트 본문과 어투 검사가 끝나면 게시하기 전에 사용자에게 한 번 확인합니다: **"발견된 이슈 N개를 PR #<number 또는 로컬 PR id>에 인라인 코멘트로 게시할까요?"** N은 `mergedIssues` 수입니다. 3.7단계에서 뺀 이슈는 세지 않습니다. 동의하지 않으면 써 둔 코멘트는 버리고 리포트만 보여준 채 종료합니다.
+
+코멘트를 다 쓴 뒤에 묻는 건 사용자가 확인한 다음 에이전트를 한 번 더 기다리지 않게 하려는 것입니다. 4.5단계와 함께 띄우는 흐름에서는 확인을 먼저 받으면 병렬로 돌릴 수가 없습니다. 게시만 따로 요청받은 경로도 같은 자리에서 묻습니다.
+
 #### 리뷰 이벤트 결정 (postVerdict와 본인 PR 예외)
 
 `mergedIssues`의 `severity`로 리뷰 전체의 `event`를 정합니다. 본문 첫 글자를 파싱하지 않습니다 — 접두어는 사람이 읽는 라벨이지 판정 입력이 아닙니다.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@tienne/gestalt",
-  "version": "0.84.0",
+  "version": "0.84.2",
   "description": "TypeScript AI Development Harness - Gestalt psychology-driven requirement clarification",
   "repository": {
     "type": "git",

package/plugin/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "gestalt",
-  "version": "0.84.0",
+  "version": "0.84.2",
   "description": "Gestalt psychology-driven AI development harness. Transforms scattered requirements into structured, validated specifications through interactive interviews.",
   "author": {
     "name": "tienne"

package/plugin/.mcp.json

@@ -2,7 +2,7 @@
   "mcpServers": {
     "gestalt": {
       "command": "npx",
-      "args": ["-y", "@tienne/gestalt@0.84.0", "serve"],
+      "args": ["-y", "@tienne/gestalt@0.84.2", "serve"],
       "startup_timeout_sec": 180,
       "tool_timeout_sec": 900
     }

package/plugin/mcp.json

@@ -2,7 +2,7 @@
   "mcpServers": {
     "gestalt": {
       "command": "npx",
-      "args": ["-y", "@tienne/gestalt@0.84.0", "serve"],
+      "args": ["-y", "@tienne/gestalt@0.84.2", "serve"],
       "startup_timeout_sec": 180,
       "tool_timeout_sec": 900
     }

package/plugin/skills/review/SKILL.md

@@ -1303,6 +1303,22 @@ ges_execute {
 
 **그 67KB를 통째로 딸려 보내지도 않습니다.** 윤문에 넘기기 전에 먼저 스캔을 돌려 이번 리포트에서 실제로 걸린 룰만 처방과 함께 프롬프트에 싣습니다. 걸린 게 서너 개인데 예순 개가 넘는 룰북을 라운드마다 펼치면 모델이 나눠 쓰는 주의가 안 걸린 룰까지 흩어집니다. `ship`이 이 파이프라인을 라운드로 돌리는 자리라 그 낭비가 라운드마다 되풀이됩니다.
 
+#### 4.7단계 코멘트 작성과 함께 띄우기
+
+**`prTarget`이 `github`이나 `local`이면 이 윤문과 4.7단계 코멘트 본문 작성을 한 메시지에 담아 병렬로 돌립니다.** 두 호출은 서로의 산출물을 받지 않습니다. `humanize-monolith`는 `review_consensus`가 돌려준 리포트와 사전 스캔 출력만 받습니다. `code-review-writer`는 `mergedIssues`와 `audience`만 받습니다. 윤문한 리포트는 코멘트의 입력이 아니고 코멘트도 리포트의 입력이 아니라서 차례로 기다릴 이유가 없습니다. consensus 뒤 구간이 이 스킬에서 제일 오래 걸리는 자리이고(2026-09-24 이후 게시까지 간 리뷰의 중앙값이 10분이었습니다) 그 안에서 에이전트 하나를 통째로 기다리던 시간이 여기서 빠집니다. 이 프롬프트에 코멘트 본문을 싣거나 코멘트 프롬프트에 윤문한 리포트를 싣는 변경은 이 전제와 부딪힙니다.
+
+띄우기 전에 메인이 끝내 두는 일이 있습니다. 전부 셸 호출 한두 번이라 에이전트를 기다리는 시간에 비하면 짧습니다.
+
+1. 아래 `사전 스캔`을 돌립니다. 그 출력이 윤문 프롬프트에 들어갑니다.
+2. 4.7단계 `consensus 일치 검사`를 합니다. stale이면 둘 다 띄우지 않고 그 절이 정한 대로 1단계부터 다시 돌립니다. 낡은 consensus로 리포트와 코멘트를 둘 다 만들고 나서 버리게 됩니다.
+3. 4.7단계 `게시 준비`의 PR 확인과 `audience` 확인을 합니다.
+
+**게시 확인은 두 결과가 다 돌아온 뒤에 받습니다.** 4.7단계 `게시 확인` 절의 자리입니다. 사용자가 게시를 거절하면 `code-review-writer` 결과는 버립니다. 거절하는 일은 드뭅니다. 그 낭비보다 사용자가 확인 뒤에 에이전트를 한 번 더 기다리지 않게 하는 쪽이 낫습니다.
+
+**두 어투 검사도 한 메시지에서 함께 돌립니다.** 아래 `리포트 어투 검사`와 4.7단계 `어투 검사`는 register가 다르고 파일도 따로 씁니다. 합쳐서 한 번에 부르지 않습니다(각 절에 근거가 있습니다). 한쪽만 걸리면 그쪽 에이전트만 다시 부릅니다.
+
+`prTarget`이 `none`이면 윤문만 띄웁니다. 대화 도중 게시만 따로 요청받은 경로는 이 단계를 안 거치므로 4.7단계를 적힌 순서대로 따릅니다.
+
 #### 사전 스캔 (필수)
 
 `review_consensus`가 돌려준 리포트를 윤문에 넘기기 전에 먼저 스캔합니다. 이 스캔의 출력이 아래 윤문 프롬프트의 입력이 됩니다.
@@ -1329,6 +1345,8 @@ gestalt humanize-scan --file "$scanTmp/consensus.md" --register report
 
 #### 윤문 위임
 
+`prTarget`이 `github`이나 `local`이면 이 호출을 4.7단계 `코멘트 본문 작성`의 호출과 같은 메시지에 담습니다.
+
 ```
 Agent {
   subagent_type: "Explore",
@@ -1391,7 +1409,7 @@ gestalt humanize-scan --file "$scanTmp/report.md" --register report
 
 `--register report`입니다. 리포트는 서술체 문서라 룰북이 `report`에서 함께 보는 평서체와 합니다체의 혼용 검사까지 봐야 합니다. 코드펜스 안쪽은 register와 무관하게 항상 스캔에서 빠집니다. **`>` 블록인용 제외는 `chat`에서만 켜지므로 여기서는 함께 스캔됩니다** — 리포트가 이슈 원문이나 PR 본문을 인용하는 자리에서 그 원문이 걸릴 수 있습니다. 걸리면 인용 표시는 유지한 채로 `humanize-monolith`가 그 문장만 다시 씁니다.
 
-윤문된 리포트를 사용자에게 표시합니다. 그다음 `prTarget`이 `github`이나 `local`이면 4.7단계로 넘어갑니다. `none`이면 결과 표시로 넘어갑니다.
+윤문된 리포트를 사용자에게 표시합니다. 그다음 `prTarget`이 `github`이나 `local`이면 4.7단계 `게시 확인`으로 넘어갑니다. 함께 띄운 코멘트 작성과 그 어투 검사도 여기까지 끝내 둡니다. `none`이면 결과 표시로 넘어갑니다.
 - `approved: true` → 리뷰 통과. 리포트를 보여줍니다.
 - `approved: false` → critical/high 이슈가 남아 Block 상태입니다.
 
@@ -1407,7 +1425,7 @@ gestalt humanize-scan --file "$scanTmp/report.md" --register report
 
 #### consensus 일치 검사 (stale이면 게시 금지)
 
-게시 직전에, 게시하려는 consensus가 **현재 diff와 일치하는지** 반드시 확인합니다. 리뷰를 끝낸 뒤 코드가 바뀌었거나(커밋 추가·로컬 수정), 애초에 활성 리뷰 세션이 없으면 그 consensus는 stale이므로 **그대로 올리지 않습니다.**
+코멘트를 쓰기 전에, 게시하려는 consensus가 **현재 diff와 일치하는지** 반드시 확인합니다. 4.5단계에서 윤문과 함께 띄우는 흐름이면 두 에이전트를 띄우기 전에 합니다. 리뷰를 끝낸 뒤 코드가 바뀌었거나(커밋을 더했거나 로컬에서 고쳤거나), 애초에 활성 리뷰 세션이 없으면 그 consensus는 stale이므로 **그대로 올리지 않습니다.**
 
 ```bash
 # 리뷰 시점 대비 작업트리가 바뀌었는지 확인 — 대상과 무관하게 공통
@@ -1427,7 +1445,7 @@ gestalt pr --json show <id>   # headSha 필드로 비교
 
 인라인 코멘트는 **언제 요청받든 항상 "현재 diff 기준 consensus + code-review-writer voice"** 로만 게시됩니다. 옛 리뷰 메모리를 그대로 옮겨 적거나 Claude가 손으로 코멘트를 짜는 경로는 없습니다.
 
-#### 게시 준비 (PR 식별, audience 확인, 게시 확인)
+#### 게시 준비 (PR 식별, audience 확인)
 
 **PR 식별.** 대상 판별은 1단계 직후에 이미 끝났습니다. 여기서는 그때 보관한 `prTarget`과 PR 식별자를 그대로 씁니다. **같은 조회를 다시 하지 않습니다.**
 
@@ -1445,10 +1463,10 @@ gestalt pr --json show <id> 2>/dev/null
 
 **`audience` 확인이 남았는지 봅니다.** 1.05단계를 안 거치고 이 단계로 바로 들어온 경로(대화 도중 "이제 PR에 코멘트 남겨줘")가 있습니다. `audience`가 `junior`인데 `prTarget`이 `local`이고 그 확인을 받은 기록이 없으면 여기서 먼저 묻습니다 — 1.05단계와 같은 문구입니다.
 
-**게시 확인.** PR이 식별되면 사용자에게 한 번 확인합니다: **"발견된 이슈 N개를 PR #<number 또는 로컬 PR id>에 인라인 코멘트로 게시할까요?"** N은 `mergedIssues` 수입니다. 3.7단계에서 뺀 이슈는 세지 않습니다. 동의하지 않으면 리포트만 보여주고 종료합니다.
-
 #### 코멘트 본문 작성 (code-review-writer)
 
+4.5단계를 거쳐 온 흐름이면 이 호출은 4.5단계 `윤문 위임`의 호출과 같은 메시지에 담깁니다. 게시만 따로 요청받은 경로에서는 혼자 띄웁니다.
+
 **서브에이전트에 위임합니다.** 이 에이전트는 본문 18.8KB에 `author-voice.md` 23KB를 딸고 오는, 이 스킬에서 제일 무거운 자리입니다.
 
 **`author-voice.md`는 읽고 `ai-tell-quick-rules.md`는 첫 판에 안 엽니다.** 앞의 것은 코멘트를 쓰는 기준이라 없으면 쓰기 자체가 안 됩니다. 뒤의 것은 다 쓴 뒤에 무엇이 걸렸는지 보는 기준입니다. 그 답은 아래 `어투 검사`가 걸린 룰의 처방까지 붙여 돌려줍니다. 44KB를 미리 펼쳐 놓고 그중 서너 줄을 쓰는 대신, 걸린 자리의 처방만 재작성 판에 실어 보냅니다.
@@ -1568,6 +1586,12 @@ find "$scanTmp" -maxdepth 1 -name '*.md' | sort | sed 's/^/--file /' \
 
 **큰따옴표로 감싼 평문은 형태로 못 가릅니다.** 한국어에서 큰따옴표는 인용만이 아니라 강조로도 쓰여서요. 룰북 Do-NOT 목록이 "큰따옴표 안 직접 인용"을 예외로 두지만 그건 사람과 모델이 판단하는 자리의 기준입니다. 자동 스캔은 위 셋만 뺍니다. 원문을 가리켜야 하면 백틱이나 블록인용을 씁니다.
 
+#### 게시 확인
+
+코멘트 본문과 어투 검사가 끝나면 게시하기 전에 사용자에게 한 번 확인합니다: **"발견된 이슈 N개를 PR #<number 또는 로컬 PR id>에 인라인 코멘트로 게시할까요?"** N은 `mergedIssues` 수입니다. 3.7단계에서 뺀 이슈는 세지 않습니다. 동의하지 않으면 써 둔 코멘트는 버리고 리포트만 보여준 채 종료합니다.
+
+코멘트를 다 쓴 뒤에 묻는 건 사용자가 확인한 다음 에이전트를 한 번 더 기다리지 않게 하려는 것입니다. 4.5단계와 함께 띄우는 흐름에서는 확인을 먼저 받으면 병렬로 돌릴 수가 없습니다. 게시만 따로 요청받은 경로도 같은 자리에서 묻습니다.
+
 #### 리뷰 이벤트 결정 (postVerdict와 본인 PR 예외)
 
 `mergedIssues`의 `severity`로 리뷰 전체의 `event`를 정합니다. 본문 첫 글자를 파싱하지 않습니다 — 접두어는 사람이 읽는 라벨이지 판정 입력이 아닙니다.