feat(scaffold): target SolverForge 0.25.1

AGENTS.md

@@ -9,7 +9,7 @@
 Current scaffold policy:
 - current CLI package version is `3.9.0`
 - minimum supported Rust version is `1.95`, matching the current SolverForge runtime crates
-- generated projects currently target `solverforge 0.25.0`; the default web shell additionally targets `solverforge-ui 0.9.1` and `solverforge-maps 2.3.3`; the MCP shell additionally targets `rmcp 3.9.0`
+- generated projects currently target `solverforge 0.25.1`; the default web shell additionally targets `solverforge-ui 0.9.1` and `solverforge-maps 2.3.3`; the MCP shell additionally targets `rmcp 3.9.0`
 - `solverforge new <name>` is the only public scaffold path and produces a neutral app shell
 - `--shell web|api|cli|mcp` is the current public shell selector; `web` is the default, `api` omits frontend assets, `cli` omits Axum/SSE routes and frontend assets, and `mcp` delivers the solver as an MCP server over stdio and stateless Streamable HTTP
 - API/CLI/MCP app specs omit `ui_source`, and subsequent CLI mutations must preserve that absence
@@ -80,7 +80,7 @@ Current end-to-end scenario policy:
 - the scalar-only runtime scenario covers full compact telemetry, bounded candidate detail, and qualified trace provenance
 - the MCP scenario models a mixed scalar-plus-list problem, generates the sample data, and drives both stdio and stateless Streamable HTTP through the real `rmcp` client: annotated tool surface, task-backed solve to a terminal snapshot with scalar assignment and complete list placement, retained lifecycle via a legacy client, and byte-level stdio stdout purity during a solve, all with parallel evaluation enabled on a pinned Rayon pool
 
-SolverForge `0.25.0` uses list variables as the sequence and route model. The
+SolverForge `0.25.1` uses list variables as the sequence and route model. The
 generated-app runtime and browser scenarios must continue to start and observe
 a real mixed scalar/list solve.
 

README.md

@@ -16,7 +16,7 @@ Required Rust version: `1.95` or later.
 
 New projects currently target these crate versions:
 
-- `solverforge 0.25.0`
+- `solverforge 0.25.1`
 - `solverforge-ui 0.9.1` for the default web shell
 - `solverforge-maps 2.3.3` for the default web shell
 - `rmcp 3.9.0` for the MCP shell
@@ -199,7 +199,7 @@ Core commands:
 - `generate score` and `generate solution --score` accept `HardSoftScore`,
   `HardSoftDecimalScore`, `HardMediumSoftScore`, and `SoftScore`.
   `BendableScore` is rejected because `#[planning_solution]` requires a
-  `ParseableScore`, which SolverForge `0.25.0` does not implement for it.
+  `ParseableScore`, which SolverForge `0.25.1` does not implement for it.
 - `solverforge generate scalar-group|conflict-repair` wires opt-in model
   resources by exact ID.
 - `solverforge destroy fact|entity|variable|constraint|solution|scalar-group|conflict-repair`
@@ -327,7 +327,7 @@ including applied/not-doable/rejected moves, hard-score direction counts,
 construction counters, one record per started phase (`phases`, in execution
 order), per-selector and per-move breakdowns, and the bounded applied-move
 trace. The six `conflictRepair*` counters are run-level totals; selector
-records do not carry them because SolverForge `0.25.0` `SelectorTelemetry`
+records do not carry them because SolverForge `0.25.1` `SelectorTelemetry`
 has no such fields. These fields are carried consistently by status,
 snapshot, and typed SSE payloads. Constraint analysis reports each
 constraint's `name`, `weightMultiplier` (the bound constraint weight, a
@@ -460,7 +460,7 @@ Current scenario coverage:
   byte-level stdio check that the transport channel stays pure JSON-RPC; every
   MCP phase runs with parallel evaluation enabled
 
-SolverForge `0.25.0` supports mixed scalar/list construction, canonical mixed
+SolverForge `0.25.1` supports mixed scalar/list construction, canonical mixed
 local-search defaults, and list-based sequence modeling. The CLI suite proves
 the mixed path in both runtime and browser pipelines; the scalar-only scenario keeps the deeper
 pause/resume, analysis, reconnect, and qualified-trace checks.

UPSTREAM_FEATURE_AUDIT.md

@@ -5,7 +5,7 @@ Audit date: 2026-11-09
 This audit compares the current `solverforge-cli` scaffold surface against the
 live SolverForge upstream checkout at `/srv/lab/dev/solverforge/solverforge`
 and the crates.io release state. Generated projects now target the published
