@chrono-meta/fh-gate 1.4.97 → 1.4.99

package/README.zh.md

@@ -8,12 +8,18 @@
   <img src="https://img.shields.io/badge/Claude_Code-compatible-a855f7.svg" alt="Claude Code">
   <a href="https://github.com/chrono-meta/forge-harness/issues/72"><img src="https://img.shields.io/badge/Codex-beta_·_help_validate-f59e0b.svg" alt="Codex-compatible beta — help validate (issue #72)"></a>
   <a href="https://www.npmjs.com/package/@chrono-meta/fh-gate"><img src="https://img.shields.io/npm/v/@chrono-meta/fh-gate.svg?color=cb3837" alt="npm"></a>
+  <a href="https://github.com/chrono-meta/homebrew-forge-harness"><img src="https://img.shields.io/badge/homebrew-tap-FBB040.svg" alt="Homebrew tap"></a>
+  <a href="https://github.com/chrono-meta/forge-harness/stargazers"><img src="https://img.shields.io/github/stars/chrono-meta/forge-harness?style=social" alt="GitHub stars"></a>
 </p>
 
 <p align="center">
   <a href="README.md">English</a> · <a href="README.ko.md">한국어</a> · <b>中文</b> · <a href="README.ja.md">日本語</a>
 </p>
 
+<p align="center">
+  <sub>如果这对你有用，⭐ 一下能帮助更多人发现它。</sub>
+</p>
+
 <p align="center">
   <b>锻造你的 Claude Code 项目 —— 让它通过，它会更快出炉。</b><br>
   一个实践者的 <b>元框架 (meta-harness)</b> —— 你的项目框架们所栖居的星系。<br>它抬高每个项目的 <b>下限 (floor)</b>（把设置框架化）和 <b>上限 (ceiling)</b>（加速工作），再把这些收益在你的整个项目组合中复利累积。
@@ -56,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
@@ -79,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` 找不到它） |
 
 ---
 
@@ -131,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。
 
 ---
 
@@ -185,6 +335,10 @@ npx --package @chrono-meta/fh-gate fh-gate                    # 默认：Claude
 FH_BACKEND=codex npx --package @chrono-meta/fh-gate fh-gate   # Codex 后端
 FH_BACKEND=auto npx --package @chrono-meta/fh-gate fh-gate "src/foo.ts" full
 # → FH_GATE_VERDICT: PASS | PENDING | BLOCKED | ESCALATE
+
+# 或通过 Homebrew（内容相同，安装后无需 npx 前缀）：
+brew tap chrono-meta/forge-harness && brew install forge-harness
+fh-gate
 ```
 
 `fh-gate` 对两种运行时使用同一套 FH 治理提示。`FH_BACKEND=claude` 运行 `claude --print`；`FH_BACKEND=codex` 运行 `codex exec`；`FH_BACKEND=auto` 在两个 CLI 都存在时优先选择 Codex —— 但 `auto` 是回退式*选择*，只运行一条腿。`FH_BACKEND=cross` 会运行两个模型家族并对 findings 取并集(只有一方发现的问题仍然是问题，因此是并集而非投票)，判定取各腿中最严重者。成本约为 2 倍，因此并非默认值，适用于判定/门禁/不可逆面的变更。输出始终声明实际运行了哪些腿(`FH_GATE_LEGS:`、`FH_GATE_DECORRELATED:`) —— 在只装了一个家族的机器上，`cross` 会降级为单腿并明确说明，因为让单家族结果读起来像交叉验证过更糟。
@@ -229,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)
 
 ---
@@ -250,7 +416,9 @@ forge-harness 把项目当作钢来对待 —— 而这个隐喻是字面的，
 签名部件让它持续运转：`harvest-loop`（每次会话的教训成为永久技能）与
 `agent-composer`（编排派发）。其余技能等你需要时再出场 —— 完整清单见下。
 
-## 37 skills · 8 agents
+## 40 skills · 8 agents
+
+> 计数 = 未废弃的技能（仅为旧名路由而保留的废弃重定向桩不计入）。
 
 <details>
 <summary>全部资产激活检查</summary>
@@ -266,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` | 反向校验决策 | "那样对吗？"、"再确认一下" |
@@ -281,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` 开始 |
+
+> 这些区间是一次粗略的自查，不是测量 —— 没有任何产物定义过这些阈值，而先前那组固定数字是对着
+> 一个更小的资产盘校准的，随着资产盘变大就悄悄漂移了。用更多技能本身也不是目标；用上你的工作
+> 真正需要的那些才是。
 
 **按你想做的事找技能：**
 
