@chrono-meta/fh-gate 1.4.73 → 1.4.74

package/.claude-plugin/marketplace.json

@@ -11,13 +11,13 @@
   "plugins": [
     {
       "name": "fh-meta",
-      "version": "1.4.73",
+      "version": "1.4.74",
       "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.74",
       "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/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/patterns/multi-persona-review.md

@@ -0,0 +1,88 @@
+---
+name: multi-persona-review (parallax)
+description: Generalized architecture for multi-persona parallel artifact review — parallel isolated personas + shared output protocol + neutral synthesizer. The domain-agnostic, IP-stripped pattern named "parallax" for FH; embodied as sim-conductor Step 1.5. Use when designing or explaining structured multi-viewpoint review (code, spec, design, plan).
+type: reference
+tags: [pattern, multi-persona, review, parallax, sim-conductor, verify-axis]
+---
+
+# Multi-Persona Parallel Review — the `parallax` pattern
+
+> **parallax**: depth — the hidden, the omitted — is only perceivable from multiple viewpoints. One
+> standpoint is flat; the shift *between* standpoints reveals what a single seat cannot. The name is the
+> thesis: structured multi-standpoint coverage finds categorically more than any one viewpoint.
+
+**Provenance**: generalized and domain-stripped from a field marketplace implementation (`deep-insight`,
+a company-internal term — not adopted here). The domain-agnostic *architecture* is portable; the
+domain-specific personas were field extensions and are excluded. In FH this pattern is a **mode of
+`sim-conductor`** (Step 1.5), not a separate skill — see `asset-placement-gate` verdict (2026-06-06):
+it overlaps sim-conductor ~80–90%, so the distinctive patterns were absorbed, not forked.
+
+## The architecture (6 + 1 patterns)
+
+1. **Parallel isolated persona spawn** — N personas run as parallel agents (`Task(subagent_type=…)` /
+   parallel Agents), each in its own context, no inter-agent communication. Isolation is mechanical: it
+   lets each persona reach an independent verdict, which is what makes cross-persona agreement meaningful.
+2. **Shared output protocol (constitution)** — every persona, whatever its lens, emits the same shape:
+
+   ```
+   ### Strengths        (0–3, from this persona's viewpoint)
+   ### Concerns
+     Critical   — compile/runtime failure · clear logic error · data corruption · security leak
+     Important  — significant user/service impact in a plausible scenario
+     Suggestion — optional improvement
+     (each: [file:line or quoted span] one-line summary — rationale)
+   ### Open questions   (0–3 needed for a decision)
+   ### Absence check    (outside-vantage personas: what does the artifact FAIL to specify that this
+                         standpoint needs — discoverability, undocumented contract, unstated assumption?)
+   ```
+3. **Neutral synthesizer** — a NON-persona aggregator that injects no opinion: never a conclusion no
+   persona stated · preserve attribution (who said what) · priority labels verbatim · no forced consensus
+   or forced conflict. It reports Common opinions (2+ agree) and Conflicts (A vs B, each with rationale).
+4. **Persona taxonomy (group aliases)** — `dev` (fe/be/…), `biz` (pm/designer/…), `review`
+   (qa/compliance/devil-advocate), `user` (newcomer/power-user), `all`. Sourced, not hardcoded.
+5. **FP judgment discipline** — only escalate when confident. Never escalate: pre-existing issues ·
+   style without a quotable rule · linter-catchable · speculative · subjective (→ Suggestion). *If not
+   confident, do not mark it* — false positives erode reviewer trust.
+6. **Devil's advocate as a structural member** — not a special case; a standard member of `review`. Every
+   objection carries a rationale (no contrarianism for its own sake); the faster others converge, the
+   harder it hunts the weak point.
+7. **External-harness persona sourcing** (FH addition) — a lens may be sourced from an installed *sibling
+   harness*, not only the built-in palette: e.g. gstack `/review` (staff-engineer), `/cso`
+   (security-officer), `/qa` (QA-lead). The orchestrator runs FH; the sibling supplies the specialist
+   lens. Isomorphic to `steel-quench` Step 0.4 (Specialized Reviewer Discovery) + Wave 5 (external CLIs).
+
+## The two-layer severity (why it's required, not redundant)
+
+Per-persona `Critical/Important/Suggestion` (each persona's own judgment in isolation) → synthesizer
+triages to `M/S/R` (cross-persona). An isolated persona **cannot** assign `S = found by 3+ personas` —
+that depends on agreement it never sees. So the per-persona → synthesized split is *required by isolation*,
+not duplicate vocabulary.
+
+## What this pattern's value actually IS (honest, from the R9 experiment arc)
+
+Established by controlled experiment (companion-store `RESULT9`, codex, capability-controlled, 2026-06-06):
+
+- **It is NOT de-biasing.** Ownership had ≈ zero effect (a model self-reviewing blunt = an outsider
+  blunt). It is NOT "seeing what the author structurally can't": when explicitly asked, an author finds
+  their own omissions about as well as an outsider (clean replication refuted the "non-self-administrable"
+  claim).
+- **What is real**: the gradient **`blunt < single-rubric < multi-persona`** — structured multi-standpoint
+  coverage finds categorically more (a single-flaw prompt missed SSRF; a single rubric missed the
+  consumer-contract axis a newcomer surfaces). Different standpoints make different issues *visible*.
+- **So the value is**: **pure rubric/standpoint supply + routine enforcement** — the pattern assembles and
+  *routinely runs* the structured multi-standpoint rubric (including the omission/absence check) that a
+  builder would not assemble or run on themselves. **Fully copyable utility, zero cognitive-moat.**
+  Isolation's role is mechanical (independent verdicts → honest cross-persona triage + decorrelation), not
+  cognitive.
+
+This framing is falsifiable and matches FH's utility-not-moat positioning: the personas are a copyable
+marketplace; the marginal value is making the structured sweep routine, not exclusivity.
+
+## Where it lives in FH
+
+- **Operational home**: `sim-conductor` Step 1.5 (Persona Output Protocol + Neutral Synthesizer). Area D
+  (artifact validation) is the focused multi-persona review entry point.
+- **Sourcing kinship**: `steel-quench` Step 0.4 + Wave 5 (external reviewer/CLI discovery).
+- **6-axis**: a validated pattern for **Axis 5 (Verify)** — structured multi-viewpoint review of a
+  near-complete artifact, complementary to steel-quench (adversarial hardening) and phantom-quench
+  (source grounding).