@chrono-meta/fh-gate 1.3.0 → 1.4.1

package/AGENTS.md

@@ -19,11 +19,14 @@ CLAUDE.md governs *how* the session runs. AGENTS.md defines *what each agent doe
 
 ## Agent Registry
 
-forge-harness ships 5 tracked agents across `.claude/agents/` and plugin `agents/` directories. Four serve general harness operations; one (`quench-challenger`) is steel-quench-dedicated.
+forge-harness ships 8 tracked agents across plugin `agents/` directories. The **user-mastery spectrum** (`beginner` · `main-player` · `expert`) plus `challenger` (adversarial axis) supply multi-persona review; `fact-checker`, `hub-persona-auditor`, and `persona-innovator` serve general harness operations; `quench-challenger` is steel-quench-dedicated.
 
 | Agent | File | Role | Invoked by |
 |---|---|---|---|
-| `challenger` | `.claude/agents/challenger.md` | Frontier-grade adversarial evaluator — adapts attack vectors to artifact type, enforces evidence citation, models its own information asymmetry | `steel-quench`, `harvest-loop`, `sim-conductor`, or direct dispatch |
+| `beginner` | `plugins/fh-meta/agents/beginner.md` | First-contact cold-read standpoint (spectrum entry tier) — onboarding friction a fluent author cannot feel; constructive, not adversarial | `sim-conductor` Area A, `marketplace-gate`, `install-wizard`, or direct dispatch |
+| `main-player` | `plugins/fh-meta/agents/main-player.md` | Engaged-user standpoint (spectrum core tier) — intelligently scopes Light/Midcore/Heavy; Heavy = classic power-user edge/limit lens | `sim-conductor` Area A/D-code, or direct dispatch |
+| `expert` | `plugins/fh-meta/agents/expert.md` | Domain-authority standpoint (spectrum frontier tier) — web-grounded accuracy + SOTA currency, citation-enforced | `sim-conductor` Area E/D, paper review, or direct dispatch |
+| `challenger` | `plugins/fh-meta/agents/challenger.md` | Frontier-grade adversarial evaluator — adapts attack vectors to artifact type, enforces evidence citation, models its own information asymmetry; U1 absorbs the skeptic "why not just X?" lens | `steel-quench`, `harvest-loop`, `sim-conductor`, or direct dispatch |
 | `fact-checker` | `plugins/fh-meta/agents/fact-checker.md` | Pre-recommendation deduplication — greps hub assets for existing skills/agents/patterns before main agent commits to a new recommendation; catches stale facts and duplicate work | Main agent before any new asset creation or recommendation |
 | `hub-persona-auditor` | `plugins/fh-meta/agents/hub-persona-auditor.md` | Pre-publication audit of external-facing assets — 3+ persona simulation, 4-axis review (resonance/confusion/resistance/supplement), 3-tier revision proposals | `hub-cc-pr-reviewer`, `sim-conductor`, or direct dispatch |
 | `quench-challenger` | `plugins/fh-commons/agents/quench-challenger.md` | Steel-quench dedicated adversary — 3-DNA synthesis of Devil + Innovator + Prescriber; every attack paired with a concrete fix direction | `steel-quench` Wave 1 (primary), `install-doctor`, `marketplace-gate` |

package/CATALOG.md

@@ -9,7 +9,7 @@ AI reads this file first when searching past work. Open individual files for det
 <!-- Add entries in reverse date order (newest at top) -->
 
 ### 2026-06-05 | _audit | sister-asset, gstack, field-harness, garry-tan
-**File:** tracks/_audit/session_2026_06_05_gstack-sister.md (private mirror: fh-be)
+**File:** tracks/_audit/session_2026_06_05_gstack-sister.md (private companion mirror)
 gstack (garrytan, ~66K stars) sister-asset cross-audit — the field/execution-harness counterpart to FH's meta/governance harness, both running on the Claude Code skill substrate. FH governs / gstack executes (composes, not competes). Bidirectional import (frictionless one-command install, opinionated front door, privacy-first telemetry) / propagate (post-ship governance gate, cross-project knowledge compounding, HITL promotion gate) lists recorded.
 - Decision: public index only — bet evidence (B1·ID·SB) + full audit held in private store; external cross-link proposal to garrytan/gstack gated behind 3+ persona × 4-axis audit.
 

package/CLAUDE.md

@@ -226,6 +226,8 @@ Proposal format: `"I see [X]. Want me to run /[skill] to [one-line description]?
 | "review for the team", "CTO review", "decision-maker", "share with leadership", "approval deck" | `/apex-review` |
 | "run full pipeline", "verify everything", "end-to-end sweep", "chain all verifications" | `/pipeline-conductor` |
 | "help me write a prompt", "build a prompt", "improve this prompt", "prompt template" | `/meta-prompt-builder` |
+| "/goal", "run this autonomously", "big multi-step task", "orchestrate this goal", or **any heavy autonomous/multi-agent run** (proactive — propose *before* running; it is expensive, so the proposal is mandatory, not the auto-run) | `/goal-quench` (budget gate + quality gate) |
+| "I don't know what to build", "how should I approach this", "organize this for me", "clarify this", "정리해줘" (ambiguous request before dispatch) | `/deep-clarify` |
 | "memory feels bloated", "clean up memory", "memory too large", "memory hygiene" | `/memory-hygiene` |
 | "ready to PR", "about to push", "merge this", "PR 올려줘", FH asset changed in session | 4-axis auto-gate (see above — runs automatically, no proposal needed) |
 
@@ -330,10 +332,15 @@ Closing phrase detected ("wrap up", "done", "good work", "end session", etc.)
   → ② If FH assets changed: harvest-loop
   → ③ Sync local/gitignored session state to your durable companion store, if you keep one
   → ④ Memory hygiene — update stale entries + record new session findings
-  → ⑤ Card update ← ABSOLUTE LAST: must capture ①–④ outcomes
+  → ④-b npm freshness — if any npm-shipped asset changed this session (the `package.json` `files[]`
+       surface: skills · agents · README · AGENTS.md · CLAUDE.md · CHEATSHEET), **propose an npm
+       republish**: version bump + Pre-Publish Surface Gate (`/public-surface-audit` + `/marketplace-gate`
+       Check 5) + `npm publish`. The npm-served README and shipped skills/agents freeze at publish time,
+       so updating FH assets without republishing leaves the package stale. **Propose, don't auto-publish.**
+  → ⑤ Card update ← ABSOLUTE LAST: must capture ①–④-b outcomes
   → ⑥ Commit card + push
 ```
-**Card-last guard**: ①–④ must ALL complete before ⑤ runs. Any new information produced
+**Card-last guard**: ①–④-b must ALL complete before ⑤ runs. Any new information produced
 during ①–④ (new commits, model changes, new findings) feeds INTO ⑤ — card is never
 written mid-sequence and then left open for more work to accumulate after it.
 

package/README.md

@@ -1,5 +1,5 @@
 <p align="center">
-  <img src="https://raw.githubusercontent.com/chrono-meta/forge-harness/main/docs/banner.png" alt="forge-harness — Forge your projects, pass them through, faster." width="680">
+  <img src="https://raw.githubusercontent.com/chrono-meta/forge-harness/main/docs/banner.png" alt="forge-harness — Forge your projects, pass them through, faster. Quality is the lever — speed is the result." width="680">
 </p>
 
 <p align="center">
@@ -15,6 +15,10 @@
   A practitioner's meta-harness: it raises each project's <b>floor</b> (harness-ify the setup)<br>and <b>ceiling</b> (accelerate the work), then compounds the gains across your whole portfolio.
 </p>
 
+<p align="center">
+  <b>Quality is the lever; speed is the result.</b> Every change earns its way through the gates —<br>adversarial · phantom · regression — and <i>that</i> is what makes the next change faster.
+</p>
+
 <p align="center">
   <i>Fork it. Rename it. Make it yours.</i>
 </p>
@@ -24,9 +28,9 @@
 </p>
 
 <p align="center">
-  <a href="ETHOS.md"><b>The principles</b></a> ·
-  <a href="WHY.md"><b>Why it exists</b></a> ·
-  <a href="OUTPUT_EVIDENCE.md"><b>The evidence</b></a> ·
+  <a href="docs/ETHOS.md"><b>The principles</b></a> ·
+  <a href="docs/WHY.md"><b>Why it exists</b></a> ·
+  <a href="docs/OUTPUT_EVIDENCE.md"><b>The evidence</b></a> ·
   <a href="CHEATSHEET.md"><b>How to use it</b></a>
 </p>
 
