@chrono-meta/fh-gate 1.4.98 → 2.0.0

package/README.ko.md

@@ -62,21 +62,59 @@
 
 **전제 조건**: Claude Code CLI — `claude --version`으로 확인
 
+<details><summary><b>선택: 게이트 하나가 Python + PyYAML을 필요로 합니다</b> — 없으면 <code>npm test</code>가 빨갛습니다</summary>
+
+동의-레지스트리 게이트는 YAML을 파싱하며, 파싱할 수 없으면 **fail-closed**로 막습니다 — 검증되지
+않은 동의 기록이 깨끗한 것으로 읽혀서는 안 되므로 옳은 동작입니다. 다만 그 fail-closed 때문에
+PyYAML이 없는 머신에서는 `npm test`(그리고 `prepublishOnly`) 전체가 빨개지는데, 2026-08-12까지
+이 요구사항은 **어디에도** 적혀 있지 않았습니다. 이제 여기 적혀 있고 — 이 편집 시점 기준으로 *오직*
+여기에만 있습니다: `package.json`에도, 치트시트에도, 다른 어떤 문서에도 여전히 없으므로, 새 머신이
+이 사실을 알 수 있는 유일한 자리가 이 블록입니다. 이는 아무 데도 없던 것보다 나아진 것이지 해결은
+아닙니다:
+
+```bash
+python3 -m pip install --user pyyaml     # 확인:  python3 -c 'import yaml; print(yaml.__version__)'
+```
+
+왜 암묵적으로 두지 않고 굳이 밝히나: 어느 릴리스가 초록으로 출하된 적이 있는데, 그 세션의
+`python3`이 마침 PyYAML이 설치된 **무관한 프로젝트의 virtualenv**로 해석됐고 머신 자체의 `python3`
+에는 없었습니다. 게이트는 우회된 적이 없습니다 — 통과했고, 다만 그 통과가 이식되지 않았을 뿐입니다.
+이제 그 게이트의 모든 판정은 자신이 쓴 인터프리터와 PyYAML 버전을 함께 출력하므로, 초록이 무엇으로
+만들어진 초록인지 독자가 추측하지 않아도 됩니다.
+
+</details>
+
 ```bash
 # 1. 플러그인 설치
 claude plugin marketplace add https://github.com/chrono-meta/forge-harness.git
 claude plugin install -s user fh-meta@forge-harness
 
 # 2. 허브 클론
-git clone https://github.com/chrono-meta/forge-harness.git ~/forge-harness
-cd ~/forge-harness
+git clone https://github.com/chrono-meta/forge-harness.git ~/projects/forge-harness
+cd ~/projects/forge-harness
 
 # 3. 세션 시작
 claude
 ```
 
-> ✅ Claude가 `CLAUDE.md`를 읽고, 어떤 프로젝트를 연결할지 또는 어떤 작업을 시작할지 묻습니다.
+> ✅ 그다음 **인사를 타이핑하세요("hi")** — 🐿️ 문 메뉴는 실행만으로가 아니라 타이핑된 인사에 뜹니다.
 > **"프로젝트 연결해줘"** 라고 하면 → 허브가 `../`를 스캔해 `.git` 디렉터리를 찾고 `tracks/{project}/`를 생성합니다.
+> 전체 초기 설정(훅 · 게이트 · 베이스라인 — 항목마다 개별 승인하며, 거부해도 존중하고 기록합니다)은
+> **`/install-wizard`**를 요청하세요.
+> 이미 다른 곳에 클론했나요? 그 경로가 당신의 허브입니다 — 문서의 모든 `~/projects/forge-harness`를
+> 실제 클론 경로로 바꿔 읽으세요.
+
+**처음 15분** — 무엇이 성공이고, 그것으로 무엇을 할 것인가:
+
+1. 인사("hi")에 🐿️ 문 메뉴가 뜨고, "프로젝트 연결해줘"가 `tracks/{your-project}/`를 만들면 설정이
+   된 것입니다.
+2. 그다음 같은 세션에서 즉시 얻을 수 있는 것을 챙기세요: **"이 프로젝트 가속화해줘"**(배선할 값어치가
+   있는 스킬·플러그인의 순위 계획, 설치는 게이트를 거침) 또는 **"/context-doctor 돌려줘"**(토큰 낭비 스캔).
+3. 정직한 주석 하나: FH의 핵심 보상은 **복리**입니다 — 세션 기록, 수확된 학습, 세션 간 기억. 이는
+   **2번째 세션부터** 드러납니다. 첫날에 얻는 것은 메뉴, 가속 계획, 거버넌스 게이트입니다. 복리를
+   첫날로 판단하지 마세요.
+
+낯선 용어가 나오면 → [`knowledge/shared/GLOSSARY.md`](knowledge/shared/GLOSSARY.md).
 
 **플러그인만 (클론 없이):**
 ```bash
@@ -85,15 +123,20 @@ claude plugin install -s user fh-meta@forge-harness
 cd ~/projects/{your-project} && claude
 ```
 
