fv-skills-baif 2.3.5 → 2.3.6

package/CHANGELOG.md

@@ -6,6 +6,37 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/).
 
 ## [Unreleased]
 
+## [2.3.6] - 2026-09-29
+
+### Added
+
+- `/fvs:map-code`, `/fvs:fc-plan`, and `/fvs:trust-audit` first check whether the project has a
+  verified probe-aeneas: its Aeneas, Charon, and Lean versions must match a tested combination and
+  every helper must report the tested version. On macOS arm64, FVS can install the pinned official
+  probe-aeneas v0.20.0 into its own versioned directory after you agree, and it runs extraction in
+  a sandbox with no network access and no writes outside the project's build directories, the
+  output, and a private temporary directory. Without a verified probe you can set it up, continue
+  without a graph (qualitative notes only, no counts or verdicts), or cancel. Linux support is
+  tracked in #77 (#69).
+- Crypto and Lean specification reviews report how many grounding signature lines they charge and
+  the first reference that exceeds the budget. A read-only `preflight` checks a request without
+  contacting a reviewer (#73).
+- In Codex marketplace installs, a workflow that requests an unregistered FVS specialist now warns.
+  It then runs a labeled generic agent, or stops before dispatch when the step depends on the
+  specialist's settings. The README explains how to switch to the direct Codex installation, which
+  registers the specialist roles (#71).
+
+### Fixed
+
+- Completed Claude and Codex reviews are no longer rejected when the reviewer writes one plain
+  progress sentence before the required title (#72).
+- Native reviewers run in their own process group with a 20-minute review deadline and a 30-second
+  version and authentication deadline (`FVS_REVIEW_TIMEOUT_MS`, `FVS_REVIEW_AUTH_TIMEOUT_MS`). On
+  timeout or interruption FVS stops the whole group, including descendants. Cleanup is tested on
+  macOS and Linux; Windows refuses to launch native reviewers (#75).
+- When its sync metadata is missing, `/fvs:sync-aeneas-verif` points only to `/fvs:update`, which
+  updates the installation you already have, and no longer suggests the npm installer.
+
 ## [2.3.5] - 2026-09-21
 
 ### Added

package/README.md

@@ -90,7 +90,31 @@ codex plugin add fvs@beneficial-ai-foundation
 ```
 
 Start a new session after installation. Run `/fvs:help` in Claude Code or mention `$fvs:help` in
-Codex. To refresh an existing install, update the catalog and then update or reinstall FVS:
+Codex.
+
+On Codex, the marketplace plugin ships the FVS agent prompts as Markdown but does not register them
+as Codex agent roles. When a workflow asks for an FVS specialist that Codex has not registered, FVS
+warns you. If the step does not depend on that specialist's settings, FVS runs a generic Codex agent
+with the specialist's prompt and labels its output, but Codex then does not guarantee the
+specialist's identity, sandbox, model, or reasoning effort. If the step does depend on them, FVS
+stops before starting the agent or writing files. A role registered some other way still has its
+settings checked at run time.
+
+#### Codex specialist roles
+
+Use one FVS installation per runtime. The npm installer installs a complete, separately managed FVS
+for Codex: skills as `$fvs-<name>`, scripts, hooks, a `config.toml` block, and the `fvs-*` agent
+roles. To get registered roles today, switch installations rather than adding a second copy:
+
+```bash
+codex plugin remove fvs@beneficial-ai-foundation
+npx fv-skills-baif --codex --global
+```
+
+Adding or updating the marketplace plugin, including with `$fvs:update`, never registers roles or
+runs the npm installer.
+
+To refresh an existing install, update the catalog and then update or reinstall FVS:
 
 ```bash
 # Claude Code

package/bin/install.js

@@ -878,13 +878,13 @@ function getCodexSkillAdapterHeader(skillName, options = {}) {
     ? `\n## D. Shared Plugin Syntax\n- This file is shared with Claude Code. On Codex, interpret \`/${pluginName}:<name>\` references as \`$${pluginName}:<name>\`.\n- Treat \`$ARGUMENTS\` in the shared body as \`{{FVS_ARGS}}\`.\n- \`\${CLAUDE_PLUGIN_ROOT}\` is the installed plugin root. If a host leaves that token unexpanded, resolve the plugin root as two directories above this SKILL.md.\n`
     : '';
   const typedDispatchQualification = pluginName
-    ? `\nEven when \`agent_type\` is present, typed dispatch is available only if the exact requested FVS type is advertised by the tool schema or a confirmed runtime registry. Codex marketplace plugins do not register the bundled Claude agent Markdown as typed Codex agents, so otherwise use the bundled-agent workaround below.\n`
+    ? `\n**Requested specialist gate (at dispatch only):** When a workflow requests a named FVS specialist, check BOTH the visible \`spawn_agent\` schema and whether the exact requested \`agent_type\` is advertised there or in a confirmed runtime registry. An \`agent_type\` field alone is not evidence that this role is registered; bundled \`agents/*.md\` are instructions, not registered Codex specialists. If the exact role is registered and \`agent_type\` is available, use typed mapping below WITHOUT a missing-role warning. Otherwise, even if \`agent_type\` is present, warn the user in plain language: Requested FVS specialist <agent-name> is not registered in this Codex session; the bundled Markdown cannot supply typed identity. Do not warn merely for opening help, installing, or mentioning a skill without requesting specialist dispatch. Apply the settings gate below before considering the generic-agent workaround. Never run an installer on the user's behalf.\n`
     : '';
   const typedModelNote = pluginName
-    ? 'The marketplace plugin does not install Codex agent TOML. Use this mapping only when the exact FVS agent type is registered independently; otherwise use the bundled-agent workaround.'
-    : 'Installed agent TOML supplies only a fallback effort; it does not prove that the command-level stage selection was applied.';
+    ? 'The marketplace plugin does not install Codex agent TOML; use typed mapping only for an independently registered exact role.'
+    : 'Installed agent TOML pins its own effort, which overrides a per-call value; check the pinned effort against the confirmed selection.';
   const fallbackSteps = pluginName
-    ? `1. Read \`\${CLAUDE_PLUGIN_ROOT}/agents/<agent-name>.md\` and extract its instructions. If the token is still literal, resolve the path from this SKILL.md as described above.\n2. Spawn a generic/default agent and inject those instructions as a role preamble before the task prompt.\n3. Label results clearly as \"generic-agent workaround\" so the user knows typed guarantees are not in effect.\n4. Where typed dispatch is mandatory for correctness, fail closed and report the schema limitation rather than silently degrading.`
+    ? `1. Read \`\${CLAUDE_PLUGIN_ROOT}/agents/<agent-name>.md\` and extract its instructions. If the token is still literal, resolve the path from this SKILL.md as described above.\n2. Only when the settings gate permits generic execution, spawn a generic/default child with those instructions as a role preamble before the task prompt. Do not pass an unregistered \`agent_type\`.\n3. Label output \"generic-agent workaround\". This is NOT equivalent to a registered specialist: the preamble does not assure typed identity, sandbox, model, or reasoning effort.\n4. If required guarantees cannot be honored, stop before dispatch or artifact writes; explain which guarantee is missing. Typed FVS roles currently require the direct Codex installation, a separate complete FVS install: point the user to "Codex specialist roles" in the FVS README and never suggest keeping both channels. Even after switching, confirm exact registration and settings in the runtime.`
     : `1. Resolve your active Codex config root (the directory containing your \`config.toml\`), then read \`agents/<agent-name>.toml\` relative to that root to extract the agent's instructions.\n2. Inject those instructions as a role-preamble into a generic \`spawn_agent(message=...)\` call.\n3. Label results clearly as \"generic-agent workaround\" so the user knows typed guarantees are not in effect.\n4. Where typed dispatch is mandatory for correctness, fail closed and report the schema limitation rather than silently degrading.`;
   return `<codex_skill_adapter>
 This block applies only when this shared skill runs in Codex. Claude Code must ignore it and use the
@@ -921,25 +921,25 @@ Execute mode fallback:
 ## C. Task() -> spawn_agent Mapping
 FVS workflows use \`Task(...)\` (Claude Code syntax). Translate to Codex collaboration tools:
 
-**Schema detection (required first step):** Codex exposes two \`spawn_agent\` schemas:
-- **agent_type-capable schema:** \`spawn_agent\` accepts \`agent_type\`, \`message\`, \`reasoning_effort\`, \`fork_context\`, etc. — typed FVS agent dispatch is available.
-- **Generic schema:** \`spawn_agent\` accepts only \`message\`, \`items\`, \`fork_context\` — there is **no \`agent_type\` field**. Typed FVS agent dispatch is unavailable in this session.
+**Schema detection (required first step):** Inspect the visible \`spawn_agent\` schema. It may have \`agent_type\` or be generic (no \`agent_type\`); inspect \`model\` and \`reasoning_effort\` fields independently rather than assuming either exists. An available \`agent_type\` field does not establish that a particular FVS role is registered.
 
 Before spawning, inspect the \`spawn_agent\` tool's visible parameter schema to determine which form is active.${typedDispatchQualification}
 
-Selection-capability gate (before manifest confirmation):
-- Compare the requested model with the exact active/inherited Codex model. Because \`spawn_agent\` has no inline model field, any different requested model is unresolved. Rebuild the manifest around the actual active model and ask explicitly, choose a capable external runner, or fail before dispatch in noninteractive mode.
-- When \`reasoning_effort\` is absent from the schema, compare the requested effort with the installed/runtime default. A mismatch is unresolved and follows the same rebuild/ask-or-fail rule.
-- Never confirm a requested model or effort and then omit it with a warning. ${typedModelNote}
+Selection-capability gate (before manifest confirmation, child dispatch, or artifact writes):
+- Check required specialist identity and sandbox against the exact registered role and effective child settings. A generic role preamble cannot meet a mandatory typed identity or sandbox requirement; stop and explain the unavailable guarantee before dispatch or artifact writes.
+- If \`model\` is exposed for this child, pass the requested model. Otherwise compare it with the exact active/inherited Codex model; a different or unconfirmed model is unresolved. Rebuild the manifest around confirmed settings and ask explicitly, choose a capable external runner, or fail before dispatch in noninteractive mode.
+- If \`reasoning_effort\` is exposed for this child, pass the requested effort. Otherwise compare it with the confirmed effective installed/runtime default; a different or unconfirmed effort is unresolved and follows the same rebuild/ask-or-fail rule.
+- Model and effort are separate values: pass an exact catalog model id and an effort that model lists. A registered role that pins \`model\` or \`reasoning_effort\` (its role description says the setting is locked, or its TOML sets it) overrides the per-call value, so the pinned value is the effective one; if it differs from the confirmed selection it is unresolved.
+- Never confirm a requested specialist setting and then omit it with a warning. ${typedModelNote}
 
-Typed mapping (agent_type-capable schema only):
+Typed mapping (only when the exact requested FVS role is registered AND agent_type is exposed):
 - \`Task(subagent_type="X", prompt="Y")\` -> \`spawn_agent(agent_type="X", message="Y")\`
-- \`Task(model="...")\` -> omit only after the selection-capability gate proves it equals the active/inherited model.
-- \`Task(reasoning_effort="...")\` -> \`spawn_agent(reasoning_effort="...")\` when that field is present. If absent, dispatch only after the gate proves the installed/runtime default equals the confirmed effort.
+- \`Task(model="...")\` -> pass \`model\` if available for this child; otherwise omit only after the selection-capability gate proves it equals the active/inherited model.
+- \`Task(reasoning_effort="...")\` -> pass \`reasoning_effort\` if available for this child and the role does not pin it; otherwise omit only after the gate proves the effective (pinned or default) effort equals the confirmed effort.
 - \`fork_context: false\` by default -- FVS agents load their own context via \`<files_to_read>\` blocks.
 
-Generic-agent workaround (schema with NO agent_type field):
-When only the generic schema is available, typed FVS agent dispatch (${dispatchExamples}, etc.) is NOT possible. This workaround is NOT equivalent to typed execution — FVS agents carry verification-aware prompts and sandbox settings a generic subagent lacks. Fallback:
+Generic-agent workaround (missing exact registered role OR no agent_type field):
+If the requested FVS type (${dispatchExamples}, etc.) is not registered, typed dispatch is NOT possible even with an \`agent_type\` field. If the field is absent, typed dispatch is also unavailable. Fallback:
 ${fallbackSteps}
 
 Parallel fan-out:

package/commands/fvs/crypto-review.md

@@ -85,6 +85,20 @@ scout. Save a fresh inventory under this topic's `reviews/_grounding/` and set
 `GROUNDING_FILE` to its project-relative path. Check the plan's `## Reuse audit`;
 missing analysis belongs in reviewer findings, not a fabricated scout result.
 
+Check the signature-line budget first. This is read-only: it creates no review files and
+contacts no reviewer.
+
+```bash
+node ~/.claude/scripts/fvs-codex-think.mjs review-preflight \
+  --topic "$ROOT" --iteration "n$N" --target "$TARGET_KIND" --grounding "$GROUNDING_FILE"
+```
+
+It prints charged lines out of 200, with analog and `cited_apis` subtotals. Every span occurrence
+is charged, including repeats; the distinct-span count is informational only. On overrun it
+names the first span that crossed the limit and exits nonzero. Narrow the inventory or review
+scope as `review-grounding.md` describes (never compact repeated spans) and rerun it until it
+passes. Then run the review, which repeats the same check against current sources:
+
 ```bash
 node ~/.claude/scripts/fvs-codex-think.mjs review \
   --topic "$ROOT" --iteration "n$N" --target "$TARGET_KIND" \

package/commands/fvs/fc-plan.md

@@ -8,6 +8,7 @@ allowed-tools:
   - Glob
   - Grep
   - Write
+  - AskUserQuestion
   - Task
 ---
 
@@ -19,7 +20,8 @@ The helper owns membership, edges, endpoint sets, statuses, and progress. The re
 executor add only complexity, risk, and recommendation prose keyed by canonical atom ID.
 
 Output: .formalising/PLAN.md with qualitative target recommendations and a pointer to CODEMAP's
-checked generated facts.
+checked generated facts. Without a verified probe the user may continue without a graph; that
+exploratory run writes only `.formalising/PLAN-exploratory.md`.
 </objective>
 
 <execution_context>
@@ -30,14 +32,82 @@ checked generated facts.
 <context>
 Target function: $ARGUMENTS (optional -- narrows the displayed functions and progress denominator)
 
-Require `.formalising/CODEMAP.md`. A target changes only the selected view; endpoint membership
-still uses the complete project graph.
+Verified mode requires `.formalising/CODEMAP.md`. A target changes only the selected view;
+endpoint membership still uses the complete project graph.
 </context>
 
 <process>
 
+## Step 0: Choose verified or exploratory mode
+
+`PROJECT_ROOT` is the current directory.
+
+This is the first operational decision. Run it before path prompts, model selection,
+`.formalising/` writes, cache or build work, and any agent dispatch. The resolver is read-only:
+it compares the project's generated `translation.json`, its Aeneas pin in `lake-manifest.json`
+and `aeneas-config.yml`, and `lean-toolchain` with the tested tuples shipped in
+`fvs-probe-inventory.mjs`, then checks the probe-aeneas executable and the preinstalled helpers
+(probe-rust, probe-lean, scip, rust-analyzer). It reports `verified`, `missing`, `incompatible`,
+`unknown` (missing or conflicting provenance) or `unsupported-platform`, and never installs
+anything.
+
+```bash
+# fvs:probe-mode
+PROJECT_ROOT=$(cd "${PROJECT_ROOT:-$PWD}" && pwd -P) || exit 1
+INVENTORY_SCRIPT=~/.claude/scripts/fvs-probe-inventory.mjs
+PROBE_STATUS=$(node "$INVENTORY_SCRIPT" resolve --project-root "$PROJECT_ROOT" --format status) || exit 1
+node "$INVENTORY_SCRIPT" resolve --project-root "$PROJECT_ROOT" --format text
+FVS_MODE=
+if [ "$PROBE_STATUS" = verified ]; then FVS_MODE=verified; fi
+```
+
+`verified` continues without a prompt. For any other status in an interactive session, ask
+(AskUserQuestion; on Codex or Pi a plain-text question, then wait) with exactly these choices
+before doing anything else:
+
+- **Set up the verified probe.** When `resolve --format json` reports `install.available`, show
+  `node "$INVENTORY_SCRIPT" install --project-root "$PROJECT_ROOT" --manifest` (official URL,
+  pinned SHA-256, FVS-owned versioned destination, no PATH or shell-profile change) and ask
+  Install / Show manual instructions / Cancel. Install runs
+  `node "$INVENTORY_SCRIPT" install --project-root "$PROJECT_ROOT" --consent interactive`; then
+  rerun this step and continue verified only if it now reports `verified`. Missing or
+  incompatible helpers get the printed manual steps only: FVS never installs a helper. After
+  showing manual steps, stop so the user can rerun.
+- **Continue without graph.** Set `FVS_MODE=exploratory`.
+- **Cancel.** Stop now. Nothing has been written.
+
+A noninteractive run never prompts and never infers consent. Installing needs
+`FVS_PROBE_INSTALL_POLICY=install`; continuing without a graph needs the separate opt-in
+`FVS_ALLOW_EXPLORATORY=1`:
+
+```bash
+# fvs:probe-mode-noninteractive
+if [ -z "$FVS_MODE" ] && [ "${FVS_PROBE_INSTALL_POLICY:-}" = install ]; then
+  if node "$INVENTORY_SCRIPT" install --project-root "$PROJECT_ROOT" --consent policy; then
+    PROBE_STATUS=$(node "$INVENTORY_SCRIPT" resolve --project-root "$PROJECT_ROOT" --format status)
+    if [ "$PROBE_STATUS" = verified ]; then FVS_MODE=verified; fi
+  fi
+fi
+if [ -z "$FVS_MODE" ]; then
+  if [ "${FVS_ALLOW_EXPLORATORY:-}" = 1 ]; then
+    FVS_MODE=exploratory
+  else
+    echo "FVS >> probe-aeneas is $PROBE_STATUS for this project; set FVS_ALLOW_EXPLORATORY=1 to continue without a graph" >&2
+    exit 1
+  fi
+fi
+```
+
+Exploratory mode never writes the managed CODEMAP block, canonical counts, graph, endpoint or
+progress facts, or an audit verdict. Only verified mode runs the probe, and only through
+`fvs-probe-inventory.mjs run`, which invokes the resolved probe-aeneas by absolute path under an
+FVS-generated sandbox (no network; writes limited to the project's build directories, the
+output directory and a private tmp; every tool home and bin directory denied).
+
 ## Step 1: Check CODEMAP
 
+Verified mode only; exploratory mode does not require CODEMAP.
+
 ```bash
 [ -f .formalising/CODEMAP.md ] && echo "CODEMAP found" || echo "CODEMAP missing"
 ```
@@ -51,26 +121,22 @@ HALT. fc-plan refreshes an existing managed block; it does not create CODEMAP.
 
 ## Step 2: Refresh deterministic graph and progress facts
 
-Run a fresh probe from the current project root. Accurate public API data is optional: request it
-when `cargo-public-api` exists, but retry the core extract without it if that path fails.
+Verified mode only. Run a fresh confined `probe-aeneas extract` for the project resolved in
+Step 0. Accurate public API data is optional: request it when `cargo-public-api` exists, but retry
+the core extract without it if that path fails.
 
 ```bash
-PROJECT_ROOT=$(pwd -P)
+# Verified mode only.
 PROBE_TMP=$(mktemp -d "${TMPDIR:-/tmp}/fvs-probe-inventory.XXXXXX") || exit 1
 RAW_PROBE_JSON="$PROBE_TMP/extract.json"
-INVENTORY_SCRIPT=~/.claude/scripts/fvs-probe-inventory.mjs
 TARGET_ARGS=()
 PUBLIC_API_ARGS=()
 [ -n "$ARGUMENTS" ] && TARGET_ARGS=(--target "$ARGUMENTS")
-
-command -v probe-aeneas >/dev/null 2>&1 || {
-  echo "probe-aeneas >= 0.19.0 is required. Install or upgrade it, then retry."
-  exit 1
-}
+PROBE_RUN=(node "$INVENTORY_SCRIPT" run --project-root "$PROJECT_ROOT" --output "$RAW_PROBE_JSON")
+PROBE_FAILED='confined probe-aeneas extract failed; fix the reported error and retry.'
 if command -v cargo-public-api >/dev/null 2>&1; then
   PROBE_LOG="$PROBE_TMP/public-api.log"
-  if probe-aeneas extract "$PROJECT_ROOT" --with-public-api \
-      --output "$RAW_PROBE_JSON" >"$PROBE_LOG" 2>&1; then
+  if "${PROBE_RUN[@]}" --with-public-api >"$PROBE_LOG" 2>&1; then
     cat "$PROBE_LOG"
     if grep -Fq 'cargo-public-api found' "$PROBE_LOG"; then
       PUBLIC_API_ARGS=(--public-api-exact)
@@ -80,16 +146,10 @@ if command -v cargo-public-api >/dev/null 2>&1; then
   else
     cat "$PROBE_LOG"
     echo "Public API extraction unavailable; retrying the core inventory without it."
-    probe-aeneas extract "$PROJECT_ROOT" --output "$RAW_PROBE_JSON" || {
-      echo "probe-aeneas extract failed; fix the reported extraction error and retry."
-      exit 1
-    }
+    "${PROBE_RUN[@]}" || { echo "$PROBE_FAILED"; rm -rf -- "$PROBE_TMP"; exit 1; }
   fi
 else
-  probe-aeneas extract "$PROJECT_ROOT" --output "$RAW_PROBE_JSON" || {
-    echo "probe-aeneas extract failed; fix the reported extraction error and retry."
-    exit 1
-  }
+  "${PROBE_RUN[@]}" || { echo "$PROBE_FAILED"; rm -rf -- "$PROBE_TMP"; exit 1; }
 fi
 CANONICAL_INVENTORY=$(node "$INVENTORY_SCRIPT" "$RAW_PROBE_JSON" \
   --project-root "$PROJECT_ROOT" "${TARGET_ARGS[@]}" "${PUBLIC_API_ARGS[@]}" --format json) || {
@@ -116,6 +176,28 @@ For a target, `inScopeDependencies` contains selected dependencies and
 `outsideTargetDependencies` retains project dependencies outside the selection. This prevents a
 false entry point.
 
+## Exploratory route (continue without graph)
+
+Exploratory mode only. Do not run the probe or touch CODEMAP's managed block. Give the agents
+CODEMAP's qualitative notes (if CODEMAP exists) with the generated block removed, so stale counts
+are never presented as current:
+
+```bash
+# fvs:exploratory-codemap
+CODEMAP_NOTES=
+if [ -f .formalising/CODEMAP.md ]; then
+  CODEMAP_NOTES=$(sed '/<!-- fvs:probe-inventory:start -->/,/<!-- fvs:probe-inventory:end -->/d' .formalising/CODEMAP.md)
+fi
+```
+
+Dispatch the same agents with the same models. The researcher (`Research mode: plan
+(exploratory)`) reads the target or the files the user names and returns qualitative complexity,
+risk and approach notes keyed by Lean or Rust name. It states no membership, counts, edges,
+endpoints, statuses, progress, readiness or order. The executor writes only
+`.formalising/PLAN-exploratory.md`, headed `Exploratory plan: no verified probe graph`. This route
+leaves `.formalising/CODEMAP.md` and `.formalising/PLAN.md` unchanged and reports
+`FVS >> PLAN (EXPLORATORY)`.
+
 ## Step 3: Resolve models + effort and inline references
 
 Read the complete config and the canonical contract in `model-profiles.md`. Declare `research` for
@@ -279,7 +361,10 @@ Target selected: {function_name}
 </process>
 
 <success_criteria>
-- [ ] CODEMAP.md exists and its managed block is refreshed from a fresh probe extract
+- [ ] The read-only resolver classifies the probe before any prompt, write, or dispatch
+- [ ] Non-verified status offers setup / continue without graph / cancel; noninteractive runs need explicit opt-ins
+- [ ] Exploratory runs strip CODEMAP's generated block and write only PLAN-exploratory.md
+- [ ] CODEMAP.md exists and its managed block is refreshed from a fresh confined probe extract
 - [ ] Optional public API extraction falls back without blocking the core inventory
 - [ ] Target filtering retains project-wide endpoint truth and outside-target dependencies
 - [ ] Both agents receive the same canonical inventory used to refresh CODEMAP

package/commands/fvs/map-code.md

@@ -8,6 +8,7 @@ allowed-tools:
   - Glob
   - Grep
   - Write
+  - AskUserQuestion
   - Task
 ---
 
@@ -18,7 +19,8 @@ Analyze an Aeneas-generated Lean project to produce `.formalising/CODEMAP.md`.
 A two-phase subagent pipeline adds qualitative annotations without changing those facts.
 
 Output: .formalising/CODEMAP.md with a generated function graph/progress block and separate
-complexity, risk, and recommendation notes.
+complexity, risk, and recommendation notes. Without a verified probe the user may continue without
+a graph; that exploratory run writes only `.formalising/CODEMAP-exploratory.md`.
 </objective>
 
 <execution_context>
@@ -38,6 +40,73 @@ This command can run anytime to refresh the codebase map.
 
 <process>
 
+## Step 0: Choose verified or exploratory mode
+
+Set `PROJECT_ROOT` to `$ARGUMENTS` when supplied, otherwise leave it unset for the current
+directory.
+
+This is the first operational decision. Run it before path prompts, model selection,
+`.formalising/` writes, cache or build work, and any agent dispatch. The resolver is read-only:
+it compares the project's generated `translation.json`, its Aeneas pin in `lake-manifest.json`
+and `aeneas-config.yml`, and `lean-toolchain` with the tested tuples shipped in
+`fvs-probe-inventory.mjs`, then checks the probe-aeneas executable and the preinstalled helpers
+(probe-rust, probe-lean, scip, rust-analyzer). It reports `verified`, `missing`, `incompatible`,
+`unknown` (missing or conflicting provenance) or `unsupported-platform`, and never installs
+anything.
+
+```bash
+# fvs:probe-mode
+PROJECT_ROOT=$(cd "${PROJECT_ROOT:-$PWD}" && pwd -P) || exit 1
+INVENTORY_SCRIPT=~/.claude/scripts/fvs-probe-inventory.mjs
+PROBE_STATUS=$(node "$INVENTORY_SCRIPT" resolve --project-root "$PROJECT_ROOT" --format status) || exit 1
+node "$INVENTORY_SCRIPT" resolve --project-root "$PROJECT_ROOT" --format text
+FVS_MODE=
+if [ "$PROBE_STATUS" = verified ]; then FVS_MODE=verified; fi
+```
+
+`verified` continues without a prompt. For any other status in an interactive session, ask
+(AskUserQuestion; on Codex or Pi a plain-text question, then wait) with exactly these choices
+before doing anything else:
+
+- **Set up the verified probe.** When `resolve --format json` reports `install.available`, show
+  `node "$INVENTORY_SCRIPT" install --project-root "$PROJECT_ROOT" --manifest` (official URL,
+  pinned SHA-256, FVS-owned versioned destination, no PATH or shell-profile change) and ask
+  Install / Show manual instructions / Cancel. Install runs
+  `node "$INVENTORY_SCRIPT" install --project-root "$PROJECT_ROOT" --consent interactive`; then
+  rerun this step and continue verified only if it now reports `verified`. Missing or
+  incompatible helpers get the printed manual steps only: FVS never installs a helper. After
+  showing manual steps, stop so the user can rerun.
+- **Continue without graph.** Set `FVS_MODE=exploratory`.
+- **Cancel.** Stop now. Nothing has been written.
+
+A noninteractive run never prompts and never infers consent. Installing needs
+`FVS_PROBE_INSTALL_POLICY=install`; continuing without a graph needs the separate opt-in
+`FVS_ALLOW_EXPLORATORY=1`:
+
+```bash
+# fvs:probe-mode-noninteractive
+if [ -z "$FVS_MODE" ] && [ "${FVS_PROBE_INSTALL_POLICY:-}" = install ]; then
+  if node "$INVENTORY_SCRIPT" install --project-root "$PROJECT_ROOT" --consent policy; then
+    PROBE_STATUS=$(node "$INVENTORY_SCRIPT" resolve --project-root "$PROJECT_ROOT" --format status)
+    if [ "$PROBE_STATUS" = verified ]; then FVS_MODE=verified; fi
+  fi
+fi
+if [ -z "$FVS_MODE" ]; then
+  if [ "${FVS_ALLOW_EXPLORATORY:-}" = 1 ]; then
+    FVS_MODE=exploratory
+  else
+    echo "FVS >> probe-aeneas is $PROBE_STATUS for this project; set FVS_ALLOW_EXPLORATORY=1 to continue without a graph" >&2
+    exit 1
+  fi
+fi
+```
+
+Exploratory mode never writes the managed CODEMAP block, canonical counts, graph, endpoint or
+progress facts, or an audit verdict. Only verified mode runs the probe, and only through
+`fvs-probe-inventory.mjs run`, which invokes the resolved probe-aeneas by absolute path under an
+FVS-generated sandbox (no network; writes limited to the project's build directories, the
+output directory and a private tmp; every tool home and bin directory denied).
+
 ## Step 1: Detect project
 
 Check for an Aeneas project. Look for config first, then auto-detect:
@@ -107,24 +176,20 @@ fail before dispatch with exact remediation.
 
 ## Step 4: Generate the canonical function inventory
 
-Resolve `$PROJECT_ROOT` to the confirmed absolute project root. Require `probe-aeneas` on PATH,
-create a private temporary directory, and run a fresh extract:
+Verified mode only; exploratory mode skips to the exploratory route below. `$PROJECT_ROOT` is the
+absolute root resolved in Step 0 (rerun Step 0 if the user pointed at a different root in Step 1).
+Run a fresh confined `probe-aeneas extract` into a private temporary directory:
 
 ```bash
-PROJECT_ROOT=$(cd "$PROJECT_ROOT" && pwd -P)
+# Verified mode only.
 PROBE_TMP=$(mktemp -d "${TMPDIR:-/tmp}/fvs-probe-inventory.XXXXXX") || exit 1
 RAW_PROBE_JSON="$PROBE_TMP/extract.json"
-INVENTORY_SCRIPT=~/.claude/scripts/fvs-probe-inventory.mjs
 PUBLIC_API_ARGS=()
-
-command -v probe-aeneas >/dev/null 2>&1 || {
-  echo "probe-aeneas >= 0.19.0 is required. Install or upgrade it, then retry."
-  exit 1
-}
+PROBE_RUN=(node "$INVENTORY_SCRIPT" run --project-root "$PROJECT_ROOT" --output "$RAW_PROBE_JSON")
+PROBE_FAILED='confined probe-aeneas extract failed; fix the reported error and retry.'
 if command -v cargo-public-api >/dev/null 2>&1; then
   PROBE_LOG="$PROBE_TMP/public-api.log"
-  if probe-aeneas extract "$PROJECT_ROOT" --with-public-api \
-      --output "$RAW_PROBE_JSON" >"$PROBE_LOG" 2>&1; then
+  if "${PROBE_RUN[@]}" --with-public-api >"$PROBE_LOG" 2>&1; then
     cat "$PROBE_LOG"
     if grep -Fq 'cargo-public-api found' "$PROBE_LOG"; then
       PUBLIC_API_ARGS=(--public-api-exact)
@@ -134,16 +199,10 @@ if command -v cargo-public-api >/dev/null 2>&1; then
   else
     cat "$PROBE_LOG"
     echo "Public API extraction unavailable; retrying the core inventory without it."
-    probe-aeneas extract "$PROJECT_ROOT" --output "$RAW_PROBE_JSON" || {
-      echo "probe-aeneas extract failed; fix the reported extraction error and retry."
-      exit 1
-    }
+    "${PROBE_RUN[@]}" || { echo "$PROBE_FAILED"; rm -rf -- "$PROBE_TMP"; exit 1; }
   fi
 else
-  probe-aeneas extract "$PROJECT_ROOT" --output "$RAW_PROBE_JSON" || {
-    echo "probe-aeneas extract failed; fix the reported extraction error and retry."
-    exit 1
-  }
+  "${PROBE_RUN[@]}" || { echo "$PROBE_FAILED"; rm -rf -- "$PROBE_TMP"; exit 1; }
 fi
 CANONICAL_INVENTORY=$(node "$INVENTORY_SCRIPT" "$RAW_PROBE_JSON" \
   --project-root "$PROJECT_ROOT" "${PUBLIC_API_ARGS[@]}" --format json) || exit 1
@@ -158,7 +217,7 @@ definition of a function in scope is exactly:
 
 `language=rust && kind=exec && is-relevant=true && untracked=false`
 
-If the tool is missing, old, malformed, fails, or produces an empty inventory, HALT. Never fall
+If the confined run is refused, fails, or produces malformed or empty output, HALT. Never fall
 back to grep or model enumeration.
 
 The helper derives direct `dependents`, `topLevelFunctions`, `entryPointFunctions`, and both
@@ -311,8 +370,21 @@ rm -rf -- "$PROBE_TMP"
 
 If this fails, HALT: CODEMAP is not current and must not be used for planning.
 
+## Exploratory route (continue without graph)
+
+Skip Step 4 and the post-write check. Dispatch the same two agents with the same models, but give
+the researcher `Research mode: map-code (exploratory)` with the source paths and no canonical
+inventory, and tell both agents that no verified function list exists: they describe files,
+modules and types qualitatively, keyed by file path, and state no function count, membership,
+dependency edges, endpoint sets, progress or public-API facts. The executor writes only
+`.formalising/CODEMAP-exploratory.md`, headed `Exploratory map: no verified probe graph`. This
+route never creates or modifies `.formalising/CODEMAP.md` or its managed block.
+
 ## Step 8: Display summary with FVS >> banner
 
+In exploratory mode show `FVS >> MAP (EXPLORATORY)`, `Functions: not counted (no verified probe
+graph)` and `Written: .formalising/CODEMAP-exploratory.md` instead of the verified summary.
+
 ```
 FVS >> MAP COMPLETE
 
@@ -335,6 +407,9 @@ Written: .formalising/CODEMAP.md
 </process>
 
 <success_criteria>
+- [ ] The read-only resolver classifies the probe before any prompt, write, or dispatch
+- [ ] Non-verified status offers setup / continue without graph / cancel; noninteractive runs need explicit opt-ins
+- [ ] Verified extraction runs only through the confined `run` path, never a PATH lookup
 - [ ] Project detected via lakefile.toml + lean-toolchain (or fvs-config.json)
 - [ ] .formalising/ directory created
 - [ ] Model profile resolved from .formalising/fvs-config.json (or quality default)

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

@@ -69,8 +69,8 @@ SYNC_META="$HOME/.claude/fv-skills/upstream/aeneas/_sync-meta.json"
 if [ ! -s "$SYNC_META" ]; then
   echo "FVS >> AENEAS SYNC METADATA MISSING"
   echo "The installed fv-skills/upstream/aeneas/_sync-meta.json mapping is absent."
-  echo "Run /fvs:update, or run: npx fv-skills-baif@latest"
-  echo "Choose your current runtime in the normal installer flow; there is no separate Aeneas option."
+  echo "Run /fvs:update to refresh this installation."
+  echo "There is no separate Aeneas install option."
   exit 1
 fi
 
@@ -82,7 +82,7 @@ node -e '
       m.extraction_inputs.some(x => !x.repository || !x.upstream_path || !x.snapshot_target) ||
       !m.tactic_renames || typeof m.tactic_renames !== "object") process.exit(2);
 ' "$SYNC_META" || {
-  echo "FVS >> Aeneas sync metadata is invalid. Run /fvs:update or npx fv-skills-baif@latest."
+  echo "FVS >> Aeneas sync metadata is invalid. Run /fvs:update to refresh this installation."
   exit 1
 }
 ```