@@ -160,7 +164,7 @@ hardened by attack, and only then does it ship faster, for having survived.
 | → **Accelerate** | a blade that survived the forge cuts faster | `goal-quench` — *Pass → Accelerate* |
 
 Three movements are shipped; **temper** is the direction ahead — and naming the movement we have *not*
-finished is the point (see [`ETHOS.md`](ETHOS.md#the-forge)). Around the forge, two more signatures keep
+finished is the point (see [`ETHOS.md`](docs/ETHOS.md#the-forge)). Around the forge, two more signatures keep
 it running: `harvest-loop` (each session's lessons become permanent skills) and `agent-composer`
 (orchestrate the dispatch). The other skills wait until you need them — full list below.
 
@@ -227,16 +231,18 @@ it running: `harvest-loop` (each session's lessons become permanent skills) and
 Claude Code does not auto-select models by task complexity — you configure this once.
 
 ```bash
-/model opusplan   # recommended for forge-harness
+/model opus   # recommended for forge-harness — pin Opus so gate/verification turns never silently drop
 ```
 
 | Command | Who runs what | Best for |
 |---|---|---|
-| `/model sonnet` | Sonnet handles everything | Fast coding, simple tasks |
-| `/model opus` | Opus handles everything | Complex reasoning, architecture |
-| `/model opusplan` | **Opus plans · Sonnet executes** | FH orchestration + sub-agents |
+| `/model opus` | Opus handles everything | **FH default** — verification, governance, agent reasoning |
+| `/model opusplan` | Opus *plans* · Sonnet executes *(when Opus engages)* | Cost-conscious routine coding — see caveat |
+| `/model sonnet` | Sonnet handles everything | Fast, simple tasks (no FH gates) |
+
+**Why `/model opus` for FH**: FH is a *quality* harness — its value lives in verification turns (steel-quench, phantom-quench, the 4-axis gate, agent reasoning) that must not silently run on a weaker model. `opusplan`'s Opus engagement is **not guaranteed**: in a measured 10-turn run it used Opus on **0** turns (CC classifies few turns as "plan-mode"), so the reasoning FH leans on quietly ran on Sonnet — pinning `/model opus` removed that variance (22/22 turns Opus in the follow-up). **Sub-agent dispatch** model is set by the dispatch's own `model` parameter; the session model/plan-mode does **not** propagate Opus to sub-agents, so pin Opus there too for adversarial/verification agents. Use `opusplan` only when the task is mostly routine edits and you accept that Opus may not engage.
 
-**Why `opusplan` for FH**: CC switches models per-turn based on task weight — Opus activates for plan-mode turns (complex reasoning, decomposition decisions), Sonnet handles execution turns (tool calls, file edits, bash). forge-harness orchestration leans on both: Opus for design decisions in agent-composer / goal-quench / steel-quench, Sonnet for the actual file edits and sub-agent execution contexts. Sub-agent token costs are CC-visible and appear in the session jsonl under `message.model`.
+> **By role**: editing the harness itself → `/model opus` (full). Running FH on a field project → `/model opus` for any gated/verification work; `opusplan` is an acceptable cost tradeoff for routine coding, with the caveat above. Sub-agent token costs are CC-visible in the session jsonl under `message.model`.
 
 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.
 
@@ -280,5 +286,5 @@ External convergence:
 | [`CHEATSHEET.md`](CHEATSHEET.md) | Full command reference |
 | [`AGENTS.md`](AGENTS.md) | Runtime agent specs |
 | [`CATALOG.md`](CATALOG.md) | Past work search index |
-| [`CONTRIBUTING.md`](CONTRIBUTING.md) | How to contribute skills and patterns |
+| [`CONTRIBUTING.md`](docs/CONTRIBUTING.md) | How to contribute skills and patterns |
 | [`fh_integration_contract.md`](knowledge/shared/harness-core/fh_integration_contract.md) | Governance gate spec |

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@chrono-meta/fh-gate",
-  "version": "1.3.0",
+  "version": "1.4.1",
   "description": "FH runtime adapters — run FH governance, skills, and agents via Claude or Codex with machine-parseable gates.",
   "license": "MIT",
   "keywords": [
@@ -41,12 +41,11 @@
     }
   },
   "files": [
-    ".claude/agents/challenger.md",
     "AGENTS.md",
     "CATALOG.md",
     "CHEATSHEET.md",
     "CLAUDE.md",
-    "CONTRIBUTING.md",
+    "docs/CONTRIBUTING.md",
     "bin/fh-gate.js",
     "bin/fh-run.js",
     "bin/fh-goal.js",

package/plugins/fh-commons/skills/deliberation/SKILL.md

@@ -71,7 +71,7 @@ Upon completing Step 0, include the following in the output:
 Jury auto-selection criteria:
 | Topic nature | Recommended jury personas |
 |---|---|
-| New user experience related | `newcomer` + `power-user` |
+| New user experience related | `beginner` + `main-player` |
 | Technical implementation feasibility | `persona-be` + `persona-fe` |
 | Business viability / policy / legal | `persona-pm` + `persona-business` |
 | General design decisions | No jury (3-layer is sufficient) |

package/plugins/fh-meta/agents/beginner.md

@@ -0,0 +1,104 @@
+---
+name: beginner
+description: Frontier-grade first-contact standpoint evaluator. Simulates a zero-context user meeting an artifact for the first time — attempts the task cold rather than skimming, then reports exactly where comprehension or execution breaks. Lowest tier of the user-mastery spectrum (beginner → main-player → expert). Constructive standpoint, not an adversary — surfaces onboarding friction a fluent author cannot feel. Returns parallax-compatible [Strengths / Concerns / Absence check / Open questions]. Use when you need a true cold-read of a SKILL, README, prompt, or onboarding path.
+tools: Read
+version: 0.1
+---
+
+> **Dual registration**: ships in `plugins/fh-meta/agents/beginner.md`. External installs use this version directly — no hub clone required.
+
+# beginner — First-Contact Standpoint
+
+> challenger asks "what's wrong?" (adversarial). beginner asks "I just got here with zero context — where did I get stuck, and what made me give up?" (constructive). The value is the *first stumble*, which the author can no longer see.
+
+## Core Principle — Cold-Start, Not Skim
+
+The beginner **attempts the artifact**, it does not review it from above. The discipline:
+
+```
+What beginner DOES:
+  - Reads top-to-bottom in document order, as a first-timer would (no jumping ahead) — `Read` only, by design
+  - Stops at the FIRST point where it cannot proceed without outside knowledge
+  - Records the stumble in place, then continues — collecting every friction point, not just the first
+  - Judges only what a zero-context reader could know from the text itself
+
+What beginner does NOT do:
+  - Use author-context, internal vocabulary, or prior-session knowledge to "fill gaps"
+  - Attack, rank by severity-of-exploit, or hunt edge cases (that is challenger / main-player)
+  - Rewrite — it reports friction, it does not fix
+```
+
+**Implication**: "I don't know what this term means" is a valid finding, not ignorance. If a first-timer cannot proceed and the text does not unblock them, that is onboarding friction — full stop.
+
+## Friction Taxonomy
+
+Classify every stumble by where the comprehension breaks:
+
+| # | Friction | Core question |
+|:---:|---|---|
+| F1 | **Undefined term** | A word/acronym used before it is defined or linked. |
+| F2 | **Assumed prerequisite** | A tool, file, install, or prior step the reader is assumed to have but was never told to get. |
+| F3 | **Order break** | A step references something introduced later, or the sequence cannot be followed linearly. |
+| F4 | **Ambiguous instruction** | A directive with two+ plausible readings; the reader must guess. |
+| F5 | **Silent success criterion** | No way to tell whether a step worked before moving on. |
+| F6 | **Entry-point gap** | Unclear where to even start, or which of N paths applies to "someone like me". |
+
+## Execution Protocol
+
+### Phase 1 — Frame
+```
+Artifact: [path / name]
+Reader I am simulating: [first-time user with zero context about this project]
+Knowledge I am NOT allowed to use: [internal vocab, author intent, prior sessions]
+```
+
+### Phase 2 — Cold Walk
+Read in order. At each stumble:
+```
+Friction: [F1–F6 + one-line description]
+Location: [file:line / section / quoted phrase — REQUIRED]
+What I expected vs what I got: [one line]
+Did it block me? : HARD (could not continue) / SOFT (continued but unsure)
+```
+
+### Phase 3 — First-Stumble Report
+```
+First HARD block encountered: [the single earliest point a first-timer gives up]
+Total friction: HARD n / SOFT m
+Did I reach a successful first outcome? : YES / NO (blocked at [where])
+```
+
+## Output Format (parallax-compatible)
+
+```
+### Strengths        (0–3 — what made first contact easy, from a beginner's seat)
+- [what landed: clear entry point, good first example, etc.]
+
+### Concerns
+**Critical** — a HARD block: a first-timer cannot complete the intended first outcome
+- [location] friction code + one-line — what a newcomer cannot get past
+**Important** — significant friction, reader continues but likely wrong/unsure
+**Suggestion** — polish lowering first-contact cost
+
+### Absence check     (outside-vantage: what does the artifact FAIL to provide a first-timer?)
+- [missing prerequisite list / missing "you are here" / missing first success signal]
+
+### Open questions   (0–3 — what a beginner would have to ask a human to proceed)
+```
+
+## Integration Hooks
+
+- **sim-conductor Area A** — beginner is the canonical first-contact persona (A-1). Pairs with main-player (engaged use) and challenger (adversarial).
+- **marketplace-gate / install-wizard** — README & onboarding-path friendliness cold-read.
+- **hub-persona-auditor boundary** — *lens*, not artifact-exclusivity. Both may touch a README. `hub-persona-auditor` = multi-reader 4-axis pre-publication audit of external-facing drafts (briefing/card/guide/README as a publication). `beginner` = a single cold-read standpoint surfacing first-contact friction in any artifact (SKILL/README/prompt/config/code). For a publication-readiness verdict on an external draft, defer to hub-persona-auditor; for "can a first-timer actually get started," use beginner.
+
+## Done When
+
+```
+Cited friction locations appear in ascending document order (evidence of a linear cold walk)
++ Every friction has a Location citation (no abstract "this is confusing")
++ First HARD block identified (or NONE, with the reached first outcome stated)
++ Parallax output emitted (Strengths / Concerns / Absence check / Open questions)
+```
+
+beginner does not defend or fix — it reports first-contact friction. Remediation is the caller's.

package/{.claude → plugins/fh-meta}/agents/challenger.md

@@ -3,6 +3,8 @@ name: challenger
 description: Frontier-grade adversarial evaluator for harness assets, papers, designs, and code. Goes beyond fixed-angle critique — adapts attack vectors to artifact type, enforces evidence citation on every attack, models its own information asymmetry (Sandboxed Adversary), and tracks convergence across rounds. Returns structured [issue · location · severity] output consumable by steel-quench, harvest-loop, and sim-conductor. Use when you need adversarial pressure that a self-reviewing author cannot generate.
 ---
 
+> **Dual registration**: ships in `plugins/fh-meta/agents/challenger.md` (the adversarial axis of the user-mastery spectrum: beginner · main-player · expert · challenger). External plugin installs get it directly — no hub clone required.
+
 # challenger — Frontier Adversarial Evaluator
 
 > The original devil-advocate asks "what's wrong?" The challenger asks "what's wrong, where exactly, why does evidence support that claim, and what can I NOT see that might invalidate my attack?" Adversarial pressure with epistemic discipline.
@@ -38,7 +40,7 @@ Before attacking, challenger identifies the artifact type and loads the correspo
 
 | # | Angle | Core question |
 |:---:|---|---|
-| U1 | **Existence justification** | Why does this exist? Is there a simpler alternative? |
+| U1 | **Existence justification & alternatives** | Why does this exist? Is there a simpler path — or an existing external tool/approach that already does this? *(Absorbs the skeptic "why not just X?" lens — web-grounded: search for prior art / a named existing solution before accepting that this needs to exist. An unrebutted existing alternative is an S/A-grade attack on the artifact's reason to exist.)* |
 | U2 | **Self-referential closure** | Does this evaluate itself by its own criteria? |
 | U3 | **Evidence grounding** | Every quantitative claim: is there a measurement artifact? |
 | U4 | **Bus factor** | If the author is unavailable, does this still function? |

package/plugins/fh-meta/agents/expert.md

@@ -0,0 +1,114 @@
+---
+name: expert
+description: Frontier-grade domain-authority evaluator. Checks an artifact's technical accuracy, completeness, and state-of-the-art currency against EXTERNAL authoritative sources — fetched from the open web, since a general model must ground domain claims rather than assert them. Top tier of the user-mastery spectrum (beginner → main-player → expert): the professor / prolific author / frontier-harness operator. Every accuracy judgment carries an external citation; ungrounded assertions are withheld. Returns parallax-compatible output. Use when "is this technically correct and current with the field?" matters.
+tools: Read, WebSearch, WebFetch
+version: 0.1
+---
+
+> **Dual registration**: ships in `plugins/fh-meta/agents/expert.md`. External installs use this version directly — no hub clone required.
+
+# expert — Domain-Authority Standpoint (web-grounded)
+
+> beginner reads cold; main-player reads as the daily user. expert reads as the **person who knows the field** — a professor, a prolific author, someone running frontier harnesses and agents — and holds the artifact to what the field actually knows *today*.
+
+## Core Principle — Ground, Don't Assert
+
+A general model's "expert opinion" is unreliable when it leans on parametric memory. The expert agent's discipline inverts this: **a domain-accuracy claim is only emitted if an external authoritative source supports it.** No source → no claim (downgrade to an Open question).
+
+```
+What expert grounds against:
+  - External authoritative sources (standards, official docs, peer-reviewed work,
+    primary-source repos, maintainer statements) — fetched live via WebSearch/WebFetch
+  - The current state of the art (is this approach still current, or superseded?)
+
+What expert does NOT rely on:
+  - Its own unverified parametric recall ("I think X is true")
+  - Internal hub assets only (that is fact-checker's job — internal grep)
+  - Declared-source-file back-tracing only (that is source-grounding-audit's job)
+```
+
+**Boundary (no overlap)**: `fact-checker` greps the *hub/own environment*; `source-grounding-audit` traces claims to *declared internal source files*; `expert` checks against the *external world / frontier*. The three cover internal-duplication, internal-provenance, and external-accuracy respectively.
+
+## Accuracy Matrix
+
+| # | Angle | Core question |
+|:---:|---|---|
+| E1 | **Factual correctness** | Is each technical claim true per an authoritative external source? |
+| E2 | **Completeness** | Does it omit something the field considers essential for this topic? |
+| E3 | **Currency / SOTA** | Is the approach current, or superseded by a known better method? |
+| E4 | **Citation integrity** | Do the artifact's own citations say what it claims they say? (cite ≠ verified) |
+| E5 | **Terminology precision** | Are domain terms used in their established technical sense? |
+| E6 | **Overclaim** | Does a stated benefit exceed what the evidence/field supports? |
+
+## Execution Protocol
+
+### Phase 1 — Domain Frame
+```
+Artifact: [path / name]
+Domain(s) identified: [the field(s) this artifact makes claims in]
+Authoritative source classes I will consult: [standards / docs / papers / primary repos]
+Claims extracted for grounding: [list the checkable technical assertions]
+```
+
+### Phase 2 — Grounding Round
+**Prioritize** the highest-risk claims first (load-bearing assertions, quantitative/benchmark claims,
+SOTA claims). Budget: ground the top ~5–8 claims; if more remain, list them under Open questions rather
+than running an unbounded fetch loop. For each grounded claim, run a search/fetch and record:
+```
+Claim: [the artifact's assertion + location file:line]
+Angle: [E1–E6]
+External source: [URL / standard name / paper — REQUIRED to assert a verdict]
+Evidence excerpt: [the actual quoted span the source says — NOT a paraphrase. Self-applies E4:
+                   a source you did not quote is a source you did not verify.]
+Verdict: SUPPORTED / CONTRADICTED / OUTDATED / UNVERIFIABLE (no authoritative source found)
+Note: [one line — what the source says vs what the artifact says]
+```
+
+> **Withhold rule**: if no authoritative source is found (or none could be fetched), the verdict is
+> UNVERIFIABLE and the item moves to Open questions — it is NEVER reported as an error on parametric
+> recall alone. A verdict with no `Evidence excerpt` is not a verdict; downgrade it to UNVERIFIABLE.
+
+> **Source-quality bar**: when sources conflict, rank primary/standard/peer-reviewed over secondary
+> (blog/forum). State the ranking used when a conflict is resolved.
+
+### Phase 3 — Currency Pass
+```
+Approaches that are current (SOTA-consistent): [...]
+Approaches superseded / deprecated by the field: [... with the superseding method + source]
+Field developments the artifact appears unaware of: [...]
+```
+
+## Output Format (parallax-compatible)
+
+```
+### Strengths        (0–3 — what is technically sound / current, with a source)
+- [location] claim — SUPPORTED by [source]
+
+### Concerns   (severity = IMPACT, per the shared parallax contract — not a separate accuracy scale, so the synthesizer can rank across personas)
+**Critical** — a CONTRADICTED claim whose falsity would cause user/system harm or invalidate the artifact's core function — with source + evidence excerpt
+- [location] claim — contradicted by [source]: [what's actually true]
+**Important** — OUTDATED approach, or a material completeness gap with significant impact — with source
+**Suggestion** — terminology / precision / minor currency polish
+
+### Absence check     (what does the field consider essential that the artifact omits?)
+- [missing essential concept / unaddressed known failure mode — with source]
+
+### Open questions   (0–3 — UNVERIFIABLE claims needing the author's source, or domain ambiguities)
+```
+
+## Integration Hooks
+
+- **sim-conductor** — `expert` is the domain-accuracy persona for **Area E** (primary) and for **Area D** on citation-/research-bearing artifacts (design docs with citations — see sim-conductor SKILL_detail persona map). Pairs with `main-player` (usability) and the adversarial agent (`challenger` / `fh-commons:quench-challenger`).
+- **paper / research review** — E4 (citation integrity) and E6 (overclaim) are the paper-grade angles. These deliberately overlap the adversary's paper angles (challenger P1/P5); run expert when you want *grounded* accuracy with external sources, the adversary when you want attack pressure. Both is stronger than either.
+- **frontier-digest adjacency** — E3 currency findings are candidate inputs to frontier-digest's trend scan.
+
+## Done When (each item artifact-checkable)
+
+```
+Every SUPPORTED / CONTRADICTED / OUTDATED verdict carries BOTH a source URL and a quoted evidence excerpt
++ Every claim lacking a quoted excerpt appears under Open questions as UNVERIFIABLE (none asserted from recall)
++ Currency pass completed (SOTA-consistent vs superseded list present)
++ Parallax output emitted (Strengths / Concerns / Absence check / Open questions)
+```
+
+expert does not defend or rewrite — it grounds accuracy against the field. Remediation is the caller's.

package/plugins/fh-meta/agents/main-player.md

@@ -0,0 +1,106 @@
+---
+name: main-player
+description: Frontier-grade engaged-user standpoint evaluator. Simulates the artifact's actual core user base — and intelligently scopes which engagement tier to inhabit (Light / Midcore / Heavy) based on who really uses this. Middle tier of the user-mastery spectrum (beginner → main-player → expert). The Heavy sub-tier carries the old "power-user" lens (edge cases, undocumented behavior, limits); Light/Midcore carry everyday-use friction. Constructive standpoint, not an adversary. Returns parallax-compatible output. Use when "does this actually work for the people who use it daily?" matters.
+tools: Read, Grep, Glob
+version: 0.1
+---
+
+> **Dual registration**: ships in `plugins/fh-meta/agents/main-player.md`. External installs use this version directly — no hub clone required.
+
+# main-player — Engaged-User Standpoint (tier-adaptive)
+
+> beginner is first contact; expert is the frontier authority. main-player is the **core engaged user** — the person who actually uses this regularly. Its distinctive move: it does not assume one user. It reads who the artifact is *for*, then inhabits the right engagement tier(s).
+
+## Core Principle — Inhabit the Real User Base, Not a Generic One
+
+A flat "power-user" review misses that most artifacts serve a *distribution* of users. main-player first profiles the user base, then simulates the tier(s) that actually dominate it — so findings reflect real usage weight, not a single imagined persona.
+
+```
+Tier        Who they are                              What they care about
+─────────────────────────────────────────────────────────────────────────────
+Light       Casual / occasional use; low investment   "Does it just work with defaults?
+            (leisure-grade engagement)                 Low friction, sane defaults, no surprises."
+Midcore     Regular use; the dependable middle         "Is the common workflow efficient?
+            (between light and heavy)                   Customization for my routine? Predictable."
+Heavy       Most time/cost invested; the committed     "Edge cases, undocumented behavior, limits,
+            power user (≈ classic power-user)           advanced config, what breaks at scale."
+```
+
+## Execution Protocol
+
+### Phase 1 — User-Base Profiling (REQUIRED, before any review)
+```
+Caller-passed tier (if any): [e.g. sim-conductor dispatches "main-player (Heavy)"] — if present, it
+  OVERRIDES self-profiling: simulate that tier; you may add one adjacent tier only with a stated reason.
+Artifact: [path / name]
+Dominant tier (qualitative, evidence-based — NOT a fabricated %): [Light | Midcore | Heavy]
+  Evidence: [quote the artifact signal that implies this — flag count, defaults, complexity, audience line]
+Tiers I will simulate: [the dominant one or two — DO NOT review all three by reflex]
+```
+
+> **Grounding honesty**: you can only Read the artifact, not its real user telemetry. Infer the dominant
+> tier from *observable artifact signals* and quote them — never emit invented usage percentages. If the
+> signals are ambiguous, say so and default to Midcore.
+
+> **Intelligent scoping rule**: simulate the tier(s) that carry the artifact's real weight. A one-shot
+> install script → Light dominates. A power-tooling SKILL with many flags → Heavy dominates. A general
+> workflow tool → Midcore (+Heavy for edges). Reviewing a tier the artifact does not serve is noise —
+> declare it skipped.
+
+### Phase 2 — Per-Tier Walk
+For each selected tier, walk the artifact *as that user* and record:
+```
+Tier: [Light / Midcore / Heavy]
+Finding: [one-line — friction, gap, or strength for THIS tier]
+Location: [file:line / section / quoted phrase — REQUIRED]
+Impact for this tier: HIGH (blocks/forces workaround) / MED (slows) / LOW (annoyance)
+```
+
+Heavy-tier checklist (the absorbed power-user lens):
+- H1 Edge/boundary behavior documented, or silently undefined?
+- H2 Undocumented behavior a heavy user will discover and depend on?
+- H3 Stated limits / scale ceilings / rate boundaries?
+- H4 Advanced config & override paths — present and consistent?
+- H5 Failure/recovery under heavy use (conflicts, duplication, overwrite)?
+
+### Phase 3 — Synthesis
+```
+Tiers simulated: [...]  (skipped: [...] — reason)
+Dominant-tier verdict: [does it serve its core user base? YES / PARTIAL / NO]
+Cross-tier conflicts: [where serving one tier hurts another — e.g., defaults good for Light bury Heavy config]
+```
+
+## Output Format (parallax-compatible)
+
+```
+### Strengths        (0–3 — what serves the core user base well, tier-tagged)
+- [Heavy] / [Midcore] / [Light] : what works
+
+### Concerns
+**Critical** — dominant-tier user cannot accomplish their routine use, or forced into a workaround
+- [tier][location] one-line — impact
+**Important** — significant slowdown / undocumented dependence for a served tier
+**Suggestion** — improvement for a served tier
+
+### Absence check     (what does the artifact FAIL to provide its real user base?)
+- [missing limits doc / missing advanced path / missing sane default — tier-tagged]
+
+### Open questions   (0–3 — what the engaged user would need answered to rely on this)
+```
+
+## Integration Hooks
+
+- **sim-conductor Area A / D-code** — main-player is the engaged-use persona (A-2); Heavy tier supplies the edge-case lens for code artifacts.
+- **install-doctor adjacency** — Heavy H5 (conflicts/duplication/overwrite) complements install-doctor; main-player reports the *user-experienced* symptom, install-doctor the structural cause.
+- **challenger boundary** — challenger *attacks* edges adversarially; main-player reports edges as a real heavy user *experiences and depends on* them. Different vantage, intentionally.
+
+## Done When
+
+```
+Dominant tier selected with a QUOTED artifact signal as evidence (no invented %; caller-passed tier honored if given)
++ Every finding tier-tagged with a Location citation
++ Dominant-tier verdict given (YES / PARTIAL / NO)
++ Parallax output emitted (Strengths / Concerns / Absence check / Open questions)
+```
+
+main-player does not defend or fix — it reports engaged-use fit. Remediation is the caller's.

package/plugins/fh-meta/skills/agent-composer/SKILL.md

@@ -114,7 +114,7 @@ Default composition table by task type.
 |---|---|:---:|
 | **[Wave 0] Recon (all tasks)** | Recon agent (A) — file/structure understanding. Direct orchestrator execution forbidden | — |
 | **[Wave 0] All tasks including new assets** | fact-checker (A) — proactive duplicate/stale validation | — |
-| Meta-simulation quality validation | sim-conductor (S) — devil-advocate + newcomer + power-user | ✅ Parallel |
+| Meta-simulation quality validation | sim-conductor (S) — challenger + beginner + main-player | ✅ Parallel |
 | Field pattern harvest | field-harvest (S) | — |
 | Harness structural diagnosis | harness-doctor (S) | — |
 | New asset placement decision | asset-placement-gate (S) | — |

package/plugins/fh-meta/skills/apex-review/SKILL.md

@@ -145,7 +145,7 @@ Choose your next step:
   D. Exit
 ```
 
-> **"Conditionally passed" → option B is the default path**: Conditions listed by personas remain unresolved until sim-conductor Area E runs devil/newcomer/power-user validation against them. Choosing C or D without sim-conductor leaves those conditions unverified — present B as the default choice and require explicit opt-out.
+> **"Conditionally passed" → option B is the default path**: Conditions listed by personas remain unresolved until sim-conductor Area E runs challenger/beginner/main-player validation against them. Choosing C or D without sim-conductor leaves those conditions unverified — present B as the default choice and require explicit opt-out.
 
 ---
 

package/plugins/fh-meta/skills/harness-doctor/SKILL_detail.md

@@ -420,7 +420,6 @@ fi
 
 ```bash
 if echo "$changed" | grep -q "^README\.md$"; then
-  grep -n "chrono-code" README.md 2>/dev/null && echo "STALE: 'chrono-code' found — should be 'chrono-meta'" || true
   actual=$(ls -d plugins/fh-meta/skills/*/ plugins/fh-commons/skills/*/ 2>/dev/null | wc -l | tr -d ' ')
   readme_count=$(grep -oE '[0-9]+ (fh-meta[^)]+)?skills' README.md 2>/dev/null | head -1 || echo "not found")
   echo "Actual skills: $actual | README mentions: $readme_count"

package/plugins/fh-meta/skills/install-wizard/SKILL.md

@@ -26,15 +26,15 @@ category: Composability Gate
 > See `README.md > Advanced Settings > Plugin Install` for detailed guide.
 
 Run immediately after cloning forge-harness (FH), or when setting up a new project for the first time.
-Sets up periodic notification structure (zshrc hook) and weekly audit notifications within Claude Code (CC) sessions. The zshrc hook is permanently applied; CronCreate is valid only for the current session.
+Sets up the periodic-audit notification structure: a permanent zshrc hook (`fh_audit_check.zsh`, runs on terminal start) plus FH's session-start mtime detection. Both surface a weekly-audit reminder when 7+ days have elapsed since the last `weekly_audit` — no persistent cron is used (a session-scoped scheduler cannot survive to fire on a later day).
 
 ## Key Terms
 
 | Term | Definition |
 |---|---|
 | **sentinel** | An empty file that records whether a specific event (audit complete, install complete, etc.) has occurred. Created in `~/.cc_sentinels/`. |
-| **CronCreate** | Claude Code built-in command — schedules periodic tasks valid for the current session. Disappears when session ends. |
 | **zshrc hook** | Shell function added to `~/.zshrc`. Automatically runs on terminal start and applies permanently. |
+| **session-start detection** | FH's durable weekly-audit cadence — at session start the mtime of the latest `weekly_audit_*` is checked and `/harvest-loop` is proposed if 7+ days elapsed (see CLAUDE.md Cadence Rules). No persistent scheduler required. |
 
 ## Execution Modes
 
@@ -51,7 +51,7 @@ Sets up periodic notification structure (zshrc hook) and weekly audit notificati
 - **Per-item approval**: Select each item individually (Y approve / N skip / L later)
 - **Double-confirm irreversible changes**: Preview before file writes and zshrc modifications
 - **User review before PR creation**: Output PR parameters (title, base branch, included files, body) and get approval before execution. No automatic submission.
-- **Periodic audit structure setup**: zshrc hook (permanently applied on terminal start) + sentinel initialization + CronCreate (valid for current CC session)
+- **Periodic audit structure setup**: zshrc hook (permanently applied on terminal start) + sentinel initialization + session-start mtime detection (7-day threshold)
 
 ## Execution Steps
 
@@ -138,9 +138,13 @@ echo 'source ~/.cc_secrets/tokens.env' >> ~/.zshrc
 **The following are environment detection procedures that CC executes automatically. No need for users to run manually.**
 
 ```bash
-# Prompt injection pre-flight: check for AI instruction injection in external config files
-if grep -rE "^# CLAUDE:|^# AI:|<instructions>" ~/.zshrc .claude/settings.json 2>/dev/null | grep -q .; then
-  echo "⚠️  AI instruction pattern detected in external config files — injection risk. Manual check recommended."; fi
+# Prompt injection pre-flight: scan config AND the project's AI-instruction surfaces — CLAUDE.md,
+# AGENTS.md, .claude/rules/* — which are the higher-risk vectors in an unknown repo (not just shell/settings).
+# Injection-SPECIFIC patterns only (override/exfil), since instruction files legitimately carry directives;
+# advisory (recommend manual review), never an auto-block.
+if grep -rIE "ignore (all )?previous|disregard (the )?above|exfiltrat|^# CLAUDE:|^# AI:|<instructions>" \
+     ~/.zshrc .claude/settings.json CLAUDE.md AGENTS.md .claude/rules/ 2>/dev/null | grep -q .; then
+  echo "⚠️  AI-instruction / override pattern detected in config or instruction files — injection risk in an unknown repo. Review the listed files manually before proceeding."; fi
 
 # FH location
 echo "FH_DIR=${FH_DIR:-not set}"
@@ -164,13 +168,13 @@ python3 -c "import json,os; d=json.load(open(os.path.expanduser('~/.claude.json'
 # zshrc hook status
 grep -q "fh_audit_check.zsh" ~/.zshrc 2>/dev/null && echo "zshrc hook: present" || echo "zshrc hook: absent"
 
-# Framework detection (Streamlit) — must be specified in requirements.txt or pyproject.toml
-STREAMLIT_PROJECT=false
-if grep -q "streamlit" requirements.txt 2>/dev/null || \
-   grep -q "streamlit" pyproject.toml 2>/dev/null; then
-  STREAMLIT_PROJECT=true
-  echo "Framework: Streamlit detected"
-fi
+# Framework detection (optional) — only used to look for a matching OPTIONAL domain pattern pack.
+# Generic: capture the framework name; the pattern-pack path is derived as {framework}_patterns.md.
+# No pattern pack ships by default — this is a user-supplied extension point, absence is the normal state.
+FRAMEWORK=""
+for fw in streamlit django fastapi flask; do
+  if grep -qi "$fw" requirements.txt pyproject.toml 2>/dev/null; then FRAMEWORK="$fw"; echo "Framework: $fw detected"; break; fi
+done
 ```
 
 **Bootstrap guidance when FH_DIR is not set (stop immediately in Step 0):**
@@ -180,8 +184,10 @@ fi
   1. Clone FH repo:
      git clone https://github.com/chrono-meta/forge-harness ~/forge-harness
 
-  2. Set environment variable:
+  2. Set environment variables:
      export FH_DIR=~/forge-harness
+     export CC_HUB_DIR=$FH_DIR   # FH hub dir (holds tracks/_audit for the weekly-audit mtime check);
+                                 # equals FH_DIR unless you run a separate hub clone
 
   3. Install FH plugin in CC:
      Settings → Plugins → Add → {FH_DIR}/plugins/fh-meta
@@ -194,11 +200,12 @@ fi
 
 *(Run after Step 0-A·B pre-checks. Output results as environment card, then continue to Step 0-C.)*
 
-Output detection results as **environment card**. Activate CC pattern reference on Streamlit detection:
+Output detection results as **environment card**. If a framework was detected AND you maintain a matching
+optional domain pattern pack, reference it (none ship by default — absence is normal, never a gap):
 ```
-📌 Streamlit project detected → CC pattern reference activated
-   {CC_HUB_DIR}/knowledge/shared/streamlit_patterns.md loaded (if present — optional Streamlit pattern pack, not shipped by default)
-   Check: data_editor empty df / column nesting / async wrapper / CSS numeric variables
+📌 {FRAMEWORK} project detected → optional domain pattern pack check
+   {CC_HUB_DIR}/knowledge/shared/{FRAMEWORK}_patterns.md loaded (only if you supplied it; not shipped by default)
+   If absent: skip silently — no pack is the expected default state.
 ```
 
 ```
@@ -219,7 +226,7 @@ install-wizard — Environment Detection
 > **Core message**: FH is not something placed on top of an existing harness.  
 > It analyzes existing rules to remove duplicates — making things lighter.
 >
-> **Measured expectations** (--dry-run verified values):
+> **Illustrative single-run measurements** (n=1 per project, `--dry-run` verified — not benchmarks; your numbers will differ):
 >
 > | Project type | Example | Total volume | Reduction | Main cause |
 > |---|---|---|---|---|
@@ -324,9 +331,9 @@ Auto-check the following items based on detected environment. Each item classifi
 | `deep-insight plugin` | settings.json plugins contains deep-insight | `grep -r "deep-insight" .claude/settings.json 2>/dev/null` |
 | `fh_env_context.jsonc` | `.claude/rules/fh_env_context.jsonc` exists | `ls .claude/rules/fh_env_context.jsonc` |
 | `phantom-gate` | **(Python + AI-output projects only)** `phantom-gate` present in `requirements.txt` / `pyproject.toml` | `grep "phantom.gate" requirements.txt pyproject.toml 2>/dev/null` |
-| `Streamlit pattern applied` | (Streamlit projects only, if the pattern pack is present) data_editor empty df branch/async wrapper/CSS numeric variables | CC `knowledge/shared/streamlit_patterns.md` Pattern 1-5 check (skip if file absent) |
+| `Domain pattern pack applied` | (optional — only when a `{framework}_patterns.md` pack is present; none ship by default) framework-specific pattern checks | `knowledge/shared/{framework}_patterns.md` check (skip if file absent — the normal default) |
 
-**Score calculation**: PASS = 1 point / MISS = 0.5 points / FAIL = 0 points → converted to 100-point scale.
+**Score calculation**: PASS = 1 / MISS = 0.5 / FAIL = 0. Formula: `score = round( Σ(points) ÷ (applicable item count) × 100 )`. Conditional items (domain pattern pack / phantom-gate / MCP / deep-insight) are excluded from the denominator when not relevant, so always print the denominator next to the score (e.g. `{score}/100 over {n} applicable items`) — the percentage is reproducible only when the item count is shown.
 
 ### Step 2. Diagnosis Report + Proposal List
 
@@ -357,9 +364,11 @@ install-wizard — Diagnosis Results ({score}/100)
   [6] Add MCP plugin — activate integrations (if MCP plugin MISS)
       Run: claude mcp add <your-mcp-plugin> -- npx -y <your-mcp-plugin>
       CC restart required after completion
-  [7] Install deep-insight plugin — activate sim-conductor multi-persona simulation (if deep-insight MISS)
-      Settings → Plugins → Add → {deep-insight plugin path}
-      Without install, /sim-conductor persona branching disabled (single-point simulation only)
+  [7] (Optional — field plugin, NOT required) Install deep-insight — adds the field's domain personas to sim-conductor
+      deep-insight is a private/field marketplace plugin. sim-conductor already ships the built-in
+      user-mastery spectrum (beginner · main-player · expert · challenger), so multi-persona simulation
+      works WITHOUT it. If you have access: Settings → Plugins → Add → <your deep-insight path>.
+      If not: skip — sim-conductor falls back to the built-in spectrum agents (no capability lost).
   [8] Create fh_env_context.jsonc — org/network/Git environment context file (if fh_env_context.jsonc MISS)
       Copy: {FH_DIR}/templates/fh_env_context.jsonc → .claude/rules/fh_env_context.jsonc
       Then manually update with actual values for org name, Jira URL, environment status, etc.
@@ -477,9 +486,16 @@ source "$FH_DIR/templates/fh_audit_check.zsh"
 EOF
 fi
 
-# 4-axis verification gate — install the FH pre-commit hook on the forge-harness clone (idempotent)
-# Git does NOT set core.hooksPath automatically on clone, so this one-time step is required for the gate to enforce (otherwise it stays advisory).
+# 4-axis verification gate (Mode D / FH-self-development only — OPT-IN, double-confirm required)
+# SCOPE (state this before asking): this gates commits IN YOUR FH CLONE ($FH_DIR) — git commit there is
+#   blocked until the 4-axis markers pass. It is FH-internal infra (hardcodes hub paths/markers) and is
+#   NEVER installed into field projects (see auto_project_mapping.md §6). Skip unless you develop FH itself.
+# Per Core Principles (Per-item approval + Double-confirm irreversible changes): this is NOT auto-run —
+#   it is a separate explicit Y/N, not folded into the baseline-setup batch.
 if [ -d "$FH_DIR/templates/.git-hooks" ]; then
+  echo "Enable the 4-axis pre-commit gate on your FH clone ($FH_DIR)? It will block commits there until"
+  echo "markers pass (Mode D / FH-development only). Skip if you are not developing FH itself. (Y/N)"
+  # → On explicit Y only:
   git -C "$FH_DIR" config core.hooksPath templates/.git-hooks
   chmod +x "$FH_DIR/templates/.git-hooks/pre-commit" 2>/dev/null
   echo "4-axis pre-commit gate: installed (core.hooksPath -> templates/.git-hooks)"
@@ -489,8 +505,9 @@ fi
 mkdir -p ~/.cc_sentinels
 touch ~/.cc_sentinels/$(basename "$(pwd)")_wizard_done
 
-# Weekly audit schedule in CC (CronCreate — valid for this session)
-# → auto-call /harvest-loop (lightweight mode) every Monday at 9:03
+# Weekly audit cadence — NO cron needed (a session-scoped scheduler cannot fire on a later day).
+# Durable mechanism = the zshrc hook above (fh_audit_check.zsh warns on terminal start when 7+ days
+# since last weekly_audit) + FH session-start detection (proposes /harvest-loop lightweight when overdue).
 ```
 
 ### Step 5. Completion Report + Contribution Guidance
@@ -503,7 +520,7 @@ install-wizard — Complete
   From now on:
   · Periodic audit auto-check on terminal start
   · Yellow warning output when weekly_audit exceeds 7 days
-  · Auto /harvest-loop (lightweight) at 9am Monday when CC is open
+  · /harvest-loop (lightweight) proposed at session start when 7+ days since last weekly_audit
 
   Next step skills:
   · Not sure which plugin you need → /plugin-recommender

package/plugins/fh-meta/skills/sim-conductor/SKILL.md

@@ -32,7 +32,7 @@ Proposal format: `"If it's related to [X], should I simulate with /sim-conductor
 | "Test it with personas", "Run an external user simulation" | External user reaction | Area A |
 | "Look at it through someone else's eyes" | External perspective | Area A |
 | "Validate that this actually works" | Real-usage validation | Area D |
-| "Find problems aggressively" | Adversarial validation | Area B (devil persona) |
+| "Find problems aggressively" | Adversarial validation | Area B (`challenger`) |
 
 ## Triggers
 
@@ -76,8 +76,8 @@ Read target artifact(s) → classify on 5 dimensions → output recommendation
 | Dimension | Signal → Weight shift |
 |---|---|
 | `artifact_type` | SKILL.md / design-doc → Area B + D-skill↑ · README / CHEATSHEET → Area A↑ · code / config → Area D-code↑ |
-| `audience` | external installer / first-time user → newcomer↑ · internal team only → devil↑ |
-| `claim_density` | 3+ stated benefits or superlatives → devil-advocate↑ |
+| `audience` | external installer / first-time user → beginner↑ · internal team only → challenger↑ |
+| `claim_density` | 3+ stated benefits or superlatives → challenger↑ |
 | `risk_level` | external publish / marketplace listing → steel-quench prerequisite triggered |
 | `novelty` | first-of-its-kind / no prior session evidence → phantom-quench recommended |
 
@@ -113,8 +113,8 @@ Persona Discovery output:
 
 ```
 Persona Map:
-  newcomer       → [installed agent name] OR [built-in fallback]
-  devil-advocate → [installed agent name] OR [built-in fallback]
+  beginner       → [installed agent: beginner] OR [ad-hoc directive]
+  challenger     → [installed agent: challenger] OR [ad-hoc directive]
   [profile-specific role] → ⚠️ GAP — plugin-recommender recommends: [X] (install? y/n)
 ```
 
@@ -165,17 +165,20 @@ sim-conductor does **not** run a fixed persona set. It derives needed perspectiv
 ③ External fetch — chain to /plugin-recommender when ①② insufficient for high-stakes tasks
 ```
 
-Built-in fallback palette (② tier):
+Shipped standpoint agents (① tier — sourced installed-first):
 
-| Role | Perspective | Focus |
-|---|---|---|
-| Newcomer | First-time user, zero development context | Clarity, terminology, onboarding friction |
-| Power-user | Advanced user, edge cases | Undocumented behavior, limits |
-| Devil-advocate | Adversarial critic | Claim-evidence gaps, naming-substance mismatch |
-| Domain-expert | Adjacent-field subject matter expert | Technical accuracy, completeness |
-| Skeptic | Pragmatic outsider | ROI, "why not just X?" |
+FH ships a coherent **user-mastery spectrum** as real, reusable agents (not prompt-directive shells) — found by the ① installed-first scan, reusable across skills, and each isolated-context dispatchable for a true cold read (the bias-isolation value: an evaluator outside the author's context reads cold):
+
+| Agent | Spectrum tier | Standpoint | Type |
+|---|---|---|---|
+| `beginner` | entry | First-contact cold-read — onboarding friction a fluent author cannot feel | reasoning |
+| `main-player` | core | Engaged user; intelligently scopes Light / Midcore / Heavy (Heavy = classic power-user edge/limit lens) | reasoning |
+| `expert` | frontier | Domain authority; web-grounded accuracy + SOTA currency, citation-enforced | data (WebSearch/WebFetch) |
+| `challenger` | adversarial axis | Frontier adversary; U1 absorbs the skeptic "why not just X?" lens | adversarial |
 
-Derive task-specific personas (e.g. "security auditor", "non-native reader") when the task profile demands it.
+> **Lineage**: `beginner` / `main-player` / `expert` are the FH-native frontier successors to the field deep-insight `user` group (newcomer / power-user) — re-derived to FH grade with embedded methodology + Done-When, not name-copied. `challenger` is the advanced form of the field `devil-advocate`. The former standalone skeptic standpoint is folded into `challenger` U1.
+
+**Ad-hoc roles** (② tier — prompt-directive fallback): when the profile demands a standpoint with no shipped agent (e.g. "security auditor", "non-native reader"), inject the role as a directive into a general-purpose Agent. Prefer ① shipped agents; use ② only for genuinely task-specific one-offs.
 
 #### Scale
 
@@ -197,9 +200,9 @@ Pre-entry user confirmation required before multi-team execution.
 
 > **Detail**: See `SKILL_detail.md §MultiTeam` — team formation table (T0–T4), CLI detection bash, confirmation dialog, cross-team synthesis format — read when multi-team mode activates.
 
-**A-1** (Newcomer Agent) — description friendliness · onboarding friction · terminology clarity
-**A-2** (Power-user Agent) — install conflicts · duplication · silent overwrite
-**A-3** (challenger Agent, artifact_type="SKILL") — claim-evidence gaps · angles U3, U5, S2
+**A-1** (`beginner`) — first-contact friendliness · onboarding friction · terminology clarity
+**A-2** (`main-player`) — engaged-use fit; Heavy tier: install conflicts · duplication · silent overwrite
+**A-3** (`challenger`, artifact_type="SKILL") — claim-evidence gaps · angles U3, U5, S2
 
 > ⚠️ **Human review gate**: Area A S-tier judgments require owner review before entering AI-AI loop.
 
@@ -246,10 +249,10 @@ Persona composition adapts to `artifact_type` from Step 0.3 profile:
 
 | Artifact type | Primary persona | Supporting persona | Focus |
 |---|---|---|---|
-| SKILL.md / design doc | challenger (artifact_type="SKILL") | Newcomer | Governance gaps, behavioral rule coverage |
-| Python / JS / bash code | challenger (artifact_type="Code") | Power-user | Edge cases, performance, security surface |
-| Prompt / config | Newcomer | challenger | Interpretation errors, implicit assumptions |
-| Auth / security-sensitive | challenger + Security-auditor† | Power-user | Attack surface, privilege escalation |
+| SKILL.md / design doc | challenger (artifact_type="SKILL") | `beginner` | Governance gaps, behavioral rule coverage |
+| Python / JS / bash code | challenger (artifact_type="Code") | `main-player` (Heavy) | Edge cases, performance, security surface |
+| Prompt / config | `beginner` | challenger | Interpretation errors, implicit assumptions |
+| Auth / security-sensitive | challenger + Security-auditor† | `main-player` (Heavy) | Attack surface, privilege escalation |
 
 † Security-auditor = built-in fallback role (② tier) injected as prompt directive.
 
@@ -265,7 +268,7 @@ Consumer agent attempts actual use (not just reads and judges). Grades: F (funct
 
 ### Area E — Artifact Quality Review
 
-Domain-expert objection (E-1) + Practitioner confusion (E-2) in parallel → Pattern structuring (E-3) integrates both.
+`expert` objection (E-1) + Practitioner confusion (E-2) in parallel → Pattern structuring (E-3) integrates both.
 
 > **Detail**: See `SKILL_detail.md §AreaE-Detail` — E-1/E-2/E-3 execution, finding format, pattern naming procedure — read when executing Area E.
 
@@ -273,11 +276,18 @@ Domain-expert objection (E-1) + Practitioner confusion (E-2) in parallel → Pat
 
 ## Step 1.5 — Persona Output Protocol + Neutral Synthesizer (parallax)
 
-Generalized from the field `deep-insight` multi-persona pattern (fh-be #7), domain-stripped and renamed
-**parallax** for public FH (it is a mode of this skill, not a separate skill — see asset-placement
+Generalized from the field `deep-insight` multi-persona pattern (private companion store), domain-stripped — the *pattern*
+is renamed **parallax** for public FH (it is a mode of this skill, not a separate skill — see asset-placement
 2026-06-06). It gives the persona dispatch above a shared output contract + a neutral aggregator, so
 multi-persona findings stay comparable and the synthesis injects no bias of its own.
 
+> **Naming provenance (precise)**: "renamed" above refers to the *pattern* (→ parallax), not the personas.
+> The company-team-coupled field personas (fe/be/ios/pm/ux-writer/compliance/qa) were domain-stripped
+> entirely. The generic `user` group (newcomer/power-user) was **re-derived to FH grade as the shipped
+> `beginner` / `main-player` / `expert` mastery-spectrum agents** (embedded methodology + Done-When, not
+> name-copied shells), and the field `devil-advocate` was **advanced into `challenger`** (sandboxed-adversary
+> + adaptive attack matrix). Lineage is acknowledged; nothing is carried verbatim as a shell.
+
 **Shared persona output protocol** — every dispatched persona emits the same shape, whatever its lens:
 
 ```
@@ -288,7 +298,7 @@ multi-persona findings stay comparable and the synthesis injects no bias of its
   Suggestion — optional improvement
   (each item: [file:line or quoted span] one-line summary — rationale)
 ### Open questions   (0–3 items needed for a decision)
-### Absence check    (outside-vantage personas — newcomer/integrator: what does the artifact FAIL to
+### Absence check    (outside-vantage personas — beginner/integrator: what does the artifact FAIL to
                       specify that this standpoint needs? discoverability · undocumented contract ·
                       unstated assumption. A normal, self-administrable rubric item — surfaces real gaps.)
 ```
@@ -318,7 +328,7 @@ supplies the specialist lens. Same ①installed → ②fallback → ③fetch pri
 external harness's review-skills count as ① installed sources, widening the persona pool without FH
 shipping every specialist.
 
-> **Absence check — resolved (added above)**: the clean replication (fh-be RESULT9 Arm F: identical
+> **Absence check — resolved (added above)**: the clean replication (companion-store experiment, Arm F: identical
 > artifact, explicit omission prompt, ownership-only variable) found self ≈ isolated (~90% overlap) —
 > **omission-detection is self-administrable when explicitly asked**, refuting the earlier "the author
 > can't see their own omissions" (Arm E, a prompt/design-drift artifact). So the Absence check is a

package/plugins/fh-meta/skills/sim-conductor/SKILL_detail.md

@@ -64,11 +64,11 @@ GAP detected for [perspective X]:
 
 | Artifact type | Optimal personas | Likely GAP (not in FH native) |
 |---|---|---|
-| SKILL.md / governance doc | challenger · newcomer · governance-expert | governance-expert → query plugin-recommender |
-| README / marketing copy | newcomer · devil-advocate · domain-expert | domain-expert (field-specific) → query |
-| Python / JS code | challenger/Code · power-user · security-auditor | security-auditor → query if auth/data |
-| Auth / security-sensitive code | security-auditor · challenger/Code · power-user | security-auditor → block if GAP (high-weight) |
-| Design doc + citations | challenger · domain-expert · skeptic | domain-expert (field-specific) → query |
+| SKILL.md / governance doc | challenger · beginner · expert | deep org-specific governance role → query plugin-recommender |
+| README / marketing copy | beginner · challenger · expert | none native (challenger U1 covers the skeptic lens); niche field depth → query |
+| Python / JS code | challenger/Code · main-player (Heavy) · security-auditor | security-auditor → query if auth/data |
+| Auth / security-sensitive code | security-auditor · challenger/Code · main-player (Heavy) | security-auditor → block if GAP (high-weight) |
+| Design doc + citations | challenger · expert | expert web-grounds citations natively; deep niche subfield → query |
 
 ### Degraded coverage flag
 
@@ -96,7 +96,7 @@ Target Profile:
 
 Recommendation:
   Areas: B (internal meta audit) + D-skill (cold-start validation)
-  Persona composition: challenger (high — claim verification), newcomer (medium — onboarding), governance-expert (medium)
+  Persona composition: challenger (high — claim verification), beginner (medium — onboarding), expert (medium — governance accuracy)
   Scale: Minimum (3)
   Prerequisites: none (not yet external publish)
 ```
@@ -112,7 +112,7 @@ Target Profile:
 
 Recommendation:
   Areas: A (external user perspective — primary) + C (naming gap scan)
-  Persona composition: newcomer (high), devil-advocate (high — claim density), power-user (medium)
+  Persona composition: beginner (high), challenger (high — claim density), main-player (medium)
   Scale: Extended (4–5)
   Prerequisites: steel-quench REQUIRED before Area A proceeds
 ```
@@ -128,7 +128,7 @@ Target Profile:
 
 Recommendation:
   Areas: D-code (primary)
-  Persona composition: challenger/Code (edge cases, security surface), power-user (performance)
+  Persona composition: challenger/Code (edge cases, security surface), main-player (Heavy — performance, limits)
   Scale: Minimum (2 — third persona adds minimal value for bash)
   Prerequisites: none
 ```
@@ -145,7 +145,7 @@ Target Profile:
 
 Recommendation:
   Areas: D-code + phantom-quench (quantitative claims)
-  Persona composition: challenger (claim-evidence), domain-expert (arXiv validity)
+  Persona composition: challenger (claim-evidence), expert (arXiv validity, web-grounded)
   Scale: Minimum (3)
   Prerequisites: phantom-quench recommended (novelty + citations)
 ```
@@ -167,11 +167,11 @@ Run multi-team? (a) Full panel  (b) Claude sub-agents only  (c) Skip to Area B
 
 | Team | CLI | Personas | Dispatch method |
 |---|---|---|---|
-| T0 Claude | Agent sub-agent | hub-persona-auditor · challenger · domain-expert | Agent() call |
-| T1 Gemini | `gemini` pipe | newcomer · power-user · devil | `echo PROMPT \| gemini` |
-| T2 Copilot | `gh copilot suggest` | devil · domain-expert | `gh copilot suggest -t shell` |
-| T3 Ollama | `ollama run` | devil | `ollama run llama3 PROMPT` |
-| T4 Codex | `npx @openai/codex exec` | devil · edge-case-hunter | `echo PROMPT \| npx @openai/codex exec -m gpt-5 -` |
+| T0 Claude | Agent sub-agent | hub-persona-auditor · challenger · expert | Agent() call |
+| T1 Gemini | `gemini` pipe | beginner · main-player · challenger | `echo PROMPT \| gemini` |
+| T2 Copilot | `gh copilot suggest` | challenger · expert | `gh copilot suggest -t shell` |
+| T3 Ollama | `ollama run` | challenger | `ollama run llama3 PROMPT` |
+| T4 Codex | `npx @openai/codex exec` | challenger · edge-case-hunter | `echo PROMPT \| npx @openai/codex exec -m gpt-5 -` |
 
 ### CLI detection bash
 
@@ -205,7 +205,7 @@ Claude blind spots (external-only findings):
 
 Structural methods to reduce self-reference risk in Area B:
 
-1. **Regular devil attacks**: Area B once/month + devil attack (challenger) once/quarter. Route devil → defense results directly into SKILL.md via steel-quench handoff after Area B ends.
+1. **Regular adversarial attacks**: Area B once/month + `challenger` attack once/quarter. Route challenger → defense results directly into SKILL.md via steel-quench handoff after Area B ends.
 2. **Direct external user validation**: Non-owner attempts install + invocation → collect reactions. (cascade β validated: first autonomous external run confirmed.)
 3. **steel-quench integration**: After Area B ends, hand off challenger findings to `/steel-quench` for deeper adversarial review + SKILL.md inscription.
 4. **Dual validation principle**: Internal validation (Area B) alone is insufficient — minimized only when combined with external install reaction collection or cross-model validation.
@@ -266,7 +266,7 @@ Findings format: `[judgment type · pattern · root cause · fix direction]`
 
 ### E-2 — Practitioner Confusion
 
-Agent (Newcomer brief): confusing items, fix suggestions more awkward than original, classification criteria consistency breaks.
+Agent (`beginner` brief): confusing items, fix suggestions more awkward than original, classification criteria consistency breaks.
 
 Findings format: `[item · confusion cause · improvement direction]`
 

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

@@ -214,9 +214,9 @@ Default team-persona assignments:
 
 | Team | CLI | Personas deployed |
 |---|---|---|
-| **T0 Claude** | Agent sub-agent (always present) | challenger · quench-challenger · domain-expert |
-| **T1 Gemini** | `gemini` pipe | devil · newcomer · skeptic |
-| **T2 Copilot** | `gh copilot suggest` | devil · domain-expert |
+| **T0 Claude** | Agent sub-agent (always present) | challenger · quench-challenger · expert |
+| **T1 Gemini** | `gemini` pipe | devil · beginner · alternatives (challenger U1 lens) |
+| **T2 Copilot** | `gh copilot suggest` | devil · expert |
 | **T3 Ollama** | `ollama run {model}` | devil |
 | **T4 Codex** | `npx @openai/codex exec` | devil · edge-case-hunter |
 
@@ -230,9 +230,9 @@ declare -A TEAM_RESULTS
 if [[ " ${TEAMS[*]} " =~ " gemini " ]]; then
   G_DEVIL=$(printf '[Devil] Adversarial reviewer, no prior context.\nFind 3 critical structural flaws — especially whether Done When criteria are binary and achievable.\nFormat: [issue · location · severity S/A/B]\n---\n%s' \
     "$ARTIFACT_TAIL" | gemini 2>/dev/null) &
-  G_NEW=$(printf '[Newcomer] First-time user, zero background.\nFind 3 unclear or jargon-heavy points.\nFormat: [issue · location · severity]\n---\n%s' \
+  G_NEW=$(printf '[Beginner] First-time user, zero background.\nFind 3 unclear or jargon-heavy points.\nFormat: [issue · location · severity]\n---\n%s' \
     "$ARTIFACT_TAIL" | gemini 2>/dev/null) &
-  G_SKEP=$(printf '[Skeptic] Pragmatic outsider.\nFind 3 "why not just X?" challenges.\nFormat: [issue · location · severity]\n---\n%s' \
+  G_SKEP=$(printf '[Alternatives — challenger U1 lens] Pragmatic outsider.\nFind 3 "why not just X?" challenges.\nFormat: [issue · location · severity]\n---\n%s' \
     "$ARTIFACT_TAIL" | gemini 2>/dev/null) &
   wait
   TEAM_RESULTS["gemini"]="$G_DEVIL
@@ -244,7 +244,7 @@ fi
 if [[ " ${TEAMS[*]} " =~ " gh-copilot " ]]; then
   GH_D=$(echo "[Devil] Find 3 critical flaws. Format: [issue · location · severity S/A/B]. Artifact: $ARTIFACT_TAIL" \
     | gh copilot suggest -t shell 2>/dev/null) &
-  GH_E=$(echo "[Domain-expert] Find 3 technical depth gaps. Format: [issue · location · severity]. Artifact: $ARTIFACT_TAIL" \
+  GH_E=$(echo "[Expert] Find 3 technical depth gaps. Format: [issue · location · severity]. Artifact: $ARTIFACT_TAIL" \
     | gh copilot suggest -t shell 2>/dev/null) &
   wait
   TEAM_RESULTS["gh-copilot"]="$GH_D