fv-skills-baif 2.0.2 → 2.0.3

package/CHANGELOG.md

@@ -4,6 +4,19 @@ All notable changes to FVS (Formal Verification Skills) will be documented in th
 
 The format is based on [Keep a Changelog](https://keepachangelog.com/).
 
+## [2.0.3] - 2026-07-04
+
+### Changed
+- The crypto formalisation loop now drives a dedicated crypto executor with an `implement -> check -> complete -> escalate -> BLOCKED` discipline, replacing the borrowed functional-correctness one-sorry-at-a-time proof-attempt grind that did not fit crypto work.
+- `/fvs:crypto-execute` gained a runtime-agnostic executor model/effort knob resolved at dispatch time (explicit flag, then a config `model_overrides` entry, then an interactive ask, then inherit the default) so the executor is never hard-pinned to one model.
+- The crypto thinker's plan mode is fenced to producing statements rather than proofs, with an added escalate-to-user tier when a step exceeds its remit.
+- Guidance now treats `lake build` as the style authority for crypto work, and isolation checks skip the package's own style linters to avoid contradictory signals.
+- `/fvs:lean-verify` received a minimal refresh keeping proof-attempt behavior functional-correctness-scoped, decoupling it from the crypto executor without a rewrite.
+
+### Fixed
+- Codex `hooks.json` is now written in the nested `{ hooks: { ... } }` shape that current Codex expects; pre-existing flat hook files are migrated on reinstall while foreign entries are preserved.
+- Corrected the crypto-plan knowledge-base invocation path so KB querying resolves the intended interpreter and script location.
+
 ## [2.0.2] - 2026-07-02
 
 ### Fixed

package/agents/fvs-crypto-executor.md

@@ -0,0 +1,138 @@
+---
+name: fvs-crypto-executor
+description: Write-capable executor for the crypto formalisation loop. Dispatched by /fvs:crypto-execute to implement a fully-specified plan, complete proofs, and hand back BLOCKED/escalate when stuck.
+tools: Read, Bash, Grep, Glob, Write
+color: pink
+---
+
+<role>
+You are the FVS crypto formalisation executor. You are dispatched by /fvs:crypto-execute with a
+bounded, fully-specified plan authored by the crypto thinker and INLINED into your prompt. Your job
+is to IMPLEMENT that plan end to end: write the new spec/definition file, complete its proofs, and
+return a structured report. You are write-capable — you own the deliverable file.
+
+You are NOT a proof-attempt pair-programmer. Unlike the FC `fvs-executor` `proof-attempt` mode, you
+do not target one `sorry` at a time, you do not cap yourself at a few tactic lines per invocation,
+and you do not hand the file back to the user to compile between every step. You implement the whole
+specified unit, drive it to a green build yourself, and only stop to escalate a genuine statement
+decision or to report a real block.
+
+CRITICAL: All file writes MUST use the Write tool. Never use Bash to write files. Every change is
+presented as a VS Code diff for user approval.
+
+You do NOT use @-references — the parent command inlines every piece of context (the plan, the
+paper-grounded sources, the branch/build state) into your prompt.
+</role>
+
+<process>
+
+Your parent command provides the bounded plan (branch/state, exact target files and theorems,
+immutable public statements, allowed-`sorry` policy, stop conditions, verification commands) inlined
+in your prompt. Execute the discipline below in order.
+
+1. **Implement the fully-specified spec.** Write the whole new file the plan names — definitions,
+   theorem statements verbatim from the plan, and proof scaffolding. The allowed-`sorry` policy is
+   NONE unless the plan explicitly names an intentional obligation and gives the exact statement it
+   must carry. Do not introduce a `sorry` the plan did not authorise. Preserve every immutable public
+   statement (signature / definition) exactly as the plan specifies.
+
+2. **Kernel-check the signatures.** Confirm the definitions and theorem statements you wrote
+   elaborate and typecheck before you invest in the proof bodies. A signature that does not
+   elaborate is a scope/statement problem — resolve it against the plan, or escalate (step 5) if it
+   requires changing a public statement.
+
+3. **Complete the proofs.** Drive each proof to a closed goal. Use the `mcp__ide__getDiagnostics`
+   runtime tool to read the live goal state and error/warning diagnostics as you work — it is your
+   in-loop feedback signal, not a substitute for the authoritative build in step 4. Work the whole
+   unit; do not artificially cap the amount of proof you write per step.
+
+4. **Self-fix mechanical issues, and run the build as the style authority.** After the proofs close
+   under diagnostics, run the build and fix mechanical fallout yourself (unresolved identifiers,
+   import order, missing lemmas that exist under another name, arithmetic side-goals). EXPECT style
+   warnings that surface ONLY at `lake build` and never at `lake env lean` / `--stdin` isolation
+   checks or at `mcp__ide__getDiagnostics`: the package style linters (for example
+   `linter.style.show` and `linter.style.longLine`) run at build time. `lake build` is the style
+   authority; isolation checks are advisory and cannot certify style. Reproduce the style pass
+   cheaply with `lake env lean -Dlinter.style.show=true -Dlinter.style.longLine=true <file>`, but the
+   authoritative gate is the build. House style: prefer `change` over a goal-altering `show`
+   (semantics-preserving by defeq) and wrap lines at 100 columns.
+
+5. **Escalate to the user for any statement adjustment.** If closing the work requires changing a
+   public signature or theorem statement (anything the plan marked immutable), HALT and escalate. Do
+   NOT silently rewrite a statement to make a proof go through. State the exact statement, the
+   before/after you propose, and why it is needed; record the approved edit before/after once the
+   user rules.
+
+6. **Hand back BLOCKED when genuinely stuck.** If a prerequisite is absent, the build cannot be made
+   green after honest effort, or a modeling decision is required that you must not make, stop and
+   report BLOCKED with the concrete blocker — do not grind indefinitely.
+
+Write your run report to `IMPLEMENTATION_nN.md` (where `nN` is the iteration the command passes you),
+capturing what you implemented, the final build state, any authorised `sorry` obligations with their
+statements, and any escalation/block.
+
+**Anti-pattern this agent rejects (the FC lean-verify sorry-grind — stays FC-only):** no
+one-`sorry`-at-a-time targeting; no ≤3-line-per-invocation tactic cap; no
+user-compiles-between-steps pair-programming. That discipline belongs to the FC `fvs-executor`
+`proof-attempt` mode and must not leak into the crypto loop.
+
+</process>
+
+<fvs_hard_rules>
+- NEVER run a bare `lake build` -- always `nice -n 19 lake build` with the `set -o pipefail` / `${PIPESTATUS` guard so a piped build failure is never masked.
+- NEVER edit generated Lean (`Types.lean` / `Funs.lean`).
+- All writes MUST use the Write tool -- never echo, cat, or Bash redirection. When creating new files, create parent directories first using Bash if needed.
+- Escalate, do not overrule: never change an immutable public statement to force a proof through -- HALT and ask, then record the approved before/after.
+- NEVER call `gh` to open or create any upstream artifact.
+- This is a Lean-via-Aeneas pipeline only -- no other-framework verification paths.
+</fvs_hard_rules>
+
+<return_format>
+
+On successful completion, end your output with:
+
+```
+## IMPLEMENTATION COMPLETE
+
+**Iteration:** nN
+**Files written:** {list of file paths, including IMPLEMENTATION_nN.md}
+**Build:** green via `nice -n 19 lake build`
+**Obligations:** {named allowed-sorry obligations with their statements, or "none"}
+**Summary:** {1-2 sentences on what was implemented and proven}
+```
+
+When a public-statement decision is required:
+
+```
+## ESCALATE
+
+**Iteration:** nN
+**Statement at stake:** {the immutable signature/theorem the work needs changed}
+**Proposed change:** {before -> after}
+**Why:** {what fails without it}
+```
+
+When genuinely stuck:
+
+```
+## BLOCKED
+
+**Iteration:** nN
+**Blocker:** {the concrete missing prerequisite, red build, or modeling decision}
+**Build state:** {last known state from `nice -n 19 lake build`}
+**What would unblock:** {the specific input needed}
+```
+
+</return_format>
+
+<success_criteria>
+- [ ] Implemented the fully-specified plan as a whole unit (no unauthorised `sorry`; immutable public statements preserved verbatim)
+- [ ] Kernel-checked signatures, then completed proofs using `mcp__ide__getDiagnostics` for in-loop goal/diagnostic feedback
+- [ ] Ran `nice -n 19 lake build` as the style authority and self-fixed mechanical + style fallout (expecting style warnings that surface only at build time, not in isolation checks)
+- [ ] Escalated (never overruled) any immutable-public-statement change; handed back BLOCKED when genuinely stuck
+- [ ] Did NOT use the one-`sorry` / ≤3-line / user-compiles-between-steps proof-attempt grind
+- [ ] Wrote the run report to `IMPLEMENTATION_nN.md` and returned with a ## IMPLEMENTATION COMPLETE / ## ESCALATE / ## BLOCKED header
+- [ ] All writes via the Write tool; no bare `lake build`; no generated-Lean edits; no `gh` auto-open; Lean-via-Aeneas pipeline only; no @-references
+</success_criteria>
+</content>
+</invoke>

package/agents/fvs-crypto-thinker.md

@@ -34,6 +34,16 @@ Your parent command provides the stage via a `<thinker_mode>` tag and the inline
 prior plan/review in `fv-plans/<topic>/`.
 **Output (returned as text):** ONE bounded executor plan.
 
+**Depth fence (statements, not proofs):** the plan carries the SPEC VERBATIM (APIs, def bodies,
+theorem/definition statements) but contains NO proof bodies and NO tactic scripts -- authoring the
+proof is the executor's job, not yours. You do NOT compile or type-check while planning: at most ONE
+coarse go/no-go compile check, and only when viability genuinely hinges on an architectural unknown.
+That single go/no-go probe is a viability check, NOT a style certification -- `lake build` in the
+executor's loop remains the style authority (a planner that does not fully compile cannot certify
+style). `Bash` stays in your tool list SOLELY for that one permitted go/no-go probe, and so the plan
+can author the `nice -n 19 lake build` command as text the executor runs; it is not a license to
+iterate a proof while planning.
+
 The plan is bounded and runtime-neutral -- it must be executable by a Claude, Codex, or other
 runtime's executor with no thinker in the loop. State EVERY field explicitly:
 
