genetics-mcp 2.14.0 → 2.16.0

package/skills/genetics-report/SKILL.md

@@ -2,13 +2,15 @@
 name: genetics-report
 description: |
   Lim 문서 포털(cs.lim.software)에 발행하거나 단일 HTML 로 전달하는 고객 문서를 만듭니다 —
-  수정 내역 보고, 검수 요청, 진행 현황, 장애 사후 보고, 납품 보고, 기술보고서·인수인계.
+  수정 내역 보고, 검수 요청, 진행 현황, 장애 사후 보고, 납품 보고, 기술보고서·인수인계,
+  R&D 브리핑·기술 도입 검토·결정 요청서.
   다음과 같은 요청 시 사용하세요:
   - "이번에 고친 것들 고객사에 보낼 보고서로 정리해줘" / "Lim 에 보고서 올려줘"
   - "수정 내역을 케이스별로 정리해서 문서로 만들어줘"
   - "고객이 우리가 뭘 했는지 모른다, 정리해서 보내야 한다"
   - "검수 요청 문서 만들어줘" / "장애 사후 보고서 / 릴리스 노트를 고객용으로"
   - "기술보고서/인수인계/온보딩 문서/포스트모템 만들어줘" (→ PART 구성으로 푼다)
+  - "조사한 걸 정리해서 할지 말지 정하게 해줘" / "R&D 브리핑 / 기술 도입 검토서 / 결정 요청서" (→ 결정한다 모드)
   내용 설계(독자 정의 → 등급 → 고객 언어 치환 → 개조식 전환)가 본체이고, 전달은 둘 중 하나입니다:
   Lim MCP 발행(서버 렌더, 링크 공유) 또는 단일 HTML(같은 관보 서식·폰트 임베드).
   서식은 **한국 정부간행물(관보) 문서 문법**입니다 — 표지·발행 이력·차례·활용법·요약·PART 간지·
@@ -74,6 +76,7 @@ version: "4.0.0"
 - `sections[].kind` 는 `summary|status|cases|asks|note` 다섯 가지뿐 — 그 밖의 값은 절이 통째로 사라지므로 서버가 거절한다.
 - `cases[].grade` 는 `grades` 에 정의된 이름이어야 한다.
 - **`update_report` 는 같은 주소를 덮어쓴다** — 이미 고객에게 나간 링크가 새 내용을 가리키므로, 발행 후 수정은 재발행이 아니라 update 로 한다. 기존 문서는 `list_reports`/`get_report` 로 받아 고쳐 되돌려 보낸다.
+  - **그림 계약**: `update_report` 에서 `assets` 를 **빼고** 보내면 서버가 저장된 그림을 그대로 유지한다. 전부 지우려면 `assets: []` 를 명시하고 `sections[].plates`·`chapters[].asset` 에서도 그 id 를 빼야 한다 — 가리키는 곳이 없는 id 는 422. 한 장만 바꾸려면 그 id 에 새 `source`/`file`, 나머지는 `get_report` 가 준 표식 그대로.
 - 초안 상태로 올려 두고 다듬어도 된다(발행이 막히지 않는다). 단, 고객에게 링크를 보내기 전에 완성할 것.
 - 내용 설계 규칙(아래 0~2단계, 고객 언어 치환, 카피 게이트)은 **전달 경로와 무관하게 동일하게** 적용된다 — 서버가 렌더한다고 해서 원고 품질 단계를 건너뛰지 않는다.
 
@@ -87,7 +90,7 @@ version: "4.0.0"
 | 고객본 / 내부본 분리 | 내부 메모를 남겨 두고도 고객본에서는 빠진 채로 내보낸다 |
 | 조판 검사 8종 통과 필수 | 대비 미달·빠진 블록·용어 유출은 **눈으로 못 잡는다** |
 
-## 두 가지 독자 — 뼈대는 하나다
+## 세 가지 독자 — 뼈대는 하나다
 
 서식은 하나뿐이므로 **뼈대를 바꾸지 않는다.** 바뀌는 것은 PART 를 무엇으로 가르느냐다.
 
@@ -95,6 +98,12 @@ version: "4.0.0"
 |---|---|---|
 | 판정한다 (검수·회신·결재) | 요청 / 경과 / 잔여 | `asks` → `summary` → `status` → `cases` → `note` |
 | **배운다** (유지보수·인수·온보딩·사후분석) | 원리 / 붕괴와 처방 / 적용과 남은 것 | 같은 다섯 kind 를 그 순서로 쓴다 |
+| **결정한다** (도입 여부·옵션 선택·예산·일정) | 결정 / 근거 / 이행 | `asks` → `summary` → `status` → `cases` → `note`(하지 않기로 한 것) → `note`(리스크) → `note`(활용 계획) |
+
+**결정 문서와 R&D 블로그 글은 다른 물건이다.** 블로그 글은 「이런 걸 해 봤고 이런 걸 배웠다」로 끝나고 독자가
+할 일이 없다. 브리핑은 **결정 요청(무엇을 언제까지)·복수의 선택지(기각안 포함)·근거 등급·성숙도·기한**이
+추가된다 — 이 다섯이 없으면 문서가 아무리 두꺼워도 블로그 글이다. 정부 R&D 최종보고서·군 결정문(BLUF)·
+영국 정부 Submissions 가 공통으로 요구하는 것이 이 다섯이다(`references/lim-portal-format.md` §12.7b).
 
 `kind:"lesson"` 같은 것은 **없다.** 서버가 발행 단계에서 거절한다.
 가르치는 문서도 다섯 kind 로 푼다 — 자세한 것은 `references/lim-portal-format.md` §12.
@@ -107,7 +116,8 @@ version: "4.0.0"
 
 Lim 보고서, Lim 에 올려줘, 고객 보고서, 수정 내역, 검수 요청, 처리 현황, 릴리스 노트,
 사후 보고, 납품 보고, QC 보고, 이슈 정리, 대응 결과, 제안서 수준 문서, **기술보고서,
-인수인계, 온보딩 문서, 포스트모템, "다음 사람이 읽고 이해해야 하는 문서"**
+인수인계, 온보딩 문서, 포스트모템, "다음 사람이 읽고 이해해야 하는 문서"**,
+**R&D 브리핑, 기술 도입 검토, 타당성 검토, 결정 요청서, "할지 말지 정해야 하는 문서"**
 
 ---
 
@@ -119,6 +129,8 @@ Lim 보고서, Lim 에 올려줘, 고객 보고서, 수정 내역, 검수 요청
 
 1. **이 문서를 누가 읽는가** — 고객사 검수 담당? 결정권자? 실무 매장 인원?
 2. **읽고 나서 무엇을 해야 하는가** — 확인만? 판단해서 회신? 결재?
+3. **읽고 나서 무엇을 결정하는가** — 선택지는 무엇이고, 우리 권고는 무엇이며, **언제까지** 정해야 하는가.
+   (「결정한다」 모드에서는 필수. 답이 「특별히 결정할 것은 없다」면 그 문서는 브리핑이 아니라 보고다.)
 
 독자가 정해지면 나머지가 전부 따라 정해진다. 같은 사실이 이렇게 갈린다.
 
@@ -205,6 +217,13 @@ Lim 보고서, Lim 에 올려줘, 고객 보고서, 수정 내역, 검수 요청
 3. 여러 건을 관통하는 공통 원인
 4. 상대가 무엇을 하면 되는가
 
+「결정한다」 모드의 요약 4칸은 다르다 — 결정권자가 첫 화면에서 yes/no 를 고를 수 있어야 한다.
+
+1. 무엇을 **언제까지** 결정해야 하는가
+2. 검토한 선택지와 각각의 편익·비용·불확실성
+3. 우리 권고와 그 근거의 등급·성숙도
+4. 결정 뒤 이어지는 것(누가·무엇을·언제)
+
 그리고 **절마다 여백 주석 세 줄**을 쓴다. 이것이 안 채워지면 두 단 본문이 한 단으로
 서고, 문서는 「문서처럼 꾸민 웹페이지」로 되돌아간다.
 
@@ -236,6 +255,7 @@ report.json + cases.json 을 하나로 합쳐 `publish_report` 에 준다
 확인한 뒤 `release_report(id)` 로 연다 — 그것이 사람의 승인 행위다.
 
 수정은 `get_report` → 데이터 수정 → `update_report` — **같은 링크가 새 내용을 가리킨다.**
+그림은 서버가 보관한다 — `assets` 를 빼고 보내면 유지, `assets: []` 면 삭제(plates 에서도 빼야 422 가 안 난다), 바꿀 장만 새 `source`/`file`.
 
 ### 5-1. 발행 뒤 판정 — 블록 목록으로 본다
 
@@ -280,7 +300,7 @@ render·css·폰트를 함께 얹는다. 직접 부르면 옛 서식 시트가
 |---|---|
 | `kcheck.mjs` | 대비(알파·조상 opacity 합성) · 제목 레벨 · 표 접근명 · 앵커 · 7폭 넘침 |
 | `read.mjs` | 한글 자폭 실측 글자/줄 · 행간 · 본문 대비 |
-| `tone.mjs` | 경어체 잔존 · 늘어짐 지표 · **한 문장 한 줄** |
+| `tone.mjs` | 경어체 잔존 · 늘어짐 지표 · **한 문장 한 줄** · 문체 유형 4종(학생 보고서투·완충어·근거 없는 총평·단독 부정 종결) |
 | `fontchk.mjs` | 렌더된 활자 크기·굵기 분포 |
 | `flexcheck.mjs` | flex/grid 안에서 문장이 토막 나는 곳 |
 | `cssaudit.sh` | 활자 스케일 · 간격 격자 · 표 마감 · 미봉책 |
@@ -301,6 +321,7 @@ 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열·기한 있는 권고·하지 않기로 한 것·활용 계획 |
 | 폰트 | **레포** `private/builder/fonts/pretendard-gazette.woff2` — 가변 1면 |
 
 **스킬에는 렌더러도 스타일시트도 검사기도 없다.** 셋 다 레포와 `gazette-report` 스킬에 있고,
@@ -356,6 +377,18 @@ render·css·폰트를 함께 얹는다. 직접 부르면 옛 서식 시트가
    실패 사례(2026-08-17): 스킬 표에 체중계·팔근육 같은 특정 업종 아이콘을 적어 두었고,
    검수기에는 그 테넌트의 강조색 hex 를 상수로 박아 두었다. 강조색이 다른 테넌트에서
    **전량 오판정**했다. 스킬에 값을 박으면 다음 고객에서 터진다.