@@ -324,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 派发 —— 你的会话模型不受触碰。
@@ -343,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，
 而固定更强的模型仅推荐用于编辑框架的会话。
 
@@ -400,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"** · 筹备中。
 
 外部收敛：
@@ -421,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>

package/docs/OUTPUT_EVIDENCE.md

@@ -8,10 +8,10 @@
 
 | What | Count | Notes |
 |---|---:|---|
-| Active skills | **33** | 29 in `fh-meta` + 4 in `fh-commons`; 3 deprecated redirect stubs not counted |
+| Active skills | **40** | 35 in `fh-meta` + 5 in `fh-commons`; **0** deprecated redirect stubs currently exist, so that exclusion is a no-op today |
 | Agent definitions | **8** | `challenger`, `quench-challenger`, `fact-checker`, `hub-persona-auditor`, `persona-innovator`, `beginner`, `main-player`, `expert` |
-| Operating rules | **6** | `.claude/rules/*.md` — mapping, modes, sync, sister-asset, operations |
-| Knowledge docs | **23** | `knowledge/` — 6-axis framework, compounding loop, runtime flow, dialogue playbook |
+| Operating rules | **1** | `.claude/rules/*.md` — `fh_4axis_gate.md`. The drop from 6 is **not** deletion: the others were relocated to `knowledge/shared/rules/` so they stop loading on every session, and this path now holds only the path-scoped gate |
+| Knowledge docs | **57** | `knowledge/` — 6-axis framework, compounding loop, runtime flow, dialogue playbook, and the harness-core canon |
 | Plugins | **2** | `fh-meta` (meta-harness) + `fh-commons` (project-agnostic) |
 | Self-gate | **1** | 4-axis pre-commit hook (backward / adversarial / forward / record) |
 
@@ -19,12 +19,17 @@
 
 | Metric | Value |
 |---|---|
-| First commit → latest | **2026-05-26 → 2026-06-06** (12 days) |
-| Commits | **224** |
-| Merged PRs | **66** |
+| First commit → latest | **2026-05-26 → 2026-08-15** (81 days) |
+| Commits | **768** |
+| Merged PRs | **372** |
 
-> Read honestly: this is *velocity*, not *maturity*. A 12-day-old project is early. The point is that the
-> compounding loop and self-gate were exercised on the harness's own development, not just described.
+> ⚠️ **Counted 2026-08-15; a pace table is stale the day after it is written.** The previous version of
+> this block sat at "12 days / 224 commits / 66 PRs" for two months and read as current, because nothing
+> in it said when it was measured. Re-run the commands below rather than trusting the numbers above —
+> and if you update them, update this date in the same edit.
+
+> Read honestly: this is *velocity*, not *maturity*. The point is that the compounding loop and self-gate
+> were exercised on the harness's own development, not just described.
 
 ## External artifacts (verifiable links)
 
