fv-skills-baif 2.2.1 → 2.3.0

package/CHANGELOG.md

@@ -4,6 +4,30 @@ 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.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,22 @@ 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`, a review menu 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. Reviews and source hashes live under `.formalising/spec-reviews/`.
+
+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

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:

package/commands/fvs/crypto-plan.md

@@ -130,6 +130,22 @@ Then PROCEED only at the user's explicit choice in a LABELED DEGRADED mode -- re
 formalisation was not paper-grounded. Do NOT silently continue; do NOT repeat the loud-fail on
 every question (loud-fail ONCE, then degrade or stop on the user's choice).
 
+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 5: Dispatch the thinker (author the bounded plan)
 
 Default (no `--codex`) -- dispatch the in-runtime thinker. `cat` the topic artifacts and the cached
@@ -200,7 +216,7 @@ Carry the BOUNDED-PLAN CONTRACT verbatim into `EXEC_PLAN_nN.md`:
 5. **Allowed-`sorry` policy** -- which `sorry`s are permitted as NAMED obligations with the exact
    statement each must carry (never judged by count).
 6. **Stop conditions** -- the explicit conditions under which the executor HALTS.
-7. **Verification commands** -- ALWAYS `nice -n 19 lake build` (never a bare `lake build`), under
+7. **Verification commands** -- ALWAYS `LEAN_NUM_THREADS="${LEAN_NUM_THREADS:-4}" nice -n 19 lake build` (never a bare `lake build`), under
    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.
@@ -251,7 +267,7 @@ auto-picks a default, never writes an upstream artifact).
 - [ ] At most eight relevant crypto/shared lessons loaded and snapshotted for either thinker runtime.
 - [ ] `$THINKER_MODEL` resolved via the model-profiles sequence; the thinker dispatched (`subagent_type="fvs-crypto-thinker"`) with inlined context.
 - [ ] KB grounded intensively when configured; cached under `sources/` and re-read before re-querying; loud-fail-once + labeled-degrade + `/fvs:kb-setup` when unconfigured.
-- [ ] The bounded-plan contract (stop conditions, verification commands `nice -n 19 lake build`, immutable public statements, allowed-`sorry`) is written into `EXEC_PLAN_nN.md`.
+- [ ] The bounded-plan contract (stop conditions, verification commands `LEAN_NUM_THREADS="${LEAN_NUM_THREADS:-4}" nice -n 19 lake build`, immutable public statements, allowed-`sorry`) is written into `EXEC_PLAN_nN.md`.
 - [ ] Both plan artifacts record truthful `Authoring runtime:` provenance; the next action is
       independent `/fvs:crypto-review`, not direct execution.
 - [ ] At most three evidence-gated lesson candidates reconciled as one file each plus index updates.

package/commands/fvs/fc.md

@@ -1,11 +1,11 @@
 ---
 name: fvs:fc
-description: "formal-verification core | plan specify verify explain refactor"
+description: "formal-verification core | plan specify review verify explain refactor"
 argument-hint: ""
 allowed-tools:
   - Read
   - Skill
-requires: [fc-plan, lean-specify, lean-verify, natural-language, lean-refactor, trust-audit]
+requires: [fc-plan, lean-specify, lean-spec-review, lean-verify, natural-language, lean-refactor, trust-audit]
 ---
 
 Route to the appropriate formal-verification-core skill based on the user's intent.
@@ -19,6 +19,7 @@ When invoked WITH a request, match it against the table below and invoke the mat
 |---|---|
 | Pick next verification targets | fvs:fc-plan |
 | Generate a Lean spec skeleton | fvs:lean-specify |
+| Adversarially review a specification against source | fvs:lean-spec-review |
 | Attempt a proof | fvs:lean-verify |
 | Explain a module/function in natural language | fvs:natural-language |
 | Refactor / simplify / decompose a proof | fvs:lean-refactor |

package/commands/fvs/help.md

@@ -27,7 +27,7 @@ Commands are grouped into five bundles. Each bundle has a router command (e.g. `
 1. `/fvs:aeneas-extract <path>` - Extract Rust → Lean 4 via the bounded Aeneas repair loop
 2. `/fvs:map-code` - Analyze project, build dependency graph
 3. `/fvs:fc-plan` - Select verification targets
-4. `/fvs:lean-specify <function>` - Generate spec with sorry
+4. `/fvs:lean-specify <function>` - Generate spec with sorry, then choose an adversarial reviewer
 5. `/fvs:lean-verify <spec_path>` - Attempt proof interactively
 6. `/fvs:lean-refactor <spec_path>` - Golf and clean up verified proofs
 7. `/fvs:trust-audit <target>` - Audit the sorry/axiom trust surface