@@ -48,7 +58,8 @@ runtime's executor with no thinker in the loop. State EVERY field explicitly:
    the exact statement each must carry. A `sorry` is never judged by count; only a named obligation
    with the correct statement is acceptable.
 6. **Stop conditions** -- the explicit conditions under which the executor halts (target reached,
-   build red after N attempts, a modeling decision needed).
+   build red after N attempts, a modeling decision needed). A modeling decision or any change to a
+   public statement is ESCALATED to the user -- never decided by the thinker.
 7. **Verification commands** -- ALWAYS `nice -n 19 lake build` (never a bare `lake build`), with the
    `set -o pipefail` / `${PIPESTATUS` guard so a piped build failure is never masked.
 8. **Expected artifact updates** -- which `fv-plans/<topic>/{plans,reviews,sources,merge}` files the

package/agents/fvs-executor.md

@@ -79,6 +79,7 @@ Your parent command provides `<execution_mode>` and `<research_findings>` tags.
 
 <mode name="proof-attempt">
 **Dispatched by:** /fvs:lean-verify
+**Scope:** Functional-correctness track only. The crypto formalise track uses the dedicated `fvs-crypto-executor`, so this mode's one-sorry discipline is never borrowed by crypto.
 **Input:** Current proof state, available lemmas, recommended strategy from research
 **Output:** Modified spec file with tactic steps replacing sorry
 

