@chrono-meta/fh-gate 1.4.98 → 2.0.0

package/README.md

@@ -67,7 +67,9 @@
 The consent-registry gate parses YAML, and it **fails closed** when it cannot — correctly, since an
 unvalidated consent record must not read as a clean one. But that fail-closed turns the whole of
 `npm test` (and `prepublishOnly`) red on a machine without PyYAML, and until 2026-08-12 the
-requirement was written down **nowhere**:
+requirement was written down **nowhere**. It is written here now — and, as of this edit, *only*
+here: it is still absent from `package.json`, the cheatsheet and every other doc, so this block is
+the single place a new machine can learn it. That is an improvement over nowhere, not a fix:
 
 ```bash
 python3 -m pip install --user pyyaml     # verify:  python3 -c 'import yaml; print(yaml.__version__)'
@@ -183,35 +185,146 @@ them evolve together instead of scattering.
 This galaxy is more than a container. FH can run a field harness **in simulation inside its own
 sandbox** — expensive per run, cheaper in total, because the trial-and-error pools in one place and
 compounds — and when the simulation holds, it **emits** the project as an independent, specialized
-harness. That is the goal it is built toward. In practice it works in four ways:
+harness. **That last step is the goal it is built toward, not a shipped feature** — the incubation
+chamber has emitted once, and the run that produced it did not go through the full flow. Read the
+simulate-and-emit sentence as direction of travel; everything before it is in use today.
 
-**① Assemble** — FH runs a *cluster* of harnesses at optimized token cost and hands you the right one for
-the project. You don't wire up skills one by one; you get a **harness** — its plugins, skills, and agents
-included — assembled to fit.
+### The five identities — what FH is for
 
-**② Forge** *(the quality gate)* — every change earns its way through adversarial · phantom · regression
-gates. This is not "check more." It is a **responsibility router**: as automation rises, human sign-offs
-get fewer but heavier, so the gate spends your attention only where a change is *irreversible*. Quality is
-the lever; the speed is the result.
+These are not five modules, and they are not five shipped features either. They are the **shapes the
+skills clump into** — the name of something that was already there, spread across the skills and agents
+rather than layered on top of them. They sit at a different level from the problem table at the top of
+this page: that table is *symptoms you might arrive with*, this is *what the hub is organized around*.
 
-**③ Sidecar** — capability itself stays on the frontier. FH dispatches across multiple LLMs (Claude,
-Codex, Gemini, local) so raw power is never tied to one model or one generation. The point is *not*
-patching each model's weak spots — that scaffolding dies as models improve. It is **riding the frontier's
-evolution**: shed what the substrate now does natively, absorb what it ships next. Decorrelation is
-today's trust lever (a cross-family panel beats a single model's ceiling); co-evolution is the structure.
-
-**④ Self-evolving loop** — the harness gets better without being rebuilt, in two directions: **outward**,
-where each session's lessons compound into the hub so the next project starts faster, and **inward**,
-where it catches and repairs *its own* defects (the 4-axis gate, bidirectional verify, per-user
-adaptation).
+| | Identity | What a person gets |
+|---|---|---|
+| **①** | **Multi-harness cluster** | One task rides several harnesses, and governance is computed *between* them |
+| **②** | **Project incubator** | A new harness comes out **walking where it was born**, not as an empty scaffold |
+| **③** | **Governance gate** | What must not ship is blocked **mechanically**, not by remembering to check |
+| **④** | **Frontier → org propagation** | What arrives from outside lands all the way *inside* the organization |
+| **⑤** | **Amplifier** | A short intent gets forged all the way to the finished artifact |
+
+**They are not equally finished, and you should not read the table as five working features.** Maturity is
+tracked per identity on a four-step scale — `aspirational → partial → RC (stood up in the lab) → REALIZED
+(walked outside)` — with a dated line of evidence for each. Those grades are deliberately **not** copied
+here: a grade kept in two files goes stale in one, and this page exists in four languages, so a copy here
+would be four copies. Before you rely on any row above, read the current grades — that is one file:
+[`ship_readiness_gate.md`](knowledge/shared/harness-core/ship_readiness_gate.md). The short version if you
+only want one sentence, as of **2026-08-15**: **③ and ⑤ are graded green — demonstrated outside the lab;
+①, ② and ④ are release candidates — built and calibrated, not yet shown to walk in someone else's hands.**
+If that sentence and the gate file disagree, the gate file is right and this line is stale.
+
+Two properties cut across all five, and neither is a feature you switch on:
+
+- **It rides the frontier instead of patching it.** FH dispatches across families (Claude, Codex, Gemini,
+  local) — but the point is *not* papering over each model's weak spots, because that scaffolding dies as
+  models improve. It is co-evolution: shed what the substrate now does natively, absorb what it ships
+  next. **Decorrelation** is today's trust lever, and it is the load-bearing word on this page:
+  deliberately making two checks fail *differently* — a reviewer from another model family, a run against
+  a real target, an outside audit of your own record — so that what one is blind to, another is not.
+  A cross-family panel beats a single model's ceiling for exactly that reason, not because it is bigger.
+- **It evolves in two directions.** *Outward*, each session's lessons compound into the hub so the next
+  project starts further along. *Inward*, it catches and repairs **its own** defects — the same gates,
+  turned on the harness itself.
 
 The whole thing is a division of labor: **raw capability is the model's; assembly, trust, and evolution
 are the harness's.**
 
-> **Self-healing here isn't a claim — it's in the commit log.** This very README's voice rules were fixed
-> mid-session by FH catching its own drift: a tone miss → diagnosis → a cross-family challenger that
-> attacked *its own first fix* → re-fix → floor-tier re-verification → memory update. A harness repairing
-> its own defect, on the record — not a slogan.
+---
+
+## How it is built — process → engines → identity
+
+The five identities above are the surface. Two layers sit under them, and naming all three is what keeps
+"what FH does" from collapsing into one undifferentiated pile:
+
+```
+five identities   what a person can actually use          (surface — what you get)
+      ↑ backed by
+four engines      the capability that makes it possible   (capability — what it can do)
+      ↑ produced by
+three-stage       the ORDER those engines are forged in   (process — how it gets made)
+  process
+```
+
+**The four engines.** Each one is what some identity above is standing on. They were not invented for this
+page: the readiness gate had already been scoring every identity against these same four capabilities in a
+column of its own ([`ship_readiness_gate.md`](knowledge/shared/harness-core/ship_readiness_gate.md)), so
+naming them was recognition rather than taxonomy-building.
+
+| Engine | What it is | Identities it backs |
+|---|---|---|
+| `judgment-circuit` | what counts as success, which way to lean under uncertainty, what is out of scope, what never happens | ⑤ Amplifier · ② Incubator |
+| `ship-gate` | mechanical blocking before an irreversible surface — commit, publish, delete, rewrite | ③ Governance gate |
+| `context-continuity` | not losing the thread across compaction, sub-agents, machines, sessions | ① Cluster · ② Incubator |
+| `external-grounding` | reaching outside the repo *before* asserting novelty or settling a design | ④ Frontier → org |
+
+They are written by name, never by number — the table order here and the prose order elsewhere differ, so
+"engine ④" decodes to two different engines depending on which you read.
+
+`judgment-circuit` is the one that gets misread most, so state it flatly: **it is a coordinate system for
+deciding, not a statement of who the harness is.** The four items in its row are the whole of it. Do not
+shorten it to "the harness's soul" in English either — that word reads as *persona*, and the largest
+finding of the measurement behind this engine (105 runs, comparing prompts with and without an identity
+declaration) was precisely that the two are different things: adding *"you are a ~"* came out a **net loss**
+on the weakest model tested, and taking it out recovered ground. A one-word rename re-fuses exactly what
+that measurement separated. The figure itself is deliberately not quoted here — the source records it
+without a scale, and an unscaled number on a front page is decoration; it is in
+[`ship_readiness_gate.md`](knowledge/shared/harness-core/ship_readiness_gate.md) with its context. Nor is
+a judgment circuit built in one sitting: FH hands a new harness a **seed draft**, and it fills in as that
+harness is actually used.
+
+**The three-stage process** — this is an *order of investment*, not a menu:
+
+```
+① Circuit before design   the judgment circuit goes in FIRST — success · leaning · out-of-scope ·
+                          never-do — not written up afterwards as a record of what you did
+
+② Decorrelate in the      split the work into checks that fail DIFFERENTLY and run them at once.
+   middle, to accelerate  Choose which differences matter — a second reviewer of the same kind is
+                          not decorrelation, it is the same blind spot twice. Parallelism has no
+                          direction of its own; the judgment circuit from ① is what picks.
+                          This is a way of WORKING, not the end-of-line check in ③.
+
+③ Burn it down at the     the four axes below. Adversarial review is ONE of them, not all of them
+   end, on four axes
+```
+
+**The four verification axes** — where "we reviewed it" usually turns out to mean only the first of them.
+Read the middle column to pick one, and the right column to see what it catches:
+
+| Axis | Reach for it when… | What it catches | Typical instrument |
+|---|---|---|---|
+| **ⓐ Different family** | the change decides something — a PASS/FAIL, a gate, a safety rule | the **implementation** is wrong | a reviewer from another model family (`auto-decorrelation`) |
+| **ⓑ First real use** | you are about to trust a number, a count, or a scan's output | the **way you are measuring** is wrong | run it once against one real target and look at the result by hand |
+| **ⓒ Record grounding** | you wrote down claims, figures or citations others will act on | the **claim** is wrong | someone who did not write it re-measures what it says |
+| **ⓓ Revert and observe** | you added a test, a guard or a check and believe it protects you | the **anchor** is wrong — the check is decorative | delete the thing it guards and confirm *that specific* check goes red |
+
+**You do not run all four every time, and that is the design.** A one-line fix earns none of them; a change
+that returns a verdict earns ⓐ; a published number earns ⓑ and ⓒ; a new guard earns ⓓ; an irreversible
+surface — publish, delete, history rewrite — earns whichever of the four its failure mode exposes, and the
+benefit of the doubt goes to running one more. Multiplying reviewers is not the same as adding an axis.
+
+One further axis sits outside this four because it changes *whose* ground truth you stand on rather than
+*what* you check: **standpoint** — when a change crosses into another harness, run the diff from the
+target's own repo and rules, not from your reading of them
+([`field_verdict_crossfamily_gate.md §7`](knowledge/shared/harness-core/field_verdict_crossfamily_gate.md)).
+
+> **Honest note — this is not a clean stack, and that is the point.** Stage ① and stage ③ are made of the
+> same material as the engines, so the lower layer uses the upper one. The contradiction resolves on
+> *subject*: the **engines** are what FH applies to your work, while the **process** is the order FH uses
+> when forging its own engines. If the method had been borrowed from outside it would be unrelated to the
+> engines; the overlap is the fingerprint of dogfooding. Full canon, including the sample limits behind
+> each claim: [`fh_three_layer_canon.md`](knowledge/shared/harness-core/fh_three_layer_canon.md).
+
+> **Self-healing here isn't a claim — check it.** `git log` in this repo is the record, and the shape
+> repeats: a miss is caught, the fix is attacked, and the attack often lands on the fix rather than on the
+> original. One you can open by hash — `cb74ea4`, where a register-consistency rule was added to
+> `CLAUDE.md §Voice/Tone` after the harness drifted register mid-session. A second, in the same change
+> that added this section: a checker whose whole job is finding tests nothing runs was caught reporting a
+> green count off a script's *own comment*, and then the guard written to fix that turned out to have no
+> test that would fail if it were deleted — found by a different model family, not by the author, and
+> closed with a fixture that does fail. Commit hashes on feature branches do not survive squash-merge, so
+> that one is cited by its shape rather than by an ID that would rot.
 
 ---
 
@@ -345,13 +458,21 @@ two more signatures keep it running: `harvest-loop` (each session's lessons beco
 | `mcp-circuit-breaker` *(fh-commons)* | MCP tool failure pattern detection | "MCP keeps failing" |
 | `ko-tech-writer` *(fh-commons)* | Korean technical-writing pipeline (register calibration, translationese removal, honesty layering, perceptual QA) | "기술문서 써줘", "번역투 고쳐줘" |
 | `quench-challenger` *(fh-commons)* | Adversarial pressure-test agent | "Challenge this with a devil" |
-| *(+ additional assets)* | 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` | Recruits a different-model-family reviewer for load-bearing changes | "Decorrelate this verification" |
+| `video-ingest` | Video → agent context, routed by capability and length | "What does this video show?" |
+| `fh` | Renders the hub map on demand, without a greeting | "fh" |
+| *(+ remaining skills)* | marketplace-gate · contention-layer · deliberation · edit-manifest · goal-quench · install-doctor · memory-hygiene · prompt-regression · public-surface-audit · return-path-gate · salience-splitter | |
+| **8 agents** | `challenger` · `quench-challenger` (adversarial) · `beginner` · `main-player` · `expert` (the user-mastery spectrum — cold read, daily use, domain authority) · `fact-checker` · `hub-persona-auditor` · `persona-innovator` | dispatched by the skills above, or by name |
 
 | Active count | Diagnosis |
 |:---:|---|
