@chrono-meta/fh-gate 1.4.40 → 1.4.42

package/knowledge/shared/harness-core/harness_frontier_diagnosis_2026-06-02.md

@@ -0,0 +1,102 @@
+---
+name: harness-frontier-diagnosis-2026-06-02
+description: Frontier digest anchored on FH's 3-layer identity (Control Tower · Frontier→Org Propagation · AI Collaboration Guide) + Core Axis. External AI/harness-engineering signal from 2026-06 translated into per-identity strengthening candidates, with simplicity guards.
+type: frontier-diagnosis
+date: 2026-06-02
+engine: websearch
+tags: [frontier, identity, harness-engineering, multi-agent, a2a, mcp, context-engineering, observability, v2-paper]
+---
+
+# Harness Frontier Diagnosis — 2026-06-02
+
+> Identity ② asset (`harness_frontier_diagnosis_*.md`). Collects the global AI/harness-engineering
+> frontier and **translates it for FH operations** — anchored on FH's three identities + Core Axis.
+> Engine: WebSearch (no `ANTHROPIC_API_KEY`; outbound curl blocked → forced downgrade per `frontier-digest` skill).
+
+## FH Identity Anchor (from CLAUDE.md §Identity)
+
+| # | Identity | One-line role |
+|---|---|---|
+| ① | **Control Tower** | Command HQ that coordinates all connected projects |
+| ② | **Frontier → Org Propagation** | Absorb global frontier thinking, translate it into org language |
+| ③ | **AI Collaboration Guide** | Accumulate/distribute token-efficiency + dialogue methodology |
+| Axis | **Harness Engineering (How)** | The 6-axis methodology that realizes the three above |
+
+---
+
+## Frontier Highlights (2026-06)
+
+**1. "Harness Engineering" named the 4th paradigm of AI engineering.**
+The arc prompt → context → harness is now an explicit industry framing: *"Agents aren't hard; the
+Harness is hard."* The widely-cited claim is that **~65% of enterprise AI failures trace to harness
+defects** — Context Drift, Schema Misalignment, State Degradation — not model capability. This is
+direct external validation of FH's whole thesis (`meta_harness_engineering_definition.md`,
+`fh_ecosystem_positioning.md`). → **Core Axis**.
+
+**2. Agent interoperability standardized: A2A "Agent Cards" + MCP registry under Linux Foundation.**
+A2A standardizes how agents *discover* each other's capabilities (Agent Cards); MCP launched a
+community server registry (Nov 2025). Production topology data: orchestrator-worker is ~70% of
+deployments, but **centralized multi-agent coordination carries ~+285% token overhead** and the
+practical team size is **3–4 agents** before coordination cost dominates. → **① Control Tower**.
+
+**3. Observability is the bottleneck for self-improving harnesses (Agentic Harness Engineering).**
+AHE's central claim: *agents cannot reliably improve a black-box harness* — the evolution loop needs
+the harness's components, experiences, and decisions to be observable and verifiable. Eval-driven:
+the 2026 Coding Agent Index benchmarks **model+harness pairs**, not models alone. Context research
+adds the "lost in the middle" effect (10–30% accuracy drop on mid-context information) and the
+hierarchical-context remedy (L1 always-on / L2 session / L3 on-demand) + prompt compression.
+→ **② Frontier Propagation** + **③ AI Collaboration Guide**.
+
+---
+
+## Per-Identity Strengthening Candidates
+
+### ① Control Tower
+
+| Candidate | Frontier basis | FH hook |
+|---|---|---|
+| **Machine-readable `agent-card`-style capability registry** for the FH agents (capability / input-output contract, synced to actual file counts) | A2A Agent Card = the discovery standard | Closes the "count drift / no canonical registry" gap already flagged in `fh_ecosystem_positioning.md` |
+| **Coordination-overhead budget** in `context-bridge-dispatch`: parallel-fan-out cap (3–4) + capability-aware routing | Centralized = +285% tokens; team size caps at 3–4 | `plugins/fh-meta/skills/context-bridge-dispatch`, `agent-composer` |
+
+### ② Frontier → Org Propagation
+
+| Candidate | Frontier basis | FH hook |
+|---|---|---|
+| Add a **harness-defect taxonomy axis** (Context Drift / Schema Misalignment / State Degradation) to structural diagnosis | "65% of AI failures = harness defects" | `plugins/fh-meta/skills/harness-doctor` |
+| Add **observability / eval hooks** to the evolution loop so self-improvement is glass-box, not black-box (eval-driven, model+harness benchmarking style) | AHE: observability is the self-improvement bottleneck | `plugins/fh-meta/skills/harvest-loop`, `harness-doctor` |
+
+### ③ AI Collaboration Guide
+
+| Candidate | Frontier basis | FH hook |
+|---|---|---|
+| Formalize **L1/L2/L3 context hierarchy** + critical-info-at-start-and-end placement as a dialogue norm | "Lost in the middle" 10–30% degradation | `plugins/fh-meta/skills/context-doctor`, `CHEATSHEET.md` |
+| Add a **prompt-compression pass** (LLMLingua-style) to further shrink the install footprint | 100K→20K near-lossless compression cases | `plugins/fh-meta/skills/context-doctor` |
+
+---
+
+## Warning Signals
+
+- **Agent-proliferation temptation.** Centralized multi-agent = +285% tokens; it only pays off with
+  genuine specialization / parallelism / critique. FH's own principle — *"a good harness gets simpler
+  over time"* — is the built-in guard. Do not add agents to chase the trend.
+- **"Harness Engineering" is becoming a buzzword** (awesome-lists, "4th paradigm" marketing). Cite the
+  external convergence as validation, but treat it as a complexity-creep risk, not a mandate to expand.
+
+---
+
+## Provenance (WebSearch sources, 2026-06-02)
+
+- Epsilla — *The Third Evolution: Why Harness Engineering Replaced Prompting in 2026* — https://www.epsilla.com/blogs/harness-engineering-evolution-prompt-context-autonomous-agents
+- Faros.ai — *Harness Engineering: Making AI Coding Agents Work in 2026* — https://www.faros.ai/blog/harness-engineering
+- Adnan Masood — *Agent Harness Engineering — The Rise of the AI Control Plane* — https://medium.com/@adnanmasood/agent-harness-engineering-the-rise-of-the-ai-control-plane-938ead884b1d
+- getstream.io — *Top AI Agent Protocols in 2026 — MCP, A2A, ACP & More* — https://getstream.io/blog/ai-agent-protocols/
+- Zylos Research — *Agent Interoperability Protocols 2026: MCP, A2A, ACP and the Path to Convergence* — https://zylos.ai/research/2026-03-26-agent-interoperability-protocols-mcp-a2a-acp-convergence
+- codebridge.tech — *Multi-Agent Systems & AI Orchestration Guide 2026* — https://www.codebridge.tech/articles/mastering-multi-agent-orchestration-coordination-is-the-new-scale-frontier
+- Micheal Lanham — *Multi-Agent in Production in 2026: What Actually Survived* — https://medium.com/@Micheal-Lanham/multi-agent-in-production-in-2026-what-actually-survived-f86de8bb1cd1
+- Inference Weekly — *Agentic Harness Engineering (AHE): Evolving Coding-Agent Harnesses with Observability-Driven Automation* — https://medium.com/@harshit.sinha0910/agentic-harness-engineering-ahe-evolving-coding-agent-harnesses-with-observability-driven-297481226663
+- Observability-Driven Automatic Evolution of Coding-Agent Harnesses — https://arxiv.org/pdf/2604.25850
+- TokenMix — *LLM Context Window 2026: 128K to 10M Tokens* — https://tokenmix.ai/blog/llm-context-window-explained
+- dasroot.net — *Token Optimization Strategies for Cost-Effective LLM Applications* — https://dasroot.net/posts/2026/04/token-optimization-llm-costs-prompt-engineering/
+
+> Raw collected signal + the improvement-signal processing checklist (working log) are kept in the
+> private companion store, per the public/private split policy — not committed to this public repo.

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

