@chrono-meta/fh-gate 1.4.98 → 1.4.99

package/.claude-plugin/marketplace.json

@@ -11,13 +11,13 @@
   "plugins": [
     {
       "name": "fh-meta",
-      "version": "1.4.98",
+      "version": "1.4.99",
       "description": "Hub meta-operations toolkit — 35 skills + 7 agents. New in 1.4.53: `fh-codex-doctor` (npm bin) — Codex adapter drift scanner; reads the documented M1/M2/M3 skill tier map + skill/agent source and reports codex-native/adapter-required/claude-native/unclassified per unit, wired into `npm test`/`prepublishOnly` (fail-closed on unclassified Claude-native primitives). New in 1.4.49: steel-quench gains Step 0.6 Verdict-Invariance Probe (groundedness axis — a load-bearing judged gate's verdict must track behavior, not rubric phrasing; measured flip-count over cross-family paraphrases; arXiv:2605.06161 Policy Invariance anchor); multi_model_sidecar_strategy §Vendor-native harness (a model is strongest in its own vendor CLI — Claude/CC, GPT/codex, Gemini/Antigravity; a universal router degrades all of them, so it stays an autocomplete/QA sidecar, never orchestration); predelete_check.sh fail-closed rewrite; memory-hygiene A-TMA anchor. New in 1.4.48: phantom-quench + steel-quench gain external frontier anchors (arXiv:2607.02052 package-hallucination; arXiv:2607.02057 prompt-coverage-adequacy); README model-flat claim reframed from a per-release point-curve to structural invariants (operation flattens across tiers; depth tier-order fixed within a generation). New in 1.4.47: onboarding step ① surfaces the Mode D companion-store session-start load in the auto-read salience anchor (previously only in the local binding + rules, so a greeting could skip the load). New in 1.4.46: context-doctor command-output axis (route to rtk/proxy for verbose CLI stdout, complementing .claudeignore; risk-gated to token-scarce envs). New in 1.4.41: context-doctor 2026 trigger vocab (context engineering/rot/collapse) + phantom-citation hardening; hub measurement-integrity-checklist (cross-model measurement pre-flight: display-name pin/reps≥3/discriminating probe). New in 1.4.40: install-wizard queryable-wiki scaffold (INDEX + session-start read + R/W/C ingest). New in 1.4.39: auto-decorrelation (cross-family verifier sidecar recruitment) + video-ingest (capability-routed video ingestion). New in 1.4.x: verify-axis check-class taxonomy (mandatory-pass/measured/judged), no-reinvention Tier-0 inventory, 7-class failure taxonomy, Destructive-Op Gate, Wave-T (Temper), tier-floor governance, Mode D Model Notice, FC consent lane, default-Sonnet guidance. New in 1.3.0: public-surface-audit, field-harvest Mode B auto-trigger, 4-axis gate scope ext. Validated cross-CLI: Claude Code, Codex, Gemini.",
       "source": "./plugins/fh-meta"
     },
     {
       "name": "fh-commons",
-      "version": "1.4.98",
+      "version": "1.4.99",
       "description": "Project-agnostic utility skills — 5 skills (convergence-loop · deliberation · mcp-circuit-breaker · token-budget-gate · ko-tech-writer) + 1 agent (quench-challenger). Domain-independent utilities transplantable into any project.",
       "source": "./plugins/fh-commons"
     }

package/README.ja.md

@@ -62,21 +62,60 @@
 
 **前提条件**: Claude Code CLI — `claude --version` で確認
 
+<details><summary><b>任意: 1つのゲートが Python + PyYAML を必要とします</b> — 無いと <code>npm test</code> が赤くなります</summary>
+
+同意レジストリ (consent-registry) のゲートは YAML を解析し、解析できないときは**フェイルクローズ**します —
+検証されていない同意記録がきれいな記録として読まれてはいけないので、これは正しい挙動です。ただしその
+フェイルクローズは、PyYAML の無いマシンでは `npm test`（および `prepublishOnly`）全体を赤にします。そして
+2026-08-12 まで、この要件は**どこにも**書かれていませんでした。いまはここに書かれています — そしてこの編集
+時点では*ここにだけ*です: `package.json` にもチートシートにも他のどの文書にも依然として無いので、このブロックが
+新しいマシンがこれを知れる唯一の場所です。これは「どこにも無い」よりは改善であって、修正ではありません:
+
+```bash
+python3 -m pip install --user pyyaml     # 確認:  python3 -c 'import yaml; print(yaml.__version__)'
+```
+
+なぜ暗黙のままにせずわざわざ書き出すのか: あるリリースが、`python3` がたまたま**無関係な別プロジェクトの
+virtualenv**（PyYAML 入り）に解決されたセッションから緑で出荷されたことがあります — マシン自身の `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. 次に同じセッションのうちに即効の成果を1つ取ってください: **「このプロジェクトを加速して」**（配線する
+   値打ちのあるスキル/プラグインのランク付き計画、インストールはゲート付き）または
+   **「`/context-doctor` を回して」**（トークン浪費のスキャン）。
+3. 正直な注記が1つ: FH の中核の見返りは**複利**です — セッション記録、収穫された学習、セッションをまたぐ
+   記憶。これは**セッション2以降**から効いてきます。初日に手に入るのはメニュー、加速計画、そして
+   ガバナンスゲートです。初日で複利を判断しないでください。
+
+途中で見慣れない言葉が出てきたら → [`knowledge/shared/GLOSSARY.md`](knowledge/shared/GLOSSARY.md)。
 
 **プラグインのみ（クローンなし）:**
 ```bash
@@ -85,15 +124,21 @@ claude plugin install -s user fh-meta@forge-harness
 cd ~/projects/{your-project} && claude
 ```
 
-> ⚠️ **プラグインのみは部分シナジーです。** スキルとエージェントは得られますが **Layer 1** は得られません —
-> `CLAUDE.md` ガバナンス（能動オンボーディング、4軸ゲート、モード分岐）と複利文脈（`tracks/` メモリ蓄積、
-> `harvest-loop` 学習）が抜けます。各スキルは孤立していても同じように動きますが、抜けるのはそれらを
-> セッションをまたいで複利にするオーケストレーションです。道具だけでなく全体セットが欲しいなら、ハブを
-> クローンしてください（上記参照）。
+> ⚠️ **プラグインのみは部分シナジーです。** スキルとエージェントは得られますが、**ハブ側の
+> オーケストレーション**は得られません — `CLAUDE.md` のガバナンス（能動オンボーディング、4軸ゲート、
+> モード分岐; 自動化層）と、複利で積み上がる文脈（`tracks/` のメモリ蓄積、`harvest-loop` の学習;
+> 方法論層）です。
+> 各スキルは孤立していても同じように動きます。抜けるのは、それらをセッションをまたいで複利にする
+> オーケストレーションのほうです。道具だけでなく全体セットが欲しくなったら、ハブをクローンしてください（上記参照）。
 
-> 🚪 **初めてですか / スキルだけ欲しいですか?** 意見のこもった正面玄関から始めてください —
-> [`templates/starter_profile.md`](templates/starter_profile.md): インストールコマンド1つ、厳選された
-> 最初の5つのスキル、そしてインストール不要のガバナンスゲート（`npx … fh-gate`）。残りのスキルは必要になるまで待ちます。
+**どの入口があなた向きか?**
+
+| あなたは… | ここから始める |
+|---|---|
+| 個人開発者、プロジェクト1つ、まず試したい | [`templates/starter_profile.md`](templates/starter_profile.md) — コマンド1つ、厳選された最初の5つのスキル |
+| プロジェクトが複数、複利で積み上がるハブが欲しい | ハブをクローン（上のクイックスタート） |
+| CI / 非 Claude ランタイム、ゲートだけ欲しい | `npx @chrono-meta/fh-gate`（インストール不要のガバナンスゲート） |
+| `npx`/`npm` より `brew` がいい | `brew tap chrono-meta/forge-harness && brew install forge-harness` — 内容は100%同一、インストール体験だけが違います（コミュニティ tap; まだ Homebrew Core には入っていないので、先に tap しないと `brew search` では見つかりません） |
 
 ---
 
@@ -141,35 +186,147 @@ Project B  ──→  CLAUDE.md でハブを接続
 この銀河はただの容れ物ではありません。FH はフィールドハーネスを**自らのサンドボックス内で
 シミュレーションとして走らせることができ** — 1回あたりは高くつきますが、試行錯誤が一箇所に集まり
 複利で積み上がるため総コストは安くなります — シミュレーションが検証されれば、その
-プロジェクトを独立した特化ハーネスとして**送り出します (EMIT)**。これが目指す目標です。実際には、
-4つの方法で働きます:
+プロジェクトを独立した特化ハーネスとして**送り出します (EMIT)**。**この最後の一歩は目指している目標で
+あって、出荷済みの機能ではありません** — インキュベーションチャンバーが送り出したのは1回きりで、それを
+生んだランは完全なフローを通っていません。シミュレーションして送り出すという文は*進む方向*として
+読んでください。その手前にあるものはすべて、今日すでに使われています。
 
-**① 組み立て (Assemble)** — FH はハーネスの*クラスター*を最適なトークンコストで運用し、プロジェクトに合う
-ハーネスを手に握らせます。スキルを1つずつ配線するのではなく、**ハーネス**を — そのプラグイン · スキル ·
-エージェントまで含めて — 合わせて組み立てた状態で受け取ります。
+### 5つの正体 (five identities) — FH は何のためにあるのか
 
-**② 鍛え (Forge)** *(品質ゲート)* — あらゆる変更は敵対的 · ファントム · 回帰ゲートを通って自らの値打ちを
-証明します。これは「もっと検査する」ではありません。**責任ルーター (responsibility router)** です: 自動化が
-増えるほど人間の承認は減り1件あたりの重みは増すので、ゲートはあなたの注意を*取り返しのつかない*地点にだけ
-使います。品質が梃子であり、速度はその結果です。
+これは5つのモジュールではなく、5つの出荷済み機能でもありません。スキルが**固まっていく形**の名前です —
+上に載せた新しい層ではなく、スキルとエージェントに散らばって既にそこにあったものに名前を付けたもの
+です。これはこのページ冒頭の課題表とは別のレベルにあります: あの表は*あなたが抱えて来たかもしれない
+症状*であり、こちらは*ハブが何を軸に組み立てられているか*です。
 
-**③ サイドカー (Sidecar)** — 能力そのものはフロンティアに置きます。FH は複数の LLM（Claude, Codex, Gemini,
-ローカル）へディスパッチし、raw な力が1つのモデルや1つの世代に縛られないようにします。要点は各モデルの
-弱点を*機械的に埋めることではありません* — そうしたスキャフォールディングはモデルが強くなれば死んだコードに
-なります。要点は**フロンティアの進化に共に乗ること**です: substrate がいまやネイティブでやってくれるものは
-脱ぎ捨て、新しく出してくるものは吸収します。脱相関 (decorrelation) は*いまの*信頼の梃子であり（クロス
-ファミリーのパネルが単一モデルの天井を超えます）、共進化 (co-evolution) が構造です。
-
-**④ 自己進化ループ (Self-evolving loop)** — ハーネスは再構築なしにより良くなります、2つの方向へ:
-**外へ**、各セッションの教訓がハブに複利で積み上がって次のプロジェクトがより速く始まり、**内へ**、
-*自分自身の*欠陥を捕まえて直します（4軸ゲート、双方向検証、ユーザー別適応）。
+| | 正体 | 人が手にするもの |
+|---|---|---|
+| **①** | **マルチハーネスクラスター** | 1つの作業が複数のハーネスに乗り、ガバナンスはその*あいだ*で計算されます |
+| **②** | **プロジェクトインキュベーター** | 新しいハーネスが空のスキャフォールドではなく、**生まれた場所で既に歩ける状態**で出てきます |
+| **③** | **ガバナンスゲート** | 出してはいけないものが、覚えて確認する代わりに**機械的に**止まります |
+| **④** | **フロンティア → 組織への伝播** | 外から届いたものが、組織の*内側*まで届ききります |
+| **⑤** | **増幅器 (Amplifier)** | 短い意図が、完成した成果物まで鍛え上げられます |
+
+**5つが等しく仕上がっているわけではなく、この表を「5つの動く機能」として読んではいけません。** 成熟度は
+正体ごとに4段階（`aspirational → partial → RC (ラボで立った) → REALIZED (外を歩いた)`）で追跡され、
+それぞれに日付入りの証拠の行が付いています。その等級はここには**あえて写しません**: 2つのファイルに
+置かれた等級は片方が必ず腐りますし、このページは4言語で存在するので、ここに写せば写しは4つになります。
+上のどの行かに頼る前に、現在の等級を読んでください — それはファイル1つです:
+[`ship_readiness_gate.md`](knowledge/shared/harness-core/ship_readiness_gate.md)。1文だけ欲しいなら、
+**2026-08-15** 時点で: **③ と ⑤ は緑 — ラボの外で実証済み。①, ②, ④ はリリース候補 — 作られ較正されて
+いますが、他人の手の中で歩くところはまだ示されていません。** この文とゲートファイルが食い違ったときは、
+ゲートファイルが正しく、この行が古いということです。
+
+5つすべてを横断する性質が2つあり、どちらもオンにする機能ではありません:
+
+- **フロンティアに継ぎを当てるのではなく、フロンティアに乗ります。** FH はファミリーをまたいで
+  ディスパッチします（Claude, Codex, Gemini, ローカル）— ただし要点は各モデルの弱点を埋めることでは
+  *ありません*。そうしたスキャフォールディングはモデルが強くなれば死ぬからです。これは共進化です:
+  substrate がいまやネイティブでやってくれるものは脱ぎ捨て、次に出してくるものは吸収します。
+  **脱相関 (decorrelation)** が*いまの*信頼の梃子であり、このページで最も荷重を担う言葉です:
+  2つの検査が*違うかたちで*失敗するように意図的に仕組むこと — 別のモデルファミリーからのレビュアー、
+  実際の対象に対する1回の実行、自分の記録に対する外部からの監査 — そうすれば一方が見えていないものを、
+  もう一方は見ています。クロスファミリーのパネルが単一モデルの天井を超えるのはまさにその理由であって、
+  規模が大きいからではありません。
+- **2つの方向へ進化します。** *外へ*、各セッションの教訓がハブに複利で積み上がり、次のプロジェクトが
+  より先から始まります。*内へ*、**自分自身の**欠陥を捕まえて直します — 同じゲートを、ハーネス自身に
+  向けたものです。
 
 全体は1つの分業です: **raw な能力はモデルのもの、組み立て · 信頼 · 進化はハーネスのもの。**
 
-> **ここでのセルフヒーリングは主張ではなく — コミットログにあります。** まさにこの README の声のルールが
-> セッションの途中で、FH が自らのドリフトを捕まえて直されました: トーンのミス → 診断 → 自らの最初の修正案まで
-> 攻撃したクロスファミリー challenger → 再修正 → 床ティアでの再検証 → メモリ反映。ハーネスが自らの欠陥を
-> 自分で直した実例 — スローガンではなく記録です。
+---
+
+## どう作られているか — 工程 → エンジン → 正体
+
+上の5つの正体は表面です。その下に2つの層があり、3つすべてに名前を付けることが「FH は何をするのか」が
+1つの未分化な塊に潰れるのを防ぎます:
+
+```
+5つの正体      人が実際に使えるもの              (表面 — 手に入るもの)
+   ↑ 支えているのは
+4大エンジン    それを可能にする能力              (能力 — できること)
+   ↑ 生み出しているのは
+3段工程        そのエンジンを鍛える「順序」      (工程 — どう作られるか)
+```
+
+**4大エンジン。** それぞれが上のいずれかの正体を足元で支えています。これらはこのページのために発明された
+ものではありません: 出荷準備ゲートが既に、すべての正体をこの同じ4つの能力に対して専用の列で採点して
+いました（[`ship_readiness_gate.md`](knowledge/shared/harness-core/ship_readiness_gate.md)）。ですから
+名前を付けたのは、分類体系を作る作業ではなく認識でした。
+
+| エンジン | 何であるか | 支える正体 |
+|---|---|---|
+| `judgment-circuit` | 何を成功とするか、不確実なときどちらへ倒すか、何が範囲外か、何は決してやらないか — **判断の座標系** | ⑤ 増幅器 · ② インキュベーター |
+| `ship-gate` | 不可逆な表面の手前での機械的な遮断 — commit, publish, delete, rewrite | ③ ガバナンスゲート |
+| `context-continuity` | 圧縮 · サブエージェント · マシン · セッションをまたいで筋を見失わないこと | ① クラスター · ② インキュベーター |
+| `external-grounding` | 新規性を主張したり設計を決めたりする*前に*、レポの外へ手を伸ばすこと | ④ フロンティア → 組織 |
+
+エンジンは常に名前で書き、番号では書きません — ここの表の順序と他所の散文の順序は異なるので、
+「エンジン④」はどちらを読むかで2つの別のエンジンに復号されてしまいます。
+
+`judgment-circuit` はもっとも誤読されやすいので、はっきり書きます: **これは「決めるための座標系」で
+あって、ハーネスが何者であるかの表明ではありません。** その行にある4項目がこのエンジンのすべてです。
+日本語で「魂」のような1語に言い換えないでください — その語は*ペルソナ*として読まれますが、このエンジンの
+背後にある測定（105ラン、アイデンティティ宣言の有無でプロンプトを比較）の最大の発見は、まさにその2つが
+別物だということでした:「あなたは〜だ」を加えると、試した中で最も弱いモデルで*正味の損失*として現れ、
+それを取り除くと元に戻りました。1語の言い換えは、その測定が切り分けたものをそのまま再融合させてしまいます。
+数値そのものはここではあえて引用しません — 出典がスケールを記録しておらず、スケールの無い数値を表紙に
+置けばそれは装飾だからです。数値は文脈込みで
+[`ship_readiness_gate.md`](knowledge/shared/harness-core/ship_readiness_gate.md) にあります。また判断回路は
+一度に作られるものでもありません: FH は新しいハーネスに**種となる草案**を渡し、そのハーネスが実際に
+使われるなかで埋まっていきます。
+
+**3段工程** — これはメニューではなく*投資の順序*です:
+
+```
+① 設計の前に回路を        判断回路が最初に入ります — 成功 · 傾け方 · 範囲外 · 決してやらないこと —
+                          やったことの記録として後から書き起こすものではありません
+
+② 中間では脱相関して      作業を「違うかたちで失敗する」検査に分けて、一度に走らせます。どの違いが効くかを
+   加速する               選んでください — 同じ種類のレビュアーをもう1人足すのは脱相関ではなく、同じ盲点を
+                          2度持つだけです。並列化それ自体には方向がなく、選ぶのは①の判断回路です。
+                          これは「働き方」であって、③の最終検査ではありません。
+
+③ 最後に4つの軸で         下の4軸です。敵対的レビューはそのうちの1つであって、全部ではありません
+   焼き切る
+```
+
+**4つの検証軸** — 「レビューしました」が実際には最初の1つだけを指していた、と判明しがちな場所です。
+真ん中の列を読んでどれを取るかを決め、右の列でそれが何を捕まえるかを確かめてください:
+
+| 軸 | こういうときに手を伸ばす | 何を捕まえるか | 典型的な計器 |
+|---|---|---|---|
+| **ⓐ 別ファミリー** | その変更が何かを決めるとき — PASS/FAIL、ゲート、安全ルール | **実装**が間違っている | 別のモデルファミリーからのレビュアー (`auto-decorrelation`) |
+| **ⓑ 初の実使用** | 数値 · カウント · スキャンの出力を信じようとしているとき | **測り方**が間違っている | 実際の対象1件に対して一度走らせ、結果を自分の目で見る |
+| **ⓒ 記録のグラウンディング** | 他人がそれを元に動く主張 · 数値 · 引用を書き留めたとき | **主張**が間違っている | 書いていない誰かが、書かれている内容を測り直す |
+| **ⓓ 戻して観察する** | テスト · ガード · 検査を足して、それが自分を守っていると思っているとき | **アンカー**が間違っている — その検査は装飾だ | 守っている対象を消して、*その特定の*検査が赤くなることを確かめる |
+
+**4つを毎回すべて回すわけではなく、それが設計です。** 1行の修正はどれも要求しません。verdict を返す
+変更は ⓐ を要求します。公表する数値は ⓑ と ⓒ を要求します。新しいガードは ⓓ を要求します。不可逆な
+表面 — publish, delete, 履歴の書き換え — は、その失敗モードがさらしている軸を要求し、迷ったときは
+もう1つ回すほうに倒します。レビュアーを増やすことは、軸を1つ足すことと同じではありません。
+
+これら4つの外側に、もう1つの軸があります。それは*何を*検査するかではなく、*誰の*グラウンドトゥルースに
+立つかを変えるからです: **standpoint（立ち位置）** — 変更が別のハーネスへまたがるとき、自分の読み方では
+なく、対象側自身のレポとルールから diff を走らせてください
+([`field_verdict_crossfamily_gate.md §7`](knowledge/shared/harness-core/field_verdict_crossfamily_gate.md))。
+
+> **正直な注記 — これはきれいな積み木ではなく、そこが要点です。** 段階①と段階③はエンジンと同じ素材で
+> できているので、下の層が上の層を使っています。この矛盾は*主語*で解けます: **エンジン**は FH が
+> あなたの作業に適用するものであり、**工程**は FH が自分自身のエンジンを鍛えるときに使う順序です。
+> 手法を外から借りてきたのならエンジンとは無関係だったはずで、この重なりこそがドッグフーディングの
+> 指紋です。各主張の背後にある標本の限界を含む完全な正典:
+> [`fh_three_layer_canon.md`](knowledge/shared/harness-core/fh_three_layer_canon.md)。
+
+> **ここでのセルフヒーリングは主張ではありません — 確かめてください。** このレポの `git log` がその記録で
+> あり、同じ形が繰り返されます: 見落としが捕まり、その修正が攻撃され、そして攻撃は元のものではなく
+> *修正のほう*に当たることが多い。ハッシュで開けるものが1つ — `cb74ea4`、ハーネスがセッション途中で
+> レジスターをドリフトさせたあと、`CLAUDE.md §Voice/Tone` にレジスター一貫性のルールが加えられたコミット
+> です。もう1つは、この節を追加したのと同じ変更のなかで: 「何にも走らされていないテスト」を見つけるのが
+> 仕事そのものである検査器が、あるスクリプトの*自分自身のコメント*から緑のカウントを報告しているのが
+> 捕まり、さらにそれを直すために書かれたガード自体が、消しても失敗するテストを1つも持っていないことが
+> 判明しました — 見つけたのは著者ではなく別のモデルファミリーで、実際に失敗するフィクスチャを付けて
+> 閉じられました。フィーチャーブランチ上のコミットハッシュは squash-merge を生き延びないので、こちらは
+> 腐る ID ではなく「その形」で引用しています。
 
 ---
 
@@ -275,7 +432,10 @@ forge-harness はプロジェクトを鋼のように扱います — そして
 `agent-composer`（ディスパッチをオーケストレーション）。残りのスキルは必要になるまで待ちます — 全リストは
 下に。
 
-## 37 skills · 8 agents
+## 40 skills · 8 agents
+
+> カウント = 非 deprecated のスキル（旧名ルーティングのためだけに残されている deprecated
+> リダイレクトスタブは除外）。
 
 <details>
 <summary>全資産のアクティベーション確認</summary>
@@ -291,6 +451,7 @@ forge-harness はプロジェクトを鋼のように扱います — そして
 | `harness-doctor` | ハーネス構造の診断 | "Check my Claude setup" |
 | `pipeline-conductor` | 4軸品質ゲート (後方/敵対/前方/記録) | "Run the quality gate" |
 | `field-harvest` | フィールドパターンをハブへ逆伝播 | "I could reuse this" |
+| `dialogue-harvest` | AI 対話ログの採掘: 追従 (sycophancy) を剥がし、誘導された主張と独立した主張をラベル分け | "What did I actually contribute in this thread?" |
 | `frontier-digest` | HN + arXiv → 実行可能な洞察 | "AI trend digest" |
 | `hub-cc-pr-reviewer` | 自動 PR レビュー | "Review this PR" |
 | `verify-bidirectional` | 決定の逆検証 | "Is that right?", "Double-check" |
@@ -306,14 +467,24 @@ forge-harness はプロジェクトを鋼のように扱います — そして
 | `convergence-loop` *(fh-commons)* | N ラウンドの収束ループ | "Single-pass seems suspicious" |
 | `token-budget-gate` *(fh-commons)* | 作業前のトークンコスト推定 | "How expensive is this?" |
 | `mcp-circuit-breaker` *(fh-commons)* | MCP ツールの失敗パターン検知 | "MCP keeps failing" |
+| `ko-tech-writer` *(fh-commons)* | 韓国語テクニカルライティングのパイプライン（レジスターの較正、翻訳調の除去、正直さの層分け、知覚的 QA） | "기술문서 써줘", "번역투 고쳐줘" |
 | `quench-challenger` *(fh-commons)* | 敵対的プレッシャーテストエージェント | "Challenge this with a devil" |
-| *(+ 追加資産)* | 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` | 負荷を担う変更に対して別モデルファミリーのレビュアーを招集 | "Decorrelate this verification" |
+| `video-ingest` | 動画 → エージェント文脈へ、能力と長さでルーティング | "What does this video show?" |
+| `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` から始める |
+
+> このバンドはおおまかな自己点検であって、測定ではありません — 閾値を定義した成果物は存在せず、
+> 以前の固定された数値はもっと小さいロスターに対して較正されたものだったので、ロスターが増えるにつれて
+> 静かにずれていきました。スキルを多く使うこと自体も目標ではありません — 自分の作業が実際に必要と
+> するものを使うことが目標です。
 
 **やりたいことでスキルを探す:**
 
@@ -349,7 +520,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 に床）、環境が届けばその床ティアの
@@ -371,7 +542,12 @@ Claude Code は作業の複雑さでモデルを自動選択しません — こ
 > コストはセッション jsonl の `message.model` から CC で見られます。
 
 **主張ではなく測定**（実測例）: ブラインドのルール適用バッテリーで FH *運用*はほぼモデルフラットです —
-**測定したすべての Claude ティアが 94–100%**（Fable, Opus 4.8, Sonnet 4.6 と 5, Haiku 4.5）; 失った少数の点数は
+30点のブラインドバッテリー（2026-06-10）で走らせた4ティアは **94–100%** を記録し（最上位ティアのアンカー /
+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 で再アンカーされました。丸い1つの数字ではなく、正直な注記を2つ: 出典の成果物は
+最上位ティアの名前を意図的に伏せているので、このページでも名前を出しません。そして**現在の**最上位ティアは
+このバッテリーで走らせていません — 先に持ち越されるのは下のドクトリンであって、スコアではありません。
+失った少数の点数は
 フォーマットの規律であって、罠やゲート級のミスではありません。ティアが分かれるのはルーブリック超過の*設計*
 増分だけ（ハーネスを開発するのであって運用するのではない）— だから既定値が**ティア床ディスパッチ**で深さに
 敏感なターンを覆う Sonnet であり、固定された強いモデルはハーネス編集セッションにのみ推奨されます。
@@ -431,7 +607,8 @@ 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"** · 準備中。
 
 外部の収束: