| Filename | Latest commit message | Latest commit date |
|---|---|---|
|
All checks were successful
standards workspaces build + test / which workspaces this change touches (pull_request) Successful in 6s
standards workspaces build + test / macOS energy backends (pull_request) Has been skipped
repository checks / lockfiles, tests in CI, workflow hygiene, spec and section references, public text (pull_request) Successful in 1m3s
standards workspaces build + test / joulehook-rs (joulehook/joulehook-rs, joulehook-rs, linux) (pull_request) Successful in 1m17s
standards workspaces build + test / mesh-rs (mesh/mesh-rs, -p mesh-engine-gguf -p mesh-openai --features mesh-engine-gguf/gguf,mesh-openai/server, mesh-rs, linux-arm64) (pull_request) Successful in 2m1s
A receipt's weights_digest named the weights that answered, and nothing recorded when a backend's weights changed, from what, or whether the change was planned. Weights could be swapped under a running steward, and every later receipt simply named the new digest. mesh-receipt::change (SPEC §6.5): - A per-backend ChangeLog: a hash-chained sequence of JCR-1 entries (profile tag mesh_change) sealed under the steward key that seals its receipts. Each entry carries backend, recipe, seq, prev and made_at. - A plan entry records, before the changes it covers, the precisions a change may run at, the fidelity floor, the validation every change must pass, what the plan foresees, and an optional risk-assessment digest. - A weights entry records from, to, precision, fidelity, the plan it falls under or none, the digest of its validation result, effective_from (the first receipt-log sequence served on the new weights) and a reason. - Entries are checked as they join, by append when made and by from_sealed when read. The rules: chaining; time order; from must be the weights in effect; the change must change something; effective_from must not go back. A planned change must name an earlier plan entry and stay inside it (recipe, precision, fidelity floor, validation result). A plan therefore covers only what is sealed after it. An unplanned change is recorded as unplanned. - covers(receipt) names the change in effect at the receipt's sequence, matched on backend, recipe, weights and precision. A position orders a change against receipts without trusting a clock. mesh-core: - record_weights swaps an engine in only by recording the change first; plan_changes records a plan; govern holds a restarted steward to its persisted record; change_log exposes the record. - Once a backend has a record, a serve on weights the record does not have in effect (or on none) is refused before any grant or work. A serve whose engine reports other weights, or none, is not sealed. Tests: - mesh-receipt: 7 new. Read-back; tampering; each chaining rule alone; change order; inside-the-plan; plan order; coverage. - mesh-core: 4 new. Unrecorded swap refused before the meter is read; an engine that forgets its weights after serving; a planned change held to its plan with the old weights kept on refusal; restart from the persisted record, including tampered, foreign-key and ahead-of-log records. - Mutation testing: 27 mutants. 26 killed; the 27th is equivalent (a no-op `.or(None)`). Three survived the first round, the backend, seq and prev checks each tested only in combination; the single-rule test was added and kills them. Verified on the build host: mesh-rs 105 tests plus 19 behind features; clippy -D warnings and rustdoc -D warnings clean; the conformance pack is unchanged. Repo checks pass. Co-Authored-By: Claude Opus 5.5 <[email protected]> |
||
| .. | ||
| crates | ||
| Cargo.lock | ||
| Cargo.toml | ||