fv-skills-baif 2.3.2 → 2.3.4

package/commands/fvs/lean-formalise.md

@@ -160,23 +160,16 @@ mkdir -p "$PROOF_ENG_ROOT/lessons/fc" "$PROOF_ENG_ROOT/lessons/crypto" \
   cp ~/.claude/fv-skills/templates/proof-engineering-index.md "$PROOF_ENG_INDEX"
 ```
 
-## Step 3: Read Config and Resolve Models
+## Step 3: Read Config and Resolve Models + Effort
 
-Read the project config to determine which models to use for subagent dispatch:
+Read the complete config and apply `model-profiles.md`. This command declares `fc_proof_plan` for
+the structure/planning `fvs-researcher` and `fc_spec` for the Lean-definition/spec-authoring
+`fvs-executor`. Resolve each stage independently; do not choose tiers from the shared agent names.
 
-```bash
-CONFIG=$(cat .formalising/fvs-config.json 2>/dev/null || echo '{"model_profile":"quality","model_overrides":{}}')
-```
-
-Resolve models using the profile table from `fv-skills/references/model-profiles.md`:
-
-1. Parse `model_profile` from config (default: `"quality"`)
-2. Check `model_overrides` for `"fvs-researcher"` and `"fvs-executor"`
-3. If no override, look up profile table:
-   - quality: fvs-researcher=inherit, fvs-executor=inherit
-   - balanced: fvs-researcher=sonnet, fvs-executor=sonnet
-   - budget: fvs-researcher=haiku, fvs-executor=sonnet
-4. Store resolved models as `RESEARCH_MODEL` and `EXECUTOR_MODEL`
+Before dispatch, show one command-level selection manifest containing both authority stages and
+obtain confirmation. Offer one-run adjustment, exact-stage Save override, notes that rebuild and
+reconfirm the manifest, and Cancel. Missing preferred models or unsupported efforts prompt
+interactively; noninteractive unresolved choices fail before dispatch with exact remediation.
 
 ## Step 4: Read Reference Files for Inlining
 
@@ -208,6 +201,7 @@ If no Aeneas markers: skip aeneas-patterns (paper track may be pure math, not Ae
 Task(
   subagent_type="fvs-researcher",
   model="$RESEARCH_MODEL",
+  reasoning_effort="$RESEARCH_EFFORT", // when supported; otherwise apply the capability gate
   description="Research context for formalisation: $TASK_DESCRIPTION",
   prompt="Research mode: formalise
 
@@ -284,6 +278,7 @@ Use AskUserQuestion. If user adjusts: incorporate feedback before dispatching ex
 Task(
   subagent_type="fvs-executor",
   model="$EXECUTOR_MODEL",
+  reasoning_effort="$EXECUTOR_EFFORT", // when supported; otherwise apply the capability gate
   description="Create Lean files for formalisation: $TASK_DESCRIPTION",
   prompt="Execute mode: formalise
 

package/commands/fvs/lean-refactor.md

@@ -112,23 +112,16 @@ TACTIC_LINES=$(grep -cE "^\s+(unfold|step|simp|agrind|scalar_tac|ring|field_simp
 echo "Baseline: $TOTAL_LINES lines, $THEOREM_COUNT theorems, $TACTIC_LINES tactic lines"
 ```
 
-## Step 3: Read Config and Resolve Models
+## Step 3: Read Config and Resolve Models + Effort
 
-Read the project config to determine which models to use for subagent dispatch:
+Read the complete config and apply `model-profiles.md`. Declare `research` for
+`fvs-researcher` and `lean_refactor` for `fvs-lean-refactorer`; resolve both stages independently
+rather than deriving tiers from agent names.
 
