@chrono-meta/fh-gate 1.4.96 → 1.4.98

package/.claude-plugin/marketplace.json

@@ -11,13 +11,13 @@
   "plugins": [
     {
       "name": "fh-meta",
-      "version": "1.4.96",
+      "version": "1.4.98",
       "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.96",
+      "version": "1.4.98",
       "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/CATALOG.md

@@ -4,6 +4,25 @@ AI reads this file first when searching past work. Open individual files for det
 
 ---
 
+## 2026-08-15 — Global positioning & distribution roadmap (Homebrew/npm compatibility)
+
+- **New doc** (`knowledge/shared/harness-core/fh_global_positioning_and_distribution_roadmap.md`):
+  Antigravity/Gemini-authored positioning report — npm (`@chrono-meta/fh-gate`) is a full 152-file
+  portable bundle (all skills/agents/harness-core doctrine/gate machinery, everything except
+  `tracks/`·`knowledge/domain/`·`paper/`), not a thin gate-only checker; subscription-LLM runtimes
+  and a future `brew install` CLI bridge are compatible, not competing.
+- **Reviewed and corrected same day** (source-grounding pass): download/agent-count figures verified
+  against live npm API + repo file count (both held); duplicate section numbering and a copy-paste
+  duplicate subheading fixed; ungrounded superlatives ("세계 최상위...") removed/hedged; the
+  competitor comparison table captioned as a positioning frame, not a benchmark; Phase 3 given two
+  explicit caveats it originally lacked — scaffolding a project structure is not the same as FH's
+  actual compounding (`meta-harness-thin-vs-full-distribution.md`, 2026-06-08, already-established
+  axis — the value accrues in `tracks/`/memory over time, not at `fh setup` time), and a new
+  Rust/Go binary's necessity is unevaluated against simply wrapping the already-live Node npm CLI in
+  a Homebrew formula.
+
+---
+
 ## 2026-08-01 — Harness-Verification Doctrine: core lens vs cluster instruments
 
 - **New doctrine** (`knowledge/shared/harness-core/harness_verification_core_extended.md`): the

package/CHEATSHEET.md

@@ -197,7 +197,7 @@ claude plugin list
 
 ## 9.5. npx / CLI — zero-install governance gate (any repo, no Claude Code session)
 
-The npm package `@chrono-meta/fh-gate` runs FH's governance gate as a plain CLI — no clone, no plugin, no `claude` session. Use it in CI or any repo. It shells out to a backend (`claude --print` or `codex exec`) and returns a machine-parseable verdict + exit code.
+The npm package `@chrono-meta/fh-gate` runs FH's governance gate as a plain CLI — no clone, no plugin, no `claude` session. Use it in CI or any repo. It shells out to a backend (`claude --print` or `codex exec`) and returns a machine-parseable verdict + exit code. A Homebrew tap ships the exact same content (100% parity — same npm tarball, just a different install path); prefer it if you'd rather not type `npx --package` every time.
 
 ```bash
 # Governance gate — wraps any coding agent's output as a post-generation check
@@ -211,6 +211,14 @@ FH_BACKEND=codex npx --package @chrono-meta/fh-gate fh-gate   # Codex backend (d
 npx --package @chrono-meta/fh-gate fh-run --skill <name>
 npx --package @chrono-meta/fh-gate fh-goal "<goal text>"      # goal runner
 npx --package @chrono-meta/fh-gate fh-codex-doctor --strict  # Codex adapter drift check
+
+# Homebrew alternative (community tap, not yet in Homebrew Core — `brew search` won't
+# find it without tapping first): install once, then call the binaries directly
+brew tap chrono-meta/forge-harness && brew install forge-harness
+fh-gate                     # same as `npx --package @chrono-meta/fh-gate fh-gate`
+fh-run --skill <name>
+fh-goal "<goal text>"
+fh-codex-doctor --strict
 ```
 
 | Knob | Values | Effect |

package/CLAUDE.md

@@ -254,9 +254,16 @@ into muscle memory and disarm it.
 > `required_pull_request_reviews` present with `enforce_admins: true` — not something
 > `required_status_checks` says anything about.
 > ⚠️ A *different* residual on `main` is still real and must not be folded into the one just
-> retracted: `required_status_checks.contexts` is `[]` — pushes are routed through PRs by the fields
-> just named, but **no check is required to be green** for one to merge (named again in the 4-axis
-> section below).
+> retracted — but the residual's own description was itself stale and needed correction on
+> 2026-08-12 (live re-check, `[[reference_github_protection_two_layers]]`): legacy
+> `required_status_checks.contexts` is **`["validate"]`**, not `[]` — a green `validate` check IS
+> required before a PR can merge, and `GET /rules/branches/main` carries no competing
+> `required_status_checks` rule, so the legacy field is the effective one here. `validate`
+> (`.github/workflows/validate.yml`) is a **separate job from Axis 1** (`regression-guard.yml`) —
+> Axis 1 is still not required, see the 4-axis section below. The gap on `validate` is
+> `strict: false`: that check re-runs on every push to the PR branch, but nothing re-forces it
+> against a **moving** main after it last ran — so a check that passed can still land behind
+> concurrent merges it never saw.
 
 ## Permission-Denial Guidance (When Auto-Mode Blocks an Action)
 
@@ -324,7 +331,7 @@ Every new `SKILL.md` must clear a **6-item bar** (role-duplication via `/asset-p
 
 **FH 자산을 수정하면**(SKILL.md · **SKILL_detail.md** · `.claude/rules/*.md` · `knowledge/shared/rules/*.md` · `templates/` · `CLAUDE.md` · substantive `knowledge/`·`docs/*.md` · `AGENTS.md` · **`scripts/**/*.sh`** · **에이전트 정의**(`plugins/*/agents/**/*.md` · `.claude/agents/**/*.md`)) **4축 검증 체인이 그 세션 첫 커밋 전에 자동 실행된다.** 사용자 요청 불요 — 제안이 아니라 의무 단계다.
 
-**기계층 — 무엇이 실제로 막는지 나눠서 말한다(2026-08-04 실측).** `git commit` 은 `templates/.git-hooks/pre-commit` 이 **하드 차단**한다: 축이 전부 PASS 할 때까지 커밋이 안 되고, 아래 상세가 로드되지 않아도 훅이 막는다 — 이 산문은 훅 위의 살리언스 층이지 유일 floor 가 아니다. 다만 **훅은 클라이언트측이고 `--no-verify` 로 우회된다**(§Integration branch 가 이미 그렇게 말한다 — 두 곳이 어긋나 보이던 것을 여기서 맞춘다). **그리고 서버측이 이걸 받쳐주지 않는다**: `main` 은 `enforce_admins: true` 로 **푸시 경로**(PR 경유)를 강제하지만 `required_status_checks.contexts` 가 **비어 있다** — Axis 1 워크플로가 매 PR 에서 돌긴 해도 **필수 체크가 아니라 빨간 채로도 머지가 된다.** 즉 서버가 강제하는 건 *어디로 들어오는가*지 *내용이 검증됐는가*가 아니다. Axes 2–3(마커)·Axis 4(매니페스트)는 그 파일들이 `tracks/**` 로 gitignored 라 CI 가 **구조적으로 볼 수조차 없다**. 정직한 표현은 "하드 차단"이 아니라 **"가용한 가장 강한 층"**이다. **미해결 잔여**: 필수 체크 0개 — 켜는 건 운영자 결정이다(막 flaky 레인을 하나 기록한 참이라, 과차단이 override 를 습관화시키는 쪽으로 기울 수 있다).
+**기계층 — 무엇이 실제로 막는지 나눠서 말한다(2026-08-04 실측).** `git commit` 은 `templates/.git-hooks/pre-commit` 이 **하드 차단**한다: 축이 전부 PASS 할 때까지 커밋이 안 되고, 아래 상세가 로드되지 않아도 훅이 막는다 — 이 산문은 훅 위의 살리언스 층이지 유일 floor 가 아니다. 다만 **훅은 클라이언트측이고 `--no-verify` 로 우회된다**(§Integration branch 가 이미 그렇게 말한다 — 두 곳이 어긋나 보이던 것을 여기서 맞춘다). **그리고 서버측 검증엔 남은 잔여가 있다(2026-08-12 재확인 — `contexts=[]` 서술은 stale, 정정됨)**: `main` 은 `enforce_admins: true` 로 **푸시 경로**(PR 경유)를 강제하고, legacy `required_status_checks.contexts` 는 **`["validate"]`** — `validate` 잡(`.github/workflows/validate.yml`, 메타데이터·`selfcheck.sh` 배선 레인)이 실제 **필수 체크**다. ⚠️ **`validate` 는 Axis 1 이 아니다** — Axis 1(`regression-guard.yml` → `templates/regression_guard.sh`)은 여전히 필수 체크가 **아니고**, 그 워크플로의 `paths:` 필터가 `SKILL.md`·`.claude/rules/*.md`·`CLAUDE.md`·`templates/*.md` 만 보므로 이 절이 4축 대상으로 나열한 `knowledge/shared/rules/*.md`·`docs/*.md`·`AGENTS.md`·`scripts/**/*.sh`·에이전트 정의·`SKILL_detail.md` 만 바뀐 PR 에는 **Axis 1 자체가 돌지도 않는다**. `validate` 쪽 남은 갭은 `strict: false`: 그 체크는 PR 브랜치에 푸시할 때마다 재실행되지만(오픈 시점 한정이 아니다), 그 뒤 main 이 움직여도 재검증을 강제하지 않으므로 **초록으로 남아 있는 체크가 실제로 병합되는 최신 트리를 본 적이 없을 수 있다.** 즉 서버가 강제하는 건 *체크가 초록인가*지 *그 체크가 지금의 main 을 봤는가*가 아니다. Axes 2–3(마커)·Axis 4(매니페스트)는 그 파일들이 `tracks/**` 로 gitignored 라 CI 가 **구조적으로 볼 수조차 없다**. 정직한 표현은 "하드 차단"이 아니라 **"가용한 가장 강한 층"**이다. **미해결 잔여**: `strict` 를 켜는 것도, Axis 1 을 필수 체크로 걸거나 그 `paths:` 를 넓히는 것도 운영자 결정이다(막 flaky 레인을 하나 기록한 참이라, 과차단이 override 를 습관화시키는 쪽으로 기울 수 있다).
 
 > **상세 정본**: `.claude/rules/fh_4axis_gate.md` — 4축 정의·마커 필수 필드·경량 예외·substantive carve-out·target-tier sim 게이트·Mode D 모델 공지·cross-family 보완. **`paths:` 로 *일부* FH 자산 경로에 스코핑돼 있어 그 파일들을 *읽을 때* 자동 로드된다 — 로드 조건이지 게이트 적용 범위가 아니다** (공식 트리거는 read — `code.claude.com/docs/en/memory.md` §Path-specific rules).
 > (2026-07-20 분리. **파일 char 실측**: 이 절 자체가 76,706자 중 **10,331자(13.5%)**로 단일 최대였다. 그 분리 + 같은 세션의 중복 3건 제거 + New-Skill 게이트 편입까지 **합산**해 파일은 **76,706 → 67,611 (순감 9,095자, 11.9%)** — 합산치이지 이 절 하나의 성과가 아니다 — 이건 파일 크기지 `/context` 상주 실측이 아니다(계기≠대상, [[feedback_resident_memory_measured_fresh_toplevel]]: 상주는 톱레벨 새 세션 `/context` 로만 잰다 — 미측정). 트리거가 *파일*이고 *기계 백스톱*이 있어 1순위 후보였다. 같은 이유로 **비가역 게이트 3종은 이동 불가** — 의도 트리거라 경로 스코핑하면 fail-open 이 된다.)
@@ -375,11 +382,36 @@ times and any decorrelation verdict **4** times. **Residency**: sanitize company
 pipeline**, not an afterthought, and a below-floor orchestrator RUNS the review by default
 (run-first, ask-last — `sonnet_floor_doctrine.md`).
 
+**Standpoint axis (2026-08-14, orthogonal to family — §7 of the detail doc)**: family diversity
+raises resolution *within* one standpoint (the author's own repo, the author's own reading of a
+target's rules); it does not decorrelate the review's ground-truth source. For a **shared-body /
+cross-harness-boundary** change — scoped by *effect* (alters another harness's behavior, gate
+outcome, or interaction contract), not merely by touching a synced file path — the marker
+additionally carries `standpoint:` — a closed enum (`tier1` content-only · `tier2(<harness>)`
+peer-simulated, ran the target's own repo · `tier2b(<harness>)` same operator, target's real
+runtime (local wiring visible, not independent) · `tier3(<harness>)` a *different* operator of the
+target harness ran it · `not-applicable` · degrade triad `DEGRADED_NO_TARGET_ACCESS` could-not /
+`DEGRADED_NOT_RUN` did-not / `UNKNOWN` did-not-look — same shape as `crossfamily:`'s triad,
+**distinct literal values**, do not reuse crossfamily's tokens). Naming note: this collides in
+English with FH's own persona/viewpoint sense of "standpoint" (`fh-meta:beginner`/`main-player`/
+`expert`) — a different axis (which persona reviews, not whose repo is ground truth); kept as-is,
+not renamed, but do not conflate the two. **Prose-only today** — unlike `crossfamily:`, no
+pre-commit hook or fixture suite validates this field yet, and mechanizing it is FH's own
+responsibility since a sibling harness that syncs this doctrine verbatim cannot add the check
+locally; mechanize on the first recorded false value, not before. Three artifacts, one carrying two
+independent trials (forge-harness PR #368, a sibling field harness's PR #8 reps=3 and its
+known-answer trial, qasp-dev PR #161 as adjacent corroboration) crossed this repo's own evidence
+bar the same day this was formalized — including one caught by this session's own qasp PR #161
+review, not fed in externally, and a second live demonstration the same day when a cross-harness
+standpoint review of this very section caught real residency and citation defects in the first
+draft (fixed in the same commit that added this line).
+
 > **Detail**: See `knowledge/shared/harness-core/field_verdict_crossfamily_gate.md` — the discretion
 > principle, the four-faces failure signature, why same-family review misses it, the full gate
 > mechanics, the n=7 qasp field evidence incl. the **9 default-toward-PASS holes across 3 harnesses**
-> (2026-07-03), the named under-trigger residuals, and autonomous-loop baking — read when applying
-> or auditing this gate.
+> (2026-07-03), the named under-trigger residuals, autonomous-loop baking, and **§7 the standpoint
+> axis** (field spec, trigger scope, relationship to the core/extended verification axis, evidence
+> table) — read when applying or auditing this gate.
 
 ## Field-Harness Diagnostic — "진단해줘 / 개선해줘" on a mapped project (compose → rank → HITL)
 
@@ -609,6 +641,7 @@ Proposal format: `"I see [X]. Want me to run /[skill] to [one-line description]?
 | "memory feels bloated", "clean up memory", "memory too large", "memory hygiene" | `/memory-hygiene` |
 | "ready to PR", "about to push", "merge this", "PR 올려줘", FH asset changed in session | 4-axis auto-gate (see above — runs automatically, no proposal needed) |
 | **field verdict/gate/safety/irreversible code changed** in a mapped project (function returning a verdict enum / gate exit code / safety-invariant · publish/delete/history path) — **proactive, before merge** | **Field-Harness Load-Bearing Change Gate** (see above → degrade-lint → cross-family review → converge; same rigor as FH assets, applied to field code) |
+| **a diff (yours or an unattended pipeline's) alters another harness's actual behavior, gate outcome, or interaction contract** — building automation that opens PRs autonomously, touching a synced/shared-body surface, or any change whose effect crosses a harness boundary (not merely a file-class match — most self-improvement is `not-applicable` here, which is the expected common case) — **proactive, before push, never as a post-PR comment** | **Standpoint axis** (`knowledge/shared/harness-core/field_verdict_crossfamily_gate.md §7` — orthogonal to `crossfamily:`; run the diff from the TARGET harness's own repo/standpoint via `tier2`/`tier2b`/`tier3`, or record `not-applicable`/`DEGRADED_*` on the closed enum. Missed once in-session while building `scripts/frontier_digest_autopilot.sh` 2026-08-15 — mis-routed to `fh-meta:hub-cc-pr-reviewer` (same-repo self-consistency, a different lens) before the operator caught it; this row exists so the next session connects the trigger without two rounds of correction.) |
 | **"진단해줘", "개선해줘", "diagnose this", "improve this harness", "check this project", "audit this project"** — said while working **in a mapped project** (not a single-file ask) | **Field-Harness Diagnostic** (see §Field-Harness Diagnostic above → compose existing checks into one ranked M/S/R list → HITL approval per item, nothing auto-fixed) |
 | **"새 프로젝트", "하네스 작성해줘", "이 프로젝트 가속화", "harness-ify this", "accelerate this project"** — an onboarding/acceleration door (returning-menu ①②③) | **Onboarding / Acceleration Autopilot** (see §Onboarding / Acceleration Autopilot above → Phase 0 auto-discover + branch → innovator-centered recommend → ranked install plan → HITL per item, non-overwriting; "끝까지 자율로" → full-autonomy under /goal-quench gate) |
 

package/README.ja.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> · <a href="README.zh.md">中文</a> · <b>日本語</b>
 </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> を上げた上で（作業を加速）、その利得をポートフォリオ全体に複利で積み上げます。
@@ -196,6 +202,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` はフォールバック*選択*であり、レグは 1 つだけ走ります。`FH_BACKEND=cross` は両ファミリーを走らせて findings を union します(一方だけが見つけた指摘も指摘なので、投票ではなく union)。判定はレグ中で最も重いものです。コストは約 2 倍なので既定ではなく、判定・ゲート・不可逆な面の変更に使います。出力は実際に走ったレグを常に明示します(`FH_GATE_LEGS:`、`FH_GATE_DECORRELATED:`) — 片方のファミリーしかない環境では単一レグに縮退し、その事実を明記します。

package/README.ko.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> · <b>한국어</b> · <a href="README.zh.md">中文</a> · <a href="README.ja.md">日本語</a>
 </p>
 
+<p align="center">
+  <sub>도움이 됐다면 ⭐ 하나가 다른 사람이 찾는 데 도움이 됩니다.</sub>
+</p>
+
 <p align="center">
   <b>당신의 Claude Code 프로젝트를 벼려서 — 통과시키면, 더 빠르게 나옵니다.</b><br>
   실무자의 <b>메타하네스</b> — 당신의 프로젝트 하네스들이 사는 은하계.<br>각 프로젝트의 <b>바닥(floor)</b>을 올리고(설정을 하네스화) <b>천장(ceiling)</b>을 올린 뒤(작업을 가속), 그 이득을 포트폴리오 전체에 복리로 쌓습니다.
@@ -195,6 +201,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를 union 합니다(한쪽만 본 지적도 지적이므로 투표가 아니라 union). 판정은 레그 중 가장 무거운 것입니다. 비용이 약 2배라 기본값이 아니며, 판정·게이트·비가역 표면 변경에 씁니다. 출력은 실제로 돈 레그를 항상 밝힙니다(`FH_GATE_LEGS:`, `FH_GATE_DECORRELATED:`) — 한 패밀리만 설치된 머신에서는 단일 레그로 내려가되 그 사실을 명시합니다. 단일 패밀리 결과가 교차검증된 것처럼 읽히는 편이 더 나쁘기 때문입니다.

package/README.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">
   <b>English</b> · <a href="README.ko.md">한국어</a> · <a href="README.zh.md">中文</a> · <a href="README.ja.md">日本語</a>
 </p>
 
+<p align="center">
+  <sub>If this is useful, a ⭐ helps others find it.</sub>
+</p>
+
 <p align="center">
   <b>Forge your Claude Code projects — pass them through, they come out faster.</b><br>
   A practitioner's <b>meta-harness</b> — the galaxy your project harnesses live in.<br>It raises each project's <b>floor</b> (harness-ify the setup) and <b>ceiling</b> (accelerate the work), then compounds the gains across your whole portfolio.
@@ -56,6 +62,25 @@
 
 **Prerequisite**: Claude Code CLI — verify with `claude --version`
 
+<details><summary><b>Optional: one gate needs Python + PyYAML</b> — <code>npm test</code> is red without it</summary>
+
+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**:
+
+```bash
+python3 -m pip install --user pyyaml     # verify:  python3 -c 'import yaml; print(yaml.__version__)'
+```
+
+Why this is called out rather than left implicit: a release once shipped green from a session whose
+`python3` happened to resolve to an **unrelated project's virtualenv** that had PyYAML, while the
+machine's own `python3` did not. The gate was never bypassed — it passed, and the pass simply was not
+portable. Every verdict from that gate now prints the interpreter and PyYAML version it used, so a
+green states what produced it instead of leaving the reader to assume.
+
+</details>
+
 ```bash
 # 1. Install the plugin
 claude plugin marketplace add https://github.com/chrono-meta/forge-harness.git
@@ -109,6 +134,7 @@ cd ~/projects/{your-project} && claude
 | Solo dev, one project, just trying it | [`templates/starter_profile.md`](templates/starter_profile.md) — one command, curated first-five skills |
 | Multiple projects, want the compounding hub | Clone the hub (quickstart above) |
 | CI / non-Claude runtime, gates only | `npx @chrono-meta/fh-gate` (zero-install governance gate) |
+| Prefer `brew` over `npx`/`npm` | `brew tap chrono-meta/forge-harness && brew install forge-harness` — same 100%-parity content, different install UX (community tap; not yet in Homebrew Core, so `brew search` won't find it without the tap first) |
 
 ---
 
@@ -211,6 +237,10 @@ npx --package @chrono-meta/fh-gate fh-gate                    # default: Claude
 FH_BACKEND=codex npx --package @chrono-meta/fh-gate fh-gate   # Codex backend
 FH_BACKEND=auto npx --package @chrono-meta/fh-gate fh-gate "src/foo.ts" full
 # → FH_GATE_VERDICT: PASS | PENDING | BLOCKED | ESCALATE
+
+# or, via Homebrew (same content, no npx prefix needed after install):
+brew tap chrono-meta/forge-harness && brew install forge-harness
+fh-gate
 ```
 
 `fh-gate` uses the same FH governance prompt for both runtimes. `FH_BACKEND=claude` runs `claude --print`; `FH_BACKEND=codex` runs `codex exec`; `FH_BACKEND=auto` prefers Codex when both CLIs are present — note that `auto` is fallback *selection*: it runs ONE leg. `FH_BACKEND=cross` runs BOTH families and unions their findings (a finding only one family saw is still a finding, so it unions rather than votes); the verdict is the most severe across legs. It costs ~2x, so it is for load-bearing verdict/gate/irreversible-surface changes, not a default. The output always declares which legs actually ran (`FH_GATE_LEGS:`, `FH_GATE_DECORRELATED:`) — on a machine with only one family, `cross` degrades to that single leg and says so, because a single-family result that reads as cross-checked is worse than an honest one.

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>（加速工作），再把这些收益在你的整个项目组合中复利累积。
@@ -185,6 +191,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` 会降级为单腿并明确说明，因为让单家族结果读起来像交叉验证过更糟。

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.*

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

@@ -92,12 +92,32 @@ branch-claim 게이트    ① 영혼 필수   «무엇을 성공으로 볼 것
 안쪽 ③  ◀──빌린다──  바깥 기계   게이트를 검증한 4축 훅은 **세션/저장소 스코프의 것**이다.
                                 게이트가 자기 힘으로 자기를 검증한 게 아니다  [강한 증거]
 바깥 ②  ──먹인다──▶  안쪽 ②     두 축이 서로를 검증했다(각자 상대 주장을 반증)  [약한 증거]
+안쪽 ③  ◀──빌린다──  바깥 하네스 이 층은 이미 정본화됐다 — 새로운 건 ③ 스코프-차용
+                                프레임 안에서의 표본이다 (2026-08-14)  [중간 증거]
 ```
 
 **강한 쪽부터**: 안쪽 스코프는 **자기보다 바깥의 기계에 의존해서** ③을 완수한다.
 오늘 branch-claim 게이트를 통과시킨 4축 훅·마커·앵커는 전부 저장소 스코프 자산이다.
 즉 «메타하네스 자기 스코프» 는 독립 실행 단위가 아니다 — **바깥이 없으면 ③이 성립하지 않는다.**
 
+**이 층(바깥 하네스를 빌린다)은 이미 정본화돼 있다** — `harness_verification_core_extended.md`
+(2026-08-01, PR #225, ARC CLOSED): "Extended = 멀티하네스 클러스터에서 디스패치된 검증 도구,
+대상 하네스 자신의 검증 독트린 로드 금지(그게 탈상관의 요점)." 실증 N=2(qasp↔FH 슬라이스,
+7건 신규 접지 발견) + `feedback_decorrelation_axis_matches_failure_mode`(2026-08-07, mate PR
+#8, reps=3): 코어 결함은 하네스 무관 일치(6/6), **주변부 발견의 클래스가 하네스별로 갈린다**
+(같은 형태를 이 절이 지금 다시 보고 있다). ⚠️ 이 절의 초판은 이 선례를 못 찾고 "자리가 없다,
+n=1"이라고 적었다 — 바로 위 메모리 파일이 스스로 경고하는 실패모드("엣지 없어 선례를 못 찾고
+기록에 없다고 단정")를 **이 절 자신이 재현**했다. 정정: 미충족은 명제 부재가 아니라 **`crossfamily:`
+필드가 family-shaped 라 하네스 축을 typed 값으로 못 싣는다**는 좁은 배선 갭뿐이다.
+
+**2026-08-14 표본은 새 명제가 아니라 이 층의 세 번째 표본이다.** PMH 세션에서 `grep | head` 가
+증거 두 줄을 잘라 오독을 일으킨 사고를 PMH 내부 어떤 층도 못 잡고 다른 하네스(FH, PR #368 리뷰)가
+잡았다. **교란 미배제, 있는 그대로 적는다**: 그 파일(`scripts/sync-to-be.sh`)은 FH 소유 자산이라
+"다른 하네스"와 "원본 소유자"가 완전히 분리되지 않고, `head` 미사용 grep 은 스코프 문제가 아니라
+능력 문제이며, 이 클래스의 처방(대조엔 컨트롤 동반)은 이미 이 절 아래([[feedback_absence_
+measurement_needs_control]])에 있다. 표본이 지지하는 건 "바깥 하네스가 잡았다"까지이지
+"바깥 하네스가 필요하다"까지는 아니다.
+
 ⚠️ **약한 쪽은 약하다고 적는다.** 초판은 *"세션 축 분리로 **예산**이 생겨 3렌즈를 띄웠다"*
 라고 썼는데 **과장이다** — 두 세션은 예산이 독립이고, 축 분리가 준 것은 예산이 아니라
 **컨텍스트 집중**이다. 게다가 그 분리는 *계획된 탈상관*이 아니라 **원래 다른 두 작업**이었고,