-| **28+** | Advanced — chain agent-composer + sim-conductor + steel-quench + pipeline-conductor |
-| **10–27** | Activation stage — gradually enable unchecked assets |
-| **0–9** | Early stage — start with `install-wizard` |
+| **~half the surface or more** | Advanced — chain agent-composer + sim-conductor + steel-quench + pipeline-conductor |
+| **a handful up to that** | Activation stage — gradually enable unchecked assets |
+| **almost none** | Early stage — start with `install-wizard` |
+
+> These bands are a rough self-check, not a measurement — no artifact defines the thresholds, and the
+> earlier fixed numbers were calibrated against a smaller roster, so they quietly drifted as the roster
+> grew. Using more skills is also not the goal; using the ones your work actually needs is.
 
 **Find a skill by what you're trying to do:**
 
@@ -387,7 +508,7 @@ Claude Code does not auto-select models by task complexity — you configure thi
 | `/model opus` | Opus handles everything | Harness-editing sessions (Mode D) · maximum depth on every turn |
 | `/model opusplan` | Opus *plans* · Sonnet executes *(when Opus engages)* | Cost-conscious routine coding — see caveat |
 
-**Why default Sonnet now works**: measured (see §Model setup evidence note below), *operating* FH is
+**Why default Sonnet now works**: measured (see *Measured, not asserted* below), *operating* FH is
 nearly model-flat — the rules in context do most of the work. What still needs a stronger model is a
 small set of depth-sensitive turns, and FH handles those itself: **some skills and agents declare a
 model-tier floor** (e.g. `quench-challenger` floors at opus) and are dispatched as sub-agents at the
