@chrono-meta/fh-gate 1.4.53 → 1.4.55

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.