fv-skills-baif 2.3.1 → 2.3.4

package/CHANGELOG.md

@@ -4,6 +4,57 @@ All notable changes to FVS (Formal Verification Skills) will be documented in th
 
 The format is based on [Keep a Changelog](https://keepachangelog.com/).
 
+## [Unreleased]
+
+## [2.3.4] - 2026-09-20
+
+### Fixed
+
+- Crypto evaluation now trusts Lean's kernel for checked proof terms and concentrates adversarial
+  review on statement/source conformance and trust-boundary evidence. It reuses a current executor
+  build log or runs one bounded fallback without retry, rather than repeating proof derivations,
+  executor gates, or external numeric computations.
+
+## [2.3.3] - 2026-09-20
+
+### Added
+
+- FVS is now a native Pi package with 29 generated skills, provider-qualified model handling,
+  `/skill:fvs-*` invocation guidance, and direct `pi install npm:fv-skills-baif` support (#62).
+- `/fvs:configure` and every delegated workflow now use stage-scoped, runtime-aware model profiles.
+  Quality selects authority, execution, and scout tiers from the live runtime catalog; commands show
+  one confirmable model/effort manifest and fail closed when a provider or dispatch cannot honor it
+  (#64).
+
+### Fixed
+
+- Fresh local Codex installs create their configuration directory before patch discovery. Local
+  patch metadata now separates immutable history from active pending patches, preserves real edits
+  without treating unchanged generated TOML as custom, and retires resolved patches atomically
+  (#60).
+- FC and crypto reviews require explicit catalog-resolved model/effort selections, preserve raw and
+  normalized responses separately, retain writable diagnostic scratch without exposing source
+  writes, and enforce consistent verdict, severity, authority, and thread-count contracts (#60).
+
+## [2.3.2] - 2026-09-10
+
+### Fixed
+
+- Updates preserve added and modified local FVS files in complete, versioned patch bundles,
+  recover legacy unlisted backups, and track generated Codex agent/hook files. Failed backup
+  validation stops installation before replacement (#55).
+- Claude crypto and FC reviewers can run bounded diagnostic probes in native-sandboxed scratch
+  space with explicit generated Lake output paths. Failed launches and invalid responses retain
+  local evidence. Sources/plans remain protected; model/effort selection is unchanged (#58).
+
+### Added
+
+- Crypto and FC reviews receive bounded source/reuse inventories with verbatim signature spans
+  and freshness checks. FC grounds behavior in implementation source and checks project/mathlib
+  helper reuse. Review contracts cover scope economy, CONTENT/PROCESS findings, mathematical
+  coverage, and explicit author dispositions. Complete finding validation and mechanical-only
+  formatting repair preserve review substance; APPROVE-WITH-EDITS remains terminal (#56).
+
 ## [2.3.1] - 2026-09-09
 
 ### Added

package/README.md

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

package/agents/fvs-crypto-thinker.md

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