@@ -408,8 +529,13 @@ dispatch's own `model` parameter; the session model/plan-mode does **not** propa
 > does not. Sub-agent token costs are CC-visible in the session jsonl under `message.model`.
 
 **Measured, not asserted** (worked examples): on a blind rule-application battery, *operating* FH is
-near model-flat — **every Claude tier measured scores 94–100%** (Fable, Opus 4.8, Sonnet 4.6 and 5,
-Haiku 4.5); the few lost points are format discipline, never a trap or gate-class miss. The tiers
+near model-flat — on a 30-point blind battery (2026-06-10) the four tiers run scored **94–100%**
+(top-tier anchor / Opus 4.8 / Sonnet 4.6 / Haiku 4.5 = 100 / 100 / 97 / 94), and a 2026-07-03
+replication re-anchored Opus 4.8, **Sonnet 5** and Haiku 4.5 at 16/16 each. Two honesty notes rather
+than one round number: the source artifact deliberately leaves the top tier unnamed, so this page does
+not name it either; and the **current** top tier has not been run on this battery — the doctrine below
+is what carries forward, not the scores. The few lost points are format discipline, never a trap or
+gate-class miss. The tiers
 separate only on above-rubric *design* increments (developing the harness, not running it) — which is
 why the default is Sonnet with **tier-floored dispatch** covering the depth-sensitive turns, and a
 pinned stronger model is recommended only for harness-editing sessions.
@@ -471,7 +597,7 @@ Claude-side token cost does not increase when the extra reviewer is an external
 
 > **FH papers** — the methodology below is documented, not just asserted:
 > - **v1.0 — methodology** · [Zenodo](https://zenodo.org/records/20397566) (DOI 10.5281/zenodo.20397566). 2-layer design, 6-axis framework, 4-agent orchestration, and the compounding loop, with empirical evidence.
-> - **cs.SE companion — governance-gate methodology** · **published** [Zenodo](https://zenodo.org/records/20680081) (DOI 10.5281/zenodo.20680081 · latest v1.1 10.5281/zenodo.20740038 · CC-BY-4.0) · arXiv submitted (cs.SE, in moderation).
+> - **cs.SE companion — governance-gate methodology** · **published** [Zenodo](https://zenodo.org/records/20680081) (DOI 10.5281/zenodo.20680081 · latest v1.1 10.5281/zenodo.20740038 · CC-BY-4.0) · arXiv submitted (cs.SE); the moderation outcome is not tracked in this repo, so treat "submitted" as the last state this page can vouch for, not as current.
 > - **cs.AI companion — "Governance Dividend"** · in preparation.
 
 External convergence:

package/README.zh.md

@@ -62,21 +62,55 @@
 
 **前置条件**：Claude Code CLI —— 用 `claude --version` 确认
 
+<details><summary><b>可选：有一道门禁需要 Python + PyYAML</b> —— 少了它 <code>npm test</code> 是红的</summary>
+
+同意登记表 (consent-registry) 那道门禁要解析 YAML，而当它解析不了时会 **fail closed** —— 这是对的，
+因为一条未经校验的同意记录绝不该读起来像一条干净的记录。但这个 fail-closed 会让整个 `npm test`
+（以及 `prepublishOnly`）在没装 PyYAML 的机器上变红，而直到 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}/`。
+> 想做完整的初始设置（hooks · 门禁 · 基线 —— 每一项单独批准，拒绝会被尊重并记录），
+> 请要 **`/install-wizard`**。
+> 已经克隆到别的地方了？那个路径 *就是* 你的中枢 —— 把文档里每一处 `~/projects/forge-harness`
+> 都读成你实际的克隆路径。
+
+**你的头 15 分钟** —— 成功长什么样，以及拿它做什么：
+
+1. 当一句招呼（"hi"）能让 🐿️ 门菜单出现、而"连接一个项目"能建出 `tracks/{your-project}/` 时，
+   你就知道设置成功了。
+2. 然后在同一个会话里拿下一个即时收益：说 **"加速这个项目"**（一份值得接线的技能/插件排序方案，
+   安装要过门禁），或者 **"跑一下 /context-doctor"**（token 浪费扫描）。
+3. 一条诚实说明：FH 的核心回报是 **复利累积** —— 会话记录、收割来的学习、跨会话记忆。它从
+   **第 2 个会话起** 才显形。第一天给你的是菜单、加速方案和治理门禁；别在第一天就去评判复利。
+
+路上碰到不认识的词？→ [`knowledge/shared/GLOSSARY.md`](knowledge/shared/GLOSSARY.md)。
 
 **仅插件（不克隆）：**
 ```bash
@@ -85,14 +119,19 @@ claude plugin install -s user fh-meta@forge-harness
 cd ~/projects/{your-project} && claude
 ```
 
-> ⚠️ **仅插件是部分协同。** 你得到技能和 agent，但 **得不到** Layer 1 —— 即
-> `CLAUDE.md` 治理（主动引导、4 轴门禁、模式分支）和复利式上下文（`tracks/` 记忆累积、
-> `harvest-loop` 学习）。每个技能在隔离状态下运行效果相同；缺的是让它们在会话之间
-> 复利累积的编排。当你想要完整套装而不只是工具时，请克隆中枢（见上）。
+> ⚠️ **仅插件是部分协同。** 你得到技能和 agent，但 **得不到** 中枢那一侧的编排 —— 即
+> `CLAUDE.md` 治理（主动引导、4 轴门禁、模式分支；自动化层）和复利式上下文（`tracks/` 记忆
+> 累积、`harvest-loop` 学习；方法论层）。每个技能在隔离状态下运行效果相同；缺的是让它们在
+> 会话之间复利累积的那层编排。当你想要完整套装而不只是工具时，请克隆中枢（见上）。
 
-> 🚪 **初来乍到 / 只想要技能？** 从有主张的正门开始 ——
-> [`templates/starter_profile.md`](templates/starter_profile.md)：一条安装命令、一份精选的
-> 头五个技能，以及一道零安装的治理门禁（`npx … fh-gate`）。其余技能等你需要时再出场。
+**哪条入口适合你？**
+
+| 你是…… | 从这里开始 |
+|---|---|
+| 单人开发者，一个项目，只想先试试 | [`templates/starter_profile.md`](templates/starter_profile.md) —— 一条命令，一份精选的头五个技能 |
+| 有多个项目，想要那个复利累积的中枢 | 克隆中枢（见上面的快速上手） |
+| 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` 找不到它） |
 
 ---
 
@@ -137,30 +176,135 @@ Project B  ──→  在 CLAUDE.md 中连接中枢
 
 这个星系不只是容器。FH 可以在自己的沙箱里**以仿真方式跑一个现场框架** —— 单次昂贵，总体
 更便宜，因为试错汇聚在一处并复利累积 —— 当仿真验证通过，它就把该项目**输出 (emit)** 为一个
-独立的、特化的框架。这就是它所朝向的目标。实际上，它以四种方式运作：
-
-**① 组装 (Assemble)** —— FH 以优化后的 token 成本运行一整 *簇* 框架，并把最合适的那个交到你手上。
-你不是一个个去接线技能；你得到的是一个 **框架** —— 连同它的插件、技能与 agent —— 已按需组装好。
+独立的、特化的框架。**最后那一步是它所朝向的目标，而不是一项已出货的功能** —— 孵化舱迄今输出过
+一次，而产出那一次的运行并没有走完整套流程。请把"仿真然后输出"这句读作行进方向；在它之前的一切
+都是今天就在用的。
 
-**② 锻造 (Forge)** *(品质门禁)* —— 每次变更都要穿过对抗 · 幽灵 · 回归门禁来挣得它的资格。
-这不是"多检查"。它是一个 **责任路由器 (responsibility router)**：随着自动化上升，人的签字变少但
-每一次更重，于是门禁只把你的注意力花在变更 *不可逆* 的地方。品质是杠杆；速度是结果。
+### 五重身份 —— FH 是为了什么
 
-**③ 边车 (Sidecar)** —— 能力本身留在前沿。FH 跨多个 LLM（Claude、Codex、Gemini、本地）派发，
-使原始算力永不绑死在单一模型或单一世代上。重点 *不是* 去修补每个模型的弱点 —— 随着模型变强，
-那套脚手架会成为死代码。重点是 **搭上前沿的演化**：底座 (substrate) 现在原生就能做到的就卸掉，
-它接下来推出的就吸收进来。去相关 (decorrelation) 是当下的信任杠杆（跨家族面板胜过单一模型的
-上限）；共同演化 (co-evolution) 才是结构。
+这不是五个模块，也不是五项已出货的功能。它们是 **技能自然聚拢成的形状** —— 是给一个早已存在的
+东西命名，它散布在各个技能与 agent 之中，而不是叠加在它们之上。它们和本页开头那张问题表处在不同
+的层次：那张表是 *你可能带着来的症状*，这里是 *中枢围绕什么组织起来*。
 
-**④ 自演化循环 (Self-evolving loop)** —— 框架无需重建就变得更好，沿两个方向：**向外**，
-每次会话的教训复利汇入中枢，让下一个项目起步更快；**向内**，它捕捉并修复 *自身* 的缺陷
-（4 轴门禁、双向校验、按用户适配）。
+| | 身份 | 一个人得到什么 |
+|---|---|---|
+| **①** | **多框架集群 (Multi-harness cluster)** | 一个任务同时驾驭多个框架，而治理是在它们 *之间* 算出来的 |
+| **②** | **项目孵化器 (Project incubator)** | 新框架出炉时 **就已经会走路**，而不是一副空的脚手架 |
+| **③** | **治理门禁 (Governance gate)** | 不该出货的东西被 **机械地** 拦下，而不是靠记得去检查 |
+| **④** | **前沿 → 组织传导 (Frontier → org propagation)** | 从外部到来的东西，一路落进组织 *内部* |
+| **⑤** | **放大器 (Amplifier)** | 一句简短的意图被一路锻造到成品 |
+
+**它们完成度并不齐平，你也不该把上面那张表读成五项能用的功能。** 成熟度按身份逐项跟踪，用一把
+四级刻度 —— `aspirational（构想）→ partial（部分）→ RC（在实验室里立起来了）→ REALIZED（走到
+外面去了）` —— 每一级都配一条带日期的证据。这些等级刻意 **没有** 被复制到这里：同一个等级放进
+两个文件，总会有一个先腐坏，而本页有四种语言版本，复制到这里就等于四份副本。在你依赖上表任何
+一行之前，请先读当前的等级 —— 那只有一个文件：
+[`ship_readiness_gate.md`](knowledge/shared/harness-core/ship_readiness_gate.md)。如果你只想要
+一句话的版本，截至 **2026-08-15**：**③ 与 ⑤ 是绿灯 —— 已在实验室之外得到验证；①、② 与 ④ 是
+候选发布 (RC) —— 已造出并校准，但还没在别人手上走过。** 如果这句话和那个门禁文件对不上，以门禁
+文件为准，这一行就是过期的。
+
+有两条性质横贯这五重身份，而且都不是你可以打开的开关：
+
+- **它搭上前沿，而不是给前沿打补丁。** FH 跨家族派发（Claude、Codex、Gemini、本地）—— 但重点
+  *不是* 去糊住每个模型的弱点，因为随着模型变强，那套脚手架会死掉。它是共同演化 (co-evolution)：
+  底座 (substrate) 现在原生就能做到的就卸掉，它接下来推出的就吸收进来。**去相关 (decorrelation)**
+  是当下的信任杠杆，也是本页最吃重的那个词：刻意让两道检查以 *不同的方式* 失败 —— 换一个模型家族
+  的审阅者、拿真实目标真跑一次、请外人来审你自己的记录 —— 好让其中一道看不见的，另一道看得见。
+  跨家族面板胜过单一模型的上限，正是因为这个，而不是因为它人多。
+- **它沿两个方向演化。** *向外*，每次会话的教训复利汇入中枢，让下一个项目起步更靠前。*向内*，
+  它捕捉并修复 **自身** 的缺陷 —— 同一套门禁，掉转过来对准框架本身。
 
 整件事是一次分工：**原始能力属于模型；组装、信任与演化属于框架。**
 
-> **这里的自愈不是一句主张 —— 它就在提交日志里。** 正是这份 README 的语气规则，在会话进行中
-> 被 FH 抓到自身漂移而修正：语气失误 → 诊断 → 一位攻击 *它自己第一版修正* 的跨家族 challenger
-> → 再修正 → 下限层级复核 → 记忆更新。一个框架修复自身缺陷的实录 —— 是记录，不是口号。
+---
+
+## 它是怎么被造出来的 —— 工序 → 引擎 → 身份
+
+上面那五重身份是表面。它们下面还压着两层，而把三层各自命名，正是让"FH 到底做什么"不至于塌缩成
+一堆不分彼此的东西的关键：
+
+```
+五重身份   一个人真正能用到的东西         （表面 —— 你得到什么）
+      ↑ 由此支撑
+四大引擎   让它成为可能的那份能力         （能力 —— 它能做什么）
+      ↑ 由此产出
+三段工序   那些引擎被锻造出来的「顺序」    （工序 —— 它是怎么被造出来的）
+```
+
+**四大引擎。** 每一个都是上面某个身份所站立的地基。它们不是为这一页发明出来的：出货就绪门禁
+（[`ship_readiness_gate.md`](knowledge/shared/harness-core/ship_readiness_gate.md)）早就用一个独立
+的列，按这同样四项能力给每一重身份打分，所以给它们命名是识别，而不是搭一套分类法。
+
+| 引擎 | 它是什么 | 它支撑的身份 |
+|---|---|---|
+| `judgment-circuit` | 什么算成功、不确定时往哪边偏、什么不在范围内、什么绝不发生 | ⑤ 放大器 · ② 孵化器 |
+| `ship-gate` | 在不可逆的面之前机械拦截 —— commit、publish、delete、rewrite | ③ 治理门禁 |
+| `context-continuity` | 跨压缩、子 agent、机器与会话，不把线头弄丢 | ① 集群 · ② 孵化器 |
+| `external-grounding` | 在断言"这是新的"或敲定一份设计 *之前*，先伸到仓库之外去问 | ④ 前沿 → 组织 |
+
+它们只写名字，绝不写编号 —— 这里的表格顺序和别处行文里的顺序并不一致，所以"引擎 ④"会因为你读
+的是哪一份而解码成两个不同的引擎。
+
+`judgment-circuit` 是最容易被误读的一个，所以直说：**它是一套用来做决定的坐标系，而不是一句
+"这个框架是谁"的宣言。** 它那一行里的四项，就是它的全部。也不要把它简写成英文里的 "soul"
+（或中文的"灵魂"）—— 那个词读起来是 *人设 (persona)*，而这个引擎背后那次测量（105 次运行，
+对比有无身份宣言的提示词）最大的一项发现恰恰是：这两者是两样东西 —— 加上"你是一个 ~"在测过的
+最弱模型上是 **净损失**，把它拿掉反而把分数找了回来。一个词的改名，会把那次测量刚刚分开的东西
+重新焊回去。那个数字本身刻意没有引在这里 —— 源产物记录它时没有带刻度，而一个没有刻度的数字放在
+门面页上只是装饰；它连同上下文在
+[`ship_readiness_gate.md`](knowledge/shared/harness-core/ship_readiness_gate.md) 里。判断坐标系
+也不是一次坐下就能建成的：FH 交给一个新框架的是一份 **种子草稿**，随着那个框架被真正用起来而
+逐步填满。
+
+**三段工序** —— 这是一个 *投入的顺序*，不是一份菜单：
+
+```
+① 设计之前先立坐标系     判断坐标系「最先」进场 —— 成功 · 偏向 · 不在范围 · 绝不做 ——
+                        而不是事后补写成一份"我做了什么"的记录
+
+② 中段做去相关，用来加速  把工作拆成会以「不同方式」失败的检查，然后一次性跑掉。要挑「哪些
+                        差异算数」—— 再来一位同一种类的审阅者不是去相关，那是把同一个盲点
+                        看两遍。并行本身没有方向，挑方向的是 ① 里那套判断坐标系。
+                        这是一种「工作方式」，不是 ③ 里那道收尾检查。
+
+③ 最后在四条轴上烧一遍    也就是下面那四条轴。对抗审阅只是其中一条，不是全部
+```
+
+**四条验证轴** —— 所谓"我们审过了"，往往到头来只做了其中第一条。看中间那列来挑一条，看右边那列
+知道它能抓到什么：
+
+| 轴 | 什么时候该伸手拿它…… | 它抓到什么 | 典型手段 |
+|---|---|---|---|
+| **ⓐ 不同家族** | 这次变更要「决定」什么 —— 一个 PASS/FAIL、一道门禁、一条安全规则 | **实现** 错了 | 换一个模型家族的审阅者（`auto-decorrelation`） |
+| **ⓑ 首次真实使用** | 你正要去相信一个数字、一个计数，或某次扫描的输出 | **你测量的方式** 错了 | 拿一个真实目标真跑一次，然后用眼睛看那份结果 |
+| **ⓒ 记录接地** | 你写下了别人会据以行动的主张、数字或引用 | **主张** 错了 | 找一个没写过它的人，把它说的重新测一遍 |
+| **ⓓ 撤回并观察** | 你加了一个测试、一道守卫或一项检查，并相信它在护着你 | **锚** 错了 —— 那道检查是装饰 | 把它所守护的东西删掉，确认 *正是那一条* 检查变红 |
+
+**你不必每次都把四条跑满，这是设计如此。** 一行小修一条都不配；一次会返回判定的变更配得上 ⓐ；
+一个已经公开出去的数字配得上 ⓑ 加 ⓒ；一道新加的守卫配得上 ⓓ；而一个不可逆的面 —— publish、
+delete、history rewrite —— 配得上四条里它的失败模式所暴露的那些，并且拿不准时就多跑一条。多堆
+几位审阅者，跟多加一条轴不是一回事。
+
+还有一条轴坐在这四条之外，因为它换掉的是 *你站在谁的地面上*，而不是 *你检查什么*：**立场
+(standpoint)** —— 当一次变更跨进另一个框架时，从目标方自己的仓库与规则去跑这份 diff，而不是
+从你对它们的理解出发
+（[`field_verdict_crossfamily_gate.md §7`](knowledge/shared/harness-core/field_verdict_crossfamily_gate.md)）。
+
+> **诚实说明 —— 这不是一个干净的分层，而这正是重点。** 工序 ① 和 ③ 与引擎是同一种材料做的，
+> 所以下面那层用到了上面那层。这个矛盾在 *主语* 上化解：**引擎** 是 FH 施加于你的工作的东西，
+> 而 **工序** 是 FH 锻造自己那些引擎时所用的顺序。如果这套方法是从外面借来的，它本该与引擎毫无
+> 关系；这份重叠正是自己吃自己狗粮 (dogfooding) 留下的指纹。完整正典，含每条主张背后的样本
+> 限制：[`fh_three_layer_canon.md`](knowledge/shared/harness-core/fh_three_layer_canon.md)。
+
+> **这里的自愈不是一句主张 —— 你去查。** 本仓库的 `git log` 就是那份记录，而且形状是重复的：
+> 一个失误被抓到，修正被攻击，而那次攻击往往落在 *修正本身* 而不是原来的问题上。有一个你可以
+> 按哈希打开 —— `cb74ea4`：框架在会话进行中漂了语域，之后一条语域一致性规则被加进
+> `CLAUDE.md §Voice/Tone`。第二个例子就发生在加入本节的那次变更里：一个专职找出"没人跑的测试"
+> 的检查器，被抓到它报的绿色计数是从某个脚本 *自己的注释* 里读出来的；而为修这一点写下的守卫，
+> 又被发现「把它删掉也不会有任何测试变红」—— 这是另一个模型家族发现的，不是作者自己，最后用一条
+> 真的会失败的 fixture 收口。特性分支上的提交哈希熬不过 squash-merge，所以第二个例子按它的形状
+> 引用，而不是给一个会腐烂的 ID。
 
 ---
 
@@ -239,6 +383,18 @@ hooks 不会自动触发，M2 的 agent 派发步骤需要适配器（或交互
 当前门禁语义将其归为 BLOCKED：2 项 CI 未捕获的 A 级发现（允许列表中的短 token 溢出、arity
 表中缺失的 executor 工具）。
 
+**这套方法本身到底加了什么？一次实测（2026-07-14）。** 我们把模型固定在一个中等层级的下限上，
+只改变审阅 *方法*，对象是没见过的门禁代码片段，里面被植入了 *默认偏向 PASS*（fail-open）的洞。
+在八个隐晦的洞上 —— 由另外两个模型撰写，所以这套测试集并没有对着我们的方法调过 —— 一次普通的
+审阅抓到 5/8（而且其中两次"抓到"抓错了 bug，也就是假信心）；同一个模型配上 FH 的降级方向
+(degrade-direction) 透镜抓到 6/8，零误报。诚实的那部分是：**两条单模型的路线漏掉的是同样那两个
+洞**（一个假值的 error sentinel，以及一处分隔符取反的解析）。换一个模型家族、同一套透镜，两个
+都抓到了 —— 所以 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)
 
 ---
@@ -260,7 +416,9 @@ forge-harness 把项目当作钢来对待 —— 而这个隐喻是字面的，
 签名部件让它持续运转：`harvest-loop`（每次会话的教训成为永久技能）与
 `agent-composer`（编排派发）。其余技能等你需要时再出场 —— 完整清单见下。
 
-## 37 skills · 8 agents
+## 40 skills · 8 agents
+
+> 计数 = 未废弃的技能（仅为旧名路由而保留的废弃重定向桩不计入）。
 
 <details>
 <summary>全部资产激活检查</summary>
@@ -276,6 +434,7 @@ forge-harness 把项目当作钢来对待 —— 而这个隐喻是字面的，
 | `harness-doctor` | 框架结构诊断 | "检查我的 Claude 配置" |
 | `pipeline-conductor` | 4 轴品质门禁（后向/对抗/前向/记录） | "跑品质门禁" |
 | `field-harvest` | 把现场模式反向传回中枢 | "这个我能复用" |
+| `dialogue-harvest` | 挖掘 AI 对话记录：剥掉迎合、标注「被诱导」vs「自发」 | "这个线程里到底哪些真是我自己的？" |
 | `frontier-digest` | HN + arXiv → 可执行洞见 | "AI 趋势摘要" |
 | `hub-cc-pr-reviewer` | 自动 PR 审阅 | "审阅这个 PR" |
 | `verify-bidirectional` | 反向校验决策 | "那样对吗？"、"再确认一下" |
@@ -291,14 +450,23 @@ forge-harness 把项目当作钢来对待 —— 而这个隐喻是字面的，
 | `convergence-loop` *(fh-commons)* | N 轮收敛循环 | "单遍通过很可疑" |
 | `token-budget-gate` *(fh-commons)* | 任务前 token 成本估算 | "这个多贵？" |
 | `mcp-circuit-breaker` *(fh-commons)* | MCP 工具失败模式检测 | "MCP 一直失败" |
+| `ko-tech-writer` *(fh-commons)* | 韩语技术写作流水线（语域校准、去翻译腔、诚实度分层、感知式 QA） | "기술문서 써줘"、"번역투 고쳐줘" |
 | `quench-challenger` *(fh-commons)* | 对抗压测 agent | "拿魔鬼来挑战这个" |
-| *(+ 更多资产)* | 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` | 视频 → agent 上下文，按能力与时长路由 | "这个视频讲了什么？" |
+| `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 个 agent** | `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` 开始 |
+
+> 这些区间是一次粗略的自查，不是测量 —— 没有任何产物定义过这些阈值，而先前那组固定数字是对着
+> 一个更小的资产盘校准的，随着资产盘变大就悄悄漂移了。用更多技能本身也不是目标；用上你的工作
+> 真正需要的那些才是。
 
 **按你想做的事找技能：**
 
@@ -334,7 +502,7 @@ Claude Code 不会按任务复杂度自动选择模型 —— 这个要你设置
 | `/model opus` | Opus 处理一切 | 编辑框架的会话（Mode D）· 每一轮最大深度 |
 | `/model opusplan` | Opus *规划* · Sonnet 执行 *(当 Opus 介入时)* | 讲究成本的日常编码 —— 见注意事项 |
 
-**为什么现在默认 Sonnet 也行得通**：测量结果（见下文 §Model setup evidence note），*运行* FH 几乎
+**为什么现在默认 Sonnet 也行得通**：测量结果（见下文 *测量，而非断言*），*运行* FH 几乎
 与模型无关 —— 上下文里的规则完成了大部分工作。仍然需要更强模型的，是一小部分深度敏感的轮次，而
 FH 会自行处理它们：**部分技能与 agent 声明了一个模型层级下限**（例如 `quench-challenger` 的下限
 在 opus），当你的环境能够到达时，它们会以那个下限层级的子 agent 派发 —— 你的会话模型不受触碰。
@@ -353,9 +521,12 @@ plan-mode **不会** 传播到子 agent。
 >（设计增量发现），而运行则不然。子 agent 的 token 成本可在会话 jsonl 的 `message.model` 中经
 > CC 看到。
 
-**测量，而非断言**（实测示例）：在一套盲测规则应用测验中，*运行* FH 几乎与模型无关 ——
-**测量的每一个 Claude 层级都得分 94–100%**（Fable、Opus 4.8、Sonnet 4.6 与 5、Haiku 4.5）；
-失掉的少数分数是格式纪律，绝非陷阱或门禁级失误。各层级只在超越评分标准的 *设计* 增量上分野
+**测量，而非断言**（实测示例）：在一套盲测规则应用测验中，*运行* FH 几乎与模型无关 —— 在一套
+30 分的盲测题组上（2026-06-10），跑过的四个层级得分 **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。这里给两条诚实说明，而不是一个圆整的数字：源产物刻意不点出
+最顶层那一层的名字，所以本页也不点名；而 **当前** 的顶层层级尚未在这套题组上跑过 —— 往下传的是
+下面那条准则，不是这些分数。失掉的少数分数是格式纪律，绝非陷阱或门禁级失误。各层级只在超越评分标准的 *设计* 增量上分野
 （开发框架，而非运行框架）—— 这正是为何默认是配以 **层级下限派发** 覆盖深度敏感轮次的 Sonnet，
 而固定更强的模型仅推荐用于编辑框架的会话。
 
@@ -410,7 +581,7 @@ Gemini 共建时，一个全新的 Claude 抓它的泡沫；当你与 Claude 共
 
 > **FH 论文** —— 下述方法论是有文献记录的，不只是断言：
 > - **v1.0 —— 方法论** · [Zenodo](https://zenodo.org/records/20397566)（DOI 10.5281/zenodo.20397566）。两层设计、6 轴框架、4-agent 编排，以及复利循环，均附实证证据。
-> - **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"** · 筹备中。
 
 外部收敛：
@@ -431,5 +602,3 @@ Gemini 共建时，一个全新的 Claude 抓它的泡沫；当你与 Claude 共
 | [`CONTRIBUTING.md`](docs/CONTRIBUTING.md) | 如何贡献技能与模式 |
 | [`tracks/_contrib/`](tracks/_contrib/README.md) | **同意通道** —— 分享一个去标识化的工作会话；仓库在众多操作者间复利累积，而不只在本地 |
 | [`fh_integration_contract.md`](knowledge/shared/harness-core/fh_integration_contract.md) | 治理门禁规格 |
-</content>
-</invoke>