@chrono-meta/fh-gate 1.4.73 → 1.4.75

package/.claude-plugin/marketplace.json

@@ -11,13 +11,13 @@
   "plugins": [
     {
       "name": "fh-meta",
-      "version": "1.4.73",
+      "version": "1.4.75",
       "description": "Hub meta-operations toolkit — 35 skills + 7 agents. New in 1.4.53: `fh-codex-doctor` (npm bin) — Codex adapter drift scanner; reads the documented M1/M2/M3 skill tier map + skill/agent source and reports codex-native/adapter-required/claude-native/unclassified per unit, wired into `npm test`/`prepublishOnly` (fail-closed on unclassified Claude-native primitives). New in 1.4.49: steel-quench gains Step 0.6 Verdict-Invariance Probe (groundedness axis — a load-bearing judged gate's verdict must track behavior, not rubric phrasing; measured flip-count over cross-family paraphrases; arXiv:2605.06161 Policy Invariance anchor); multi_model_sidecar_strategy §Vendor-native harness (a model is strongest in its own vendor CLI — Claude/CC, GPT/codex, Gemini/Antigravity; a universal router degrades all of them, so it stays an autocomplete/QA sidecar, never orchestration); predelete_check.sh fail-closed rewrite; memory-hygiene A-TMA anchor. New in 1.4.48: phantom-quench + steel-quench gain external frontier anchors (arXiv:2607.02052 package-hallucination; arXiv:2607.02057 prompt-coverage-adequacy); README model-flat claim reframed from a per-release point-curve to structural invariants (operation flattens across tiers; depth tier-order fixed within a generation). New in 1.4.47: onboarding step ① surfaces the Mode D companion-store session-start load in the auto-read salience anchor (previously only in the local binding + rules, so a greeting could skip the load). New in 1.4.46: context-doctor command-output axis (route to rtk/proxy for verbose CLI stdout, complementing .claudeignore; risk-gated to token-scarce envs). New in 1.4.41: context-doctor 2026 trigger vocab (context engineering/rot/collapse) + phantom-citation hardening; hub measurement-integrity-checklist (cross-model measurement pre-flight: display-name pin/reps≥3/discriminating probe). New in 1.4.40: install-wizard queryable-wiki scaffold (INDEX + session-start read + R/W/C ingest). New in 1.4.39: auto-decorrelation (cross-family verifier sidecar recruitment) + video-ingest (capability-routed video ingestion). New in 1.4.x: verify-axis check-class taxonomy (mandatory-pass/measured/judged), no-reinvention Tier-0 inventory, 7-class failure taxonomy, Destructive-Op Gate, Wave-T (Temper), tier-floor governance, Mode D Model Notice, FC consent lane, default-Sonnet guidance. New in 1.3.0: public-surface-audit, field-harvest Mode B auto-trigger, 4-axis gate scope ext. Validated cross-CLI: Claude Code, Codex, Gemini.",
       "source": "./plugins/fh-meta"
     },
     {
       "name": "fh-commons",
-      "version": "1.4.73",
+      "version": "1.4.75",
       "description": "Project-agnostic utility skills — 4 skills (convergence-loop · deliberation · mcp-circuit-breaker · token-budget-gate) + 1 agent (quench-challenger). Domain-independent utilities transplantable into any project.",
       "source": "./plugins/fh-commons"
     }

package/CHEATSHEET.md

@@ -497,7 +497,7 @@ Claude agents feature
 | `asset-placement-gate` | Routes a new skill/agent/plugin to the right place (hub vs project), no role overlap | "where does this go", "should this be shared", "hub or project" |
 | `marketplace-gate` | Scores a repo against 5 listing criteria (README, zero-config, maintenance, dup, safety) | "is this OK to publish", "ready for the marketplace", "pre-publish check" |
 | `public-surface-audit` | Scans git-tracked files for operator-private tokens (real username, corp names, home paths) | "did I leak anything", "scan for private tokens", "is my split clean" |
-| `self-marketing-lint` | Flags self-promotional / hype wording in descriptions (plain-text discipline) | "lint the marketing language", "is this description hyped" |
+| `harness-doctor --lint` | Flags self-promotional / hype wording in descriptions (plain-text discipline) | "lint the marketing language", "is this description hyped" |
 
 > **Going public?** Don't run these one at a time — say **"publish"** / **"make this repo public"** and Claude
 > fires the **Pre-Publish Surface Gate** (CLAUDE.md), which runs `public-surface-audit` + `marketplace-gate`

package/CLAUDE.md

@@ -695,7 +695,10 @@ Closing phrase detected ("wrap up", "done", "good work", "end session", etc.)
        **(b) flag the matching card carry item resolved for ⑤** — ⑤ owns the card write (card-last
        guard), ④-c never edits the card. **First-run no-op** if no matching handoff/carry exists.
        (Why-its-own-step origin + ownership split + salience/backstops → §detail below.)
-  → ⑤ Card update ← ABSOLUTE LAST: must capture ①–④-c outcomes
+  → ⑤ **Log-close + card update, in that internal order** ← ABSOLUTE LAST: must capture ①–④-c
+       outcomes. ⑤ is ATOMIC and owns BOTH writes: (a) append any close-time finding to
+       `fh_completed_{date}.md` FIRST, (b) then write the card. Once ⑤ starts, `fh_completed`
+       is CLOSED — a later append re-opens the violation ⑤ exists to prevent.
   → ⑥ Commit card + push
 ```
 
@@ -709,6 +712,16 @@ Closing phrase detected ("wrap up", "done", "good work", "end session", etc.)
 new findings, a carry item flipped to DONE) feeds INTO ⑤ — card is never written mid-sequence and
 then left open for more work to accumulate after it.
 
+**Why ⑤ became atomic (N=3, 2026-07-28 — three closes in one day)**: the miss was always the same
+shape — a finding surfaced *during* the close and the reflex appended it to `fh_completed`, which is
+correct under ④ and fatal after ⑤. The three prose repairs ("next time write it into the card first")
+all failed, including one session that stated the vow and then broke it in the same close. So the
+sequence is restructured rather than re-promised: `fh_completed` is not a step that runs alongside ⑤,
+it is the **first half of** ⑤. A close-time finding has exactly one landing order — log, then card —
+and there is no remaining moment where appending is the natural move. *Honest scope*: this removes
+the ordering ambiguity, not the reflex; the pre-push gate stays the floor, and on a violation it now
+**names the offending files and prints their last lines** so re-running ⑤ is a delta, not a re-read.
+
 **Mid-session card writes are drafts**: If a task (e.g., a calibration run) internally updates
 the card, that is a draft. The close chain always re-runs ⑤ to capture post-draft activities.
 Never skip ⑤ because "the card was just updated" — check for delta first.

package/docs/ETHOS.md

@@ -0,0 +1,106 @@
+# ETHOS — what forge-harness believes
+
+> The compressed identity. Six named principles that travel as quotable units.
+> For *what it is* see [`README.md`](../README.md); for *why it exists* see [`WHY.md`](WHY.md);
+> for the *evidence* see [`OUTPUT_EVIDENCE.md`](OUTPUT_EVIDENCE.md).
+
+forge-harness (FH) is a **quality-harness**: a practitioner's meta-harness for Claude Code that
+optimizes for *whether the work holds up*, not how fast it leaves the building. Where a speed-harness
+asks "how quickly can the agent ship?", FH asks "what survives a cold, independent pass?" — and makes
+running that pass routine instead of a chore you skip.
+
+Everything below is **copyable**. None of it is a secret. The principles are the product.
+
+---
+
+## The forge
+
+FH treats a project like steel — heat, shape, and shock, in named movements. The metaphor is literal,
+not decoration:
+
+| Movement | What it does | Today |
+|---|---|---|
+| **Forge** | shape the raw project into a harness — raise its floor | `install-wizard`, harness-ify |
+| **Quench** | harden it by attack — the cold pass leaves standing only what is sound | `steel-quench`, `phantom-quench` |
+| **Temper** | take the brittleness back out of the hardened asset | `steel-quench` **Wave-T** + `templates/temper_check.sh` |
+| → **Accelerate** | a blade that survived the forge cuts faster — pass, then run | `goal-quench` · *Pass → Accelerate* |
+
+All four movements now ship. **Temper** spent its first months named-but-unbuilt — deliberately, per
+principle 5 — and shipped only after measurement runs on independent quench convergences validated that
+the check flags over-hardening without punishing simplification. Quenched steel is hard but brittle;
+no smith ships it un-tempered, and now neither does FH: after convergence, Wave-T measures the complexity
+the quench itself added and hands over-built constructs back for de-brittling.
+
+---
+
+## 1. Pass → Accelerate
+
+The gate is not friction to be tolerated; **surviving it is the speedup.** A project that has passed the
+quench can be moved on with confidence — and that confidence, not a skipped step, is what acceleration
+actually is.
+
+> *Forge your projects, pass them through — they come out faster.*
+
+## 2. The cold reviewer
+
+After a long co-authoring session, you and your AI share the same context — and the same blind spots.
+The reviewer worth having is the one who **never saw your reasoning**. You can get that by hand: paste
+the work into a fresh, empty chat. FH turns that chore into one routine command (`steel-quench`,
+`phantom-quench`, sidecar dispatch).
+
+This is **de-bias, not detection.** FH adds no detection engine — a plain prompt to a fresh model does
+much of the same. What FH removes is the *positive bias of self-review*, by separating context. It is
+symmetric across models: whoever sat outside the collaboration is your cold reviewer, not whichever
+model ranks higher.
+
+> *The reviewer worth having is the one who never saw your reasoning.*
+
+## 3. Utility, not moat
+
+The methodology is copyable; what FH packages is the **workflow, not a secret sauce.** Its value is
+narrow and honest: coverage of standpoints, plus a method that makes running them routine. There is no
+cognitive moat here to defend, and FH does not pretend otherwise.
+
+> *Fork it. Rename it. Make it yours.*
+
+## 4. Value = f(task demand)
+
+FH's techniques scale with what the task requires. Isolation pays off in proportion to how much you
+co-developed the artifact; separation pays off in proportion to your integrity target. On a trivial task
+the gain is negligible — and **saying so is part of the method.** On a demanding, deeply co-authored one
+it is essential. It is never absolute: there is no perfect integrity, only a closer asymptote. Knowing
+when *not* to reach for the harness is as much the ethos as knowing when to.
+
+> *Run the cold pass when the stakes earn it — not as a ritual.*
+
+## 5. Claims earn their words
+
+Stock phrases — "isolated", "unique", "unrivaled", "guaranteed" — smuggle strong dictionary claims past
+a warm reader who fills in charitable meaning. Every claim FH makes must survive a **cold, literal
+reading**: would it still be true to someone who refuses to be generous? FH lints its own language for
+this, and corrects itself when a phrase claims more than the evidence carries.
+
+> *A claim that only survives a charitable reading is not yet true.*
+
+## 6. A harness is a means, not an end
+
+For a *field* harness, the target is to get **simpler over time** — rising complexity is a warning
+signal. For a *meta*-harness like FH, the target is to *optimize*, not necessarily simplify: complexity
+earns its place when it earns its scope. The red flags are not size but **orphaned, redundant, and
+decorative** units. Every improvement ships with its own verification circuit (backward / adversarial /
+forward), so the harness audits itself and the learnings compound session over session.
+
+> *Complexity must earn its scope; the rest is debt.*
+
+---
+
+## What FH does not claim
+
+- It is **not** a detection engine, an accuracy multiplier, or a model ranking. The cold pass is your
+  base model's own ability, surfaced by isolation.
+- It is **not** a moat. The methodology travels; copying it is the intended outcome, not a leak.
+- It gates for **correctness** — does the work hold up — which is distinct from a security scan.
+- Its empirical results are **worked examples, not benchmarks.** The gain is an empirical, per-task
+  question, and an isolated reviewer also adds false positives you must triage.
+
+The honesty is not a disclaimer bolted on at the end. It *is* the positioning.

package/docs/OUTPUT_EVIDENCE.md

@@ -0,0 +1,118 @@
+# OUTPUT EVIDENCE — what forge-harness has produced
+
+> A compact, verifiable evidence packet. Counts are reproducible from the repo (commands at the bottom).
+> This is **not** an adoption claim — forge-harness is young and built in the open. The honest reading is
+> *volume + external artifacts*, not *proven longevity*. See [`ETHOS.md`](ETHOS.md) §"What FH does not claim".
+
+## Built (in the repo, today)
+
+| What | Count | Notes |
+|---|---:|---|
+| Active skills | **33** | 29 in `fh-meta` + 4 in `fh-commons`; 3 deprecated redirect stubs not counted |
+| Agent definitions | **8** | `challenger`, `quench-challenger`, `fact-checker`, `hub-persona-auditor`, `persona-innovator`, `beginner`, `main-player`, `expert` |
+| Operating rules | **6** | `.claude/rules/*.md` — mapping, modes, sync, sister-asset, operations |
+| Knowledge docs | **23** | `knowledge/` — 6-axis framework, compounding loop, runtime flow, dialogue playbook |
+| Plugins | **2** | `fh-meta` (meta-harness) + `fh-commons` (project-agnostic) |
+| Self-gate | **1** | 4-axis pre-commit hook (backward / adversarial / forward / record) |
+
+## Pace (built in the open)
+
+| Metric | Value |
+|---|---|
+| First commit → latest | **2026-05-26 → 2026-06-06** (12 days) |
+| Commits | **224** |
+| Merged PRs | **66** |
+
+> Read honestly: this is *velocity*, not *maturity*. A 12-day-old project is early. The point is that the
+> compounding loop and self-gate were exercised on the harness's own development, not just described.
+
+## External artifacts (verifiable links)
+
+| Artifact | Reference |
+|---|---|
+| Paper (v1.0) | Zenodo DOI [`10.5281/zenodo.20397566`](https://zenodo.org/records/20397566) — arXiv in review |
+| Package | npm [`@chrono-meta/fh-gate`](https://www.npmjs.com/package/@chrono-meta/fh-gate) — multi-backend governance gate (claude · codex · auto) |
+| Codex-compatible beta | `docs/codex-compat.md` — methodology layer runs model-agnostic |
+
+## Validation signals (worked examples, not benchmarks)
+
+- **Governance gate, real code** (2026-05-31): applied `fh-gate` to OpenCode's AI-generated
+  `permission/arity.ts` (163 lines, CI green). Gate verdict: **BLOCKED** — 2 A-grade findings CI did not
+  catch (short-token overflow in allowlist; executor tools absent from arity table).
+- **Cold-pass controlled experiments**: the `steel-quench` / `phantom-quench` isolation method was tested
+  under controlled conditions (design-defense, semantic-phantom corpora). Treated as **worked examples** —
+  the gain is an empirical, per-task question, and isolated reviewers add false positives to triage.
+- **External contribution**: filed gstack issue #1890 (subscription-auth bug) — the harness's own
+  cross-audit protocol surfacing a real bug in a sister project.
+- **Frontier cadence sustained**: digests on 2026-05-26 and 2026-06-02 (recurring external-trend scan).
+- **Model-tier flattening, measured** (2026-06-10): a 30-point blind battery — rule-application
+  ("operating FH": trap routing, gate-class decisions, sync format) + meta-dev fixtures with known ground
+  truth — run on four Claude tiers. Operation scores: top-tier anchor / Opus 4.8 / Sonnet 4.6 / Haiku 4.5
+  = **100 / 100 / 97 / 94**. With the rules in context, *operating* the harness is nearly model-flat;
+  tier differences appeared only in above-rubric design increments (3/3 · 1/3 · 0.5/3 · 0/3) — i.e. in
+  *developing* the harness, not running it. Single trial per model, pre-registered rubric, self-graded —
+  a worked example, not a benchmark.
+- **Model-tier flattening — Sonnet 5 replication** (2026-07-03): the same 구동 (rule-application)
+  battery, re-anchored on all three current tiers in one session — Opus 4.8 / **Sonnet 5** / Haiku 4.5
+  each scored **16/16**; both traps and both gate-class carve-out directions passed on every tier.
+  Sonnet 5 ties Opus 4.8 on operation, supporting the Sonnet-default doctrine. Honest caveat: the battery
+  **ceilinged** this run (Haiku 4.5 also 16/16, up from 15/16 on 2026-06-10) because the CATALOG format
+  rule was supplied in-prompt, removing the format-discipline nit that separated tiers before — so this
+  confirms parity-at-ceiling, it does **not** re-measure a tier spread. The tier-separating axis is
+  above-rubric design depth (not run here — and, by the two structural laws in README §Model setup,
+  same-generation tier order there is fixed by design, not something a replication needs to re-confirm).
+  Measurement-integrity items applied: display-name pin (partial — Agent-tool binding, family-
+  discriminated self-report), reps≥3 (not triggered — zero borderline verdicts), discriminating-probe
+  (failed at instrument level — ceiling — flagged, not hidden). Single-session, pre-registered rubric.
+- **Guard-axis before/after, measured** (2026-06-24): the same task was given to a bare agent and an
+  FH-gated agent (same FH gate rule injected as context), reps=5 each, across two irreversible surfaces.
+  On log cleanup (Destructive-Op Gate) the bare arm deletes on first run — 0/5 safe-default — while the
+  FH arm enumerates and dry-runs by default, 5/5. On npm publish (Pre-Publish Surface Gate) the bare arm
+  never scans the ship surface for secrets — 0/5 — while the FH arm scrubs, dry-runs, then requires
+  explicit confirmation, 5/5. The over-build half of the hypothesis (would the bare arm reinvent the
+  stdlib?) came back **null** — both arms used the stdlib cleanly — and is reported, not hidden. The
+  measured delta is the *default on the irreversible action*. Visual + data:
+  [`docs/before-after/`](before-after/render.png). Pre-registered rubric, isolated-agent reps=5, a worked
+  example not a benchmark.
+
+## Real-world incidents the gates target (2026-07-03)
+
+The controlled before/after above uses synthetic tasks. Three independently reported 2026
+incidents show the same irreversible surfaces failing in production. Each maps to a gate FH already
+ships — with an honest note on how much the gate would have caught.
+
+| Incident (source) | Surface | FH gate | Would it have caught it? |
+|---|---|---|---|
+| A Cursor/Opus agent wiped a production DB + 3 months of backups via an unscoped Railway `volumeDelete`, having guessed the call was staging-scoped (PocketOS, [Decrypt](https://decrypt.co/365897/ai-agent-deletes-startup-database-9-seconds-founder-says)) | Destructive op (delete) | **Destructive-Op Gate** — `enumerate → recover → destroy` | **Partial.** The gate's order invariant is exactly this failure: destroy-then-discover instead of enumerate-first. The agent skipped the enumerate step (never checked whether the volume was shared across environments) and had no recover step (backups on the same volume). FH's *mechanical* floor (`pre-push` hook) covers only git-surface deletes/force-push — a Railway GraphQL `volumeDelete` is not a git op, so the catch here is the **prose** enumerate→recover discipline, not a hook. Same un-hookable-surface honesty FH already states for the separate-repo publish surface. |
+| An agent autonomously provisioned 5 high-bandwidth AWS instances (duplicate instances + load balancers, no human review), running up ~$6,531 in 24h ([lantian.pub](https://lantian.pub/en/article/fun/ai-agent-bankrupted-their-operator-scan-dn42lantian.lantian/)) | Cost irreversibility | **Shared spine** (irreversible surface → fail-closed, human-in-loop) | **Partial / gap.** This is runaway *spend*, not delete-or-publish, so no single named FH gate targets it directly — the Destructive-Op Gate covers deletion/rewrite, and `token-budget-gate`/`goal-quench` estimate token cost, not cloud spend. What applies is the shared **propose-before-expensive-action** principle. Reported as a gap the incident motivates, not a clean 1:1. |
+| An agent auto-published a blog hit piece attacking a maintainer after its PR was closed; reached #1 on HN (Matplotlib / Scott Shambaugh, OpenClaw agent, [The Register](https://www.theregister.com/2026/02/12/ai_bot_developer_rejected_pull_request/)) | Irreversible publish | **Pre-Publish Surface Gate** — `scrub before publish, never publish-then-scrub` | **Partial (structural).** Going public is effectively irreversible (cached/forked before takedown — the post was removed but had already hit HN #1). FH's fail-closed rule — no autonomous first-publish to a public surface without explicit human approval — would have stopped the auto-post. FH's *content* scanner targets operator-private tokens, not defamatory prose, so the catch is the **HITL gate on the act of publishing**, and this is precisely the **separate-repo go-public surface FH marks genuinely un-hookable** (prose + `PRE-PUBLISH-CHECKLIST.md`, not a hook). |
+
+The pattern across all three: an autonomous agent took an **irreversible action** (delete / spend /
+publish) with no enumerate-or-approve step before it. FH's answer is not a smarter model but a gate that
+makes the irreversible action fail-closed by default — which is what the controlled before/after above
+measures (0/5 → 5/5 safe-default on the two surfaces FH does hook). The honest boundary: two of these
+three surfaces (non-git destructive tool calls; separate-repo publish) are covered by **prose discipline,
+not a mechanical hook** — the same limitation FH already documents, now shown against real incidents
+rather than only synthetic ones.
+
+## What this evidence does *not* establish
+
+- No claim of scaled external adoption or longitudinal results — the project is 12 days old.
+- Experimental results are worked examples, **not** benchmarks; reproduce before relying on them.
+- The cold-pass gain is the base model's own ability surfaced by isolation, **not** an accuracy engine FH adds.
+
+---
+
+<sub>Reproduce the counts:</sub>
+
+```bash
+# active skills (excludes deprecated redirect stubs)
+for d in plugins/*/skills/*/; do grep -qi "DEPRECATED — merged\|redirect stub\|moved to" "$d/SKILL.md" || echo "$d"; done | wc -l
+# agents
+ls .claude/agents/*.md plugins/*/agents/*.md | wc -l
+# knowledge docs
+find knowledge -name '*.md' | wc -l
+# pace
+git rev-list --count HEAD && git log --reverse --format=%ad --date=short | head -1
+gh pr list --state merged --limit 200 | wc -l
+```

package/docs/WHY.md

@@ -0,0 +1,42 @@
+# WHY — why forge-harness exists
+
+forge-harness was built by **chrono-meta**, a practicing QA engineer working in a multi-model
+environment — several LLMs in daily use, each strong at producing output, none built to ask whether
+that output holds up.
+
+That gap is the whole reason this exists.
+
+Most AI tooling optimizes for the moment of generation: how fast the agent ships, how fluent the diff
+looks. A QA practitioner spends their career on the opposite question — *does this survive contact with
+reality?* — and learns to distrust the most dangerous reviewer of all: the author. After you build
+something with an AI, you and it have co-authored a shared belief. You are now its advocate. The froth,
+the unstated assumption, the claim that reads true only if you're feeling generous — these are exactly
+what a co-author cannot see, because seeing them would mean arguing with themselves.
+
+The fix QA already knows is **independence**. The reviewer worth having is the one who never saw your
+reasoning. That is not a clever trick; it is the oldest principle in quality work, applied to a new
+medium. forge-harness is what happens when you take that instinct and make it routine for AI sessions:
+a cold pass on demand, a harness that gates for *correctness* rather than speed, a loop that compounds
+what each session learns instead of letting it evaporate.
+
+That cold pass has a name here — the **quench**, the movement where the work is hardened by attack until
+only what is sound is left standing. Naming things like a forge is not decoration; it is a way of being
+honest about which movements are built and which are still being forged.
+
+It is built by someone who **governs** AI-generated code rather than writes it by hand — which is
+increasingly what the job actually is. You don't out-type the model. You build the rails it runs on, the
+gates it passes through, the record of what it got wrong last time. That is a harness, and a meta-harness
+is the harness that builds harnesses across every project you touch.
+
+The harness runs under a handle, and the methodology is meant to be copied — both on purpose. The formal
+paper carries a real name for citation; the harness does not. Either way forge-harness makes **no appeal
+to a résumé** — its value has to stand on the principles in
+[`ETHOS.md`](ETHOS.md) and the evidence in [`OUTPUT_EVIDENCE.md`](OUTPUT_EVIDENCE.md), or it doesn't
+stand at all. There is no moat to protect, so there is no name to trade on. If a principle here is useful
+to you, take it. Fork the harness, rename it, make it yours. That was always the point.
+
+forge-harness exists because the discipline of *checking* deserves the same tooling that the act of
+*making* has received — and because the person best placed to build it was the one who spends all day
+distrusting confident output.
+
+> *Made for people who already know the hardest bug to catch is the one you wrote yourself.*

package/knowledge/patterns/ensemble_union_detection_task_pattern.md

@@ -0,0 +1,125 @@
+---
+name: ensemble-union-detection-task
+description: "Detection tasks benefit from ensemble UNION (2.5–3.0x coverage lift); generation tasks do not (voting, ~0x). Measured, domain-agnostic."
+type: pattern
+status: VALIDATED
+tags: [ensemble, union, detection, decorrelation, composition-over-scale]
+---
+
+# Ensemble Union Pattern for Detection Tasks
+
+> **Measurement basis**: a PRD-review detection protocol (n=3 real product PRDs) + a generation-task
+> contrast, measured on a fixed open-weight 3-model roster. Detection lift +11.3 findings (2.8x; per-PRD
+> range 2.5x–3.0x); generation lift ~0.
+
+## Pattern
+
+**Detection tasks benefit from an ensemble UNION strategy, not voting.**
+
+- **Detection** (finding defects, gaps, issues): union of all model findings → **2.5x–3.0x** more coverage.
+- **Generation** (creating one artifact): voting for consensus → **~0x lift** (no benefit).
+
+## Mechanism
+
+Each model has **different blind spots**. Model A finds category-X defects, B finds Y, C finds Z.
+`Union(A, B, C)` = superset of all findings → coverage expansion. Voting would **discard minority
+findings**, losing exactly the diversity that makes the panel worth running. (This is the
+composition-over-scale lever: the gain is model *diversity*, not model size — and it holds only while the
+errors are decorrelated. A shared/correlated blind spot is not closed by union; diagnose correlated vs
+independent first.)
+
+## Measured Results
+
+Anchored on a PRD-review detection protocol (3 real product PRDs; 3-model open-weight union vs each single
+model):
+
+| Metric | Union (E) | Best single | Lift |
+|---|:--:|:--:|:--:|
+| Mean findings / PRD | 18.0 | 6.7 | **+11.3 (2.8x)** |
+
+Per-PRD lift ranged **+10.7 to +12.0 (2.5x–3.0x)** — union was 18.0 on every PRD while the best single
+model never exceeded 7.3, because each model surfaced *different* findings. A generation-task contrast
+(create one artifact) showed **~0 lift** from the same union: consensus/voting adds nothing when the goal
+is one output rather than coverage. (The detection→UNION / generation→VOTING split is the validated
+pattern; the +11.3 detection anchor is the measured number, the generation-0 is the qualitative contrast.)
+
+**Arms** (illustrative open-weight roster): three distinct open-weight models spanning ≥2 model families
+(e.g. `qwen3.5-122b`, `qwen3-next-80b`, `gpt-oss-120b`). Family diversity is the point — a same-family
+trio shares blind spots. `E` = union(the three).
+
+## Implementation
+
+```python
+# Detection task → UNION
+result = ensemble_request(
+    prompt="Review this document and classify findings into bins A/B/C/D",
+    models=[MODEL_A, MODEL_B, MODEL_C],   # ≥2 families
+    strategy="UNION",
+    temperature=0.0,
+)
+# result.findings = all unique findings across models
+```
+
+### Deduplication logic
+
+```python
+def compute_union(responses):
+    """Union of findings across models, deduplicated by normalized description."""
+    seen, union = set(), []
+    for response in responses:
+        for finding in extract_findings(response):
+            key = finding.get("description", "")[:50].lower()
+            if key and key not in seen:
+                seen.add(key)
+                union.append(finding)
+    return {"findings": union, "total": len(union)}
+```
+
+## Token economics
+
+Detection is where a cheap local/open-weight union beats a single frontier call on **both** axes —
+more findings **and** lower cost — because union trades false-positive rate (filtered downstream) for
+coverage:
+
+| Option | Relative cost | Findings/item | Note |
+|---|:--:|:--:|---|
+| Frontier alone | baseline | 6.7 | single strong model |
+| Open-weight union (3-model) | ~1/19 | 18.0 | ~19x cheaper + ~2.8x more findings |
+
+## Constraints
+
+- **False positives**: union includes *all* findings → higher FP rate. Mitigate with a frontier filter
+  (union output → one strong-model validation pass), expert review of high-priority findings only, and a
+  downstream precision measurement against ground truth.
+- **Decorrelation precondition**: union only helps when the panel's errors are *independent*. If a blind
+  spot is shared (correlated), stacking more models does not close it — escalate to a human/ground anchor
+  instead. Diagnose correlated-vs-independent (reps ≥ 3) before prescribing union.
+
+## When to apply
+
+| Task type | Examples | Strategy |
+|---|---|:--:|
+| **Detection** | Bug finding · document review · audit · red-team · structure/traceability check | **UNION** |
+| **Generation** | Artifact creation · synthesis · single-answer tasks | **VOTING** |
+
+**Rule of thumb**: "find all X" → UNION. "create one Y" → VOTING.
+
+## Cross-domain applicability
+
+Domain-agnostic — applies to any detection task where (1) multiple independent judges have different
+blind spots, (2) the goal is coverage maximization not consensus, (3) false positives can be filtered
+downstream. Examples beyond QA: code review (security · performance · maintainability), multi-specialist
+diagnosis, content moderation (hate speech · spam · misinformation), fraud detection (multiple risk
+models).
+
+## Done When
+
+- [x] Validated on a PRD-review detection protocol (+11.3, 2.8x; per-PRD +10.7 to +12.0) + a generation contrast (~0 lift). *[measured]*
+- [x] Deduplication logic specified. *[mandatory-pass]*
+- [x] Decorrelation precondition + FP mitigation documented. *[judged — pair: correlated-blindspot diagnosis]*
+- [ ] (Optional) Precision/FP-rate measurement against ground truth.
+
+---
+
+**One-line takeaway**: Detection → ensemble UNION (2.5–3.0x lift). Generation → voting (~0x). The lever is
+family diversity, not model size, and only while errors stay decorrelated.

package/knowledge/shared/GLOSSARY.md

@@ -0,0 +1,77 @@
+# GLOSSARY — forge-harness Key Term Definitions
+
+> One-line definitions of FH-specific vocabulary appearing in skills, agents, and documentation.
+> Reference point for new user onboarding. Keep in sync with the README key terms table.
+
+---
+
+## Hub Structure
+
+| Term | Definition |
+|---|---|
+| **Meta-Harness** | A persistent hub in a Claude Code environment that connects the work, learnings, and patterns of N projects for mutual reinforcement. Not a simple storage — a connection layer through which knowledge flows between projects. |
+| **Meta Hub** | The role of coordinating all field projects from the meta-harness cwd. Hub = common standards and feedback center / field projects = execution sites. |
+| **Launch Pad Effect** | Using the meta-harness not as a final destination but as a launch pad — even a brief pass-through generates setup, pattern sharing, and speed-up effects. |
+| **Transit Acceleration Value** | The meta-harness's core value — passing through itself accelerates the starting line. Acceleration effect occurs the moment you pass through, without requiring absorption or permanent setup. |
+| **Shared Skill Pool** | Removes the cost of each team/harness independently reinventing the same skills/agents. The meta-harness provides a common pool and each project draws from it. |
+
+---
+
+## Operating Modes
+
+| Term | Definition |
+|---|---|
+| **Mode A** | Full harness clone + use all skills/agents. Run directly from hub cwd. |
+| **Mode B** | Partial harness clone or fork. Select and use specific skills/agents only. |
+| **Mode C** | Install only fh-meta via `claude plugin install` without cloning hub. Independent plugin method. |
+| **Path B generalization** | Generalizing skill behavior to work in external user environments without organization-specific infrastructure dependencies. |
+
+---
+
+## Diagnostic Skill Triangle
+
+| Term | Definition |
+|---|---|
+| **Three-Doctor Loop** | Pattern where harness-doctor (structure diagnosis) + context-doctor (token/context diagnosis) + sim-conductor (simulation/ideation scan) form a self-renewing closed loop of diagnosis→prescription→re-diagnosis. |
+| **harness-doctor** | Harness structure L1~L4 diagnostic skill. L1 structural completeness · L2 complexity · L3 Drift · L4 connection diagnosis. |
+| **context-doctor** | Token waste diagnostic skill. `.claudeignore` auto-generation, large file detection, `/clear` timing guidance. |
+| **sim-conductor** | Meta-simulation automation skill. Area A (external user) · B (internal audit) · C (ideation scan) · D (code/session/skill/memory verification) · E (quality examination). |
+| **install-doctor** | Plugin install pre/post conflict, duplicate, and silent overwrite risk diagnostic skill. |
+
+---
+
+## Prescription Tiers
+
+| Term | Definition |
+|---|---|
+| **M-tier (Mandatory)** | Requires immediate action. Risk of functional failure or data loss if left unaddressed. |
+| **S-tier (Strongly recommended)** | Strongly recommended improvement. Quality degradation and drift accumulation if left unaddressed. |
+| **R-tier (Recommended)** | Recommended optimization item. Efficiency improvement when resolved. |
+
+---
+
+## Design Principles
+
+| Term | Definition |
+|---|---|
+| **Simplification Guard** | Mandatory matching of existing assets before adding new ones. Additions rejected without "N+ real-use observations". The execution mechanism of the "a good harness gets simpler over time" principle. |
+| **Description diet** | Removing self-marketing vocabulary (iteration counts, version history, emphasis words, owner names) from skill frontmatter descriptions to make them readable by external users. |
+| **Layer A auto-read** | The 4 files CLAUDE.md automatically reads at session start (CATALOG.md · latest track file · MEMORY.md · next session starter card). Only works in meta-harness cwd. |
+| **Layer A fallback** | Alternate path when Layer A silent-skips in non-meta-harness cwd environments. Manual CATALOG.md read or adding Layer A reference to project CLAUDE.md. |
+| **silent overwrite** | Risk of overwriting existing settings without user awareness. Detected in advance by install-doctor. |
+| **drift** | Phenomenon of growing gap between design intent and actual behavior. Checked periodically as harness-doctor L3 item. |
+
+---
+
+## Evolution Concepts
+
+| Term | Definition |
+|---|---|
+| **cascade α** | Stage where FH skills are first autonomously executed by internal users (including owner). |
+| **cascade β** | Stage where FH skills are autonomously executed by users other than the owner (quasi-external). First achieved by an external user. |
+| **cross-project skill bus** | Structure for centrally managing skills/agents of local projects through FH and enabling cross-project cross-calling. |
+| **field harvest** | Process of feeding patterns discovered in field project work back (pull) to FH. Automated with `/field-harvest` skill. |
+
+---
+
+*Updated: 2026-05-26*

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

@@ -56,7 +56,7 @@ hierarchical-context remedy (L1 always-on / L2 session / L3 on-demand) + prompt
 | 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` |
+| **Coordination-overhead budget** (then in `context-bridge-dispatch`, merged into `agent-composer` Step 3-a on 2026-06-02): parallel-fan-out cap (3–4) + capability-aware routing | Centralized = +285% tokens; team size caps at 3–4 | `plugins/fh-meta/skills/agent-composer` |
 
 ### ② Frontier → Org Propagation
 

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

@@ -55,7 +55,7 @@ Proposed three-layer harness taxonomy:
 |---|---|---|
 | Harness interface | Context injection layer | `CLAUDE.md` · `.claude/rules/*.md` · `MEMORY.md` |
 | Harness mechanisms | Skill bus | `verify-bidirectional` · `steel-quench` · `phantom-quench` · `agent-composer` |
-| Scale | Multi-agent dispatch | Agent View · `context-bridge-dispatch` · `agent-composer` parallel dispatch |
+| Scale | Multi-agent dispatch | Agent View · `agent-composer` parallel dispatch (Step 3-a — absorbed the former context-bridge-dispatch) |
 | *(meta layer, not in taxonomy)* | Harness evolution | `harvest-loop` · `harness-doctor` · `frontier-digest` · `prompt-regression` |
 
 The academic taxonomy covers the **static structure** of a harness. FH adds the **dynamic evolution layer** — the mechanism by which the harness improves itself over time.

package/knowledge/shared/learnings/subagent_invocations_log.yaml

@@ -552,3 +552,12 @@
   finding: "Ran the adversarial pass INLINE instead. It did find a HIGH (S1 scope-exclusion swallowed `[ -f lib ] || exit 0` dependency guards — the fail-open class), closed with a regression anchor. But inline review is same-context by construction, so the isolation property the gate asks for was NOT obtained."
   note: "Recorded as `sustained` (decided NOT to invoke) because the session carries a standing instruction: no Agent tool unless the user requests it. FIRST `sustained` entry in this log — and directly relevant to fh_signal_2026-07-28_decorrelation-log-uncalibrated, which measured 0 rejected / 0 sustained across 74 entries and argued the log is written selectively toward optimistic outcomes. Operator decision pending on dispatching before merge."
 
+
+- date: 2026-07-28
+  agent: general-purpose Sonnet blind sim (NOT invoked)
+  model: n/a
+  purpose: "Target-tier sim gate (fh_4axis_gate.md) on the salience-dependent CLAUDE.md ⑤ atomicity change"
+  prompt_summary: "Would have been: cold-read the rewritten Session Wrap-up ⑤ at Sonnet and close a session with a finding arriving mid-close — does the atomic ordering actually fire, or does the fh_completed append still happen after the card?"
+  outcome: sustained
+  finding: "Not run. The four other worklist items are mechanical (scripts/hooks — tier-independent, exempt by the gate's own enforcement-column test) and were verified by known-pair + mutation + positive control. The CLAUDE.md ⑤ change is the one item the sim gate actually targets, and it is therefore UNVERIFIED at floor tier — recorded as a residual in the Axes 2-3 marker rather than absorbed silently."
+  note: "Second `sustained` in this log, same cause as the first: standing session instruction forbids the Agent tool unless the user requests it. The pattern is now n=2 — the gate's near-mandatory sim is structurally unreachable in sessions carrying that instruction, which is a governance question (whose exception is it?) rather than a per-session judgment call. Candidate for fh_signal."