v0.5 post-ship sweep (2026-05-20)

[avrabe]

Automated post-ship verification for v0.5.0, run 2026-05-20 per the release-note callout ("The 2026-05-20 verification routine includes a deeper Mythos sweep that will revisit"). Steps follow the v0.5 post-ship checklist.

---

Step 1 — v0.5.0 shipped ✅

Tag v0.5.0 exists and the GitHub release is published (2026-04-29T20:43:49Z). Four binaries uploaded (aarch64-apple-darwin, aarch64-unknown-linux-gnu, x86_64-apple-darwin, x86_64-unknown-linux-gnu). Release closed #103, #118, and partial #94 as advertised.

Note: the repo has since advanced three minor releases + one patch (current latest: v0.8.1). All downstream steps are assessed against the current main.

---

Step 2 — Post-release CI on main ✅

Latest main commit: 17b76df (PR #171, merged 2026-05-20T04:14:48Z). All 14 check runs green:

Job	Result
Format	✅ success
Clippy	✅ success
Test	✅ success
Coverage	✅ success
Bench compile-only	✅ success
Fuzz smoke × 4	✅ success (all four targets)
Mythos delta-pass gate	✅ success (no Tier-5 changes in PR #171)
LS-N verification gate	✅ success
Mythos auto-runner	⏭ skipped (CI-only change; no Tier-5 paths touched)

No regressions. No action needed.

---

Step 3 — Stale branches ⚠️ (owner decision needed)

Active branches (skip):

• feat/141-stream-pair-foundation → open PR feat(p3): cross-component stream<T> pairing detection (#141, ADR-3) #173
• bot/config-update-1777161165595 → open PR [temper] Configuration update #110 (bot namespace, do not touch)

Candidates for deletion (no open PR; not in an active worktree):

Branch	Status
fix/component-wrap-option-drops	PRs #155 and #158 both closed without merge from this branch; fix landed via separate PR #159 from fix/wrap-lift-string-encoding. Branch is abandoned.
ci/update-wit-bindgen-fixtures	No open or merged PR found. Appears to be in-progress work or a forgotten WIP.
feat/explore-I-opaque-rep	No PR found. Likely exploratory WIP.
feat/issue-92-shim-module	No PR found. Likely WIP.
feat/per-component-handle-tables	No PR found. Likely WIP.

fix/component-wrap-option-drops is the only clear stale-and-safe-to-delete candidate. The others may be in-progress work; owner should confirm before deletion.

---

Step 4 — Issues closed by v0.5 ✅

All three issues cited in the v0.5.0 release notes were verified:

Issue	Title	State
#103	Add criterion benchmarks for fusion pipeline	✅ Closed 2026-04-29 (completed)
#118	Parser slice OOB on truncated component-section input	✅ Closed 2026-04-29 (completed)
#94	P3 async lowering: stream/future/async exports	🔵 Open (umbrella; partial close expected, remaining sub-issues tracked via #141, #142)

No manual closures needed.

---

Step 5 — Mythos delta pass for v0.5.1 prep ⚠️ ACTION NEEDED

Scope: Tier-5 + tier-4 files changed between v0.4.0 and v0.5.0.

git diff --name-only v0.4.0..v0.5.0 -- meld-core/src/parser.rs ...
→ meld-core/src/parser.rs  (only tier-5 file changed)

The v0.5.0 pre-release Mythos pass (recorded in the release notes) found no confirmed findings and carried forward one unverified hypothesis:

Sibling reader.range() storage sites in parse_core_module of the same class as LS-P-5; surface narrowed by the outer module bounds check at parser.rs:820.

Current state: The hypothesis sites are unchanged since v0.5.0. Specifically, parse_core_module still contains:

// parser.rs:1279
module.element_section_range = Some((reader.range().start, reader.range().end));

// parser.rs:1287
module.data_section_range = Some((reader.range().start, reader.range().end));

These store ranges derived from reader.range() inside parse_core_module. The LS-P-5 fix applied checked_section_slice to the outer unchecked_range (line ~826) before handing module_bytes to parse_core_module; whether the inner reader.range() values can exceed module_bytes boundaries has not been verified with a PoC + Kani harness.

Required action: Run a fresh Mythos discover.md session scoped to meld-core/src/parser.rs, specifically targeting the parse_core_module reader.range() sites (lines 1279, 1287) plus any other section-range stores added since v0.4.0. Per pipeline convention, a confirmed finding requires a failing PoC test + Kani harness before promotion to an approved LS-N entry. No fix should ship without oracle confirmation.

# Fresh session prompt:
Read scripts/mythos/discover.md and apply it to meld-core/src/parser.rs,
focusing on reader.range() calls inside parse_core_module (lines 1279, 1287)
as a potential LS-P-5 sibling. Do not relax the oracle requirement.

---

Step 6 — Summary

Step	Outcome
1. v0.5.0 shipped	✅ Released 2026-04-29, binaries uploaded
2. Post-release CI	✅ All checks green on current main (commit 17b76df)
3. Stale branches	⚠️ 5 candidates identified; fix/component-wrap-option-drops is clear stale; others need owner review
4. Issue auto-close	✅ #103 and #118 closed; #94 correctly remains open
5. Mythos delta pass	⚠️ Unverified hypothesis from v0.5.0 release notes is still open; fresh discover.md session needed on parser.rs

No CI regressions to fix. No missed issue closures. One Mythos hypothesis to resolve before the next release that touches parser.rs.

[avrabe]

Step 5 — Mythos delta pass: resolved (NO FINDINGS)

Ran the discover protocol on the flagged parse_core_module
reader.range() sites (parser.rs:1279 element, :1287 data) as a
potential LS-P-5 sibling.

Verdict: NO FINDINGS.

The hypothesis was that element_section_range / data_section_range
could be stored with an out-of-bounds (start, end), then panic the
unchecked module.bytes[start..end] slices in
parse_element_segments / parse_data_segments (segments.rs:198,
:258).

It cannot. Payload::ModuleSection — the LS-P-5 site — is yielded
eagerly with an explicitly unchecked range before the nested
module is parsed. A core-module element/data section is different: it
is framed only once wasmparser's parse_all has its full declared
content. A truncated section (size LEB claiming more bytes than
remain) makes parse_all yield an Err, which parse_core_module's
payload? propagates — the *_section_range field is never set. The
downstream slice is defended by construction.

Oracle: PR #178 adds truncated_core_section_errors_rather_than_yielding_oob_range,
which feeds truncated element- and data-section inputs and asserts
wasmparser rejects each with an Err rather than yielding a section
reader with an OOB range. It doubles as a standing regression guard —
if a future wasmparser bump changes the framing behaviour, the test
fails and this hypothesis reopens.

No LS-N entry (NO FINDINGS). No production code change.

Step 5 is the last open item on this sweep — all six steps now
resolved. This issue can be closed once #178 merges.