@chrono-meta/fh-gate 1.4.54 → 1.4.56

package/.claude-plugin/marketplace.json

@@ -11,13 +11,13 @@
   "plugins": [
     {
       "name": "fh-meta",
-      "version": "1.4.54",
+      "version": "1.4.56",
       "description": "Hub meta-operations toolkit — 33 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.54",
+      "version": "1.4.56",
       "description": "Project-agnostic utility skills — 4 skills (convergence-loop · deliberation · mcp-circuit-breaker · token-budget-gate) + 1 agent (quench-challenger). Domain-independent utilities transplantable into any project.",
       "source": "./plugins/fh-commons"
     }

package/CATALOG.md

@@ -89,7 +89,7 @@ Cloud session (Mode D, ext): new field template — external-MCP tool gating wit
 - Decision: prefer host-native per-tool permission config as enforcement; this template = what-to-gate + portable fallback. §6 install row is conditional (MCP present); the proactive mount-intent trigger is the load-bearing path.
 
 ### 2026-06-11 | forge-harness | #identity-marker, #door-skeleton, #target-tier-sim, #below-floor-consumer, #false-control-kill
-**File:** CLAUDE.md §Active Onboarding (+ fh_detail_protocols.md, scripts/below_floor_scan.sh, .claude/rules/operations.md)
+**File:** CLAUDE.md §Active Onboarding (+ fh_detail_protocols.md, scripts/below_floor_scan.sh, knowledge/shared/rules/operations.md)
 Cloud session (Mode D): 🐿️ marker folded into the returning-user door skeleton — one salience unit with the menu, closing the sonnet-sim marker-drop residual (`fh_signal_2026-06-11`); verified by blind sonnet Agent sim PASS (verification tier = failure tier; in-session model-pinned dispatch available in cloud, no headless fallback needed). 6/15 billing one-line amendment rode the same CLAUDE.md edit (no churn commit). below_floor_scan.sh ships as the standing consumer the pre-commit hook promised ("weekly audit re-queues below-floor markers") but never had — resolution via `floor-rerun:`/`floor-writeoff:` marker appends, wired as weekly Phase 1.5 step 2.
 - Decision: ack rubber-stamp (card item 4) closed via route-around — build the re-run consumer, leave the ack untouched (per opus-challenger verdict on the reverted regex attempt).
 - Decision: opus challenger PASS 0S+3B — marker-append/hook-collision replicated CLEAN; P9 check: "builds the control, not paper-over".
@@ -161,7 +161,7 @@ Backlog cleanup (cloud session 2): goal-quench phantom vocab fixed — "steel-qu
 - Open: npm 1.4.8 republish ships plugin.json/README/SKILL.md count+phantom fixes (folded into the open laptop handoff).
 
 ### 2026-06-10 | forge-harness | #credit-economy, #operator-intake, #lightweight-triage, #frontier-digest
-**File:** plugins/fh-meta/skills/frontier-digest/SKILL.md (+ .claude/rules/sister_asset_protocol.md)
+**File:** plugins/fh-meta/skills/frontier-digest/SKILL.md (+ knowledge/shared/rules/sister_asset_protocol.md)
 Credit-economy engine run #2 formalization (operator-approved; this session = manual run #2: 7 walled sources → 8 audits → 15 same-day gate-passed imports, 2 human corrections): R1 — frontier-digest Step 0.5 operator-intake asks for walled-channel sources (YouTube/LinkedIn/X, machine-403) on cadence runs only, skippable, try wall-bypass (WebSearch + secondary) first. R2 — sister protocol lightweight path: dedup-hit/no-increment sources get a one-paragraph entry, full cross-audits reserved for A/B-tier.
 - Decision: the operator stays the wide-net sensor for walled channels by design (human = scarce oracle), the machine owns endurance (triage→gate cycles); intake cost discipline keeps the wide net wide.
 - Follow-up (same day): Step 0.5 video-harvest ladder — Tier 1 sidecar (codex / Gemini-route, agentic = approval-mode first) → Tier 3 Claude+yt-dlp transcript → operator floor; laptop verification trio handed off. First applied instance of the capability-probe principle.
@@ -187,7 +187,7 @@ CC built-ins utilization imports (operator-approved; video claims verified 9/13
 - Decision: built-in beats plugin install at ~80% coverage; FH native beats built-in only when it adds governance.
 
 ### 2026-06-10 | forge-harness | #ingest-gate, #contradiction-scan, #crossref-lint, #llm-wiki, #karpathy
-**File:** .claude/rules/sync_push_protocols.md (+ harness-doctor SKILL.md, probes.md)
+**File:** knowledge/shared/rules/sync_push_protocols.md (+ harness-doctor SKILL.md, probes.md)
 Karpathy LLM-Wiki sister-audit imports (operator-approved; convergence case n=5, citable primary source): I1 — contradiction scan as Sync step 3 (ingest gate, judged + verify-bidirectional pair): new knowledge grepped against existing claims before indexing, conflicts flagged in both files, old-claim removal is HITL. I2 — harness-doctor L4 knowledge cross-ref lint: no CATALOG entry = S-tier index orphan, no inbound ref = R-tier orphan page. Probes G-SYNC-01/G-LINT-01 added (30 total).
 - Decision: scale escape (W1) deliberately NOT built — watch-item with trigger (CATALOG hundreds of entries / repeated search misses); operator-preferred first remedy = salience-splitter-style CATALOG split-mapping, RAG hybrid only after that.
 - Open: npm republish (harness-doctor SKILL.md shipped) — folded into the open 1.4.8 handoff.
@@ -283,7 +283,7 @@ PR #64: Added scope-driven sidecar routing (Step D) to goal-quench Phase 1.5: ta
 - Decision: overhead multiplier documented as empirical calibration constant; sidecar routing is scope-signal-driven, not mode-locked
 
 ### 2026-06-03 | forge-harness | #goal-quench, #non-coercive, #companion-store, #ephemeral-handoff
-**File:** .claude/rules/modes_and_value.md
+**File:** knowledge/shared/rules/modes_and_value.md
 Formalized two non-coercive guidances: companion-store recommendation conditioned on accumulating context into meta-harness without a local fork; ephemeral-environment handoff rule made mode-agnostic (Mode D → companion-store handoff/, all others → committed note or PR comment in working repo).
 - Decision: single-source preserved — rule lives in public mirror; companion store holds only outputs, never a rule copy
 

package/CLAUDE.md

@@ -34,7 +34,7 @@ core invariants never melt). Full doctrine: `knowledge/shared/harness-core/harne
 
 | Layer | Role | Representative Assets |
 |---|---|---|
-| **① Control Tower** | Coordinates all connected projects and **drives harness-ification across them** — decides *which* projects to harness and *when*, propagates harness assets to each, and feeds their synced learnings into the hub's compounding loop. The *how* (rules · gates · 6-axis) is executed via the Core Axis. Command HQ, not a passive registry. | `.claude/rules/auto_project_mapping.md` (mapping + **Full-Harness Mode**) · `harvest-loop` (compounding loop) · `templates/` (project-harness bundle) · `CATALOG.md` |
+| **① Control Tower** | Coordinates all connected projects and **drives harness-ification across them** — decides *which* projects to harness and *when*, propagates harness assets to each, and feeds their synced learnings into the hub's compounding loop. The *how* (rules · gates · 6-axis) is executed via the Core Axis. Command HQ, not a passive registry. | `knowledge/shared/rules/auto_project_mapping.md` (mapping + **Full-Harness Mode**) · `harvest-loop` (compounding loop) · `templates/` (project-harness bundle) · `CATALOG.md` |
 | **② Frontier → Org Propagation** | Proactively applies global AI/harness frontier thinking and **translates it for your organization**. | `knowledge/shared/harness-core/harness_frontier_diagnosis_*.md` · `knowledge/{your-org}/` |
 | **③ AI Collaboration Guide** | Accumulates and distributes best practices for token efficiency and dialogue methodology — "how to ask, delegate, and record". | `CHEATSHEET.md` · `knowledge/shared/dialogue/ai_dialogue_playbook.md` · `MEMORY.md` intent-based + associative recall (`knowledge/shared/dialogue/memory_intent_recall.md`) |
 | **Core Axis** | **Harness Engineering (How)** — the methodology and practice axis that realizes the three layers above. The 6-axis framework is the operating unit. **A harness is a means, not an end** — Field harness: "simpler over time" (complexity = warning signal). Meta-harness: *optimize*, not necessarily simplify — complexity earns its scope; red flags are orphaned, redundant, and decorative units, not complexity itself. | `harness_6axis_framework.md` · `hub_compounding_loop.md` · `claude_code_runtime_flow.md` · `.claude/agents/` (sub-agents) |
@@ -84,7 +84,7 @@ leaked into the judgment layer and the response is wrong, not warm.
 
 ## New Project Onboarding
 
-> Detailed procedure: `.claude/rules/auto_project_mapping.md` (5-step mapping + §6 Full-Harness Mode)
+> Detailed procedure: `knowledge/shared/rules/auto_project_mapping.md` (5-step mapping + §6 Full-Harness Mode)
 
 1. `mkdir tracks/{project_name}/` — track name = project root name
 2. Hub common principles outrank project rules (scope hierarchy)
@@ -146,7 +146,7 @@ Simplification guard: trivial denials with one obvious fix → state block + sin
 
 **4-step summary**: ① Auto-read CLAUDE.md + CATALOG + session card + registry scan + UAP (`tracks/_meta/user_adaptation_profile.md`, if present — apply user-tuned defaults: preferred tier, suppressed proposals, muted nags; see §Operational Adaptation Loop) **+ Mode D companion-store load — if a companion store is configured (your `CLAUDE.local.md` binding), pull it and read its index (its TOC) before its other files, then check freshness against the card (`modes_and_value.md §Session-start freshness`); this load is part of the auto-read, not a step the operator should have to request** → ② One-line proposal (new user / exploratory / returning branches) → ③ 5-skill cascade (plugin-recommender → synergy → .claudeignore → model → verify) → ④ Approval + setup
 
-**Greeting branch + door skeleton (summary-level — applies even if the detail file read is skipped)**: the branch test is **mechanical local state — session files under `tracks/`** — never git log / CATALOG residue (a fresh clone carries full history but zero session files: it is a NEW install — origin: a fresh-clone sonnet sim rendered the returning menu off commit messages, `fh_signal_2026-06-11` FP8). Every variant opens with **🐿️ then an identity-revealing welcome line on the SAME line** (🐿️ is no longer alone on its own line), followed by the menu — one salience unit, not a separate rule. (Put a space after 🐿️; the exact count is **not significant** — a markdown renderer collapses multiple mid-line spaces to one — so the verifiable invariant is *same-line*, NOT a space count.) Welcome line by branch: new / exploratory = "Welcome to FH." · returning = "Welcome back to FH." · operator (FH-dev state) = "The FH operator — good to see you." (rendered in the user's language; the lid/onboarding-smoothness matters even though it is not the substance).
+**Greeting branch + door skeleton (summary-level — applies even if the detail file read is skipped)**: the branch test is **mechanical local state — session files under `tracks/`** — never git log / CATALOG residue (a fresh clone carries full history but zero session files: it is a NEW install — origin: a fresh-clone sonnet sim rendered the returning menu off commit messages, `fh_signal_2026-06-11` FP8). Every variant opens with **🐿️ then an identity-revealing welcome line on the SAME line** (🐿️ is no longer alone on its own line), followed by the menu — one salience unit, not a separate rule. (Put a space after 🐿️; the exact count is **not significant** — a markdown renderer collapses multiple mid-line spaces to one — so the verifiable invariant is *same-line*, NOT a space count.) Welcome line by branch: new / exploratory = "Welcome to FH." · returning = "Welcome back to FH." · operator (FH-dev state) = "The FH operator — good to see you." (rendered in the user's language **as a plain, natural translation of the pinned phrase — not an invented coinage** (cf. the operator-caught `안 조종실…` mistranslation); the lid/onboarding-smoothness matters even though it is not the substance).
 
 - **New user** (no session files AND no mapped project tracks under `tracks/` — fresh clone/install; underscore meta dirs `_meta`/`_audit`/`_contrib` don't count): 2-door starter, never the returning menu —
 
@@ -197,7 +197,7 @@ that skill class, and not a retroactive sweep of all routers.
 
 ## FH Improvement 4-Axis Auto-Gate (Self-Verification Orchestrator)
 
-**Whenever the AI modifies FH assets** (SKILL.md · `.claude/rules/*.md` · `templates/` · `CLAUDE.md` · substantive `knowledge/` docs · substantive `docs/*.md` · `AGENTS.md` — see Substantive carve-out below),
+**Whenever the AI modifies FH assets** (SKILL.md · `.claude/rules/*.md` · `knowledge/shared/rules/*.md` (relocated protocol rules — always full-gate, NOT under the knowledge carve-out) · `templates/` · `CLAUDE.md` · substantive `knowledge/` docs · substantive `docs/*.md` · `AGENTS.md` — see Substantive carve-out below),
 the 4-axis verification chain runs **automatically before the first commit** of that session.
 No user request is needed — this is a mandatory autonomous step, not a proposal.
 
@@ -668,6 +668,7 @@ At session start, determine the last run time from history files and auto-propos
 |---|---|---|
 | `/frontier-digest` | `tracks/_meta/frontier_digest_*.md` | Propose at session start if 7+ days since last run |
 | `/harness-doctor` | `tracks/_meta/*harness_doctor*.md` | Propose at session start if 30+ days since last run |
+| Weekly audit (`/harvest-loop` lightweight) | `tracks/_audit/weekly_audit_*.md` | Propose at session start if 7+ days since last run (incl. `below_floor_scan.sh` step — detail: `knowledge/shared/rules/operations.md`) |
 
 > A cadence reminder the user has repeatedly declined is **muted** per the UAP (see the loop below) — don't re-nag.
 
@@ -684,7 +685,7 @@ Some proposals are not *time*-overdue — they fire **once when a specific work
 
 ## Operational Adaptation Loop — User-Tuned Self-Optimization
 
-> Detail: `.claude/rules/operational_adaptation.md`
+> Detail: `knowledge/shared/rules/operational_adaptation.md`
 
 Self-healing is not only FH-self-dev (Mode D 4-axis) and reactive (`verify-bidirectional`). A **standing, per-user operational loop** tunes FH behavior to the individual during normal field use, and escalates **only generalizable** learnings to the `field-harvest` → FH-origin PR funnel — idiosyncratic taste stays local (drift guard).
 
@@ -711,6 +712,11 @@ Default operation is a **standard interactive session**. Agent dispatch (single
 
 Mapped paths: check `auto_project_mapping.md` or `find ~/projects -maxdepth 1 -type d` for actuals.
 
+**Invocation log obligation (always-loaded — do not rely on recall)**: immediately after any custom
+sub-agent invocation, append to `knowledge/shared/learnings/subagent_invocations_log.yaml` (8 fields ·
+outcome: `accepted`/`partial`/`rejected`/`sustained` — `sustained` = decided NOT to invoke, also recorded).
+This feeds the 60/40 promotion gate + UAP loop; detail: `knowledge/shared/rules/operations.md`.
+
 ### Context Card — Required Format for Dispatch
 ```
 [Session Context Card]
@@ -751,11 +757,11 @@ Tiers: S=light(~5K) · M=standard(~15K, FH default) · L=full(~30K) · XL=max(~6
 
 **Current: Beta → External Validation Achieved** — v1.0 formal release conditions: additional external install evidence + at least 1 external PR.
 
-> Usage modes (A/B/C) + what-you-get (Layer 1/2) details: `.claude/rules/modes_and_value.md`
+> Usage modes (A/B/C) + what-you-get (Layer 1/2) + **ephemeral-session handoff rule** (leave a surfaced handoff in a durable location before an ephemeral/cloud session ends): `knowledge/shared/rules/modes_and_value.md`
 
 ## Auto Project Mapping Protocol
 
-> Detailed procedure: `.claude/rules/auto_project_mapping.md` (5-step mapping + §6 Full-Harness Mode)
+> Detailed procedure: `knowledge/shared/rules/auto_project_mapping.md` (5-step mapping + §6 Full-Harness Mode)
 
 When the user requests **"connect a project"** · **"link to hub"** · **"map this project"** · **"scan parent directory and connect"**, follow the `auto_project_mapping.md` protocol. When they request **"harness-ify this project"** · **"full harness setup"** · **"프로젝트 하네스화"** (or accept the post-mapping promotion prompt), run **§6 Full-Harness Mode** — installs project-local harness assets (session rules · context filter · env card) from `templates/`, approval-gated and non-overwriting. (The FH self-gate is FH-internal and is not installed into projects.)
 
@@ -829,17 +835,17 @@ Card update is NOT a sub-step of harvest-loop — even if harvest-loop is skippe
 
 ## Session Sync / Knowledge Push Protocol
 
-> Detailed procedure: `.claude/rules/sync_push_protocols.md`
+> Detailed procedure: `knowledge/shared/rules/sync_push_protocols.md`
 
 When the user requests "sync", "save session", etc., follow the `sync_push_protocols.md` protocol. CATALOG.md format, tag conventions, and track mapping are also referenced in that file.
 
 ## Sister Asset Protocol
 
-> Detailed procedure (3 steps · restrictions · branch sync): `.claude/rules/sister_asset_protocol.md`
+> Detailed procedure (3 steps · restrictions · branch sync): `knowledge/shared/rules/sister_asset_protocol.md`
 
 When a sibling asset on the same topic is discovered (internal team or external frontier), follow `sister_asset_protocol.md`. Keep the detection threshold low — the goal is to close awareness gaps.
 
 ## Operations Reference
 
-> CATALOG.md format · tag conventions: `.claude/rules/sync_push_protocols.md`
-> Sub-agent operations · weekly improvement cycle · maturity 3-phase roadmap: `.claude/rules/operations.md`
+> CATALOG.md format · tag conventions: `knowledge/shared/rules/sync_push_protocols.md`
+> Sub-agent operations · weekly improvement cycle · maturity 3-phase roadmap: `knowledge/shared/rules/operations.md`

package/knowledge/shared/dialogue/ai_dialogue_playbook.md

@@ -137,5 +137,5 @@ Skill: `/verify-bidirectional`
 
 - `claude_code_runtime_flow.md` — What actually happens (the "does" layer)
 - `harness_6axis_framework.md` — The 6-axis framework (Axes 2 and 3 govern context/plan)
-- `.claude/rules/sync_push_protocols.md` — Recording procedure
+- `knowledge/shared/rules/sync_push_protocols.md` — Recording procedure
 - `CHEATSHEET.md` — Command reference

package/knowledge/shared/dialogue/claude_code_runtime_flow.md

@@ -167,4 +167,4 @@ Throughout the session, when conversation signals match the table in CLAUDE.md:
 - `ai_dialogue_playbook.md` — The "should" layer (principles)
 - `harness_6axis_framework.md` — Full 6-axis decision tree
 - `hub_compounding_loop.md` — Session close → harvest-loop → weekly cycle
-- `.claude/rules/operations.md` — Sub-agent invocation log format + weekly scanner
+- `knowledge/shared/rules/operations.md` — Sub-agent invocation log format + weekly scanner

package/knowledge/shared/dialogue/memory_intent_recall.md

@@ -206,4 +206,4 @@ constellations + the convergent/divergent split — all at prose scale, no new s
 - `crucible_mode.md` — this doc was itself forged crucible-style (operator seed → literature melt → grounded rebirth)
 - `memory-hygiene` (skill) — staleness pass; link-evolution (A-MEM) and the §D.8 store-side injection filter live here
 - `plugins/fh-meta/agents/persona-innovator` (the fh-meta agent) — the divergent-mode consumer this substrate unlocks
-- `.claude/rules/operational_adaptation.md` — the UAP is itself intent-recalled; shared tier-dependence rationale
+- `knowledge/shared/rules/operational_adaptation.md` — the UAP is itself intent-recalled; shared tier-dependence rationale

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

@@ -109,4 +109,4 @@ increment; the chained skills are all ALREADY-HAVE.
 - `harness_6axis_framework.md` — Axis 5 (the heat) + Axis 6 (the rebirth); Core principle (the core)
 - `harness_design_decision_lens.md` — harness-thickness bet (how thick the unmeltable core should be)
 - `feedback_frontier_expectation_anchoring` (memory) — the anti-bubble anchoring the core enforces
-- `.claude/rules/operational_adaptation.md` — reforge-by-operator channel (verify-bidirectional)
+- `knowledge/shared/rules/operational_adaptation.md` — reforge-by-operator channel (verify-bidirectional)

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

@@ -111,7 +111,7 @@ row + the operator's proactive framing, not by the grep alone.
 
 **Residency** — sanitize company code (redact vendor/domain literals) before any external-family
 dispatch; domain data never leaves. **Autonomy** — autonomous once the operator has consented in
-the UAP (`tracks/_meta/user_adaptation_profile.md`, defined in `.claude/rules/operational_adaptation.md`),
+the UAP (`tracks/_meta/user_adaptation_profile.md`, defined in `knowledge/shared/rules/operational_adaptation.md`),
 same as the FH cross-family complement.
 
 ## 5. Field evidence — qasp verdict-binding sweep, 2026-07-03 (n=7)

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

@@ -128,7 +128,7 @@ Lower levels cannot override higher. AI contribution → PR proposal only (no di
 - `hub_compounding_loop.md` — Axis 6 automation (weekly/monthly/quarterly cycles)
 - `ai_dialogue_playbook.md` — Axis 2 dialogue principles (how to ask, delegate, record)
 - `claude_code_runtime_flow.md` — Axis 4 runtime behavior (chronological session flow)
-- `.claude/rules/operations.md` — Sub-agent operations, weekly cycle detail
+- `knowledge/shared/rules/operations.md` — Sub-agent operations, weekly cycle detail
 
 **External sibling (independent convergence)**
 

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

@@ -105,4 +105,4 @@ it informs — no judge-only path.
 ## Related
 - `harness_6axis_framework.md` — the lifecycle framework this lens complements (Core principle: thickness; Axis 5: check-class taxonomy)
 - `tracks/_audit/session_2026_06_14_wikidocs-deep-sweep.md` — the governor-closed cross-audit this harvest came from
-- `.claude/rules/auto_project_mapping.md` — Full-Harness Mode, where thickness/permission bets are placed per project
+- `knowledge/shared/rules/auto_project_mapping.md` — Full-Harness Mode, where thickness/permission bets are placed per project

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

@@ -105,5 +105,5 @@ Fields: friction point, FH registration candidate, status (pending hub review).
 ## Related
 
 - `harness_6axis_framework.md` — Axis 6 is the "Improve" step that feeds into this loop
-- `.claude/rules/operations.md` — Sub-agent invocation log, weekly audit scanner detail
-- `.claude/rules/sync_push_protocols.md` — Session Sync Protocol (how learnings enter the loop)
+- `knowledge/shared/rules/operations.md` — Sub-agent invocation log, weekly audit scanner detail
+- `knowledge/shared/rules/sync_push_protocols.md` — Session Sync Protocol (how learnings enter the loop)

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

@@ -118,7 +118,7 @@ harness probes the live environment on-the-fly via the Tier 1→2→3 protocol a
 path. All probes failing → safe descent to Tier 3 (main model handles it).
 
 **5.3 Zero-Config standalone self-reliance** — the key requirement for **Mode C** (plugin/skill
-copied without the full framework, see `.claude/rules/modes_and_value.md`). With no
+copied without the full framework, see `knowledge/shared/rules/modes_and_value.md`). With no
 `config.json`, the module must **not error** — it switches to Zero-Config standalone mode and
 JIT-probes for whatever local tools exist, then proceeds quietly. Falls back to Tier 3 if none.
 
@@ -191,6 +191,6 @@ component tagged ❌ Proposed above so this roadmap can never be mistaken for cu
 
 - `knowledge/shared/harness-core/multi_model_sidecar_strategy.md` — shipped sidecar mechanism + fallback chain (this roadmap extends, does not replace, it)
 - `plugins/fh-meta/skills/install-wizard/SKILL.md` — current install behavior (the topology extension would build on this)
-- `.claude/rules/modes_and_value.md` — Mode C (plugin/skill-only) that Zero-Config self-reliance targets
-- `.claude/rules/operations.md` — sub-agent boundary rules the built-in-injection item must respect
+- `knowledge/shared/rules/modes_and_value.md` — Mode C (plugin/skill-only) that Zero-Config self-reliance targets
+- `knowledge/shared/rules/operations.md` — sub-agent boundary rules the built-in-injection item must respect
 - `plugins/fh-meta/skills/frontier-digest/SKILL.md` — live source for current model capability/benchmark comparison (do not freeze numbers here)

package/knowledge/shared/rules/auto_project_mapping.md

@@ -0,0 +1,134 @@
+---
+description: When the user requests "connect a project" or similar, automatically scans parent directories for candidates and handles the 5-step mapping flow (discovery, filtering, confirmation, mapping, summary). Also covers §6 opt-in Full-Harness Mode ("harness-ify this project") — installs project-local harness assets from templates/.
+---
+
+# Auto Project Mapping Protocol
+
+When the user requests **"connect a project"** · **"link hub"** · **"map project here"** · **"scan parent directory and connect"** or similar, follow this protocol instead of manual copy (cp).
+
+## 1. Scan
+
+| Scenario | Search path | Condition |
+|---|---|---|
+| **A. Default inference** | Parent (`../`) of hub cwd | Default when user specifies no path |
+| **B. User specified** | Path explicitly stated by user | Preferred when path keyword detected |
+| **C. Multiple roots** | Both A + B as candidates | When user uses both |
+| **D. 0 candidates** | — | Ask user: **"Please provide the project root path"** |
+
+## 2. Candidate filtering
+
+Only directories meeting all of the following conditions qualify as candidates:
+
+- `.git/` exists (real projects only, no empty directories)
+- Exclude the hub itself and sibling hub cwds
+- Exclude track names already mapped in `tracks/` (prevent duplicates)
+
+## 3. Mapping confirmation
+
+| Candidate count | Action |
+|---|---|
+| **0** | Scenario D — ask user |
+| **1** | Confirm: `"Map {name} project to tracks/{name}/?"` |
+| **Multiple** | Show numbered list, accept multi-select (e.g., "map 1,3 only") |
+
+## 4. Mapping execution (for each selected project)
+
+1. Create `tracks/{project}/learnings/` directory (with `.gitkeep`)
+2. **If project root has no CLAUDE.md:**
+   - Copy `templates/CLAUDE.md` → `{project_root}/CLAUDE.md`
+   - Replace `{project_name}` placeholder with actual track name
+3. **If project root already has CLAUDE.md:**
+   - **Do not modify existing content**
+   - **Propose adding** the following hub reference block at the top (insert after user confirmation):
+
+   ```markdown
+   ## Knowledge Hub (forge-harness)
+
+   Persistent knowledge for this project is stored in `~/projects/forge-harness/`.
+
+   - **Search past work**: `~/projects/forge-harness/CATALOG.md`
+   - **Learnings/feedback source**: `~/projects/forge-harness/tracks/{project}/learnings/`
+   - **At session end**: `sync_push_protocols.md` (Session Sync Protocol)
+   ```
+4. Auto-add a row for the project in the **track mapping table** in CLAUDE.md
+5. Summarize git status changes (user decides whether to commit)
+
+## 5. Summary report (required)
+
+```
+Mapping complete: N projects
+- {proj-a}: tracks/proj_a/ created, CLAUDE.md newly written
+- {proj-b}: tracks/proj_b/ created, hub block added to top of existing CLAUDE.md
+- {proj-c}: tracks/proj_c/ created, CLAUDE.md unchanged (user declined block addition)
+```
+
+## 6. Full-Harness Mode (opt-in) — harness-ify the mapped project
+
+Basic mapping (steps 1–5) registers a project *lightly* (tracks/ + a starter CLAUDE.md + hub link). **Full-Harness Mode adds the project-local harness assets** — identity ① (Control Tower) propagating harness structure to a connected project; the *how* is executed via the Core Axis.
+
+**Scope**: target *mapped* projects only. For FH-self setup / acceleration baseline (zshrc, sentinels, the FH self-gate) use `/install-wizard` — do **not** run §6 on the FH hub itself. **Prerequisite**: the project is already mapped (steps 1–5); §6 is strictly additive.
+
+**Triggers**: "harness-ify this project", "full harness setup", "프로젝트 하네스화", "promote to full harness", or an opt-in prompt offered right after a basic mapping (*"Promote {project} to a full harness now?"*).
+
+**Harness litmus (pre-check — component lens, complements the 6-axis process lens)**: before promoting,
+sanity-check the candidate actually *operates as (or will operate as) a runtime harness*, not a static
+codebase. A runtime harness has four conditions (sister-asset, sanguinekim 2026 — cross-audit
+`tracks/_audit/session_2026_06_22_sanguinekim-harness-definition.md`):
+
+| # | Condition | Litmus question |
+|---|---|---|
+| 1 | **Loop** (infer→act→observe) | Does it iterate, or emit one response and stop? |
+| 2 | **Tool interface** | Can it *modify* the environment, not just read? |
+| 3 | **Context management** | Does it *select* what to feed back, not just truncate at overflow? |
+| 4 | **Control** (verify + guardrails) | Are there checks that hold *independent of model cooperation*? |
+
+This is a *should-we-even-harness-ify* gate, not an install: 0–1 conditions met → the project isn't yet
+an agentic harness, so full-harness assets are premature (note it, offer light mapping only). 2+ met (or
+clearly intended) → proceed. The component lens is orthogonal to FH's 6-axis (process); FH adds the
+governance depth to condition 4 (mechanical-anchor / 4-axis gate) — the litmus just confirms the *shape*.
+
+**Installs (each item approval-gated · never overwrite — propose skip/merge if it exists · all from `templates/`):**
+
+| # | Item | Source → target | Effect |
+|---|---|---|---|
+| 1 | Session rules | `templates/.claude/rules/session.md` → `{project}/.claude/rules/session.md` | Session-start auto-read, backup, rule hierarchy |
+| 2 | Context filter | `templates/.claudeignore` → `{project}/.claudeignore` | Token footprint control |
+| 3 | Env card | `templates/fh_env_context.jsonc` → `{project}/.claude/rules/fh_env_context.jsonc` | Environment context for sessions |
+| 4 | **MCP tool gating** (conditional — offered only when the project mounts an external MCP server: `.mcp.json`/`mcp.json` present, or the user is adding one) | `templates/.claude/rules/mcp_tool_gating.md` → `{project}/.claude/rules/mcp_tool_gating.md` | Name-keyed ask/allow tiers for external MCP tools — server annotations are unreliable (measured 2026-06-11: a live server shipped all-None hints incl. its irreversible send tool); §3 table filled at mount time |
+| 5 | **Official-plugin scan** (recommend list only — **never auto-install**) | plugin-recommender Tier 0/1 pass on the project's stack | No-reinvention acceleration: matching `*-lsp` for the project's language + workflow plugins (code-review · commit-commands · feature-dev …) from `claude-plugins-official` — see `knowledge/shared/plugin-catalog/recommended_plugins.md` §Category 0.5. Each install user-approved |
+
+**Field-asset scaffold (on-demand — NOT a `templates/` install)**: harness-ification surfaces field-specific skills/agents *as needed* — the field's domain work produces them. FH accelerates their *creation*: not the domain content (the field team authors that), but the **gate-compliant structure**. When a skill-worthy recurring pattern appears (3+ reps → `#skill-candidate` tag · `field-harvest` signal · a repeated manual workflow), offer to scaffold a skeleton:
+
+- **Skill skeleton** — the frontmatter field set (`name`/`description`/`user-invocable`/`allowed-tools`) that is universal across active FH skills (regen: `grep -L user-invocable plugins/*/skills/*/SKILL.md` returns none; `model:` is deliberately NOT universal since 2026-07-10 — hard pins retired per `sonnet_floor_doctrine.md`, skills session-inherit and express depth as dispatch) + **four stubs, all mandatory in the skeleton**: ① Trigger stub (≥3 phrases — initiate) ② Done-When stub (with check-class — complete) ③ halt stub (budget/convergence guard) ④ persist stub (what state reaches the next run) + Step skeleton — the 5-question loop discipline by construction (`loop_engineering.md`; validate=#3 is the check-class declaration in ②). **Parameterizes** `contention-layer` Step 4's skeleton template (per its need-driven note — `origin: field-scaffold`, `contention-parents`→source-pattern pointer).
+- **Agent skeleton** — `{project}/.claude/agents/{name}.md` with `name`/`description`/`tools` + a **self-contained** prompt stub (sub-agents don't see main context).
+- **Route** via `asset-placement-gate` (its verdicts: `{project} local agent` / `FH meta-skill` / `Drop` — no commons path for an agent) · **harden** via `steel-quench` · the field team fills the **domain content** (FH never authors domain logic).
+
+The scaffold **enforces the creation gate by construction** — a field skill is gate-compliant (description diet · ≥3 triggers · Done-When · check-class · independently-executable) *from the skeleton*, even if the field author doesn't know the gate. That is the governance value: the quality bar travels to the field. **Approval-gated like items 1–5** (offer, never auto-create). **Done When** (FH's own scope; the boundary the §New-Skill-Creation gate requires): (1) skeleton emitted with all gate fields *[mandatory-pass]* · (2) `asset-placement-gate` verdict recorded *[mandatory-pass]* · (3) `steel-quench` run, no S-tier *[measured]*. **FH scope ends here** — domain-content fill is the field team's, outside this Done When. **No-reinvention**: net-new is only the *need-driven entry + agent variant* — detection (`#skill-candidate`/`field-harvest`/`contention-layer`), routing (`asset-placement-gate`), hardening (`steel-quench`), and the skill-skeleton (`contention-layer` Step 4) already exist; Claude Code's built-in agent authoring does the mechanical file write, FH adds the governance scaffold.
+
+**Plugin-bundle rung (deferred — measured-trigger, not built today)**: bundling skills+agents into a distributable plugin (`.claude-plugin/plugin.json` + `marketplace.json`) recurs far less than skill creation (a harness has many more skills than plugins), so its scaffold is added when the *bundling* friction is measured, reusing `marketplace-gate` (readiness) + the `package.json`↔plugin.json lockstep (CLAUDE.md §④-b). Not built speculatively.
+
+**Not installed (deliberately)**: the FH 4-axis **pre-commit gate** (`templates/.git-hooks/`) is FH-*internal* infra — it hard-codes hub paths and requires hub markers (`tracks/_meta/.axes_23_passed_*`, `tracks/_meta/edit_manifest.yaml`), so dropping it into a target project would **block that project's commits**, not help. A project-generic regression gate is a future candidate, not shipped today.
+
+**Loop linkage (honest — no autonomous daemon)**: `tracks/{project}/` (created in step 1, basic mapping) is what makes the project's **session-synced** learnings visible to the hub's `harvest-loop` weekly audit — *once the user runs the Session Sync Protocol from that project*. §6 adds project-local harness assets; it does **not** add loop automation inside the project, and the session-start cadence (frontier-digest 7d / harness-doctor 30d) runs in the **hub cwd**, not the project. "Acceleration" = the hub's compounding loop ingests the project on sync — not a process running in the project.
+
+**Report (required)**: list each item as `installed` / `skipped (exists)` / `declined`, then state: *"{project}: mapped (light) → project-local harness installed; learnings feed the hub loop on sync."*
+
+**Guards**: respects all Boundaries below (no overwrite, confirm-first). If the project already has its own `.claude/rules/`, propose side-by-side/merge — never clobber. Hub common principles outrank project rules (scope hierarchy); project-specific rules are preserved.
+
+## Boundaries and caution
+
+- **Do not execute without confirmation** — present candidate list → user selects → execute mapping (3 steps)
+- **Do not overwrite existing project files** — if CLAUDE.md exists, propose block addition only
+- **Warn when large monorepo detected** — repos with 10+ subprojects: ask "Which subproject is the track unit?"
+- **Name collision** — if track name already exists, ask user to specify a new track name
+- **Pre-existing `.claude/` config is untrusted input, not a mapping detail** — a candidate project
+  (step 1 scan) may already carry a `.claude/settings.json` from a source FH did not author (a clone,
+  a fork, a prior contributor). Two disclosed Claude Code CVEs show that file class is a live RCE /
+  exfiltration surface *before* Claude Code's own trust dialog ever appears: `hooks` entries executing
+  shell commands pre-trust-prompt (CVE-2025-59536, CVSS 8.7) and an `ANTHROPIC_BASE_URL` override
+  silently redirecting API traffic pre-trust-prompt (CVE-2026-21852) — both patched upstream, but a
+  stale unpatched Claude Code build or an unreviewed pre-existing settings file reintroduces the same
+  exposure. Read any existing `.claude/settings.json` (`hooks`, env-var overrides) in the candidate
+  directory **before** running a mapping session inside it — do not rely on the trust dialog alone.
+  (Signal: [Check Point Research — CVE-2025-59536 / CVE-2026-21852](https://research.checkpoint.com/2026/rce-and-api-token-exfiltration-through-claude-code-project-files-cve-2025-59536/), surfaced via
+  the frontier-digest signal 2026-07-04 (issue #102) · cross-referenced via [obot.ai](https://obot.ai/blog/claude-code-mcp-governance-enterprise-security/) and [CyberDesserts](https://blog.cyberdesserts.com/ai-agent-security-risks/).)

package/knowledge/shared/rules/modes_and_value.md

@@ -0,0 +1,162 @@
+---
+description: Defines the 4 harness usage modes (A canonical / B resident / C plugin-only / D developer) and the differentiated value automatically received on install (Layer 1 rules + Layer 2 skills).
+---
+
+# Harness Usage Modes + Differentiated Value
+
+## Usage Modes — "Don't block those who come, don't block those who leave"
+
+The forge-harness maintains **a reference asset identity** — user entry and exit are free. The AI guides and supports any mode without refusal.
+
+### 4 Mode branches
+
+| Mode | Essence | AI guidance and support obligation | Contribution path |
+|---|---|---|---|
+| **A — Canonical** | Harness cwd setup → hand off to separate project cwd → field agent works | Active onboarding 5-skill cascade + cwd handoff guidance | Direct (bidirectional sync circuit active) |
+| **B — Resident** | Create a **separate project directory** in the harness install environment and work there | Required to guide "separate project directory + proper `.gitignore`" | Indirect (harness itself maintains reference asset identity) |
+| **C — Plugin/skill only** | Install only plugin/skill without cloning harness | Guide user to accumulate history on their own project side. Explicitly state no automatic harness signals expected | Indirect + dependent on user active invocation |
+| **D — Developer/Researcher** | **Using FH while also developing/researching FH itself.** Public mirror (forge-harness) holds methodology; a private companion store (the `*-be` companion pattern) holds paper drafts, experiment logs, raw signals, and a mirror of gitignored local session data. | Guide companion-store setup (the `*-be` companion pattern). Mandatory: `.gitignore` keeps drafts local; `handoff/` enables cloud→local session continuity; a sync hook (e.g. a CC Stop hook) auto-mirrors gitignored local session data → the companion store. | Direct + private (gitignored local files auto-synced to companion store via Stop hook; explicit push for paper-drafts/signals) |
+
+### AI guidance principles
+
+- If user explicitly states a mode, immediately guide that mode. Do not force canonical mode (Mode A).
+- Mode B: **Mandatory check of separate project directory creation + `.gitignore` harness asset isolation**
+- Mode C: Guide history accumulation mechanism on user's project side. Harness side actively absorbs via issue monitoring and PR audit cadence.
+- Mode D: **Mandatory companion-store setup guidance** (backend pluggable — `*-be` repo · Obsidian vault · gbrain LLM-wiki; see *Pluggable backends* below). Public mirror = methodology only. Private store layout: `paper-drafts/` · `paper-signals/` · `digests/` · `handoff/` · `tracks-meta/`. `handoff/` files bridge cloud session → local session. `tracks-meta/` receives gitignored local session data via a sync hook (e.g. a CC Stop hook) so sync is automatic after setup. Field projects can use the same dual-repo pattern.
+- In any mode: do not accumulate user personal work in the harness directory itself (protect reference asset identity)
+
+### Scope boundary — delivery surface is routed, not built
+
+A self-improving agent's **delivery surface** (always-on messaging reach — Telegram / Slack / Discord
+as a daily-driver channel, a standalone gateway process) is a *channel*, not methodology. FH is Claude
+Code native and **deliberately does not build a messaging gateway or a self-running daemon**: messaging
+reach is routed via a messaging MCP (`recommended_plugins.md`), and recurring automation stays a
+**proposal/cadence surface, not a daemon** (`self_evolution_routine.md` §8). This is a chosen boundary,
+not a missing feature — FH's differentiator is *governed* self-evolution (the 4-axis gate), and a
+delivery channel adds reach without adding governance. **The positive half of the boundary
+(operator doctrine, 2026-07-10): development's birthplace is code and the terminal — FH builds no UI
+*because* it is terminal-native, and in exchange every non-UI axis (gates, loops, tier-floor
+reliability, token/speed efficiency, cross-harness routing) must be strong. That strength is the
+condition that lets a UI-less meta-harness embrace other harnesses and orchestrate them at
+optimized token cost and speed — the boundary is an identity, funded by excellence everywhere else.** (Recorded 2026-06-27 from the Hermes Agent
+sister-asset cross-audit, `tracks/_contrib/session_2026_06_27_hermes-agent-nous-self-improving-cross-audit.md`.)
+
+---
+
+## Companion-Store Recommendation + Ephemeral-Environment Handoff
+
+> Two related, **non-coercive** guidances. FH is public and forces nothing — a user with no companion store and no ephemeral runs is never prompted by either.
+
+### When to recommend a companion store (conditional — never forced)
+
+Recommend the private companion store (the `*-be` companion pattern) **only when both** hold:
+- the user is **accumulating their own context/synergy into the meta-harness** — preparing a contribution, or building personal synergy on top of FH — **and**
+- they keep **no separate local fork / project directory** for it.
+
+In that state the accumulation would otherwise be **lost on an ephemeral reclaim** or **pollute the public reference asset** (drift). A private companion store gives the drafts / signals / handoffs a durable, separate home, keeping the public mirror methodology-only.
+
+**Not prompted**: users with a local fork or separate project dir; Mode A/B/C users who do not accumulate personal context into FH. The companion store is a suggestion surfaced to those who would benefit — not a requirement, and not implied by any other rule.
+
+### Pluggable backends — the store's role is backend-agnostic
+
+The companion store is a **role** (durable private home for drafts · signals · handoffs · gitignored-session mirror), not a fixed technology. Do **not** force a new `*-be` git repo on a user who already runs a durable knowledge store. At setup, offer the backend that fits their existing workflow:
+
+**FH emits the same artifact for every backend — markdown output files.** The backend differs only in how it *consumes* them, so no per-backend writer needs building:
+
+| Backend | When | Consumption (FH just writes markdown to a target path) |
+|---|---|---|
+| **`*-be` git repo** (default) | Operator wants git-versioned state + Stop-hook auto-mirror | markdown committed to the private repo |
+| **Obsidian vault** | User already gardens knowledge in Obsidian | point the output path at the vault — Obsidian *is* markdown, so it's backlinked instantly, zero new infra (works today). Its **graph view is a near-free Observability surface** — FH's self-named weak ETCLOVG layer (`harnessfix_etclovg_sister`): the compounding link structure becomes *visible* for this backend at no added cost (imported from the 김효율 AX-Obsidian cross-audit, `tracks/_audit/session_2026_06_21_kim-hyoyul-ax-obsidian-wiki-harness.md` §4). |
+| **LLM-wiki / gbrain** | User runs a queryable memory brain | the user's gbrain **ingests** the emitted markdown (`gbrain` ingest); a deeper FH→gbrain MCP integration is a future candidate, **not wired today** |
+
+**Invariant across all backends** (unchanged): methodology stays in the public mirror (single-source guard); the store holds only *outputs*, never a rule copy; no domain-work pollution of the reference asset. Backend is a setup-time choice; the role, guards, and ephemeral-handoff rule below are identical regardless of backend. Rationale + import/propagate ledger: `knowledge/shared/harness-core/companion_store_pluggable_cross_audit_2026-06-11.md`.
+
+### Ephemeral-environment handoff (mode-agnostic — applies to anyone)
+
+When FH work runs in an **ephemeral, git-invoked environment** (Claude Code on the web, a GitHub Action, any cloud sandbox reclaimed after the session) **and** an open next action can only run locally (machine-bound steps the cloud session cannot do — installing hooks, native CLI runs like `/goal`, long-lived processes), **leave a surfaced handoff in a durable location before the session ends**:
+- **Mode D (companion store exists)** → the store's `handoff/` file.
+- **Otherwise (default — anyone)** → a handoff note committed to the **working repo**, or a PR comment. Everyone has the working repo, so **no companion store is required** for this.
+
+The handoff must be the obvious entry point a fresh local session lands on — its own file/comment carrying status + the single immediate next action + exact steps — not a footnote buried in a digest. **Never rely on gitignored / local-only files** (`.claude/settings.json`, and `tracks/_meta/*` unless you are Mode D with sync confirmed) for cross-session continuity in an ephemeral environment; they are wiped on reclaim. Mode D exception: gitignored local session data is auto-synced to the companion store via a Stop hook — durable for local-to-local continuity, but the sync hook itself does not run in cloud/ephemeral environments, so `handoff/` remains the correct channel there.
+
+### Session-start freshness — the card is a pointer, the committed store may be fresher (Mode D)
+
+At session start, after loading the companion store (or, for non-Mode-D users, the working-repo handoff), **check the store's newest *committed* work, not only the session card**. The companion store is a **durable git-committed repo** — distinct from the gitignored local mirror the paragraph above warns against; reading its commit history is safe *because* it is committed. A session card is written at one moment, but another environment or a later session can commit **newer** work to the store *after* that card. So **"pull is up-to-date" ≠ "I have seen the latest work."**
+
+- Concretely: compare the store's **newest commit date** to the card's date; if newer, read that content and reconcile it into the session plan/greeting *before* acting.
+- Precedence is **reconcile, not override**: newer-by-date content *triggers a read-and-reconcile* — it never silently wins over the card. The card may have been deliberately edited *after* a mechanical auto-sync commit (the card is written last in the close chain; the Stop hook fires on every stop), so **commit-recency ≠ authoring-authority**. When card and recent commits disagree, surface both and reconcile — do not let the newer timestamp auto-win.
+- Distinct from the Agent-View pre-read (in the hub `CLAUDE.md` §Session Wrap-up, which fires only in worktree/Agent-View sessions): this fires on **every** session start.
+
+*Salience → mechanical (upgraded 2026-07-05)*: this load is prose (salience-dependent), and its
+known failure mode is **task-first entry** — when the operator opens a session with an immediate task,
+the prose load silently does not fire and the agent runs on stale local memory (measured miss
+2026-07-05: stale sidecar-tool version + missed origin-model-sidecar instruction, both because the
+companion-store pull was skipped on task-first entry). The mechanical backstop is now built: a **SessionStart hook**
+(`scripts/fh_session_load.sh`, registered operator-local in `.claude/settings.local.json`) fires the
+companion pull + freshness delta **before turn 0, regardless of what the user types first**. Prose
+remains the semantic layer (read + reconcile); the hook guarantees the pull + surfaces what is newer
+than the card. (This resolves the `operational_adaptation.md` §Guards deferred-hook decision — its
+measured revisit-trigger fired.)
+
+**Single-source guard**: this methodology lives here in the public mirror. A companion store holds only the *outputs* that follow it (digests · signals · handoff files), never a copy of the rule.
+
+---
+
+## What You Get on Install — the value the harness adds
+
+The forge-harness bundles **rules, skills, and session protocols** into one environment — not a standalone plugin list. Two layers combined:
+
+### Layer 1 — Core assets (rules domain / auto-activated on harness install)
+
+| Core asset | Essence | Mode A | Mode B | Mode C | Mode D |
+|---|---|:---:|:---:|:---:|:---:|
+| **Active onboarding protocol** | Greeting trigger → 5-skill auto cascade | ✅ | ✅ | ❌ | ✅ |
+| **Harness usage mode 4 branches** | User-free mode branching + AI guidance obligation | ✅ | ✅ | ❌ | ✅ |
+| **Asset synergy branch judgment** | Auto-judgment of meta/hub seed vs field persistent location for new assets | ✅ | ✅ | ❌ | ✅ |
+| **Memory system auto-operation** | User utterances/insights auto-persisted + intent-based + associative auto-recall | ✅ | Partial | ❌ | ✅ |
+| **Companion-store routing** | Drafts/signals/handoffs → private store; methodology → public mirror | ❌ | ❌ | ❌ | ✅ |
+
+### Layer 2 — Skills domain (can separate plugin/skill / available in all Modes A·B·C·D)
+
+| Skill | Essence |
+|---|---|
+| `plugin-recommender` | Tier 1·2·3 classification + organization GHE + token check |
+| `cross-ecosystem-synergy-detection` | GHE cluster + Tier classification baseline |
+| `harvest-loop` | Weekly audit + self-evolution pipeline + Phase 2+ PR auto-proposal |
+| `verify-bidirectional` | Bidirectional self-verification + user-AI baseline update circuit |
+| `frontier-digest` | External-facing asset cross-ref + frontier trend + per-audience guide |
+| `hub-cc-pr-reviewer` | PR diff → baseline coherence check → review comment auto-generation |
+| `context-doctor` | `.claudeignore` auto-generation + large file detection + `/clear` timing guidance |
+| `harness-doctor` | Harness structure L1~L4 diagnosis + M/S/R prescription |
+| `sim-conductor` | External scenario/internal audit/ideation scan autonomous execution + M-tier auto PR |
+
+### Synergy — Layer 1 × Layer 2 combined is when it fully manifests
+
+```
+[Layer 1] Greeting trigger → active onboarding
+    ↓ auto cascade
+[Layer 2] plugin-recommender → cross-ecosystem → sister asset catch
+    ↓ results accumulated
+[Layer 1] memory system auto-persist → next session immediate awareness
+    ↓ weekly reflection
+[Layer 2] harvest-loop → pattern formalization → memory update
+    ↓ precision counter-argument
+[Layer 2] verify-bidirectional → baseline update channel
+```
+
+→ **Mode C** users receive Layer 2 but without Layer 1 rules = partial synergy only. **Mode A·B users get both layers auto-activated** = both layers active (Layer 1 + Layer 2).
+
+> **Three-Doctor Loop**: `harness-doctor` (structure) + `context-doctor` (context) + `sim-conductor` (ideation) 3 skills form a diagnosis→prescription→re-diagnosis closed loop. External term: *Diagnostic Triad* (isomorphic with Anthropic 3-Agent Harness Planner·Generator·Evaluator).
+
+### Natural language → skill connection (new user entry map)
+
+| User natural utterance | Meaning | Connected skill |
+|---|---|---|
+| "recommend a plugin", "what should I install" | Tool discovery | `plugin-recommender` |
+| "can I use what's in another project?", "what's available?" | Ecosystem synergy discovery | `cross-ecosystem-synergy-detection` |
+| "manage my context", "want to save tokens" | Context optimization | `context-doctor` |
+| "wrap up this week's work", "want to reflect" | Weekly audit | `harvest-loop` |
+| "review my PR", "please review" | PR audit | `hub-cc-pr-reviewer` |
+| "check harness structure", "confirm everything's running well" | Structure diagnosis | `harness-doctor` |
+| "what are the latest AI tools?", "tell me about frontier trends" | External asset discovery | `frontier-digest` |
+| "want to share this pattern", "can I post this here?" | Pattern harvesting | `field-harvest` |

package/knowledge/shared/rules/operational_adaptation.md

@@ -0,0 +1,73 @@
+# Operational Adaptation Loop — User-Tuned Self-Optimization
+
+Self-healing in FH today has two shapes: **FH-self-dev** (Mode D, the 4-axis auto-gate improving FH's own assets) and **reactive** (`verify-bidirectional`, a one-shot baseline update when the user pushes back). Both leave a gap: there is no **standing, per-user, operational** loop that tunes FH's everyday behavior to the individual during normal field use — and feeds the generalizable part of that tuning back to the origin.
+
+This loop fills that gap. It is deliberately thin: it **reuses** existing parts and only adds a profile convention + a generalization gate.
+
+| Concern | Existing part (reused — NOT rebuilt) | What this loop adds |
+|---|---|---|
+| Reactive correction | `verify-bidirectional` (per-correction baseline update) | A standing, aggregated profile (not one-shot) |
+| Reverse-PR funnel | `field-harvest` Mode A (field pattern → FH PR) | Feeds it generalizable UAP entries |
+| Outcome vocabulary | `operations.md` `subagent_invocations_log` (`accepted`/`rejected`/`sustained` + 60/40 gate) | Same vocabulary, extended from sub-agents to **skill proposals** |
+
+## User Adaptation Profile (UAP)
+
+**Location**: `tracks/_meta/user_adaptation_profile.md` — **local / gitignored**. It is a **personal asset**, never committed to the public mirror (single-source / drift guard, per `modes_and_value.md`). Mode D: mirror to the companion store's `tracks-meta/`.
+
+**Records behavioral preferences ONLY** — never domain work content (protects reference-asset identity):
+- **Skill-proposal outcomes** — per skill: `accepted` / `rejected` / `sustained` with counts (same 4-category vocabulary as `operations.md`).
+- **Preferred execution tier** (S/M/L/XL), language, working cadence.
+- **Capability-escalation consent** — `sidecar_consent` + `floorup_consent` (`accepted`/`declined`/`unset`),
+  per the **Capability-Escalation Consent Protocol** (`knowledge/shared/harness-core/capability_escalation_consent.md`).
+  Settled at onboarding (install-wizard) or ask-once at first need; `declined` → route to the floor
+  (Sonnet / Tier-3 CC-only sub-agent as a *first-class* mode), surface as recommendation only, **never re-nag**.
+- **Recurring friction points** (aggregated from `fh_signal_*`).
+- **Muted nags** — cadence reminders the user repeatedly declines.
+
+## Operational adaptation pass (field-session close)
+
+Runs at field-session close, **riding `field-harvest` Mode B** — no new trigger, never an interception. One pass per session.
+
+- **READ** (session start / proposal time): apply UAP — suppress a skill proposal rejected 3+ times (an `accepted` record carries **no** positive auto-action — the skill simply stays surfaced; do not auto-run on acceptance), default to the preferred tier, mute cadence nags the user always declines, and **apply capability-escalation consent** (`sidecar_consent`/`floorup_consent` `declined` → route to the Sonnet / Tier-3 floor, recommend-only, no re-nag; `unset` → ask-once at first need per the consent protocol). (Tier note: the UAP tier default is a session-depth setting; the Mode D model notice is model-only + advisory and never overrides it.)
+- **WRITE** (session close): update outcome counts + new friction points.
+
+## Generalization gate → reverse-PR funnel
+
+This is the operator's **"원본 반영 가치"** criterion made mechanical. Split each UAP learning:
+
+- **Idiosyncratic** (this user's taste) → stays in the UAP, local. **Never** escalated — pushing personal taste into the public reference asset is drift.
+- **Generalizable** (any user would benefit; the pattern recurs across **2+ sessions or projects**, not user-specific) → routed through `field-harvest` Mode A as a harvest candidate → FH-origin PR (HITL approval, per the existing field-harvest gate).
+
+**Promotion threshold** (reuse `operations.md` gate): a skill proposal `rejected ≥ 40%` across a 2+ session window is a *redefine/deprecate* candidate (a generalizable signal worth a PR); `accepted ≥ 60%` reinforces. Below threshold → personal one-off, stays local.
+
+**Generalization is a judged call — adversarial pairing required (no judge-only path).** The idiosyncratic-vs-generalizable split is not decided by the same session that wrote the UAP alone: it is paired with (a) the mechanical **2+ session/project recurrence threshold** above, and (b) `field-harvest` Mode A's contention-layer + the **human PR review** gate. A learning only reaches the public mirror after passing both — the recurrence backstop filters one-offs, the PR gate filters taste a human disagrees is general.
+
+## Done When
+
+- **UAP WRITE ran** at field-session close (or was correctly skipped — absent profile / ephemeral session). *Check class: mandatory-pass (binary — did Step 5-B.1 execute or log a skip reason).*
+- **UAP READ applied** at session start / proposal time when a profile exists (preferred tier defaulted, 3×-rejected proposals suppressed, declined cadence nags muted). *Check class: judged, pair: the target-tier blind sim below.*
+- **No domain content** entered the UAP this session. *Check class: judged, pair: phantom/content scan of the UAP diff.*
+
+## Guards
+
+- **Local-default, escalate-only-generalizable** — the drift-prevention spine of the loop.
+- **Behavioral data only** — no domain content in the UAP (reference-asset identity).
+- **Ephemeral env** — the UAP is gitignored, wiped on cloud reclaim. In an ephemeral/cloud session it is **unavailable**: operate from defaults, do not fabricate a profile, do not rely on it for cross-session continuity (`modes_and_value.md` ephemeral rule). The loop is a **local-session** mechanism.
+- **HITL** — escalation to FH origin goes through `field-harvest`'s existing PR-approval gate; no autonomous commit to the shared repo (`feedback_no_personal_commit_to_shared_repo`).
+- **Salience / tier dependence** — this loop is prose-driven, not hook-enforced. On a weaker model the READ side (apply-at-session-start) may silently not fire even when a UAP exists. This is an accepted limitation, not a silent one: it is the reason the change ships with a target-tier blind sim (per CLAUDE.md §Target-tier sim gate). A hook-enforced READ is a future hardening candidate, deliberately not built today (keep the surface thin).
+
+  **Deliberated 2026-06-16 (decision: DEFER) → BUILT 2026-07-05 (revisit-trigger fired on a real miss).**
+  The right mechanism is *not* the git pre-commit hook (the READ fires at session-start / proposal-time,
+  which is not a git event) but a Claude Code **SessionStart hook**. The 2026-06-16 deferral set a
+  **measured revisit-trigger** (build only when a real miss is observed, not on a guess). That trigger
+  **fired 2026-07-05**: an opus-tier session opened with an immediate qasp task, the prose session-start
+  companion load silently did not fire, and the agent operated on stale local memory (stale agy version;
+  missed the standing origin-model-sidecar instruction). This was a *production* miss, stronger evidence
+  than the deferral's target-tier-sim bar — so the hook is now built: **`scripts/fh_session_load.sh`**,
+  registered operator-local in `.claude/settings.local.json` SessionStart. It pulls the companion store
+  and emits a freshness delta (files newer than the session card + INDEX live pointers) into turn-0
+  context, *before* the first user message is processed — closing the task-first-entry salience gap
+  mechanically. Note the miss was **not** low-stakes as the 2026-06-16 note predicted (it produced wrong
+  recommendations, not just an unapplied preference), which is what tipped defer → build. Prose READ
+  remains the semantic layer (read + reconcile); the hook is the mechanical floor
+  (`[[feedback_judge_robustness_mechanical_anchor]]` — mechanical anchor over salience).

package/knowledge/shared/rules/operations.md

@@ -0,0 +1,48 @@
+---
+description: Defines sub-agent operating rules, weekly improvement cycle Phase 1.5~2, and the 3-phase maturity roadmap (Phase I~III).
+---
+
+# Operations Reference
+
+## Sub-agent Operations (optional)
+
+Custom sub-agents can be defined in hub or project `.claude/agents/*.md` (Claude Code standard).
+
+**Invocation rules:**
+- Prompts must be **self-contained** — sub-agents do not see main conversation context
+- Immediately after invocation, append to `knowledge/shared/learnings/subagent_invocations_log.yaml` (8 fields · outcome 4 categories: `accepted`/`partial`/`rejected`/`sustained`)
+- `sustained` (decided not to invoke) also recorded — negative sample for preventing over-engineering
+
+**Shared repository caution:** For personal agents in team shared repos, add `.claude/agents/` to `.git/info/exclude` to keep local-only. `.gitignore` is committed to the repo — do not use it.
+
+**Promotion gate (after 2+ week pilot):**
+- `accepted ≥ 60%` → maintain + strengthen description
+- `rejected ≥ 40%` → redefine scope or deprecate
+
+---
+
+## Weekly Improvement Cycle
+
+The hub audits and improves itself weekly.
+
+**Phase 1.5 (manual):**
+1. Gather window data by hand — `git log --since="{window}" --oneline` (+ count), `git tag --sort=-creatordate`, tail of `knowledge/shared/learnings/subagent_invocations_log.yaml`, stale-file spot checks. (No `_scanner.sh` exists — a prior reference here was a phantom, fixed 2026-06-11; the automation path is Phase 2 harvest-loop, a standalone scanner script is deliberately not built.)
+2. `bash scripts/below_floor_scan.sh` — below-floor marker re-run queue (the standing consumer §Floor governance promises: exit 1 = pending floor-tier re-validations, treat as S-tier; resolve via `floor-rerun:` / `floor-writeoff:` appended to the marker)
+3. Write `tracks/_audit/weekly_audit_YYYY-MM-DD.md` mirroring the previous audit file's format (frontmatter + activity table + 🟥🟧🟩 + pattern table — no separate template file exists)
+4. Propose 3-tier improvements (🟥mandatory/🟧strong/🟩recommended)
+
+**Recurrence escalation** (N=3 threshold): Scanner output shows the same defect class in 3+ distinct commits or sessions within the audit window → S-tier signal; propose instrumenting as a CI probe (`npm test` extension or pre-commit hook) rather than adding a new habit rule. Three recurrences indicate the defect class is structural — habits don't hold.
+
+**Phase 2 (skill-ized):** `/harvest-loop` (lightweight mode) automates the above procedure (manual ~10 min → auto ~3 min target). Scanner invocation, prediction vs measurement comparison, repetitive pattern detection, promotion/deprecation candidate proposal automated.
+
+**Session start auto-detection (L1):** When Claude Code session starts in hub cwd, check mtime of recent `weekly_audit_*.md` file → propose audit if 7+ days elapsed.
+
+**Phase 2~4 roadmap:** See `knowledge/shared/harness-core/hub_compounding_loop.md`.
+
+---
+
+## 3-Phase Maturity Roadmap
+
+The hub's long-term evolution path is managed as a 3-stage model: **Phase I (entering maturity) → Phase II (frontier following) → Phase III (frontier leading)**. Phase transition gates have the simplification principle ("A good harness gets simpler over time") as a common condition.
+
+**Detailed frame:** See `knowledge/shared/harness-core/hub_maturity_roadmap.md` (Phase I 5-criteria gate · Phase II (b) cadence · Phase III 6 indicators + operating guide for writing).

package/knowledge/shared/rules/sister_asset_protocol.md

@@ -0,0 +1,54 @@
+---
+description: Protocol for when a sister asset (another team within the organization, external frontier, another repo) covering the same topic is discovered — blocks cognitive gaps and opens a bidirectional learning loop. Keep the activation threshold low.
+---
+
+# Sister Asset Protocol
+
+When a **sister asset** (another team in the organization · external frontier · another repo) covering the same topic is discovered, follow this procedure to block cognitive gaps and open a bidirectional learning loop.
+
+## When to activate
+
+- During work, a **sense of deja vu** arises: "I feel like this topic was covered somewhere"
+- An external resource with **similar scope but different resolution** from a `knowledge/shared/` asset is found
+- An external reference URL repeatedly appears in the weekly audit scanner aggregation
+- User mentions "that other project/team also did this"
+
+## Lightweight path (C-tier — cheap debt entry)
+
+If step 1 (asset identity) shows the territory is **already covered** — dedup hit on the source, or
+a prior cross-audit of the same claims, with no new increment — do **not** write a full cross-audit:
+record a **one-paragraph entry** (source · dedup verdict · the one-line increment if any · pointer to
+the prior audit) in the ledger/log used for speculative intake. Full steps 2–3 are reserved for
+A/B-tier sources (new territory or a real increment). Keeps intake cheap — the discipline that lets
+the wide net stay wide.
+
+## 3 steps after detection
+
+1. **Asset identity confirmation (5 min)** — Confirm creation date · author · access scope (internal-public·open-source) · scope in one line. Identify **resolution difference** from the hub's corresponding asset.
+
+2. **Cross-audit session creation** — Record comparison in `tracks/_audit/session_YYYY_MM_DD_{slug}.md`. Minimum contents:
+   - Position comparison table of the two assets (perspective · axis basis · conclusion method)
+   - Overlap area (value if combined)
+   - List of **items to import** from the other side
+   - List of **items the hub can propagate**
+   - Cognitive gap facts (independent work interval, mutual unaware period)
+
+3. **Cross-reference link insertion judgment** — 1 line at the end of hub asset + 1 line at the head of the other asset. If no write access to the other repo, write a **proposal** (`tracks/_audit/proposal_*.md`) and deliver to the team.
+
+## Prohibited
+
+- **One-way export** — No "we'll teach them" tone. **Publicly list the items to import first** to demonstrate bidirectionality.
+- **Instructive proposals to restructure the other asset** — "add section / restructure / insert" verbs risk damaging the relationship. Use provider-humble phrasing.
+- **Clone-and-own the other asset** — Do not copy the other repo's asset into the hub. Reference links + session records only.
+
+## Required before distributing proposals externally
+
+Proposals to deliver to the other team are external-facing assets. After **3+ persona × 4-axis** (resonance·confusion·resistance·supplement) audit using `hub-persona-auditor` or similar, accept 3-tier revisions. Do not deliver directly without audit.
+
+## Quarterly sync
+
+Quarterly sync with the latest version of the sister asset recommended (approximately 3-month cycle). Sharing the schedule with the other side makes work timing predictable.
+
+## Real-world value basis
+
+The value of discovering a sister asset is proportional to the **cognitive gap period**. In a case where two teams in the same organization independently worked on the same topic 4 days apart, simply having cross-links would have multiplied the combined value. Keeping the protocol activation threshold low is the safe choice.

package/knowledge/shared/rules/sync_push_protocols.md

@@ -0,0 +1,139 @@
+---
+description: Defines the Session Sync procedure for persisting session work to the hub, the Knowledge Push protocol for feeding new knowledge back, CATALOG.md format, track mapping table, and tag conventions.
+---
+
+# Session Sync / Knowledge Push Protocols
+
+## Session Sync Protocol
+
+Procedure for persistently storing sessions worked on in other projects into the hub.
+Follow this protocol when the user requests "sync", "save session", or similar.
+
+### Sync target judgment
+
+| Sync YES | Sync NO |
+|---|---|
+| New pattern/rule discovered | Simple code change (1-line bug fix) |
+| Architecture decision | Routine test execution |
+| Lessons/feedback (learned from failures) | Repeating already-recorded content |
+| Roadmap/strategy change | Sessions with only exploration and no conclusion |
+
+**What-kind axis (Raw / Wiki / Conversation)** — orthogonal to the YES/NO above and to the
+location split (knowledge/ · tracks/ · memory/), this classifies the *processing stage*, which
+routes the destination: **Raw** = unprocessed capture (a pasted log, a fetched source) → stays in
+tracks/ or a companion store, not yet distilled · **Wiki** = distilled + `[[linked]]` knowledge →
+knowledge/ or memory/ (the compounding layer) · **Conversation** = dialogue/decision logs → tracks/
+session files. A Raw item is not yet a Wiki item; the distill step (Raw → Wiki) is where linking +
+the contradiction scan below earn their keep. (Imported from the 김효율 AX-Obsidian cross-audit,
+`tracks/_audit/session_2026_06_21_kim-hyoyul-ax-obsidian-wiki-harness.md` §4 — a crisper ingest
+schema than the location split alone.)
+
+### Sync procedure
+
+```
+1. Create/move session file
+   → tracks/{project}/session_YYYY_MM_DD_{slug}.md
+   → YAML frontmatter required: name, description, type, date, tags
+
+2. If learnings/feedback exist, create separate file
+   → tracks/{project}/learnings/feedback_{slug}.md
+
+3. Contradiction scan — ingest gate (class: judged, pair: verify-bidirectional)
+   → Before indexing, grep CATALOG.md + knowledge/ for claims the new content contradicts
+     (same topic with opposite conclusion · superseded version/number · changed definition)
+   → Contradiction found: flag it in BOTH the new file and its CATALOG entry
+     ("conflicts with / supersedes: {file}") — contradictions never coexist silently
+   → Removing or rewriting the OLD claim requires operator approval (HITL)
+   → Clean scan: proceed without notes
+
+4. Add entry to CATALOG.md
+   → Maintain reverse date order (newest at top)
+   → Include tags, 3-line summary, key decisions
+
+5. git commit
+   → "sync: {project} {date} session — {one-line summary}"
+```
+
+### Track mapping
+
+Update the track mapping table in CLAUDE.md each time a project is added.
+
+| Project | Track directory |
+|---|---|
+| (example) project-a | tracks/project_a/ |
+| Patterns common to 2+ projects | knowledge/shared/ |
+| Hub meta work (weekly_audit, etc.) | tracks/_{topic}/ — underscore prefix |
+
+**Underscore prefix convention**: `tracks/_audit/` · `tracks/_mcp/` etc. are for hub operations/meta work only. Consider promoting to parent directory when meta tracks accumulate to 3+.
+
+**Two-layer storage principle**: `tracks/` = detailed work history (local, machine-dependent). For critical cross-session state — pending codes, DOIs, active action items — also write to `~/.claude/projects/.../memory/` (durable, survives re-clone or machine change).
+
+---
+
+## Knowledge Push Protocol
+
+Protocol for feeding new knowledge discovered in projects back to the hub.
+
+### Learnings/feedback (short patterns)
+
+```yaml
+---
+name: {identifiable name}
+description: {one-line summary}
+type: feedback
+date: YYYY-MM-DD
+tags: [{related}, {tag}]
+originProject: {project name}
+---
+
+{content — Why/How to apply structure recommended}
+```
+
+Storage path: `tracks/{project}/learnings/feedback_{slug}.md`
+
+### Session records (work history)
+
+```yaml
+---
+name: {session title (include date)}
+description: {one-line main achievement}
+type: project
+date: YYYY-MM-DD
+tags: [{related}, {tag}]
+---
+```
+
+Storage path: `tracks/{project}/session_YYYY_MM_DD_{slug}.md`
+
+### Cross-project patterns
+
+Patterns applicable to 2+ projects are written in `knowledge/shared/`.
+
+**Ingest gate applies here too**: before adding a `knowledge/shared/` doc, run the
+contradiction scan (Sync procedure step 3) against existing knowledge/ claims.
+
+---
+
+## CATALOG.md Format
+
+Follow the format below when adding entries:
+
+```markdown
+### YYYY-MM-DD | {project} | {tag1}, {tag2}, {tag3}
+**File:** tracks/{project}/filename.md
+{Summary within 3 lines. What was done and why it matters.}
+- Decision: {key decision — architecture choice, direction confirmed, etc.}
+- Open: {unresolved issues — only if applicable}
+```
+
+---
+
+## Tag Conventions
+
+Add freely, but prefer reusing existing tags.
+
+**Operations trigger tags** (aggregated by weekly audit scanner):
+- `#gap-trigger:axis-N` — per-axis asset gap (auto-assigned when 0 entries continue 2+ months)
+- `#skill-candidate:XXX` — Skill promotion candidate for patterns repeated 3+ times
+- `#rule-candidate:XXX` — Rule promotion candidate for mistakes repeated 3+ times
+- `#archive-candidate` — Self-reported deprecation

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@chrono-meta/fh-gate",
-  "version": "1.4.54",
+  "version": "1.4.56",
   "description": "FH runtime adapters — run FH governance, skills, and agents via Claude or Codex with machine-parseable gates.",
   "license": "MIT",
   "keywords": [
@@ -72,6 +72,7 @@
     "plugins/fh-commons/agents",
     "knowledge/shared/harness-core",
     "knowledge/shared/dialogue",
+    "knowledge/shared/rules",
     "README.md",
     "README.ko.md",
     "README.zh.md",

package/plugins/fh-commons/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "fh-commons",
-  "version": "1.4.54",
+  "version": "1.4.56",
   "engines": {
     "claudeCode": ">=1.0.0"
   },

package/plugins/fh-meta/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "fh-meta",
-  "version": "1.4.54",
+  "version": "1.4.56",
   "engines": {
     "claudeCode": ">=1.0.0"
   },

package/plugins/fh-meta/skills/contention-layer/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: contention-layer
-description: When two skills, agents, or independent research tracks produce conflicting verdicts on the same output, reads the conflict as a signal rather than an error and harvests new skill candidates or insight deltas. Also accepts a Dual-Track Grounding conflict — an open-frontier research track vs an internally-grounded recall track disagreeing — as a research-layer partial analogue of Non-Model Ground (the grounded track is a time-decorrelated anchor, not a non-model one). Routes skills born from contention to fh-meta if they are meta-layer, to commons plugin if project-agnostic, or to field harvest if domain-specific. Triggered by "two skills conflict", "they produce different conclusions", "contention-layer", "contention harvest", "open vs grounded contradiction", "research tracks disagree".
+description: When two skills, agents, or independent research tracks produce conflicting verdicts on the same output, reads the conflict as a signal rather than an error and harvests new skill candidates or insight deltas — including a Dual-Track Grounding conflict (open-frontier track vs internally-grounded recall track disagreeing). Routes skills born from contention to fh-meta (meta-layer), the commons plugin (project-agnostic), or field harvest (domain-specific). Triggered by "two skills conflict", "they produce different conclusions", "contention-layer", "contention harvest", "open vs grounded contradiction", "research tracks disagree".
 user-invocable: true
 allowed-tools: ["Read", "Bash", "Grep", "Write"]
 model: sonnet

package/plugins/fh-meta/skills/field-harvest/SKILL.md

@@ -200,7 +200,7 @@ Output the confirmation block (file path + commit hash + push offer — format i
 
 ## Step 5-B.1. UAP Update (Operational Adaptation Loop)
 
-> Rule: `.claude/rules/operational_adaptation.md`
+> Rule: `knowledge/shared/rules/operational_adaptation.md`
 
 At field-session close, update the **User Adaptation Profile** (`tracks/_meta/user_adaptation_profile.md`, local/gitignored — skip silently if absent or in an ephemeral/cloud session):
 

package/plugins/fh-meta/skills/field-harvest/SKILL_detail.md

@@ -16,7 +16,7 @@ load: on-demand
 
 ```bash
 # Priority 1: Read FH auto_project_mapping.md
-cat .claude/rules/auto_project_mapping.md 2>/dev/null | grep -E "path:|project:" | head -10
+cat knowledge/shared/rules/auto_project_mapping.md 2>/dev/null | grep -E "path:|project:" | head -10
 
 # Priority 2: Auto-discover git repos in common development directories
 find "$HOME/projects" "$HOME/dev" "$HOME/workspace" "$HOME/PycharmProjects" \

package/plugins/fh-meta/skills/harness-doctor/SKILL.md

@@ -78,9 +78,21 @@ confirms the gap*, never a verdict the report emits on its own; surface each gap
 | 15+ `##` sections in CLAUDE.md | S-tier warning |
 | SKILL.md > 300 lines AND no `SKILL_detail.md` | S-tier — propose `/salience-splitter` (governance-semantic split, not compression) |
 | Rules files unreferenced in CLAUDE.md | R-tier |
+| Always-loaded footprint (CLAUDE.md + every `.claude/rules/*.md` lacking `paths:` frontmatter) > 40k chars | S-tier — relocate detail rules to a non-loaded dir (e.g. `knowledge/shared/rules/`), pointers stay in CLAUDE.md |
+| Always-loaded footprint > 80k chars | M-tier — same prescription, mandatory |
+| **Pointer-illusion**: a CLAUDE.md "detail/detailed procedure" pointer whose target is itself an always-loaded `.claude/rules/*.md` | S-tier — the split saves zero context (rules/ auto-loads regardless); move the target out of auto-load, keep the pointer |
 | weekly_audit 14~30 days elapsed | S-tier |
 | weekly_audit 30+ days elapsed | M-tier |
 
+Always-loaded + pointer-illusion checks are mechanical (found 2026-07-12 — FH itself shipped ~50k chars of rules/ behind "detail pointers" that saved nothing; the meta-harness blind spot this row closes):
+
+```bash
+# always-loaded footprint (chars): CLAUDE.md + rules files with no paths: frontmatter
+T=$(wc -c < CLAUDE.md 2>/dev/null); for f in .claude/rules/*.md; do [ -f "$f" ] || continue; head -5 "$f" | grep -q '^paths:' || T=$((T + $(wc -c < "$f"))); done; echo "always-loaded: $T chars"
+# pointer-illusion: CLAUDE.md pointers targeting still-auto-loaded rules files
+grep -oE '\.claude/rules/[a-z_]+\.md' CLAUDE.md | sort -u | while read p; do [ -f "$p" ] && echo "ILLUSION: $p (pointed-to AND always-loaded)"; done
+```
+
 ### Step 3-L. Language Lint (`--lint` mode only)
 
 > Activate with `/harness-doctor --lint` or when harvest-loop surfaces a P10-series signal. Skipped in standard runs.

package/plugins/fh-meta/skills/harvest-loop/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: harvest-loop
-description: A self-evolution pipeline that runs automatically after field sessions end. field-harvest (pattern extraction) → contention-layer (collision signals) → [Agent(subagent_type="challenger") + persona-innovator parallel] → synthesizer (challenger/innovator collision harvest) → Critic isolated Agent (SAGE automated critique) → harness-doctor (health check) → verify-bidirectional (consistency validation) → curator (skill lifecycle management) — 8 steps. Session learnings are automatically absorbed back into the FH ecosystem so the harness evolves on its own. In the main development environment, runs automatically at session end. For external FH users, proposes execution first. Triggered by "session harvest", "learning absorption", "fh evolution", or "harvest-loop". (The phrase "run the pipeline" is ceded to pipeline-conductor to avoid a trigger collision — for end-to-end verification sweeps use pipeline-conductor.)
+description: An 8-step self-evolution pipeline that runs after field sessions end (field-harvest → contention-layer → challenger + persona-innovator → synthesizer → Critic agent → harness-doctor → verify-bidirectional → curator), absorbing session learnings back into the FH ecosystem. Runs automatically at session end in the main dev environment; proposes execution first for external users. Triggered by "session harvest", "learning absorption", "fh evolution", or "harvest-loop". (The phrase "run the pipeline" is ceded to pipeline-conductor — use that for end-to-end verification sweeps.)
 user-invocable: true
 allowed-tools: ["Read", "Write", "Bash", "Grep", "Glob", "Agent"]
 model-note: session-inherit — Sonnet base is first-class (sonnet_floor_doctrine.md); depth-critical judged steps route to dispatch (opus agent / cross-family sidecar, consent-gated), never a substrate requirement
@@ -40,7 +40,7 @@ Step 0 (Regression Guard) + Step 1 (field-harvest) + Step 2 (contention-layer) +
 Session end
     │
 [Step 0-a] FH asset change detection → auto-quench
-    │  git diff --name-only HEAD | grep -E "SKILL\.md|\.claude/rules/|templates/|CLAUDE\.md"
+    │  git diff --name-only HEAD | grep -E "SKILL\.md|\.claude/rules/|knowledge/shared/rules/|templates/|CLAUDE\.md"
     │  → 1+ FH assets changed: run full 3-axis gate
     │  → No changes: proceed to Step 0-b immediately
     │

package/plugins/fh-meta/skills/video-ingest/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: video-ingest
-description: Ingests a video's content (YouTube and similar) for agent context, routing by capability, by what the task needs, and by video length. When the task needs video understanding it prefers a natively multimodal engine that ingests the URL directly (Gemini via agy or the Gemini API, best for long video); when no such engine is present it uses Claude's own vision over ffmpeg-extracted frames (the claude-video pattern, best for short/medium, no external-runtime dependency); when the transcript alone suffices it uses yt-dlp's caption-track path; auth-gated videos fall back to the logged-in claude-in-chrome session. The governor cross-checks any multimodal comprehensive-read rather than trusting it. Reuses frontier-digest's Sidecar Engine Resolution Protocol for the capability probe. Triggered by "ingest this video", "what does this video show", "get the transcript from this YouTube video", "video-ingest".
+description: Ingests a video's content (YouTube and similar) for agent context, routing by capability, task need, and video length — a natively multimodal engine (Gemini via agy or the Gemini API) for direct-URL and long video, Claude vision over ffmpeg-extracted frames when no such engine is present, yt-dlp captions when the transcript alone suffices, and the logged-in claude-in-chrome session for auth-gated videos. The governor cross-checks any multimodal comprehensive-read. Triggered by "ingest this video", "what does this video show", "get the transcript from this YouTube video", "video-ingest".
 user-invocable: true
 allowed-tools: ["Read", "Bash"]
 model: sonnet