-SolverForge `0.25.0` release. Registry-only generated-app validation is the
+SolverForge `0.25.1` release. Registry-only generated-app validation is the
 release gate; `SF_USE_LOCAL_PATCHES=1` remains reserved for explicit future
 prerelease checks against sibling checkouts.
 
@@ -15,13 +15,13 @@ without turning the neutral scaffold into a domain-specific demo.
 
 ## Source Evidence
 
-- Published gate: `cargo info solverforge@0.25.0` resolves the published crate
+- Published gate: `cargo info solverforge@0.25.1` resolves the published crate
   on 2026-11-09, with Rust `1.95` and the `serde`, `console`, and
   `verbose-logging` features; `verbose-logging` is
   `[console, solverforge-console/verbose-logging]`, so the web, API, and CLI
   shells keep all three and the MCP shell enables only `serde`.
 - Upstream local checkout: the workspace and inter-crate dependency baseline is
-  `0.25.0`, with `v0.25.0` (`3115b4dd`) at the checked-out release commit. The `0.19.0`
+  `0.25.1`, with `v0.25.1` (`6069763d`) at the checked-out release commit. The `0.19.0`
   release made list variables the sole sequence and route model; the published
   `0.19.1` through `0.19.7` patch line carries the subsequent solver fixes.
 - Upstream `0.19.7..0.22.0` release surface: `0.19.8` through `0.19.14` are
@@ -179,6 +179,11 @@ without turning the neutral scaffold into a domain-specific demo.
 - Upstream macro docs: `crates/solverforge-macros/WIREFRAME.md` documents
   `scalar_groups = "path"` on `#[planning_solution]` and scalar hook arguments
   on `#[planning_variable]`.
+- Upstream `0.25.0..0.25.1` release surface: the nearby list change and swap
+  cursors keep the nearest destinations in one bounded buffer per cursor, and
+  the zero-regression gate runs both sides from equal-length paths and grades
+  cache and branch behaviour on Cachegrind's simulation. No public API or
+  configuration changes; generated apps pick it up through the version pin.
 - Upstream `0.24.0..0.25.0` release surface (source-carrying, breaking):
   configuration semantics made literal and validated, partitioned search run by
   the framework, the `auto` parallel-evaluation policy, and construction and
@@ -212,7 +217,7 @@ without turning the neutral scaffold into a domain-specific demo.
   `scalar_groups`, `ScalarGroup::assignment`, grouped scalar construction with
   `group_name`, `construction_obligation = "assign_when_candidate_exists"`, and
   `grouped_scalar_move_selector`.
-- CLI coverage today: the scaffold targets `solverforge 0.25.0`, exposes the
+- CLI coverage today: the scaffold targets `solverforge 0.25.1`, exposes the
   `web`, `api`, `cli`, and `mcp` shells, and includes the retained
   `SolverManager` lifecycle, typed SSE, snapshots, analysis,
   pause/resume/cancel/delete, generated `solverforge.app.toml`, scalar/list
@@ -336,7 +341,7 @@ without turning the neutral scaffold into a domain-specific demo.
 
 ## Recommended Follow-Up Implementation Slice
 
-The current starter-safe 0.25.0 surface is implemented, apart from the
+The current starter-safe 0.25.1 surface is implemented, apart from the
 unknown-key `solver.toml` validation gap recorded in the matrix. The next high-value slice
 is domain-specific documentation and executable examples, not more neutral
 scaffold defaults.
@@ -353,16 +358,16 @@ scaffold defaults.
 
 ## Implementation Status
 
-- Release state: `solverforge 0.25.0` is published on crates.io and matches
+- Release state: `solverforge 0.25.1` is published on crates.io and matches
   the live upstream release checkout and this generated target. The
-  `0.19.8..0.25.0` line is source-carrying (grouped-scalar search/perf work,
+  `0.19.8..0.25.1` line is source-carrying (grouped-scalar search/perf work,
   the `0.20.3` search-order hooks, the `0.21.0` scoring `group_by` joins, the
   `0.21.2` selector-subgraph edge rebase fix, the `0.21.3` precedence route
   delta fix, the `0.22.0` grouped-stream accumulator-kernel rework, the
   `0.23.0` parallel local-search evaluation, the `0.24.0` constraint weights
   and API cleanup, the `0.25.0` configuration audit, framework partitioned
-  search and `auto` evaluation policy), and the published crate, the `v0.25.0`
-  tag, and this
+  search and `auto` evaluation policy, and the `0.25.1` bounded nearby list
+  candidate buffer), and the published crate, the `v0.25.1` tag, and this
   generated target are the same code. Registry-only validation is therefore authoritative.
   `SF_USE_LOCAL_PATCHES=1` is only for an explicit future coordinated prerelease
   check. The audit uses the current `scalar_groups` / `ScalarGroup::assignment`
