fv-skills-baif 2.2.1 → 2.3.1

package/CHANGELOG.md

@@ -4,6 +4,47 @@ 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.3.1] - 2026-09-09
+
+### Added
+- Crypto plan and follow-up review now support selected Codex, Claude, or external reviewers with
+  explicit model/effort choices, read-only execution, honest provenance, immutable hash-bound
+  packets, and a three-round author/reviewer loop. Automatic handoff stays interactive, while
+  one-run Skip and `crypto_review.automatic: false` retain an explicit unreviewed trusted path.
+  This resolves
+  [GitHub issue #51](https://github.com/Beneficial-AI-Foundation/formal-verification-skills/issues/51).
+
+### Changed
+- Crypto and functional-correctness review now treat `APPROVE-WITH-EDITS` as terminal once the
+  authoring seat applies the exhaustively named bounded edits and reruns its gates. Reviewer output
+  remains immutable; only true `REJECT`, `REVISE`, or `BLOCKED` verdicts start a fresh review.
+  This resolves
+  [GitHub issue #52](https://github.com/Beneficial-AI-Foundation/formal-verification-skills/issues/52).
+
+## [2.3.0] - 2026-09-07
+
+### Added
+- `/fvs:lean-spec-review` adversarially reviews a functional-correctness specification against
+  its Rust implementation, extracted Lean definitions, and interpretation layer before proof work.
+  Users choose the reviewer runtime, model, and effort: Codex offers GPT Sol and Astra, Claude
+  offers Fable, cheaper or custom models remain available, and effort defaults to `max`.
+- `/fvs:lean-specify` now offers the same review flow automatically after successful generation
+  checks. Existing projects need no migration: a missing `spec_review.automatic` setting enables
+  the menu, while `{"spec_review":{"automatic":false}}` disables only the automatic handoff.
+- Review records preserve runtime/model provenance, source hashes, immutable history, validated
+  `PASS | REVISE | BLOCKED` verdicts, and orchestrator triage. Other providers use an exported
+  review packet and imported response rather than arbitrary command execution. This resolves
+  [GitHub issue #46](https://github.com/Beneficial-AI-Foundation/formal-verification-skills/issues/46)
+  and delivers the functional-correctness slice of
+  [GitHub issue #32](https://github.com/Beneficial-AI-Foundation/formal-verification-skills/issues/32).
+
+### Fixed
+- Lean workflows now retrieve the project cache before build-capable work and cap Lake concurrency
+  at four threads unless the caller overrides it. Crypto execution accepts IDE diagnostics when
+  available and keeps a documented headless fallback. This resolves
+  [GitHub issue #49](https://github.com/Beneficial-AI-Foundation/formal-verification-skills/issues/49)
+  and [GitHub issue #50](https://github.com/Beneficial-AI-Foundation/formal-verification-skills/issues/50).
+
 ## [2.2.1] - 2026-08-28
 
 ### Fixed

package/README.md

@@ -160,6 +160,7 @@ Commands are grouped into five bundles. Each bundle has a **router** command tha
 |---------|-------------|
 | `/fvs:fc-plan` | Pick next verification targets via greedy dependency graph traversal |
 | `/fvs:lean-specify` | Generate a style-checked Lean spec skeleton with `@[step]` theorem pattern |
+| `/fvs:lean-spec-review` | Adversarially review an FC specification with a chosen runtime, model, and effort |
 | `/fvs:lean-verify` | Attempt proof with domain tactics while blocking new target-style violations |
 | `/fvs:natural-language` | Generate natural language explanation of module or function with pre/post conditions |
 | `/fvs:lean-refactor` | Refactor, simplify, and decompose verified proofs (dead code removal, simp sharpening, tactic golf) — *also in Formalise* |
@@ -171,6 +172,29 @@ 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
+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
+writes separate `triage.md`. PASS proceeds; APPROVE-WITH-EDITS also proceeds after accepted bounded
+edits pass the structure/style/build gates, with no redundant second review. Only REVISE/BLOCKED
+starts another fresh review, carrying prior records as untrusted history, with a three-round cap.
+
+Automatic review works even without a config file. To disable the automatic menu, merge this
+setting into `.formalising/fvs-config.json` (or create that file with just this object):
+
+```json
+{"spec_review": {"automatic": false}}
+```
+
+`/fvs:lean-spec-review <spec.lean>` remains available when automation is disabled. No migration or
+health command is needed. Missing/authentication failures offer setup and an explicit fallback;
+reviewer changes are never silent. A PASS approves the statement for proof work, not the proof.
+
 `lean-specify`, `lean-verify`, and `lean-formalise` share an indexed proof-engineering store at
 `.formalising/proof-engineering/`. Commands read `index.md` first, load at most eight relevant
 lessons as delimited untrusted reference data, and reconcile at most three evidence-backed
@@ -199,7 +223,7 @@ secrets, raw transcripts, ephemeral error dumps, unsupported guesses, or inferre
 | `/fvs:lean-formalise` | Formalise paper/math content into Lean 4 specs and definitions (one-shot) |
 | `/fvs:lean-refactor` | Refactor, simplify, and decompose verified proofs — *also in Formal-Core* |
 | `/fvs:crypto-plan` | Author the next bounded, runtime-neutral plan for a topic-based crypto formalisation iteration (KB-grounded, cached under `sources/`) |
-| `/fvs:crypto-review` | Send an initial or follow-up crypto plan to authenticated Codex for independent, read-only adversarial review before execution |
+| `/fvs:crypto-review` | Review a crypto plan with selected Codex, Claude, or Other runtime/model/effort |
 | `/fvs:crypto-execute` | Run the current iteration's bounded plan under the green-build guard |
 | `/fvs:crypto-eval` | Adversarially evaluate the iteration; ends in one of ACCEPT / FOLLOWUP / HUMAN_RULING / BLOCKED |
 | `/fvs:crypto-followup` | Convert eval findings into the next follow-up plan; HALTs on HUMAN_RULING |
@@ -257,12 +281,12 @@ The paper track formalises papers directly into Lean 4 — no Rust, no Aeneas. T
 
 - **One-shot:** `/fvs:lean-formalise` reads your PDFs / images / LaTeX (optionally grounded in a NotebookLM knowledge base via `/fvs:kb-setup`) and produces Lean definition and spec files in a single pass.
 - **Iterative crypto loop:** for larger crypto formalisations, a topic-based, restartable loop with
-  an independent pre-execution review gate:
+  a fresh pre-execution review gate:
 
   `/fvs:crypto-plan` → `/fvs:crypto-review` → `/fvs:crypto-execute` → `/fvs:crypto-eval` → `/fvs:crypto-followup` → `/fvs:crypto-review` → repeat
 
-  A high-effort thinker authors each bounded plan. Before execution, authenticated Codex
-  independently attacks the plan or follow-up under a read-only sandbox and returns an
+  A high-effort thinker authors each bounded plan. Before execution, a selected Codex, Claude, or
+  Other fresh reviewer attacks the plan or follow-up under read-only controls and returns an
   evidence-backed APPROVE / APPROVE-WITH-EDITS / REJECT verdict. The executor runs an approved plan
   under a green-build guard; the post-execution adversarial eval tries to refute the spec, proof,
   and assumptions and ends in exactly one of ACCEPT / FOLLOWUP / HUMAN_RULING / BLOCKED. Follow-up
@@ -272,8 +296,15 @@ The paper track formalises papers directly into Lean 4 — no Rust, no Aeneas. T
   The authoring, execution, eval, and follow-up stages use the lightweight proof-engineering overlay:
   they load at most eight relevant `crypto`/`shared` lessons and propose at most three reviewed
   updates. Modeling lessons require paper or standard citations and remain provisional until an
-  accepted adversarial eval or explicit human ruling. The independent `crypto-review` gate is
-  deliberately memory-blind, so inherited lessons cannot frame the second-runtime critique.
+  accepted adversarial eval or explicit human ruling. The `crypto-review` gate is deliberately
+  memory-blind. It labels cross-runtime, same-runtime fresh reviewer, and unverified provenance;
+  Other uses packet export/import. APPROVE-WITH-EDITS becomes terminal after the authoring seat
+  applies accepted edits and reruns gates, with no second review. REJECT starts a fresh reviewed
+  revision with prior history, capped at three reviewer rounds per invocation. Automatic plan and
+  follow-up handoff asks reviewer -> model -> effort and never auto-selects. One-run `Skip review`
+  records `Unreviewed (user skipped)` and never starts execution. To opt out persistently, merge
+  `"crypto_review": {"automatic": false}` into `.formalising/fvs-config.json`; standalone review
+  and explicit trusted-path execution remain available without fabricating approval.
 
   **Single- vs dual-runtime (`--codex`).** By default the loop is single-runtime — the thinking stages (`crypto-plan`, `crypto-eval`, `crypto-followup`) run the in-runtime `fvs-crypto-thinker`. Pass `--codex` to hand a stage's thinking to an independent **Codex CLI** thinker instead, so the adversarial planner/evaluator runs on a *different engine* than the executor and blind spots don't correlate. `crypto-execute` is the runtime-neutral executor and takes no `--codex`. Without the Codex CLI installed, a `--codex` stage stops with an install hint rather than silently falling back.
 

package/agents/fvs-axiom-auditor.md

@@ -31,7 +31,7 @@ Iterate exactly the parent-supplied canonical atom IDs. For each entry, introspe
 
 ## 2. Introspect each declaration with `#print axioms`
 For each usable FQN, run `#print axioms <FQN>` via `lake env lean` (introspection only -- if you
-must rebuild anything use `nice -n 19 lake build`, NEVER a bare `lake build`). `#print axioms` is the
+must rebuild anything use `LEAN_NUM_THREADS="${LEAN_NUM_THREADS:-4}" nice -n 19 lake build`, NEVER a bare `lake build`). `#print axioms` is the
 authoritative oracle; static grep never determines inventory membership or classification.
 
 ## 3. Classify from the `#print axioms` output
@@ -64,7 +64,7 @@ count; unresolved entries are explicit, never omitted.
 </process>
 
 <fvs_hard_rules>
-- NEVER run a bare `lake build` -- use `nice -n 19 lake build` if you must rebuild; introspection uses `lake env lean` + `#print axioms`.
+- NEVER run a bare `lake build` -- use `LEAN_NUM_THREADS="${LEAN_NUM_THREADS:-4}" nice -n 19 lake build` if you must rebuild; introspection uses `lake env lean` + `#print axioms`.
 - NEVER edit generated Lean (`Types.lean` / `Funs.lean`) -- you introspect them, you never write them.
 - Read-only: never write or modify any file -- you RETURN the classified, ordered table as text; the command body persists it and fires the gate.
 - Never widen the inventory beyond the strictly-scoped target; surface cone prerequisites separately, never fold them in.

package/agents/fvs-crypto-executor.md

@@ -1,7 +1,7 @@
 ---
 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
+tools: Read, Bash, Grep, Glob, Write, mcp__ide__getDiagnostics
 color: pink
 ---
 
@@ -44,7 +44,10 @@ in your prompt. Execute the discipline below in order.
 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.
+   unit; do not artificially cap the amount of proof you write per step. In a headless runtime where
+   the IDE MCP tool is not registered, or when its call fails because the tool/server is unavailable,
+   fall back to Bash: use `lake env lean <file>` for file diagnostics and the bounded full-project
+   build in step 4 as the authoritative check.
 
 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,
@@ -79,7 +82,7 @@ user-compiles-between-steps pair-programming. That discipline belongs to the FC
 </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 run a bare `lake build` -- always `LEAN_NUM_THREADS="${LEAN_NUM_THREADS:-4}" 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.
@@ -96,7 +99,7 @@ On successful completion, end your output with:
 
 **Iteration:** nN
 **Files written:** {list of file paths, including IMPLEMENTATION_nN.md}
-**Build:** green via `nice -n 19 lake build`
+**Build:** green via `LEAN_NUM_THREADS="${LEAN_NUM_THREADS:-4}" 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}
 ```
@@ -119,7 +122,7 @@ When genuinely stuck:
 
 **Iteration:** nN
 **Blocker:** {the concrete missing prerequisite, red build, or modeling decision}
-**Build state:** {last known state from `nice -n 19 lake build`}
+**Build state:** {last known state from `LEAN_NUM_THREADS="${LEAN_NUM_THREADS:-4}" nice -n 19 lake build`}
 **What would unblock:** {the specific input needed}
 ```
 
@@ -128,7 +131,7 @@ When genuinely stuck:
 <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)
+- [ ] Ran `LEAN_NUM_THREADS="${LEAN_NUM_THREADS:-4}" 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

package/agents/fvs-crypto-thinker.md

@@ -41,7 +41,7 @@ coarse go/no-go compile check, and only when viability genuinely hinges on an ar
 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
+can author the `LEAN_NUM_THREADS="${LEAN_NUM_THREADS:-4}" 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
@@ -60,7 +60,7 @@ runtime's executor with no thinker in the loop. State EVERY field explicitly:
 6. **Stop conditions** -- the explicit conditions under which the executor halts (target reached,
    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
+7. **Verification commands** -- ALWAYS `LEAN_NUM_THREADS="${LEAN_NUM_THREADS:-4}" 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
    run is expected to produce or update.
@@ -104,7 +104,7 @@ that silently picks one side of a modeling decision -- the ruling is reserved fo
 
 If the prior eval was `FOLLOWUP`, author the next bounded plan using the full `plan`-mode contract
 (branch/state, exact targets, immutable public statements, allowed-`sorry` policy, stop conditions,
-`nice -n 19 lake build` verification, expected artifact updates).
+`LEAN_NUM_THREADS="${LEAN_NUM_THREADS:-4}" nice -n 19 lake build` verification, expected artifact updates).
 
 End with `## PLAN COMPLETE` (a follow-up plan) or `## ERROR` (HALT for an HUMAN_RULING you cannot
 resolve without the human).
@@ -113,7 +113,7 @@ resolve without the human).
 </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 run a bare `lake build` -- always `LEAN_NUM_THREADS="${LEAN_NUM_THREADS:-4}" 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`).
 - Author-by-return: never write or modify a project file -- you RETURN the plan/eval/followup as text; the command body persists it under `fv-plans/<topic>/`.
 - On an `HUMAN_RULING`, HALT and ask -- never fabricate a plan that silently makes the modeling decision.
@@ -155,7 +155,7 @@ On HALT / failure:
 </return_format>
 
 <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, `nice -n 19 lake build` verification, and expected artifact updates
+- [ ] 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
 - [ ] 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`

package/agents/fvs-doc-syncer.md

@@ -74,7 +74,7 @@ The parent provides a `<sync_mode>` tag. Execute the matching mode.
 <fvs_hard_rules>
 - Reconcile-not-append: never duplicate an existing catalog entry or reference section; update in place.
 - "Fixed in upstream main" is NOT "fixed for us" -- never auto-retire a catalog entry until the resolved pin carries the fix.
-- NEVER run a bare `lake build` (use `nice -n 19 lake build` if a build is ever needed).
+- NEVER run a bare `lake build` (use `LEAN_NUM_THREADS="${LEAN_NUM_THREADS:-4}" nice -n 19 lake build` if a build is ever needed).
 - NEVER edit generated Lean (`Types.lean` / `Funs.lean`).
 - NEVER call `gh` to OPEN/create an upstream artifact (gh api READ for fetching docs/issues is allowed).
 - Propose each change for approval; all writes use the Write/Edit tool.

package/agents/fvs-draft-investigator.md

@@ -78,7 +78,7 @@ the local-clone commit, the existing-issue numbers you dedup'd against, the cata
 - ESCAPE all interpolated MFE/error/tool output when writing `*.html` (error strings can contain markup).
 - Quote and validate every clone path as a directory before `git -C`; never `eval` a path.
 - Dedup first: cite an existing issue rather than drafting a duplicate.
-- NEVER run a bare `lake build` (use `nice -n 19 lake build` if you must reproduce anything).
+- NEVER run a bare `lake build` (use `LEAN_NUM_THREADS="${LEAN_NUM_THREADS:-4}" nice -n 19 lake build` if you must reproduce anything).
 - NEVER edit generated Lean (`Types.lean` / `Funs.lean`).
 - Write only to the workspace; all writes use the Write/Edit tool.
 - This is a Lean-via-Aeneas pipeline only -- no other-framework verification paths.

package/agents/fvs-equivalence-assessor.md

@@ -82,7 +82,7 @@ This is the load-bearing constraint of your role:
 <fvs_hard_rules>
 - NEVER write section 7 or the ratification token -- you are not the proposer and not the human reviewer.
 - Read-only: never write or modify a file (return the drafted sections as text).
-- NEVER run a bare `lake build` (use `nice -n 19 lake build` if you must reproduce anything).
+- NEVER run a bare `lake build` (use `LEAN_NUM_THREADS="${LEAN_NUM_THREADS:-4}" nice -n 19 lake build` if you must reproduce anything).
 - NEVER edit generated Lean (`Types.lean` / `Funs.lean`).
 - NEVER call `gh` to open or create any upstream artifact.
 - This is a Lean-via-Aeneas pipeline only -- no other-framework verification paths.

package/agents/fvs-extract-applier.md

@@ -83,12 +83,12 @@ crate root using the Write tool:
 - append the trusted assumption to `src-assumptions.md` when the recipe axiomatizes, excludes, or
   gates an item (every A-opacity and every gated build-script edit leaves an assumption).
 
-Then rebuild to confirm the recipe cleared the blocker, ALWAYS with `nice -n 19 lake build`.
+Then rebuild to confirm the recipe cleared the blocker, ALWAYS with `LEAN_NUM_THREADS="${LEAN_NUM_THREADS:-4}" nice -n 19 lake build`.
 
 </process>
 
 <fvs_hard_rules>
-- NEVER run a bare `lake build`. Always `nice -n 19 lake build`.
+- NEVER run a bare `lake build`. Always `LEAN_NUM_THREADS="${LEAN_NUM_THREADS:-4}" nice -n 19 lake build`.
 - NEVER edit generated Lean (`Types.lean` / `Funs.lean`). A-opacity edits the RUST source or the
   hand-authored external files; `tweaks-substitution` repairs generated text only via the guarded
   substitution mechanism, never a hand edit of a generated file.
@@ -139,7 +139,7 @@ On failure:
 - [ ] Generated Lean (`Types.lean` / `Funs.lean`) never edited by hand
 - [ ] Reversible records written (src-modifications + src-assumptions where an assumption arises)
 - [ ] `tweaks-substitution` guards honored (>= 1 match; 0-match is a HARD failure)
-- [ ] Rebuild run with `nice -n 19 lake build`, never bare
+- [ ] Rebuild run with `LEAN_NUM_THREADS="${LEAN_NUM_THREADS:-4}" nice -n 19 lake build`, never bare
 - [ ] All writes via the Write tool; no `gh` auto-open; Lean-via-Aeneas pipeline only
 - [ ] Result returned with the appropriate header
 - [ ] No @-references used (all reference content is inlined by the parent)

package/agents/fvs-extract-bisector.md

@@ -28,7 +28,7 @@ tool.
 1. **Shrink.** Starting from the failing input, remove code until the failure disappears, then
    restore the smallest unit that brings it back. Drive every step by an oracle run -- the actual
    extraction step that the classifier said failed (read its exit status with `set -o pipefail` /
-   `${PIPESTATUS[0]}`, never the tail of a piped log; rebuild with `nice -n 19 lake build` when the
+   `${PIPESTATUS[0]}`, never the tail of a piped log; rebuild with `LEAN_NUM_THREADS="${LEAN_NUM_THREADS:-4}" nice -n 19 lake build` when the
    failing layer is `lean`).
 2. **Grow.** From that minimal core, add back only what is needed to make the example
    self-contained and reproducible. The result is the MFE: the smallest standalone reproduction of
@@ -73,7 +73,7 @@ proposal awaiting a separate disposition.
 
 <fvs_hard_rules>
 - NEVER auto-apply a fix and NEVER stamp a ratification token -- you propose, never dispose.
-- NEVER run a bare `lake build`. Always `nice -n 19 lake build`.
+- NEVER run a bare `lake build`. Always `LEAN_NUM_THREADS="${LEAN_NUM_THREADS:-4}" nice -n 19 lake build`.
 - NEVER edit generated Lean (`Types.lean` / `Funs.lean`).
 - NEVER call `gh` to open or create any upstream artifact.
 - A catalog candidate with an empty `evidence` field is malformed -- evidence is the real MFE path,
@@ -119,7 +119,7 @@ On failure:
 
 <success_criteria>
 - [ ] Two-phase shrink-then-grow minimization driven by the actual failing-layer oracle
-- [ ] Exit status read via `set -o pipefail` / `${PIPESTATUS[0]}`; rebuilds use `nice -n 19 lake build`
+- [ ] Exit status read via `set -o pipefail` / `${PIPESTATUS[0]}`; rebuilds use `LEAN_NUM_THREADS="${LEAN_NUM_THREADS:-4}" nice -n 19 lake build`
 - [ ] Variant budget enforced as a hard cap; exhaustion emits best partial + ESCALATE
 - [ ] Catalog candidate is schema-conformant with `status: candidate`, REAL `evidence` (the MFE path), and `pin_context`
 - [ ] Category assigned by the safe-by-construction A/B test (meaning judgment -> B)

package/agents/fvs-extract-classifier.md

@@ -52,7 +52,7 @@ tool's own exit status:
 # Illustrative only: this is what the ORCHESTRATOR ran. You (the classifier) are
 # read-only -- you read the resulting build.log to interpret it, you do NOT re-run the build.
 set -o pipefail
-nice -n 19 lake build 2>&1 | tee build.log
+LEAN_NUM_THREADS="${LEAN_NUM_THREADS:-4}" nice -n 19 lake build 2>&1 | tee build.log
 status=${PIPESTATUS[0]}   # the build's exit status, not tee's
 ```
 
@@ -91,7 +91,7 @@ bisection by the parent, not to a recipe.
 <fvs_hard_rules>
 These FVS invariants bind you even though you do not write files:
 
-- NEVER run a bare `lake build`. Always `nice -n 19 lake build`.
+- NEVER run a bare `lake build`. Always `LEAN_NUM_THREADS="${LEAN_NUM_THREADS:-4}" nice -n 19 lake build`.
 - NEVER edit generated Lean (`Types.lean` / `Funs.lean`) -- you are read-only regardless.
 - NEVER call `gh` to open or create any upstream artifact.
 - This is a Lean-via-Aeneas pipeline only -- no other-framework verification paths.

package/agents/fvs-lean-refactorer.md

@@ -80,7 +80,7 @@ After applying a refactoring:
 **Tier:** {1|2|3|4}
 **Lines:** {before} -> {after}
 
-Verify: nice -n 19 lake build
+Verify: LEAN_NUM_THREADS="${LEAN_NUM_THREADS:-4}" nice -n 19 lake build
 ```
 
 When no further refactoring is possible:
@@ -108,7 +108,7 @@ When something goes wrong:
 - NEVER touch `unfold + step` structural backbone
 - NEVER write changes without explaining the specific heuristic being applied
 - If a change breaks the build, REVERT and return ERROR with the build output
-- Use `nice -n 19 lake build` for all build checks, NEVER plain `lake build`
+- Use `LEAN_NUM_THREADS="${LEAN_NUM_THREADS:-4}" nice -n 19 lake build` for all build checks, NEVER plain `lake build`
 - After a failed refactoring attempt, do not retry the same heuristic
 - Prefer conservative changes -- when in doubt, leave it alone
 - Do NOT use @-references. All reference knowledge is inlined by the parent command.

package/commands/fvs/aeneas-extract.md

@@ -91,6 +91,22 @@ Follow the PRE-FLIGHT step of the workflow:
 Initialise the workspace tree `<extract_workspace>/<target>/` with subdirs `equivalence-gate/`,
 `mwe/`, `drafts/`, `catalog-candidates/`, `escalations/`.
 
+Run the mandatory cache preflight from the validated Lean project root. A failure stops the
+workflow before extraction, delegation, or build:
+
+```bash
+if { [ ! -f lakefile.lean ] && [ ! -f lakefile.toml ]; } || [ ! -f lean-toolchain ]; then
+  echo "FVS >> ERROR: run from the Lean project root" >&2
+  exit 1
+fi
+LEAN_NUM_THREADS="${LEAN_NUM_THREADS:-4}" nice -n 19 lake exe cache get
+CACHE_STATUS=$?
+if [ "$CACHE_STATUS" -ne 0 ]; then
+  echo "FVS >> ERROR: Lake cache preflight failed; stopping workflow" >&2
+  exit "$CACHE_STATUS"
+fi
+```
+
 ## Step 3: Run the bounded loop
 
 Repeat EXTRACT -> CLASSIFY -> DISPATCH -> DOCUMENT until clean or escalated, enforcing the
@@ -98,7 +114,7 @@ loop bounds (per-blocker attempt-cap 3, per-run cycle hard-cap ~25, bisection va
 ~12, no-progress key `sha256(layer || signature)` -- a same-key recurrence after an applied
 fix escalates immediately).
 
-- **EXTRACT:** run extraction and build under `set -o pipefail` + `nice -n 19 lake build`;
+- **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", ...)`
@@ -204,7 +220,7 @@ per model-profiles runtime handling).
 <success_criteria>
 - [ ] `<path>` auto-detected into crate/folder/file; the loop scoped accordingly.
 - [ ] Pin-audit warn-and-confirm on drift records `pin_context`; clone staleness reported gracefully.