+10. **부정 서술은 조건을 주어로 세우고, 한 절에서 한 번만 말한다.** 「할 수 없다·제외된다·지원하지
+   않는다」로 문장을 끝내지 않는다 — 그 문장은 독자에게 「당신은 못 한다」로 읽히고, 이유·기준·다음이
+   없으면 배제 통보가 된다(사회적 배제 연구의 귀결: 이유 없는 거절은 통제감·소속감을 깎고, 이유가 붙은
+   거절은 그 효과가 대부분 사라진다 — `references/lim-portal-format.md` §12.7b).
+   - **주어는 조건**이다. 「[조건]이면 [기준] 때문에 [결과]」. 사람·조직·국가를 제외/미지원의 주어로 세우지 않는다.
+   - 부정 하나에 **원인·기준·재검토 시점·선택지** 넷을 붙인다. 넷 중 하나라도 없으면 그 부정은 아직 못 쓴다.
+   - 같은 부정을 여러 절에서 되풀이하지 않는다. 「하지 않기로 한 것」 절에 한 번, 다른 절은 그 절을 가리킨다.
+   - 나쁜 소식 앞에 **상대가 이미 잘 둔 것 한 문장**. 위로가 아니라 기준점이다 — 그 다음 문장의 기준이 된다.
+   - 「해야 합니다」를 쓰지 않는다. 「권고함 — 근거는 §n.n, 대안은 §n.n」. 선택은 상대에게 둔다.
+   - 구체적인 값(지역명·회사명·제품명)은 스킬이 아니라 **그 문서의 `forbid`** 로 막는다(9번).
+   기계가 잡는 것은 「조건·이유 없이 부정으로 끝난 문장」까지다(`tone.mjs` 단독 부정 종결). **주어가 사람·조직·
+   국가인지는 기계가 못 본다** — 사람의 눈 검수 표에 그 행이 있다(`references/process.md` 7단계).
 
 ## 흔한 실패 모드
 
@@ -373,10 +406,24 @@ render·css·폰트를 함께 얹는다. 직접 부르면 옛 서식 시트가
 | 검사기가 전부 초록인데 문서가 허옇다 | `build.py` 를 직접 불러 **스타일시트가 안 실렸다.** 색이 없으니 대비가 자동 통과 | `render.py` 를 쓴다. 0표본 통과를 통과로 읽지 않는다 |
 | 문장이 이어 붙어 기계 글로 읽힌다 | 개조식으로 바꿔도 조판이 그대로 | 한글은 **한 문장 한 줄**. `gazette-report` 의 `sentbreak.py --apply` |
 
-## 카피 게이트
+## 카피 게이트 — 규칙마다 집행자를 적는다
 
 doc-pptx 의 슬롭 3종 중 **대시 대비 헤드라인**("복붙에서 위임으로 — 목표만 주면")과
-**"A에서 B로" 전환 공식**은 이 문서에서도 그대로 금지다. 검수기가 잡는다.
+**"A에서 B로" 전환 공식**은 이 문서에서도 그대로 금지다.
+
+**집행자가 없는 규칙은 규칙이 아니다.** 이 절은 2026-08-27 까지 「검수기가 잡는다」 한 줄로 끝났는데,
+그 검수기(`qa.py`)는 폐기됐고 남은 `tone.mjs` 는 대시 밀도만 셌다 — 넉 달 동안 아무도 「A에서 B로」를
+기계로 잡지 않았다. 규칙마다 누가 잡는지를 적고, **없으면 없음이라고 적는다**(`references/qa.md`).
+
+| 규칙 | 집행자 | 어느 경로에서 |
+|---|---|---|
+| 대시 `—` 밀도 | `tone.mjs` S2(0.5/천자) | 로컬 렌더 산출물 |
+| 「A에서 B로」 전환 공식 | **없음** — 사람의 눈 검수(`process.md` 7단계 표) | — |
+| 경어체 잔존 · 한 문장 한 줄 | `tone.mjs` S1 | 로컬 렌더 산출물 |
+| 학생 보고서투 · 완충어 · 근거 없는 총평 · 단독 부정 종결 | `tone.mjs` S1/S2(2026-08-27 추가) | 로컬 렌더 산출물 |
+| 금칙 값(고객사·지역·제품명·티켓) | `build.py` `forbid` | **로컬 렌더만** — 포털 발행은 안 돈다(`report_publish.php:76`) |
+| 권고에 기한 없음 · `asks` 절 없음 · 옵션 표에 근거 등급 열 없음(브리핑) | `gazette.py` ⚠ | **두 경로 다**(dry_run·로컬) |
+| 부정 서술의 주어가 사람·조직·국가 | **없음** — 사람의 눈 검수 | — |
 
 다만 **조사·체언 종결 조각문** 규칙은 보고서 문맥에서 완화한다. 목차 항목과 건 제목은
 "…던 문제", "…내역 정리"처럼 명사구로 끝나는 것이 한국어 보고서의 관례다. 슬라이드 헤드라인과

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

