@chrono-meta/fh-gate 1.4.59 → 1.4.61

package/README.md

@@ -72,6 +72,18 @@ claude
 > ✅ Claude reads `CLAUDE.md` and asks what project to connect or what task to start.
 > Say **"Connect a project"** → hub scans `../`, finds `.git` directories, creates `tracks/{project}/`.
 
+**Your first 15 minutes** — what success looks like, and what to do with it:
+
+1. You'll know setup worked when a greeting ("hi") shows the 🐿️ door menu, and "Connect a project"
+   creates `tracks/{your-project}/`.
+2. Then grab an immediate win in the same session: say **"accelerate this project"** (ranked plan of
+   skills/plugins worth wiring, install-gated) or **"run /context-doctor"** (token-waste scan).
+3. One honest note: FH's core payoff is **compounding** — session records, harvested learnings,
+   cross-session memory. It shows from **session 2 onward**. Day one gives you the menu, the
+   acceleration plan, and governance gates; don't judge the compounding on day one.
+
+Unfamiliar words on the way? → [`knowledge/shared/GLOSSARY.md`](knowledge/shared/GLOSSARY.md).
+
 **Plugin only (no clone):**
 ```bash
 claude plugin marketplace add https://github.com/chrono-meta/forge-harness.git  # once
@@ -79,16 +91,20 @@ claude plugin install -s user fh-meta@forge-harness
 cd ~/projects/{your-project} && claude
 ```
 
-> ⚠️ **Plugin-only is partial synergy.** You get the skills and agents, but **not** Layer 1 — the
-> `CLAUDE.md` governance (active onboarding, the 4-axis gate, mode branching) and the compounding
-> context (`tracks/` memory accumulation, `harvest-loop` learning). Each skill runs the same in
-> isolation; what's missing is the orchestration that makes them compound across sessions. Clone the
-> hub (above) when you want the full set, not just the tools.
+> ⚠️ **Plugin-only is partial synergy.** You get the skills and agents, but **not** the hub-side
+> orchestration — the `CLAUDE.md` governance (active onboarding, the 4-axis gate, mode branching;
+> automation layer) and the compounding context (`tracks/` memory accumulation, `harvest-loop`
+> learning; methodology layer).
+> Each skill runs the same in isolation; what's missing is the orchestration that makes them compound
+> across sessions. Clone the hub (above) when you want the full set, not just the tools.
 
-> 🚪 **New here / just want the skills?** Start with the opinionated front door —
-> [`templates/starter_profile.md`](templates/starter_profile.md): one install command, a curated
-> first-five skills, and a zero-install governance gate (`npx … fh-gate`). The other skills wait
-> until you need them.
+**Which entry path is for you?**
+
+| You are… | Start with |
+|---|---|
+| 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) |
 
 ---
 
@@ -131,12 +147,13 @@ attention is spent only where a change is irreversible.
 
 Scale is the second point. A **skill, agent, or plugin** is a tool. A **harness** is a level up — a *star*:
 one project's tools, rules, gates, and memory bound into a single working body. **forge-harness is the
-galaxy those stars live in** — it holds many harnesses in one gravity well, keeps them in orbit (a
-shared floor, no drift), and lets them evolve together instead of scattering. And the system is a
-*nursery*, not just 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 the gravity comes from four things:
+galaxy those stars live in**: it binds many harnesses onto a shared floor to prevent drift, and lets
+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:
 
 **① 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
@@ -220,7 +237,7 @@ FH_BACKEND=codex npx --package @chrono-meta/fh-gate fh-goal --prompt "Implement
 
 The broader FH automation layer still depends on Claude Code for sub-agents, hooks, and slash commands. The portable path is shared documents plus runtime adapters, not separate Codex and Claude forks.
 
-**Recommended posture — Claude Code as orchestrator, others as sidecars.** FH's automation layer (auto-firing hooks, sub-agent dispatch, onboarding, memory) is Claude-Code-native, so the fullest experience runs **Claude Code as the main orchestrator with Gemini, Codex, or Antigravity (`agy`) as actively-used sidecars**. You can also run a **non-CC runtime as your main agent** — you keep the full methodology layer and M1 skills through `fh-gate`/`fh-run`, but you do **not** get the autopilot layer: hooks don't auto-fire, M2 agent-dispatch steps need the adapter (or interactive approval), and M3 skills are reference-only. This is a deliberate two-layer boundary, not a gap to be closed. Per-runtime detail: [`docs/codex-compat.md`](docs/codex-compat.md) (tier-by-tier) and [`multi_model_sidecar_strategy.md`](knowledge/shared/harness-core/multi_model_sidecar_strategy.md) (sidecar engines, including the Gemini→`agy` succession at the 2026-06-18 EOL).
+**Recommended posture — Claude Code as orchestrator, others as sidecars.** FH's automation layer (auto-firing hooks, sub-agent dispatch, onboarding, memory) is Claude-Code-native, so the fullest experience runs **Claude Code as the main orchestrator with Gemini, Codex, or Antigravity (`agy`) as actively-used sidecars**. You can also run a **non-CC runtime as your main agent** — you keep the full methodology layer and M1 skills (M1 = runs on any runtime as written; M2 = needs agent dispatch; M3 = Claude-Code-native — the portability tiers detailed in [`docs/codex-compat.md`](docs/codex-compat.md)) through `fh-gate`/`fh-run`, but you do **not** get the autopilot layer: hooks don't auto-fire, M2 agent-dispatch steps need the adapter (or interactive approval), and M3 skills are reference-only. This is a deliberate two-layer boundary, not a gap to be closed. Per-runtime detail: [`docs/codex-compat.md`](docs/codex-compat.md) (tier-by-tier) and [`multi_model_sidecar_strategy.md`](knowledge/shared/harness-core/multi_model_sidecar_strategy.md) (sidecar engines, including the Gemini→`agy` succession at the 2026-06-18 EOL).
 
 **Empirical result (2026-05-31)**: Applied to OpenCode's AI-generated `permission/arity.ts` (163 lines, CI green). Current gate semantics classify this as BLOCKED: 2 A-grade findings CI didn't catch (short-token overflow in allowlist, executor tools absent from arity table).
 