@@ -0,0 +1,109 @@
+# Hub Compounding Loop
+
+> Axis-6 automation: the mechanism by which the forge-harness hub improves itself over time through structured feedback cycles.
+
+**Principle**: Each session's learnings are absorbed back into the hub so the harness evolves on its own — without requiring manual re-triggering.
+
+---
+
+## Cycle Overview
+
+| Cadence | Trigger | Key actions |
+|---|---|---|
+| **Per-session** | Session close ("wrap up", "done", "good work") | harvest-loop → card update → push check |
+| **Weekly** | 7 days since last `frontier_digest_*.md` | `/frontier-digest` → CATALOG entry + 6-candidate implementation |
+| **Monthly** | 30 days since last harness-doctor run | `/harness-doctor` → L1~L4 diagnosis + M/S/R prescription |
+| **Quarterly** | ~90 days | Sister asset sync, Phase transition gate review |
+
+---
+
+## Per-Session Close Chain (Automatic — Not Skippable)
+
+```
+Closing phrase detected
+  → ① git diff check
+  → ② if diff exists → harvest-loop
+  → ③ card update (reference_next_session_starter.md) — independent obligation
+  → ④ unpushed commits → propose "push?"
+```
+
+Card update is NOT a sub-step of harvest-loop — runs even if harvest-loop is skipped.
+
+**Real-time tracking**: Complete S-tier/A-tier items get immediately appended to
+`tracks/_meta/fh_completed_{YYYY-MM-DD}.md` (before context compression).
+harvest-loop Step 0-b uses this file — relying on LLM memory after compression causes omissions.
+
+---
+
+## harvest-loop Pipeline (8 Steps)
+
+```
+field-harvest (pattern extraction)
+    → contention-layer (collision signals)
+    → [persona-devil-advocate + persona-innovator] (parallel)
+    → synthesizer (devil/innovator collision harvest)
+    → Critic isolated Agent (SAGE critique)
+    → harness-doctor (health check)
+    → verify-bidirectional (consistency validation)
+    → curator (skill lifecycle management)
+```
+
+Session learnings automatically absorbed back into FH ecosystem.
+
+**In main dev env**: runs automatically at session end.
+**For external FH users**: proposes execution first.
+
+---
+
+## Weekly Audit Cycle (Phase 1.5)
+
+1. `./tracks/_audit/_scanner.sh "7 days ago"` — aggregates: commits, tags, stale files, sub-agent invocation log, self-asset references
+2. Copy `_template_weekly.md` → `weekly_audit_YYYY-MM-DD.md`
+3. Propose 3-tier improvements (🟥mandatory / 🟧strong / 🟩recommended)
+
+**Phase 2 (skill-ized)**: `/harvest-loop` automates the above (manual ~10 min → auto ~3 min target).
+
+---
+
+## Cadence Files (Session-Start Auto-Detection)
+
+| File | Cadence | Auto-propose condition |
+|---|---|---|
+| `tracks/_meta/frontier_digest_*.md` | 7 days | Propose `/frontier-digest` at session start if 7+ days |
+| `tracks/_meta/*harness_doctor*.md` | 30 days | Propose `/harness-doctor` at session start if 30+ days |
+
+---
+
+## 3-Phase Maturity Roadmap
+
+| Phase | Name | Criteria |
+|---|---|---|
+| **Phase I** | Entering Maturity | 5-criteria gate — consistent weekly audit, no critical debt, harvest-loop running |
+| **Phase II** | Frontier Following | frontier-digest cadence + sister asset sync + external PR evidence |
+| **Phase III** | Frontier Leading | 6 indicators + writing guide for org-level propagation |
+
+**Shared condition for all transitions**: optimization principle — field harness: getting simpler over time; meta-harness: complexity justified by scope (no orphaned/redundant/decorative units).
+
+Detailed frame: `hub_maturity_roadmap.md`.
+
+---
+
+## FH Improvement Signal Recording
+
+When friction is detected during a session, record it for the next session's awareness:
+
+```
+tracks/_meta/fh_signal_{YYYY_MM_DD}_{source}.md
+```
+
+Fields: friction point, FH registration candidate, status (pending hub review).
+
+**Guard**: 1 file per session (append if same date+source). Structural improvements only — no minor typos.
+
+---
+
+## 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)

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