@@ -0,0 +1,32 @@
+[
+  {
+    "group": "evidence",
+    "title": "방식 A 가 현행보다 찾는 정확도를 올리는가",
+    "grade": "직접 실험 확인",
+    "symptom": "같은 질문 묶음에서 방식 A 가 현행보다 원하는 자료를 더 자주 찾아 주는가?",
+    "cause": "실제 질문 200개를 두 방식에 같이 태움. 첫 화면 안에서 답을 찾은 비율이 현행 61%, 방식 A 82%.",
+    "fix": "정확도 이득은 실재함. 다만 이득의 대부분은 질문이 길고 구체적일 때 남. 한 낱말 질문에서는 차이가 작음.",
+    "how_to_check": "부록 4의 질문 묶음으로 검증 환경에서 같은 비교를 다시 돌리면 같은 구간의 수치가 나옴.",
+    "remaining": "질문 묶음이 최근 석 달치 위주라 계절성 주제는 덜 들어 있음."
+  },
+  {
+    "group": "evidence",
+    "title": "도입·운영 비용이 편익을 넘지 않는가",
+    "grade": "실데이터 대조",
+    "symptom": "방식 A 를 붙이면 달마다 얼마가 더 들고, 그 값이 편익과 견줄 만한가?",
+    "cause": "석 달치 실제 사용량으로 비용을 셈함. 현행 대비 월 운영비가 약 1.4배. 사용량이 두 배로 늘면 격차가 1.6배까지 벌어짐.",
+    "fix": "지금 사용량에서는 감내할 수 있는 폭임. 사용량 급증 구간의 상한은 계약 조건으로 눌러 두는 것이 안전함.",
+    "how_to_check": "부록 4의 산식에 최신 월 사용량을 넣으면 같은 배수가 나옴.",
+    "remaining": "내년 사용량 전망치는 추정임. 분기마다 실측으로 갱신 필요."
+  },
+  {
+    "group": "evidence",
+    "title": "방식 B 를 기각한 판단이 지금도 유효한가",
+    "grade": "문헌·타사 사례",
+    "symptom": "더 싼 방식 B 로도 같은 이득을 얻을 수 있지 않은가?",
+    "cause": "타사 공개 사례 6건을 대조함. 방식 B 는 자료가 백만 건을 넘는 곳에서 정확도가 급락한 사례가 4건.",
+    "fix": "우리 자료 규모가 그 문턱을 이미 넘어 방식 B 는 지금 규모에서 부적합함. 규모가 줄면 다시 볼 수 있음.",
+    "how_to_check": "부록 4에 사례 6건의 출처와 규모·정확도 수치를 적어 둠. 같은 표로 대조 가능함.",
+    "remaining": "타사 사례라 우리 자료 특성과의 차이는 남음. 직접 실험은 하지 않음(근거 등급이 한 단 낮은 이유임)."
+  }
+]

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

