@chrono-meta/fh-gate 1.4.47 → 1.4.48

package/README.md

@@ -276,12 +276,28 @@ dispatch's own `model` parameter; the session model/plan-mode does **not** propa
 > *self-development* is where tier depth measurably pays (design-increment finding), while operation
 > does not. Sub-agent token costs are CC-visible in the session jsonl under `message.model`.
 
-**Measured, not asserted** (2026-06-10, worked example): on a 30-point blind rule-application battery,
-*operating* FH was nearly model-flat — Opus 4.8 / Sonnet 4.6 / Haiku 4.5 scored **100 / 97 / 94** against
-a top-tier anchor at 100, with the rules in context doing most of the work. The tiers separated only on
-above-rubric *design* increments (developing the harness, not running it) — which is why the default is
-Sonnet with **tier-floored dispatch** covering the depth-sensitive turns, and a pinned stronger model is
-recommended only for harness-editing sessions. Details: `docs/OUTPUT_EVIDENCE.md` §Validation signals.
+**Measured, not asserted** (worked examples): on a blind rule-application battery, *operating* FH is
+near model-flat — **every Claude tier measured scores 94–100%** (Fable, Opus 4.8, Sonnet 4.6 and 5,
+Haiku 4.5); the few lost points are format discipline, never a trap or gate-class miss. The tiers
+separate only on above-rubric *design* increments (developing the harness, not running it) — which is
+why the default is Sonnet with **tier-floored dispatch** covering the depth-sensitive turns, and a
+pinned stronger model is recommended only for harness-editing sessions.
+
+This is stated as an **invariant, not a per-model leaderboard**. Two structural laws, neither of which a
+new release overturns:
+
+1. **Operation (구동) flattens across tiers** — the rules-in-context do the work, so every tier ceilings
+   on rule-application (Sonnet 5 tied Opus 4.8 at the battery ceiling in a 2026-07-03 replication).
+2. **Depth (design increments) is tier-ordered, and the order is fixed *within a generation*** — a lower
+   tier never overtakes the higher of the **same** generation (tiers are priced to be worth it, so the
+   vendor keeps them ordered). *Across* generations a newer lower-tier model can surpass an older
+   higher-tier one (Sonnet 5 ≥ Opus 4.8 on operation is exactly this cross-generation case) — but the
+   current top tier of any generation still wins its own depth turns.
+
+So the doctrine is permanent, not perishable: **default to the mid tier for operation; escalate to the
+current top tier for depth.** Re-measurement is warranted only when a new model becomes a field-main
+*candidate* (a one-time cross-generation threshold check), never to re-confirm same-generation tier order
+— that is guaranteed by design. Details + dated runs: `docs/OUTPUT_EVIDENCE.md` §Validation signals.
 
 If you use external CLIs (Gemini, Codex, `gh copilot`) as sidecars, their costs are billed to their own quota and not visible in CC's token display.
 
@@ -292,7 +308,7 @@ the canary / cheap-breadth rungs only:
 
 | Tier | Spec | Runs locally | What it buys |
 |---|---|---|---|
-| **Minimum** | anything that runs Claude Code | nothing | full methodology + gates; operating FH is ~model-flat (Opus/Sonnet/Haiku 100/97/94) |
+| **Minimum** | anything that runs Claude Code | nothing | full methodology + gates; operating FH is ~model-flat across every tier tested (94–100%) |
 | **Recommended** | laptop-class, ~16GB RAM | one 8B-class quantized model (e.g. an 8B / small Gemma) | a token-free **floor canary** (pre-screen before a metered sim) · offline triage · a cheap-breadth panel arm |
 | **Optional (heavy)** | ~24GB VRAM GPU | a 27–32B model | a *stronger* decorrelation canary |
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@chrono-meta/fh-gate",
-  "version": "1.4.47",
+  "version": "1.4.48",
   "description": "FH runtime adapters — run FH governance, skills, and agents via Claude or Codex with machine-parseable gates.",
   "license": "MIT",
   "keywords": [

package/plugins/fh-meta/skills/phantom-quench/SKILL.md

@@ -83,6 +83,13 @@ When AI generates artifacts without reading the source, those artifacts look lik
 | **Partial reading** | Source partially read, rest filled in with inference | A |
 | **Reconstruction contamination** | Source was read but LLM modified values/conditions during paraphrase | A |
 
+> **External anchor**: *package hallucination* — an LLM emitting a non-existent or invalid
+> package name, which an attacker can then register under the hallucinated name as a supply-chain
+> vector — is a documented instance of the Phantom Claim class (arXiv:2607.02052, *Mitigating
+> Package Hallucinations in Large Language Models via Model Editing*). That work mitigates the failure inside the
+> model; phantom-quench catches the same class at the artifact surface by back-tracing each
+> referenced name to a declared source.
+
 ---
 
 ## Execution Steps

package/plugins/fh-meta/skills/steel-quench/SKILL.md

@@ -112,6 +112,12 @@ Treat the adapter output as the isolated challenger result for Wave 1. This pres
 
 > **Import origin** (sister-asset cross-audit 2026-06-14, `tracks/_audit/session_2026_06_14_official-plugins-cross-audit.md`): skill-creator + plugin-dev/skill-reviewer measure trigger accuracy **empirically**; FH's skill gate ("3+ NL triggers") and steel-quench's trigger-collision attack are **judged**, not measured. This probe converts that one verdict to **measured** — the mechanical-anchor discipline (a terminal trigger verdict should rest on a count, not an inference: the W4-4 question applied to the skill's own description).
 
+> **External frame**: treating a trigger/prompt phrase set as a first-class artifact that needs a
+> coverage criterion analog to code coverage is the position argued in arXiv:2607.02057, *Prompt
+> Coverage Adequacy*. FH's instrument here is a fire-count over should-fire / near-miss phrases,
+> not that paper's attention-based test-suite coverage — the anchor grounds the coverage-adequacy
+> framing, not a drop-in metric.
+
 **Fires only when** `artifact_type = skill_md` (Step 0.3 canonical enum, `tpa_schema.md` — i.e. a SKILL.md) AND the **trigger surface** changed. *Trigger surface* = exactly the `description:` YAML field **plus** the `## Triggers` / `## Trigger Phrases` section (and nothing else — a body-wave or procedure edit with both of those untouched does **not** fire it). Any other artifact has no trigger surface — note `Step 0.5: skipped (not a skill_md trigger change)` and proceed.
 
 **Procedure** (prose-scale — FH routes + governs, it does **not** rebuild skill-creator's eval engine; no Python harness, no vector store):