@@ -106,10 +111,14 @@ rather than only synthetic ones.
 <sub>Reproduce the counts:</sub>
 
 ```bash
-# active skills (excludes deprecated redirect stubs)
-for d in plugins/*/skills/*/; do grep -qi "DEPRECATED — merged\|redirect stub\|moved to" "$d/SKILL.md" || echo "$d"; done | wc -l
-# agents
-ls .claude/agents/*.md plugins/*/agents/*.md | wc -l
+# active skills. NOTE: the old recipe here grepped each SKILL.md for "redirect stub"/"deprecated"
+# and returned 38, because phantom-quench and hub-cc-pr-reviewer — both live — merely MENTION those
+# words in their prose. A body-text grep cannot tell "I am a stub" from "I detect stubs". There are
+# currently zero stubs, so count the files and re-introduce an exclusion only when one exists, in
+# frontmatter where it can be matched on a field rather than on a phrase.
+find plugins -name SKILL.md | wc -l
+# agents  (there is no .claude/agents/ in this repo — that path is for field projects)
+find plugins -path '*/agents/*.md' | wc -l
 # knowledge docs
 find knowledge -name '*.md' | wc -l
 # pace

package/docs/pillars.svg

@@ -17,15 +17,11 @@
   <!-- Background -->
   <rect width="680" height="100" fill="url(#bg)"/>
 
-  <!-- Top hot-metal accent -->
-  <rect width="680" height="3" fill="#e07d2a" filter="url(#glow)"/>
-  <rect y="3" width="680" height="5" fill="#e07d2a" fill-opacity="0.10"/>
-
   <!-- ═══ HARNESS (x=8, cx=88) ═══ -->
   <rect x="8" y="10" width="160" height="84" rx="5" fill="url(#cd)" stroke="#c46820" stroke-width="0.8"/>
-  <!-- Chain link icon (harness = link) -->
-  <ellipse cx="81" cy="34" rx="10" ry="6" fill="none" stroke="#e07d2a" stroke-width="2" transform="rotate(-35 81 34)"/>
-  <ellipse cx="95" cy="44" rx="10" ry="6" fill="none" stroke="#e07d2a" stroke-width="2" transform="rotate(-35 95 44)"/>
+  <!-- Chain link icon (harness = link) — opposite tilts so the two loops actually interlock -->
+  <ellipse cx="83" cy="30" rx="6" ry="8.5" fill="none" stroke="#e07d2a" stroke-width="1.8" transform="rotate(-30 83 30)"/>
+  <ellipse cx="93" cy="38" rx="6" ry="8.5" fill="none" stroke="#e07d2a" stroke-width="1.8" transform="rotate(30 93 38)"/>
   <text x="88" y="63" text-anchor="middle" font-family="Georgia,'Times New Roman',serif" font-size="13" font-weight="bold" fill="#f5943a" letter-spacing="2">HARNESS</text>
   <text x="88" y="76" text-anchor="middle" font-family="Georgia,'Times New Roman',serif" font-size="9.5" fill="#9e7040">Harness-ify a project</text>
   <text x="88" y="88" text-anchor="middle" font-family="Georgia,'Times New Roman',serif" font-size="9.5" fill="#9e7040">— raise its floor</text>

package/knowledge/shared/harness-core/fh_ecosystem_positioning.md

@@ -16,6 +16,8 @@ tags: [ecosystem, positioning, synergy, opencode, opencode, hermes, openhuman, r
 
 Target: FH full structure vs Hermes-type agent frameworks, OpenCode-style coding agents, OpenHuman-style human-in-loop systems.
 
+**Cross-ref**: `fh_global_positioning_and_distribution_roadmap.md` (2026-08-15) covers adjacent ground — same "FH vs bare execution coders" positioning question, but scoped to npm/Homebrew distribution mechanics rather than this doc's 3-model ecosystem-structure audit. Read together, not as duplicates.
+
 ---
 
 ## Gap Analysis — Where FH Falls Short

package/knowledge/shared/harness-core/fh_global_positioning_and_distribution_roadmap.md

@@ -0,0 +1,136 @@
+---
+name: fh-global-positioning-and-distribution-roadmap
+description: Comprehensive report on forge-harness global ecosystem positioning, governance brain architecture vs bare coders, and distribution roadmap (Homebrew/standalone binary compatibility with subscription LLMs).
+date: 2026-08-15
+tags: [positioning, roadmap, governance, distribution, homebrew, architecture]
+---
+
+# forge-harness 글로벌 입지 분석 및 배포 로드맵 (Global Positioning & Distribution Roadmap)
+
+## Executive Summary
+
+본 보고서는 **`forge-harness` (FH)의 글로벌 에이전트 프레임워크 생태계 내 포지셔닝**을 객관적으로 정의하고, **유료 구독 모델(Claude Code / Antigravity 등) 기반 환경에서 독립 바이너리/패키지 매니저(`brew install`) 배포 모델로의 확장 가능성 및 로드맵**을 제시합니다.
+
+**Cross-ref**: `fh_ecosystem_positioning.md`(2026-05-31)가 같은 "FH vs 다른 코딩 에이전트" 포지셔닝 질문을 3모델(Claude+Gemini+Codex) 적대적 감사로 더 정식으로 다룬다. 이 문서는 배포(npm/Homebrew) 메커니즘에 특화 — 중복 아니라 상호보완으로 같이 읽을 것.
+
+* **글로벌 포지셔닝**: FH는 코드를 직접 빠르게 뱉어내는 '실행 에이전트'가 아닌, 실행 결과의 환각·보안·근거를 적대적으로 검증하고 자가 진화하는 **품질 거버넌스 계층(Governance Brain)**입니다. (외부 벤치마크나 경쟁사 대비 정량 비교는 아직 없음 — 이 문서의 비교표는 포지셔닝 프레임이지 검증된 성능 우위 주장이 아님.)
+* **배포 모델 결론**: **구독 모델 기반 LLM(Claude Code, Antigravity)과 `brew install` / 독립 바이너리 배포는 대립하지 않으며 완벽히 호환됩니다.** CLI 설치 프로그램(`fh-cli`)이 환경 감지, 플러그인 동기화, 사이드카 라우팅, Git 훅 배선을 자율 수행하고 실제 에이전트 추론은 사용자의 기존 구독/API 계정을 활용합니다.
+
+---
+
+## 1. 글로벌 생태계 구조 비교 (Governance Brain vs. Bare Coders)
+
+```
+[ Bare Execution Coders ]               [ forge-harness (Governance Brain) ]
+ (OpenCode, Devin, Aider 등)              (자가 진화, Quench, 4-Axis Gate)
+┌───────────────────────────┐           ┌───────────────────────────────────┐
+│ • 고속 코드 생성           │  +  +  +  │ • 적대적 4축 검증 (Steel-Quench)  │
+│ • CLI / 데스크톱 패키징   │  =======> │ • 출처 역추적 (Phantom-Quench)    │
+│ • 빌드 / 테스트 자동 실행  │  Synergy  │ • 필드 패턴 자가 수확 (Harvest)   │
+└───────────────────────────┘           └───────────────────────────────────┘
+```
+
+> **읽는 법**: 아래 표는 FH의 자체 포지셔닝 프레임이지, OpenCode/Devin/Aider를 벤치마크·정량 비교한 결과가 아닙니다. 그 도구들도 각자 검증/자동화 기능을 주장하므로, "단순 고속생성기"로 단순화한 왼쪽 열은 균형 잡힌 비교가 아니라 FH 관점의 상대적 강조점으로 읽어야 합니다.
+
+| 검증 및 배포 축 | "실행 우선" 코딩 에이전트 부류 (OpenCode / Aider 등, FH 관점 프레이밍) | forge-harness (FH Meta-Harness) |
+|---|---|---|
+| **주요 역할** | 코드 및 스크립트 고속 자동 생성 | 생성물 품질 검증, 자가 진화, 거버넌스 |
+| **품질 검증** | 단위 테스트(CI) 통과 여부만 확인 (도구별 상이 — 미검증 일반화) | **CI가 놓치는 엣지케이스/보안/근거 적대적 검수** |
+| **학습 메커니즘** | 단순 대화 이력 수동 보존 (도구별 상이 — 미검증 일반화) | **세션 마감 시 `harvest-loop`로 자가 규율 업데이트** |
+| **현재 배포 형태**| `brew install`, 단일 바이너리, GUI 앱 | npm 패키지 [`@chrono-meta/fh-gate`](https://www.npmjs.com/package/@chrono-meta/fh-gate) (v1.4.x) & 레포지토리 |
+
+---
+
+## 2. 라이브 npm 패키지 (`@chrono-meta/fh-gate`)의 실측 수치 및 if(kakao) 발표 레퍼런스
+
+### 2.1. npm 공식 API 라이브 데이터
+
+* **실측 (2026-08-15, `api.npmjs.org` 직접 조회, 재현 가능)**: 최초 배포일(2026-06-01)부터 누적 **16,326건**. 최근 2개월 창(06-15~08-15)만 보면 **12,856건** — 둘 다 실제 API 응답이며 창(window) 선택 차이일 뿐 서로 모순되지 않음.
+* **⚠️ 백분위/등수 주장은 뺀다 — 근거 없음(2026-08-15, 검증 후 정정)**: 이전 초안이 "npm 전체 300만 패키지 대비 상위 2%"라고 썼으나, 그런 분포표를 발행한 공개 출처(npms.io 포함)를 웹서치로도 못 찾음. npm 레지스트리는 패키지 간 백분위 순위를 공식 제공하지 않는다 — 이 문서를 원본으로 삼은 작성자(Gemini)도 검증 후 **"등수는 npm이 공식 제공하지 않는 추정치이므로 발표/논문에는 실측 다운로드 수만 남기라"**고 스스로 정정함. 이 문서와 앞으로의 발표 자료 모두 이 규율을 따른다: **다운로드 수(실측)만 인용, 백분위/등수(추정)는 인용하지 않는다.**
+
+### 2.2. npm 패키지의 실제 포함 범위 (152개 `files[]` 전수 실측)
+`forge-harness` npm 패키지는 단순한 "경량 단품 검사기"가 아니라, if(kakao) 발표 및 학술 논문(arXiv)에서 다루는 **15페이지 분량의 핵심 검증 방법론과 §7 Standpoint 축을 100% 내장한 포터블 완전체 패키지**입니다.
+
+* **실제 번들 포함 자산 (`package.json` `files[]` 152개 전수)**:
+  1. **스킬 & 에이전트 전체**: `plugins/fh-meta/skills·agents`, `plugins/fh-commons/skills·agents` (29개+ 스킬 및 8개 에이전트 전원 포함)
+  2. **핵심 독트린 지식베이스 전체**: `knowledge/shared/harness-core/` (§7 Standpoint 축, `field_verdict_crossfamily_gate.md`, `sonnet_floor_doctrine.md` 등), `knowledge/shared/dialogue/`, `knowledge/shared/rules/`
+  3. **`CLAUDE.md` & `AGENTS.md` 자체**: Standpoint 트리거 행을 포함한 하네스 규칙 정본
+  4. **4축 게이트 기계층 전체**: `pre-commit`/`pre-push` 훅, `selfcheck`, `package-coverage`, `branch_claim`, `consent_registry`, `public_surface_scan` 스크립트 전수
+* **제외 항목 (단 3가지)**:
+  * `tracks/` (개별 허브의 세션/작업 이력 — 개인화된 운영 데이터)
+  * `knowledge/domain/` (조직 특화 도메인 지식)
+  * `paper/` (arXiv 제출용 논문 원고)
+
+### 2.3. npm 배포와 로컬 워크스페이스 간의 관계
+* **npm (`@chrono-meta/fh-gate`)**: 키노트 및 학술 논문(arXiv)의 핵심 검증 방법론(§7 Standpoint 축 포함), 스킬, 에이전트, 게이트를 어느 레포에서나 `npx` 한 줄로 100% 실행할 수 있게 제공하는 **완전체 포터블 하네스 패키지**.
+* **로컬 워크스페이스 (Local Hub)**: npm으로 배포되는 스킬/에이전트/독트린 정본 위에 **해당 허브 고유의 이월 작업 이력(`tracks/`)**이 지속해서 쌓여 자가진화하는 **운영 허브(Operating Hub)**.
+
+### 2.4. Homebrew (`brew install`)와의 차세대 확장 관계
+* npm 패키지가 Node.js 생태계에서 FH의 전 스킬/에이전트/독트린을 100% 이식해 준다면, **Homebrew (`brew install forge-harness`)**는 Node.js 종속성 없이 OS 레벨에서 글로벌 CLI 바이너리 및 전역 Git 훅 셋업을 지원하는 **글로벌 OS 패키지 채널 확장(Phase 3)** 역할을 수행합니다.
+
+---
+
+## 3. 구독 모델 기반 런타임과 CLI 브리지 배포의 호환 원리
+
+### 3.1. 구조적 작동 원리 (CLI Bridge Architecture)
+
+`brew install`이나 독립 `.exe/.app` 바이너리는 **"LLM 모델 자체를 내장하는 것"이 아니라, "에이전트가 작동하는 로컬 하네스 인프라를 자동으로 구축·관리해 주는 CLI 도구(Launcher/Bridge)"**를 설치하는 것입니다.
+
+```mermaid
+graph TD
+    User["👤 개발자 (brew install forge-harness)"] -->|설치| Binary["📦 fh CLI (Homebrew Formula, npm 패키지 wrap)"]
+    Binary -->|fh init 실행| LocalRepo["📁 로컬 프로젝트 (.claude/ & AGENTS.md 자동 배선)"]
+    LocalRepo -->|작업 수행| Runner["🤖 LLM Runtime Engine"]
+    Runner -->|구독 계정 활용| ClaudeCode["🔐 User's Claude Code / Antigravity / API Key"]
+    Runner -->|검증 및 사이드카| FHPipeline["🛡️ FH Governance Pipeline (Quench & 4-Axis)"]
+```
+
+1. **설치 단계 (`brew install forge-harness`)**:
+   * 경량 바이너리(`fh` CLI)가 사용자의 Mac/Linux에 설치됩니다.
+2. **프로젝트 연동 (`fh init` 또는 `fh setup`)**:
+   * 명령 한 줄로 프로젝트에 최신 `AGENTS.md`, `plugins/`, `rules/`, Git 훅을 자동으로 구성하고 종속성을 진단합니다.
+3. **추론 실행 시**:
+   * `fh` CLI는 코드를 직접 추론하는 대신, 사용자가 이미 구독 중인 **Claude Code, Antigravity CLI, 또는 로컬 API 키**를 브리지(Bridge)하여 오케스트레이션을 수행합니다.
+
+---
+
+## 4. forge-harness 진화 로드맵 (Evolution Roadmap)
+
+```
+[ Phase 1: 로컬 메타 하네스 코어 ] ──> [ Phase 2: npm 완전체 배포 ] ──> [ Phase 3: Homebrew & IDE 에코시스템 ]
+ (자가진화 본체 & 지식 완비)           (누적 16,326건 실측, 현재!)          (OS 전역 CLI & cmux/IDE 연동)
+```
+
+### Phase 1: 로컬 파일 시스템 메타 하네스 코어 (완료)
+* **특징**: `AGENTS.md`, `plugins/`, Markdown 기반의 모델 비의존성 프로세스 및 검증 지능 완비.
+* **달성**: `steel-quench`, `phantom-quench`, `sim-conductor`, `ko-tech-writer` 등 29개+ 스킬 및 8개 에이전트 개발 완료.
+
+### Phase 2: npm 공식 레지스트리 포터블 완전체 배포 (현재 완벽히 라이브)
+* **특징**: npm 공식 패키지 [`@chrono-meta/fh-gate`](https://www.npmjs.com/package/@chrono-meta/fh-gate) (v1.4.x)를 통해 152개 번들 파일 전수 출하.
+* **달성 (누적 16,326건 실측, 2026-08-15 npm API 재현 가능)**:
+  * 29개+ 스킬 전체, 8개 에이전트 전원, §7 Standpoint 축 포함 지식베이스, 4축 게이트 엔진이 타르볼에 100% 실려 배포되어 어느 레포에서나 `npx`로 100% 실행 가능함.
+  * `fh-gate`, `fh-run`, `fh-goal`, `fh-codex-doctor` CLI 실행 가능.
+
+### Phase 3: Homebrew OS 패키지 채널 확장 & IDE/Event-Bus 에코시스템 (차기 목표)
+* **특징**: Node.js 환경 의존성이 없는 OS 전역 CLI 라운처(`brew install forge-harness`) 및 IDE/플러그인 직접 연동.
+* **목표**:
+  * `brew install forge-harness`
+  * `fh setup`: 명령 한 줄로 신규 레포지토리에 하네스 구조(`.claude/`·`plugins/`·rules·Git 훅)를 스캐폴딩
+  * OpenCode, Hermes, VS Code, JetBrains, `cmux` 플러그인과 직접 Event-bus 연동.
+* **⚠️ 스캐폴딩 ≠ 복리(compounding)** — `meta-harness-thin-vs-full-distribution.md`(2026-06-08, 이미 결론난 축)의 핵심: FH의 진짜 값어치는 스킬/명령 자체가 아니라 **클론 상태에 쌓이는 `tracks/`·메모리·규칙 이력(오케스트레이션)**에 있음. `fh setup`이 구조를 1초 만에 깔아줘도, 그 프로젝트가 실제 FH급 시너지를 가지려면 이후 세션이 쌓이며 `tracks/`가 축적돼야 함 — 초기화 시점의 "완전 배포"와 축적된 자가진화 상태는 다른 것. 로드맵을 실행할 때는 이 구분을 각주가 아니라 Phase 3의 성공 기준에 포함시킬 것.
+* **✅ 신규 바이너리 불필요 — 운영자 결정(2026-08-15)으로 해소**: 위 mermaid 다이어그램이 남겨뒀던 `fh CLI 바이너리 (Rust/Go/Node)` 언어 미정 상태는 검토 결과 닫혔다. Homebrew는 npm 패키지를 그대로 감싸는 표준 패턴(`nodejs_module`/`resource` 블록으로 npm 레지스트리에서 직접 받아 `libexec`에 설치)을 지원하므로, `brew install forge-harness`는 **신규 바이너리를 재작성하지 않고 이미 라이브인 `@chrono-meta/fh-gate` npm 패키지를 그대로 얹는 Formula 하나**로 구현한다. `brew upgrade`도 npm 쪽 새 버전을 그대로 따라가므로 별도 릴리스 파이프라인이 필요 없다. 엔지니어링 비용이 사실상 0에 가까움 — Added-Scope Gate의 "이거 없이 안 되는 게 뭔가?"에 답이 없으므로 재작성 경로는 폐기.
+* **✅ Homebrew는 "npm 대신 옵션"이 아니라 100% 동등 배포 — 커버리지 저하 없음**: brew formula가 npm 패키지를 그대로 감싸므로, §2.1에서 실측한 152개 파일(스킬 29개+·에이전트 8개·독트린 지식베이스·4축 게이트 기계층 전부)이 설치 방식만 바뀌어 그대로 전달된다. "brew는 가벼운 대안" 프레임은 틀렸다 — 내용은 동일하고 설치/업데이트 UX만 개선된다.
+* **포지셔닝 (운영자 확정, 2026-08-15)**: **FH 레포(git clone) = 개발·기여·전체 맥락 참고 목적 전용.** `tracks/`가 쌓이는 복리(orchestration) 본체는 여기서만 생기고, npm이든 brew든 이 부분은 처음부터 못 주며 줄 필요도 없다(운영 이력은 그 프로젝트 고유 데이터라 원리적으로 배포 불가능한 자산). **그 외 모든 순수 사용 목적 = brew(또는 npm)**, git pull 반복의 피로도 없이 스킬+게이트+독트린을 100% 받아 즉시 사용. 개발/기여자가 아니면 git clone을 권할 이유가 없다.
+* **① 커스텀 tap — 배포 완료(2026-08-15)**: `chrono-meta/homebrew-forge-harness` 공개 repo에 `Formula/forge-harness.rb` 게시 완료 (`brew tap chrono-meta/forge-harness && brew install forge-harness`). 로컬 검증: `brew audit --strict --online` 클린 · `brew style` 클린 · `brew install --build-from-source` 5초 완주 · `brew test` PASS(라이브 `claude`/`codex` 백엔드 호출 없이 fail-closed 경로만 결정론적으로 검증). README(4개 언어) + CHEATSHEET.md에 npm과 나란히 안내 추가.
+* **② Homebrew Core 등재 — 보류(운영자 결정, 2026-08-15), 재개 조건 명시**: 공식 기준(`docs.brew.sh/Package-Acceptance-Policy`) 실측 결과 **스타 75개 · 포크 30개 · 워처 30개 중 하나**를 충족해야 하는데(본인 제출이면 3배: 225·90·90), forge-harness 저장소 실측(2026-08-15, `gh repo view`)은 **스타 7 · 포크 0 · 워처 0**로 기준에 한참 못 미침 — npm 다운로드 수(16,326건)는 이 기준과 무관(GitHub 저장소 자체의 notability만 봄, 별개 축). 지금 제출하면 사실상 거절 확정이라 보류. **재개 조건**: 위 세 지표 중 하나가 임계치 근처(스타 ~50+)에 도달하면 재검토.
+
+---
+
+## 5. 결론
+
+1. **글로벌 입지**: `forge-harness`는 단순 코드 생성을 넘어선 **품질 거버넌스 및 자가진화 계층**입니다 (외부 벤치마크 비교는 미실시 — §1 캡션 참조).
+2. **배포 메커니즘**: 구독 모델(Claude Code 등)을 사용하더라도 `brew install`을 통해 **로컬 하네스 인프라 구축, 자동 업데이트, 환경 통합을 수행하는 CLI 라운처** 형태로 확장할 수 있습니다 — 단, 그 라운처가 주는 것은 초기 스캐폴딩이며 FH의 복리(compounding) 자체는 아님(§4 Phase 3 각주).
+3. **배포 채널 3분할 (운영자 확정, 2026-08-15)**: git clone = 개발/기여/전체 맥락 참고 전용(복리가 여기서만 축적). npm/`brew install` = 순수 사용 목적 전원 대상, 152개 파일 100% 동등 배포(내용 저하 없음, 설치 UX만 다름). Homebrew는 npm을 그대로 감싸는 Formula로 구현하며 신규 바이너리 재작성은 하지 않음(§4 Phase 3 참조) — Phase 3은 "npm의 대안"이 아니라 "npm과 동일 내용의 더 편한 설치 경로" 추가로 재정의.
+
+---
+*Documented by Antigravity in forge-harness Knowledge Core (`knowledge/shared/harness-core/fh_global_positioning_and_distribution_roadmap.md`). Reviewed and source-grounded 2026-08-15.*