-> ⚠️ **플러그인-only는 부분 시너지입니다.** 스킬과 에이전트는 얻지만 **Layer 1**은 얻지 못합니다 —
-> `CLAUDE.md` 거버넌스(능동 온보딩, 4축 게이트, 모드 분기)와 복리 맥락(`tracks/` 메모리 축적,
-> `harvest-loop` 학습)이 빠집니다. 각 스킬은 고립돼서도 동일하게 작동하지만, 빠지는 것은 그것들을
-> 세션에 걸쳐 복리로 만드는 오케스트레이션입니다. 도구만이 아니라 전체 세트를 원하면 허브를
-> 클론하세요(위 참조).
+> ⚠️ **플러그인-only는 부분 시너지입니다.** 스킬과 에이전트는 얻지만, 허브 쪽 오케스트레이션은
+> **얻지 못합니다** — `CLAUDE.md` 거버넌스(능동 온보딩, 4축 게이트, 모드 분기; 자동화 층)와 복리
+> 맥락(`tracks/` 메모리 축적, `harvest-loop` 학습; 방법론 층)이 빠집니다.
+> 각 스킬은 고립돼서도 동일하게 작동하지만, 빠지는 것은 그것들을 세션에 걸쳐 복리로 만드는
+> 오케스트레이션입니다. 도구만이 아니라 전체 세트를 원하면 허브를 클론하세요(위 참조).
 
-> 🚪 **처음 왔거나 스킬만 원하나요?** 의견이 담긴 정문에서 시작하세요 —
-> [`templates/starter_profile.md`](templates/starter_profile.md): 설치 명령 하나, 엄선된
-> 첫 5개 스킬, 그리고 무설치 거버넌스 게이트(`npx … fh-gate`). 나머지 스킬은 필요해질 때까지 기다립니다.
+**어느 진입 경로가 당신에게 맞나?**
+
+| 당신은… | 여기서 시작 |
+|---|---|
+| 1인 개발자, 프로젝트 하나, 일단 써보는 중 | [`templates/starter_profile.md`](templates/starter_profile.md) — 명령 하나, 엄선된 첫 5개 스킬 |
+| 프로젝트 여럿, 복리 허브를 원함 | 허브 클론(위 빠른 시작) |
+| CI / 비-Claude 런타임, 게이트만 | `npx @chrono-meta/fh-gate` (무설치 거버넌스 게이트) |
+| `npx`/`npm`보다 `brew`를 선호 | `brew tap chrono-meta/forge-harness && brew install forge-harness` — 100% 동일한 내용, 설치 UX만 다름(커뮤니티 탭; 아직 Homebrew Core에 없어서 탭을 먼저 추가하지 않으면 `brew search`로는 안 잡힙니다) |
 
 ---
 
@@ -140,35 +183,147 @@ Project B  ──→  CLAUDE.md에서 허브 연결
 
 이 은하계는 담는 그릇에 그치지 않습니다. FH는 현장 하네스를 자기 샌드박스 안에서 **시뮬레이션으로
 돌려보고** — 한 번 돌리는 값은 비싸도 시행착오가 한곳에 모여 복리로 쌓이므로 총비용은 쌉니다 —
-검증이 끝나면 그 프로젝트를 독립된 특화 하네스로 **내보냅니다(EMIT)**. 이것은 지향하는 목표입니다.
-구체적으로는 네 가지 방식으로 작동합니다:
-
-**① 조립(Assemble)** — FH는 하네스의 *클러스터*를 최적 토큰 비용으로 운용하며, 프로젝트에 맞는
-하네스를 손에 쥐어줍니다. 스킬을 하나하나 배선하는 게 아니라, **하네스**를 — 그 플러그인 · 스킬 ·
-에이전트까지 포함해 — 맞춰 조립한 채로 받습니다.
+검증이 끝나면 그 프로젝트를 독립된 특화 하네스로 **내보냅니다(EMIT)**. **그 마지막 단계는 지향하는
+목표이지 출하된 기능이 아닙니다** — 인큐베이션 챔버는 한 번 내보냈고, 그것을 만든 실행은 전체 흐름을
+거치지 않았습니다. 시뮬레이션-후-내보내기 문장은 진행 방향으로 읽으세요. 그 앞의 것들은 오늘 쓰이고
+있습니다.
 
-**② 벼림(Forge)** *(품질 게이트)* — 모든 변경은 적대 · 팬텀 · 회귀 게이트를 통과해 제 값을
-증명합니다. 이것은 "더 많이 검사"가 아닙니다. **책임 라우터**입니다: 자동화가 늘수록 사람의 도장은
-줄고 개당 무게는 커지므로, 게이트는 당신의 주의를 *되돌릴 수 없는* 지점에만 씁니다. 품질이
-지렛대이고, 속도는 그 결과입니다.
+### 다섯 정체성 — FH는 무엇을 위한 것인가
 