@@ -0,0 +1,201 @@
+---
+name: Hub Maturity 3-Phase Roadmap Frame (template)
+description: Long-term evolution path frame for the hub. Phase I (entering maturity) → Phase II (frontier following) → Phase III (frontier leading) 3-stage model. Fixes the gap, output, completion criteria, and transition conditions for each phase as a quarterly re-diagnosis reference document. The maturity axis is the parent frame referenced by monthly level snapshots and quarterly re-diagnosis. **This file is a template — in actual hub operation, add project-specific information (timing, asset names, identifiers) to write an operating copy**.
+type: reference
+date: 2026-04-28
+tags: [harness, maturity, roadmap, 3-phase, frontier-tracking, evolution, compounding, long-term, hub, strategic, template-frame]
+scope: hub-template
+---
+
+# Hub Maturity 3-Phase Roadmap (frame)
+
+## Why this document exists
+
+If the monthly level snapshot captures **"where are we now"**, this document captures **"where are we going and when do we transition"**. If the quarterly re-diagnosis captures **current position vs industry frontier**, this document captures **the evolution of the relationship with the frontier itself** (follower → leader).
+
+**Core vision**:
+
+> The hub model matures enough to **enter the maturity phase**, **follow** the frontier's advancement direction periodically, and after that, the path where **we become the frontier**.
+
+This vision is made explicit as 3 phases so that at each quarterly re-diagnosis, "which phase are we in · what are the conditions for the next phase transition" can be judged.
+
+---
+
+## 1. 3-Phase Overview
+
+| Phase | Scope | Core gap (example) | Representative output (example) | Standard duration (example) |
+|---|---|---|---|---|
+| **I. Entering maturity** | Infrastructure/asset building + routine establishment | Operational gap axes remain · automation not established · 0 external propagation | Weekly audit automation · operations guide · 1-2 external assets · sub-agent judgment · self-diagnosis warning reduction | 3-6 months |
+| **II. Frontier following** | Quarterly re-diagnosis routine + gap auto-detection | Single/dual input sources · no auto gap detection · cadence not confirmed | Quarterly frontier diagnosis 2 times + monthly brief established + external scan cadence confirmed | 5-8 months |
+| **III. Frontier leading** | Self-invented outbound propagation + self-evolving | 0 open-source/presentation record · no self-evolving loop · 0 industry citations | Public refactor · blog/presentation 10+ per year · industry citation case accumulation | Ongoing (no completion) |
+
+---
+
+## 2. Current Position (fill in operating copy)
+
+Fill in the following format in the operating copy:
+
+```
+**Phase X · ~N% progress** — infrastructure/asset accumulation status · N remaining completion gaps
+```
+
+### Achievement table (example format)
+
+| Area | Status | Basis |
+|---|---|---|
+| 6-axis framework + feedback loop | ✅ | (corresponding asset path) |
+| Package structure alignment | ✅ | (realignment session) |
+| ... | ... | ... |
+
+### Gaps remaining
+
+See §3 Phase I completion criteria.
+
+---
+
+## 3. Phase I Completion Criteria (5 measurable criteria)
+
+Phase II entry gate passed when all 5 are met.
+
+| # | Condition | Measurement method (frame) |
+|---|---|---|
+| 1 | **Weekly audit automation established** | audit skill run 3+ times + manual N min → auto N min measured |
+| 2 | **Axis N operations guide established** | orchestration guide draft + mode switch 3+ cases accumulated (if gap axis exists) |
+| 3 | **External propagation N cases** | Distributed to external channel + external response received (generally 2 cases recommended) |
+| 4 | **Sub-agent pilot promotion/deprecation judgment** | 2+ week observation + invocation log-based judgment (`accepted ≥ 60%` / `rejected ≥ 40%` / `invocation count ≥ N`) |
+| 5 | **Self-diagnosis warning reduction** | Quarterly self-diagnosis warnings N items → 1 or fewer |
+
+### Completion checklist derived Decision
+
+- Phase I completion date = earliest date all 5 criteria are met
+- Completion confirmation event = **Phase II entry meeting** (1 separate session, §4 entry condition check)
+- No Phase II output (e.g., external GitHub scan) before Phase I completion — simplification principle violation
+
+---
+
+## 4. Phase II (Frontier Following) — Entry conditions, cadence, outputs
+
+### 4.1 Entry conditions
+
+- Phase I completion 5 criteria **all** met
+- Monthly level snapshot updated 2+ consecutive times
+- §2 current position re-judged as "Phase II · 0%"
+
+### 4.2 Cadence 3-option comparison
+
+| Option | Cycle | Pros | Cons |
+|---|---|---|---|
+| **(a) Quarterly only** | 3 months | Simple | Gap detection delayed 3 months (slow if frontier moves fast) |
+| **(b) Quarterly + monthly light scan** | 3 months + 4 weeks | Gap detection within 1 month + 10 min addition to existing monthly routine (minimum invasive) | (None — recommended) |
+| (c) Trigger-based | When stagnation detected | Resource efficient | Stagnation detection criteria + auto-alerts + trigger tags all require new infra. **Simplification principle violation risk** |
+
+→ **Recommended: (b) quarterly + monthly**. Joining existing monthly routine = minimum invasive. Consistent with simplification principle.
+
+### 4.3 Representative outputs (frame)
+
+| Output | Cycle | Content |
+|---|---|---|
+| **Quarterly frontier diagnosis #N** | 3 months | 6-axis level change vs previous edition + 3-5 new frontier techniques integrated |
+| **Monthly brief** | 4 weeks | 10-min scan of GitHub trending, Anthropic/OpenAI blog, and similar — 3-5 line summary |
+| **External GitHub scan actual operation** | Monthly | Monthly 10-min scan of public repos. Sprint Contract in 5 lines |
+| **Auto gap detection** | Scanner feature addition | Flag "frontier diagnosis not updated > 90 days" |
+
+### 4.4 Completion conditions
+
+- Quarterly re-diagnosis 2 times + monthly brief 6+ consecutive productions
+- 1+ time **own methodology back-referenced from frontier** found
+- 2+ axes in monthly level snapshot sustained as "leading" judgment
+
+---
+
+## 5. Phase III (Frontier Leading) — Entry conditions, 6 indicators, outputs
+
+### 5.1 Entry conditions
+
+- Phase II completion 3 conditions all met
+- 3+ of N self-invented assets **observed as original concepts** for similar industry concepts
+- Public seed repository external contribution record started (at least one of fork/issue/star)
+
+### 5.2 6 Leading indicators
+
+| # | Indicator | Measurement |
+|---|---|---|
+| 1 | Public seed repository record | star/fork/issue count |
+| 2 | Blog/presentation | 2-3 per quarter · 10+ per year |
+| 3 | Industry citation cases | External articles/seminars citing this hub/methodology |
+| 4 | External organization adoption | Other companies/departments |
+| 5 | Self-evolving loop demonstration | Skill generates skills |
+| 6 | Self-invented industry original recognition | Adopted as industry term/frame |
+
+### 5.3 Representative outputs
+
+- **Public seed repository refactor** — from personal seed to collaboratable template. Team customization + common protocol separation
+- **10+ blog/presentations per year** — externalize 1 self-invented asset per quarter
+- **Self-evolving loop MVP** — audit skill proposes own skill generation + user approval → auto-generate → usage observation → deprecate/improve
+
+### 5.4 Phase III has no "completion"
+
+Phase III is an ongoing state. Instead of completion criteria, **3 maintenance conditions**:
+- 3+ of 6 indicators continuously rising
+- "Frontier level maintained" judgment in quarterly re-diagnosis (no regression)
+- Self-diagnosis 8-item checklist failure signal 0 maintained
+
+---
+
+## 6. Common principles for transitions
+
+### 6.1 Consistent simplification principle
+
+Phase transitions are **methodology/abstraction level rises**, not **increases in file/skill/rule count**. At each phase transition, do the following first:
+
+- [ ] Self-diagnosis 8-item checklist check — confirm 0 failure signals
+- [ ] Files unreferenced 6+ months → move to `archive/` or consolidate
+- [ ] Clean up previous phase temporary outputs made unnecessary by new phase entry
+- [ ] Confirm CLAUDE.md and CATALOG within 200 lines
+- [ ] Re-confirm optimization principle: field harness → simpler over time; meta-harness → complexity earns its scope (purge orphaned/redundant/decorative units)
+
+### 6.2 Transition deferred on simplification failure
+
+Above checklist not passed → **phase transition deferred**. Perform previous phase remaining work + simplification work for 1 additional month then re-check.
+
+### 6.3 Phase regression possible
+
+**Regression** from Phase II to Phase I also allowed. E.g., frontier following routine missed 2 consecutive times → "manual re-establishment" re-perform part of Phase I. Do not force linear progression.
+
+---
+
+## 7. This roadmap update cycle
+
+| Trigger | Update content |
+|---|---|
+| Quarterly re-diagnosis | §2 current position re-judgment + §3·§4·§5 criteria change check |
+| Phase transition event | Record corresponding phase completion + initialize next phase progress |
+| Self-invented asset recognized as industry original | §5.1 entry condition counter update |
+| Simplification principle violation detected | §6 transition deferral activation record |
+
+---
+
+## 8. Operating copy writing guide (for template users)
+
+When moving this frame to an operating copy:
+
+1. **Fill §2 current position** — add asset list and basis material paths
+2. **Concretize §3 5 criteria** — add `current` column + `target date` column (e.g., `2026-05-17`)
+3. **Recommend §4.2 cadence (b)** — if adopting other option, need to prove §6.1 simplification gate passed
+4. **Add current counter to §5 6 indicators** — starting from all 0 is natural
+5. **Update §2 at each quarterly re-diagnosis** + record cumulative changes in §7 trigger table
+
+---
+
+## 9. Related assets
+
+- 6-axis framework — `knowledge/shared/harness-core/harness_6axis_framework.md` (frame premise)
+- Monthly level snapshot — `knowledge/shared/harness-core/harness_level_snapshot_*.md` (current position)
+- Quarterly re-diagnosis — `knowledge/shared/harness-core/harness_frontier_diagnosis_*.md` (following basis)
+- Feedback automation — `knowledge/shared/harness-core/hub_compounding_loop.md` (Phase transition gate input)
+
+---
+
+## 10. One-line conclusion
+
+**Phase I completion → Phase II frontier following (b)cadence → Phase III leading. Simplification principle is the common gate for each transition**.

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