@@ -0,0 +1,271 @@
+{
+  "out": "예시-브리핑.html",
+  "cases": "cases-briefing.json",
+  "lang": "ko",
+  "doc_type": "R&D 브리핑",
+
+  "title_tag": "자료 검색 방식 도입 검토 · 예시 고객사",
+  "description": "새 검색 방식(방식 A) 도입 여부를 결정하기 위한 브리핑. 권고 1건과 근거, 하지 않기로 한 것을 정리함",
+
+  "doc_no": "LIM-2026-0827-02",
+  "client": "예시 고객사",
+  "kicker": "우리회사 · 예시 고객사",
+  "title": "자료 검색 방식 도입 검토",
+  "title_sub": "R&D 브리핑",
+  "subtitle": "새 검색 방식(방식 A)의 도입 여부를 정하기 위한 문서임. 2026년 9월 30일까지 채택 여부 회신 필요.",
+  "cover_date": "2026.08.27",
+  "issuer": ["우리회사", "예시 고객사", "2026. 8."],
+  "running_footer": "예시 고객사 · LIM-2026-0827-02",
+
+  "meta": [
+    ["검토 기간", "2026.07.01 – 08.27"],
+    ["결정 사항", "1건 (방식 A 도입 여부)"],
+    ["회신 기한", "2026년 9월 30일"],
+    ["수신", "예시 고객사 결정권자"],
+    ["작성", "2026.08.27 · 우리회사"]
+  ],
+
+  "history": [
+    { "no": 1, "date": "2026. 8. 27.", "note": "최초 발행. 두 달 검토의 결과와 권고 1건, 하지 않기로 한 것 3가지를 정리함." }
+  ],
+
+  "guide": [
+    { "q": "이 문서로 무엇을 결정하는가?",
+      "a": ["방식 A 도입 여부 하나임.", "01절의 권고에 채택 또는 반려로 회신하면 끝남.", "회신 기한은 2026년 9월 30일."] },
+    { "q": "우리 권고는 무엇인가?",
+      "a": ["방식 A 를 다음 분기에 도입하는 것을 권고함.", "근거는 04절, 검토한 다른 길은 03절과 05절에 있음."] },
+    { "q": "이 권고를 얼마나 믿어도 되는가?",
+      "a": ["핵심 근거 2건은 직접 실험과 실데이터 대조까지 확인함.", "등급의 뜻은 부록 1, 남은 불확실성은 각 건의 마지막 행."] },
+    { "q": "시간이 없다면 어디를 봐야 하는가?",
+      "a": ["이 쪽과 01·02절이면 결정에 충분함.", "그 뒤는 결정을 검증하러 올 때 읽는 자리임."] }
+  ],
+
+  "notice": { "state": "info", "text": "결정 요청 1건. 2026년 9월 30일까지 회신 필요." },
+  "bar": [
+    { "value": 1, "label": "권고안", "tone": "you" },
+    { "value": 2, "label": "검토한 다른 길", "tone": "neutral" }
+  ],
+  "bar_alt": "권고안 1건과 검토한 다른 길 2건의 분포",
+  "bar_note": "「검토한 다른 길」은 방식 B 와 현행 유지. 기각 이유는 03절 비교표와 05절에 있음.",
+  "stats": [
+    { "value": "1", "unit": "건", "label": "결정할 것", "accent": true, "href": "#sec-1", "go": "01절로" },
+    { "value": "3", "unit": "가지", "label": "검토한 선택지", "href": "#sec-3", "go": "03절로" },
+    { "value": "3", "unit": "가지", "label": "하지 않기로 한 것", "href": "#sec-5", "go": "05절로" }
+  ],
+
+  "grades": {
+    "직접 실험 확인": ["m-live", "검증 환경에서 실제로 돌려 수치까지 확인함. 가장 강한 근거."],
+    "실데이터 대조": ["m-data", "실제 사용량·자료로 셈해 확인함. 실험 재현은 미실시."],
+    "문헌·타사 사례": ["m-doc", "공개 자료와 타사 사례로 확인함. 우리 환경과의 차이는 남음."],
+    "추정": ["m-est", "산식·전망에 기댄 값임. 실측으로 갱신될 때까지 잠정."]
+  },
+
+  "labels": {
+    "symptom": "물음",
+    "cause": "관찰",
+    "fix": "판단",
+    "check": "재현 방법",
+    "ask": "남은 불확실성",
+    "cta": "결론 먼저",
+    "col_evidence": "근거 등급"
+  },
+
+  "parts": [
+    { "no": "1", "title": "결정", "tone": "you",
+      "lede": "무엇을 결정해 달라는 것인지와 그 요지. 이 PART 만으로 회신할 수 있음.",
+      "questions": ["무엇을 언제까지 결정하는가?", "권고와 그 근거의 강도는?"] },
+    { "no": "2", "title": "근거", "tone": "neutral",
+      "lede": "선택지 비교와 검증 결과, 그리고 하지 않기로 한 것.",
+      "questions": ["다른 길은 왜 아닌가?", "이 수치는 어떻게 다시 확인하는가?"] },
+    { "no": "3", "title": "이행", "tone": "wait",
+      "lede": "채택 시 따르는 위험과 결정 뒤의 일정.",
+      "questions": ["채택하면 무엇이 언제 일어나는가?", "무엇이 잘못될 수 있고 어떻게 눌러 두는가?"] }
+  ],
+
+  "groups": [
+    { "key": "evidence", "no": "4", "name": "검증한 것" }
+  ],
+
+  "sections": [
+    { "name": "결정 요청", "kind": "asks", "part": "1",
+      "lede": "회신이 필요한 권고 1건.",
+      "sub": "수신 측 결정 사항의 전부",
+      "short": "결정 요청",
+      "marg": {
+        "why": "무엇을 결정해 달라는 것인가?",
+        "key": "방식 A 도입 여부 하나. 2026년 9월 30일까지.",
+        "advice": "근거는 04절, 기각한 길은 03·05절."
+      } },
+
+    { "name": "검토 요지", "kind": "summary", "part": "1",
+      "lede": "무엇을 왜 검토했고 무엇을 권고하는지 네 문단으로.",
+      "sub": "결정권자용 요약",
+      "short": "요지",
+      "marg": {
+        "why": "두 달 검토의 결론은 무엇인가?",
+        "key": "방식 A 도입을 권고함. 핵심 근거 2건은 직접 확인함.",
+        "advice": "각 문단 끝의 절 표시가 근거의 출처."
+      } },
+
+    { "name": "선택지 비교", "kind": "status", "part": "2",
+      "lede": "검토한 세 길을 같은 축으로 견줌. 기각한 길도 여기 있음.",
+      "sub": "같은 축으로 견준 세 길",
+      "short": "선택지",
+      "tables": [
+        { "caption": "선택지 비교 — 같은 축 여덟 가지",
+          "cols": ["옵션", "편익", "해악·비용", "불확실성", "이행 장벽", "성숙도", "근거 등급", "권고 강도"],
+          "rows": [
+            ["방식 A", "찾는 정확도 61%→82%", "월 운영비 약 1.4배", "계절성 주제 미검증", "두 달 전환 작업", "상용 단계", "직접 실험 확인", "권고함"],
+            ["방식 B", "비용은 현행 수준", "자료 백만 건 초과 시 정확도 급락 사례 4건", "우리 자료와의 차이", "전환 작업은 한 달", "상용 단계", "문헌·타사 사례", "지금 규모에서는 반려 권고"],
+            ["현행 유지", "비용·작업 없음", "정확도 개선 없음", "없음", "없음", "운영 중", "직접 실험 확인", "권고하지 않음(정확도 개선 요구가 접수돼 있음)"]
+          ] }
+      ],
+      "marg": {
+        "why": "다른 길은 왜 아닌가?",
+        "key": "방식 B 는 우리 자료 규모에서 정확도가 꺾임.",
+        "advice": "각 행의 근거 등급은 부록 1 기준."
+      } },
+
+    { "name": "검증한 것", "kind": "cases", "group": "evidence", "part": "2",
+      "lede": "권고를 받치는 세 물음과 그 답. 물음·관찰·판단·재현 방법 순서로 적음.",
+      "sub": "물음 세 개와 그 답",
+      "short": "검증",
+      "marg": {
+        "why": "이 수치는 어떻게 나온 것인가?",
+        "key": "핵심 두 건은 직접 실험·실데이터로 확인함.",
+        "advice": "재현 방법 행대로 하면 같은 수치가 나옴."
+      } },
+
+    { "name": "이번 범위에서 하지 않기로 한 것", "kind": "note", "part": "2",
+      "lede": "기각·보류한 길과 그 이유, 다시 보는 시점.",
+      "sub": "기각·보류와 재검토 조건",
+      "short": "하지 않는 것",
+      "count": "3",
+      "count_unit": "가지",
+      "limit_label": "이번 범위에서 하지 않기로 한 것",
+      "paragraphs": [
+        "방식 B 도입은 이번에 하지 않기로 함. 자료가 백만 건을 넘는 규모에서 정확도가 꺾인 사례가 넷이기 때문임(§4.3). 자료 규모가 지금의 절반 아래로 줄면 다시 봄. 그때까지는 방식 A 와 현행의 두 갈래만 유지함.",
+        "전 화면 동시 전환은 하지 않기로 함. 한 화면씩 바꿔야 문제가 생겼을 때 되돌릴 곳이 분명하기 때문임. 첫 화면 안정화가 확인되는 분기에 다음 화면을 봄. 그동안 나머지 화면은 현행 그대로 둠.",
+        "검색 품질 지표의 자체 개발은 이번 범위에 넣지 않기로 함. 표준 지표로도 이번 결정에는 충분하기 때문임. 도입 뒤 첫 분기 실측에서 표준 지표가 부족하다고 판명되면 다시 봄. 그동안은 부록 4의 질문 묶음을 지표로 씀."
+      ],
+      "marg": {
+        "why": "왜 이 길들은 아닌가?",
+        "key": "각 문단에 이유와 다시 보는 시점을 함께 적음.",
+        "advice": "방식 B 의 수치 근거는 §4.3."
+      } },
+
+    { "name": "채택 시 리스크와 완화", "kind": "note", "part": "3",
+      "lede": "권고대로 했을 때 잘못될 수 있는 것과 눌러 두는 방법.",
+      "sub": "위험 · 완화 대조",
+      "short": "리스크",
+      "tables": [
+        { "caption": "리스크와 완화",
+          "cols": ["리스크", "크기", "완화", "근거 등급"],
+          "rows": [
+            ["사용량 급증으로 운영비 격차 확대", "월 1.4배가 1.6배까지", "계약에 사용량 상한 조항. 분기 실측으로 갱신", "실데이터 대조"],
+            ["계절성 주제에서 정확도 미확인", "미지(질문 묶음 밖)", "도입 첫 분기에 계절 질문 묶음으로 재실험", "추정"]
+          ] }
+      ],
+      "marg": {
+        "why": "무엇이 잘못될 수 있는가?",
+        "key": "비용 격차는 계약 조항으로 눌러 둠.",
+        "advice": "크기가 「추정」인 행은 첫 분기 실측에서 갱신."
+      } },
+
+    { "name": "결정 뒤의 일정", "kind": "note", "part": "3",
+      "lede": "채택 회신을 받으면 누가 무엇을 언제 하는지.",
+      "sub": "30일 · 90일 계획",
+      "short": "활용 계획",
+      "paragraphs": [
+        "회신 후 30일 안에 우리회사가 검증 환경을 첫 화면에 그대로 옮겨 세움. 이때 부록 4의 질문 묶음으로 도입 전후를 같은 자로 잼.",
+        "회신 후 90일 안에 첫 화면 전환을 마치고 첫 분기 실측 보고를 냄. 계절 질문 묶음 재실험이 여기 포함됨.",
+        "반려 회신이면 현행을 유지하고, 05절의 재검토 조건이 열릴 때 이 문서를 갱신해 다시 올림."
+      ],
+      "marg": {
+        "why": "채택하면 무엇이 언제 일어나는가?",
+        "key": "30일 검증 환경, 90일 첫 화면 전환과 실측 보고.",
+        "advice": "일정의 주어는 우리회사임. 수신 측 작업은 없음."
+      } }
+  ],
+
+  "summary": [
+    { "lead": "방식 A 를 다음 분기에 도입하는 것을 권고함.",
+      "body": "같은 질문 묶음에서 원하는 자료를 첫 화면 안에 찾는 비율이 61%에서 82%로 오름(§4.1). 회신 기한은 2026년 9월 30일.",
+      "refs": ["4.1"] },
+    { "lead": "비용은 월 운영비 약 1.4배로, 지금 사용량에서는 감내할 수 있는 폭임.",
+      "body": "석 달치 실사용량으로 셈함(§4.2). 사용량 급증 구간은 계약의 상한 조항으로 눌러 둠.",
+      "refs": ["4.2"] },
+    { "lead": "더 싼 방식 B 는 우리 자료 규모에서 정확도가 꺾여 기각함.",
+      "body": "자료 백만 건 초과 규모에서 급락 사례 4건(§4.3). 규모가 절반 아래로 줄면 재검토함.",
+      "refs": ["4.3"] },
+    { "lead": "결정해 달라는 것은 하나임 — 방식 A 채택 여부.",
+      "body": "채택이면 30일 안에 검증 환경, 90일 안에 첫 화면 전환(§4.2 의 비용 전제 그대로). 반려면 현행 유지함.",
+      "refs": ["4.2"] }
+  ],
+
+  "open_items": [
+    { "title": "방식 A 를 다음 분기에 도입하는 것을 권고함. 채택 여부 회신 필요.",
+      "priority": "must",
+      "body": "2026년 9월 30일까지 회신 필요. 근거는 §4.1·§4.2, 기각한 길은 §4.3 과 05절. 채택 시 30일 안에 검증 환경부터 세움.",
+      "refs": ["4.1", "4.2", "4.3"] },
+    { "title": "계약의 사용량 상한 조항 초안을 같이 검토해 주기를 요청함.",
+      "body": "회신 기한과 같은 2026년 9월 30일까지. 운영비 격차가 커지는 구간을 계약으로 눌러 두는 장치임(§4.2).",
+      "refs": ["4.2"] },
+    { "title": "계절성 주제의 질문 묶음 표본을 보내 주기를 요청함.",
+      "body": "도입 첫 분기 재실험 전(2026년 12월 이내)까지면 충분함. 지금 질문 묶음의 남은 불확실성이 여기임(§4.1).",
+      "refs": ["4.1"] }
+  ],
+
+  "cta": [
+    "결정할 것은 하나, <strong>방식 A 채택 여부</strong>. 2026년 9월 30일까지 회신 필요.",
+    "우리 권고는 채택임. 근거의 강도는 각 건의 <strong>근거 등급</strong>이 말함.",
+    "이 쪽과 01·02절만으로 결정에 충분함. 그 뒤는 검증하러 올 때 읽는 자리임."
+  ],
+
+  "appendix": [
+    { "no": "부록 1", "title": "「근거 등급」 판정 기준",
+      "rows": [
+        ["직접 실험 확인", "검증 환경에서 실제로 돌려 수치까지 확인함. 가장 강한 근거."],
+        ["실데이터 대조", "실제 사용량·자료로 셈해 확인함. 실험 재현은 미실시."],
+        ["문헌·타사 사례", "공개 자료와 타사 사례로 확인함. 우리 환경과의 차이는 남음."],
+        ["추정", "산식·전망에 기댄 값임. 실측으로 갱신될 때까지 잠정."]
+      ],
+      "note": "직접 실험이 아니면 한 단 내리고, 이해관계가 있는 출처면 또 한 단 내림. 올려 적지 않음." },
+    { "no": "부록 2", "title": "이 문서의 확률 어휘",
+      "rows": [
+        ["확실함", "실측으로 확인한 사실. 수치를 함께 적음."],
+        ["가능성 높음", "대략 10에 7 이상. 반대 사례가 나오면 본문을 고침."],
+        ["반반", "판단 유보. 결정에 쓰지 않고 재검토 조건만 적음."],
+        ["가능성 낮음", "대략 10에 3 이하. 리스크 표에서만 다룸."]
+      ],
+      "note": "본문에서 「~로 보임」 같은 흐린 표현 대신 이 네 낱말을 씀." },
+    { "no": "부록 3", "title": "「성숙도」 대응표",
+      "rows": [
+        ["연구 단계", "논문·시제품 수준. 성숙도 기준에 못 미쳐 이번 비교에서 다루지 않음."],
+        ["시험 단계", "일부 환경에서 검증됨. 파일럿으로만 도입."],
+        ["상용 단계", "여러 곳에서 운영 중. 이번 비교표의 두 방식이 여기임."],
+        ["운영 중", "우리가 이미 쓰고 있음."]
+      ] },
+    { "no": "부록 4", "title": "검증 환경과 재현 자료",
+      "rows": [
+        ["질문 묶음", "실사용 질문 200개 (2026년 5–7월). 계절성 주제는 미포함(§4.1 의 남은 불확실성)."],
+        ["비용 산식", "월 사용량 × 단가 배수. 최신 사용량을 넣으면 §4.2 의 배수가 나옴."],
+        ["타사 사례", "공개 사례 6건의 규모·정확도 대조표. §4.3 의 근거."]
+      ] }
+  ],
+
+  "colophon": {
+    "rows": [
+      ["발행", "우리회사"],
+      ["문서번호", "LIM-2026-0827-02"],
+      ["수신", "예시 고객사 결정권자"],
+      ["회신", "이 문서를 보낸 담당자에게 회신"]
+    ],
+    "mark": "이 브리핑의 수치는 2026년 8월 27일 기준이며, 권고는 2026년 9월 30일까지 유효함.",
+    "badge": "고객 공유용",
+    "note": "※ 이 문서에는 입력·저장 기능이 없음. 채택 여부는 별도 회신 필요.",
+    "tail": "회신 뒤 일정은 07절 그대로 진행하고, 첫 분기 실측 보고로 이어짐."
+  },
+
+  "forbid": ["(은|는|을|를) 제외(함|됨|했음|했다|한다|하였음|하였다)", "지원(하지|되지) 않음", "부득이", "양해 바", "가나다솔루션", "(?<!나)머지"]
+}

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

