docs(solverforge): update site for 0.8.2 release

Author: blackopsrepl

content/en/blog/releases/solverforge-0-8-2.md

@@ -0,0 +1,48 @@
+---
+title: 'SolverForge 0.8.2: Retained Runtime Refinement'
+date: 2026-04-11
+draft: false
+description: >
+  SolverForge 0.8.2 is now available with more responsive retained-runtime
+  controls, list-variable solution trait bounds, and pause lifecycle fixes.
+---
+
+SolverForge **0.8.2** is now available.
+
+This release tightens the retained-runtime surface introduced in `0.8.0` and
+rounds out a few gaps for production applications:
+
+- **Interruptible retained phases** so built-in search work responds faster to
+  `pause()`, `cancel()`, and config termination
+- **List-variable solution trait bounds** via
+  `#[planning_list_variable(solution_trait = "...")]` when routing helpers or
+  meters need extra solution-side contracts
+- **Serialized pause lifecycle publication** so `PauseRequested` remains
+  authoritative before later pause-state events
+- **Pause-resume construction fixes** so interrupted placements are retried
+  correctly after a retained pause
+
+## Why this release matters
+
+If you are building a service, UI, or embedded runtime around `SolverManager`,
+`0.8.2` makes the retained lifecycle more predictable under real interactive
+control. Pause and cancellation settle faster, pause-state events stay ordered,
+and list-heavy domains have a cleaner way to express extra trait requirements
+without local macro forks.
+
+## Upgrade notes
+
+- Keep using the retained job lifecycle from `SolverManager`; the public model
+  is still job, snapshot, and checkpoint based.
+- Prefer `#[planning_solution(config = "...")]` when a solve should decorate
+  the loaded `solver.toml` rather than replace it.
+- For list-heavy models with custom meters or helpers, add
+  `solution_trait = "path::Trait"` only when generated stock helpers need an
+  explicit extra solution-side bound.
+- The current crate line targets Rust `1.92+`.
+
+## What's next
+
+The next documentation pass will keep tightening the public API guides around
+retained lifecycle orchestration, list-heavy planning models, and scaffold
+extension workflows.

content/en/docs/getting-started/employee-scheduling-rust.md

@@ -5,14 +5,14 @@ icon: fa-brands fa-rust
 date: 2026-04-05
 weight: 5
 description:
-  "Build an employee scheduler with the current SolverForge 0.7.1 runtime
+  "Build an employee scheduler with the current SolverForge 0.8.2 runtime
   surface"
 categories: [Quickstarts]
 tags: [quickstart, rust]
 ---
 
 {{% pageinfo color="primary" %}} This guide is written against the current
-**SolverForge 0.7.1** runtime surface: generated constraint-stream accessors,
+**SolverForge 0.8.2** runtime surface: generated constraint-stream accessors,
 `solver.toml`, and `SolverEvent`-based solving through `SolverManager`.
 {{% /pageinfo %}}
 
@@ -287,6 +287,10 @@ For list-heavy models, nearby search is expressed by picking a nearby selector
 variant such as `nearby_list_change_move_selector` or
 `nearby_list_swap_move_selector`.
 
+When runtime policy needs per-problem tweaks, use
+`#[planning_solution(config = "...")]` to decorate the loaded `solver.toml`
+config instead of replacing it outright.
+
 ## Useful Generated Surface
 
 The macros generate several helpers that are worth leaning on:
@@ -306,6 +310,8 @@ That generated surface is the main reason the current docs prefer
   on standard variables
 - Use `#[planning_list_variable(element_collection = "visits")]` plus `Vec<usize>`
   for stock list variables
+- Add `config = "..."` on `#[planning_solution]` when a solve should layer
+  per-solution runtime policy on top of `solver.toml`
 - Use `.join(equal(...))` for self-joins and `.join((extractor, equal_bi(...)))`
   for cross-joins
 - Use `.named("...")`, not `as_constraint`

content/en/docs/overview.md

@@ -152,13 +152,14 @@ constraints.
 # Project Status & Roadmap
 
 {{% pageinfo %}} SolverForge is a **production-ready constraint solver** written
-in Rust. This documentation set is aligned with **SolverForge 0.7.1**. {{% /pageinfo %}}
+in Rust. This documentation set is aligned with **SolverForge 0.8.2** and the
+current crate line targets **Rust 1.92+**. {{% /pageinfo %}}
 
 ## Current Status
 
 | Component     | Status              | Description                                                      |
 | ------------- | ------------------- | ---------------------------------------------------------------- |
-| **Rust Core** | ✅ Production-ready | Native Rust constraint solver with the current `0.7.1` runtime surface |
+| **Rust Core** | ✅ Production-ready | Native Rust constraint solver with the current `0.8.2` runtime surface |
 
 **Want to try it today?**
 
@@ -196,7 +197,21 @@ SolverForge Rust is **feature-complete** as a production constraint solver:
   `SolverStatus`, exact in-process pause/resume checkpoints, retained
   snapshots, snapshot-bound analysis, and terminal-job deletion
 - **Configuration**: stock `solver.toml` loading plus