-**③ 사이드카(Sidecar)** — 능력 자체는 프런티어에 둡니다. FH는 여러 LLM(Claude, Codex, Gemini,
-로컬)에 디스패치해 raw 능력이 하나의 모델이나 하나의 세대에 묶이지 않게 합니다. 핵심은 각 모델의
-약점을 *기계적으로 메꾸는 것이 아닙니다* — 그런 스캐폴딩은 모델이 강해지면 죽은 코드가 됩니다.
-핵심은 **프런티어의 진화에 함께 타는 것**입니다: substrate가 이제 네이티브로 해주는 것은 벗어버리고,
-새로 내놓는 것은 흡수합니다. 탈상관(decorrelation)은 *지금의* 신뢰 지렛대이고(크로스패밀리 패널이
-단일 모델의 천장을 넘어섭니다), 공진화(co-evolution)가 구조입니다.
+다섯 개의 모듈이 아니고, 출하된 기능 다섯도 아닙니다. 스킬들이 **뭉쳐서 만들어내는 형태**들이며,
+스킬과 에이전트 위에 새로 얹은 층이 아니라 이미 그 안에 흩어져 있던 것에 이름을 붙인 것입니다.
+이 페이지 맨 위의 문제 표와는 층이 다릅니다: 그 표는 *당신이 들고 왔을 법한 증상*이고, 이것은
+*허브가 무엇을 중심으로 조직돼 있는가*입니다.
 
-**④ 자기진화 루프(Self-evolving loop)** — 하네스는 재구축 없이 더 나아집니다, 두 방향으로:
-**밖으로**, 매 세션의 교훈이 허브에 복리로 쌓여 다음 프로젝트가 더 빨리 시작하고, **안으로**,
-*자기 자신의* 결함을 잡아 고칩니다(4축 게이트, 양방향 검증, 사용자별 적응).
+| | 정체성 | 사람이 얻는 것 |
+|---|---|---|
+| **①** | **멀티하네스 클러스터** | 하나의 작업이 여러 하네스를 타고, 거버넌스는 그 *사이에서* 계산됨 |
+| **②** | **프로젝트 인큐베이터** | 새 하네스가 빈 스캐폴드가 아니라 **태어난 자리에서 이미 걷는 상태로** 나옴 |
+| **③** | **거버넌스 게이트** | 나가면 안 되는 것이 점검을 기억해서가 아니라 **기계적으로** 막힘 |
+| **④** | **프런티어 → 조직 전파** | 밖에서 들어온 것이 조직 *안쪽까지* 내려앉음 |
+| **⑤** | **증폭자** | 짧은 의도가 완성된 산출물까지 벼려짐 |
+
+**다섯이 똑같이 완성돼 있지 않으며, 이 표를 작동하는 기능 다섯으로 읽어서는 안 됩니다.** 성숙도는
+정체성별로 `지향 → 부분 → RC(실험실에서 섬) → REALIZED(밖에서 걸음)` 4단계로, 각각 날짜가 박힌
+증거 한 줄과 함께 추적합니다. 그 등급은 의도적으로 여기에 **옮겨 적지 않습니다**: 두 파일에 나눠 둔
+등급은 한쪽이 반드시 낡고, 이 페이지는 4개 언어로 존재하므로 여기에 복제하면 사본이 넷이 됩니다.
+위의 어느 행이든 믿고 쓰기 전에 현재 등급을 읽으세요 — 파일 하나입니다:
+[`ship_readiness_gate.md`](knowledge/shared/harness-core/ship_readiness_gate.md). 한 문장만 원한다면,
+**2026-08-15** 기준 요약: **③과 ⑤는 초록 — 실험실 밖에서 실증됨. ①·②·④는 릴리스 후보 —
+만들어지고 보정됐지만, 아직 남의 손에서 걷는 것이 확인되지 않음.** 이 문장과 게이트 파일이 다르면,
+게이트 파일이 옳고 이 줄이 낡은 것입니다.
+
+다섯 전부를 가로지르는 성질이 둘 있고, 둘 다 켜고 끄는 기능이 아닙니다:
+
+- **프런티어를 메꾸는 게 아니라 함께 탑니다.** FH는 여러 패밀리(Claude, Codex, Gemini, 로컬)에
+  디스패치하지만, 핵심은 각 모델의 약점을 땜빵하는 것이 *아닙니다* — 그런 스캐폴딩은 모델이
+  강해지면 죽습니다. 공진화입니다: substrate가 이제 네이티브로 해주는 것은 벗어버리고, 새로
+  내놓는 것은 흡수합니다. **탈상관(decorrelation)**은 지금의 신뢰 지렛대이자 이 페이지에서 하중을
+  지는 단어입니다: 두 검사가 *다르게* 실패하도록 일부러 만드는 것 — 다른 모델 패밀리의 리뷰어,
+  진짜 대상에 대한 한 번의 실행, 내 기록에 대한 외부 감사 — 그래서 하나가 못 보는 것을 다른 하나가
+  봅니다. 크로스패밀리 패널이 단일 모델의 천장을 넘어서는 이유가 바로 그것이지, 패널이 더 크기
+  때문이 아닙니다.
+- **두 방향으로 진화합니다.** *밖으로*, 매 세션의 교훈이 허브에 복리로 쌓여 다음 프로젝트가 더
+  앞선 지점에서 시작합니다. *안으로*, **자기 자신의** 결함을 잡아 고칩니다 — 같은 게이트를
+  하네스 자신에게 돌리는 것입니다.
 
 전체는 하나의 분업입니다: **raw 능력은 모델의 것, 조립 · 신뢰 · 진화는 하네스의 것.**
 