@@ -196,5 +196,5 @@
     "tail": "이후 진행 사항은 차기 회차 보고로 공유 예정."
   },
 
-  "forbid": ["티켓", "스프린트", "레포지토리", "커밋", "(?<!나)머지"]
+  "forbid": ["티켓", "스프린트", "레포지토리", "커밋", "(?<!나)머지", "(은|는|을|를) 제외(함|됨|했음|했다|한다|하였음|하였다)", "지원(하지|되지) 않음"]
 }

package/skills/genetics-report/references/content-pipeline.md

@@ -299,6 +299,11 @@ MCP 발행 스키마에도 `text_fix` 칸이 없음(`mcp/genetics.mjs`).
 | H | 한 문장 두 사실 → 두 문장 재편 | 복문 해체 | 3.3 의 문장 길이 규칙과 같은 뿌리임 | `같은 배포에 …(이전에는 잠시 남아 보임)이 함께 포함됐음` → `함께 반영된 수정이 하나 더 있음. 녹음을 삭제하면 일지 상세에서도 즉시 사라짐.` |
 | I | 내부 관용어 → 중립 어휘 | 팀 은어 정규화 | 같은 개념을 두 이름으로 부르면 독자가 **다른 것으로** 읽음 | `자동 정리 방식` → `일괄 정리 방식` |
 | J | **삭제** | 설계 검토 이력·내부 잔여 정리는 서술 대상이 아님 | 채택되지 않은 대안은 **고객의 판단·행동을 바꾸지 않음.** 문서에 남으면 「아직 안 끝났다」로만 읽힘 | `처음 검토안 중 …은 제외함` → (통째로 삭제) |