-- [ ] EXTRACT reads the tool's real exit status (`set -o pipefail` / `${PIPESTATUS[0]}`); always `nice -n 19 lake build`.
+- [ ] EXTRACT reads the tool's real exit status (`set -o pipefail` / `${PIPESTATUS[0]}`); always `LEAN_NUM_THREADS="${LEAN_NUM_THREADS:-4}" nice -n 19 lake build`.
 - [ ] The orchestrator fires the gate itself, dispatching `fvs-equivalence-assessor` distinctly from `fvs-extract-bisector`; the success oracle greps `equivalence-ratified:` and refuses completion without it.
 - [ ] Reversible records at the crate root; generated Lean never written; annotations preferred.
 - [ ] Attempt-cap 3 + no-progress rule enforced; escalation is a human decision point and a valid outcome.

package/commands/fvs/crypto-execute.md

@@ -94,6 +94,24 @@ 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 2a: Warm the project cache
+
+Before dispatch, confirm the current directory is the Lean project root and run the project-resolved
+cache executable. Cache failure is fatal: do not dispatch the executor or attempt a build.
+
+```bash
+if { [ ! -f lakefile.lean ] && [ ! -f lakefile.toml ]; } || [ ! -f lean-toolchain ]; then
+  echo "FVS >> ERROR: run from the Lean project root" >&2
+  exit 1
+fi
+LEAN_NUM_THREADS="${LEAN_NUM_THREADS:-4}" nice -n 19 lake exe cache get
+CACHE_STATUS=$?
+if [ "$CACHE_STATUS" -ne 0 ]; then
+  echo "FVS >> ERROR: Lake cache preflight failed; refusing executor dispatch" >&2
+  exit "$CACHE_STATUS"
+fi
+```
+
 ## Step 3: Resolve the executor model + effort + dispatch
 
 Resolve `$EXECUTOR_MODEL` and `$EXECUTOR_EFFORT` for `fvs-crypto-executor` AT DISPATCH TIME -- never