@@ -462,7 +467,7 @@ scaffold defaults.
   help says: unary is `for_each` + `filter` + `penalize` for both hardness
   levels, reward is `for_each` + `filter` + `reward`, and pair filters out
   unassigned entities before a `joiner::equal` self-join (each unordered pair
-  once; `0.25.0` has no `for_each_unique_pair`) and selects conflicts with a
+  once; `0.25.1` has no `for_each_unique_pair`) and selects conflicts with a
   filter.
 - Changed: the neutral `solver.toml` declares no `[[phases]]` and defers to the
   runtime's model-aware default pipeline; its explicit phases remain as a
@@ -492,7 +497,7 @@ Any implementation from this audit should pass:
 - focused parser/generator/app-spec tests for the new metadata;
 - scaffold contract tests proving fresh generated projects include only the
   opt-in scalar-group surface requested by the user;
-- generated app `cargo check` against the published `0.25.0` registry target;
+- generated app `cargo check` against the published `0.25.1` registry target;
 - runtime pipeline coverage only if the new command claims actual solving
   behavior;
 - `SF_USE_LOCAL_PATCHES=1` only for an explicit future sibling-checkout

WIREFRAME.md

@@ -21,7 +21,7 @@ Required Rust version: `1.95` or later.
 
 Current generated projects target:
 
-- `solverforge 0.25.0`
+- `solverforge 0.25.1`
 - `solverforge-ui 0.9.1` for the web shell
 - `solverforge-maps 2.3.3` for the web shell
 - `rmcp 3.9.0` for the MCP shell
@@ -279,7 +279,7 @@ Generated apps should behave like production references:
   snapshot revision
 - status, snapshot, and SSE payloads expose every compact SolverForge telemetry
   aggregate and phase/selector/move/applied-move breakdown; the six
-  `conflictRepair*` counters are run-level only, because SolverForge `0.25.0`
+  `conflictRepair*` counters are run-level only, because SolverForge `0.25.1`
   `SelectorTelemetry` does not carry them
 - constraint analysis carries `name`, `weightMultiplier` (the bound constraint
   weight), `score`, and `matchCount` per constraint
@@ -333,7 +333,7 @@ warning, not an error, so the user can define it afterward.
 `generate score` and `generate solution --score` accept `HardSoftScore`,
 `HardSoftDecimalScore`, `HardMediumSoftScore`, and `SoftScore`.
 `BendableScore` is rejected: `#[planning_solution]` requires a
-`ParseableScore`, and SolverForge `0.25.0` does not implement it for
+`ParseableScore`, and SolverForge `0.25.1` does not implement it for
 `BendableScore`. Score rewrites change only the bare type name inside `use`
 items.
 
@@ -348,7 +348,7 @@ functions that panic with the function name and the
 - `--reward`: `for_each` + `filter(reward_condition)` + `reward`
 - `--pair`: `for_each` + `filter` (variable assigned) + `join(joiner::equal(key))`
   self-join, which yields each unordered pair once, + `filter(pair_condition)`
-  + `penalize`; SolverForge `0.25.0` has no `for_each_unique_pair`
+  + `penalize`; SolverForge `0.25.1` has no `for_each_unique_pair`
 
 Weight helpers return the unit penalty or reward. A solve that reaches a
 placeholder fails: the job ends `FAILED` and the panic names the file and
@@ -446,7 +446,7 @@ Current scenario policy:
   legacy client, and byte-level stdio stdout purity during a solve, all with
   parallel evaluation enabled
 
-SolverForge `0.25.0` uses list variables for ordered sequences and routes. Both
+SolverForge `0.25.1` uses list variables for ordered sequences and routes. Both
 generated-app end-to-end suites start and observe the real mixed scalar/list
 path.
 

skills/solverforge-modeling/SKILL.md

@@ -25,7 +25,7 @@ required source/collector rules for the grouped patterns.
   `solverforge --version`, `solverforge new --help`,
   `solverforge generate variable --help`.
 