+| K | 배제·무력 서술 → **조건 주어** + 원인·기준·재검토 시점 + 선택지 | 「[누구]는 할 수 없음/제외됨」 → 「[조건]이면 [기준] 때문에 [결과]. [재검토 시점]. 그동안은 [선택지]」 | 사람·조직·지역을 주어로 세운 부정은 배제 통보로 읽힘. 이유·선택지가 붙으면 같은 사실이 판단 근거로 읽힘(lim-portal-format §12.7b) | `[지역명] 은 라이선스에서 제외됨` → `[조건]에 해당하면 [라이선스 조항] 때문에 그 경로는 쓸 수 없음. 조항이 바뀌면 재검토. 그동안은 [대안 경로]` |
+
+**경계선 둘.**
+K 는 **우리 근거의 약함을 지우라는 뜻이 아님** — 약한 근거는 등급을 달아 노출함(process.md §11 원리 3). 지우는 것은 「독자의 무력함」 서술임.
+브리핑(§12.3b)에서는 J 보다 K 가 앞섬 — 기각안은 지우지 않고 K 의 틀로 적음.
 
 **경계선 하나.**
 `별도 티켓` 은 금지, `별건`·`별도 건` 은 허용.
@@ -341,6 +346,8 @@ AssertionError: 금지 표현 유출: 조회 색인 → ['조회 색인']
 | `운영 배포` | 유형 **B** 를 빠뜨림 |
 | `별도 티켓` | 유형 **C** 를 빠뜨림 |
 | `자동 검증 \d건` | 유형 **D** 를 빠뜨림 |