-  `SolverConfig::load()`, `from_toml_str()`, and `from_yaml_str()`
+  `SolverConfig::load()`, `from_toml_str()`, `from_yaml_str()`, and
+  `#[planning_solution(config = "...")]` overlays that decorate the loaded
+  runtime config
+
+## Latest Runtime Additions in 0.8.2
+
+- **Prompt retained-runtime controls**: built-in search phases now poll pause,
+  cancel, and config termination state during large neighborhood work so
+  interactive controls settle promptly without app-side watchdogs
+- **List-variable solution trait bounds**: `#[planning_list_variable]` can now
+  declare `solution_trait = "path::Trait"` when meters or helpers require extra
+  solution-side API
+- **Serialized pause lifecycle publication**: the retained event stream keeps
+  `PauseRequested` authoritative and ordered before later worker-side
+  pause-state events
 
 ## Roadmap
 
@@ -316,7 +331,7 @@ optimized native code.
 </details>
 
 <details>
-<summary><strong>What's implemented (0.7.1)</strong></summary>
+<summary><strong>What's implemented (0.8.2)</strong></summary>
 
 **Repository**:
 [solverforge/solverforge](https://github.com/solverforge/solverforge)

content/en/docs/solverforge/_index.md

@@ -4,7 +4,7 @@ linkTitle: 'SolverForge'
 icon: fa-brands fa-rust
 weight: 10
 description: >
-  Native Rust constraint solver — aligned with the 0.7.1 runtime surface.
+  Native Rust constraint solver — aligned with the 0.8.2 runtime surface.
 ---
 
 SolverForge is a native Rust constraint solver for planning and scheduling
@@ -27,6 +27,8 @@ cd my-scheduler
 solverforge server
 ```
 
+The current `0.8.2` crate line targets Rust `1.92+`.
+
 ## Minimal Example
 
 ```rust

content/en/docs/solverforge/modeling/list-variables.md

@@ -58,7 +58,24 @@ pub struct VehicleRoutePlan {
 ```
 
 The list variable stores visit indices, not `Visit` structs directly. This keeps
-move generation and list manipulation aligned with the stock `0.7.1` runtime.
+move generation and list manipulation aligned with the stock `0.8.2` runtime.
+
+## Solution-Side Trait Bounds
+
+Some list-variable helpers, distance meters, or route utilities need more from
+the planning solution than the base `PlanningSolution` contract. In `0.8.2`,
+`#[planning_list_variable]` can express that directly:
+
+```rust
+#[planning_list_variable(
+    element_collection = "visits",
+    solution_trait = "crate::routing::RouteContext"
+)]
+pub visits: Vec<usize>,
+```
+
+Use `solution_trait` only when stock list-variable helpers must see an explicit
+extra trait on the solution type.
 
 ## Shadow Updates
 

content/en/docs/solverforge/modeling/planning-entities.md

@@ -69,6 +69,14 @@ this is represented as `Vec<usize>` plus an `element_collection` name.
 pub visits: Vec<usize>,
 ```
 
+Common parameters:
+
+- `element_collection = "visits"`: names the solution collection that contains
+  all list elements
+- `solution_trait = "path::Trait"`: adds an explicit solution-side trait bound
+  for generated stock list-variable helpers when meters or route utilities need
+  richer solution context
+
 ### `#[planning_pin]`
 
 Prevents the solver from changing an entity's variables. Useful for pre-assigned or locked entities.

content/en/docs/solverforge/solver/configuration.md

@@ -15,7 +15,7 @@ helpers for TOML and YAML when you want to inspect or build configs directly.
 ### From a TOML file
 
 ```rust
-let config = SolverConfig::load("solver-config.toml").unwrap();
+let config = SolverConfig::load("solver.toml").unwrap();
 ```
 
 ### From a TOML string
@@ -170,6 +170,30 @@ let config = SolverConfig::new()
     .with_termination_seconds(30);
 ```
 
+## Per-Solution Overlays
+
+Macro-generated retained solves can layer runtime policy on top of the loaded
+`solver.toml` by using `config = "..."` on `#[planning_solution]`:
+
+```rust
+#[planning_solution(
+    constraints = "define_constraints",
+    config = "solver_config_for_solution"
+)]
+pub struct Schedule {
+    #[planning_score]
+    pub score: Option<HardSoftScore>,
+    pub time_limit_secs: u64,
+}
+
+fn solver_config_for_solution(solution: &Schedule, config: SolverConfig) -> SolverConfig {
+    config.with_termination_seconds(solution.time_limit_secs)
+}
+```
+
+The callback receives the already loaded `solver.toml` config, so it should
+decorate that base config rather than replace it from scratch.
+
 ## See Also
 
 - [Phases](../phases/) — Phase types and configuration

content/en/docs/solverforge/solver/solver-manager.md

@@ -150,6 +150,11 @@ MANAGER.cancel(job_id).expect("cancel should be accepted");
 retains a checkpoint-backed snapshot, emits `Paused`, and only then allows
 `resume()`.
 
+In `0.8.2`, the built-in construction, local-search, and retained phase flow
+poll control state during large neighborhood work more aggressively, so
+`pause()`, `cancel()`, and config termination unwind promptly without extra
+watchdog code in the application.
+
 ## Snapshots and Analysis
 
 Every retained solution snapshot has a monotonic `snapshot_revision` within its
@@ -175,6 +180,10 @@ println!("analysis score: {:?}", analysis.analysis.score);
 
 Analysis is snapshot-bound. You do not analyze the live mutable job directly.
 
+After `pause()` is accepted, `PauseRequested` is published before any later
+worker-side event already carrying `PauseRequested` state. Treat that ordering
+as authoritative when synchronizing UI or service-layer state.
+
 ## Delete and Slot Reuse
 
 Jobs remain retained after `Completed`, `Cancelled`, or `Failed` so you can read