@chrono-meta/fh-gate 1.4.41 → 1.4.43

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

@@ -0,0 +1,104 @@
+---
+name: goal-quench-anthropic-issue
+description: Draft Anthropic GitHub issue — native /goal token budget + quality verification hook. Reference for when arXiv number is confirmed.
+type: reference
+date: 2026-05-31
+tags: [goal, anthropic, feature-request, token-budget, quality-gate]
+---
+
+# [Feature Request] /goal — native token budget control + quality verification hook
+
+## Summary
+
+`/goal` is powerful but ships two structural gaps: no token budget enforcement and a binary completion evaluator (Haiku yes/no) with no quality signal. This issue proposes three native flags to close these gaps, with a userspace proof-of-concept as reference.
+
+---
+
+## Problem
+
+### 1. Token explosion with no mid-run intervention
+
+`/goal` runs until Haiku says "done" or context is exhausted. There is no mechanism to:
+- Set a token ceiling before the run
+- Intervene at a percentage threshold (e.g., 80% consumed)
+- Save and checkpoint progress when budget runs low
+
+Real-world symptom: users report running `/goal "finish all of this"`, going to sleep, and waking to a fully exhausted context with no recovery path for incomplete work.
+
+### 2. Completion ≠ quality
+
+Haiku's binary evaluator (`done? yes/no`) checks whether the stated goal condition is satisfied — not whether the output is correct, well-structured, or regression-free.
+
+A session can reach `done = yes` while having introduced bugs, phantom references, or broken existing behavior. There is no hook for a quality gate on the completion verdict.
+
+### 3. No checkpoint / resume
+
+When budget exhaustion forces a stop, there is no structured record of what was completed vs. what remains. The next session starts cold.
+
+---
+
+## Proposed Native Flags
+
+### `--budget <N>`
+
+Enforce a token ceiling for the `/goal` session.
+
+Behavior:
+- At 70% of `N`: surface a warning to the user — "Budget at 70%. Recommend re-prioritizing remaining tasks."
+- At 85% of `N`: pause the session. Prompt: "Budget at 85%. Options: (a) continue / (b) reduce scope / (c) stop and save."
+- At 95% of `N`: force stop. Commit completed work. Output structured summary: `Completed: [...] | Remaining: [...]`
+
+### `--verify <command>`
+
+Run a shell command when Haiku returns `done = yes`. Accept the completion verdict only if the command exits 0.
+
+```bash
+# Example: test suite must pass before /goal accepts "done"
+/goal "all tests pass" --verify "npm test"
+
+# Example: FH quality gate before accepting completion
+/goal "refactor complete" --verify "claude -p 'run pipeline-conductor --quick'"
+```
+
+This separates the concerns that a single evaluator cannot serve simultaneously:
+- **Haiku**: completion detection (fast, cheap, every turn)
+- `--verify` command: quality gate (once, on completion, user-defined)
+
+The same principle that motivated separating the Haiku evaluator from Claude's self-assessment (avoiding cognitive bias) applies here: the completion judge should not also be the quality judge.
+
+### `--checkpoint`
+
+Auto-commit on structured sub-goal boundaries. Requires Haiku to output sub-goal markers (not just yes/no), which is a separate RFC — listed here for completeness.
+
+---
+
+## Reference Implementation
+
+**forge-harness `goal-quench`** implements a userspace version of `--budget` + `--verify` using:
+- Pre-run: `token-budget-gate` skill estimates cost and sets thresholds
+- Mid-run: thresholds injected as session instructions (Claude self-enforces)
+- Post-run: Stop hook detects `/goal` completion → triggers `pipeline-conductor --quick`
+
+Limitations of the userspace approach (why native support is needed):
+- Mid-run token ceiling cannot be hard-enforced without native hook
+- Stop hook cannot invoke Claude recursively (verification triggers on next session, not immediately)
+- Checkpoint requires manual commit — no structured sub-goal output from Haiku
+
+**Paper reference**: forge-harness: A Meta-Harness Engineering Platform for Terminal-Native Claude Code Workflows. Zenodo DOI: 10.5281/zenodo.20397566. arXiv: [pending number].
+
+---
+
+## Adoption signal
+
+`/goal` was introduced in Claude Code Week 20 (2026-05-11), absorbing the community `claude-goal` project (Stop hook implementation) 11 days after OpenAI Codex CLI v0.128.0 shipped a similar feature. Community demand is established. This request addresses the production-readiness gap that community implementations cannot close without native runtime access.
+
+---
+
+## Related issues / PRs
+
+- `claude-goal` (community Stop hook implementation): [link if available]
+- OpenAI Codex CLI `/goal` reference: v0.128.0 release notes
+
+---
+
+*Drafted: 2026-05-31. Submit after arXiv number confirmed.*

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