-This skill describes CLI `3.9.0` (scaffold runtime target `solverforge 0.25.0`,
+This skill describes CLI `3.9.0` (scaffold runtime target `solverforge 0.25.1`,
 UI `solverforge-ui 0.9.1`, maps `solverforge-maps 2.3.3`, MCP `rmcp 3.9.0`).
 Re-derive specifics from the CLI if the version differs.
 
@@ -221,7 +221,7 @@ from a hand-written extractor.
 The common skeletons are `--unary` = `for_each` + `filter` + `penalize` (hard
 or soft), `--reward` = `for_each` + `filter` + `reward`, and `--pair` =
 `for_each` + `filter` (variable assigned) + `joiner::equal` self-join +
-`filter` + `penalize`. SolverForge `0.25.0` has no `for_each_unique_pair`;
+`filter` + `penalize`. SolverForge `0.25.1` has no `for_each_unique_pair`;
 the self-join already yields each unordered pair once.
 
 `#[planning_solution]` generates a public associated accessor for each

skills/solverforge-modeling/references/constraint-patterns.md

@@ -182,7 +182,7 @@ fn pair_weight(_left: &Task, _right: &Task) -> HardSoftScore {
 }
 ```
 
-SolverForge `0.25.0` has no `for_each_unique_pair`; this self-join is the pair
+SolverForge `0.25.1` has no `for_each_unique_pair`; this self-join is the pair
 pattern. A self-join visits each unordered pair **exactly once** and never
 pairs an entity with itself, so one match is one violation. Do not add a self-pair guard
 and do not halve the weight. Keep the assigned filter before the join: an

skills/solverforge-modeling/references/gotchas.md

@@ -153,7 +153,7 @@ construction phase covers the group.
 
 - `SoftScore` has no hard level: only `--soft` constraints are allowed.
 - `generate score <Type>` must name a supported type, or the CLI rejects it.
-  `BendableScore<N, M>` is rejected: SolverForge `0.25.0` has no
+  `BendableScore<N, M>` is rejected: SolverForge `0.25.1` has no
   `ParseableScore` for it, which `#[planning_solution]` requires.
 
 ## `solverforge.app.toml` is a projection, not an input

skills/solverforge-modeling/references/verification.md

@@ -23,7 +23,7 @@ cargo check
 Catches wrong field names, missing imports, wrong score types, and closure
 signature mismatches. It will **not** catch the runtime localizing-source panic
 (that is a runtime assertion, not a compile error). The generated scaffolds
-target `solverforge 0.25.0`; the first build downloads and compiles the runtime
+target `solverforge 0.25.1`; the first build downloads and compiles the runtime
 and web dependencies, which can take a few minutes. `SF_USE_LOCAL_PATCHES=1`
 exists in the CLI's own test harness for prerelease targets — do not set it for
 ordinary app builds.

src/scaffold_target.rs

@@ -1,13 +1,13 @@
-pub const RUNTIME_CRATE_VERSION: &str = "0.25.0";
+pub const RUNTIME_CRATE_VERSION: &str = "0.25.1";
 pub const UI_CRATE_VERSION: &str = "0.9.1";
 pub const MAPS_CRATE_VERSION: &str = "2.3.3";
 pub const MCP_CRATE_VERSION: &str = "3.9.0";
 
-pub const RUNTIME_TARGET_LABEL: &str = "solverforge 0.25.0";
+pub const RUNTIME_TARGET_LABEL: &str = "solverforge 0.25.1";
 pub const UI_TARGET_LABEL: &str = "solverforge-ui 0.9.1";
 pub const MAPS_TARGET_LABEL: &str = "solverforge-maps 2.3.3";
-pub const RUNTIME_TARGET_DISPLAY: &str = "SolverForge crate target 0.25.0";
-pub const RUNTIME_SOURCE_PATH: &str = "crates.io: solverforge 0.25.0";
+pub const RUNTIME_TARGET_DISPLAY: &str = "SolverForge crate target 0.25.1";
+pub const RUNTIME_SOURCE_PATH: &str = "crates.io: solverforge 0.25.1";
 pub const UI_SOURCE_PATH: &str = "crates.io: solverforge-ui 0.9.1";
 pub const MAPS_SOURCE_PATH: &str = "crates.io: solverforge-maps 2.3.3";
 pub const MCP_SOURCE_PATH: &str = "crates.io: rmcp 3.9.0";
@@ -18,12 +18,12 @@ pub const LONG_VERSION_TEXT: &str = concat!(
     env!("CARGO_PKG_VERSION"),
     "\nCLI version: ",
     env!("CARGO_PKG_VERSION"),
-    "\nScaffold runtime target: SolverForge crate target 0.25.0",
+    "\nScaffold runtime target: SolverForge crate target 0.25.1",
     "\nScaffold UI target: solverforge-ui 0.9.1",
     "\nScaffold maps target: solverforge-maps 2.3.3",
     "\nScaffold MCP target: rmcp 3.9.0",
     "\nRuntime source: ",
-    "crates.io: solverforge 0.25.0",
+    "crates.io: solverforge 0.25.1",
     "\nUI source: ",
     "crates.io: solverforge-ui 0.9.1",
     "\nMaps source: ",