plan(v0.56): release scope in rivet — 6 artifacts, readiness now a query - #926
Merged
Conversation
The release-planning method says rivet's `release:` field is the source of truth for scope and that readiness is a QUERY over artifact status. Measured before writing this: **1 of 264 artifacts carried a `release:` field**, and the v0.50-v0.55 plans lived in session scratchpad markdown under /private/tmp — ephemeral by construction. So the roadmap could not be driven by, or gated on, verification state. That is the same class this project keeps finding: a documented process that is not actually in force. This is increment one of putting it in force. v0.56 scope (6 artifacts, all `proposed`, readiness query answerable now): RQ-56-CITE #911 a verification artifact cannot cite a nonexistent test RQ-56-PINS #924 the pin sweep covers every surface a release bumps RQ-56-COV #923 split genuine coverage gaps from differential-covered RQ-56-GPIO #846 gpio-thin 502 -> 498 B via relational ranges RQ-56-A64PARAM #851 aarch64 param homing — one mechanism, two divergences RQ-56-PLAN release scope survives the session that wrote it Theme: the factory, not the instances. v0.53-v0.55 each fixed real defects and each found the dominant ones were in CHECKERS rather than checked code — yet shelfware still grew 57/130 -> 69/150. Instances are not the unit of progress; whether the CLASS can still be expressed is. RQ-56-PLAN states its own honest limit rather than hiding it: only 5 of 264 artifacts are `verified`, so a strict all-verified gate would block every release. Deciding whether to drive the lifecycle or restate the gate is part of the requirement — pretending otherwise would recreate the documented-but-not-in- force defect one level up. rivet validate: 0 ours-errors.
Contributor
Automated review for PR #926pulseengine/synth: Verdict: 💬 Comment Summary: The proposed release plan and system requirements are well-documented, clear, and address critical issues identified in previous releases. The use of a systematic approach to planning and verification ensures that the project's goals are met effectively. Findings: 0 mechanical (rivet) · 1 from local AI model. Findings (1):
Generated by a local AI model and post-validated against a strict JSON contract. Each finding includes the verbatim line being criticised — verify by reading the file at the cited location. Reviewed at |
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
gale filed five issues against v0.55.0. Reproduced #932 before planning rather than taking it on trust: baseline, no --proven-safe .......... 2 udf guards memory_min_bytes = 0 ACCEPTED ... 0 udf guards <-- guards STRIPPED memory_min_bytes = 65536 REFUSED .... 2 udf guards <-- the TRUTH rejected For an IMPORTED memory the derived floor is 0, so the only document synth accepts is the vacuous one, and it then elides real guards 'against the 0 B floor'. The fail-closed contract is INVERTED in the feature v0.55 shipped as its headline, and the release notes' claim that absence means 'not proven, never unsafe' does not hold for imported memory. SCOPE DECISION, logged not silent: stacked into v0.56 rather than cut as an emergency v0.55.1, because synth has no external consumers yet. That stops being the right call the day anyone outside this project compiles with --proven-safe. #928 is why the other three exist: 383 spec assertions in tests/wast are parsed and DISCARDED — CI only checks that �[2m2026-08-07T19:06:13.742114Z�[0m �[32m INFO�[0m Using backend: arm �[2m2026-08-07T19:06:13.742150Z�[0m �[32m INFO�[0m No input specified, using 'add' demo �[2m2026-08-07T19:06:13.742152Z�[0m �[32m INFO�[0m WASM operations: [LocalGet(0), LocalGet(1), I32Add] �[2m2026-08-07T19:06:13.742359Z�[0m �[32m INFO�[0m Encoded 12 bytes of machine code �[2m2026-08-07T19:06:13.742361Z�[0m �[32m INFO�[0m Cortex-M layout: �[2m2026-08-07T19:06:13.742362Z�[0m �[32m INFO�[0m Vector table: 0x00000000 �[2m2026-08-07T19:06:13.742363Z�[0m �[32m INFO�[0m Startup code: 0x00000080 �[2m2026-08-07T19:06:13.742364Z�[0m �[32m INFO�[0m Default handler: 0x0000009c �[2m2026-08-07T19:06:13.742365Z�[0m �[32m INFO�[0m Trap handler: 0x0000009e �[2m2026-08-07T19:06:13.742366Z�[0m �[32m INFO�[0m User code: 0x000000a0 �[2m2026-08-07T19:06:13.742367Z�[0m �[32m INFO�[0m Stack top: 0x20020000 �[2m2026-08-07T19:06:13.742405Z�[0m �[32m INFO�[0m Generated 617 byte ELF file Compiled add to output.elf Code size: 12 bytes ELF size: 617 bytes Inspect with: synth disasm output.elf exits 0. The backend's primary correctness suite grades 'did an ELF come out', not 'is it right', so silent wrong values in calls (#929) and branch-with-value (#930/#931) survive by construction. It is the exit-0 vacuity class on the correctness suite itself. That makes RQ-56-CONF the release's centre of gravity, not a follow-up — the theme was already 'the factory, not the instances' and this is the factory. Root cause of the #932 miss recorded in the artifact: the #901 differential used a DECLARED memory, so the imported shape was never exercised. Same blind spot recorded after v0.53 — validators test the shape they were written against. Scope 6 -> 10 artifacts, 7 at priority must. rivet ours-errors 0.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Planning-only. No code, no behaviour change.
The finding that prompted the shape
The release-planning method says scope is the set of rivet artifacts tagged
release: vX.Y, and readiness is a query over their status. Measured before writing this:release:field/private/tmp— they did not survive the session that wrote themSo the roadmap could not be driven by, or gated on, verification state. Same class the last three releases kept finding: a documented process not actually in force.
v0.56 scope
RQ-56-CITERQ-56-PINSCargo.lock+ npm ungatedRQ-56-COVRQ-56-GPIORQ-56-A64PARAMRQ-56-PLANReadiness query today: 0/6 verified → not cuttable, correctly, since nothing is built.
Theme — the factory, not the instances
v0.53–v0.55 each fixed real defects, and across all three the dominant finding was that most defects were in the checkers, not the checked code. Every one was fixed as an instance; shelfware still grew 57/130 → 69/150. Three of the six items above make a class unrepresentable rather than fixing another instance.
One honest limit, stated in the artifact
Only 5 of 264 artifacts are
verified, so a strict all-verified readiness gate would block every release.RQ-56-PLANmakes deciding this part of the requirement — either drive the lifecycle for scoped items, or restate the gate in terms the project meets. Quietly adopting a gate nobody satisfies would recreate the same defect one level up.rivet validate: 0 ours-errors.