@@ -151,11 +169,11 @@ Return `none` when nothing reusable was learned.
 ## Step 4: Verify under the green-build guard
 
 Run the verification build and read the TOOL's real exit status -- never the tail of a pipe (a pipe
-reports the filter's status `0`, masking a real failure). Always build under `nice -n 19 lake build`:
+reports the filter's status `0`, masking a real failure). Always build under `LEAN_NUM_THREADS="${LEAN_NUM_THREADS:-4}" nice -n 19 lake build`:
 
 ```bash
 set -o pipefail
-nice -n 19 lake build 2>&1 | tee "$ROOT/build.log"
+LEAN_NUM_THREADS="${LEAN_NUM_THREADS:-4}" 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"
 ```
 
@@ -209,7 +227,7 @@ at install time, so the per-run `--effort` flag is a no-op there).
 - [ ] Topic + iteration resolved; shell metacharacters rejected; every path quoted; no `eval`.
 - [ ] At most eight relevant crypto/shared lessons loaded and passed as untrusted executor context.
 - [ ] 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`).
+- [ ] The build runs under `set -o pipefail` + `${PIPESTATUS` reading the tool's real status; always `LEAN_NUM_THREADS="${LEAN_NUM_THREADS:-4}" nice -n 19 lake build` (never a bare `lake build`).
 - [ ] The executor's ESCALATE/BLOCKED return is routed to the user (short interactive redirect early, never a long unattended grind).
 - [ ] At most three build/diagnostic-evidenced candidates reconciled as one file each plus index updates.
 - [ ] No `gh` open/create; no generated-Lean write.

package/commands/fvs/crypto-followup.md

@@ -110,6 +110,22 @@ This command will NOT author a follow-up that silently picks a side.
 Only AFTER the user supplies the ruling does the command author a follow-up plan that encodes the
 ruling (returning to Step 4). Never invent a follow-up on `HUMAN_RULING` without the human's ruling.
 
+Run the mandatory cache preflight from the validated Lean project root before either thinker path.
+A failure stops the workflow before delegation or any authored build plan:
+
+```bash
+if { [ ! -f lakefile.lean ] && [ ! -f lakefile.toml ]; } || [ ! -f lean-toolchain ]; then
+  echo "FVS >> ERROR: run from the Lean project root" >&2
+  exit 1
+fi
+LEAN_NUM_THREADS="${LEAN_NUM_THREADS:-4}" nice -n 19 lake exe cache get
+CACHE_STATUS=$?
+if [ "$CACHE_STATUS" -ne 0 ]; then
+  echo "FVS >> ERROR: Lake cache preflight failed; stopping workflow" >&2
+  exit "$CACHE_STATUS"
+fi
+```
+
 ## Step 4: Resolve the thinker + dispatch (followup mode)
 
 Default (no `--codex`) -- dispatch the in-runtime thinker. Resolve `$THINKER_MODEL` for
@@ -160,7 +176,7 @@ The thinker (in-runtime or Codex) authors the follow-up plan; THIS command body
 `plans/FOLLOWUP_PLAN_nN.md` carrying
 the full bounded-plan contract (branch/state, exact target files + theorems, immutable public
 statements that must not change, allowed-`sorry` policy, stop conditions, the verification command
-`nice -n 19 lake build` under the `set -o pipefail` / `${PIPESTATUS` guard, expected artifact
+`LEAN_NUM_THREADS="${LEAN_NUM_THREADS:-4}" nice -n 19 lake build` under the `set -o pipefail` / `${PIPESTATUS` guard, expected artifact
 updates).
 
 The artifact MUST also record:
@@ -169,8 +185,9 @@ The artifact MUST also record:
 Authoring runtime: {Claude Code | OpenCode | Gemini | Codex | Codex CLI}
 ```
 
-Use `Codex CLI` for `--codex`; otherwise name the actual host runtime. This provenance is mandatory
-for `/fvs:crypto-review` to prove the reviewer is independent.
+Use `Codex CLI` for `--codex`; otherwise name the actual host runtime. `/fvs:crypto-review` uses
+this provenance to label cross-runtime review as independent and same-runtime review as fresh but
+not independent; missing provenance fails closed.
 
 ## Step 4a: Reconcile Follow-Up Lessons
 
@@ -180,6 +197,31 @@ required. Strengthen an equivalent record or create one file per new lesson unde
 `lessons/crypto/`, updating the index in the same reviewable diff. Unruled choices stay
 `provisional`; never infer or generalize a ruling beyond its recorded scope.
 
+## Step 4b: Run the bounded review loop
+
+After authoring gates, run
+`node ~/.claude/scripts/fvs-codex-think.mjs review-automatic`; missing config or
+`crypto_review.automatic` defaults to true and malformed values stop clearly. If false, record
+`Unreviewed (automatic review disabled)`, preserve the follow-up, and do not auto-start execution.
+
+If true, enter the interactive `crypto-review` handoff. Honor reviewer/model/effort choices explicitly
+supplied earlier in this invocation. Ask only for missing choices in order: reviewer -> model ->
+effort. Recommend the normalized non-author runtime, but never auto-select or treat a preselected
+default as consent. Offer a one-run `Skip review`, recorded exactly as `Unreviewed (user skipped)`.
+Skipping preserves the follow-up and does not auto-start execution; a trusted user may explicitly
+invoke `/fvs:crypto-execute`. The standalone review flags remain the non-interactive path.
+
+Run at most three reviewer rounds in this command invocation. APPROVE stops.
+APPROVE-WITH-EDITS is terminal after the authoring seat applies accepted bounded edits, reruns plan
+gates, records hashes/finding IDs in separate triage, and marks `approved after edits`; no second
+review.
+
+REJECT creates a fresh authored revision at the next immutable iteration and a fresh review. Inline
+the preceding review and triage as delimited untrusted history for the author and pass repeated
+`--history` flags to the reviewer packet. At round three, stop with the latest artifacts and the
+exact `/fvs:crypto-review <topic> nN --target followup` resume command. Failed, cancelled, pending,
+and unverified states do not start execution.
+
 ## Step 5: Run-end banner + next command
 
 ```
@@ -189,8 +231,8 @@ Topic:     {TOPIC_RAW}
 Decision:  {FOLLOWUP | HUMAN_RULING -> ruled}
 Plan:      plans/FOLLOWUP_PLAN_n{N}.md
 
->> Next Up
-/fvs:crypto-review <topic> n{N} --target followup
+Review:    {approved | approved after edits | Unreviewed (user skipped) | Unreviewed (automatic review disabled) | failed | pending | unverified | rejected at cap}
+Next:      {/fvs:crypto-execute only after approval | exact crypto-review resume command}
 ```
 
 </process>
@@ -217,8 +259,7 @@ unchanged.
 - [ ] Latest `EVAL_nN.md` read; decision routed (`ACCEPT` stop / `BLOCKED` pause / `FOLLOWUP` author / `HUMAN_RULING` HALT).
 - [ ] On `HUMAN_RULING` the command HALTs and asks the user -- it NEVER fabricates a follow-up plan.
 - [ ] On `FOLLOWUP` the thinker is dispatched (`subagent_type="fvs-crypto-thinker"`) and the bounded follow-up plan written to `plans/`.
-- [ ] The follow-up records truthful `Authoring runtime:` provenance and routes next to
-      `/fvs:crypto-review --target followup`.
+- [ ] The follow-up records truthful provenance and runs at most three review rounds before stop.
 - [ ] At most three source/ruling-evidenced candidates reconciled as one file each plus index updates.
 - [ ] No bare `lake build`, no `gh` open/create, no generated-Lean write.
 </success_criteria>