fv-skills-baif 2.3.2 → 2.3.4

package/CHANGELOG.md

@@ -6,6 +6,36 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/).
 
 ## [Unreleased]
 
+## [2.3.4] - 2026-09-20
+
+### Fixed
+
+- Crypto evaluation now trusts Lean's kernel for checked proof terms and concentrates adversarial
+  review on statement/source conformance and trust-boundary evidence. It reuses a current executor
+  build log or runs one bounded fallback without retry, rather than repeating proof derivations,
+  executor gates, or external numeric computations.
+
+## [2.3.3] - 2026-09-20
+
+### Added
+
+- FVS is now a native Pi package with 29 generated skills, provider-qualified model handling,
+  `/skill:fvs-*` invocation guidance, and direct `pi install npm:fv-skills-baif` support (#62).
+- `/fvs:configure` and every delegated workflow now use stage-scoped, runtime-aware model profiles.
+  Quality selects authority, execution, and scout tiers from the live runtime catalog; commands show
+  one confirmable model/effort manifest and fail closed when a provider or dispatch cannot honor it
+  (#64).
+
+### Fixed
+
+- Fresh local Codex installs create their configuration directory before patch discovery. Local
+  patch metadata now separates immutable history from active pending patches, preserves real edits
+  without treating unchanged generated TOML as custom, and retires resolved patches atomically
+  (#60).
+- FC and crypto reviews require explicit catalog-resolved model/effort selections, preserve raw and
+  normalized responses separately, retain writable diagnostic scratch without exposing source
+  writes, and enforce consistent verdict, severity, authority, and thread-count contracts (#60).
+
 ## [2.3.2] - 2026-09-10
 
 ### Fixed

package/README.md

@@ -13,7 +13,7 @@
 npx fv-skills-baif
 ```
 
-**Works on Mac, Windows, and Linux. Supports Claude Code, Codex, OpenCode, and Gemini CLI.**
+**Works on Mac, Windows, and Linux. Supports Pi, Claude Code, Codex, OpenCode, and Gemini CLI.**
 
 <br>
 
@@ -42,6 +42,18 @@ Framework-specific commands (currently Lean) handle the actual specification and
 
 ## Getting Started
 
+### Pi package
+
+Install FVS directly from npm as a Pi package:
+
+```bash
+pi install npm:fv-skills-baif
+```
+
+Start a new session, then run `/skill:fvs-help`. Bundle routers such as `/skill:fvs-fc` and
+`/skill:fvs-formalise`, plus member skills such as `/skill:fvs-crypto-plan`, are available directly.
+Update an unpinned install with `pi update npm:fv-skills-baif`.
+
 ### Plugin marketplace (Claude Code and Codex)
 
 The Beneficial AI Foundation maintains one catalog for FVS and future BAIF plugins. Add the catalog
@@ -74,7 +86,7 @@ The BAIF Git catalog is a versioned distribution source that can list multiple i
 released plugins. It is separate from OpenAI's universal public Plugins Directory, which has its
 own per-plugin submission process.
 
-### npm installer (all runtimes)
+### npm installer (Claude Code, Codex, OpenCode, and Gemini)
 
 ```bash
 npx fv-skills-baif
@@ -172,11 +184,10 @@ Commands are grouped into five bundles. Each bundle has a **router** command tha
 rejects ordinary Lean identifiers with three or more namespace dots, steering generated code
 toward scoped namespaces, `open`, and local names.
 
-After `lean-specify`, an interactive review menu asks reviewer, then model, then effort; it never
-auto-selects a choice. It offers the other runtime first, a fresh reviewer in the current runtime,
-or another provider. Choose GPT Sol or Astra for Codex, Fable for Claude, or a cheaper/custom model;
-effort defaults to `max` and can be lowered. Other providers use an exported source packet and
-imported response. One-run `Skip review` records `Unreviewed (user skipped)` and does not begin
+After `lean-specify`, an interactive review menu resolves reviewer, exact catalog model, and
+model-supported effort; it never auto-selects a choice. It offers the other runtime first, a fresh
+reviewer in the current runtime, or another provider. Other providers use an exported source packet
+and imported response. One-run `Skip review` records `Unreviewed (user skipped)` and does not begin
 proof work. Reviews and source hashes live under `.formalising/spec-reviews/`.
 
 The reviewer stays read-only and `review.md` stays immutable. The `lean-specify` authoring seat
@@ -233,10 +244,19 @@ secrets, raw transcripts, ephemeral error dumps, unsupported guesses, or inferre
 | Command | Description |
 |---------|-------------|
 | `/fvs:help` | Show available FVS commands and usage guide |
+| `/fvs:configure` | Configure runtime-aware subagent models, effort levels, and review defaults |
 | `/fvs:update` | Update FVS through the current installation channel |
 | `/fvs:reapply-patches` | Preserve customizations across FVS updates (patches for npm installs; fork guidance for plugin installs) |
 | `/fvs:kb-setup` | Set up NotebookLM knowledge base integration (venv, auth, config) |
 
+`/fvs:configure` stores concrete model IDs under the runtime and exact stage that reported them.
+The quality profile is role-aware: authority artifacts use the strongest detected model with max
+reasoning, execution/proof filling uses the executor model with xhigh, and research/eval/audit work
+uses a smaller model with high. Claude and Codex family preferences never cross runtimes; Pi uses
+provider-qualified IDs and keeps its active provider for ordinary work. Each interactive command
+shows one model/effort selection manifest with one-run, save, notes, and cancel paths. Missing models
+or unsupported efforts require a user choice; unresolved noninteractive runs fail before dispatch.
+
 ---
 
 ## How It Works

package/agents/fvs-crypto-thinker.md

@@ -6,15 +6,14 @@ color: purple
 ---
 
 <role>
-You are the FVS crypto formalisation thinker. You are the high-effort author of the loop: you
-re-derive everything independently, from the branch state and the paper-grounded sources, and you
-return your reasoning as text. You are NOT the executor -- a separate `fvs-executor`-style agent in
-the current runtime runs the plans you author. You author; they execute.
+You are the FVS crypto formalisation thinker. You are the high-effort author of the loop: in plan and
+follow-up modes you derive bounded work independently from the branch state and paper-grounded
+sources, then return your reasoning as text. You are NOT the executor -- a separate
+`fvs-executor`-style agent in the current runtime runs the plans you author. You author; they execute.
 
-Planning is ALWAYS high reasoning effort -- you never produce a sketch and call it a plan. The eval
-stage is ALWAYS adversarial: you take the posture of a reviewer who is actively trying to REFUTE the
-spec, the proof, and the stated assumptions, not one who is looking for a reason to wave them
-through. A plan or proof survives only by surviving your attempt to break it.
+Planning is ALWAYS high reasoning effort -- you never produce a sketch and call it a plan. Eval mode
+is adversarial about landed statements, modeling assumptions, source fidelity, and trust boundaries;
+it follows the bounded kernel-trusting contract below instead of reproducing checked proof work.
 
 You are read-only with respect to the deliverable: you do NOT write or modify any project file. You
 RETURN the bounded plan / the adversarial eval / the follow-up as text, and the orchestrating
@@ -77,18 +76,28 @@ from this iteration. Apply the same audit to follow-up plans.
 **Input:** the executor's run output, the touched files, the plan it was run against, the KB sources.
 **Output (returned as text):** an adversarial review ending in exactly ONE decision verb.
 
-This stage is ALWAYS adversarial. Re-derive independently; do not echo the executor's reasoning.
-Actively try to REFUTE: does the spec actually capture the paper's claim? Does the proof close the
-goal it claims, or does it lean on an unstated assumption? Is every `sorry` a named obligation with
-the correct statement, or is it papering over a real gap? Name the exact input, caller, or modeling
-assumption that would make the argument FALSE.
+This stage TRUSTS THE LEAN KERNEL for kernel-checked proof terms and stays adversarial about statements
+and trust boundaries. Check the landed definitions, theorem signatures, constants, and API shape
+against the paper/standard and the approved plan. Run cheap scans over touched Lean files and import
+changes for reserved names, forbidden imports, `sorry`, unexpected `axiom`, `native_decide`, and
+`set_option`. Classify every hit in context; unexplained or disallowed hits prevent `ACCEPT`.
 
-A `sorry` is acceptable ONLY as an intentional, named obligation carrying the correct statement --
-never judged by count, never waved through because "the build is green".
+Reuse a successful current executor `build.log`. If it is missing, failed, or does not cover the
+landed files, run at most one fallback `LEAN_NUM_THREADS="${LEAN_NUM_THREADS:-4}" nice -n 19 lake build`;
+do not retry. A failed fallback is `BLOCKED`. Never re-elaborate individual files, replay the
+executor's per-gate builds, search for proof terms, or use an outside script to recompute certified
+numbers. Compare landed constants directly with explicit plan/source values; missing derivation
+evidence is `FOLLOWUP`, not permission to recompute it.
+
+A `sorry` is an intentional, named unmet obligation carrying the correct statement. It is never
+judged by count or waved through because the build is green, and it does not inherit the
+kernel-complete status of checked proof terms. Name the exact input, caller, statement, or modeling
+assumption that would make the landed claim false.
 
 End with EXACTLY ONE of these decision verbs, on its own:
 
-- **ACCEPT** -- the spec/proof survives the adversarial pass; the obligations are honest.
+- **ACCEPT** -- statement/source conformance, classified trust-boundary evidence, and required green
+  build evidence all pass; named unmet obligations are honestly recorded.
 - **FOLLOWUP** -- the work is sound but incomplete; a bounded follow-up plan is warranted.
 - **HUMAN_RULING** -- a modeling decision is required that you must NOT make yourself (see followup).
 - **BLOCKED** -- the work cannot proceed (e.g. the build will not compile, a prerequisite is absent).
@@ -145,7 +154,7 @@ Adversarial eval:
 
 **Stage:** eval
 **Decision:** ACCEPT | FOLLOWUP | HUMAN_RULING | BLOCKED
-**Refutation attempted:** {the strongest counter you raised}
+**Statement challenge:** {the strongest source/spec counterexample you tested}
 ```
 
 On HALT / failure:
@@ -160,7 +169,7 @@ On HALT / failure:
 
 <success_criteria>
 - [ ] In `plan`/`followup` mode, authored a bounded, runtime-neutral plan stating branch/state, exact target files+theorems, immutable public statements, old->new API map (if a port), allowed-`sorry` policy, stop conditions, `LEAN_NUM_THREADS="${LEAN_NUM_THREADS:-4}" nice -n 19 lake build` verification, and expected artifact updates
-- [ ] In `eval` mode, took an adversarial posture (tried to refute), judged each `sorry` as a named obligation not by count, and ended in exactly one of ACCEPT | FOLLOWUP | HUMAN_RULING | BLOCKED
+- [ ] In `eval` mode, trusted kernel-checked proof terms, challenged statement/source conformance and trust boundaries, reused current build evidence or ran one guarded fallback without retry, and ended in exactly one of ACCEPT | FOLLOWUP | HUMAN_RULING | BLOCKED
 - [ ] On `HUMAN_RULING`, HALTed and asked for the modeling decision -- never fabricated a plan
 - [ ] Author-by-return: no project file written or modified; no `gh` auto-open; Lean-via-Aeneas pipeline only; no bare `lake build`
 - [ ] Result returned with the ## PLAN COMPLETE / ## EVAL COMPLETE / ## ERROR header

package/bin/install.js

@@ -70,37 +70,30 @@ const CODEX_AGENT_SANDBOX = {
   'fvs-axiom-auditor': 'read-only',
 };
 
-// Codex agents inherit the user's selected Codex model — the converter never
-// pins a `model`, it sets only the reasoning-effort budget. The user owns the
-// model choice and may change it mid-session; FVS controls only how hard each
-// agent thinks. Precision-critical roles (spec authoring, proof attempt and
-// refactor, explanation) run at the highest effort; the research/mapping
-// support role runs one tier lower. Codex accepts minimal|low|medium|high|xhigh;
-// any unmapped agent defaults to high at the lookup site.
+// Codex agent TOMLs cannot express FVS's stage-aware quality matrix: shared
+// agents serve authority, work, and scout stages. These are safe installation
+// fallbacks only. The command-level selection manifest is authoritative and
+// passes a stage effort dynamically when spawn_agent supports it; otherwise it
+// must surface the limitation instead of claiming the requested stage setting.
+// Codex accepts minimal|low|medium|high|xhigh in agent TOML; any unmapped agent
+// defaults to high at the lookup site.
 const FVS_CODEX_AGENT_EFFORT = {
   'fvs-executor': 'xhigh',
   'fvs-lean-refactorer': 'xhigh',
-  'fvs-explainer': 'xhigh',
+  'fvs-explainer': 'high',
   'fvs-researcher': 'high',
-  // Extraction loop + doc-sync workers. The two roles whose output is the most
-  // reasoning-sensitive — the independent equivalence assessor (judging whether a
-  // meaning-bearing change preserves behaviour) and the bisector (minimizing a
-  // novel blocker to a faithful failing example) — run at xhigh; the remaining
-  // workers run at high.
-  'fvs-equivalence-assessor': 'xhigh',
+  // Extraction fallbacks follow the confirmed work/scout split.
+  'fvs-equivalence-assessor': 'high',
   'fvs-extract-bisector': 'xhigh',
   'fvs-extract-classifier': 'high',
-  'fvs-extract-applier': 'high',
+  'fvs-extract-applier': 'xhigh',
   'fvs-draft-investigator': 'high',
   'fvs-doc-syncer': 'high',
-  // Crypto loop + trust audit. The thinker authors bounded plans and runs the
-  // always-adversarial eval -- the most reasoning-sensitive role in the loop --
-  // so it runs at xhigh (the dual-runtime Codex thinker must think at least this
-  // hard); the read-only auditor introspects axioms at high.
+  // The thinker spans authority plan/follow-up and scout eval stages, so xhigh
+  // is the strongest safe static fallback; the manifest supplies max/high when
+  // dynamic effort is available. The executor is a work stage.
   'fvs-crypto-thinker': 'xhigh',
-  // The crypto executor is the dial-down implementation stage (vs the thinker's
-  // xhigh authoring) -- it executes a fully-specified plan, so it runs at high.
-  'fvs-crypto-executor': 'high',
+  'fvs-crypto-executor': 'xhigh',
   'fvs-axiom-auditor': 'high',
 };
 
@@ -762,7 +755,7 @@ function getCodexSkillAdapterHeader(skillName, options = {}) {
     : '';
   const typedModelNote = pluginName
     ? 'The marketplace plugin does not install Codex agent TOML. Use this mapping only when the exact FVS agent type is registered independently; otherwise use the bundled-agent workaround.'
-    : 'FVS bakes each agent\'s reasoning effort into its `.toml` at install time and the model is inherited from the user\'s Codex configuration.';
+    : 'Installed agent TOML supplies only a fallback effort; it does not prove that the command-level stage selection was applied.';
   const fallbackSteps = pluginName
     ? `1. Read \`\${CLAUDE_PLUGIN_ROOT}/agents/<agent-name>.md\` and extract its instructions. If the token is still literal, resolve the path from this SKILL.md as described above.\n2. Spawn a generic/default agent and inject those instructions as a role preamble before the task prompt.\n3. Label results clearly as \"generic-agent workaround\" so the user knows typed guarantees are not in effect.\n4. Where typed dispatch is mandatory for correctness, fail closed and report the schema limitation rather than silently degrading.`
     : `1. Resolve your active Codex config root (the directory containing your \`config.toml\`), then read \`agents/<agent-name>.toml\` relative to that root to extract the agent's instructions.\n2. Inject those instructions as a role-preamble into a generic \`spawn_agent(message=...)\` call.\n3. Label results clearly as \"generic-agent workaround\" so the user knows typed guarantees are not in effect.\n4. Where typed dispatch is mandatory for correctness, fail closed and report the schema limitation rather than silently degrading.`;
@@ -807,9 +800,15 @@ FVS workflows use \`Task(...)\` (Claude Code syntax). Translate to Codex collabo
 
 Before spawning, inspect the \`spawn_agent\` tool's visible parameter schema to determine which form is active.${typedDispatchQualification}
 
+Selection-capability gate (before manifest confirmation):
+- Compare the requested model with the exact active/inherited Codex model. Because \`spawn_agent\` has no inline model field, any different requested model is unresolved. Rebuild the manifest around the actual active model and ask explicitly, choose a capable external runner, or fail before dispatch in noninteractive mode.
+- When \`reasoning_effort\` is absent from the schema, compare the requested effort with the installed/runtime default. A mismatch is unresolved and follows the same rebuild/ask-or-fail rule.
+- Never confirm a requested model or effort and then omit it with a warning. ${typedModelNote}
+
 Typed mapping (agent_type-capable schema only):
 - \`Task(subagent_type="X", prompt="Y")\` -> \`spawn_agent(agent_type="X", message="Y")\`
-- \`Task(model="...")\` -> omit. \`spawn_agent\` has no inline \`model\` parameter. ${typedModelNote}
+- \`Task(model="...")\` -> omit only after the selection-capability gate proves it equals the active/inherited model.
+- \`Task(reasoning_effort="...")\` -> \`spawn_agent(reasoning_effort="...")\` when that field is present. If absent, dispatch only after the gate proves the installed/runtime default equals the confirmed effort.
 - \`fork_context: false\` by default -- FVS agents load their own context via \`<files_to_read>\` blocks.
 
 Generic-agent workaround (schema with NO agent_type field):
@@ -2639,11 +2638,14 @@ const MANIFEST_NAME = 'fvs-file-manifest.json';
 /**
  * Compute SHA256 hash of file contents
  */
-function fileHash(filePath) {
-  const content = fs.readFileSync(filePath);
+function contentHash(content) {
   return crypto.createHash('sha256').update(content).digest('hex');
 }
 
+function fileHash(filePath) {
+  return contentHash(fs.readFileSync(filePath));
+}
+
 /**
  * Recursively collect all files in dir with their hashes
  */
@@ -2710,12 +2712,25 @@ function writeManifest(configDir, runtime = 'claude') {
   return manifest;
 }
 
+function matchesGeneratedCodexAgentToml(configDir, rel, digest) {
+  if (!/^agents\/fvs-.*\.toml$/.test(rel)) return false;
+  const markdownPath = path.join(configDir, rel.replace(/\.toml$/, '.md'));
+  if (!fs.existsSync(markdownPath)) return false;
+  const converted = fs.readFileSync(markdownPath, 'utf8');
+  const { frontmatter, body } = extractFrontmatterAndBody(converted);
+  if (!frontmatter || !/<codex_agent_role>/.test(body)) return false;
+  const originalBody = body.replace(/^\s*<codex_agent_role>[\s\S]*?<\/codex_agent_role>\s*/, '');
+  const reconstructed = `---\n${frontmatter}\n---\n\n${originalBody}`;
+  const agentName = path.basename(rel, '.toml');
+  return contentHash(generateCodexAgentToml(agentName, reconstructed)) === digest;
+}
 
 /**
  * Detect user-modified FVS files by comparing against install manifest.
  * Backs up modified files to fvs-local-patches/ for reapply after update.
  */
 function saveLocalPatches(configDir, runtime = 'claude') {
+  fs.mkdirSync(configDir, { recursive: true });
   configDir = fs.realpathSync(configDir);
   const manifestPath = path.join(configDir, MANIFEST_NAME);
   // An unreadable baseline must stop the update before any destructive copy.
@@ -2725,7 +2740,12 @@ function saveLocalPatches(configDir, runtime = 'claude') {
     throw new Error('Invalid FVS manifest; repair it before updating. Existing files were preserved.');
   }
   const current = ownedFileHashes(configDir, runtime);
-  const modified = Object.keys(current).filter(rel => current[rel] !== manifest.files[rel]);
+  const modified = Object.keys(current).filter(rel => {
+    if (current[rel] === manifest.files[rel]) return false;
+    if (!Object.prototype.hasOwnProperty.call(manifest.files, rel) && runtime === 'codex' &&
+        matchesGeneratedCodexAgentToml(configDir, rel, current[rel])) return false;
+    return true;
+  });
   const patchesDir = path.join(configDir, PATCHES_DIR_NAME);
   if (fs.lstatSync(patchesDir, { throwIfNoEntry: false })?.isSymbolicLink()) {
     throw new Error('Local patch directory is a symlink; refusing to update');
@@ -2736,15 +2756,22 @@ function saveLocalPatches(configDir, runtime = 'claude') {
   const addBundle = (directory, meta) => {
     const hashes = generateManifest(directory);
     delete hashes['backup-meta.json'];
-    for (const rel of meta?.files ?? []) {
+    const listed = new Set(meta?.files ?? []);
+    const pending = new Set(meta?.pending ?? meta?.files ?? Object.keys(hashes));
+    for (const rel of listed) {
       if (!Object.prototype.hasOwnProperty.call(hashes, rel)) throw new Error(`Missing backed-up patch: ${rel}; refusing to update`);
       if (meta.hashes?.[rel] && meta.hashes[rel] !== hashes[rel]) {
         throw new Error(`Backed-up patch changed: ${rel}; inspect it before updating`);
       }
     }
     for (const rel of Object.keys(hashes)) {
-      if (meta && !meta.files?.includes(rel)) console.warn(`  Unlisted local patch recovered: ${rel}`);
-      sources.set(rel, { file: path.join(directory, rel), kind: meta?.kinds?.[rel] ?? 'legacy' });
+      if (meta && !listed.has(rel)) {
+        console.warn(`  Unlisted local patch recovered: ${rel}`);
+        pending.add(rel);
+      }
+      if (pending.has(rel)) {
+        sources.set(rel, { file: path.join(directory, rel), kind: meta?.kinds?.[rel] ?? 'legacy' });
+      }
     }
   };
   if (prior?.bundle) {
@@ -2777,8 +2804,9 @@ function saveLocalPatches(configDir, runtime = 'claude') {
   fs.mkdirSync(bundles, { recursive: true });
   const staging = fs.mkdtempSync(path.join(bundles, '.pending-'));
   const bundle = `bundles/bundle-${path.basename(staging).slice(9)}`;
-  const meta = { version: 2, bundle, backed_up_at: new Date().toISOString(),
-    from_version: manifest.version, files: [...sources.keys()].sort(), hashes: {}, kinds: {} };
+  const meta = { version: 3, bundle, backed_up_at: new Date().toISOString(),
+    from_version: manifest.version, files: [...sources.keys()].sort(), pending: [], hashes: {}, kinds: {} };
+  meta.pending = [...meta.files];
   for (const rel of meta.files) {
     const dest = path.join(staging, rel);
     fs.mkdirSync(path.dirname(dest), { recursive: true });
@@ -2808,7 +2836,8 @@ function reportLocalPatches(configDir, runtime = 'claude') {
   let meta;
   try { meta = JSON.parse(fs.readFileSync(metaPath, 'utf8')); } catch { return []; }
 
-  if (meta.files && meta.files.length > 0) {
+  const pending = meta.pending ?? meta.files ?? [];
+  if (pending.length > 0) {
     const reapplyCommand = runtime === 'opencode'
       ? '/fvs-reapply-patches'
       : runtime === 'codex'
@@ -2816,7 +2845,7 @@ function reportLocalPatches(configDir, runtime = 'claude') {
         : '/fvs:reapply-patches';
     console.log('');
     console.log('  ' + yellow + 'Local patches detected' + reset + ' (from v' + meta.from_version + '):');
-    for (const f of meta.files) {
+    for (const f of pending) {
       console.log('     ' + orange + f + reset);
     }
     console.log('');
@@ -2825,7 +2854,7 @@ function reportLocalPatches(configDir, runtime = 'claude') {
     console.log('  Or manually compare and merge the files.');
     console.log('');
   }
-  return meta.files || [];
+  return pending;
 }
 
 /**

package/commands/fvs/aeneas-extract.md

@@ -47,27 +47,22 @@ idempotent and skips already-clean blockers. There is no separate status/resume
 
 <process>
 
-## Step 1: Read config and resolve subagent models
+## Step 1: Read config and resolve subagent models + effort
 
-Read the project config and resolve the model for each subagent dispatch using the
-model-profiles dispatch sequence (config `model_overrides` first, then the profile table,
-then `inherit` for unknown agents):
+Read the complete project config and apply the canonical resolution contract in
+`model-profiles.md`. Declare these stage keys rather than deriving tiers from agent names:
 
-```bash
-CONFIG=$(cat .formalising/fvs-config.json 2>/dev/null)
-# profile = config.model_profile || "balanced"
-# for each agent: model = model_overrides[agent] ?? PROFILE_TABLE[agent][profile]
-```
-
-Resolve and store:
-- `$CLASSIFIER_MODEL` for `fvs-extract-classifier`
-- `$APPLIER_MODEL` for `fvs-extract-applier`
-- `$BISECTOR_MODEL` for `fvs-extract-bisector`
-- `$ASSESSOR_MODEL` for `fvs-equivalence-assessor`
-- `$DRAFT_MODEL` for `fvs-draft-investigator`
+- `fvs-extract-classifier` -> `extract_classify`
+- `fvs-extract-applier` -> `extract_apply`
+- `fvs-extract-bisector` -> `extract_bisect`
+- `fvs-equivalence-assessor` -> `extract_assess`
+- `fvs-draft-investigator` -> `extract_investigate`
 
-On Codex (which does not support dynamic model selection) the `model=` parameter is silently
-ignored; the same dispatches work unchanged.
+Resolve model and effort independently for every distinct stage. Before the first dispatch, show
+one command-level selection manifest and obtain confirmation. `Adjust once` changes only this run;
+`Save override` writes the exact runtime+stage entry. Notes rebuild the manifest and require
+reconfirmation. Missing preferred models or unsupported efforts prompt interactively and fail with
+exact remediation in noninteractive mode. Pass only validated native model/effort fields.
 
 ## Step 2: PRE-FLIGHT (pin audit + clone resolution)
 
@@ -117,13 +112,13 @@ fix escalates immediately).
 - **EXTRACT:** run extraction and build under `set -o pipefail` + `LEAN_NUM_THREADS="${LEAN_NUM_THREADS:-4}" nice -n 19 lake build`;
   read the tool's real exit status via `${PIPESTATUS[0]}`, never the tail of a piped log.
   Clean -> success oracle (Step 5). Failure -> classify.
-- **CLASSIFY:** `Task(subagent_type="fvs-extract-classifier", model="$CLASSIFIER_MODEL", ...)`
+- **CLASSIFY:** `Task(subagent_type="fvs-extract-classifier", model="$CLASSIFIER_MODEL", reasoning_effort="$CLASSIFIER_EFFORT", ...)`
   -> `{ layer, symbol, signature, match }`.
 - **DISPATCH by category + coverage_impact:**
-  - Category-A -> `Task(subagent_type="fvs-extract-applier", model="$APPLIER_MODEL", ...)`.
+  - Category-A -> `Task(subagent_type="fvs-extract-applier", model="$APPLIER_MODEL", reasoning_effort="$APPLIER_EFFORT", ...)`.
     The coverage-escalation guard: A-opacity on a function inside required coverage is NOT
     auto-applied -- it becomes Category-B and routes to the gate.
-  - NOVEL -> `Task(subagent_type="fvs-extract-bisector", model="$BISECTOR_MODEL", ...)` to
+  - NOVEL -> `Task(subagent_type="fvs-extract-bisector", model="$BISECTOR_MODEL", reasoning_effort="$BISECTOR_EFFORT", ...)` to
     minimize to an MFE, write a schema-conformant candidate, and PROPOSE a fix.
   - Forced Category-B -> the GATE (Step 4).
   - Escalate conditions (attempt-cap hit, same-signature recurrence, forced
@@ -146,6 +141,7 @@ a fixing subagent:
 
    ```
    Task(subagent_type="fvs-equivalence-assessor", model="$ASSESSOR_MODEL",
+        reasoning_effort="$ASSESSOR_EFFORT", // when supported; otherwise apply the capability gate
         description="Draft equivalence-gate packet sections 2-6",
         prompt="...minimized diff (section 1) + the blocker context...")
    ```
@@ -182,6 +178,7 @@ ONLY on the user's acceptance -- on acceptance dispatch the draft-investigator:
 
 ```
 Task(subagent_type="fvs-draft-investigator", model="$DRAFT_MODEL",
+     reasoning_effort="$DRAFT_EFFORT", // when supported; otherwise apply the capability gate
      description="Mine precedent + draft an evidence-cited HTML+MD report",
      prompt="...the MFE + the escalation context...")
 ```
@@ -213,8 +210,9 @@ On Codex, every interactive HALT in this command -- the pin-audit warn-and-confi
 the Category-B gate presentation (Step 4), and the escalation draft offer (Step 6) -- degrades
 to a plain-text question and WAITS for the user. It is fail-closed: it never auto-picks a
 default, never self-ratifies a gate packet, and never writes an upstream artifact. The
-`Task(...)` dispatches survive intact (the `model=` parameter is silently ignored on Codex,
-per model-profiles runtime handling).
+Before any Codex dispatch, apply the model-profile capability gate: confirm only the actual
+active/inherited model and applicable effort, or fail before dispatch. Never silently ignore a
+confirmed field.
 </codex_skill_adapter>
 
 <success_criteria>

package/commands/fvs/configure.md

@@ -0,0 +1,159 @@
+---
+name: fvs:configure
+description: Configure runtime-aware FVS stage models, effort levels, and review defaults
+argument-hint: ""
+allowed-tools:
+  - Read
+  - Write
+  - Edit
+  - Bash
+  - AskUserQuestion
+---
+
+<objective>
+Edit `.formalising/fvs-config.json` through bounded choice menus. Store exact runtime model IDs only
+when the runtime reports them, keep quality role-aware by stage, preserve one-run user control, and
+preserve unrelated project configuration.
+</objective>
+
+<execution_context>
+@~/.claude/fv-skills/references/model-profiles.md
+@~/.claude/fv-skills/templates/config.json
+</execution_context>
+
+<process>
+
+## 1. Load without clobbering
+
+Read `.formalising/fvs-config.json` when it exists; otherwise start from the shipped template. Reject
+malformed JSON and stop before writing. Preserve unknown keys and every unrelated nested value.
+Never replace the whole file with a partial settings object.
+
+Add missing current-schema containers without deleting old settings: `stage_overrides`,
+`model_overrides`, `effort_overrides`, `spec_review`, and `crypto_review`.
+
+## 2. Detect runtime, provider, and catalog
+
+Prefer explicit host identity over directory guesses:
+
+1. `PI_CODING_AGENT=true` or `AI_AGENT=pi` means Pi.
+2. A host adapter or `AI_AGENT` value naming Claude, Codex, OpenCode, or Gemini wins next.
+3. If identity is still unknown, ask which runtime is being configured.
+
+Read the runtime's current model catalog or picker. On Pi, `pi --list-models` is the CLI fallback.
+Keep Pi IDs provider-qualified and identify its active provider. Never invent or persist a guessed
+slug. Read the canonical quality stage and runtime matrices from `model-profiles.md`; do not copy or
+weaken them here.
+
+For ordinary Pi stages, stay within the active provider. Review routing is configured separately and
+may use an authenticated opposite-runtime CLI. Never treat a Claude Code subscription as a Pi
+Anthropic credential.
+
+## 3. Main settings menu
+
+Use `AskUserQuestion` and repeat until the user saves or cancels. Retain the question UI's notes or
+custom-answer path. Present at most these four choices:
+
+- **Profile** — choose `quality`, `balanced`, or `budget`.
+- **Stage overrides** — configure one exact canonical stage for the active runtime.
+- **Advanced defaults** — open agent-compatibility or review-default settings.
+- **Save/exit** — preview, save, discard, or continue.
+
+If structured questions are unavailable, print the same numbered choices plus a notes/custom line,
+then stop and wait. Never select on the user's behalf.
+
+## 4. Configure a stage override
+
+Read stage keys and tiers from the sole canonical table in `model-profiles.md`. First choose a tier,
+then a stage in that tier. Do not infer a stage from an agent name.
+
+Show the quality recommendation for the detected runtime/provider as an exact catalog match. The
+model menu offers:
+
+1. the exact detected quality model when available;
+2. `inherit`;
+3. up to one other detected runtime/provider model;
+4. catalog/custom selection.
+
+If the preferred model is absent, show the detected catalog and require a choice; do not silently
+choose a lower family. Custom input must exactly match a catalog entry. On Pi it must include the
+provider. For ordinary Pi stages, reject entries whose catalog provider differs from the active
+provider; review stages use their separate opposite-provider policy.
+
+For effort, offer every value the selected catalog model reports as supported, with the stage
+tier's quality effort first. Never advertise a value the model cannot accept. Save either or both fields under:
+
+```
+stage_overrides[runtime][stage] = { model?, effort? }
+```
+
+Removing both fields removes the stage entry. A saved stage override affects only that runtime and
+stage.
+
+## 5. Configure advanced defaults
+
+Use a submenu with at most three choices: **Agent compatibility**, **Review defaults**, **Back**.
+
+### Agent compatibility
+
+Existing broad overrides remain available for projects that need one setting across several
+stages. Choose one shipped agent and store exact values under
+`model_overrides[runtime][agent]` / `effort_overrides[runtime][agent]`. Explain that a stage override
+wins and is preferred when a shared agent performs different roles.
+
+Shipped groups:
+
+- FC: `fvs-researcher`, `fvs-executor`, `fvs-lean-refactorer`, `fvs-explainer`.
+- Crypto: `fvs-crypto-thinker`, `fvs-crypto-executor`.
+- Extraction: `fvs-extract-classifier`, `fvs-extract-applier`, `fvs-extract-bisector`,
+  `fvs-equivalence-assessor`, `fvs-draft-investigator`, `fvs-doc-syncer`.
+- Audit: `fvs-axiom-auditor`.
+
+### Review defaults
+
+Choose `spec_review`, `crypto_review`, or both. Null reviewer/model/effort values keep role-aware
+profile routing and the per-command confirmation active. For each explicit saved review setting:
+
+1. choose reviewer runtime `codex`, `claude`, `pi`, or `other` (`pi` only when the active host is Pi and the selected provider is authenticated);
+2. choose an exact model from that reviewer's catalog;
+3. choose a supported effort;
+4. keep `automatic` unchanged unless explicitly edited.
+
+Quality recommends the authenticated opposite provider/runtime and its authority-tier model+effort.
+On Pi, OpenAI review of Claude-authored work prefers a fresh provider-qualified Pi seat only when
+the child facility can honor and report the exact per-child model/effort, then Codex CLI. Review of
+OpenAI-authored work uses authenticated Claude Code CLI when available. If the opposite runner is
+unavailable, do not silently save a same-runtime fallback.
+
+## 6. Preview and save
+
+Show all changed keys and a selection preview. Ask for confirmation with `Save`, `Continue editing`,
+`Discard`, and `Cancel`. Notes rebuild the preview and require another confirmation.
+
+Create `.formalising/` if needed, serialize with two-space indentation and a trailing newline,
+validate the complete JSON in a temporary file, then atomically replace
+`.formalising/fvs-config.json`. On validation or write failure, leave the old file untouched.
+
+Report runtime/provider, profile, changed stage/agent/review settings, and precedence:
+
+1. explicit one-run selection;
+2. saved review value for review stages;
+3. runtime+stage override;
+4. runtime+agent compatibility override;
+5. profile/catalog resolution.
+
+Also report that missing preferred models, ordinary-Pi provider mismatches, unsupported efforts,
+and unavailable per-child controls prompt interactively, while noninteractive unresolved choices
+fail before dispatch with exact remediation.
+
+</process>
+
+<success_criteria>
+- [ ] Runtime/provider identified explicitly; every concrete model came from its current catalog.
+- [ ] Ordinary Pi stage overrides use the active provider; review overrides follow review routing.
+- [ ] Quality recommendations use the canonical authority/work/scout matrices.
+- [ ] Stage overrides are stored under the exact runtime+stage key and win over agent overrides.
+- [ ] Choice menus expose notes and reconfirm after notes change the preview.
+- [ ] Review defaults may remain null so opposite-runtime profile routing stays active.
+- [ ] Unknown config keys were preserved and malformed JSON was never overwritten.
+</success_criteria>