@@ -39,7 +39,7 @@ Commands are grouped into five bundles. Each bundle has a router command (e.g. `
 ## Core Workflow
 
 ```
-Code track:  /fvs:aeneas-extract → /fvs:map-code → /fvs:fc-plan → /fvs:lean-specify → /fvs:lean-verify → /fvs:lean-refactor → /fvs:trust-audit
+Code track:  /fvs:aeneas-extract → /fvs:map-code → /fvs:fc-plan → /fvs:lean-specify → /fvs:lean-spec-review → /fvs:lean-verify → /fvs:lean-refactor → /fvs:trust-audit
 Paper track: /fvs:lean-formalise → /fvs:lean-verify → /fvs:lean-refactor
 Crypto loop: /fvs:crypto-plan → /fvs:crypto-review → /fvs:crypto-execute → /fvs:crypto-eval → /fvs:crypto-followup → /fvs:crypto-review → repeat
 ```
@@ -50,7 +50,7 @@ Five router commands group the skills. Invoke a router bare to print its routing
 
 - `/fvs:aeneas` — Aeneas/Charon extraction maintenance (aeneas-extract, sync-aeneas-verif)
 - `/fvs:context` — Codebase context (map-code)
-- `/fvs:fc` — Formal-correctness core (fc-plan, lean-specify, lean-verify, natural-language, lean-refactor, trust-audit)
+- `/fvs:fc` — Formal-correctness core (fc-plan, lean-specify, lean-spec-review, lean-verify, natural-language, lean-refactor, trust-audit)
 - `/fvs:formalise` — Paper formalisation (lean-formalise, lean-refactor)
 - `/fvs:manage` — Management (help, update, checkpoint, pause-work, resume-work, reapply-patches, kb-setup)
 
@@ -132,6 +132,23 @@ Generate Lean spec skeleton following @[step] theorem pattern.
 Usage: `/fvs:lean-specify scalar_mul_inner`
 Result: `Specs/{path}/{FunctionName}.lean` with sorry placeholder
 
+**`/fvs:lean-spec-review <spec.lean> [--reviewer codex|claude|other] [--model ID] [--effort LEVEL]`**
+Adversarially review an FC specification against Rust, extracted Lean, and interpretation definitions.
+
+- Offers reviewer -> model -> effort menus; the other runtime appears first
+- Codex suggestions: GPT Sol and Astra; Claude suggestion: Fable; cheaper/custom models allowed
+- Effort defaults to `max`; lower settings and `runtime-default` remain selectable
+- Uses fresh reviewers and labels cross-runtime versus same-runtime review
+- Other providers use an exported packet and imported response; missing CLIs offer setup/fallback
+- Preserves the spec and records findings, input hashes, and triage in `.formalising/spec-reviews/`
+- PASS readies the statement for proof; REVISE/BLOCKED need corrections or evidence
+
+Runs automatically after `lean-specify` by default, even on projects without config. To disable
+only automation, merge `"spec_review": {"automatic": false}` into `.formalising/fvs-config.json`,
+or create the file with `{"spec_review": {"automatic": false}}`. Manual invocation still works.
+
+Usage: `/fvs:lean-spec-review Specs/Scalar/Mul.lean --reviewer codex --model gpt-6-astra --effort max`
+
 **`/fvs:lean-verify <spec_file_path>`**
 Attempt proof using domain tactics with interactive feedback.
 
@@ -173,7 +190,7 @@ Usage: `/fvs:lean-refactor Specs/Backend/Field/Sub.lean --theorem sub_spec --rep
 **`/fvs:trust-audit <target spec file | module subtree>`**
 Build-backed trust audit of an Aeneas-extracted Lean target.
 
-- Runs `nice -n 19 lake build` as a green-build-guarded precondition; HALTs if the target layer does not compile
+- Runs `LEAN_NUM_THREADS="${LEAN_NUM_THREADS:-4}" nice -n 19 lake build` as a green-build-guarded precondition; HALTs if the target layer does not compile
 - Dispatches the read-only `fvs-axiom-auditor` to introspect every in-scope declaration via `#print axioms`
 - Classifies each: `sorryAx` ⇒ sorry, classical trio (propext / Classical.choice / Quot.sound) auto-noted, project-custom axioms require justification
 - Strictly-scoped inventory (Rust path convention); cone members surfaced as prerequisites, never inventory rows

package/commands/fvs/lean-formalise.md

@@ -124,6 +124,24 @@ For images (PNG/JPG): note they will be read via Claude's vision capability (Rea
 
 If no resources and no KB: warn that the researcher will have limited context, but continue -- the user may be working from general mathematical knowledge.
 
+### Mandatory Lake cache preflight
+
+Run this from the validated Lean project root before either subagent dispatch. A failure stops the
+workflow before 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 2a: Load Bounded Proof-Engineering Memory
 
 Follow `proof-engineering-loop.md` and initialize `.formalising/proof-engineering/`. Classify this
@@ -331,12 +349,12 @@ Check:
 ## Step 9: Optional Build Check
 
 ```bash
-nice -n 19 lake build 2>&1 | tail -20
+LEAN_NUM_THREADS="${LEAN_NUM_THREADS:-4}" nice -n 19 lake build 2>&1 | tail -20
 ```
 
 - sorry warnings are expected and correct at this stage
 - Import errors or type errors noted for user
-- NEVER run plain `lake build`. Always use `nice -n 19 lake build`.
+- NEVER run plain `lake build`. Always use `LEAN_NUM_THREADS="${LEAN_NUM_THREADS:-4}" nice -n 19 lake build`.
 
 ## Step 9a: Reconcile Proof-Engineering Lessons
 
@@ -377,7 +395,7 @@ Status:    [??] Ready for verification (contains sorry)
 - [ ] Researcher's proposed structure reviewed by user before execution
 - [ ] Executor subagent created both definition files AND spec files
 - [ ] Generated files validated (sorry present, imports consistent)
-- [ ] Build check uses nice -n 19 lake build (never plain lake build)
+- [ ] Build check uses LEAN_NUM_THREADS="${LEAN_NUM_THREADS:-4}" nice -n 19 lake build (never plain lake build)
 - [ ] At most three evidence-gated candidates reconciled as one lesson per file plus index updates
 - [ ] Summary uses FVS >> FORMALISE banner with file list
 - [ ] Clear next step offered: /fvs:lean-verify