+| `(은\|는\|을\|를) 제외(함\|됨\|했음\|했다\|한다\|하였음\|하였다)` · `지원(하지\|되지) 않음` | 유형 **K** 를 빠뜨림 — 조건 주어 없이 부정으로 끝난 문장(개조식 전이라 서술형 어미도 잡는다 — 8/18 반려 문구 「…을 제외했다」가 원형) |
+| 그 문서의 배제 대상 값(지역명·회사명·제품명) | 유형 **K** 의 값이 새어 들어옴 — 값은 스킬이 아니라 그 문서의 `forbid` 에 |
 
 > **규칙: 치환 유형을 하나 정할 때마다, 그 유형이 없앴어야 할 낱말을 `forbid` 에 함께 등록한다.**
 > 짝이 없는 치환 규칙은 방어되지 않음.
@@ -443,6 +450,19 @@ AssertionError: 금지 표현 유출: 조회 색인 → ['조회 색인']
 **건을 추가·삭제하면 이 숫자들이 조용히 거짓말을 함.**
 렌더 로그의 `절 5 · 건 2 · 확인요청 1` 을 위 자리들과 손으로 대조하는 것이 유일한 방어임.
 
+### 6.4 문체 유형 — 「학생 보고서투」와 「배제 통보」 (2026-08-27 추가)
+
+사용자 반려 사유에서 회수한 넷임. 집행은 `tone.mjs`(gazette-report) — 여기는 무엇을 재는가만 적음.
+
+| 유형 | 심각도 | 패턴 | 왜 · 처방 |
+|---|---|---|---|
+| 학생 보고서투 | S1 | `사료됨` · `고찰하` · `살펴보았/살펴보고자` · `알아보았/알아보고자` · `에 대해(서) 조사하` · `조사하였` | 「무엇을 했다」가 아니라 「무엇을 알아냈다」로. 관찰과 판단을 직설로 |
+| 완충어 | S1 | `부득이` · `양해` · `유감스럽` · `안타깝게도` · `죄송` · `please` | 사과는 사실을 흐림. 사실 → 이유 → 선택지 순으로 |
+| 근거 없는 총평 | S2 (1.0/천자 · 3회↑) | `전반적으로` · `대체로` · `종합적으로 보면` · `매우 우수` · `크게 개선` · `성공적으로` | 총평은 등급·수치·절 참조로 대체 |
+| 단독 부정 종결 | S1 | 문장 끝 `할 수 없음/불가함/제외됨/제외함/지원하지 않음/미지원임/대상이 아님` 인데 같은 블록 앞뒤 문장에 이유·기준·재검토·선택지 표지(`때문` `이유` `기준` `까지` `재검토` `대신` `대안` `선택` `조건` `예정` `가능한 것`)가 없음 | 유형 K 로 고쳐 씀. **주어가 사람·조직·국가인지는 기계가 못 봄** — 눈 검수 표 |
+
+모드 무관임 — 검수 보고에서도 이 넷은 반려 사유였음.
+
 ---
 
 ## 7. 이 문서가 책임지는 검수 항목