-```bash
-CONFIG=$(cat .formalising/fvs-config.json 2>/dev/null || echo '{"model_profile":"quality","model_overrides":{}}')
-```
-
-Resolve models using the profile table from `fv-skills/references/model-profiles.md`:
-
-1. Parse `model_profile` from config (default: `"quality"`)
-2. Check `model_overrides` for `"fvs-researcher"` and `"fvs-lean-refactorer"`
-3. If no override, look up profile table:
-   - quality: fvs-researcher=inherit, fvs-lean-refactorer=inherit
-   - balanced: fvs-researcher=sonnet, fvs-lean-refactorer=sonnet
-   - budget: fvs-researcher=haiku, fvs-lean-refactorer=sonnet
-4. Store resolved models as `RESEARCH_MODEL` and `REFACTORER_MODEL`
+Before dispatch, show one command-level selection manifest with both stages and obtain confirmation.
+Offer one-run adjustment, exact-stage Save override, notes that rebuild and reconfirm the manifest,
+and Cancel. Missing preferred models or unsupported efforts prompt interactively; noninteractive
+unresolved choices fail before dispatch with exact remediation.
 
 ## Step 4: Read Reference Files for Inlining
 
@@ -148,6 +141,7 @@ All three must be captured as content strings for inlining into subagent prompts
 Task(
   subagent_type="fvs-researcher",
   model="$RESEARCH_MODEL",
+  reasoning_effort="$RESEARCH_EFFORT", // when supported; otherwise apply the capability gate
   description="Research refactoring context for $SPEC_FILE",
   prompt="Research mode: lean-refactor
 
@@ -201,6 +195,7 @@ WHILE PASS < MAX_PASSES:
   Task(
     subagent_type="fvs-lean-refactorer",
     model="$REFACTORER_MODEL",
+    reasoning_effort="$REFACTORER_EFFORT", // when supported; otherwise apply the capability gate
     description="Refactor {theorem_name} pass {PASS+1}",
     prompt="<refactoring_reference>$LEAN_REFACTORING_CONTENT</refactoring_reference>
     <research_findings>$RESEARCH_OUTPUT</research_findings>

package/commands/fvs/lean-spec-review.md

@@ -1,7 +1,7 @@
 ---
 name: fvs:lean-spec-review
 description: Adversarially review an FC Lean specification with a chosen runtime, model, and effort
-argument-hint: "<spec.lean> [--reviewer codex|claude|other] [--model ID] [--effort LEVEL]"
+argument-hint: "<spec.lean> [--reviewer codex|claude|pi|other] [--model ID] [--effort LEVEL]"
 allowed-tools:
   - Read
   - Bash
@@ -20,6 +20,7 @@ runtime, model, and effort menu; preserve the spec and record the review and fin
 <execution_context>
 @~/.claude/fv-skills/workflows/lean-spec-review.md
 @~/.claude/fv-skills/references/fc-spec-review.md
+@~/.claude/fv-skills/references/model-profiles.md
 </execution_context>
 
 <process>
@@ -27,10 +28,30 @@ Follow the review workflow with `$ARGUMENTS`. Explicit invocation always runs th
 even when `spec_review.automatic` is false. Automatic invocation from `lean-specify` enters the
 same workflow after generation checks, with the resolved spec/source paths and author runtime.
 
-Honor explicit reviewer/model/effort choices. Supplying all three standalone flags is the
-non-interactive path; otherwise ask only for missing choices in order: reviewer -> model -> effort.
-Automatic callers record `Skip review` exactly as `Unreviewed (user skipped)` and do not auto-start
-proof work.
+Declare authority stage `spec_review` and apply `model-profiles.md`. Precedence is explicit one-run
+flags, non-null `spec_review.reviewer` / `spec_review.model` / `spec_review.effort`, then the quality
+opposite-runtime recommendation. Null saved values keep profile routing active.
+
+Detect the specification authoring runtime. Recommend an authenticated opposite provider/runtime:
+OpenAI/Codex-authored specs use Claude Code CLI; Claude-authored specs use a fresh
+provider-qualified OpenAI Pi seat when running in Pi, then Codex CLI. Unknown authors receive an
+explicit reviewer menu without an independence claim. Never route a Claude Code subscription
+through Pi. The `pi` reviewer is available only inside Pi with a provider-qualified model from its
+live authenticated catalog and a fresh-child facility that can honor and report the exact per-child
+model/effort. It launches a fresh read-only child, never a manual Other packet. Persistence requires
+the workflow's completed-child receipt with actual run ID/model/effort and packet/response hashes;
+missing capability or evidence leaves the review pending.
+
+Build one review selection manifest containing reviewer runner, provenance, exact catalog model,
+and effort. Confirm it before launch with Continue once, Adjust once, Save override, or Cancel;
+retain notes. Notes rebuild the manifest and require reconfirmation. Save writes only the
+`spec_review` object. Offer every effort value the selected model/provider reports as supported.
+Missing models or unsupported efforts ask for one-run/save/cancel; unresolved noninteractive
+choices fail before launch with exact remediation.
+
+If no opposite runner is authenticated, ask among setup/retry, fresh same-runtime review, Other
+handoff, one-run skip, or cancel; never switch silently. A one-run skip records exactly
+`Unreviewed (user skipped)`, stops at the review boundary, and does not auto-start proof work.
 
 The reviewer is read-only; the `lean-specify` authoring seat keeps `review.md` unchanged and writes
 separate `triage.md` with finding IDs, old/new hashes (pre-edit/post-edit), and rerun structure,

package/commands/fvs/lean-specify.md

@@ -112,23 +112,16 @@ if [ "$CACHE_STATUS" -ne 0 ]; then
 fi
 ```
 
-## Step 3: Read Config and Resolve Models
+## Step 3: Read Config and Resolve Models + Effort
 
-Read the project config to determine which models to use for subagent dispatch:
+Read the complete config and apply `model-profiles.md`. Declare `research` for the implementation
+analysis `fvs-researcher` and `fc_spec` for the specification-authoring `fvs-executor`. Resolve both
+stages independently rather than deriving tiers from shared agent names.
 
-```bash
-CONFIG=$(cat .formalising/fvs-config.json 2>/dev/null || echo '{"model_profile":"quality","model_overrides":{}}')
-```
-
-Resolve models using the profile table from `fv-skills/references/model-profiles.md`:
-
-1. Parse `model_profile` from config (default: `"quality"`)
-2. Check `model_overrides` for `"fvs-researcher"` and `"fvs-executor"`
-3. If no override, look up profile table:
-   - quality: fvs-researcher=inherit, fvs-executor=inherit
-   - balanced: fvs-researcher=sonnet, fvs-executor=sonnet
-   - budget: fvs-researcher=haiku, fvs-executor=sonnet
-4. Store resolved models as `RESEARCH_MODEL` and `EXECUTOR_MODEL`
+Before dispatch, show one command-level selection manifest with both stages and obtain confirmation.
+Offer one-run adjustment, exact-stage Save override, notes that rebuild and reconfirm the manifest,
+and Cancel. Missing preferred models or unsupported efforts prompt interactively; noninteractive
+unresolved choices fail before dispatch with exact remediation.
 
 ## Step 4: Discover and Load the Target Style Guide
 
@@ -174,6 +167,7 @@ target style guide from Step 4 must be inlined separately into BOTH prompts.
 Task(
   subagent_type="fvs-researcher",
   model="$RESEARCH_MODEL",
+  reasoning_effort="$RESEARCH_EFFORT", // when supported; otherwise apply the capability gate
   description="Research context for spec generation of $FUNCTION_NAME",
   prompt="Research mode: spec-generation
 
@@ -230,6 +224,7 @@ Parse the returned research findings for use by the executor.
 Task(
   subagent_type="fvs-executor",
   model="$EXECUTOR_MODEL",
+  reasoning_effort="$EXECUTOR_EFFORT", // when supported; otherwise apply the capability gate
   description="Generate spec for $FUNCTION_NAME",
   prompt="Execute mode: spec-generation
 

package/commands/fvs/lean-verify.md

@@ -115,23 +115,16 @@ if [ "$CACHE_STATUS" -ne 0 ]; then
 fi
 ```
 
-## Step 2: Read Config and Resolve Models
+## Step 2: Read Config and Resolve Models + Effort
 
-Read the project config to determine which models to use for subagent dispatch:
+Read the complete config and apply `model-profiles.md`. Declare `fc_proof_plan` for the proof
+strategy `fvs-researcher` and `fc_proof_execution` for the proving `fvs-executor`. Resolve both
+stages independently rather than deriving tiers from shared agent names.
 
-```bash
-CONFIG=$(cat .formalising/fvs-config.json 2>/dev/null || echo '{"model_profile":"quality","model_overrides":{}}')
-```
-
-Resolve models using the profile table from `fv-skills/references/model-profiles.md`:
-
-1. Parse `model_profile` from config (default: `"quality"`)
-2. Check `model_overrides` for `"fvs-researcher"` and `"fvs-executor"`
-3. If no override, look up profile table:
-   - quality: fvs-researcher=inherit, fvs-executor=inherit
-   - balanced: fvs-researcher=sonnet, fvs-executor=sonnet
-   - budget: fvs-researcher=haiku, fvs-executor=sonnet
-4. Store resolved models as `RESEARCH_MODEL` and `EXECUTOR_MODEL`
+Before dispatch, show one command-level selection manifest with both stages and obtain confirmation.
+Offer one-run adjustment, exact-stage Save override, notes that rebuild and reconfirm the manifest,
+and Cancel. Missing preferred models or unsupported efforts prompt interactively; noninteractive
+unresolved choices fail before dispatch with exact remediation.
 
 ## Step 3: Discover the Target Style Guide and Capture a Baseline
 
@@ -212,6 +205,7 @@ grep -E "@\[step\]|theorem " "$SPEC_PATH"
 Task(
   subagent_type="fvs-researcher",
   model="$RESEARCH_MODEL",
+  reasoning_effort="$RESEARCH_EFFORT", // when supported; otherwise apply the capability gate
   description="Research proof context for $SPEC_FILE",
   prompt="Research mode: proof-attempt
 
@@ -286,6 +280,7 @@ FOR EACH SORRY (in recommended order from research):
     Task(
       subagent_type="fvs-executor",
       model="$EXECUTOR_MODEL",
+      reasoning_effort="$EXECUTOR_EFFORT", // when supported; otherwise apply the capability gate
       description="Prove sorry {N} in $SPEC_FILE",
       prompt="Execute mode: proof-attempt
 

package/commands/fvs/manage.md

@@ -1,11 +1,11 @@
 ---
 name: fvs:manage
-description: "management | help update checkpoint pause resume patches kb"
+description: "management | help configure update checkpoint pause resume patches kb"
 argument-hint: ""
 allowed-tools:
   - Read
   - Skill
-requires: [help, update, checkpoint, pause-work, resume-work, reapply-patches, kb-setup]
+requires: [help, configure, update, checkpoint, pause-work, resume-work, reapply-patches, kb-setup]
 ---
 
 Route to the appropriate management skill based on the user's intent.
@@ -15,6 +15,7 @@ When invoked WITH a request, match it against the table below and invoke the mat
 | User wants | Invoke |
 |---|---|
 | Show the FVS command reference | fvs:help |
+| Configure subagent models, effort, and review defaults | fvs:configure |
 | Update FVS to the latest version | fvs:update |
 | Checkpoint current verification progress | fvs:checkpoint |
 | Pause work and write a handoff doc | fvs:pause-work |

package/commands/fvs/map-code.md

@@ -95,26 +95,15 @@ If .formalising/ already exists, ask user whether to refresh CODEMAP.md or abort
 
 ## Step 3: Read config and resolve models
 
-Read the project config to determine which models to use for subagent dispatch:
+Read the complete config and apply `model-profiles.md`. Both the read-only researcher and the
+map-writing executor use stage key `map_code`: the output is a code map, not authority or proof
+execution. Resolve one stage selection and reuse it for both agents unless an explicit one-run
+adjustment says otherwise.
 
-```bash
-CONFIG=$(cat .formalising/fvs-config.json 2>/dev/null)
-```
-
-If config exists, extract `model_profile` and `model_overrides`.
-If config is missing, use defaults: `model_profile = "quality"`, no overrides.
-
-**Resolve models from profile table** (see fv-skills/references/model-profiles.md):
-
-For `fvs-researcher`:
-- Check `model_overrides["fvs-researcher"]` first
-- Otherwise use profile table: quality=inherit, balanced=sonnet, budget=haiku
-
-For `fvs-executor`:
-- Check `model_overrides["fvs-executor"]` first
-- Otherwise use profile table: quality=inherit, balanced=sonnet, budget=sonnet
-
-Store resolved models as `$RESEARCH_MODEL` and `$EXECUTOR_MODEL`.
+Before dispatch, show and confirm the command-level selection manifest. Offer one-run adjustment,
+exact-stage Save override, notes that rebuild and reconfirm the manifest, and Cancel. Missing
+preferred models or unsupported efforts prompt interactively; noninteractive unresolved choices
+fail before dispatch with exact remediation.
 
 ## Step 4: Generate the canonical function inventory
 
@@ -200,6 +189,7 @@ Spawn the research subagent to annotate the canonical functions:
 Task(
   subagent_type="fvs-researcher",
   model="$RESEARCH_MODEL",
+  reasoning_effort="$RESEARCH_EFFORT", // when supported; otherwise apply the capability gate
   description="Map codebase dependencies",
   prompt="Research mode: map-code
 
@@ -264,6 +254,7 @@ Spawn the executor subagent with research findings:
 Task(
   subagent_type="fvs-executor",
   model="$EXECUTOR_MODEL",
+  reasoning_effort="$EXECUTOR_EFFORT", // when supported; otherwise apply the capability gate
   description="Write CODEMAP.md",
   prompt="Execute mode: map-code
 

package/commands/fvs/natural-language.md

@@ -71,9 +71,17 @@ Or run /fvs:map-code to build the function index.
 
 Wait for user clarification.
 
-## Step 2: Read Reference Files for Agent Dispatch
+## Step 2: Resolve Runtime Settings and Read References
 
-Read the three reference files. These MUST be inlined into the Task() prompt because @-references do NOT cross Task boundaries.
+Read `fv-skills/references/model-profiles.md` and declare stage key `explain` for
+`fvs-explainer`. Resolve the exact runtime/provider model and effort through the canonical
+precedence. Before dispatch, show and confirm the command-level selection manifest. Offer one-run
+adjustment, exact-stage Save override, notes that rebuild and reconfirm the manifest, and Cancel.
+Missing preferred models or unsupported efforts prompt interactively; noninteractive unresolved
+choices fail before dispatch with exact remediation.
+
+Read the three domain reference files. These MUST be inlined into the Task() prompt because
+@-references do NOT cross Task boundaries.
 
 ```bash
 AENEAS_PATTERNS=$(cat ~/.claude/fv-skills/references/aeneas-patterns.md)
@@ -101,6 +109,8 @@ Display dispatch indicator:
 
 ```
 Task(
+  model="$EXPLAINER_MODEL",
+  reasoning_effort="$EXPLAINER_EFFORT", // when supported; otherwise apply the capability gate
   prompt="Analyze function for natural-language explanation.
 
 <rust_module>

package/commands/fvs/reapply-patches.md

@@ -21,16 +21,19 @@ manifest. For local installs this is under the project runtime directory; for
 global installs use that runtime’s configured root (including custom config roots).
 Do not search unrelated runtimes or prefer a global backup over the active local one.
 
-Read `backup-meta.json` from the patches directory. For version 2, resolve its `bundle`
-relative to that directory (strictly `bundles/bundle-<id>`). This immutable bundle is
-the source for the file copies below. Legacy metadata refers to the flat directory.
+Read `backup-meta.json` from the patches directory. For version 2 or 3, resolve its `bundle`
+relative to that directory (strictly `bundles/bundle-<id>`). This immutable bundle is the source
+for file copies below. Version 3 uses `pending` as the active reapply set and keeps `files` as the
+historical bundle inventory; version 2 treats every `files` entry as pending. Legacy metadata refers
+to the flat directory.
 Check canonical paths remain inside the selected installation and reject symlinks.
 
-Before merging, enumerate every file in the bundle, excluding its `backup-meta.json`.
-Compare the enumeration with `files` and verify `hashes` when present. Report every
-unlisted file and every missing or changed entry; never silently omit them. Stop for
-user inspection on missing/changed entries. Offer unlisted legacy files for recovery.
-Older immutable bundles and legacy flat copies remain available for inspection.
+Before merging, enumerate every file in the bundle, excluding its `backup-meta.json`. Compare the
+enumeration with historical `files` and verify `hashes` when present. Report every unlisted file and
+every missing or changed entry; never silently omit them. Stop for user inspection on
+missing/changed entries. Offer unlisted legacy files for recovery. Process only `pending` (or
+version-2 `files`) as active patches. Older immutable bundles and resolved entries remain available
+for inspection without being copied into the next active set.
 
 **If no patches found:**
 ```
@@ -58,7 +61,7 @@ Exit.
 
 ## Step 3: Merge each file
 
-For each file in `backup-meta.json`:
+For each active file in `pending` (or version-2 `files`):
 
 1. **Read the backed-up version** (user's modified copy from `fvs-local-patches/`)
 2. **Read the newly installed version** (current file after update)
@@ -88,21 +91,24 @@ For each file in `backup-meta.json`:
    - `Skipped` -- modification already in upstream
    - `Conflict` -- user chose resolution
 
-## Step 4: Update manifest
+## Step 4: Retire processed active entries
 
-After reapplying, note that the manifest will be regenerated on the next `/fvs:update`:
+After each file reaches a final outcome (`Merged`, `Skipped (already upstream)`, or an explicit
+choice to keep the new upstream file), atomically rewrite the top-level `backup-meta.json` as
+version 3 with that path removed from `pending`. Preserve `bundle`, historical `files`, `hashes`,
+`kinds`, and the immutable bundle contents. A conflict the user defers remains pending.
 
-```bash
-# The manifest will be regenerated on next /fvs:update
-# For now, just note which files were modified
-```
+When `pending` becomes empty, keep the pointer with `pending: []` so the selected bundle remains
+historical evidence. The next update must not reactivate or copy those resolved entries. A newly
+modified installed file will still be detected independently against `fvs-file-manifest.json`.
 
 ## Step 5: Cleanup option
 
 Ask user:
-- "Keep patch backups for reference?" -- preserve `fvs-local-patches/`
-- "Clean up selected patch bundle?" -- name the exact bundle; delete it only after
-  explicit approval, without deleting older bundles or dangling the active pointer.
+- "Keep patch backups for reference?" -- preserve `fvs-local-patches/`; this never keeps resolved
+  entries active.
+- "Clean up selected patch bundle?" -- only when its `pending` set is empty; name the exact bundle
+  and delete it after explicit approval without deleting older bundles or dangling the pointer.
 
 ## Step 6: Report
 
@@ -121,8 +127,9 @@ Ask user:
 </process>
 
 <success_criteria>
-- [ ] All backed-up patches processed
-- [ ] User modifications merged into new version
-- [ ] Conflicts resolved with user input
+- [ ] Every active pending patch processed or explicitly left pending
+- [ ] User modifications merged into the new version
+- [ ] Resolved/upstream-chosen entries removed from `pending` without deleting historical bundles
+- [ ] Conflicts resolved with user input or kept pending
 - [ ] Status reported for each file
 </success_criteria>

package/commands/fvs/sync-aeneas-verif.md

@@ -90,18 +90,14 @@ of every normal runtime install. If the preflight fails, STOP before all later s
 
 ## Step 1: Read config and resolve subagent model
 
-Read the project config and resolve the model for the `fvs-doc-syncer` dispatch using the
-model-profiles dispatch sequence (config `model_overrides` first, then the profile table, then
-`inherit` for unknown agents):
+Read the complete config and apply `model-profiles.md`. Declare stage key `doc_sync` for every
+`fvs-doc-syncer` mode and resolve one exact runtime/provider model+effort selection.
 
-```bash
-CONFIG=$(cat .formalising/fvs-config.json 2>/dev/null)
-# profile = config.model_profile || "balanced"
-# SYNCER_MODEL = model_overrides["fvs-doc-syncer"] ?? PROFILE_TABLE["fvs-doc-syncer"][profile]
-```
-
-On Codex (which does not support dynamic model selection) the `model=` parameter is silently
-ignored; the dispatches work unchanged.
+Before the first dispatch, show and confirm the command-level selection manifest. Offer one-run
+adjustment, exact-stage Save override, notes that rebuild and reconfirm the manifest, and Cancel.
+Missing preferred models or unsupported efforts prompt interactively; noninteractive unresolved
+choices fail before dispatch with exact remediation. Pass only native fields the selected runtime
+actually supports.
 
 ## Step 2: Resolve the local clones (config -> auto-detect -> prompt -> error)
 
@@ -159,6 +155,7 @@ the `tactic_renames` table (the parent inlines all reference content; the worker
 
 ```
 Task(subagent_type="fvs-doc-syncer", model="$SYNCER_MODEL",
+     reasoning_effort="$SYNCER_EFFORT", // when supported; otherwise apply the capability gate
      description="Sync tactics + Lean-syntax docs (mode a)",
      prompt="<sync_mode>tactics-lean-syntax</sync_mode>
              ...inlined _sync-meta.json mapping + tactic_renames + snapshot SHA + the
@@ -178,6 +175,7 @@ extraction doc targets and the current `blocker-catalog.md` seed:
 
 ```
 Task(subagent_type="fvs-doc-syncer", model="$SYNCER_MODEL",
+     reasoning_effort="$SYNCER_EFFORT", // when supported; otherwise apply the capability gate
      description="Sync extraction docs + reconcile blocker catalog (mode b)",
      prompt="<sync_mode>extraction-docs</sync_mode>
              ...Charon docs/{what_charon_translates,transformations,limitations}.md + README.md +
@@ -219,8 +217,9 @@ On Codex, every interactive HALT in this command -- the clone-path prompt (Step
 propose-each approval the workers surface -- degrades to a plain-text question and WAITS for the
 user. It is fail-closed: it never auto-picks a default, never auto-applies a change, and never
 fetches or opens an upstream artifact without the read-only fetch being explicitly part of the sync.
-The `Task(...)` dispatches survive intact (the `model=` parameter is silently ignored on Codex, per
-model-profiles runtime handling).
+Before dispatch on Codex, 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/trust-audit.md

@@ -55,8 +55,7 @@ project-defs paths with the precedence config -> auto-detect -> prompt -> error,
 
 ```bash
 CONFIG=$(cat .formalising/fvs-config.json 2>/dev/null)
-# profile = config.model_profile || "balanced"
-# model = model_overrides["fvs-axiom-auditor"] ?? PROFILE_TABLE["fvs-axiom-auditor"][profile]
+# Resolve stage `trust_audit` for fvs-axiom-auditor through model-profiles.md.
 ```
 
 The target is UNTRUSTED input flowing into path expansion and a `lake` / `lake env lean`
@@ -134,11 +133,16 @@ Never fall back to grep/model enumeration; models never discover, add, remove, o
 
 ## Step 4: Resolve the auditor model + dispatch the read-only auditor
 
-Resolve `$AUDITOR_MODEL` for `fvs-axiom-auditor` from the profile table (auditor:
-quality=inherit, balanced=sonnet, budget=haiku), then dispatch:
+Resolve `$AUDITOR_MODEL` and `$AUDITOR_EFFORT` for `fvs-axiom-auditor` with stage key
+`trust_audit` through `model-profiles.md`. Before dispatch, show and confirm the command-level
+selection manifest. Offer one-run adjustment, exact-stage Save override, notes that rebuild and
+reconfirm the manifest, and Cancel. Missing preferred models or unsupported efforts prompt
+interactively; noninteractive unresolved choices fail before dispatch with exact remediation.
+Pass validated native fields, then dispatch:
 
 ```
 Task(subagent_type="fvs-axiom-auditor", model="$AUDITOR_MODEL",
+     reasoning_effort="$AUDITOR_EFFORT", // when supported; otherwise apply the capability gate
      description="Introspect #print axioms over canonical functions",
      prompt="Target: $TARGET
 
@@ -214,8 +218,9 @@ Table:         .formalising/audits/<target>.md
 On Codex, every interactive HALT in this command -- the build-precondition HALT (Step 2) and any
 justification prompt at the gate (Step 5) -- degrades to a plain-text question and WAITS for the
 user. It is fail-closed: it never auto-justifies an axiom, never self-clears the NOT-CLEAN gate,
-and never produces a CLEAN verdict without a green build. The `Task(...)` dispatch survives intact
-(the `model=` parameter is silently ignored on Codex, per model-profiles runtime handling).
+and never produces a CLEAN verdict without a green build. Before dispatch on Codex, 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/fv-skills/VERSION

@@ -1 +1 @@
-2.3.2
+2.3.4

package/fv-skills/references/crypto-plan-review.md

@@ -65,7 +65,9 @@ specify a stricter order, use:
 4. The plan documents under review.
 
 On conflict, the earlier item wins. Missing or ambiguous authority is itself a finding when the
-plan makes a normative mathematical choice.
+plan makes a normative mathematical choice. When the project names a practical reference
+implementation, use it to settle details the mathematics leaves open (for example field names or
+return order); it never overrides definitions, equations, or other mathematical authority.
 
 </authority>
 
@@ -103,8 +105,10 @@ Work through every applicable item and record both findings and cleared surfaces
      surface regresses, and the follow-up stays bounded to the named defects.
 10. **Reuse audit and scope economy.** Judge the explicit `## Reuse audit` against
     the supplied grounding inventory. Missing reuse analysis is a MAJOR CONTENT
-    finding. Check new abstractions against existing project and pinned-upstream
-    signatures, and apply the appended shared reuse/scope policy.
+    finding. Check whether the same concept already exists in the project; following an external
+    specification is not itself a reason to duplicate it. Apply the appended shared reuse/scope
+    policy. Detailed tables have one canonical copy; other locations reference it rather than
+    reproducing rows that can drift.
 
 </attack_surface>
 
@@ -140,6 +144,9 @@ End with exactly one verdict:
 - **APPROVE-WITH-EDITS** — no BLOCKER; the named bounded edits are sufficient before dispatch.
 - **REJECT** — any BLOCKER, or MAJOR findings that require re-planning rather than bounded edits.
 
+`REJECT` and `APPROVE-WITH-EDITS` require at least one finding. An empty Findings section is valid
+only with `APPROVE`.
+
 </severities_and_verdict>
 
 <output_contract>

package/fv-skills/references/fc-spec-review.md

@@ -41,7 +41,8 @@ Check every applicable surface:
    The implementation is the source of truth; library convenience must not change its semantics.
 
 Give each finding an ID, severity (BLOCKER, MAJOR, MINOR), a precise claim, reproducible `path:line`
-evidence or a concrete counterexample, and a minimal suggested change. Combine duplicate symptoms.
+evidence or a concrete counterexample, and a minimal suggested change. `OBSERVATION` is not a
+supported FC severity. Combine duplicate symptoms.
 Do not invent findings to satisfy a quota. Explain which surfaces were checked and which remain
 unverified; a blanket approval is insufficient.
 
@@ -78,7 +79,8 @@ Choose **PASS** only when the statement has adequate source/intent coverage and
 semantic corrections remain. Choose **APPROVE-WITH-EDITS** only when every necessary change can be
 named exhaustively as a bounded edit and no missing authority remains. Use **REVISE** for
 substantive statement correction and **BLOCKED** for missing or ambiguous evidence. Findings may be
-empty, but Coverage and Evidence remain substantive.
+empty only for PASS or BLOCKED; APPROVE-WITH-EDITS and REVISE require at least one finding.
+Coverage and Evidence remain substantive.
 
 The reviewer response is immutable and the reviewer never edits the specification. The separate
 authoring seat (`lean-specify`) re-checks findings and writes `triage.md`. For