Problem
The body of the published v0.3.3 GitHub release still describes the
2026-07-31 validation build:
- size:
2,852,241 bytes
- SHA-256:
8FB9CD29EC79CE5B9489A55F7BCAC321393E7B4426CE63BD84A0B9E5D29955DD
The JAR currently attached to that release was uploaded on 2026-08-25 and
GitHub reports:
- size:
2,854,635 bytes
- SHA-256:
84422c6751fd05574b5e3cdfd20bc64c2a5fd7a6d74be28b0d2d8ccd0df8d043
The repository documentation now records this distinction in
docs/release-integrity.md, but the existing release body itself must be
edited through GitHub's release UI/API.
Required correction
- remove or replace the stale size/checksum in the
v0.3.3 release body;
- state explicitly that the July checksum belongs to the validation build, not
the currently attached binary;
- use GitHub's reported digest for the currently attached JAR;
- keep the historical validation report intact.
Future releases are protected by the tag-driven release workflow added in #9.
Problem
The body of the published
v0.3.3GitHub release still describes the2026-07-31 validation build:
2,852,241bytes8FB9CD29EC79CE5B9489A55F7BCAC321393E7B4426CE63BD84A0B9E5D29955DDThe JAR currently attached to that release was uploaded on 2026-08-25 and
GitHub reports:
2,854,635bytes84422c6751fd05574b5e3cdfd20bc64c2a5fd7a6d74be28b0d2d8ccd0df8d043The repository documentation now records this distinction in
docs/release-integrity.md, but the existing release body itself must beedited through GitHub's release UI/API.
Required correction
v0.3.3release body;the currently attached binary;
Future releases are protected by the tag-driven release workflow added in #9.