-> **여기서 셀프힐링은 주장이 아니라 — 커밋 로그에 있습니다.** 바로 이 README의 목소리 규칙이
-> 세션 도중 FH가 자기 드리프트를 잡아 고쳐졌습니다: 톤 미스 → 진단 → 자기 첫 수정안까지 공격한
-> 크로스패밀리 challenger → 재수정 → 바닥-티어 재검증 → 메모리 반영. 하네스가 자기 결함을 스스로
-> 고친 실례 — 슬로건이 아니라 기록입니다.
+---
+
+## 어떻게 만들어졌나 — 공정 → 엔진 → 정체성
+
+위의 다섯 정체성은 표면입니다. 그 아래에 두 층이 있고, 셋을 모두 이름 붙이는 것이 "FH가 무엇을
+하는가"를 구분 없는 한 덩어리로 뭉개지 않게 하는 방법입니다:
+
+```
+다섯 정체성    사람이 실제로 쓸 수 있는 것        (표면 — 무엇을 얻나)
+      ↑ 떠받치는 것
+네 엔진        그것을 가능하게 하는 능력          (능력 — 무엇을 할 수 있나)
+      ↑ 만들어내는 것
+3단 공정       그 엔진들을 벼리는 순서            (공정 — 어떻게 만들어지나)
+```
+
+**네 엔진.** 각각은 위의 어떤 정체성이 딛고 서 있는 바닥입니다. 이 페이지를 위해 만들어낸 것이
+아닙니다: 레디니스 게이트가 이미 모든 정체성을 이 같은 네 능력에 대해 별도 열로 채점하고 있었고
+([`ship_readiness_gate.md`](knowledge/shared/harness-core/ship_readiness_gate.md)), 이름을 붙인 것은
+분류체계를 새로 세운 것이 아니라 인식이었습니다.
+
+| 엔진 | 무엇인가 | 떠받치는 정체성 |
+|---|---|---|
+| `judgment-circuit` *(영혼 · 심지)* | 무엇을 성공으로 볼 것인가, 불확실할 때 어느 쪽으로 기울 것인가, 무엇이 범위 밖인가, 무엇은 절대 하지 않는가 | ⑤ 증폭자 · ② 인큐베이터 |
+| `ship-gate` | 비가역 표면 앞에서의 기계적 차단 — 커밋 · 공개 · 삭제 · 히스토리 재작성 | ③ 거버넌스 게이트 |
+| `context-continuity` | 압축 · 서브에이전트 · 머신 · 세션을 가로질러 맥락을 놓치지 않는 것 | ① 클러스터 · ② 인큐베이터 |
+| `external-grounding` | net-new를 주장하거나 설계를 확정하기 *전에* 레포 밖에 손을 뻗는 것 | ④ 프런티어 → 조직 |
+
+엔진은 이름으로 쓰지 번호로 쓰지 않습니다 — 여기 표의 순서와 다른 문서의 서술 순서가 다르므로,
+"엔진 ④"는 어느 쪽을 읽느냐에 따라 서로 다른 엔진을 가리킵니다.
+
+가장 자주 오독되는 것이 `judgment-circuit`이라 못 박아 둡니다: **이것은 판단하기 위한 좌표계이지,
+하네스가 누구인지에 대한 진술이 아닙니다.** 위 표의 그 행에 있는 네 항목이 전부입니다. 영혼(심지)
+이라는 운영자의 말도 그 좌표계를 가리키는 것이지 페르소나가 아니며, 영어로 "soul"이라 옮기지 않는
+이유도 그것입니다 — 그 단어는 *페르소나*로 읽힙니다. 이 엔진 뒤에 있는 측정(105회 실행, 정체성
+선언이 있는 프롬프트와 없는 프롬프트를 비교)의 가장 큰 발견이 바로 **둘은 다른 것**이라는
+사실이었습니다: *"너는 ~이다"*를 넣은 쪽이 시험한 가장 약한 모델에서 **순손실**로 나왔고, 그것을
+빼자 회복됐습니다. 한 단어로 뭉뚱그리는 순간, 그 측정이 갈라놓은 것이 다시 붙습니다. 수치 자체는
+의도적으로 여기 인용하지 않습니다 — 원 기록이 척도 없이 적어 두었고, 척도 없는 숫자를 표지에 싣는
+것은 장식입니다. 맥락과 함께
+[`ship_readiness_gate.md`](knowledge/shared/harness-core/ship_readiness_gate.md)에 있습니다. 또한
+판단 회로는 한 번에 만들어지지 않습니다: FH는 새 하네스에 **씨앗 초안**을 쥐어주고, 그 하네스가
+실제로 쓰이면서 채워집니다.
+
+**3단 공정** — 이것은 메뉴가 아니라 *투자의 순서*입니다:
+
+```
+① 설계 전에 회로       판단 회로부터 심을 것 — 무엇이 성공 · 어디로 기움 · 범위 밖 ·
+                       절대 안 함. 한 일을 나중에 기록으로 적어두는 게 아님
+
+② 중간은 탈상관으로     작업을 «다르게 실패하는» 검사들로 쪼개어 한꺼번에 돌릴 것.
+   가속                 어떤 차이가 중요한지 고를 것 — 같은 종류의 리뷰어를 하나 더
+                        붙이는 건 탈상관이 아니라 같은 사각을 두 번 보는 것.
+                        병렬화 자체엔 방향이 없고, 고르는 것은 ①의 판단 회로.
+                        이건 «일하는 방식»이지 ③의 마감 검사가 아님
+
+③ 끝에서 4축으로       아래 네 축. 적대검증은 그중 하나이지 전부가 아님
+   태우기
+```
+
+**네 검증 축** — "리뷰했다"가 실제로는 이 중 첫 번째 하나만 뜻하는 경우가 대부분입니다. 가운데 열을
+보고 하나를 고르고, 오른쪽 열로 그것이 무엇을 잡는지 확인하세요:
+
+| 축 | 이럴 때 꺼내 쓴다 | 무엇을 잡나 | 대표 계기 |
+|---|---|---|---|
+| **ⓐ 다른 패밀리** | 그 변경이 무언가를 결정할 때 — PASS/FAIL, 게이트, 안전 규칙 | **구현**이 틀림 | 다른 모델 패밀리의 리뷰어(`auto-decorrelation`) |
+| **ⓑ 첫 실사용** | 숫자·개수·스캔 출력을 믿으려 할 때 | **재는 방식**이 틀림 | 진짜 대상 하나에 한 번 돌리고 결과를 손으로 확인 |
+| **ⓒ 기록 그라운딩** | 남이 그것을 근거로 행동할 주장·수치·인용을 적었을 때 | **주장**이 틀림 | 그것을 쓰지 않은 사람이 적힌 내용을 다시 잼 |
+| **ⓓ 되돌려 관찰** | 테스트·가드·검사를 추가하고 그게 나를 지킨다고 믿을 때 | **앵커**가 틀림 — 검사가 장식임 | 그것이 지키는 대상을 지우고 *바로 그* 검사가 빨개지는지 확인 |
+
+**넷을 매번 다 돌리지 않으며, 그것이 설계입니다.** 한 줄짜리 수정은 어느 축도 벌지 못합니다.
+판정을 반환하는 변경은 ⓐ를 벌고, 공개되는 수치는 ⓑ와 ⓒ를, 새 가드는 ⓓ를 법니다. 비가역 표면 —
+공개 · 삭제 · 히스토리 재작성 — 은 자신이 노출된 실패 모드에 해당하는 축을 모두 벌며, 애매하면
+하나 더 돌리는 쪽에 이익을 줍니다. 리뷰어를 늘리는 것은 축을 더하는 것과 다릅니다.
+
+한 축이 이 넷의 바깥에 따로 있습니다. *무엇을* 검사하는지가 아니라 *누구의* ground truth 위에
+서는지를 바꾸기 때문입니다: **관점(standpoint)** — 변경이 다른 하네스로 넘어갈 때, 그 diff를 당신의
+해석이 아니라 대상 하네스 자신의 레포와 규칙에서 돌립니다
+([`field_verdict_crossfamily_gate.md §7`](knowledge/shared/harness-core/field_verdict_crossfamily_gate.md)).
+
+> **정직한 주석 — 이것은 깔끔한 스택이 아니고, 그게 핵심입니다.** 1단계와 3단계는 엔진과 **같은
+> 재료**로 되어 있어서, 아래층이 위층을 씁니다. 모순은 *주어*에서 풀립니다: **엔진**은 FH가 당신의
+> 작업에 적용하는 것이고, **공정**은 FH가 자기 엔진을 벼릴 때 쓰는 순서입니다. 방법론을 밖에서
+> 빌려왔다면 엔진과 무관했을 것이고, 겹친다는 사실 자체가 도그푸딩의 지문입니다. 각 주장 뒤의
+> 표본 한계를 포함한 전체 정본:
+> [`fh_three_layer_canon.md`](knowledge/shared/harness-core/fh_three_layer_canon.md).
+
+> **여기서 셀프힐링은 주장이 아니라 — 직접 확인하세요.** 이 레포의 `git log`가 기록이고, 형태가
+> 반복됩니다: 미스가 잡히고, 그 수정이 공격당하고, 공격은 원본이 아니라 *수정 쪽*에 꽂히는 일이
+> 잦습니다. 해시로 열어볼 수 있는 것 하나 — `cb74ea4`, 하네스가 세션 도중 레지스터를 드리프트한
+> 뒤 `CLAUDE.md §Voice/Tone`에 레지스터-일관성 규칙이 추가된 커밋입니다. 두 번째는 이 절을 추가한
+> 바로 그 변경 안에 있습니다: 아무도 안 돌리는 테스트를 찾아내는 것이 본업인 검사기가 스크립트
+> *자신의 주석*에서 초록 개수를 읽어 보고하고 있던 것이 잡혔고, 그것을 고치려고 쓴 가드는 정작
+> 지워도 실패하는 테스트가 하나도 없는 것으로 드러났습니다 — 저자가 아니라 다른 모델 패밀리가
+> 찾았고, 실제로 실패하는 픽스처로 닫았습니다. 피처 브랜치의 커밋 해시는 squash-merge에서
+> 살아남지 못하므로, 그 건은 썩을 ID 대신 형태로 인용합니다.
 
 ---
 