package/bin/install.js

@@ -60,6 +60,10 @@ const CODEX_AGENT_SANDBOX = {
   // return (the command body persists the artifacts) and the auditor only
   // introspects and returns a table -- both are read-only.
   'fvs-crypto-thinker': 'read-only',
+  // The crypto executor owns the deliverable file -- it writes the new spec and
+  // completes proofs, so it needs workspace-write; the unmapped default is
+  // read-only, which would silently fail every write on Codex.
+  'fvs-crypto-executor': 'workspace-write',
   'fvs-axiom-auditor': 'read-only',
 };
 
@@ -91,6 +95,9 @@ const FVS_CODEX_AGENT_EFFORT = {
   // so it runs at xhigh (the dual-runtime Codex thinker must think at least this
   // hard); the read-only auditor introspects axioms at high.
   '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-axiom-auditor': 'high',
 };
 
@@ -1369,9 +1376,15 @@ function isFvsManagedCodexHookCommand(commandText, configDir) {
 
 // Read hooks.json, drop any prior FVS-managed entries for `eventName`, then
 // append exactly one fresh managed entry (unless managedCommand is null, which
-// means remove-only). Foreign entries are preserved and the file is written back
-// in the SAME shape it used: nested `{ hooks: { <Event>: [...] } }` or flat
-// `{ <Event>: [...] }`. Returns { changed, wrote, path }.
+// means remove-only). Foreign entries are preserved and the file is ALWAYS
+// written back in the nested `{ "hooks": { "<Event>": [...] } }` shape that
+// current Codex (0.142.x) requires — the older flat `{ "<Event>": [...] }` shape
+// is silently ignored by Codex. A flat top-level table is treated as a legacy
+// read source and migrated to nested: the sanitized event table plus any foreign
+// top-level event keys (e.g. Stop, PostToolUse, SubagentStart) are rehomed under
+// `hooks`, so the written object is exactly `{ hooks: { ...all events... } }`
+// (foreign non-event top-level content is preserved at the top level).
+// Returns { changed, wrote, path }.
 function reconcileCodexHooksJsonEvent(targetDir, eventName, opts = {}) {
   const hooksJsonPath = path.join(targetDir, 'hooks.json');
   const managedCommand = typeof opts.managedCommand === 'string' ? opts.managedCommand : null;
@@ -1394,8 +1407,21 @@ function reconcileCodexHooksJsonEvent(targetDir, eventName, opts = {}) {
 
   const usesNestedHooksObject =
     parsed.hooks && typeof parsed.hooks === 'object' && !Array.isArray(parsed.hooks);
-  const hookTable = usesNestedHooksObject ? parsed.hooks : parsed;
-  const eventEntries = Array.isArray(hookTable[eventName]) ? hookTable[eventName] : [];
+
+  // Build the normalized nested event table. Seed it from any existing nested
+  // `parsed.hooks` events, then rehome any foreign top-level event keys — a
+  // legacy flat table stores events directly at the top level, so migrate them
+  // (an already-nested key wins over a same-named flat one).
+  const nestedTable = {};
+  if (usesNestedHooksObject) {
+    for (const [key, value] of Object.entries(parsed.hooks)) nestedTable[key] = value;
+  }
+  for (const [key, value] of Object.entries(parsed)) {
+    if (key === 'hooks') continue;
+    if (Array.isArray(value) && !(key in nestedTable)) nestedTable[key] = value;
+  }
+
+  const eventEntries = Array.isArray(nestedTable[eventName]) ? nestedTable[eventName] : [];
 
   let removedManaged = false;
   const sanitizedEntries = [];
@@ -1423,28 +1449,41 @@ function reconcileCodexHooksJsonEvent(targetDir, eventName, opts = {}) {
   }
 
   if (sanitizedEntries.length > 0) {
-    hookTable[eventName] = sanitizedEntries;
+    nestedTable[eventName] = sanitizedEntries;
   } else {
-    delete hookTable[eventName];
+    delete nestedTable[eventName];
+  }
+
+  // Assemble the always-nested output. Preserve foreign non-event top-level keys
+  // (anything other than `hooks` whose value is not an array) so unrelated
+  // user-authored content survives; the event keys themselves live under `hooks`.
+  const output = {};
+  for (const [key, value] of Object.entries(parsed)) {
+    if (key === 'hooks') continue;
+    if (Array.isArray(value)) continue;
+    output[key] = value;
+  }
+  if (Object.keys(nestedTable).length > 0) {
+    output.hooks = nestedTable;
   }
-  if (usesNestedHooksObject) parsed.hooks = hookTable;
 
-  // When the reconcile empties the object (no foreign keys remain) and a file
-  // existed on disk, delete it rather than leaving an orphaned `{}` the user
-  // never authored. Foreign content keeps at least one key, so this only fires
-  // for an FVS-only file. A non-existent file with nothing to write is a no-op.
-  if (Object.keys(parsed).length === 0) {
+  // When the reconcile empties the whole normalized object (no events, no foreign
+  // top-level content) and a file existed on disk, delete it rather than leaving
+  // an orphaned `{}` the user never authored. Foreign content keeps at least one
+  // key, so this only fires for an FVS-only file. A non-existent file with
+  // nothing to write is a no-op.
+  if (Object.keys(output).length === 0) {
     if (currentContent !== null) {
       const removed = removedManaged || currentContent.trim() !== '{}';
       fs.unlinkSync(hooksJsonPath);
       return { changed: true, wrote: removed, path: hooksJsonPath, deleted: true };
     }
-    return { changed: changed || removedManaged, wrote: false, path: hooksJsonPath };
+    return { changed: removedManaged, wrote: false, path: hooksJsonPath };
   }
 
-  const nextContent = `${JSON.stringify(parsed, null, 2)}\n`;
+  const nextContent = `${JSON.stringify(output, null, 2)}\n`;
   const changed = currentContent !== nextContent;
-  const shouldWrite = changed && (currentContent !== null || Object.keys(parsed).length > 0);
+  const shouldWrite = changed && (currentContent !== null || Object.keys(output).length > 0);
   if (shouldWrite) {
     atomicWriteFileSync(hooksJsonPath, nextContent, 'utf8');
   }

package/commands/fvs/crypto-execute.md

@@ -1,7 +1,7 @@
 ---
 name: fvs:crypto-execute
 description: Run the current iteration's bounded executor plan under a green-build guard and a bounded loop
-argument-hint: "<topic> nN"
+argument-hint: "<topic> nN [--model <value>] [--effort <value>]"
 allowed-tools:
   - Read
   - Write
@@ -15,13 +15,15 @@ allowed-tools:
 
 <objective>
 Run the current iteration's bounded executor plan (`EXEC_PLAN_nN.md` or `FOLLOWUP_PLAN_nN.md`). The
-existing `fvs-executor` runs the plan in proof-attempt mode under a bounded loop with the green-build
-guard; this command body owns loop termination and the build status check.
+dedicated `fvs-crypto-executor` implements the fully-specified plan under the green-build guard; this
+command body owns dispatch and the build status check, and routes the executor's ESCALATE/BLOCKED
+return to the user.
 
 This command is the EXECUTE stage of the single-runtime loop (plan -> execute -> eval -> followup).
 The plan it runs is RUNTIME-NEUTRAL: the loop runs as a `(R1; R1)` same-runtime pair by default, with
-an optional secondary runtime available for the planning/eval stages in a later wave. A failed proof
-triggers a SHORT interactive redirect early -- never a long unattended grind.
+an optional secondary runtime available for the planning/eval stages in a later wave. When the
+executor hits a public-statement change or cannot proceed, it hands back ESCALATE/BLOCKED and the
+command routes that to the user -- never a long unattended grind.
 
 Output: the executed proof changes on the working branch, with `build.log` captured for the eval.
 </objective>
@@ -42,11 +44,20 @@ iteration from `plans/` and runs it. The loop is restartable from its on-disk re
 ## Step 1: Resolve the topic slug + paths (path safety)
 
 Resolve the topic into a slug (whitespace -> `-`, capitalization preserved, e.g.
-`CKA from KEM` -> `CKA-from-KEM`). Treat the topic + iteration arg as UNTRUSTED: REJECT a slug with
-shell metacharacters, QUOTE every path expansion, NEVER `eval` a path.
+`CKA from KEM` -> `CKA-from-KEM`). Treat the topic + iteration arg AND the new `--model` / `--effort`
+flag values as UNTRUSTED: REJECT a slug with shell metacharacters, QUOTE every path expansion, NEVER
+`eval` a path. The `--model` / `--effort` values are opaque, runtime-valid strings -- do NOT validate
+them against any model taxonomy; reject only shell metacharacters (the same path-safety check).
 
 ```bash
-TOPIC_RAW="$1"; ITER="$2"
+TOPIC_RAW=""; ITER=""; EXEC_MODEL=""; EXEC_EFFORT=""
+while [ $# -gt 0 ]; do
+  case "$1" in
+    --model )  EXEC_MODEL="$2";  shift 2 ;;
+    --effort ) EXEC_EFFORT="$2"; shift 2 ;;
+    * ) if [ -z "$TOPIC_RAW" ]; then TOPIC_RAW="$1"; elif [ -z "$ITER" ]; then ITER="$1"; fi; shift ;;
+  esac
+done
 case "$TOPIC_RAW" in
   *[';|&$`()<>'*]* ) echo "FVS >> ERROR: topic contains shell metacharacters" >&2; exit 1 ;;
   *..*|*/* ) echo "FVS >> ERROR: topic contains '..' or '/' (path traversal); refusing" >&2; exit 1 ;;
@@ -55,6 +66,11 @@ case "$ITER" in
   n[0-9]* ) : ;;
   * ) echo "FVS >> ERROR: iteration must be of the form nN" >&2; exit 1 ;;
 esac
+for FLAGVAL in "$EXEC_MODEL" "$EXEC_EFFORT"; do
+  case "$FLAGVAL" in
+    *[';|&$`()<>'*]* ) echo "FVS >> ERROR: --model/--effort contains shell metacharacters" >&2; exit 1 ;;
+  esac
+done
 SLUG=$(printf '%s' "$TOPIC_RAW" | tr -s '[:space:]' '-')
 ROOT=".formalising/fv-plans/$SLUG"
 ```
@@ -68,22 +84,48 @@ Read the bounded executor plan for this iteration -- `plans/EXEC_PLAN_nN.md`, or
 the executor needs (it is runtime-neutral and bounded -- branch/state, exact targets, immutable public
 statements, allowed-`sorry` policy, stop conditions, verification command).
 
-## Step 3: Resolve the executor model + dispatch
+## Step 3: Resolve the executor model + effort + dispatch
 
-Resolve `$EXECUTOR_MODEL` for `fvs-executor` via the model-profiles dispatch sequence. `cat` the
-bounded plan and INLINE it into the prompt (references do not cross the Task boundary):
+Resolve `$EXECUTOR_MODEL` and `$EXECUTOR_EFFORT` for `fvs-crypto-executor` AT DISPATCH TIME -- never
+pinned in the agent frontmatter. The resolved values are opaque, runtime-valid strings passed
+STRAIGHT THROUGH to `Task(model=...)`; FVS keeps NO cross-provider model/effort taxonomy (an invalid
+value is rejected by the runtime itself). Resolve with this ladder:
+
+1. The per-run `--model` / `--effort` flags from Step 1, if present.
+2. Else a top-level override in `.formalising/fvs-config.json`:
+   `model_overrides["fvs-crypto-executor"]`. Read it at the TOP-LEVEL `model_overrides` key the
+   model-profiles resolver actually consults -- NOT the template's nested `model.model_profile` (a
+   pre-existing shape mismatch, out of scope here; do not depend on the nested key).
+3. Else, in an interactive run, ASK via `AskUserQuestion` which model + effort to use for the
+   execution subagent, offering "inherit / default" as a choice.
+4. Else default `inherit` (works zero-config on every runtime).
+
+```bash
+CONFIG=$(cat .formalising/fvs-config.json 2>/dev/null || echo '{}')
+# 1. flag  ->  2. top-level model_overrides["fvs-crypto-executor"]  ->  4. inherit
+#    (3. AskUserQuestion runs between 2 and 4 in an interactive run)
+EXECUTOR_MODEL="${EXEC_MODEL:-$(printf '%s' "$CONFIG" | OVERRIDE_KEY='model_overrides["fvs-crypto-executor"]' read_top_level_override)}"
+EXECUTOR_MODEL="${EXECUTOR_MODEL:-inherit}"
+EXECUTOR_EFFORT="${EXEC_EFFORT:-inherit}"
+```
+
+On Codex the `model=` parameter is silently ignored and per-agent effort is FIXED at install time
+(from `FVS_CODEX_AGENT_EFFORT`), so the per-run `--effort` flag is a Claude / OpenCode / Gemini
+nicety; Codex users tune the crypto executor's effort via the agent `.toml` / reinstall.
+
+`cat` the bounded plan and INLINE it into the prompt (references do not cross the Task boundary):
 
 ```
 Task(
-  subagent_type="fvs-executor",
+  subagent_type="fvs-crypto-executor",
   model="$EXECUTOR_MODEL",
   description="Run bounded plan",
-  prompt="Execute mode: proof-attempt
+  prompt="Execute the bounded crypto plan.
 
 <bounded_plan>...the inlined EXEC_PLAN_nN.md / FOLLOWUP_PLAN_nN.md...</bounded_plan>
 
-Target one sorry at a time with small tactic blocks; after 3 failed attempts on a goal, return
-NEEDS INPUT. Return with ## EXECUTION COMPLETE"
+Implement the fully-specified plan; self-fix at the green build; ESCALATE for any public-statement
+change and hand back BLOCKED if you cannot proceed. Return with ## IMPLEMENTATION COMPLETE"
 )
 ```
 
@@ -98,23 +140,19 @@ nice -n 19 lake build 2>&1 | tee "$ROOT/build.log"
 test ${PIPESTATUS[0]} -eq 0 || echo "FVS >> build red -- a proof did not close"
 ```
 
-## Step 5: Enforce the bounded loop
-
-Bound the loop so a failed proof triggers a SHORT interactive redirect early, not a long grind:
-
-| Bound | Default | Rationale |
-|-------|---------|-----------|
-| Per-step attempt-cap | `3` | Matches the FVS `lean-verify` per-sorry limit. |
-| Cycle hard-cap | `~25` | On exhaustion, HALT with the transcript. |
-| No-progress key | `sha256(target || goal-state)` | A same-key recurrence after a fix is known-stuck. |
+`lake build` is the STYLE authority: `lake env lean` / `--stdin` isolation does NOT run the package
+style linters (`linter.style.show`, `linter.style.longLine` from `weak.linter.mathlibStandardSet`),
+so a style warning surfaces only here. Reproduce it cheaply and early with `lake env lean
+-Dlinter.style.show=true -Dlinter.style.longLine=true <file>`. House style uses `change` (not a
+goal-altering `show`) and wraps lines to <=100 columns.
 
-```bash
-PROGRESS_KEY=$(printf '%s' "$TARGET$GOAL" | sha256sum | cut -c1-16)
-```
+## Step 5: Route the executor's ESCALATE/BLOCKED return
 
-On the attempt-cap, the cycle hard-cap, or a no-progress recurrence: HALT and redirect via
+The `fvs-crypto-executor` owns its own implement -> check -> complete -> escalate -> BLOCKED
+discipline; this command does not re-drive a per-goal grind. When the executor returns ESCALATE (a
+public-statement change is needed) or BLOCKED (it cannot proceed), HALT and redirect to the user via
 `AskUserQuestion` (degrade to plain-text + WAIT on a secondary runtime that lacks it) -- a short
-interactive redirect early beats a long unattended grind.
+interactive redirect beats a long unattended grind.
 
 ## Step 6: Run-end banner + next command
 
@@ -133,15 +171,17 @@ Plan:      plans/{EXEC_PLAN | FOLLOWUP_PLAN}_{ITER}.md
 </process>
 
 <codex_skill_adapter>
-On a secondary runtime, the bounded-loop redirect (Step 5) degrades to a plain-text question and
-WAITS for the user; it is fail-closed (never auto-picks a default, never writes an upstream artifact).
-The `Task(...)` dispatch survives intact (the `model=` parameter is silently ignored on Codex).
+On a secondary runtime, both the Step 3 model/effort ask and the Step 5 ESCALATE/BLOCKED redirect
+degrade to a plain-text question and WAIT for the user; each is fail-closed (never auto-picks a
+default beyond the ladder's `inherit`, never writes an upstream artifact). The `Task(...)` dispatch
+survives intact (the `model=` parameter is silently ignored on Codex, where per-agent effort is fixed
+at install time, so the per-run `--effort` flag is a no-op there).
 </codex_skill_adapter>
 
 <success_criteria>
 - [ ] Topic + iteration resolved; shell metacharacters rejected; every path quoted; no `eval`.
-- [ ] The bounded plan (`EXEC_PLAN_nN.md` / `FOLLOWUP_PLAN_nN.md`) read and inlined; `fvs-executor` dispatched (`subagent_type="fvs-executor"`).
+- [ ] The bounded plan (`EXEC_PLAN_nN.md` / `FOLLOWUP_PLAN_nN.md`) read and inlined; `fvs-crypto-executor` dispatched (`subagent_type="fvs-crypto-executor"`).
 - [ ] The build runs under `set -o pipefail` + `${PIPESTATUS` reading the tool's real status; always `nice -n 19 lake build` (never a bare `lake build`).
-- [ ] Bounded loop enforced (per-step attempt-cap, cycle hard-cap, no-progress key); a failed proof triggers a SHORT interactive redirect early.
+- [ ] The executor's ESCALATE/BLOCKED return is routed to the user (short interactive redirect early, never a long unattended grind).
 - [ ] No `gh` open/create; no generated-Lean write.
 </success_criteria>

package/commands/fvs/crypto-plan.md

@@ -99,7 +99,7 @@ QHASH=$(printf '%s' "$QUESTION" | shasum -a 256 | cut -c1-16)
 if [ -f "$ROOT/sources/$QHASH.json" ]; then
   cat "$ROOT/sources/$QHASH.json"            # cache hit -- re-read, do NOT re-query
 else
-  python3 scripts/fvs-kb-query.py ask "$QUESTION" --notebook "$NOTEBOOK_ID" --json \
+  .formalising/.kb-venv/bin/python ~/.claude/scripts/fvs-kb-query.py ask "$QUESTION" --notebook "$NOTEBOOK_ID" --json \
     | tee "$ROOT/sources/$QHASH.json"        # cache the answer for the next iteration
 fi
 ```

package/commands/fvs/lean-verify.md

@@ -14,6 +14,8 @@ allowed-tools:
 <objective>
 Orchestrate interactive proof development for a Lean specification using two-phase subagent dispatch (research -> iterative execute). Dispatches fvs-researcher to analyze sorry locations and recommend proof strategies, then iteratively dispatches fvs-executor to replace each sorry ONE AT A TIME with small tactic blocks.
 
+This is a functional-correctness (FC) track command. Its `fvs-executor` `proof-attempt` mode is FC-only: the crypto formalise track drives its own dedicated executor, so the one-sorry pair-programming loop below is exclusive to this command and is not shared with or borrowed by any other track.
+
 This is the most interactive command -- it feels like pair programming. The executor proposes a small tactic step, the user checks Lean compiles, and the cycle repeats. This is a locked user decision and must not be overridden.
 
 Output: Spec file with sorry replaced by complete proof (VERIFIED) or clear report of where proof got stuck (STUCK).

package/fv-skills/VERSION

@@ -1 +1 @@
-2.0.2
+2.0.3

package/fv-skills/references/model-profiles.md

@@ -132,6 +132,24 @@ Task(
 - **Invalid profile name:** Fall back to `quality` with a warning.
 - **Empty overrides:** Ignored. Equivalent to no overrides.
 
+## crypto-execute Model + Effort Knob
+
+`/fvs:crypto-execute` resolves the model + effort for `fvs-crypto-executor` ABOVE the profile table,
+at its own dispatch site (command Step 3) -- not from a `PROFILE_TABLE` row. The crypto executor is
+intentionally NOT pinned, so there is deliberately **no `fvs-crypto-executor` row and no `opus`
+value** in the table above. The resolution ladder is:
+
+1. A per-run `--model` / `--effort` flag on the command.
+2. Else a top-level override `model_overrides["fvs-crypto-executor"]` in `.formalising/fvs-config.json`
+   (read at the top-level `model_overrides` key this resolver consults, not the template's nested
+   `model.model_profile`).
+3. Else an interactive `AskUserQuestion` offering "inherit / default".
+4. Else the default `inherit`.
+
+The resolved value is an opaque, runtime-valid string passed straight to `Task(model=...)`; FVS keeps
+no cross-provider taxonomy. On Codex `model=` is ignored and per-agent effort is fixed at install
+time, so the per-run `--effort` flag is a Claude / OpenCode / Gemini nicety.
+
 ## Two-Phase Dispatch
 
 Each main command dispatches two subagents in sequence:

package/fv-skills/workflows/crypto-execute.md

@@ -4,10 +4,10 @@ plan under a green-build guard and a bounded loop, so a failed proof triggers a
 redirect early rather than a long unattended grind.
 
 This workflow is the state machine for `/fvs:crypto-execute`. The command body resolves the topic +
-iteration, reads the bounded plan from `plans/`, dispatches the existing `fvs-executor` in
-proof-attempt mode, and owns the build-status check + loop termination. The plan is RUNTIME-NEUTRAL:
-the loop runs as a `(R1; R1)` same-runtime pair by default, with an optional secondary runtime for
-the planning/eval stages in a later wave.
+iteration, reads the bounded plan from `plans/`, dispatches the dedicated `fvs-crypto-executor`, and
+owns the build-status check + routing the executor's ESCALATE/BLOCKED return to the user. The plan is
+RUNTIME-NEUTRAL: the loop runs as a `(R1; R1)` same-runtime pair by default, with an optional
+secondary runtime for the planning/eval stages in a later wave.
 
 Hard invariants this workflow preserves:
 - The build's exit status is read from the TOOL (`set -o pipefail` / `${PIPESTATUS`), never from the
@@ -38,19 +38,19 @@ allowed-`sorry` policy, stop conditions, verification command).
 </step>
 
 <step name="dispatch_executor">
-## Step 3: Dispatch the executor (proof-attempt mode)
+## Step 3: Dispatch the crypto executor
 
-Resolve `$EXECUTOR_MODEL` via the model-profiles sequence, then dispatch the existing executor,
-INLINING the bounded plan:
+Resolve `$EXECUTOR_MODEL` via the model-profiles sequence, then dispatch the dedicated crypto
+executor, INLINING the bounded plan:
 
 ```
-Task(subagent_type="fvs-executor", model="$EXECUTOR_MODEL",
+Task(subagent_type="fvs-crypto-executor", model="$EXECUTOR_MODEL",
      description="Run bounded plan",
-     prompt="Execute mode: proof-attempt ...inlined bounded plan... Return with ## EXECUTION COMPLETE")
+     prompt="Execute the bounded crypto plan. ...inlined bounded plan... Return with ## IMPLEMENTATION COMPLETE")
 ```
 
-Proof-attempt discipline (reused from the existing executor): target one sorry at a time with small
-tactic blocks; after 3 failed attempts on a goal, return NEEDS INPUT.
+The `fvs-crypto-executor` owns its own implement -> check -> complete -> escalate -> BLOCKED
+discipline; this workflow does not re-drive a per-goal grind.
 </step>
 
 <step name="green_build_guard">
@@ -64,23 +64,21 @@ set -o pipefail
 nice -n 19 lake build 2>&1 | tee "$ROOT/build.log"
 test ${PIPESTATUS[0]} -eq 0 || echo "build red -- a proof did not close"
 ```
-</step>
-
-<step name="loop_bounds">
-## Step 5: Bounded loop -- caps + the no-progress rule
 
-| Bound | Default | Rationale |
-|-------|---------|-----------|
-| Per-step attempt-cap | `3` | Matches the FVS `lean-verify` per-sorry limit. |
-| Cycle hard-cap | `~25` | On exhaustion, HALT with the full transcript. |
-| No-progress key | `sha256(target || goal-state)` | A same-key recurrence after a fix is known-stuck. |
+`lake build` is the STYLE authority: `lake env lean` / `--stdin` isolation does NOT run the package
+style linters (`linter.style.show`, `linter.style.longLine` from `weak.linter.mathlibStandardSet`),
+so a style warning surfaces only here. Reproduce it cheaply and early with `lake env lean
+-Dlinter.style.show=true -Dlinter.style.longLine=true <file>`. House style uses `change` (not a
+goal-altering `show`) and wraps lines to <=100 columns.
+</step>
 
-```bash
-PROGRESS_KEY=$(printf '%s' "$TARGET$GOAL" | sha256sum | cut -c1-16)
-```
+<step name="route_escalation">
+## Step 5: Route the executor's ESCALATE/BLOCKED return
 
-On the attempt-cap, the cycle hard-cap, or a no-progress recurrence: HALT and redirect (a short
-interactive redirect early beats a long unattended grind). On a secondary runtime that lacks an
+The `fvs-crypto-executor` owns escalation (implement -> check -> complete -> escalate -> BLOCKED);
+this workflow does not enforce a per-goal attempt grind. When the executor returns ESCALATE (a
+public-statement change is needed) or BLOCKED (it cannot proceed), HALT and redirect to the user (a
+short interactive redirect beats a long unattended grind). On a secondary runtime that lacks an
 interactive prompt, degrade to plain-text and WAIT (fail-closed).
 </step>
 
@@ -88,8 +86,8 @@ interactive prompt, degrade to plain-text and WAIT (fail-closed).
 
 <success_criteria>
 - [ ] Topic + iteration resolved; shell metacharacters rejected; paths quoted; no `eval`.
-- [ ] The bounded plan read and inlined; `fvs-executor` dispatched (`subagent_type="fvs-executor"`) in proof-attempt mode.
+- [ ] The bounded plan read and inlined; `fvs-crypto-executor` dispatched (`subagent_type="fvs-crypto-executor"`).
 - [ ] The build runs under `set -o pipefail` + `${PIPESTATUS` reading the tool's real status; always `nice -n 19 lake build` (never a bare `lake build`).
-- [ ] Bounded loop enforced (attempt-cap, cycle hard-cap, `sha256` no-progress key); a failed proof triggers a SHORT interactive redirect early.
+- [ ] The executor's ESCALATE/BLOCKED return is routed to the user (short interactive redirect early, never a long unattended grind).
 - [ ] No generated-Lean write; no `gh` open/create.
 </success_criteria>

package/fv-skills/workflows/crypto-plan.md

@@ -58,7 +58,7 @@ QHASH=$(printf '%s' "$QUESTION" | shasum -a 256 | cut -c1-16)
 if [ -f "$ROOT/sources/$QHASH.json" ]; then
   cat "$ROOT/sources/$QHASH.json"            # cache hit -- re-read, do NOT re-query
 else
-  python3 scripts/fvs-kb-query.py ask "$QUESTION" --notebook "$NOTEBOOK_ID" --json \
+  .formalising/.kb-venv/bin/python ~/.claude/scripts/fvs-kb-query.py ask "$QUESTION" --notebook "$NOTEBOOK_ID" --json \
     | tee "$ROOT/sources/$QHASH.json"        # cache the answer under sources/
 fi
 ```

package/fv-skills/workflows/lean-verify.md

@@ -2,6 +2,10 @@
 Orchestrate interactive proof development for a Lean specification using two-phase
 subagent dispatch (research -> iterative execute).
 
+This is a functional-correctness (FC) track workflow. The fvs-executor proof-attempt
+mode it drives is FC-only -- the crypto formalise track uses its own dedicated executor,
+so this one-sorry loop is exclusive to lean-verify and is not shared with any other track.
+
 Dispatches fvs-researcher to analyze sorry locations and recommend proof strategies,
 then iteratively dispatches fvs-executor to replace each sorry ONE AT A TIME with
 small tactic blocks. The user checks Lean compiles between each step.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "fv-skills-baif",
-  "version": "2.0.2",
+  "version": "2.0.3",
   "description": "Formal verification skills for Claude Code, Codex, OpenCode, and Gemini. Rust -> Lean 4 via Aeneas.",
   "bin": {
     "fv-skills-baif": "bin/install.js"