@chrono-meta/fh-gate 1.4.46 → 1.4.48

package/CLAUDE.md

@@ -120,7 +120,7 @@ Simplification guard: trivial denials with one obvious fix → state block + sin
 
 **Triggers**: greetings (`hi`/`hello`/`hey`/`안녕` — and the same word in any language; FH is English-based but language-agnostic, a bare greeting in any tongue fires this) · start intent (`resume`, `continue`, `where were we`) · new task (`new project`, `new task`) · discovery (`what is this`, `what can you do`, `first time here`)
 
-**4-step summary**: ① Auto-read CLAUDE.md + CATALOG + session card + registry scan + UAP (`tracks/_meta/user_adaptation_profile.md`, if present — apply user-tuned defaults: preferred tier, suppressed proposals, muted nags; see §Operational Adaptation Loop) → ② One-line proposal (new user / exploratory / returning branches) → ③ 5-skill cascade (plugin-recommender → synergy → .claudeignore → model → verify) → ④ Approval + setup
+**4-step summary**: ① Auto-read CLAUDE.md + CATALOG + session card + registry scan + UAP (`tracks/_meta/user_adaptation_profile.md`, if present — apply user-tuned defaults: preferred tier, suppressed proposals, muted nags; see §Operational Adaptation Loop) **+ Mode D companion-store load — if a companion store is configured (your `CLAUDE.local.md` binding), pull it and read its index (its TOC) before its other files, then check freshness against the card (`modes_and_value.md §Session-start freshness`); this load is part of the auto-read, not a step the operator should have to request** → ② One-line proposal (new user / exploratory / returning branches) → ③ 5-skill cascade (plugin-recommender → synergy → .claudeignore → model → verify) → ④ Approval + setup
 
 **Greeting branch + door skeleton (summary-level — applies even if the detail file read is skipped)**: the branch test is **mechanical local state — session files under `tracks/`** — never git log / CATALOG residue (a fresh clone carries full history but zero session files: it is a NEW install — origin: a fresh-clone sonnet sim rendered the returning menu off commit messages, `fh_signal_2026-06-11` FP8). Every variant opens with **🐿️ then an identity-revealing welcome line on the SAME line** (🐿️ is no longer alone on its own line), followed by the menu — one salience unit, not a separate rule. (Put a space after 🐿️; the exact count is **not significant** — a markdown renderer collapses multiple mid-line spaces to one — so the verifiable invariant is *same-line*, NOT a space count.) Welcome line by branch: new / exploratory = "Welcome to FH." · returning = "Welcome back to FH." · operator (FH-dev state) = "The FH operator — good to see you." (rendered in the user's language; the lid/onboarding-smoothness matters even though it is not the substance).
 

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.46",
+  "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):