@@ -252,6 +407,19 @@ Code를 메인 오케스트레이터로 두고 Gemini, Codex, 또는 Antigravity
 현재 게이트 의미론은 이를 BLOCKED로 분류합니다: CI가 못 잡은 A급 발견 2건(허용목록의 짧은-토큰
 오버플로, arity 테이블에서 빠진 executor 도구).
 
+**이 방법이 실제로 뭔가를 더하나? 측정한 확인 (2026-07-14).** 모델을 중간-티어 바닥에 고정해 두고
+리뷰 *방법*만 바꿔, **default-toward-PASS**(fail-open) 구멍이 심어진 처음 보는 게이트 조각들에
+돌렸습니다. 미묘한 구멍 8개 — 테스트셋이 우리 방법에 맞춰지지 않도록 다른 두 모델이 만든 것 —
+에서 평범한 리뷰는 5/8을 잡았고(그중 둘은 엉뚱한 버그를 잡은 것, 즉 잘못된 확신), 같은 모델에
+FH의 degrade-direction 렌즈를 붙이자 오탐 0으로 6/8을 잡았습니다. 정직한 부분: **단일-모델 레인
+둘 다 같은 구멍 2개를 놓쳤습니다**(falsy 에러-센티널, 그리고 구분자-부정 파싱). 다른 모델 패밀리에
+같은 렌즈를 붙이니 둘 다 잡았고 — 그래서 FH *스택*(렌즈 + 크로스패밀리 + 기계적 사전-스크린)은
+8/8에 닿습니다. 핵심은 헤드라인 점수가 아닙니다. 값어치가 **탈상관된 스택**에서 나온다는 것입니다.
+잘 프롬프트된 단일 모델조차 상관된 맹점을 갖고, 그것은 다른 패밀리만 닫습니다. 놓친 두 부류는
+이제 한 층 앞에서 기계적으로(lint 사전-스크린) 잡힙니다. 표본이 작습니다(단일 추출); 반복 실행과
+더 어려운 구멍이 명시된 다음 단계입니다. 방법 + 전체 결과:
+[`ship_readiness_gate.md`](knowledge/shared/harness-core/ship_readiness_gate.md).
+
 전체 스펙: [`fh_integration_contract.md`](knowledge/shared/harness-core/fh_integration_contract.md)
 
 ---
