genetics-mcp 2.17.0 → 2.18.0

package/skills/genetics-report/SKILL.md

@@ -11,7 +11,7 @@ description: |
   - "검수 요청 문서 만들어줘" / "장애 사후 보고서 / 릴리스 노트를 고객용으로"
   - "기술보고서/인수인계/온보딩 문서/포스트모템 만들어줘" (→ PART 구성으로 푼다)
   - "조사한 걸 정리해서 할지 말지 정하게 해줘" / "R&D 브리핑 / 기술 도입 검토서 / 결정 요청서" (→ 결정한다 모드)
-  내용 설계(독자 정의 → 등급 → 고객 언어 치환 → 개조식 전환)가 본체이고, 전달은 둘 중 하나입니다:
+  내용 설계(독자 정의 → 등급 → 고객 언어 치환 → 자리별 문체 전환)가 본체이고, 전달은 둘 중 하나입니다:
   Lim MCP 발행(서버 렌더, 링크 공유) 또는 단일 HTML(같은 관보 서식·폰트 임베드).
   서식은 **한국 정부간행물(관보) 문서 문법**입니다 — 표지·발행 이력·차례·활용법·요약·PART 간지·
   두 단 본문(여백 주석)·부록·판권지로 서고, 인쇄하면 실제 A4 페이지가 나옵니다.
@@ -58,7 +58,8 @@ version: "4.0.0"
 > 부록 · 판권지로 서고, 인쇄하면 실제 A4 페이지가 나온다.
 >
 > **가구만 채우면 반려된다.** 셋이 본체다 —
-> ① `sections[].marg`(여백 주석 Why/Key Point/Advice) ② `parts`(PART 층위) ③ **개조식 톤**.
+> ① `sections[].marg`(여백 주석 Why/Key Point/Advice) ② `parts`(PART 층위) ③ **자리별 톤**
+> (기록 자리는 개조식, 요청 자리는 하십시오체 — 5·5a).
 > 없어도 발행은 되지만 렌더러가 ⚠ 로 세므로 `dry_run` 경고를 반드시 읽는다.
 >
 > **비트맵은 두 자리에 실린다** — `logo`(표지 고객사 마크)와 `figure`(절 본문 도판).
@@ -70,15 +71,14 @@ version: "4.0.0"
 > 자세한 것은 `references/lim-portal-format.md`. 조판 규칙 원전은 `gazette-report` 스킬.
 
 **Lim 발행 규칙** (어겨도 서버가 거부하지만, 알고 시작할 것):
-- **톤은 개조식이다 — 다만 「우리가 한 일」에만 그렇다.** `~함 / ~했음 / ~필요 / ~한 상황`.
-  본문에 `습니다|십시오|합니다|입니다|됩니다|주세요` 가 **0건**이어야 한다.
-- ⚠ **상대가 할 일에 개조식 종결을 붙이면 그대로 명령형이 된다.** 이 규칙의 **반대쪽 벽**이고,
-  오래 안 적혀 있어서 사고가 났다(2026-09-02, 보고서 #32) — 「~해 주셔야 함」·「회신 필요」·
-  「확인 필요」로 나갔고 고객이 **「이거 너무 싸가지없는 거 아니야?」**로 반려했다.
-  고치는 법은 금지 어휘를 쓰는 것이 **아니라** 높임 어간 `-시-` 를 되살리는 것이다 —
-  「확인 부탁드림」·「정해 주시면 반영하겠음」·「회신 주시면 이어서 진행함」. 제목은 명사형 「~ 요청」.
-  ⚠ **「~하시면 됨」도 요청 자리에서는 하대다**(2026-09-03 재반려) — 아래 5a.
-  서버가 `dry_run` 경고로 센다(`lib/report_tone.php`).
+- **톤은 자리가 정한다 — 문서 전체가 아니다.** 기록 자리(우리·사물이 주어)는 개조식
+  `~함 / ~했음 / ~임`. **상대에게 말 거는 자리는 하십시오체**
+  `~하여 주시기 바랍니다 / ~부탁드립니다 / ~하겠습니다`. 자세한 것은 아래 5·5a.
+  경어체 `습니다|십시오|합니다|입니다|됩니다|주세요` 0건은 **기록 자리에만** 거는 기준이다.
+- ⚠ **톤 게이트는 경고이지 거절이 아니다.** `lib/report_tone.php` 가 `dry_run` 경고로 셀 뿐
+  발행을 막지 않는다 — 실측(2026-09-11): 경어체 경고를 안은 `update_report` 2회 모두 발행 성공.
+  **요청 자리에서 나는 경어체 경고는 의도된 것이므로 고치지 않는다**(`references/visual-first.md` §8).
+  이 경고를 하드 규칙으로 오인해 종결을 비튼 것이 2026-09-02부터 **네 번 반복된 반려의 원인**이다.
 - `tenant` 는 키가 가리키는 고객사와 일치해야 한다(오발행 방지 가드). 값은 소속처 slug 우선·이름 폴백 — 아래 :228 의 `slug` 는 **보고서** slug 라 다른 것이다.
 - `sections[].kind` 는 `summary|status|cases|asks|note` 다섯 가지뿐 — 그 밖의 값은 절이 통째로 사라지므로 서버가 거절한다.
 - `cases[].grade` 는 `grades` 에 정의된 이름이어야 한다.
@@ -99,16 +99,26 @@ version: "4.0.0"
 
 ## 세 가지 독자 — 뼈대는 하나다
 
-서식은 하나뿐이므로 **뼈대를 바꾸지 않는다.** 바뀌는 것은 PART 를 무엇으로 가르느냐다.
+서식은 하나뿐이므로 **뼈대를 바꾸지 않는다.** 바뀌는 것은 PART 를 무엇으로 가르느냐,
+그리고 **그 독자에게 말을 걸 때 어떤 종결로 맺느냐**다(5a) — 독자가 사람이면 요청 자리는
+하십시오체다. 문체를 독자와 무관한 상수로 두었다가 말투 반려를 네 번 받았다.
 
 | 독자의 일 | PART 를 무엇으로 가르나 | 절의 kind |
 |---|---|---|
 | 판정한다 (검수·회신·결재) | 요청 / 경과 / 잔여 | `asks` → `summary` → `status` → `cases` → `note` |
 | **배운다** (유지보수·인수·온보딩·사후분석) | 원리 / 붕괴와 처방 / 적용과 남은 것 | 같은 다섯 kind 를 그 순서로 쓴다 |
-| **결정한다** (도입 여부·옵션 선택·예산·일정) | 결정 / 근거 / 이행 | `asks` → `summary` → `status` → `cases` → `note`(하지 않기로 한 것) → `note`(리스크) → `note`(활용 계획) |
+| **결정한다** (도입 여부·옵션 선택·예산·일정) | 결정 / 근거 / 이행 | `asks` → `summary` → `note`(선택지 전치 행렬) → `cases` → `note`(FCG 의견 표 한 장) → `note`(바꾸는 길의 위험) → `note`(회신 뒤 일정) |
+
+**회신·결정이 없는 정황 공유 보고는 판정한다 뼈대에서 요청 PART 만 뺀다.** PART 는 「경과 / 남은 것」이고,
+요지·대조표·건은 경과 PART 하나에 함께 선다(`references/process.md` 「PART 를 먼저 가른다」).
+절의 성격(시각표·원인·앞날)으로 PART 를 새로 짓지 않는다 — 「경과 / 원인」으로 가르면 같은 건이 두 PART 에 문장만 바꿔 선다(실사례 2026-09-12).
+독자가 결정권자면 `status` 대조표를 빼고 요약면 상태 막대만 남긴다(`references/process.md` 「이 답에서 곧바로 정해지는 것」).
+
+결정한다 모드에 「하지 않기로 한 것」 절은 **따로 두지 않는다** — 선택지 표의 「정할 자리」·「다시 볼 때」 행이
+그 몫을 한다(반드시 지키는 것 10). FCG 의견은 절 하나, 표 한 장이 전부다 — 다른 절·열·제목에 배지 않는다.
 
 **결정 문서와 R&D 블로그 글은 다른 물건이다.** 블로그 글은 「이런 걸 해 봤고 이런 걸 배웠다」로 끝나고 독자가
-할 일이 없다. 브리핑은 **결정 요청(무엇을 언제까지)·복수의 선택지(기각안 포함)·근거 등급·성숙도·기한**이
+할 일이 없다. 브리핑은 **결정 요청(무엇을 언제까지)·복수의 선택지(그대로 두는 길 포함)·근거 등급·성숙도·기한**이
 추가된다 — 이 다섯이 없으면 문서가 아무리 두꺼워도 블로그 글이다. 정부 R&D 최종보고서·군 결정문(BLUF)·
 영국 정부 Submissions 가 공통으로 요구하는 것이 이 다섯이다(`references/lim-portal-format.md` §12.7b).
 
@@ -136,14 +146,16 @@ Lim 보고서, Lim 에 올려줘, 고객 보고서, 수정 내역, 검수 요청
 
 1. **이 문서를 누가 읽는가** — 고객사 검수 담당? 결정권자? 실무 매장 인원?
 2. **읽고 나서 무엇을 해야 하는가** — 확인만? 판단해서 회신? 결재?
-3. **읽고 나서 무엇을 결정하는가** — 선택지는 무엇이고, 우리 권고는 무엇이며, **언제까지** 정해야 하는가.
+3. **읽고 나서 무엇을 결정하는가** — 선택지는 무엇이고, 선택지마다 무엇이 달라지는가, **언제까지** 정해야 하는가.
+   **FCG 의견을 낼지는 따로 묻는다** — 내면 한 절 한 자리.
    (「결정한다」 모드에서는 필수. 답이 「특별히 결정할 것은 없다」면 그 문서는 브리핑이 아니라 보고다.)
 
 독자가 정해지면 나머지가 전부 따라 정해진다. 같은 사실이 이렇게 갈린다.
 
-**두 가지를 동시에 바꾼다** — 내부 용어를 고객 용어로, 그리고 문체를 개조식으로.
+**두 가지를 동시에 바꾼다** — 내부 용어를 고객 용어로, 그리고 문체를 그 자리에 맞게.
+아래는 **기록 자리**(우리가 한 일)의 대응표다. 상대에게 말 거는 자리는 5a 를 따른다.
 
-| 내부 기록 | 고객 문서(개조식) |
+| 내부 기록 | 고객 문서(기록 자리 · 개조식) |
 |---|---|
 | "저장 경로 6곳을 수정" | "저장이 일어나는 모든 경로를 수정**함**" |
 | "2026-08-09 운영 배포 완료" | "2026년 8월 9일 운영 환경에 반영**됨**" |
@@ -160,6 +172,29 @@ Lim 보고서, Lim 에 올려줘, 고객 보고서, 수정 내역, 검수 요청
 
 ---
 
+## 0.5단계 — 시각 우선: 글보다 먼저 정한다 [MUST] (2026-09-08)
+
+> 반려 원문 셋(앳플리 체중 조절 권장량 4차, 같은 날): 「글만 적어서는 이해가 어려움 — 그림 자료」 →
+> 「신입은 읽다가 자겠다」 → 「색상 다변화, 핵심은 굵게, 배지·그래프 보강」. 셋 다 원고를 쓴
+> 에이전트가 「글이면 충분하다」고 판단한 자리였다. **판단을 에이전트에게 남겨 두지 않는다** —
+> 렌더러가 센다(dry_run ⚠, `lim-portal-format.md` §10-1). 여기는 그 앞의 집필 공식이다.
+
+원고를 쓰기 전에, 절마다 이 순서로 정한다. 글은 마지막이다.
+
+| 순서 | 정할 것 | 기준 |
+|---|---|---|
+| 1 | **한 장 이야기** | 문제 → 원인 → 해법 → 지금 상태 → 정할 것. 요약면 다섯 칸이 이 순서이고, 다루는 일의 **사건 경과** 표 한 장을 1절에 둔다(이 문서의 판 이력은 `history` — 3b) |
+| 2 | **예시 한 명** | 실존 이용자 하나의 실제 숫자로 문서 전체를 관통시킨다(같은 사람이 그림·표·건에 반복) |
+| 3 | **용어 잠금 표** | 같은 낱말이 두 값을 가리키면 그 자리에서 문서가 죽는다. 뜻이 갈리는 낱말은 표 한 장으로 값·정의·보이는 자리를 박는다 |
+| 4 | **절마다 시각 장치 먼저** | 개념은 그림(HTML 개념도 → `assets/figure.mjs`), 실제 화면은 번호 표식을 얹은 캡처(`assets/shot.mjs`), 견주기는 표, 「A 면 B」는 흐름도, 분포는 막대 차트. 글은 그 옆 3줄. 도판은 `references/readability.md` 의 규칙표(R1~R10)를 `figure.mjs` 로 통과시킨다 — 글자 17/15px·행간 1.4·뜻 색 3·그림 안 문장 0·무손실. **글 층도 같은 문서의 R11** — 한 문장 60자(한 줄은 45자)·표 칸 20자(5열 이상 12자)·캡션 60자·괄호 문장당 1·숫자 나열은 표 행. 렌더러 dry_run 과 로컬 `render.py` 가 ⚠ 로 센다. 9/10 「도판은 좋아졌는데 가독성은 아직」 반려 |
+| 5 | **판단 요청** | 요청은 **고객이 고를 물음**이다 — 제목은 물음, 본문 첫 문장은 기한과 두 길의 이름. 결과는 한눈표 **한 곳에만**, 열은 「항 · 지금 · 그대로 두면 · 바꾸면」으로 **대칭**. 6항 이상이면 관문 흐름도(정하면 어느 길로)를 곁에 둔다. 권고 열·시한 칩·한 길의 결과만 있는 열은 쓰지 않고 `priority:"must"` 도 쓰지 않는다. **화면 변화**(팝업·안내·칸의 유무)가 따르면 글과 표만으로 묻지 않고 **고객 디자인 시스템 규격의 도안**을 붙여 결재를 청한다 — `references/visual-first.md` 「화면 도안」 절. 집행자: 기한은 `gazette.py` ⚠(`doc_type` 에 「브리핑」), 권고 낱말은 `gazette.py` ⚠ W1(카피 게이트 표), 도안 유무는 없음 — 사람의 눈(`references/process.md` 7단계 표) |
+| 5a | **원본 확인** | 주장·그림마다 **원본 이름 · 쪽(행) · 찾을 낱말**과 「건 §n.n」을 적는다. 「흐리다」「못 연다」고 쓰기 전에 **잰다** — PDF 는 `pdfimages -list` 전체, 웹은 실제로 열어 찾는다. 고객이 운영에서 **실제로 누를 수 있는 링크**만 근거로 친다 — 건 `source_url`, 그리고 글자 안의 맨 주소·`[글자](주소)`(도판 출처 줄 `source_text` 포함). 집행자: `references/reader-review.workflow.js` 「원본 대조」 관점(7행) · 도판 출처 줄은 `gazette.py` ⚠ W2 — 그 밖은 없음, 사람의 눈 |
+| 6 | **표기** | 인라인 표기(`**굵게**`·`==강조==`·`{{ok|칩}}`·`[글자](주소)`·**맨 주소**)와 절·PART 의 `tone`, 차트 행 `tone`, 건의 `source_url`, 요약면 `notice.state`. 색은 뜻으로(`lim-portal-format.md` §11-6) |
+| 7 | **독자 검토** | 발행 전 `references/reader-review.workflow.js` 로 다섯 관점(처음 읽는 사람·결정권자·정보 디자이너·원본 대조·구조) 검토를 돌리고 상위 발견을 반영한다. **구조 발견(PART·절 합치기·빼기)을 먼저** 반영한다 — 문장·표를 더하는 처방이 절 구성보다 앞서면 겹침이 커진다(2026-09-12 실측: 처방 반영 뒤 PART 사이에 다시 선 시각표 행 8→12) |
+| 8 | **실물 확인** | 발행 뒤 열람 주소를 열어 그림·표·칩이 섰는지 캡처로 본다. dry_run 경고 0 이 목표 |
+
+상세와 도판 예산(장당 80KB · 합계 400KB), 그림 만드는 법, 반려 사례는 `references/visual-first.md`.
+
 ## 워크플로우
 
 ### 1. 자료 모으기 → `cases.json`
@@ -226,9 +261,9 @@ Lim 보고서, Lim 에 올려줘, 고객 보고서, 수정 내역, 검수 요청
 
 「결정한다」 모드의 요약 4칸은 다르다 — 결정권자가 첫 화면에서 yes/no 를 고를 수 있어야 한다.
 
-1. 무엇을 **언제까지** 결정해야 하는가
+1. 무엇을 **언제까지** 결정해야 하는가 — 「무엇을 언제까지」 그 한 줄은 요약면 현황 줄(`notice`)의 몫이다
 2. 검토한 선택지와 각각의 편익·비용·불확실성
-3. 우리 권고와 그 근거의 등급·성숙도
+3. **확인한 사실과 근거 등급**(권고 없음 — FCG 의견은 별도 절 한 자리)
 4. 결정 뒤 이어지는 것(누가·무엇을·언제)
 
 그리고 **절마다 여백 주석 세 줄**을 쓴다. 이것이 안 채워지면 두 단 본문이 한 단으로
@@ -255,6 +290,8 @@ report.json + cases.json 을 하나로 합쳐 `publish_report` 에 준다
 서버가 렌더하므로 **HTML 을 만들지 않는다.**
 
 **`dry_run: true` 로 먼저 태우고 `warnings` 를 읽는다.** 그것이 실질적 유일한 품질 관문이다.
+단 **구조는 세지 않는다** — PART·절 사이에서 같은 사실을 다시 푸는 되풀이를 재는 경고는 렌더러에도 서버에도 없다.
+경고 0 은 구조 통과가 아니다. 그 몫은 독자 검토 「구조」 관점과 사람의 눈(`references/process.md` 7단계 「PART 간지」 행)이다.
 서버는 「빈 칸」을 안 막는다 — 막는 것은 **조용히 사라지는 것**뿐이고, 관보의 본체가
 빠지면 ⚠ 로 소리 내어 센다. `marg` 가 비었다는 경고를 못 보고 넘기면 두 단이 한 단으로 선다.
 
@@ -328,7 +365,8 @@ render·css·폰트를 함께 얹는다. 직접 부르면 옛 서식 시트가
 | `assets/render.py` | `report.json` → 단일 HTML. **서버 등록부에서 서식을 읽어** 레포 `private/builder/build.py` 를 부른다 — 여기 사본을 두지 마라 |
 | `assets/subset_font.py` | 폰트 서브셋 생성 (보통 실행 불필요) |
 | `assets/example/report.json` · `cases.json` | 관보 필드를 전부 채운 본보기. 새 문서는 여기서 베낀다 |
-| `assets/example/report-briefing.json` · `cases-briefing.json` | 「결정한다(R&D 브리핑)」 모드 본보기 — 옵션 표 8열·기한 있는 권고·하지 않기로 한 것·활용 계획 |
+| `assets/figure.mjs` · `shot.mjs` · `mockshot.mjs` | 도판 도구 — 개념도를 굽고 가독성 관문을 잰다(`figure.mjs`) · 웹 화면을 번호 표식과 함께 찍는다(`shot.mjs`) · 고객 앱 화면 도안을 2배 밀도로 찍는다(`mockshot.mjs`, `references/visual-first.md` 「화면 도안」) |
+| `assets/example/report-briefing.json` · `cases-briefing.json` | 「결정한다(R&D 브리핑)」 모드 본보기 — 물음 제목 · 두 길 대칭 한눈표 · 선택지 전치 행렬 · FCG 의견 표 한 장 · 바꾸는 길의 위험 · 고른 길별 일정 · `cta` 기본 `[]` |
 | 폰트 | **레포** `private/builder/fonts/pretendard-gazette.woff2` — 가변 1면 |
 
 **스킬에는 렌더러도 스타일시트도 검사기도 없다.** 셋 다 레포와 `gazette-report` 스킬에 있고,
@@ -350,36 +388,56 @@ render·css·폰트를 함께 얹는다. 직접 부르면 옛 서식 시트가
    활용법(`guide`)에 한 줄 둘 수 있다. 절 `lede`·본문 문단·표 주석·건·요청에는 두지 않는다.
    실측(2026-09-01): 3차 회차 문서에서 절 셋·문단 둘·건 하나·요청 하나, **일곱 자리**에 샜다.
    위 3번 규칙이 이미 있었으나 예시가 배포·티켓·테스트뿐이라 이 형태가 빠져나갔다.
+   **회차 낱말만이 아니다 — 진행 상태 어휘와 구조도 금한다.** 「정해짐 · 회신 대기 · 남은 물음 · 정해진 것 · N판」,
+   상태 열(「상태: 정해짐/회신 대기」), 개수로 상태를 세는 표 제목(「정해진 것 셋과 남은 것 하나」),
+   「~ 그대로(변화 없음)」. 독자는 앞 회차·회신·판을 모른다. 정해진 것은 **사실**로 요지(배경)에 적고,
+   결정 요청 절에는 **지금 열린 것만** 둔다. 회차의 자리는 `history` 하나. 원고는 직전 판의 차분이 아니라
+   **독자의 0 상태에서 다시 쓴다** — 판마다 「처음 읽는 사람이 이 절에서 무엇을 알아야 하나」를 다시 묻는다.
+   집행자: `gazette.py` `text_scan()` 과정 어휘 ⚠(2026-09-11 추가, `tests/builder.test.py` 시험 3건) ·
+   `references/readability.md` R11h. 상태 열·「그대로(변화 없음)」는 기계가 못 본다 — 사람의 눈.
+   까닭 — 실사례(2026-09-11, 고객사 결정 브리핑): 사용자 결정을 판마다 차분으로 반영하다 1절이
+   「정해진 것 셋과 남은 것 하나」 상태판이 됐음. 「뒷 내용을 나는 알고 너는 알아도, 독자는 모름. 이해관계자 입장 고려 안 해?」
 4. **확인 못 한 범위를 반드시 적는다.** 감추면 다음 보고서까지 못 믿게 된다.
-5. **개조식으로 쓴다 — 우리 행위에.** `~함 / ~했음 / ~필요 / ~한 상황`. 본문에
-   `습니다|십시오|합니다|입니다|됩니다|주세요` 가 0건이어야 한다. 문체를 안 바꾸면
-   관보 문법 위에서 겉돈다 — 낱말이 아니라 **조판**의 문제다.
-5a. **상대의 행위에는 높임 어간을 살린다.** 5번을 상대에게 적용하면 명령형이 된다 —
-   개조식은 「우리가 한 일」을 적는 문체이지 부탁하는 문체가 아니다. 실제 공문도 본문은
-   개조식이되 요청부는 존대로 맺는다.
+5. **개조식은 「우리가 한 일」에만 쓴다.** `~함 / ~했음 / ~임`.
+   그 자리는 우리·사물이 주어인 **기록 자리**다 — `cases` 의 증상·원인·조치·확인 방법,
+   `summary`, 절 도입문·여백 주석, `status` 대조표, 부록, 판권지의 사실 서술.
+   **여기서만** `습니다|십시오|합니다|입니다|됩니다|주세요` 가 0건이어야 한다.
+5a. **상대에게 말 거는 자리는 하십시오체로 맺는다.** 종결까지 존댓말이어야 한다.
+   그 자리는 요청 절(`cta`·`open_items`)·PART I 간지·판권지의 회신 안내다.
 
    | 상대가 할 일 | 쓰지 않는다 | 쓴다 |
    |---|---|---|
-   | 제목 | ~해 주셔야 함 · ~ 확인 필요 · **서술문 제목** | **~ 요청** + 기한 괄호(명사형이 공문 표준) |
-   | 회신 청함 | 회신 필요. · **회신 주시면 됨.** | 회신 **부탁드림** · 표시해 회신 주시면 **반영하겠음** |
-   | 확인 청함 | ~인지 확인. · 설치해 확인하면 됨. | 의견을 **부탁드림** · 보시면 **확인됨** |
-   | 값을 정해 달라 함 | 네 글자로 지정 — 반영함 | 네 글자로 정해 **주시면 반영하겠음** |
-   | 우리가 아쉬운 요청 | **동의해 주시면 됨.** | 동의 여부를 **요청드림** |
-
-   `-시-` 는 금지 어휘가 아니라서 **개조식을 깨지 않고** 정중해진다.
-
-   ⚠ **`-시-` 만으로는 부족하다 — 이 규칙의 두 번째 반려**(2026-09-03, 보고서 #112).
-   「① 계약 기간을 10월 30일까지 연장하는 것에 동의해 주시면 됨」이 **「이런 말투 존나 싸가지
-   없지 않아? 전반적으로 말장난하는 어투네?」**로 반려됐다. `-시-` 를 살려도 **「됨」은 사실
-   통보의 종결**이라, 고객이 주어인 문장에 붙으면 「그것만 하면 된다」는 지시가 되고 —
-   특히 우리가 아쉬워서 드리는 요청(계약 연장·매장 협조)에서 어긋난다. 같은 종결이 문서
-   전체에 반복되면 문체가 아니라 말버릇으로 읽힌다(반려 문구의 「말장난하는 어투」).
-   **갈리는 자리는 종결 어미가 아니라 문장의 주어다** — 주어가 우리면 개조식, 주어가 고객이면
-   요청형(요청드림·부탁드림·정해 주시면 반영하겠음·보시면 확인됨). 「~하시면 됨」은 고객이
-   **이미 하기로 한 절차의 안내**에만 남기고 새로 부탁하는 자리에는 쓰지 않는다.
-   정본은 genetics 결정문
-   `decisions/고객-문서-어투-상대가-주어인-문장은-요청드림-부탁드림으로-맺는다.md`(hnl) —
+   | 제목 | ~해 주셔야 함 · ~ 확인 필요 · 서술문 제목 · ~하시겠습니까? | 검수·보고 문서의 확인 요청은 **~ 요청** + 기한 괄호(명사형이 공문 표준). 결정 문서의 판단 항목은 **물음**(「…할 것인가」)이고 기한은 본문 첫 문장(0.5단계 5행) |
+   | 회신 청함 | 회신 필요 · 회신 주시면 됨 · 회신 부탁드**림** | 회신 **부탁드립니다** · 회신 주시면 그대로 **반영하겠습니다** |
+   | 확인 청함 | ~인지 확인 · 설치해 확인하면 됨 · 의견을 부탁드**림** | 확인해 **주시기 바랍니다** · 의견 **부탁드립니다** |
+   | 값을 정해 달라 함 | 네 글자로 지정 — 반영함 | 네 글자로 정해 주시면 **반영하겠습니다** |
+   | 우리가 아쉬운 요청 | 동의해 주시면 됨 · 동의 여부를 요청드**림** | 동의 여부를 **회신해 주시기 바랍니다** |
+
+   ⚠ **명사형 종결(`-ㅁ/-음`)은 존댓말이 아니다.** 한국어 상대높임법은 **종결어미**가 담당하는데
+   (하십시오체·해요체·하오체·하게체·해체·해라체), 명사형 종결은 그 등급 체계 **밖**이라
+   청자 높임이 0 이다. 중립이 아니라 **기록체**이고, 사람에게 직접 말하는 자리에 쓰면
+   하대로 읽힌다. 그래서 겸양 어간 `-드리-` 가 든 「부탁드림」도 존대가 아니다.
+
+   ⚠ **이 규칙은 네 번 반려당하고서야 고쳐졌다.** 앞의 세 처방이 모두 종결을 못 건드린 채
+   어휘만 갈았기 때문이다. 같은 실수를 반복하지 않도록 경위를 남긴다.
+
+   | 회차 | 나간 글자 | 고객 반응 | 당시 처방 |
+   |---|---|---|---|
+   | 2026-09-02 #32 | ~해 주셔야 함 · 회신 필요 | 이거 너무 싸가지없는 거 아니야? | `-시-` 되살리기 |
+   | 2026-09-03 #112 | 동의해 주시면 됨 | 이런 말투 존나 싸가지 없지 않아? | 「부탁드림」으로 교체 |
+   | 2026-09-03 #112 | 보고 칸의 요청문 | 보고와 요청의 차이를 잘 모르는거야? | 요청문은 요청 절에만 |
+   | 2026-09-11 #176 | 부탁드**림** · 진행하겠**음** | 존나 마음에 안듦 · 관보가 원래 이런말투임? | **종결을 하십시오체로** |
+
+   네 번째 반려가 겨눈 것은 **2·3차 처방 그 자체**였다. 종결을 못 바꾼 이유는
+   「톤 게이트가 `습니다` 를 세므로 이쪽은 바꿀 수 없다」는 전제였는데 **그 전제가 틀렸다** —
+   게이트는 경고이지 거절이 아니다(위 「Lim 발행 규칙」).
+
+   ⚠ **관형 명사구는 고치지 마라** — 「회신이 필요한 것은 4가지임」의 주어는 「것」이라
+   이름이지 명령이 아니다. 「자격이 필요함」처럼 주어가 사물인 「필요」도 그대로 둔다.
+   여기까지 높이면 표지 통계·색인 라벨이 말을 거는 문장이 되어 오히려 어색해진다.
+   정본은 genetics 결정문 `decisions/고객-문서-요청-자리는-하십시오체로-맺는다-명사형-종결은-하대로-읽힌다.md`(hnl) —
    이 스킬은 패키지로 덮어써지므로 여기 적은 것은 사본이다.
+   앞 결정문 `…상대가-주어인-문장은-요청드림-부탁드림으로-맺는다.md` 는 **뒤집혔다**.
 
    ⚠ **보고 칸에 요청문을 두지 마라 — 세 번째 반려**(2026-09-03 저녁, 같은 보고서).
    건의 `how_to_check`·`fix`·`remaining`, 절 `paragraphs`, `summary` 는 **보고 자리**다.
@@ -389,9 +447,8 @@ render·css·폰트를 함께 얹는다. 직접 부르면 옛 서식 시트가
    `open_items`·`cta` 와 PART I 간지에만 둔다. 계사 「~임」으로 끝나는 판정문
    (「순서는 다른 항목 뒤임」)도 무성의하게 읽힌다 — 우리 행위 동사로 적는다
    (「다른 항목을 마친 뒤 착수함」). 정본: genetics `decisions/고객-문서-보고-칸에는-요청문을-두지-않는다-요청은-요청-절에만.md`(hnl).
-   ⚠ **관형 명사구는 고치지 마라** — 「회신이 필요한 것은 4가지임」의 주어는 고객이 아니라
-   「것」이라 이름이지 명령이 아니다. 「자격이 필요함」처럼 주어가 사물인 「필요」도 그대로 둔다.
-   여기까지 높이면 표지 통계·색인 라벨이 말을 거는 문장이 되어 오히려 어색해진다.
+   이 규칙은 **여전히 유효하다** — 5a 와 짝이다. 5a 가 요청 자리를 하십시오체로 올리는 만큼,
+   요청문이 보고 칸으로 새면 관보가 통째로 편지가 된다. **자리를 먼저 가르고, 그 다음 문체다.**
 5b. **한글은 마침표에서 줄을 바꾼다.** 문장을 이어 붙인 한글 문단은 개조식으로 고쳐도
    여전히 기계가 쓴 글로 읽힌다. **줄만 바꾸면 부족하다** — 실측(문장 296개)에서 26%가
    글줄 폭을 넘어 접혔고 좁은 단은 54%였다. 접히면 둘째 줄과 다음 문장을 구별할 수 없다.
@@ -435,12 +492,23 @@ render·css·폰트를 함께 얹는다. 직접 부르면 옛 서식 시트가
    거절은 그 효과가 대부분 사라진다 — `references/lim-portal-format.md` §12.7b).
    - **주어는 조건**이다. 「[조건]이면 [기준] 때문에 [결과]」. 사람·조직·국가를 제외/미지원의 주어로 세우지 않는다.
    - 부정 하나에 **원인·기준·재검토 시점·선택지** 넷을 붙인다. 넷 중 하나라도 없으면 그 부정은 아직 못 쓴다.
-   - 같은 부정을 여러 절에서 되풀이하지 않는다. 「하지 않기로 한 것」 절에 한 번, 다른 절은 그 절을 가리킨다.
+   - 같은 부정을 여러 절에서 되풀이하지 않는다. 한 자리에 한 번, 다른 절은 그 자리를 가리킨다 —
+     결정권이 고객에게 있는 문서에서 그 자리는 「하지 않기로 한 것」 절이 아니라 선택지 표의 「정할 자리」·「다시 볼 때」 행이다.
    - 나쁜 소식 앞에 **상대가 이미 잘 둔 것 한 문장**. 위로가 아니라 기준점이다 — 그 다음 문장의 기준이 된다.
-   - 「해야 합니다」를 쓰지 않는다. 「권고함 — 근거는 §n.n, 대안은 §n.n」. 선택은 상대에게 둔다.
+   - 「해야 합니다」를 쓰지 않는다. **결정권이 고객에게 있는 문서에서는 「하지 않기로 함」「권고함」「기각」도 쓰지 않는다** —
+     선택은 상대에게 둔다. FCG 의견은 별도 절 한 자리에만(세 가지 독자 표·4단계).
+     실사례(2026-09-11, 고객사 결정 브리핑): 「보고서에 답정너 형식 좀 없애」.
    - 구체적인 값(지역명·회사명·제품명)은 스킬이 아니라 **그 문서의 `forbid`** 로 막는다(9번).
    기계가 잡는 것은 「조건·이유 없이 부정으로 끝난 문장」까지다(`tone.mjs` 단독 부정 종결). **주어가 사람·조직·
    국가인지는 기계가 못 본다** — 사람의 눈 검수 표에 그 행이 있다(`references/process.md` 7단계).
+   권고 낱말(제목·표 열·절 이름·여백 주석·요약면)은 `gazette.py` ⚠ W1 이 센다(카피 게이트 표).
+11. **원본을 「흐리다」「못 연다」고 쓰기 전에 잰다.** PDF 는 `pdfimages -list` 전체, 웹은 실제로 열어 찾는다 —
+   짐작으로 판정하지 않고, 못 열었으면 「미확인」이라 적는다. **인용은 원문 문구 그대로**, 위치는 절·쪽(행)까지.
+   고객이 눌러 열 수 없는 참조는 근거가 아니다(0.5단계 5a행).
+   집행자: `references/reader-review.workflow.js` 「원본 대조」 관점(발행 전 독자 검토) · 도판 출처 줄의 원본 위치 누락은
+   `gazette.py` ⚠ W2 — 그 밖은 없음, 사람의 눈.
+   실사례(2026-09-11, 고객사 결정 브리핑): 확인 없이 「원본이 흐림」이 실렸고 재보니 원본은 충분히 컸다 —
+   「고객은 직접 원본을 보고 싶은데 볼 수 없잖아」.
 
 ## 흔한 실패 모드
 
@@ -471,17 +539,22 @@ doc-pptx 의 슬롭 3종 중 **대시 대비 헤드라인**("복붙에서 위임
 |---|---|---|
 | 대시 `—` 밀도 | `tone.mjs` S2(0.5/천자) | 로컬 렌더 산출물 |
 | 「A에서 B로」 전환 공식 | **없음** — 사람의 눈 검수(`process.md` 7단계 표) | — |
-| 경어체 잔존 · 한 문장 한 줄 | `tone.mjs` S1 | 로컬 렌더 산출물 |
+| 경어체 잔존(기록 자리) · 한 문장 한 줄 | `tone.mjs` S1 — 판단 항목 본문(`p.ask__body`)과 「」 인용은 세지 않는다(5a · 11) | 로컬 렌더 산출물 |
 | 학생 보고서투 · 완충어 · 근거 없는 총평 · 단독 부정 종결 | `tone.mjs` S1/S2(2026-08-27 추가) | 로컬 렌더 산출물 |
 | 금칙 값(고객사·지역·제품명·티켓) | `build.py` `forbid` | **로컬 렌더만** — 포털 발행은 안 돈다(`report_publish.php:76`) |
-| 권고에 기한 없음 · `asks` 절 없음 · 옵션 표에 근거 등급 열 없음(브리핑) | `gazette.py` ⚠ | **두 경로 다**(dry_run·로컬) |
+| 판단 항목에 기한 없음 · `asks` 절 없음 · 선택지 표에 근거 등급 열이나 행 없음(브리핑) | `gazette.py` `brief_checks()` ⚠ | **두 경로 다**(dry_run·로컬) |
 | 본문 절의 회차 서술(「이번 회차…」) | `gazette.py` `round_talk_scan()` ⚠ | **두 경로 다**(dry_run·로컬) |
+| 본문의 진행 상태 어휘(정해짐·회신 대기·N판) · 개수로 상태를 세는 표 제목(3b) | `gazette.py` `text_scan()` 과정 어휘 ⚠(2026-09-11) | **두 경로 다**(dry_run·로컬) |
+| 권고 낱말(제목·표 열·절 이름·여백 주석·요약면) — 결정권이 고객에게 있는 문서(10번) | `gazette.py` ⚠ **W1** | **두 경로 다**(dry_run·로컬) |
+| 고객·제3자 자료에서 낸 도판(`user-provided`)의 출처 줄에 원본 위치(쪽·행·주소·건 §) 누락(11번) | `gazette.py` ⚠ **W2** | **두 경로 다**(dry_run·로컬) |
+| 확인 포기 문구(「흐리다」「못 연다」)를 원본을 재지 않고 쓴 것(11번) | **없음** — 사람의 눈(`process.md` 7단계 표 · 독자 검토 「원본 대조」 관점) | — |
 | 부정 서술의 주어가 사람·조직·국가 | **없음** — 사람의 눈 검수 | — |
+| 같은 건 묶음(요지·대조표·건)이 요청 없이 두 PART 로 갈림 · 앞 PART 가 뒤 PART 물음에 먼저 답함 · 두 절 `marg.key` 가 같은 명제(readability R12g) | 독자 검토 「구조」 관점(`references/reader-review.workflow.js`) · 사람의 눈(`references/process.md` 7단계 「PART 간지」 행) — **기계 없음** | 발행 전 |
 
 다만 **조사·체언 종결 조각문** 규칙은 보고서 문맥에서 완화한다. 목차 항목과 건 제목은
 "…던 문제", "…내역 정리"처럼 명사구로 끝나는 것이 한국어 보고서의 관례다. 슬라이드 헤드라인과
 달리 목록으로 훑는 항목이라 완전문으로 바꾸면 오히려 읽기 어렵다.
-대신 **요약의 각 리드 문장과 확인 요청의 제목은 완전문**으로 쓴다 — 여기가 판단이 일어나는 자리다.
+대신 **요약의 각 리드 문장은 완전문**, 확인 요청의 제목은 「~ 요청」, 결정 문서 판단 항목의 제목은 **물음**으로 쓴다 — 여기가 판단이 일어나는 자리다.
 
 ## 폰트
 

package/skills/genetics-report/assets/example/cases-briefing.json

@@ -11,21 +11,21 @@
   },
   {
     "group": "evidence",
-    "title": "도입·운영 비용이 편익을 넘지 않는가",
+    "title": "도입·운영 비용은 얼마나 드는가",
     "grade": "실데이터 대조",
-    "symptom": "방식 A 를 붙이면 달마다 얼마가 더 들고, 그 값이 편익과 견줄 만한가?",
+    "symptom": "방식 A 를 붙이면 달마다 얼마가 더 들고, 사용량이 늘면 어떻게 되는가?",
     "cause": "석 달치 실제 사용량으로 비용을 셈함. 현행 대비 월 운영비가 약 1.4배. 사용량이 두 배로 늘면 격차가 1.6배까지 벌어짐.",
-    "fix": "지금 사용량에서는 감내할 수 있는 폭임. 사용량 급증 구간의 상한은 계약 조건으로 눌러 두는 것이 안전함.",
+    "fix": "지금 사용량에서의 격차는 1.4배임. 격차가 커지는 급증 구간은 계약의 사용량 상한 조항으로 줄일 수 있음.",
     "how_to_check": "부록 4의 산식에 최신 월 사용량을 넣으면 같은 배수가 나옴.",
     "remaining": "내년 사용량 전망치는 추정임. 분기마다 실측으로 갱신 필요."
   },
   {
     "group": "evidence",
-    "title": "방식 B 를 기각한 판단이 지금도 유효한가",
+    "title": "방식 B 는 우리 자료 규모에서 같은 이득을 내는가",
     "grade": "문헌·타사 사례",
     "symptom": "더 싼 방식 B 로도 같은 이득을 얻을 수 있지 않은가?",
     "cause": "타사 공개 사례 6건을 대조함. 방식 B 는 자료가 백만 건을 넘는 곳에서 정확도가 급락한 사례가 4건.",
-    "fix": "우리 자료 규모가 그 문턱을 이미 넘어 방식 B 는 지금 규모에서 부적합함. 규모가 줄면 다시 볼 수 있음.",
+    "fix": "우리 자료 규모는 그 문턱을 이미 넘었음. 규모가 절반 아래로 줄면 사례의 조건과 달라짐.",
     "how_to_check": "부록 4에 사례 6건의 출처와 규모·정확도 수치를 적어 둠. 같은 표로 대조 가능함.",
     "remaining": "타사 사례라 우리 자료 특성과의 차이는 남음. 직접 실험은 하지 않음(근거 등급이 한 단 낮은 이유임)."
   }