@@ -0,0 +1,196 @@
+---
+name: hybrid-orchestration-architecture-roadmap
+description: Proposed (not-yet-implemented) architecture roadmap for fh as an intelligent hybrid orchestration engine — Claude Code as main driver, other CLIs/APIs as runtime-discovered sidecars, with Zero-Config standalone fallback for plugin-only users. Design intent + reconciliation against existing FH assets.
+type: roadmap
+date: 2026-06-09
+status: proposed (design intent — NOT implemented; see §Status & Reconciliation)
+tags: [hybrid-orchestration, sidecar, zero-config, jit-probing, install-wizard, roadmap, proposed]
+---
+
+# Hybrid Orchestration Architecture — Roadmap (Proposed)
+
+> **Status: PROPOSED design intent, not current behavior.** This document captures a
+> forward-looking architecture for fh. Several components it describes — a `config.json`
+> engine-topology file, runtime JIT engine probing, an install-wizard that auto-builds an
+> engine map — **do not exist in FH today**. Read §Status & Reconciliation first to see
+> what is already shipped vs what is aspirational. Nothing here should be cited as a
+> current feature.
+>
+> **Source**: operator design doc (2026-06-09), reconciled to FH conventions on ingest —
+> pinned model versions → `{model-name}` placeholders (per `multi_model_sidecar_strategy.md`
+> §Generalization #4); illustrative pseudo-code marked as such (FH's real layer is markdown
+> methodology + Claude-native automation, not a Python runtime engine).
+
+## 1. Overview
+
+fh aims to be a **hybrid orchestration** harness: **Claude Code as the main driver (core
+controller)**, with third-party CLIs / APIs mapped in as **sidecars** according to whatever
+the user's local environment makes available. The goal is to escape single-model dependency
+and **progressively enhance** output by discovering the user's own resources (subscription
+CLIs, API keys) at runtime — while still working in a fully **Zero-Config** state for users
+who copy only a single plugin/skill rather than installing the whole framework.
+
+This is the design north star. The mechanism for *delegating to sidecars* is already
+validated and shipped (see `multi_model_sidecar_strategy.md`); the *automatic
+discovery/topology* layer below is the proposed addition.
+
+## 2. Model roles (provider-agnostic)
+
+FH convention forbids pinning version numbers or benchmark figures into durable assets
+(they age and become phantom claims), so roles are stated by function, not by pinned model:
+
+| Role | Engine slot | Function | Maps to FH skill family |
+|---|---|---|---|
+| **Core Driver** | `{primary-model}` (strongest available; CC host) | Full code edit, architecture, final synthesis | steel-quench, refactor, design consensus |
+| **Context/Analysis Sidecar** | `{large-context-sidecar}` | Bulk log/API-spec parsing → distilled clues | harvest-loop bulk scan |
+| **Test/Util Sidecar** | `{fast-util-sidecar}` | Boilerplate, unit tests, repetitive drops | speed-run / scaffolding |
+
+> Capability/benchmark comparisons between providers change every release cycle — consult a
+> live source (`/frontier-digest`, or the `claude-api` skill for Claude specifics) at decision
+> time rather than trusting any number frozen into this doc. No SWE-bench figures are recorded
+> here by design.
+
+## 3. Main driver + sidecar dual channel
+
+```
+                 ┌─────────────────────────────┐
+                 │      user terminal (fh)      │
+                 └──────────────┬──────────────┘
+                                │   [intelligent routing]
+            ┌───────────────────┼───────────────────┐
+            ▼ (bulk / low-cost)  ▼ (final reasoning)  ▼ (fast unit-test / repeat)
+   ┌─────────────────┐  ┌──────────────────┐  ┌─────────────────┐
+   │ context sidecar │  │ Claude Code (main)│  │  util sidecar   │
+   └────────┬────────┘  └────────┬─────────┘  └────────┬────────┘
+            └────────────────────┼─────────────────────┘
+                                 ▼
+                   [final quality verification + apply]
+```
+
+- **Claude Code (main)** keeps full project context/architecture and is the only writer of
+  final code. This matches FH's existing rule: *"Host is always single"*
+  (`multi_model_sidecar_strategy.md` §Mechanism).
+- **Sidecars** are stateless one-shot `Bash`-invoked processes whose stdout is folded back in
+  by the calling skill — **already the shipped mechanism**, not new.
+
+## 4. 3-Tier routing protocol (proposed ordering)
+
+When a skill needs a sidecar engine, probe in priority order:
+
+```
+[sidecar request]
+   ├── Tier 1: subscription CLI (zero marginal cost)
+   │            discover logged-in binaries: `claude -p`, `aider`, `gemini`, `codex`, `gh copilot`
+   ├── Tier 2: native API call (pay-per-use)
+   │            env keys: GEMINI_API_KEY, OPENAI_API_KEY, ANTHROPIC_API_KEY
+   └── Tier 3: self-contained sub-agent split (fallback)
+                no external sidecar → Claude Code spawns isolated sub-agent / prompt-chunking
+```
+
+> **Relation to the shipped fallback chain**: `multi_model_sidecar_strategy.md`
+> §Implementation-Patterns already defines a 3-tier *fallback* chain (Copilot CLI → corporate
+> endpoint → direct Gemini/Codex). The ordering here is framed by **cost/access tier** rather
+> than network reachability. These are two lenses on the same fan-out; if implemented, they
+> should be unified into one routing table, not maintained as two competing lists. Tier 3
+> ("Claude internal sub-agent fallback") is the genuinely new contribution — it guarantees the
+> chain never hard-fails even with zero external resources.
+
+## 5. Static inheritance + dynamic JIT fallback (proposed)
+
+```
+execution request (skill / agent)
+        │
+        ▼
+[config.json present?]   ← PROPOSED file; does NOT exist in FH today
+        ├── Yes → static-inheritance mode → load priority map → run immediately
+        └── No  → Zero-Config standalone mode → runtime JIT probing:
+                     1. local subscription CLI scan   (Tier 1)
+                     2. system API-key env scan        (Tier 2)
+                     3. main-driver sub-agent fallback (Tier 3)
+```
+
+**5.1 Static config inheritance** — if an install-wizard run had persisted an engine map,
+skills would adopt it as default and skip per-call scan overhead. *(Proposed: install-wizard
+does not generate such a file today.)*
+
+**5.2 Runtime JIT probing** — if no config exists (or a tool was added after install), the
+harness probes the live environment on-the-fly via the Tier 1→2→3 protocol and binds the best
+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
+`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.
+
+```python
+# ILLUSTRATIVE resolution logic — NOT shipped code.
+# FH's actual layer is markdown methodology + Claude-native automation (skills/rules/hooks),
+# not a Python engine. This sketch only shows the intended decision order.
+def resolve_sidecar_engine(preferred="{util-sidecar}"):
+    cfg = load_static_config_safe()              # Step 1: static config (if any)
+    if cfg and cfg.get("mapped_engine"):
+        return cfg["mapped_engine"]
+    if shutil.which("aider") or shutil.which("{cli}"):   # Tier 1: subscription CLI
+        return "CLI_WRAPPER_MODE"
+    if os.environ.get("{PROVIDER}_API_KEY"):             # Tier 2: API key
+        return "NATIVE_API_MODE"
+    return "CLAUDE_SUBAGENT_FALLBACK"                     # Tier 3: peaceful fallback
+```
+
+## 6. Intelligent install-wizard (proposed extension)
+
+Today `install-wizard` sets up the periodic-audit notification structure (zshrc hook +
+sentinels + session-start mtime detection). It does **not** build an engine topology. The
+proposed extension would add, at install time:
+
+- **Binary probing** — scan `$PATH` for available CLIs/dependencies.
+- **Profile mapping** — write the discovered hybrid config (the proposed `config.json`).
+- **Sanity check** — a light sidecar call to confirm the pipeline actually works.
+
+Onboarding UX phrasing (proposed):
+- Minimal env → *"Configured a Claude-Code-only harness. All skills run safely via context
+  splitting, no API key needed."*
+- Expansion nudge → *"To enable cheaper large-analysis skills, register a sidecar API key later;
+  fh will auto-detect it on the next run and apply sidecar orchestration."*
+
+## 7. sim-conductor & core-skill improvement directions (proposed)
+
+- **7.1 `claude -p` non-interactive pipe runtime** — exploit CC's non-interactive flag; pipe
+  stdout/stdin between agents; reuse session cache via a harness wrapper.
+- **7.2 Hybrid context bridge** — normalize heterogeneous sidecar output (API JSON vs CLI
+  streamed text); embed an extractor (code-block / JSON-structure parser) in a bridge layer so
+  callers always get structured responses regardless of invocation path.
+- **7.3 Built-in sub-agent injection** — for minimal envs with no third-party CLI/API: place
+  worker prompt specs (e.g. `steel-quench-worker.md`, `harvest-loop-worker.md`) into
+  `.claude/agents/`, so the harness spawns Claude's own isolated-context sub-agent pool for
+  parallel work. *(Note: per `operations.md`, personal agents in shared repos should be kept
+  local via `.git/info/exclude` — an installer-placed agent must respect that boundary.)*
+
+---
+
+## Status & Reconciliation (read this before citing anything)
+
+| Component | In FH today? | Where / note |
+|---|---|---|
+| Sidecar delegation via `Bash` (stateless, host-single) | ✅ Shipped + validated | `multi_model_sidecar_strategy.md` (Experiment 1·2) |
+| Cross-provider perspective-diversity rationale | ✅ Shipped | same doc + `steel-quench` Wave 5 |
+| 3-tier *fallback* chain (network-reachability lens) | ✅ Shipped | same doc §Implementation-Patterns |
+| 3-tier *routing* by cost/access (Tier1 CLI→Tier2 API→Tier3 subagent) | 🟡 Partial | reorders the shipped chain; Tier-3 subagent fallback is new |
+| `config.json` engine-topology file | ❌ Proposed | does not exist |
+| Runtime JIT engine probing | ❌ Proposed | does not exist |
+| Zero-Config standalone auto-heal (Mode C) | ❌ Proposed | concept aligns with Mode C in `modes_and_value.md` |
+| install-wizard builds engine topology / sanity-check | ❌ Proposed | install-wizard today = zshrc hook + sentinels only |
+| Hybrid context bridge / built-in sub-agent injection | ❌ Proposed | sim-conductor roadmap item |
+
+**Conflicts resolved on ingest** (per FH conventions): pinned model versions + SWE-bench
+figures dropped → `{model-name}` placeholders (avoids phantom/stale claims); Python
+`engine_resolver.py` marked ILLUSTRATIVE (FH has no Python runtime layer); every non-shipped
+component tagged ❌ Proposed above so this roadmap can never be mistaken for current behavior.
+
+## References
+
+- `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
+- `plugins/fh-meta/skills/frontier-digest/SKILL.md` — live source for current model capability/benchmark comparison (do not freeze numbers here)