@@ -274,7 +442,9 @@ forge-harness는 프로젝트를 강철처럼 다룹니다 — 그리고 이 은
 `agent-composer`(디스패치를 오케스트레이션). 나머지 스킬은 필요해질 때까지 기다립니다 — 전체 목록은
 아래에.
 
-## 37 skills · 8 agents
+## 40 skills · 8 agents
+
+> 개수 = 폐기되지 않은 스킬(옛 이름 라우팅용으로만 남긴 deprecated 리다이렉트 스텁은 제외).
 
 <details>
 <summary>전체 자산 활성화 확인</summary>
@@ -290,6 +460,7 @@ forge-harness는 프로젝트를 강철처럼 다룹니다 — 그리고 이 은
 | `harness-doctor` | 하네스 구조 진단 | "내 Claude 설정 점검" |
 | `pipeline-conductor` | 4축 품질 게이트 (후방/적대/전방/기록) | "품질 게이트 돌려" |
 | `field-harvest` | 필드 패턴을 허브로 역전파 | "이거 재사용할 수 있겠다" |
+| `dialogue-harvest` | AI 대화록 채굴: 동조 걷어내기, 유도된 것과 독립적인 것 구분 | "이 스레드에서 내가 실제로 기여한 게 뭐야?" |
 | `frontier-digest` | HN + arXiv → 실행 가능한 통찰 | "AI 트렌드 다이제스트" |
 | `hub-cc-pr-reviewer` | 자동 PR 리뷰 | "이 PR 리뷰해" |
 | `verify-bidirectional` | 결정 역검증 | "그게 맞아?", "다시 확인해" |
