@tienne/gestalt 0.33.3 → 0.34.0

package/CLAUDE.md

@@ -89,3 +89,4 @@ skills/          — build-graph, blast-radius, diff-radius
 - LLM 호출: temperature 0.3, JSON 응답 파싱 + fallback
 - 해상도 점수 ≥ 0.8 = 요구사항 충분히 명확
 - 테스트 DB: `.gestalt-test/xxx-${randomUUID()}.db` 고유 경로 (병렬 안전)
+- 한글 산문에서 가운뎃점(·) 나열 절제 → 쉼표나 "A랑 B하고 C"로 (표·용어 목록은 예외). 룰은 `ai-tell-quick-rules.md` C-12, `style-guide.md`에 정의

package/dist/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@tienne/gestalt",
-  "version": "0.33.3",
+  "version": "0.34.0",
   "description": "TypeScript AI Development Harness - Gestalt psychology-driven requirement clarification",
   "type": "module",
   "main": "./dist/src/index.js",

package/dist/role-agents/presentation-designer/AGENT.md

@@ -205,6 +205,8 @@ Reveal.initialize({
 
 프레젠테이션은 **워딩이 먼저, 디자인이 나중**이다. 순서를 지키지 않으면 디자인에 워딩을 끼워 맞추게 된다.
 
+슬라이드 한글 텍스트에서 가운뎃점(·)으로 항목을 압축하지 않는다. "A·B·C" 대신 쉼표나 줄바꿈으로 푼다 — 사람은 산문에서 가운뎃점을 거의 안 쓴다 (불릿 라벨 같은 짧은 목록은 예외). 워딩 초안 단계의 technical-writer도 style-guide의 같은 규칙을 따른다.
+
 ### Phase 1: technical-writer (워딩 초안)
 
 프레젠테이션 작성 요청이 들어오면, 디자인 작업 전에 반드시 `technical-writer` 관점을 먼저 확보해야 한다.

package/dist/role-agents/product-planner/AGENT.md

@@ -28,3 +28,5 @@ Provide a structured perspective with:
 - Priority recommendations
 - Acceptance criteria suggestions
 - Scope boundary clarifications
+
+한글로 작성할 때 가운뎃점(·)으로 항목을 압축 나열하지 않는다. "A·B·C" 대신 쉼표나 "A랑 B하고 C"로 푼다 — 사람은 산문에서 가운뎃점을 거의 안 쓴다 (표·용어 목록은 예외).

package/dist/role-agents/technical-writer/references/ai-tell-quick-rules.md

@@ -50,6 +50,7 @@
 | C-9 | 숫자 괄호 인덱싱 "(1)·(2)·(3)" | S2 | 본문에 녹이거나 단순 줄바꿈 |
 | C-10 | 콜론 부제 헤딩 "X: Y" 반복 | S1 | 헤딩 짧게 또는 평서 헤딩으로 |
 | C-11 | 연결어미 뒤 쉼표 (-고/-며/-지만/-며서/-아서/-어서 직후 쉼표) | S1 | 쉼표 제거. 6+회=강한 신호. KatFish 4.84배 분리도 |
+| C-12 | 가운뎃점(·) 나열 남발 — 본문 산문에서 "A·B·C"로 항목 압축 | S2 | 쉼표나 구어 연결로 풀기("A, B, C" / "A랑 B하고 C"). 사람은 산문에서 가운뎃점을 거의 안 쓴다. 단 표 안 압축, 용어 목록, 굳어진 합성어("입출력")는 예외 |
 
 ## D. AI 특유의 관용구 (Signature Phrases)
 

package/dist/role-agents/technical-writer/references/author-voice.md

@@ -143,6 +143,7 @@ ghost 는 button의 ghost variant 를 위한 토큰입니다.
 반대로 두 레지스터 모두에서 **제거**할 진짜 AI-tell:
 - "결론적으로", "요약하자면", "이를 통해", "~를 수행합니다" 의인화 주어
 - 과장 어휘("핵심적으로", "시사하는 바가 크다"), 콜론 부제, 이모지 남발, 문두 접속사 반복
+- **가운뎃점(·) 나열 남발** — 본문에서 "A·B·C" 압축은 기계 티. 쉼표나 "A랑 B하고 C"로 푼다 (ai-tell C-12)
 - **`c:`/`r:` 접두어, `[출처]` 대괄호 태깅, "…권장." 체언 종지** — Claude가 만든 가짜 시그니처
 
 ---

package/dist/role-agents/technical-writer/references/style-guide.md

@@ -40,6 +40,7 @@
 - 번역체 금지 — "API 키를 이용한 사용자 인증 처리가 완료된 후" → "API 키로 인증한 후"
 - 용어 일관성 — 같은 개념에 다른 단어 혼용 금지
 - 약어: 첫 등장 시 `SSR(Server-Side Rendering)` 형식
+- 가운뎃점(·) 절제 — 본문에서 "A·B·C" 압축 나열 대신 쉼표나 "A랑 B하고 C"로 푼다. 사람은 산문에서 가운뎃점을 거의 안 쓴다 (표·용어 목록은 예외). 자세히는 `ai-tell-quick-rules.md` C-12
 
 ### Technical Term Handling
 

package/dist/role-agents/ux-writer/AGENT.md

@@ -101,6 +101,11 @@ You are the UX Writer role agent.
 '{명사}가 {명사}해서' 형태로 풀어도 캐주얼해진다.
 - ❌ 네트워크 오류 발생 → ✅ 네트워크가 연결되지 않아서 불러오지 못했어요
 
+## 원칙 6 — 가운뎃점(·) 절제
+
+문구에서 "A·B·C"로 항목을 압축하지 않는다. 쉼표나 "A랑 B"처럼 푼다 — 사람은 가운뎃점을 거의 안 쓴다.
+- ❌ 이름·전화번호·이메일을 입력해요 → ✅ 이름, 전화번호, 이메일을 입력해요
+
 ## 작업 모드
 
 ### 문구 작성

package/dist/role-agents/video-summarizer/AGENT.md

@@ -75,6 +75,10 @@ URL인지 로컬 경로인지 먼저 판별하고, 로컬 경로면 다운로드
    - **인터뷰**: 질문, 답변, 게스트, 인터뷰
    - 위 어디에도 해당하지 않으면 **일반**으로 처리한다.
 
+## 한글 작성 규칙
+
+요약 본문에서 가운뎃점(·)으로 항목을 압축하지 않는다. "A·B·C" 대신 쉼표나 "A랑 B하고 C"로 푼다 — 사람은 산문에서 가운뎃점을 거의 안 쓴다 (표나 용어 목록은 예외).
+
 ## 출력 MD 구조
 
 아래 템플릿으로 작성한다. 유형에 따라 마지막에 추가 섹션을 붙인다.

package/dist/skills/review/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: review
 version: "1.0.0"
-description: "PR·브랜치·커밋의 변경사항을 3종 리뷰 에이전트(보안·성능·품질)로 검토하고, humanize-monolith로 리포트를 자연스러운 한국어로 다듬는다."
+description: "PR·브랜치·커밋의 변경사항을 3종 리뷰 에이전트(보안·성능·품질)로 검토하고, humanize-monolith로 리포트를 다듬은 뒤, PR 대상이면 code-review-writer가 작성한 인라인 코멘트로 게시한다."
 triggers:
   - "PR 리뷰"
   - "브랜치 리뷰"
@@ -11,6 +11,10 @@ triggers:
   - "review branch"
   - "이 브랜치 리뷰"
   - "변경사항 리뷰"
+  - "PR에 코멘트 남겨줘"
+  - "리뷰 코멘트 달아줘"
+  - "PR에 인라인 코멘트"
+  - "리뷰 결과 PR에 게시"
 inputs:
   target:
     type: string
@@ -25,12 +29,13 @@ outputs:
   - changeContext
   - reviewReport
   - verdict
+  - postedReview
 ---
 
 # Review Skill
 
 execute 세션 없이 PR·브랜치·커밋의 변경사항을 직접 리뷰 파이프라인에 주입해 검토합니다.
-변경 파일을 수집하고, 3종 리뷰 에이전트(보안·성능·품질)로 다각도 리뷰한 뒤, Pass/Block 판정과 마크다운 리포트를 생성합니다.
+변경 파일을 수집하고, 3종 리뷰 에이전트(보안·성능·품질)로 다각도 리뷰한 뒤, Pass/Block 판정과 마크다운 리포트를 생성합니다. 리뷰 대상이 GitHub PR이면 `code-review-writer` 에이전트가 작성한 인라인 코멘트로 PR에 게시까지 이어집니다.
 
 ## 사용 방법
 
@@ -182,14 +187,71 @@ humanize-monolith는 두 룰북을 함께 적용합니다.
 
 즉 리뷰 파이프라인 리포트도 인라인 코멘트와 동일하게 voice + 음차가 함께 처리됩니다.
 
-윤문된 리포트를 사용자에게 표시합니다:
-- `approved: true` → 리뷰 통과. 리포트를 보여주고 종료합니다.
-- `approved: false` → critical/high 이슈가 남아 Block 상태입니다. 5단계로 진행합니다.
+윤문된 리포트를 사용자에게 표시합니다. 그다음 대상이 GitHub PR이면 4.7단계로, 아니면 결과 표시로 넘어갑니다.
+- `approved: true` → 리뷰 통과. 리포트를 보여줍니다.
+- `approved: false` → critical/high 이슈가 남아 Block 상태입니다.
 
-### 5단계: 수정 확인 (review_fix)
+### 4.7단계: 인라인 코멘트 게시 (code-review-writer)
 
-Block일 때 사용자에게 **"수정하시겠습니까?"** 를 먼저 확인합니다.
-동의하면 `review_fix`로 수정 컨텍스트를 받아 critical/high 이슈를 수정합니다:
+리뷰 대상이 GitHub PR이면, 4단계에서 병합한 이슈를 **리포트로 끝내지 않고 PR에 인라인 코멘트로 게시**합니다. 이 단계의 코멘트 본문은 반드시 `code-review-writer` 에이전트가 작성합니다 — Claude가 즉흥으로 쓰지 않습니다. 그래야 어투가 매 리뷰마다 일정하게 유지됩니다.
+
+#### 진입 경로 두 가지
+
+이 단계는 `/review`를 처음부터 돌린 흐름뿐 아니라, **대화 도중 "이제 PR에 코멘트 남겨줘"처럼 게시만 따로 요청**받았을 때도 진입점이 됩니다 (위 triggers의 "PR에 코멘트 남겨줘" 등). 두 경우 모두 아래 **신선도 가드를 먼저 통과해야** 게시할 수 있습니다.
+
+#### 신선도 가드 (stale consensus 게시 금지)
+
+게시 직전에, 게시하려는 consensus가 **현재 diff와 일치하는지** 반드시 확인합니다. 리뷰를 끝낸 뒤 코드가 바뀌었거나(커밋 추가·로컬 수정), 애초에 활성 리뷰 세션이 없으면 그 consensus는 stale이므로 **그대로 올리지 않습니다.**
+
+```bash
+# 리뷰 시점 대비 PR head·작업트리가 바뀌었는지 확인
+gh pr view <target> --json headRefOid
+git rev-parse HEAD && git status --porcelain
+```
+
+판단 기준:
+
+- **이번 세션에 방금 리뷰를 끝냈고 그 뒤 diff 변화가 없다** → consensus가 신선함. 곧장 게시 진행.
+- **리뷰 후 코드가 바뀌었다 / 활성 리뷰 세션이 없다 / 다른 세션의 오래된 결과다** → consensus가 stale. **게시하지 말고**, 1단계(blast_radius)부터 현재 diff로 리뷰 파이프라인(1~4단계)을 다시 돌린 뒤, 새로 나온 consensus로 4.7을 진행합니다. 사용자에게 "변경이 있어 현재 코드로 다시 리뷰한 뒤 게시할게요"라고 한 줄 알립니다.
+
+즉 인라인 코멘트는 **언제 요청받든 항상 "현재 diff 기준 consensus + code-review-writer voice"** 로만 게시됩니다. 옛 리뷰 메모리를 그대로 옮겨 적거나 Claude가 손으로 코멘트를 짜는 경로는 없습니다.
+
+**PR 식별.** 먼저 대상이 PR인지 확인합니다.
+
+```bash
+gh pr view <target> --json number,headRefName,baseRefName,url 2>/dev/null
+```
+
+`target`이 브랜치면 그 브랜치의 PR을, 생략됐으면 현재 브랜치의 PR을 찾습니다. PR이 없으면(로컬 브랜치·커밋 범위 등) 이 단계를 통째로 건너뛰고 결과 표시로 갑니다.
+
+**게시 확인.** PR이 식별되면 사용자에게 한 번 확인합니다: **"발견된 이슈 N건을 PR #<number>에 인라인 코멘트로 게시할까요?"** 동의하지 않으면 리포트만 보여주고 종료합니다.
+
+**코멘트 본문 작성 (code-review-writer).** `ges_agent { action: "get", name: "code-review-writer" }`로 에이전트 시스템 프롬프트를 가져온 뒤, 그 관점에서 4단계 `mergedIssues`의 각 이슈를 인라인 코멘트 본문으로 작성합니다. 이슈의 `file`·`line`·`severity`는 그대로 두고, `message`·`suggestion`을 에이전트 voice로 다듬어 코멘트 본문을 만듭니다.
+
+- code-review-writer는 `author-voice.md`(제안형·온기·물결·이모지)와 `ai-tell-quick-rules.md`(음차 교정)를 이미 내장하므로 **별도 humanize-monolith 패스를 거치지 않습니다.**
+- 에이전트 룰에 따라 `c:`/`r:` 접두어, `[출처]` 태깅, "…권장." 체언 종지는 쓰지 않습니다. 이건 Claude artifact이지 실제 리뷰어 어투가 아닙니다.
+- severity는 본문 첫 줄에 `[critical]`처럼 대괄호 라벨로만 표기합니다.
+
+**게시 (gh api).** 작성한 코멘트를 한 번의 리뷰로 묶어 게시합니다. 이슈마다 개별 호출하지 않고 `comments` 배열로 모읍니다.
+
+```bash
+gh api repos/{owner}/{repo}/pulls/{number}/reviews \
+  -f event=COMMENT \
+  -f body="<요약 한 줄 — code-review-writer가 작성한 overall summary>" \
+  --input <(jq -n '{ comments: [ { path: "...", line: 42, side: "RIGHT", body: "..." } ] }')
+```
+
+- `line`은 diff의 **우측(신규) 라인**을 기준으로 하고 `side: "RIGHT"`를 명시합니다. 삭제된 라인을 짚어야 하면 `side: "LEFT"`를 씁니다.
+- 라인 매핑이 불확실한 이슈(파일 전반·구조적 지적 등)는 인라인 대신 리뷰 `body` 요약에 한 줄로 넣습니다. 임의 라인에 억지로 붙이지 않습니다.
+- 게시 후 리뷰 URL을 사용자에게 보여줍니다.
+
+JSON 제어문자가 깨지지 않도록 코멘트 본문은 셸 변수 echo 파이프 대신 `jq`로 직접 조립하거나 파일로 떨궈 `--input`으로 전달합니다.
+
+### 5단계: 수정 확인 (review_fix, opt-in)
+
+자동 수정은 기본 동작이 아닙니다. 4.7단계로 인라인 코멘트를 게시했거나 리포트를 보여준 뒤, 사용자가 **명시적으로 수정을 요청할 때만** 진행합니다 ("고쳐줘"·"수정해줘" 등). Block 상태라도 먼저 자동 수정을 들이밀지 않습니다.
+
+요청을 받으면 `review_fix`로 수정 컨텍스트를 받아 critical/high 이슈를 수정합니다:
 
 ```
 ges_execute {
@@ -227,3 +289,13 @@ ges_execute {
 
 {report 마크다운}
 ```
+
+4.7단계에서 인라인 코멘트를 게시했으면, 리포트 끝에 게시 결과를 한 줄로 덧붙입니다.
+
+```
+---
+
+**인라인 코멘트**: PR #<number>에 <N>건 게시 완료 → <리뷰 URL>
+```
+
+PR이 아니거나 사용자가 게시를 거절했으면 이 블록을 생략합니다.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@tienne/gestalt",
-  "version": "0.33.3",
+  "version": "0.34.0",
   "description": "TypeScript AI Development Harness - Gestalt psychology-driven requirement clarification",
   "type": "module",
   "main": "./dist/src/index.js",

package/role-agents/presentation-designer/AGENT.md

@@ -205,6 +205,8 @@ Reveal.initialize({
 
 프레젠테이션은 **워딩이 먼저, 디자인이 나중**이다. 순서를 지키지 않으면 디자인에 워딩을 끼워 맞추게 된다.
 
+슬라이드 한글 텍스트에서 가운뎃점(·)으로 항목을 압축하지 않는다. "A·B·C" 대신 쉼표나 줄바꿈으로 푼다 — 사람은 산문에서 가운뎃점을 거의 안 쓴다 (불릿 라벨 같은 짧은 목록은 예외). 워딩 초안 단계의 technical-writer도 style-guide의 같은 규칙을 따른다.
+
 ### Phase 1: technical-writer (워딩 초안)
 
 프레젠테이션 작성 요청이 들어오면, 디자인 작업 전에 반드시 `technical-writer` 관점을 먼저 확보해야 한다.

package/role-agents/product-planner/AGENT.md

@@ -28,3 +28,5 @@ Provide a structured perspective with:
 - Priority recommendations
 - Acceptance criteria suggestions
 - Scope boundary clarifications
+
+한글로 작성할 때 가운뎃점(·)으로 항목을 압축 나열하지 않는다. "A·B·C" 대신 쉼표나 "A랑 B하고 C"로 푼다 — 사람은 산문에서 가운뎃점을 거의 안 쓴다 (표·용어 목록은 예외).

package/role-agents/technical-writer/references/ai-tell-quick-rules.md

@@ -50,6 +50,7 @@
 | C-9 | 숫자 괄호 인덱싱 "(1)·(2)·(3)" | S2 | 본문에 녹이거나 단순 줄바꿈 |
 | C-10 | 콜론 부제 헤딩 "X: Y" 반복 | S1 | 헤딩 짧게 또는 평서 헤딩으로 |
 | C-11 | 연결어미 뒤 쉼표 (-고/-며/-지만/-며서/-아서/-어서 직후 쉼표) | S1 | 쉼표 제거. 6+회=강한 신호. KatFish 4.84배 분리도 |
+| C-12 | 가운뎃점(·) 나열 남발 — 본문 산문에서 "A·B·C"로 항목 압축 | S2 | 쉼표나 구어 연결로 풀기("A, B, C" / "A랑 B하고 C"). 사람은 산문에서 가운뎃점을 거의 안 쓴다. 단 표 안 압축, 용어 목록, 굳어진 합성어("입출력")는 예외 |
 
 ## D. AI 특유의 관용구 (Signature Phrases)
 

package/role-agents/technical-writer/references/author-voice.md

@@ -143,6 +143,7 @@ ghost 는 button의 ghost variant 를 위한 토큰입니다.
 반대로 두 레지스터 모두에서 **제거**할 진짜 AI-tell:
 - "결론적으로", "요약하자면", "이를 통해", "~를 수행합니다" 의인화 주어
 - 과장 어휘("핵심적으로", "시사하는 바가 크다"), 콜론 부제, 이모지 남발, 문두 접속사 반복
+- **가운뎃점(·) 나열 남발** — 본문에서 "A·B·C" 압축은 기계 티. 쉼표나 "A랑 B하고 C"로 푼다 (ai-tell C-12)
 - **`c:`/`r:` 접두어, `[출처]` 대괄호 태깅, "…권장." 체언 종지** — Claude가 만든 가짜 시그니처
 
 ---

package/role-agents/technical-writer/references/style-guide.md

@@ -40,6 +40,7 @@
 - 번역체 금지 — "API 키를 이용한 사용자 인증 처리가 완료된 후" → "API 키로 인증한 후"
 - 용어 일관성 — 같은 개념에 다른 단어 혼용 금지
 - 약어: 첫 등장 시 `SSR(Server-Side Rendering)` 형식
+- 가운뎃점(·) 절제 — 본문에서 "A·B·C" 압축 나열 대신 쉼표나 "A랑 B하고 C"로 푼다. 사람은 산문에서 가운뎃점을 거의 안 쓴다 (표·용어 목록은 예외). 자세히는 `ai-tell-quick-rules.md` C-12
 
 ### Technical Term Handling
 

package/role-agents/ux-writer/AGENT.md

@@ -101,6 +101,11 @@ You are the UX Writer role agent.
 '{명사}가 {명사}해서' 형태로 풀어도 캐주얼해진다.
 - ❌ 네트워크 오류 발생 → ✅ 네트워크가 연결되지 않아서 불러오지 못했어요
 
+## 원칙 6 — 가운뎃점(·) 절제
+
+문구에서 "A·B·C"로 항목을 압축하지 않는다. 쉼표나 "A랑 B"처럼 푼다 — 사람은 가운뎃점을 거의 안 쓴다.
+- ❌ 이름·전화번호·이메일을 입력해요 → ✅ 이름, 전화번호, 이메일을 입력해요
+
 ## 작업 모드
 
 ### 문구 작성

package/role-agents/video-summarizer/AGENT.md

@@ -75,6 +75,10 @@ URL인지 로컬 경로인지 먼저 판별하고, 로컬 경로면 다운로드
    - **인터뷰**: 질문, 답변, 게스트, 인터뷰
    - 위 어디에도 해당하지 않으면 **일반**으로 처리한다.
 
+## 한글 작성 규칙
+
+요약 본문에서 가운뎃점(·)으로 항목을 압축하지 않는다. "A·B·C" 대신 쉼표나 "A랑 B하고 C"로 푼다 — 사람은 산문에서 가운뎃점을 거의 안 쓴다 (표나 용어 목록은 예외).
+
 ## 출력 MD 구조
 
 아래 템플릿으로 작성한다. 유형에 따라 마지막에 추가 섹션을 붙인다.

package/skills/review/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: review
 version: "1.0.0"
-description: "PR·브랜치·커밋의 변경사항을 3종 리뷰 에이전트(보안·성능·품질)로 검토하고, humanize-monolith로 리포트를 자연스러운 한국어로 다듬는다."
+description: "PR·브랜치·커밋의 변경사항을 3종 리뷰 에이전트(보안·성능·품질)로 검토하고, humanize-monolith로 리포트를 다듬은 뒤, PR 대상이면 code-review-writer가 작성한 인라인 코멘트로 게시한다."
 triggers:
   - "PR 리뷰"
   - "브랜치 리뷰"
@@ -11,6 +11,10 @@ triggers:
   - "review branch"
   - "이 브랜치 리뷰"
   - "변경사항 리뷰"
+  - "PR에 코멘트 남겨줘"
+  - "리뷰 코멘트 달아줘"
+  - "PR에 인라인 코멘트"
+  - "리뷰 결과 PR에 게시"
 inputs:
   target:
     type: string
@@ -25,12 +29,13 @@ outputs:
   - changeContext
   - reviewReport
   - verdict
+  - postedReview
 ---
 
 # Review Skill
 
 execute 세션 없이 PR·브랜치·커밋의 변경사항을 직접 리뷰 파이프라인에 주입해 검토합니다.
-변경 파일을 수집하고, 3종 리뷰 에이전트(보안·성능·품질)로 다각도 리뷰한 뒤, Pass/Block 판정과 마크다운 리포트를 생성합니다.
+변경 파일을 수집하고, 3종 리뷰 에이전트(보안·성능·품질)로 다각도 리뷰한 뒤, Pass/Block 판정과 마크다운 리포트를 생성합니다. 리뷰 대상이 GitHub PR이면 `code-review-writer` 에이전트가 작성한 인라인 코멘트로 PR에 게시까지 이어집니다.
 
 ## 사용 방법
 
@@ -182,14 +187,71 @@ humanize-monolith는 두 룰북을 함께 적용합니다.
 
 즉 리뷰 파이프라인 리포트도 인라인 코멘트와 동일하게 voice + 음차가 함께 처리됩니다.
 
-윤문된 리포트를 사용자에게 표시합니다:
-- `approved: true` → 리뷰 통과. 리포트를 보여주고 종료합니다.
-- `approved: false` → critical/high 이슈가 남아 Block 상태입니다. 5단계로 진행합니다.
+윤문된 리포트를 사용자에게 표시합니다. 그다음 대상이 GitHub PR이면 4.7단계로, 아니면 결과 표시로 넘어갑니다.
+- `approved: true` → 리뷰 통과. 리포트를 보여줍니다.
+- `approved: false` → critical/high 이슈가 남아 Block 상태입니다.
 
-### 5단계: 수정 확인 (review_fix)
+### 4.7단계: 인라인 코멘트 게시 (code-review-writer)
 
-Block일 때 사용자에게 **"수정하시겠습니까?"** 를 먼저 확인합니다.
-동의하면 `review_fix`로 수정 컨텍스트를 받아 critical/high 이슈를 수정합니다:
+리뷰 대상이 GitHub PR이면, 4단계에서 병합한 이슈를 **리포트로 끝내지 않고 PR에 인라인 코멘트로 게시**합니다. 이 단계의 코멘트 본문은 반드시 `code-review-writer` 에이전트가 작성합니다 — Claude가 즉흥으로 쓰지 않습니다. 그래야 어투가 매 리뷰마다 일정하게 유지됩니다.
+
+#### 진입 경로 두 가지
+
+이 단계는 `/review`를 처음부터 돌린 흐름뿐 아니라, **대화 도중 "이제 PR에 코멘트 남겨줘"처럼 게시만 따로 요청**받았을 때도 진입점이 됩니다 (위 triggers의 "PR에 코멘트 남겨줘" 등). 두 경우 모두 아래 **신선도 가드를 먼저 통과해야** 게시할 수 있습니다.
+
+#### 신선도 가드 (stale consensus 게시 금지)
+
+게시 직전에, 게시하려는 consensus가 **현재 diff와 일치하는지** 반드시 확인합니다. 리뷰를 끝낸 뒤 코드가 바뀌었거나(커밋 추가·로컬 수정), 애초에 활성 리뷰 세션이 없으면 그 consensus는 stale이므로 **그대로 올리지 않습니다.**
+
+```bash
+# 리뷰 시점 대비 PR head·작업트리가 바뀌었는지 확인
+gh pr view <target> --json headRefOid
+git rev-parse HEAD && git status --porcelain
+```
+
+판단 기준:
+
+- **이번 세션에 방금 리뷰를 끝냈고 그 뒤 diff 변화가 없다** → consensus가 신선함. 곧장 게시 진행.
+- **리뷰 후 코드가 바뀌었다 / 활성 리뷰 세션이 없다 / 다른 세션의 오래된 결과다** → consensus가 stale. **게시하지 말고**, 1단계(blast_radius)부터 현재 diff로 리뷰 파이프라인(1~4단계)을 다시 돌린 뒤, 새로 나온 consensus로 4.7을 진행합니다. 사용자에게 "변경이 있어 현재 코드로 다시 리뷰한 뒤 게시할게요"라고 한 줄 알립니다.
+
+즉 인라인 코멘트는 **언제 요청받든 항상 "현재 diff 기준 consensus + code-review-writer voice"** 로만 게시됩니다. 옛 리뷰 메모리를 그대로 옮겨 적거나 Claude가 손으로 코멘트를 짜는 경로는 없습니다.
+
+**PR 식별.** 먼저 대상이 PR인지 확인합니다.
+
+```bash
+gh pr view <target> --json number,headRefName,baseRefName,url 2>/dev/null
+```
+
+`target`이 브랜치면 그 브랜치의 PR을, 생략됐으면 현재 브랜치의 PR을 찾습니다. PR이 없으면(로컬 브랜치·커밋 범위 등) 이 단계를 통째로 건너뛰고 결과 표시로 갑니다.
+
+**게시 확인.** PR이 식별되면 사용자에게 한 번 확인합니다: **"발견된 이슈 N건을 PR #<number>에 인라인 코멘트로 게시할까요?"** 동의하지 않으면 리포트만 보여주고 종료합니다.
+
+**코멘트 본문 작성 (code-review-writer).** `ges_agent { action: "get", name: "code-review-writer" }`로 에이전트 시스템 프롬프트를 가져온 뒤, 그 관점에서 4단계 `mergedIssues`의 각 이슈를 인라인 코멘트 본문으로 작성합니다. 이슈의 `file`·`line`·`severity`는 그대로 두고, `message`·`suggestion`을 에이전트 voice로 다듬어 코멘트 본문을 만듭니다.
+
+- code-review-writer는 `author-voice.md`(제안형·온기·물결·이모지)와 `ai-tell-quick-rules.md`(음차 교정)를 이미 내장하므로 **별도 humanize-monolith 패스를 거치지 않습니다.**
+- 에이전트 룰에 따라 `c:`/`r:` 접두어, `[출처]` 태깅, "…권장." 체언 종지는 쓰지 않습니다. 이건 Claude artifact이지 실제 리뷰어 어투가 아닙니다.
+- severity는 본문 첫 줄에 `[critical]`처럼 대괄호 라벨로만 표기합니다.
+
+**게시 (gh api).** 작성한 코멘트를 한 번의 리뷰로 묶어 게시합니다. 이슈마다 개별 호출하지 않고 `comments` 배열로 모읍니다.
+
+```bash
+gh api repos/{owner}/{repo}/pulls/{number}/reviews \
+  -f event=COMMENT \
+  -f body="<요약 한 줄 — code-review-writer가 작성한 overall summary>" \
+  --input <(jq -n '{ comments: [ { path: "...", line: 42, side: "RIGHT", body: "..." } ] }')
+```
+
+- `line`은 diff의 **우측(신규) 라인**을 기준으로 하고 `side: "RIGHT"`를 명시합니다. 삭제된 라인을 짚어야 하면 `side: "LEFT"`를 씁니다.
+- 라인 매핑이 불확실한 이슈(파일 전반·구조적 지적 등)는 인라인 대신 리뷰 `body` 요약에 한 줄로 넣습니다. 임의 라인에 억지로 붙이지 않습니다.
+- 게시 후 리뷰 URL을 사용자에게 보여줍니다.
+
+JSON 제어문자가 깨지지 않도록 코멘트 본문은 셸 변수 echo 파이프 대신 `jq`로 직접 조립하거나 파일로 떨궈 `--input`으로 전달합니다.
+
+### 5단계: 수정 확인 (review_fix, opt-in)
+
+자동 수정은 기본 동작이 아닙니다. 4.7단계로 인라인 코멘트를 게시했거나 리포트를 보여준 뒤, 사용자가 **명시적으로 수정을 요청할 때만** 진행합니다 ("고쳐줘"·"수정해줘" 등). Block 상태라도 먼저 자동 수정을 들이밀지 않습니다.
+
+요청을 받으면 `review_fix`로 수정 컨텍스트를 받아 critical/high 이슈를 수정합니다:
 
 ```
 ges_execute {
@@ -227,3 +289,13 @@ ges_execute {
 
 {report 마크다운}
 ```
+
+4.7단계에서 인라인 코멘트를 게시했으면, 리포트 끝에 게시 결과를 한 줄로 덧붙입니다.
+
+```
+---
+
+**인라인 코멘트**: PR #<number>에 <N>건 게시 완료 → <리뷰 URL>
+```
+
+PR이 아니거나 사용자가 게시를 거절했으면 이 블록을 생략합니다.