@@ -0,0 +1,136 @@
+# Harness 6-Axis Framework
+
+> Top-level meta-framework for forge-harness operations. The 6 axes form a decision tree that governs all harness-level work — from initial structure through continuous improvement.
+
+**Core principle (field harness)**: "A good harness gets simpler over time. If it's getting more complex, something is wrong."
+
+**Meta-harness variant**: A good meta-harness *optimizes* over time — complexity is justified when it earns its scope. Red flags: orphaned skills (never invoked), redundant overlap (two skills doing the same thing), decorative structure (exists but doesn't change behavior). Complexity itself is not the warning signal.
+
+**Completeness model (frame-wise ultimate)**: A harness is never *finally* complete — it is **frame-wise ultimate**. A *frame* is the scope one verification cycle can currently see: per-asset, an edit-manifest RECORD (Axis 3) → verify (Axis 5) cycle; for FH-as-a-whole, a release/version milestone (cf. a model's knowledge cutoff = its release frame's timestamp). A frame is *closed* — ultimate **for that frame** — when every **visible** gap is resolved or **named**: a named gap is evidence the frame closed (you saw the edge), not evidence against it; the only signal of incompleteness is an **un-named** gap. This reframes the existing completion-claim discipline (Axis 5 before "done", residuals declared) — growth is not the opposite of completeness but its **ladder**: Axis 6 carries one frame's closure into the next frame's baseline. **Two guards keep this honest, not self-congratulatory:** (1) never declare a frame closed before the gap-surfacing pass (Axis 5) has run — premature closure (e.g. "downloads ≠ validated usage"); (2) the verdict "are all *visible* gaps named?" is **judged, so it is adversarially paired** (Axis 5's challenger, or an external sister-GT) — never self-asserted, because an un-named gap is invisible *to the self-judge by construction*; only a non-self pass expands what is visible (mechanical-anchor / Non-Model-Ground principle, §Scope Hierarchy's no-self-commit kin). An *irreducible* gap (visible but unclosable — e.g. the 4-axis gate's autonomous-runner self-verification residual, documented honest in CLAUDE.md §FH 4-Axis Gate) closes its frame **at the ceiling**; the next frame opens only when a new capability changes what is visible.
+
+---
+
+## The 6 Axes
+
+| Axis | Name | Question it answers |
+|:---:|---|---|
+| **1** | **Structure** | Where does this work live? (hub vs. project, rules vs. skills, knowledge vs. tracks) |
+| **2** | **Context** | What does the AI need to know before starting? (session card, CATALOG, relevant docs) |
+| **3** | **Plan** | What is the intended change and its predicted impact? (edit-manifest RECORD) |
+| **4** | **Execute** | What is the minimal, reversible action? (direct edit, agent dispatch, parallel dispatch) |
+| **5** | **Verify** | Did the change do what was predicted? (regression guard, adversarial, source-grounding) |
+| **6** | **Improve** | What pattern is worth keeping? (harvest-loop, field-harvest, compounding loop) |
+
+---
+
+## Decision Tree (Condensed)
+
+```
+New work arrives
+    │
+    ▼ Axis 1 — Structure
+    Where does this live?
+    ├── Hub meta (rules/skills/templates) → FH 4-axis auto-gate applies
+    ├── Field project → route via Agent dispatch or direct edit
+    └── Cross-project knowledge → knowledge/shared/
+
+    ▼ Axis 2 — Context
+    What must the AI know?
+    ├── Read session_card (reference_next_session_starter.md)
+    ├── Read CATALOG.md → candidate files only
+    └── Load LOCAL_SKILL_REGISTRY if cross-project dispatch
+
+    ▼ Axis 3 — Plan
+    What will change?
+    └── edit-manifest RECORD entry: branch, change, predicted_impact, verify_next
+
+    ▼ Axis 4 — Execute
+    Minimum viable action:
+    ├── Direct edit (simple, known file, absolute path)
+    ├── Single Agent dispatch (field task, one project)
+    └── Parallel Agent dispatch (2+ independent tasks — no asking, just dispatch)
+
+    ▼ Axis 5 — Verify
+    Did it work?
+    ├── Axis 1 (backward): regression_guard.sh
+    ├── Axis 2 (adversarial): steel-quench
+    ├── Axis 3 (forward): phantom-quench
+    ├── Axis 4 (record): confirm edit-manifest entry exists
+    └── Before claiming "done": attach (a) evidence (b) failure-checks run
+        (c) residual risk — bare "completed" does not pass (see Completion-claim discipline)
+
+    ▼ Axis 6 — Improve
+    Worth keeping as a pattern?
+    ├── 3+ repeats → skill-candidate tag → field-harvest
+    ├── Session end → harvest-loop (weekly cycle)
+    └── Compounding: hub_compounding_loop.md
+```
+
+---
+
+## Axis 5 — FH 4-Axis Verification Gate (detail)
+
+Applies automatically when any FH asset is modified (SKILL.md, rules, templates, CLAUDE.md, substantive knowledge/ docs).
+
+| Gate axis | Tool | Class | What it catches |
+|---|---|---|---|
+| **Backward** | `regression_guard.sh` | mandatory-pass | Critical section loss, broken refs, syntax errors, line reduction |
+| **Adversarial** | `steel-quench` | judged | Trigger phrase collisions, design attack surface, over-engineered steps |
+| **Forward** | `phantom-quench` | judged | Phantom references, paths that don't exist, stale external links |
+| **Record** | `edit-manifest RECORD` | mandatory-pass | Logs predicted impact — closes the predict-verify loop |
+
+**Check classes**: every verify check is one of three classes — **mandatory-pass**
+(deterministic; blocks on fail), **measured** (quantitative; tracked, not blocking alone —
+e.g. `token-budget-gate`, goal-quench calibration), **judged** (LLM-judge emitting verdict +
+cited evidence + a corrective action — a judge score without a fix path is unactionable, and
+self-judges grade leniently). **Judged rule**: a judge verdict alone never passes — it must be
+paired with adversarial re-verification (`steel-quench` / `verify-bidirectional`), and its
+cited evidence is itself subject to `phantom-quench`. (Taxonomy adapted from external
+supervisor-loop discourse, 2026-06; FH adds the judged-pairing rule and evidence
+re-verification, which the source leaves open.)
+
+**Completion-claim discipline** (judged-class sharpening): a "done" / "passed" claim is itself a judged
+verdict and must carry three things, not just an assertion — **(a) an evidence artifact** (the output,
+diff, or run that shows it), **(b) the enumerated failure-checks actually run** (which negative cases
+were tested, not only that it "works"), and **(c) the explicit residual risk** (what could still be
+wrong). A bare "completed" with none of these is an ungrounded judge verdict and does not pass. Each of
+(a)–(c) must be **non-vacuous** — a named artifact, an enumerated case list, and a specific risk; "it
+works" / "tested" / "none known" are vacuous fills and fail the discipline (same non-vacuity bar as the
+CLAUDE.md §marker rule: a recorded verdict/count, not "it ran"). Bounded scope: (b) means the negative
+cases you *actually ran*, not all conceivable ones; (c) means the one or two risks you can name now, not
+an exhaustive proof of safety. Applies to every skill's Done When and to `goal-quench` /
+`pipeline-conductor` completion gates. (Harvested as independent-convergence reinforcement from sister
+assets — oh-my-claudecode "Ralph" Done-When + book/19689's verification-before-completion-claim theme;
+cross-audit `tracks/_audit/session_2026_06_14_wikidocs-deep-sweep.md`.)
+
+**Hard gate**: git pre-commit hook (`templates/.git-hooks/pre-commit`) blocks commit until marker + manifest entry exist.
+
+**Lightweight exception** (Axis 1 + 4 only): sessions where zero SKILL.md/rules/templates files changed.
+
+---
+
+## Scope Hierarchy
+
+```
+Hub common principles (CLAUDE.md)
+    └── Project CLAUDE.md
+            └── Domain session rules (.claude/rules/session.md)
+```
+
+Lower levels cannot override higher. AI contribution → PR proposal only (no direct commit to shared repos without explicit user approval).
+
+---
+
+## Related
+
+- `harness_design_decision_lens.md` — orthogonal companion: the 7 architectural-bet decisions (which design point at Axis 1 / Axis 4) + default-bias checklist + scaffolding-removal method
+- `crucible_mode.md` — total-immersion absorption stance: chains Axis 5 (the melt) + Axis 6 (the rebirth) with an unmeltable identity core; used when a whole corpus on a core FH axis is absorbed
+- `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
+
+**External sibling (independent convergence)**
+
+- arXiv:2603.25723 (*Natural-Language Agent Harnesses*, NLAH) — external academic sibling that independently converges on the same core thesis: a harness control layer can be an executable natural-language object, not code. NLAH measures the natural-language-harness form empirically; FH governs and compounds it.
+- arXiv:2606.06324 (*HarnessFix / ETCLOVG*, 2026-06) — sibling on the **orthogonal** axis: where NLAH and FH describe the harness as a *process/control* object, HarnessFix supplies a *component taxonomy* of what a deployed harness contains (7 layers — Execution · Tooling · Context · Lifecycle · Observability · Verification · Governance). Its **V layer maps onto FH's Axis-5 gate on 3 of its 4 functions** (intermediate validation → steel/phantom-quench · final-output eval → completion-claim discipline · regression testing → regression_guard); its *readiness-check* function maps to FH pre-flight gates (install-doctor / asset-placement-gate) that sit outside Axis-5. Its named **Observability** layer is a structural axis FH lacks — FH's nearest coverage is *retrospective audit* (weekly_audit, subagent_invocations_log), not runtime observability (import candidate for `harness-doctor`). Cross-audit: `tracks/_audit/session_2026_06_19_harnessfix-etclovg-cross-audit.md`.

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

@@ -0,0 +1,108 @@
+# Harness Design-Decision Lens
+
+> A complement to `harness_6axis_framework.md`. The 6-axis framework is a **lifecycle** decomposition —
+> it answers *when, in the flow of a piece of work*, each concern applies (structure → context → plan →
+> execute → verify → improve). This lens is **orthogonal**: it answers *which architectural bet to place*
+> at Axis 1 (Structure) and Axis 4 (Execute), where the 6-axis tree says "route it" but not "which design
+> point." Use the two together — the 6-axis says *which stage*; this lens says *which trade-off setting*.
+>
+> **Open this doc when** you are about to add agents, tools, permissions, or harness thickness — or when
+> the 6-axis tree says "route it" (Axis 1 / Axis 4) but not *which way*. For lifecycle questions (what
+> stage am I in, what must I verify), stay in the 6-axis framework.
+
+**Provenance (independent-convergence harvest — not clone-and-own):** the decision-table framing was
+harvested from the sister asset `wikidocs.net/book/19689` 「하네스 엔지니어링 백과사전」 Ch12 (governor
+source-closed 2026-06-14; cross-audit `tracks/_audit/session_2026_06_14_wikidocs-deep-sweep.md`). **The
+single net-new increment from the harvest is the orthogonal-bets *framing* itself** — presenting harness
+architecture as ~7 trade-off axes set against the 6-axis lifecycle. The governor source-close ruled the
+individual decisions, the contrarian checklist, and the scaffolding-removal method **ALREADY-HAVE** (FH
+embodies them — see column 3 and the `measured`/judged check classes). They are reproduced below only to
+make the already-placed bets *explicit and operational in one place*, not as novel imports. Where this
+doc restates an existing FH principle, it says so.
+
+---
+
+## The seven decisions (architectural bets)
+
+Each is a spectrum, not a right answer. The third column names the FH asset that already embodies the
+bet — so this is a *map of bets FH is already placing*, made explicit, plus the two FH was placing only
+implicitly (agent-count, reasoning-strategy).
+
+| Decision | Spectrum | Where FH already places the bet | "Which point, when" |
+|---|---|---|---|
+| **Agent count** | single ↔ multi-agent | `agent-composer` (single vs parallel dispatch) | Single by default; split only on genuinely independent sub-tasks (agent-composer's per-wave fan-out cap, ≤4). Isolation cost rises with agent count. |
+| **Reasoning strategy** | ReAct (think each step) ↔ plan-then-execute | 6-axis Axis 3 (Plan) → Axis 4 (Execute); `goal-quench` decomposition | Plan-then-execute for parallelizable / known work; ReAct for genuinely exploratory steps. |
+| **Context strategy** | strong compression ↔ rich context | `context-doctor`, compact-before-saturation reflex, layered memory (MEMORY.md index / `memory/*.md` keyword-load / `tracks/` archive) | Compress on long sessions; keep rich context where verification needs the evidence intact (phantom-quench tension). |
+| **Verification** | computational ↔ judged | check-class taxonomy: mandatory-pass / measured / **judged** (`harness_6axis_framework.md` Axis 5) | Prefer computational anchors; a judged verdict never passes alone (judge-robustness rule). |
+| **Permissions** | permissive ↔ restrictive | `mcp_tool_gating` allow / ask / deny; Destructive-Op + Pre-Publish gates | Restrictive on irreversible / external-facing actions; permissive on reversible local work. |
+| **Tool scope** | all tools always ↔ staged minimal | ToolSearch (deferred-tool fetch), `mcp_tool_gating` | Stage tools in; broad always-on exposure degrades selection accuracy. (Vercel measured 17 specialized tools → 80% success vs 2 general-purpose tools → 100%, at lower token + latency: "We removed 80% of our agent's tools", vercel.com/blog/we-removed-80-percent-of-our-agents-tools, accessed 2026-06-14.) |
+| **Harness thickness** | thin (trust model) ↔ thick (control by code/rules) | field principle "simpler over time" vs meta principle "complexity earns its scope" (`harness_6axis_framework.md` Core principle) | FH already holds a *more nuanced* field-vs-meta split than a single thin/thick dial. Thicker buys predictability but encodes "things the model can't do" — assumptions that age as the model improves (design intuition, not a benchmarked claim). |
+
+The decisions are **not independent**: more agents raises the cost of context isolation + verification;
+always-on tools raises the stakes of permission design; a thicker harness raises the carrying cost of
+stale assumptions.
+
+**Orthogonality is partial, not total.** Two of the seven bets — *reasoning strategy* and *verification* —
+are placed *at* a 6-axis stage (Axis 3→4 for reasoning, Axis 5 for verification), so for those the lens
+and the lifecycle touch rather than run perpendicular. The lens is still the right tool for "which setting"
+(plan-vs-ReAct, computational-vs-judged); the 6-axis is the right tool for "at which stage." The orthogonal
+claim holds strongly for the other five bets and loosely for these two.
+
+---
+
+## Default-bias checklist (the contrarian inversions)
+
+> *Already-embodied (governor: ALREADY-HAVE) — restated here as a one-place design-time pass, not a novel
+> import. FH already runs these instincts through `steel-quench` and the meta-harness red-flag scan.*
+
+Four intuitions that feel right while building and fail in operation. Run this as a quick adversarial
+pass on any harness design (it is the design-time analogue of `steel-quench`'s attack lenses):
+
+1. **"More tools = more capable."** Often false — broad tool exposure hurts selection accuracy. Prefer
+   staged, single-purpose tools over a wide general surface.
+2. **"Reason at every step (ReAct always)."** Often false — for parallelizable / known work,
+   plan-then-execute is faster and cheaper.
+3. **"Broader permissions = faster."** False under operations — the cost lands as irreversible mistakes,
+   not saved time. Gate the irreversible.
+4. **"Thicker harness = safer."** True short-term, debt long-term — a thick harness encodes "things the
+   model can't do," and those assumptions age. Safety that does not get revisited becomes a burden.
+
+---
+
+## Scaffolding-removal method (operationalizes "simpler over time")
+
+> *The principle is already FH's (governor: ALREADY-HAVE — 6-axis core principle). What is operationalized
+> here is the **method** the principle left unstated, consistent with FH's `measured` check class.*
+
+FH's core principle states the *goal* — "a good harness gets simpler over time" — but not the *method*.
+A testable one, consistent with FH's verification identity:
+
+> **Remove scaffolding one piece at a time, and compare.** When simplifying, ablate a single support at a
+> time and check what actually holds quality before removing the next. Removing several at once loses the
+> signal of which support was load-bearing.
+
+This is the disciplined form of the meta-harness red-flag scan (orphaned / redundant / decorative units):
+do not bulk-delete suspected-decorative structure — ablate-one, measure, then proceed. It pairs with the
+`measured` check class (the comparison is the measurement).
+
+---
+
+## How it plugs into the 6-axis flow
+
+- **Axis 1 (Structure)** — when deciding where work lives and how it is shaped, consult the seven
+  decisions for the architectural bet, and the default-bias checklist before committing to "more"
+  (agents, tools, permissions, thickness).
+- **Axis 4 (Execute)** — the agent-count and reasoning-strategy decisions set the dispatch shape
+  (direct / single agent / parallel) the 6-axis tree otherwise leaves to habit.
+- **Axis 6 (Improve)** — apply the scaffolding-removal method when the simplification principle fires.
+
+**Check class:** this doc is a *judged* design aid (it informs human/AI design choices, it does not gate
+mechanically). Its adversarial pairing is the default-bias checklist above + `steel-quench` on any design
+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

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)