@@ -305,14 +476,24 @@ forge-harness는 프로젝트를 강철처럼 다룹니다 — 그리고 이 은
 | `convergence-loop` *(fh-commons)* | N-라운드 수렴 루프 | "단일 패스가 의심스러워" |
 | `token-budget-gate` *(fh-commons)* | 작업 전 토큰 비용 추정 | "이거 얼마나 비싸?" |
 | `mcp-circuit-breaker` *(fh-commons)* | MCP 도구 실패 패턴 탐지 | "MCP가 계속 실패해" |
+| `ko-tech-writer` *(fh-commons)* | 한국어 기술 글쓰기 파이프라인(레지스터 보정, 번역투 제거, 정직도 층화, 지각적 QA) | "기술문서 써줘", "번역투 고쳐줘" |
 | `quench-challenger` *(fh-commons)* | 적대적 압박-테스트 에이전트 | "악마로 이걸 공격해" |
-| *(+ 추가 자산)* | marketplace-gate · contention-layer · edit-manifest · fact-checker · goal-quench · hub-persona-auditor · install-doctor · memory-hygiene · persona-innovator · prompt-regression · public-surface-audit · salience-splitter | |
+| `auto-decorrelation` | 하중을 받는 변경에 다른 모델-패밀리 리뷰어를 소집 | "이 검증 탈상관해줘" |
+| `video-ingest` | 영상 → 에이전트 맥락, 능력과 길이로 라우팅 | "이 영상이 뭘 보여주는데?" |
+| `fh` | 인사 없이도 허브 지도를 즉석에서 렌더 | "fh" |
+| *(+ 나머지 스킬)* | marketplace-gate · contention-layer · deliberation · edit-manifest · goal-quench · install-doctor · memory-hygiene · prompt-regression · public-surface-audit · return-path-gate · salience-splitter | |
+| **8 에이전트** | `challenger` · `quench-challenger` (적대) · `beginner` · `main-player` · `expert` (사용자-숙련도 스펙트럼 — 냉정한 첫 읽기, 일상 사용, 도메인 권위) · `fact-checker` · `hub-persona-auditor` · `persona-innovator` | 위 스킬들이 디스패치하거나, 이름으로 직접 호출 |
 
 | 활성 개수 | 진단 |
 |:---:|---|
-| **28+** | 고급 — agent-composer + sim-conductor + steel-quench + pipeline-conductor 연쇄 |
-| **10–27** | 활성화 단계 — 미체크 자산을 점진적으로 켜기 |
-| **0–9** | 초기 단계 — `install-wizard`로 시작 |
+| **표면의 절반 이상** | 고급 — agent-composer + sim-conductor + steel-quench + pipeline-conductor 연쇄 |
+| **한 줌에서 그 절반까지** | 활성화 단계 — 미체크 자산을 점진적으로 켜기 |
+| **거의 없음** | 초기 단계 — `install-wizard`로 시작 |
+
+> 이 구간은 측정이 아니라 대략적인 자가 점검입니다 — 어떤 산출물도 이 임계값을 정의하지 않으며,
+> 이전의 고정 숫자들은 더 작던 로스터를 기준으로 맞춰진 것이라 로스터가 커지면서 조용히
+> 어긋났습니다. 스킬을 더 많이 쓰는 것 자체도 목표가 아닙니다 — 당신의 작업이 실제로 필요로 하는
+> 것을 쓰는 게 목표입니다.
 
 **하려는 일로 스킬 찾기:**
 
@@ -348,7 +529,7 @@ Claude Code는 작업 복잡도로 모델을 자동 선택하지 않습니다
 | `/model opus` | Opus가 전부 처리 | 하네스-편집 세션(Mode D) · 매 턴 최대 깊이 |
 | `/model opusplan` | Opus가 *계획* · Sonnet이 실행 *(Opus가 관여할 때)* | 비용 의식적 일상 코딩 — 주의사항 참조 |
 