@@ -258,7 +275,9 @@ All four movements ship. Temper was named before it was built — deliberately (
 two more signatures keep it running: `harvest-loop` (each session's lessons become permanent skills) and
 `agent-composer` (orchestrate the dispatch). The other skills wait until you need them — full list below.
 
-## 37 skills · 8 agents
+## 38 skills · 8 agents
+
+> Count = non-deprecated skills (deprecated redirect stubs — kept only for old-name routing — excluded).
 
 <details>
 <summary>Full asset activation check</summary>

package/README.zh.md

@@ -127,11 +127,11 @@ Project B  ──→  在 CLAUDE.md 中连接中枢
 
 规模是第二个重点。**技能、agent 或插件** 是一个工具。**框架** 高出一级 —— 是一颗 *星*：
 一个项目的工具、规则、门禁与记忆，绑成一个运作的整体。**forge-harness 就是这些星所栖居的
-星系** —— 它把众多框架收进同一个引力井，让它们保持在轨（共享的下限、无漂移），并让它们
-一起演化而不是四散。而且这个系不只是容器，更是*育星摇篮 (nursery)*：FH 可以在自己的沙箱里
-**以仿真方式跑一个现场框架** —— 单次昂贵，总体更便宜，因为试错汇聚在一处并复利累积 —— 当仿真
-验证通过，它就把该项目**孵化输出**为一个独立的、特化的框架。这就是它所朝向的目标。实际上，
-这份引力来自四件事：
+星系**：它把众多框架绑定在共享的下限之上以防止漂移，并让它们一起演化而不是四散。
+
+这个星系不只是容器。FH 可以在自己的沙箱里**以仿真方式跑一个现场框架** —— 单次昂贵，总体
+更便宜，因为试错汇聚在一处并复利累积 —— 当仿真验证通过，它就把该项目**输出 (emit)** 为一个
+独立的、特化的框架。这就是它所朝向的目标。实际上，它以四种方式运作：
 
 **① 组装 (Assemble)** —— FH 以优化后的 token 成本运行一整 *簇* 框架，并把最合适的那个交到你手上。
 你不是一个个去接线技能；你得到的是一个 **框架** —— 连同它的插件、技能与 agent —— 已按需组装好。

package/bin/fh-codex-doctor.js

@@ -117,15 +117,25 @@ function extractBacktickNames(line) {
   return names;
 }
 
+// The tier table IS this doctor's instrument. If it cannot be read or parsed, every skill
+// comes back documentedTier=null, no M1 rule can ever fire, findings is empty, and the report
+// says OK with --strict exiting 0 — a broken instrument reporting "no violations". An
+// unreadable source (permissions, wrong root) and a parse yielding zero rows (the table's
+// markdown drifted, e.g. bold dropped from `| **M1 |`) both land there, so both are reported
+// as an instrument failure rather than a clean bill of health.
 function documentedTiers(root) {
   const sources = [
     path.join(root, 'AGENTS.md'),
   ];
   const tiers = new Map();
   const evidence = [];
+  const sourceErrors = [];
   for (const source of sources) {
     const text = maybeReadText(source);
-    if (!text) continue;
+    if (!text) {
+      sourceErrors.push(`${rel(root, source)}: missing or unreadable`);
+      continue;
+    }
     const lines = text.split('\n');
     lines.forEach((line, index) => {
       const tierMatch = line.match(/\|\s*\*\*(M[123])\b/);
@@ -137,7 +147,12 @@ function documentedTiers(root) {
       }
     });
   }
-  return { tiers, evidence };
+  if (tiers.size === 0 && sourceErrors.length === 0) {
+    sourceErrors.push(
+      `${rel(root, sources[0])}: readable but yielded 0 tier rows — the tier table format drifted`
+    );
+  }
+  return { tiers, evidence, sourceErrors };
 }
 
 function compatDocTierMentions(root, skillNames) {
@@ -333,7 +348,13 @@ function buildReport(root) {
   }
 
   return {
-    status: findings.some((f) => f.severity === 'HIGH') ? 'DRIFT' : 'OK',
+    // INSTRUMENT_ERROR outranks both: without a tier table this run measured nothing, and
+    // "measured nothing" must not be reported as OK (nor as DRIFT, which would claim a
+    // finding it never made).
+    status: docs.sourceErrors.length > 0
+      ? 'INSTRUMENT_ERROR'
+      : findings.some((f) => f.severity === 'HIGH') ? 'DRIFT' : 'OK',
+    instrumentErrors: docs.sourceErrors,
     root,
     counts,
     agentCards: loadAgentCards(root),
@@ -411,6 +432,16 @@ function main() {
   } else {
     printText(report);
   }
+  // An instrument failure is not a passing run. It exits non-zero unconditionally — not only
+  // under --strict — because the failure mode it guards is precisely a caller reading exit 0
+  // as "no drift" when nothing was measured. 10 = harness error, distinct from 1 = drift found.
+  if (report.status === 'INSTRUMENT_ERROR') {
+    for (const err of report.instrumentErrors) {
+      process.stderr.write(`ERROR: tier source unusable — ${err}\n`);
+    }
+    process.stderr.write('  Nothing was classified, so no drift could be detected. Failing closed.\n');
+    process.exit(10);
+  }
   if (args.strict && report.counts.findings.HIGH > 0) {
     process.exit(1);
   }

package/bin/fh-gate.js

@@ -1,9 +1,21 @@
 #!/usr/bin/env node
 'use strict';
+// Thin wrapper — the exit code IS the contract (0 PASS / 1 PENDING / 2 BLOCKED /
+// 3 ESCALATE / 10 harness-error / 11 arg-error / 12 dry-run). execFileSync throws on any
+// non-zero exit, so an uncaught throw collapsed every one of them into node's own exit 1 —
+// i.e. BLOCKED arrived at the caller as PENDING ("proceed with awareness"). Propagate the
+// real status, and fail closed (10) when there is no status to propagate.
 const { execFileSync } = require('child_process');
 const path = require('path');
-execFileSync(
-  path.join(__dirname, '..', 'scripts', 'fh-gate.sh'),
-  process.argv.slice(2),
-  { stdio: 'inherit' }
-);
+try {
+  execFileSync(
+    path.join(__dirname, '..', 'scripts', 'fh-gate.sh'),
+    process.argv.slice(2),
+    { stdio: 'inherit' }
+  );
+} catch (err) {
+  if (typeof err.status === 'number') process.exit(err.status);
+  // Killed by a signal, or the script could not be spawned at all: no verdict exists.
+  console.error(`fh-gate: could not run the gate (${err.signal || err.code || err.message}) — failing closed`);
+  process.exit(10);
+}

package/bin/fh-goal.js

@@ -1,9 +1,17 @@
 #!/usr/bin/env node
 'use strict';
+// Thin wrapper — propagate the script's real exit status. execFileSync throws on non-zero,
+// so an uncaught throw collapsed every distinct status into node's own exit 1.
 const { execFileSync } = require('child_process');
 const path = require('path');
-execFileSync(
-  path.join(__dirname, '..', 'scripts', 'fh-goal.sh'),
-  process.argv.slice(2),
-  { stdio: 'inherit' }
-);
+try {
+  execFileSync(
+    path.join(__dirname, '..', 'scripts', 'fh-goal.sh'),
+    process.argv.slice(2),
+    { stdio: 'inherit' }
+  );
+} catch (err) {
+  if (typeof err.status === 'number') process.exit(err.status);
+  console.error(`fh-goal: could not run (${err.signal || err.code || err.message}) — failing closed`);
+  process.exit(10);
+}

package/bin/fh-run.js

@@ -1,9 +1,17 @@
 #!/usr/bin/env node
 'use strict';
+// Thin wrapper — propagate the script's real exit status. execFileSync throws on non-zero,
+// so an uncaught throw collapsed every distinct status into node's own exit 1.
 const { execFileSync } = require('child_process');
 const path = require('path');
-execFileSync(
-  path.join(__dirname, '..', 'scripts', 'fh-run.sh'),
-  process.argv.slice(2),
-  { stdio: 'inherit' }
-);
+try {
+  execFileSync(
+    path.join(__dirname, '..', 'scripts', 'fh-run.sh'),
+    process.argv.slice(2),
+    { stdio: 'inherit' }
+  );
+} catch (err) {
+  if (typeof err.status === 'number') process.exit(err.status);
+  console.error(`fh-run: could not run (${err.signal || err.code || err.message}) — failing closed`);
+  process.exit(10);
+}

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

@@ -103,9 +103,79 @@ pass/block verdict* — e.g. `agent-composer`, `goal-quench`, `asset-placement-g
 
 ---
 
+## §Cross-Family-Complement
+
+Execution detail for CLAUDE.md §FH Improvement 4-Axis Auto-Gate → *Cross-family complement*. The rule
+that a load-bearing change recruits ≥1 different-family auditor, that it is autonomous once consented,
+and that the governor keeps the terminal verdict + source-grounds every finding — all stay in CLAUDE.md.
+
+**Sidecar mapping (per the UAP)** — pick by task class, not by preference:
+
+| Task class | Recruit | Why |
+|---|---|---|
+| Repo-grounded code / security audit | `codex` (`gpt-5.5`, xhigh) | reads the actual tree; strongest on verdict-code logic |
+| Breadth / multimodal / frontier scan | `agy` (Gemini) | wide recall, video + image ingest |
+| Batch / free-tier arm | local 4090 over Tailscale | no token cost; weaker judge — anchor it |
+
+**Degrade**: when no different-family auditor is reachable, say so and fall back to single-session — but
+note the exception in §Field-Harness Load-Bearing Change Gate, where an unreachable cross-family panel is
+**NOT-CONVERGED** rather than a silent same-family pass (that surface is pre-merge and irreversible-adjacent).
+
+**Dogfood evidence (2026-06-27)**: a cross-family pass caught a HIGH execution-side-effect blind spot that
+the same-family reviewers **and** the target-tier sim all shared. That is the decorrelation value made
+concrete: the miss was not a depth failure (the sim ran at the right tier) but a *correlation* failure —
+every reviewer in the Claude family read the change the same optimistic way. Decorrelation is the only
+lever that moves a correlated blind spot; more same-family review does not.
+
+---
+
+## §Destructive-Op-Hook-Coverage
+
+Execution detail for CLAUDE.md §Destructive-Op Gate. The **order invariant** (enumerate → recover →
+destroy), the **3 steps**, the `DESTRUCTIVE_OP_OK=1` override, and the **fail-closed degrade direction**
+stay in CLAUDE.md — they are load-bearing every session. What follows is the mechanics + honest scope.
+
+**Per-ref verdict (pre-push hook)**: the hook detects the destructive refspec on stdin — *delete* = local
+SHA all-zeros; *force* = remote SHA not an ancestor of local — then judges each ref:
+
+| Ref state | Verdict | Hook action |
+|---|---|---|
+| Branch delete, fully merged | SAFE | allowed |
+| Branch delete, commits off base + 0 unique paths | CHECK | **blocked** — needs a judged content look |
+| Branch delete, unique paths present | REVIEW | **blocked** — recovery mandatory |
+| Force / non-ff push | — | **always blocked** |
+| Tag / notes delete | — | **always blocked** |
+
+The verdict is load-bearing, not decorative: a merged-branch cleanup passes, a silent-loss CHECK does not.
+This is the enumerate step as a mechanical floor rather than prose.
+
+**What it does and does NOT close (honest)**: it closes the **honest-weak-model** gap — an agent that
+simply *forgot* the prose gate is now mechanically stopped. It does **not** close the
+**injected/adversarial** gap: an agent under instruction can set the override or pass `--no-verify`, and a
+client-side hook is readable and bypassable by design. The hard floor for the adversarial case is
+**server-side branch protection** (GitHub *Restrict deletions* / *Restrict force pushes*) — this hook is
+the honest-model floor, branch protection is the hard floor.
+
+**Scope**: covers only git pushes *from a hook-installed repo*. `npm publish` is mechanized separately via
+`prepublishOnly` (see §Pre-Publish-Hook-Coverage (c)); the remaining non-git surface — a separate-repo
+`gh repo create --public` / visibility flip — is genuinely un-hookable and stays prose +
+`PRE-PUBLISH-CHECKLIST.md`.
+
+**Portability defect class**: the hook is bash-3.2 safe (macOS default `/bin/bash`). The original draft
+used a bash-4 associative array that crashed **fail-OPEN** on 3.2 — caught in test. Worth naming: a
+portability break in a gate degrades toward permissive unless the gate is written to fail closed on its
+own errors.
+
+**Origin (2026-06-10 branch cleanup)**: pre-deletion enumeration recovered a parallel session's card
+(weekly-audit completion + #88 merge state) that existed **only on an unmerged branch** with zero unique
+paths — exactly the CHECK class, and invisible to "is it merged?" intuition. Deletion without the gate
+destroys live state without anyone noticing. This is why the loss class is called *silent*.
+
+---
+
 ## §Pre-Publish-Hook-Coverage
 
-**Hook coverage — two distinct actions (refined 2026-06-17)**:
+**Hook coverage — three distinct actions** (refined 2026-06-17 for (a)/(b); (c) added 2026-06-27):
 - **(a) repo-go-public** (`gh repo create --public` / a visibility flip) is irreversible and usually in a
   **separate repo** — the FH pre-commit hook **cannot** catch it. That stays **AI-behavioral** (proactive
   trigger) **+ a portable checklist** (`templates/PRE-PUBLISH-CHECKLIST.md`), run on any repo/machine.
@@ -126,6 +196,23 @@ pass/block verdict* — e.g. `agent-composer`, `goal-quench`, `asset-placement-g
   plaintext only (encoded tokens out of scope); a line-split backstop catches a token wrapped across
   lines; `PUBLIC_SURFACE_OK=1` overrides and is logged to a gitignored audit trail for the weekly audit.
   Residuals (split-encoding, override-not-populated, override abuse) are documented, not silent.
+- **(c) `npm publish`** — mechanically gated by `scripts/public_surface_scan_files.sh`, wired into
+  `prepublishOnly` (`npm run release` also runs it *outside* the lifecycle). Unlike (b) it scans the
+  **full content of the exact npm-published file set** (`npm pack --dry-run`), *not* a commit diff — so a
+  token committed **before the scan existed**, or carried in a `files[]` entry, is still caught at the
+  registry boundary. HIGH/MED block; `PUBLIC_SURFACE_OK=1` overrides + logs. **Fail-closed** when patterns
+  or the file set are unresolved, when the parse looks partial, **or when the gitignored operator override
+  is absent** — defaults-only would otherwise green-PASS a HIGH company literal on a fresh clone or CI runner.
+
+**Named residuals for (c)** — it is a denylist **on the npm CLI path with scripts enabled**, not a
+universal secret-scanner:
+
+| # | Residual | Mitigation |
+|---|---|---|
+| i | `npm publish --ignore-scripts`, a CI `.npmrc` with `ignore-scripts=true`, or `pnpm`/`yarn publish` **skip the lifecycle hook entirely** | route publishes through `npm run release`, or add an explicit CI scan step |
+| ii | scans only the **loaded patterns** — an **un-patterned secret shape** (an API key the patterns don't describe) still ships | pattern coverage is the limit; pair with a real secret-scanner if that shape matters |
+| iii | on a runner without the gitignored override it is **defaults-only** unless populated | populate the override in each authoring env (esp. the company env) |
+| iv | scans **working-tree content, not the final tarball bytes** | benign today (content-neutral lifecycle: prepare=chmod, no prepack) — **re-open if a content-generating publish lifecycle is added** (cross-family audit 2026-06-27) |
 
 > Origin: 2026-06-05 `phantom-gate` shipped public, then needed a private→de-company-scrub→re-public
 > round-trip (`fh_signal_2026-06-05_fh-direct`). PSA existed but nothing forced it pre-publish. 2026-06-17

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

@@ -96,13 +96,13 @@ Identity marker: every greeting response opens with **🐿️ then an identity-r
 > 🐿️  **Welcome to FH.** *forge-harness is a tool hub for rapidly setting up Claude Code projects. It supports plugin recommendations, project setup, and harness diagnostics. What would you like to work on?*
 
 **Returning user** (branch test above) — open with the fixed 4-door menu (the doors are stable; the contents are composed live). A summary copy lives in CLAUDE.md §Active Onboarding — keep branch tests and door labels in sync when editing:
-> 🐿️  **Welcome back to FH.** *What would you like to start? ① Map a project · ② Create a new project · ③ Accelerate a mapped project (work · Full-Harness · skills/agents/plugins) — {field candidates} · ④ Cross-project synergy*
+> 🐿️  **Welcome back to FH.** *What would you like to start? ① Map a project · ② Create a new project · ③ Accelerate **or diagnose** a mapped project (work · Full-Harness · skills/agents/plugins · 진단) — {field candidates} · ④ Cross-project synergy*
 >
 > (When **FH-dev state exists** — the operator — the welcome line is **"The FH operator — good to see you."** in place of "Welcome back to FH.")
 
 - **① Map a project** → routes to `auto_project_mapping.md`; after a successful mapping, offer the §6 Full-Harness promotion prompt
 - **② Create a new project** → Step 3-0 (new project setup)
-- **③ Accelerate a mapped project** → compose live from `CATALOG.md` / active tracks / the session card's **field-side** candidates — never hardcode a track name; read current state each time so the menu cannot go stale. **Acceleration levers** (offer per project state, each user-approved):
+- **③ Accelerate or diagnose a mapped project** → compose live from `CATALOG.md` / active tracks / the session card's **field-side** candidates — never hardcode a track name; read current state each time so the menu cannot go stale. Picking ③ with a *fix/diagnose* intent ("고칠 거 있나", "점검") routes to the **Field-Harness Diagnostic** (CLAUDE.md §Field-Harness Diagnostic) rather than the install plan. **Acceleration levers** (offer per project state, each user-approved):
   - **Full-Harness promotion** for projects still on light mapping (`auto_project_mapping.md` §6)
   - **Skill-ification** of repeated patterns (`#skill-candidate` tag at 3+ recurrences → SKILL.md draft; FH skill gates — diet · Done When · triggers — apply to field skills too)
   - **Sub-agent proposals** (`.claude/agents/*.md`, invocation rules in `operations.md`)

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

@@ -0,0 +1,48 @@
+# Field-Harness Diagnostic — compose → rank → HITL (detail)
+
+> Always-loaded summary: `CLAUDE.md §Field-Harness Diagnostic`. This file is the detail home —
+> the full lens table, dogfood examples, and guard rationale. Read when actually running the
+> diagnostic on a mapped project.
+
+The Load-Bearing Change Gate fires on a **specific field code change**. This diagnostic is its
+**on-demand pull sibling**: when the operator, working in a mapped project, asks to *diagnose* or
+*improve* the harness itself ("진단해줘", "개선해줘", "check this project"), don't hand-pick one
+skill — **compose the checks FH already has into a single ranked diagnostic list and get per-item
+approval.** The value is that the operator asks once and the harness surfaces *everything* worth
+fixing, ranked, instead of the operator having to know which of a dozen skills to invoke. Every fix
+is HITL — the diagnostic **proposes**, never auto-edits.
+
+## Composition (no-reinvention — every row is an existing check; the diagnostic only *routes and ranks*)
+
+| Lens | Existing check | Catches (real examples from 2026-07-08) |
+|---|---|---|
+| **Confidentiality / leak** | `/public-surface-audit` (incl. Step 3c ignore-verification) | a hardcoded internal API host literal in a SKILL body; a `local_*_context.md` that is **tracked** when it should be gitignored (the gitignore-mistake class) |
+| **Split integrity** | `/phantom-quench` **Step 2.7** (bidirectional) | orphan detail sections + phantom pointers in a SKILL.md ↔ SKILL_detail.md pair |
+| **Token / salience** | salience-split candidates (`/context-doctor` · `/salience-splitter` targets) | oversized always-loaded SKILL.md / CLAUDE.md — trim candidates |
+| **Structure** | `/harness-doctor` (L1–L4) | orphaned/redundant/decorative units, missing Done-When, ≥70% overlap |
+| **Verdict/gate degrade** | `scripts/degrade_direction_scan.sh` | a field verdict/gate helper that degrades toward permissive (advisory pre-screen) |
+| **Loop-readiness** (황민호 loop-eng 5-question lens, 2026-07-10 — detail home: `loop_engineering.md`, incl. the FH loop inventory + design-time discipline) | *Loop-runtime axis — net-new vs Structure* (harness-doctor scans static form; this scans whether the path closes a loop). **Mechanical grep**: `/goal-quench`·`/loop` wiring present · check-class token declared. **Judged**: is the persisted state (card/handoff/memory) actually reloaded · is the declared check-class anchored, not judged-only · does the path halt. Done-When *presence* → see Structure row (no double-grep). **Adversarial pair** (for the judged sub-checks — decorrelated, behavior-vs-checklist): a target-tier blind sim that *runs* the path and observes whether it halts + persists, rather than re-checklisting it (the harness litmus shares this lens's axis, so it is a co-lens, not the adversary). | an agent path that *runs but doesn't loop*: no completion criterion (Done-When absent), judged-only validation with no anchor, no halt/budget guard (runaway/cost), or no state carried to the next run — the 5 questions (initiate · complete · validate · halt · persist) with 0 answers |
+
+## Output
+
+One ranked list, `M` (must-fix) / `S` (should-fix) / `R` (recommended) — same tiering as
+harness-doctor — each item stating *lens · file:line · one-line fix*. **Then HITL**: the operator
+approves per item (or a batch); an approved fix routes to the owning skill's normal path (and, if it
+is itself a load-bearing field change, through the Load-Bearing Change Gate). **Nothing is
+auto-fixed** — the diagnostic's job is the *intelligent list*, the human's job is the *go*.
+
+## Guards
+
+- **(a) Project-level ask only** — fires on a project-level "진단/개선" ask, not a single-file edit
+  request (those go straight to the relevant skill).
+- **(b) Once per ask** — not a per-turn nag.
+- **(c) Company residency** — run leak/confidentiality lenses locally, sanitize before any
+  cross-family dispatch, and *surface* company-sensitive findings (tracked company hosts,
+  git-history rewrites) for operator decision rather than auto-fixing them. Dogfood 2026-07-08: the
+  `local_pmh_context.md` tracked-company-hosts finding was surfaced, not auto-untracked — history
+  rewrite is the operator's call.
+- **(d) Autonomy floor** — the compose/rank judgment is trusted at opus-tier+; below-floor, run the
+  individual checks and present raw rather than silently skipping a lens.
+
+**Scale to the ask**: a quick "뭐 고칠 거 있어?" runs the cheap mechanical lenses (leak · split ·
+token); "제대로 진단해줘" runs all six + harness-doctor depth.

package/knowledge/shared/harness-core/measurement-integrity-checklist.md

@@ -17,6 +17,7 @@ becomes a gate other skills invoke, revisit the weight.
 | 2 | **Non-deterministic borderline verdicts** — contested/borderline cases flip across runs (observed: haiku 4/4 flip; flagship models flip too — flipping is **not** a tier signal). A single draw is noise, not a measurement. | **reps ≥ 3 on any borderline/contested verdict.** A single run on a contested case is inadmissible. Report the flip pattern (STABLE vs FLIP), not just the modal verdict. |
 | 3 | **Generic self-identity probe** — a probe any model passes ("are you working? → OK") proves nothing about *which* model answered. | **Use a discriminating probe** — one that two different models answer *differently*. A generic-pass probe is invalid. The probe is a **pattern, not a fixed string**: a probe that discriminates Opus 4.8 from Sonnet 4.6 today may both-pass a future model generation, so **re-validate the probe each model generation** (same staleness class `memory-hygiene` exists to catch). |
 | 4 | **Serving-path / quantization variance** — the *same* display-name model served over two different backends (different quantization/infra) is a **different instrument** and yields materially different measurements. Observed: one GLM-5.2 model family gave effect-size delta **+0.21** when served via an internal NVFP4-quantized deployment vs **+0.08** via an OpenRouter relay — same model name, ~2.6× different effect (n=864, reps≥3). A correctly-pinned display name (item #1) is **necessary but not sufficient**. | **Pin *and record* the serving path** — backend host + quantization, not just the display name. Two runs are comparable only if the serving path matches; a name match across different infra is an implicit apples-to-oranges. When you cannot hold it fixed, **report the serving path as a measured variable**, not a constant. |
+| 5 | **Injected-context contamination (blind-sim class)** — a subagent dispatched to evaluate a *modified* instruction file answers from the **auto-injected project context** (claudeMd/memory baked into its system prompt at spawn) instead of reading the target. Observed twice in one session (2026-07-17): a "blind sim" quoted section numbering that existed only in the pre-edit file, and a second sim cited trigger-table rows that had been **deleted** from the file it claimed to have read — tool-use count 0–1 in both. The measurement *looks* grounded (fluent, plausibly cited) but the instrument never touched the target. A prompt-line telling it to ignore injected context is **not sufficient** — both runs had one. | **Force mechanical grounding a stale answer cannot fake**: ① stage the target at a **neutral path** (tmp copy) the injection cannot cover; ② require **verbatim quotes** (or grep line-number output) from that path for every claim; ③ design the probe around a **content discriminator** — something present only in the new version, or *absent* from it (a deleted row cited = instant invalidation); ④ treat **tool-use count as a validity signal** — a sim that "read two files" with 0–1 tool calls is invalid regardless of answer quality. Re-run, don't argue with a contaminated result. |
 
 ## Why these are entangled (and why they matter beyond their own scope)
 
@@ -36,10 +37,16 @@ served over a different quantization/backend). The verified identity a measureme
 sound once the serving path of each family is itself pinned, else "different family" silently smuggles
 "different infra" ([[reference_measurement_serving_path_variance]]).
 
+Item #5 (injected-context contamination) is item #3's sibling on the *input* side: #3 proves *who*
+answered, #5 proves *what they actually read*. Both reduce to the same mechanical-anchor rule — never
+accept a measurement's self-report (of identity or of grounding) when a discriminating mechanical
+check is available. Its sharpest tool is the **deleted-content discriminator**: a probe target that no
+longer contains X makes any answer citing X self-invalidating — certainty no prompt instruction buys.
+
 ## Done When
 
-- The checklist enumerates all four failure modes, each with its countermeasure.
-  *Check class: mandatory-pass (binary — four items present, each with a countermeasure).*
+- The checklist enumerates all five failure modes, each with its countermeasure.
+  *Check class: mandatory-pass (binary — five items present, each with a countermeasure).*
 - The probe item specifies a **discriminating** test and rejects generic probes.
   *Check class: judged, pair: a probe that two different models both pass must FAIL this check; a
   discriminating one must distinguish them.*

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

@@ -0,0 +1,66 @@
+# Multi-Harness Evolution Loop — audit → persona → fix → devolution-check → settle
+
+> Operator-forged pattern (2026-07-17). The operator ran this sequence once across three harnesses
+> and named it afterward: *"오늘 내가 제시한 기법 자체가 fh·pmh를 진화시킬 수 있는 루프였을 거라고
+> 생각해."* This doc is the harvest — the loop as a repeatable protocol, with its n=1 evidence and
+> a promotion gate. It is a **composition of existing FH checks** (no-reinvention: every phase
+> routes to an existing asset); what is net-new is the loop shape and its two doctrine points below.
+
+## The loop (5 phases)
+
+| Phase | What runs | Existing asset routed | Check class |
+|---|---|---|---|
+| **1. Structure audit** | harness-doctor lens per harness **+ a cluster lens across them** (registry freshness · track sync · cross-refs · skill-bus reachability · gate propagation · orchestration artifacts) | `/harness-doctor` · LOCAL_SKILL_REGISTRY · Field-Harness gates | mechanical + judged |
+| **2. Persona usability audit** | beginner (cold-read, minutes-to-first-value) · main-player (daily intent-utterance test: do natural phrases reach the right skill?) · expert (frontier bar, external citations mandatory) — per harness | fh-meta persona agents (beginner / main-player / expert) | judged, adversarially paired by tier diversity |
+| **3. Fix application** | fixer agents per repo, **verify-before-act on every claimed defect** (a false finding gets skipped with evidence, not applied); each repo's own gates honored, HITL-deferred items go to a ranked backlog instead of being forced | fixer dispatch + per-repo 4-axis / pre-commit gates | mechanical (grep-verify per fix) |
+| **4. Devolution check** | adversarial regression audit of the fixes themselves — *"is anything now WORSE than before?"* — cross-family (codex) on public repos, same-family with an honest residency note on company repos; **iterate fix→re-verify until CONVERGED** | `auto-decorrelation` posture · codex headless · target-tier blind sim | cross-family + mechanical anchor |
+| **5. Settle** | canonical wiki node + INDEX pointer (machine side) **+ operator-readable report pushed to where the operator actually reads** (Obsidian/iCloud mirror) + ranked M/S/R backlog of operator-decision items | wiki 규약 · sync-wiki-to-icloud | mandatory-pass (artifacts exist) |
+
+## Two doctrine points (the net-new judgment content)
+
+1. **Usability is a first-class diagnostic axis, not polish.** The loop's n=1 run found the same
+   root defect in all three harnesses — *the routing surface was narrower than the user's real
+   daily utterances* — and structure-only audits (phase 1 alone) had missed it for months. The
+   operator's framing is the axis: "성능이 좋아도 결국 사용하기 쉽고 직관적이어야" — a harness whose
+   speech doesn't reach is failing regardless of internal rigor. Phase 2 is therefore not optional
+   decoration on phase 1; it is the half of the diagnosis that structure scans cannot see.
+2. **Improvement without a devolution check is half a loop.** Phase 4 exists because phase 3's
+   fixes are themselves AI-authored changes — the same optimistic-author blind spot the
+   cross-family gate guards. In the n=1 run, phase 4 caught a real regression that phases 1–3
+   produced (a README layer mis-attribution that made vague wording *wrong*), plus two S-tier
+   follow-ups in the field fixes. "다 하고 나서 기존보다 어떻게 개선되었는지, 오히려 퇴화한 부분은
+   없는지 점검" — the loop is not done at "fixes applied"; it is done at CONVERGED.
+
+## Guards (inherited, restated for the loop)
+
+- **Residency**: company-token repos never go to an external model family; their devolution check
+  runs same-family with the limitation recorded, not hidden.
+- **Verify-before-act**: every audit finding is re-verified against disk before a fixer applies it
+  (n=1 run: one "typo" finding was in-house jargon — correctly skipped with source evidence).
+- **HITL boundary**: judgment items (canonical-count decisions, dual-source direction, gate
+  loosening, architecture surgery) are never auto-applied — they land in the ranked backlog.
+- **Autonomy floor**: compose/rank judgments at opus-tier+; the loop was designed to run
+  autonomously on an explicit operator go ("자체적으로 돌아줘"), not as a standing daemon.
+
+## n=1 evidence (2026-07-17)
+
+Three harnesses (FH hub + two mapped field harnesses), 21 agents total (12 audit · 2 fixer ·
+7 verification). Outcomes: hub always-loaded footprint over-threshold closed (TARGET-rooted
+95.8k → 79.9k chars); three repos' routing surfaces extended to cover the measured daily
+utterances; ~10 phantom references replaced with disk-verified targets; registry brought to
+parity (mirror-dedup for the fork, lockline for the irreversible-execution skill); one real
+regression caught and fixed by the cross-family pass; final verdicts CONVERGED across all three
+repos. Ranked residual backlog delivered for operator decisions.
+
+## Promotion gate
+
+This doc is the pattern's home at **n=1**. Per evidence-threshold build discipline, do NOT build a
+skill or runner from it yet. Promotion path: a second full run (n=2, ideally on a different harness
+set or triggered from a field cwd) → then decide skill-ification (`/harness-evolution-loop`
+orchestrator skill, chamber-screened) vs staying a documented protocol. Cadence candidate
+(quarterly, alongside the harness-doctor 30-day cadence) is also an n≥2 decision.
+
+Related: `harness_6axis_framework.md` (axes 5–6) · `field_harness_diagnostic.md` (single-project
+pull sibling) · `hub_compounding_loop.md` (the learning-return this loop feeds) ·
+`measurement-integrity-checklist.md` (phase-4 instrument hygiene — the n=1 run also invalidated a
+contaminated sim and re-ran it with a verbatim-quote protocol).

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

@@ -0,0 +1,82 @@
+# Onboarding / Acceleration Autopilot — discover → compose → rank → install-HITL (detail)
+
+> Always-loaded summary: `CLAUDE.md §Onboarding / Acceleration Autopilot`. This file is the detail
+> home — the full Phase-0 branch logic (including the chamber / simulate-first honesty boundary),
+> provenance, and guard evidence. Read when executing the autopilot on an onboarding or
+> acceleration door.
+
+The **install-direction twin of the Field-Harness Diagnostic**: same `compose → rank → HITL`
+engine, but it decides *what to install/wire* instead of *what to fix*. When the operator enters an
+onboarding / acceleration door (returning-menu ①②③: "새 프로젝트", "하네스 작성/작성해줘",
+"이 프로젝트 가속화", "harness-ify", "accelerate this project"), don't hand-run one skill —
+**auto-discover the local state, let the innovator center a recommend cascade, produce a ranked
+install plan, and gate every install.**
+
+## Flow
+
+1. **Phase 0 — State Audit + branch (auto-discovery)**: read the target's existing
+   `.claude/agents|skills`, `CLAUDE.md`, mapped `tracks/`, **locally-connected sibling repos** (the
+   env-delta SessionStart hook already emits "N unmapped sibling repos"), and the
+   `LOCAL_SKILL_REGISTRY` + stack/language. Then **branch**: *new-build* (no prior harness) ·
+   *extend-existing* (harness present → found→extend, never fork) · *maintain* (mature harness →
+   route to the Field-Harness Diagnostic instead).
+
+   **New-build sub-branch — simulate-first (incubator doctrine)**: judge the project's character
+   before building. Clear · small · low failure-cost → build immediately (current flow). Uncertain ·
+   exploratory · failure-expensive → **flag simulate-first as an option**: doctrine says such a
+   project *should* be chamber-simulated before emit. The chamber **run orchestration is wired**
+   (`scripts/chamber_run.sh` — an intent-driven, resumable 7-step runner: budget-entry cap,
+   ≥3-blind-persona gate, Emission Gate, G4 ledger auto-append; run #3 exercised it 2026-07-14).
+   But a **live one-command autonomous simulate→EMIT of a field harness is NOT yet a capability**:
+   step-4 persona dispatch is human/Claude-driven (bash cannot spawn the isolated Agents — the
+   honest muscle boundary), the EMIT terminus is HITL, and **EMIT has never fired — the ledger's
+   real runs are honest KILLs** (the chamber to date *screens*, it has not *birthed*). So today this
+   branch = a one-line HITL recommendation to run the chamber (`chamber_run.sh`), then fall back to
+   Full-Harness Mode §6 (`auto_project_mapping.md`) for the actual onboarding; the runner gates and
+   records a human-driven run — it must **not** be presented as a push-button autonomous emit. The
+   same branch applies to a **new capability of an existing harness** — the
+   incubate-in-chamber-then-transplant flow is likewise run-orchestrated but not autonomously
+   emitting today. Rationale + economics:
+   `knowledge/shared/harness-core/harness_incubator_doctrine.md §3`.
+
+   This audit-and-branch pre-step is imported from the revfactory/harness Phase-0 State Audit
+   (sister-audit 2026-07-07) — it tightens FH's found→extend reflex and is the "이미 로컬에 연결돼
+   있으면 자동 탐색" mechanism.
+
+2. **Innovator-centered recommend**: `persona-innovator` centers the cascade (Mode I on
+   acceleration / Mode F on FH-dev), composing `plugin-recommender` (Tier 0 platform → Tier 1
+   official → Tier 2/3) + `cross-ecosystem-synergy-detection` (locally-connected skills worth
+   wiring) + inferred technical level (conversation-cue read, also imported from revfactory) to
+   shape *what* and *how much*.
+
+3. **Ranked install plan**: one list, `M`/`S`/`R`, each item = *what · why · source (Tier 0
+   built-in / Tier 1 official / local sibling / FH scaffold) · exact install command*.
+   No-reinvention: an official/built-in that covers the need ranks above a net-new scaffold.
+
+4. **Install — HITL, non-overwriting**: per-item approval; **never clobber an existing `.claude/`**
+   (propose merge/skip if present — this is FH's edge over revfactory's post-plan auto-write and
+   harness-100's raw `cp`). Any generated/installed FH asset runs the **4-axis gate**; a field
+   scaffold runs `asset-placement-gate` + `steel-quench`. **"끝까지 해줘 / 자율로 완주" →
+   full-autonomy**: run the whole plan under the `/goal-quench` budget+quality gate (token cost
+   accepted by the operator), still non-overwriting and still gated per asset — autonomy removes
+   the per-item *prompt*, never the *gate*.
+
+## Guards
+
+- **(a) Non-overwriting is inviolable** — the one thing both revfactory surfaces get wrong; FH
+  proposes merge, never clobbers.
+- **(b) No-reinvention** — Tier 0/1 first, scaffold only what adds governance.
+- **(c) Company residency** — discovery of a company sibling repo surfaces it, does not
+  auto-map/leak it; promoted to a machine field (`residency` on the skill registry,
+  `fh_detail_protocols.md §1-c`) so any derived recommendation naming a `company` /
+  `operator-private` entry lands only in gitignored `tracks/_meta/` or the private companion store,
+  never a tracked public file (chamber run #7, 2026-07-14 — the guard was prose-only and the field
+  didn't exist).
+- **(d) Autonomy floor** — the discover/rank judgment is trusted at opus-tier+; below-floor,
+  present the raw recommend and ask.
+- **(e) Once per door-entry** — not a per-turn nag.
+
+This is the door ③ (accelerate; a *diagnose* intent on the same door routes to the Field-Harness
+Diagnostic instead) engine and the new-project/harness-write path made autonomous —
+the operator asks once and the harness discovers, ranks, and (on request) installs everything worth
+wiring.