solverforge-ui 0.5.1

Frontend component library for SolverForge constraint-optimization applications
Documentation 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

# AGENTS

Repository guidance for coding agents and maintainers working in
`solverforge-ui`.

## Scope

- `README.md` is the source of truth for shipped public API and runtime
  contracts.
- `WIREFRAME.md` can include shipped and planned UI, but every section must
  clearly distinguish which is which.
- `js-src/` and `css-src/` are the editable sources. `static/sf/` contains the
  generated bundled assets served to consumers.

## Current Release

- Crate version: `0.5.1`.
- Versioned asset outputs are emitted as `static/sf/sf.<version>.css` and
  `static/sf/sf.<version>.js`.

## Solver Lifecycle Contract

- Startup streams may begin with either a scored `progress` event or a scored
  `best_solution` event.
- `progress` is metadata-only and must not carry the solution payload.
- `best_solution` must include both `solution` and `snapshotRevision`.
- If a backend seeds startup state from a retained snapshot, it must not emit an
  identical duplicate startup `best_solution` immediately after that bootstrap.
- Paused and terminal lifecycle events remain authoritative; `SF.createSolver()`
  synchronizes retained snapshot state before invoking the corresponding
  callbacks.

## Working Rules

- Keep public API changes synchronized across code, `README.md`, runnable demos,
  and tests in the same change.
- Do not document planned or exploratory wireframe ideas as shipped behavior
  until they are wired into the generated assets and the README API reference.
- Prefer `make lint-frontend` for focused JavaScript linting, `make
  test-frontend` or `make test-browser` for focused frontend validation, and
  `make test-quick` or `make test` before release work.