-**왜 이제 Sonnet 기본값이 통하나**: 측정 결과(아래 §Model setup evidence note 참조), FH *운용*은 거의
+**왜 이제 Sonnet 기본값이 통하나**: 측정 결과(아래 *주장이 아니라 측정* 참조), FH *운용*은 거의
 모델-평탄합니다 — 맥락에 든 규칙이 대부분의 일을 합니다. 여전히 더 강한 모델이 필요한 것은 깊이에
 민감한 소수의 턴이고, FH는 그것을 스스로 처리합니다: **일부 스킬과 에이전트는 모델-티어 바닥을
 선언**하며(예: `quench-challenger`는 opus에 바닥), 환경이 닿을 수 있으면 그 바닥 티어의
@@ -370,10 +551,15 @@ Claude Code는 작업 복잡도로 모델을 자동 선택하지 않습니다
 > 비용은 세션 jsonl의 `message.model`에서 CC로 볼 수 있습니다.
 
 **주장이 아니라 측정** (실측 예): 블라인드 규칙-적용 배터리에서 FH *운용*은 거의 모델-평탄합니다 —
-**측정한 모든 Claude 티어가 94–100%** (Fable, Opus 4.8, Sonnet 4.6과 5, Haiku 4.5); 잃은 소수 점수는
-포맷 규율이지 함정이나 게이트-급 미스가 아닙니다. 티어가 갈리는 것은 루브릭-초과 *설계* 증분뿐(하네스를
-개발하는 것이지 운용하는 것이 아님) — 그래서 기본값이 **티어-바닥 디스패치**로 깊이-민감 턴을 덮는
-Sonnet이고, 고정된 더 강한 모델은 하네스-편집 세션에만 권장됩니다.
+30점 블라인드 배터리(2026-06-10)에서 돌린 네 티어가 **94–100%** (top-tier anchor / Opus 4.8 /
+Sonnet 4.6 / Haiku 4.5 = 100 / 100 / 97 / 94)였고, 2026-07-03 재현에서 Opus 4.8, **Sonnet 5**,
+Haiku 4.5가 각각 16/16으로 다시 앵커됐습니다. 둥근 숫자 하나 대신 정직한 주석 둘: 원 산출물이
+의도적으로 최상위 티어의 이름을 밝히지 않으므로 이 페이지도 밝히지 않습니다. 그리고 **현재**
+최상위 티어는 이 배터리로 돌린 적이 없습니다 — 앞으로 유효한 것은 점수가 아니라 아래의 독트린입니다.
+잃은 소수 점수는 포맷 규율이지 함정이나 게이트-급 미스가 아닙니다. 티어가 갈리는 것은 루브릭-초과
+*설계* 증분뿐(하네스를 개발하는 것이지 운용하는 것이 아님) — 그래서 기본값이 **티어-바닥
+디스패치**로 깊이-민감 턴을 덮는 Sonnet이고, 고정된 더 강한 모델은 하네스-편집 세션에만
+권장됩니다.
 
 이것은 **불변식으로 진술되며, 모델별 리더보드가 아닙니다.** 새 릴리스가 뒤집지 못하는 두 구조 법칙:
 
@@ -430,7 +616,7 @@ Gemini와 함께 만들면 새 Claude가 그 거품을 잡고, Claude와 함께
 
 > **FH 논문** — 아래 방법론은 주장만이 아니라 문서화돼 있습니다:
 > - **v1.0 — 방법론** · [Zenodo](https://zenodo.org/records/20397566) (DOI 10.5281/zenodo.20397566). 2층 설계, 6축 프레임워크, 4-에이전트 오케스트레이션, 그리고 복리 루프를 실증 증거와 함께.
-> - **cs.SE companion — 거버넌스-게이트 방법론** · **게재됨** [Zenodo](https://zenodo.org/records/20680081) (DOI 10.5281/zenodo.20680081 · 최신 v1.1 10.5281/zenodo.20740038 · CC-BY-4.0) · arXiv 제출됨(cs.SE, 모더레이션 중).
+> - **cs.SE companion — 거버넌스-게이트 방법론** · **게재됨** [Zenodo](https://zenodo.org/records/20680081) (DOI 10.5281/zenodo.20680081 · 최신 v1.1 10.5281/zenodo.20740038 · CC-BY-4.0) · arXiv 제출됨(cs.SE); 모더레이션 결과는 이 레포에서 추적하지 않으므로, "제출됨"은 현재 상태가 아니라 이 페이지가 보증할 수 있는 마지막 상태로 읽으세요.
 > - **cs.AI companion — "Governance Dividend"** · 준비 중.
 
 외부 수렴: