fix(parser,adapter,resolver): canonical-ABI correctness sweep — flat_byte_size + LS-P-6/-7/-8/-9/-10/-11/-12/-13/-14/-15/-16/-17/-18/-19

[avrabe]

Summary

Five parser.rs canonical-ABI correctness fixes — all surfaced by the mythos-auto delta-pass scanning parser.rs. The auto-runner did its job: across successive scans it found four real, confirmed memory-safety / ABI-correctness bugs (LS-P-6 through LS-P-9) plus one hygiene issue.

Fix 1 — flat_byte_size element-wise variant JOIN (hygiene)

flat_byte_size computed result<T,E> / variant payload width as max(flat_byte_size(arm)) instead of the Component Model element-wise flatten_variant JOIN. Rewritten over a new flat_width_list helper. Disposition: OOB-write impact claim rejected on validation — flat_byte_size has no in-tree consumers. Hygiene fix, no LS-N entry.

Fix 2 — LS-P-6: area-size accumulators wrapped (confirmed)

params_area_byte_size / return_area_byte_size used a bare += against canonical_abi_size_unpadded which saturates to u32::MAX (LS-P-4) — once the accumulator saturated, the next field's += overflowed (debug panic, release wrap to ~3), under-sizing the params buffer and yielding an OOB write in cabi_realloc. Both sites are now saturating_add.

Fix 3 — LS-P-7: conditional-pointer CopyLayout computed for composite, not leaf (confirmed)

collect_conditional_pointers / collect_conditional_result_pointers computed CopyLayout once on the whole payload type. copy_layout only special-cases bare string/list; any composite payload fell to _ => Bulk { byte_multiplier: 1 }. A list<u64> leaf inside option<tuple<u32, list<u64>>> was tagged Bulk { 1 } instead of Bulk { 8 } — a 7/8 under-copy [H-4.1]; pointer-containing Elements leaves collapsed to flat Bulk, dropping inner pointer fixup [H-4.2]. New collect_pointer_positions_with_layout / collect_pointer_byte_offsets_with_layout carry each leaf's own layout.

Fix 4 — LS-P-8: record/tuple field-walk added unpadded child size (confirmed)

The Component Model spec lays out a record/tuple as s = 0; for f in fields: s = align_to(s, alignment(f)); s += size(f) where size(f) for an aggregate field is its full padded size. ~25 field-walk sites — Record/Tuple arms of canonical_abi_size_unpadded, collect_pointer_byte_offsets, the LS-P-7 _with_layout helpers, collect_conditional_result_pointers, collect_return_area_type_slots, collect_resource_byte_positions, element_inner_pointers, element_inner_resources, plus the top-level walks in params_area_byte_size, return_area_byte_size, pointer_pair_*_offsets/slots, resource_*_positions, and conditional_pointer_pair_result_positions — advanced offset/size by canonical_abi_size_unpadded(field) (no trailing pad) instead of canonical_abi_element_size(field). The per-field align_up doesn't re-absorb the preceding pad when the next field has smaller alignment.

Concretely tuple<record{u32,u8}, u8> now computes element_size = 12 (spec) instead of 8; a list<u32> following record{u32,u8} now sits at offset 8 instead of 5. The wrong offsets flowed into FACT adapter pointer-pair loads, list-copy byte lengths, and inner pointer-fixup walks.

Mythos process note: the auto-runner mis-located this finding as the option/variant/result payload contribution (which is actually spec-correct — those arms already use canonical_abi_element_size). Independent clean-room verification corrected the location to the Record/Tuple field accumulation.

Fix 5 — LS-P-9: total_flat_params used Iterator::sum::<u32>() instead of saturating fold (confirmed)

The canonical-ABI calling convention is picked from total_flat_params: <= MAX_FLAT_PARAMS (16) → flat; > → params-ptr. flat_count for a FixedSizeList is saturating (LS-P-4), so a nested FixedSizeList can yield flat_count = u32::MAX. A bare .sum() then panics in debug on u32::MAX + 1 and wraps to a small value in release; the wrapped total compares <= 16 and the adapter selects the flat convention for a function that genuinely needs params-ptr — call-site lowering and callee-side lifting disagree on the ABI slot. The sibling area-size accumulators already use saturating_add per LS-P-6; this calling-convention picker was missed. Replaces .sum() with .fold(0u32, u32::saturating_add).

Tests

• flat_byte_size_result_uses_element_wise_join_not_max
• ls_p_6_area_byte_size_saturates_across_fields
• ls_p_7_conditional_pointer_layout_is_per_leaf_not_per_composite
• ls_p_8_record_tuple_field_accumulation_uses_padded_field_size
• ls_p_9_total_flat_params_saturates_across_params
• Full meld-core lib suite green: 253 tests, 0 failures
• LS-N verification gate: 23/23 (LS-P-6, LS-P-7, LS-P-8, LS-P-9 all detected with matching tests)

🤖 Generated with Claude Code

[github-actions]

Mythos delta-pass required

This PR modifies one or more Tier-5 source files (per
scripts/mythos/rank.md):

meld-core/src/adapter/fact.rs
meld-core/src/parser.rs
meld-core/src/resolver.rs

Before merge, run the Mythos discover protocol on the
modified Tier-5 files:

1. Follow scripts/mythos/discover.md
   — one fresh agent session per touched Tier-5 file.
2. For each finding, the agent must produce both a Kani
   harness and a failing PoC test (per the protocol's
   "if you cannot produce both, do not report" rule).
3. Attach a comment on this PR with either the findings
   (formatted per discover.md's output schema) or
   NO FINDINGS.
4. Add the mythos-pass-done label to this PR.

Why this gate exists: LS-A-10
(CABI alignment padding in async-lift retptr writeback) was
found by the v0.8.0 pre-release Mythos pass — but it had
lived in the callback emitter since #128, across six
releases. A PR-time gate would have caught it at review
time instead of at the release boundary.

The gate check on this PR will pass once the label is
applied.

[github-actions]

LS-N verification gate

✅ 33/33 approved LS entries verified

	count
Passed (≥1 test, all green)	33
Failed (≥1 test failure)	0
Missing (no ls_*_NN_* test found)	0

_{Approved loss-scenarios.yaml entries are expected to have a
regression test named ls_<letter>_<num>_* (e.g. LS-A-11 →
ls_a_11_*). The gate runs each prefix via cargo test --lib --no-fail-fast and aggregates pass/fail/missing.}

Failed LS entries

(none)

Missing regression tests

(none)

_{Updated automatically by tools/post_verification_comment.py.
Source of truth: safety/stpa/loss-scenarios.yaml.}

[github-actions]

Mythos delta-pass (auto)

❌ 3 finding(s) across 3 Tier-5 file(s)

File	Verdict	Hypothesis
meld-core/src/adapter/fact.rs	❌ FINDING	The FixedSizeList arm of cabi_size_align computes total inline size as es * n with a plain u32 multiply. In release mode this silently wraps when es * n exceeds u32::MAX. emit_ptr_pair_result_writeback calls cabi_size_align on the FixedSizeList inner elem when the function's result type is list<FixedSizeList(T, N)>, receiving the wrapped small value as elem_size. It then uses that value as the byte multiplier (byte_count = list_len * elem_size), allocating and memory.copy-ing a tiny fraction of the callee's actual data. The fused caller receives severely truncated list elements with no trap; composed execution sees the full data. Silent semantic drift.
meld-core/src/parser.rs	❌ FINDING	copy_layout calls panic! instead of returning an error when its list element type contains a pointer-bearing conditional (option/result/variant with string/list payload), causing process abort for valid Component Model types such as list<option<string>>.
meld-core/src/resolver.rs	❌ FINDING	The last-resort fallback (lines 1346–1355) unconditionally picks the lowest-type-id [resource-rep] entry when a component has two distinct resources and only one has a canonical mapping, silently assigning resource X's rep function to a call site that holds a resource Y handle — causing the adapter to call the wrong resource table at runtime.

_{Auto-run via anthropics/claude-code-action@v1
(SHA-pinned) on the touched Tier-5 files, using the
maintainer's Max-plan OAuth token. See
.github/workflows/mythos-auto.yml and
scripts/mythos/discover.md.}

[avrabe]

mythos-auto finding #3 — reviewed (plausibly real, pre-existing, tracked separately)

The auto-runner's third scan of parser.rs flagged a new FINDING — collect_conditional_pointers assigning the wrong CopyLayout. Validated per validate.md:

Plausibly real. collect_conditional_pointers (parser.rs:2369) computes the conditional-pointer layout for option<T> / result<T,E> payloads. For each inner pointer position it does copy_layout_for_string_or_list_at(ok_ty) — passing the whole composite payload type, then assigning that one layout to every position from collect_pointer_positions. copy_layout only special-cases bare String / List; a composite (Record/Tuple/FixedSizeList) hits the _ => Bulk{1} fallback. So a list<u32> field inside result<record{ items: list<u32> }, E> gets Bulk{1} instead of Bulk{4} → the adapter copies len * 1 bytes, ¼ of the data → under-copy / truncation (H-4 class). The correct per-field pattern already exists in element_inner_pointers; collect_conditional_pointers uses the whole-composite layout instead.

Not a one-line fix — it needs collect_conditional_pointers restructured to compute the layout per pointer position (per field), not once for the composite. Tracked as a dedicated task for its own validate (PoC + Kani) + LS-N entry + PR.

This is pre-existing and unrelated to #179. #179's changes are flat_byte_size (variant JOIN) and LS-P-6 (area-size saturation) — neither touches collect_conditional_pointers. The auto-runner re-flags it because it scans the whole parser.rs, not the diff.

Process note — whole-file scan treadmill

mythos-auto scans the entire Tier-5 file, so every parser.rs PR is blocked until every latent finding in parser.rs is fixed. Across #178/#179 the auto-runner has surfaced three: flat_byte_size (dead code, not a hazard), LS-P-6 (real OOB, fixed in #179), and now finding #3. Each fix surfaces the next. Worth deciding whether the gate should scan the PR diff rather than the whole file.

#179 status

12 substantive checks green (Test, Clippy, Coverage, Bench, Format, all 4 fuzz, LS-N gate 20/20, Detect Tier-5, Mythos pass). #179 delivers two sound parser.rs canonical-ABI fixes, one a confirmed OOB bug (LS-P-6) with an approved LS-N entry. Ready to merge pending a maintainer call on dispositioning finding #3 as a separate follow-up.

[avrabe]

mythos-auto finding #4 — clean-room verified (real bug, but auto-runner mis-described it)

The latest delta-pass on 0ec063e flagged a 4th FINDING. I ran it through an independent clean-room verification (a fresh agent given only the claims and the source, no access to the auto-runner's reasoning). Result:

The bug is real — but it is NOT where the auto-runner said. The finding claimed the option/variant/result arms of canonical_abi_size_unpadded use canonical_abi_element_size instead of size(). Verification shows those arms are correct — they already use the padded element size for payloads, which is exactly the spec's size().

The actual bug is in the Record and Tuple arms. They accumulate each field as size = align_up(size, field_align); size += canonical_abi_size_unpadded(field) — adding the field's unpadded size. The Component Model canonical ABI specifies s += size(f), where size(f) for an aggregate field includes that field's own trailing alignment padding. When a higher-aligned aggregate field is followed by a lower-aligned field, the omitted trailing pad is not re-absorbed by the next field's align_up, so the following field's offset — and the whole aggregate's size — comes out too small.

Worked example — tuple<record { a: u32, b: u8 }, u8>:

• meld canonical_abi_size_unpadded → 6 (trailing u8 placed at offset 5)
• Component Model spec size() → 12 (trailing u8 at offset 8)

The wrong offsets/sizes propagate to collect_pointer_byte_offsets, params_area_byte_size, return_area_byte_size, and the LS-P-7 _with_layout collectors — every record/tuple field walk that advances a byte offset by the unpadded child size.

Minimal fix: advance by canonical_abi_element_size(field) (padded) rather than canonical_abi_size_unpadded(field) at each record/tuple field-accumulation site (~8 sites). canonical_abi_size_unpadded itself still returns the outer type without its own trailing pad — that contract is unchanged; only the per-field contribution is corrected.

Disposition

• This is pre-existing (present in v0.9.0) and unrelated to fix(parser,adapter,resolver): canonical-ABI correctness sweep — flat_byte_size + LS-P-6/-7/-8/-9/-10/-11/-12/-13/-14/-15/-16/-17/-18/-19 #179's three fixes — the auto-runner re-flags it because mythos-auto scans the whole parser.rs, not the diff.
• It is a multi-site core canonical-ABI layout correction with test fallout — distinctly larger than LS-P-7. It warrants its own validated PR (PoC + LS-N entry), not a rushed 4th commit on fix(parser,adapter,resolver): canonical-ABI correctness sweep — flat_byte_size + LS-P-6/-7/-8/-9/-10/-11/-12/-13/-14/-15/-16/-17/-18/-19 #179.
• fix(parser,adapter,resolver): canonical-ABI correctness sweep — flat_byte_size + LS-P-6/-7/-8/-9/-10/-11/-12/-13/-14/-15/-16/-17/-18/-19 #179 itself is complete and sound: three canonical-ABI fixes (flat_byte_size JOIN, LS-P-6 area-size saturation, LS-P-7 per-leaf CopyLayout), 13/15 checks green — the only two reds are this mythos FINDING and the label-only delta-pass gate.

Process — the whole-file-scan treadmill

This is the 4th finding the whole-file scan has surfaced across #178/#179: flat_byte_size (dead code, not a hazard), LS-P-6 (real, fixed), LS-P-7 (real, fixed), and now finding #4. Each fixed finding exposes the next, because mythos-auto scans the entire Tier-5 file rather than the PR diff. No parser.rs PR can go green through this gate until every latent parser.rs bug is fixed. This needs a maintainer decision — recommend either switching the gate to diff-scan, or dispositioning the pre-existing findings so a PR is judged on its own diff.

[avrabe]

mythos-auto post-LS-P-10 results — 3 new findings across 3 files

The mythos-auto scan after the LS-P-10 commit (8ea01a6) surfaced three more findings — one in each of parser.rs, adapter/fact.rs, and resolver.rs (the three Tier-5 files I touched). Initial code-read verdicts (not yet full clean-room verified):

Finding #7 — adapter/fact.rs line 4366–4370 (likely real, design needed)

&& site.requirements.pointer_pair_positions.iter().any(|_| true)

.iter().any(|_| true) is semantically !is_empty(). The auto-runner is correct that this turns "is there any pointer pair anywhere in this function?" into "this consecutive (i32, i32) slot is a pointer pair," corrupting plain integer args in async adapters. Plausibly real but the right fix is not mechanical — the surrounding code (4338–4344) explicitly says "the resolver's positions are in callee order; the adapter's locals are in caller order; instead of using resolver positions, compute them from the caller's flat param types." Replacing the broken any(|_| true) with any(|&pos| pos == i as u32) would re-introduce the very caller/callee-order disagreement the surrounding code was working around. Needs design — probably walk caller_type component types and identify string/list params directly, rather than guessing from flat (i32, i32) shapes.

Finding #8 — parser.rs::element_inner_pointers _ => {} arm (looks real)

element_inner_pointers (around line 3100, returns Vec<(byte_offset, CopyLayout)> for each pointer leaf within a list/array element type) handles String, List, FixedSizeList, Record, Tuple, Type — and falls to _ => {} for Option / Result / Variant. So list<option<string>>, list<result<string, _>>, and list<variant-with-string> are classified as CopyLayout::Bulk (no inner pointer fixup) instead of CopyLayout::Elements with the inner pointer descriptor. The adapter then does a flat byte copy, leaving callee list elements with stale string pointers into source memory. Same hazard class as LS-R-2 / LS-P-7, on the list-element-of-conditional path. Contained fix (~similar to LS-P-7 in scope).

Finding #9 — resolver.rs same-name export HashMap collision (separate file)

The auto-runner claims: "When two core modules within the same component export a function with the same name, the flat-name resolver's HashMap-based export index silently overwrites the first module's entry with the second (last-writer wins), routing any import of that name to the wrong module with no error or warning." I have not pinned down the exact line yet — resolver.rs uses several HashMaps; needs targeted reading.

#179 status

Five canonical-ABI correctness fixes landed: flat_byte_size hygiene + LS-P-6/-7/-8/-9/-10. 13 substantive CI checks green; only the mythos gate + label gate + a transient fuzz_parse_component sanitizer-musl failure remain red. 252→254 lib tests, LS-N gate 24/24.

Treadmill — decision point

After five real fixes the auto-runner found three more in the same files. Each parser/adapter/resolver PR re-surfaces every latent canonical-ABI bug in those whole files because mythos-auto scans the file, not the diff. We are now 9 confirmed-or-likely findings deep. #179 cannot reach a clean mythos pass through this strategy in any bounded number of commits. The options remain:

1. Switch the mythos-auto gate to diff-scan — a PR is judged on its own changes. fix(parser,adapter,resolver): canonical-ABI correctness sweep — flat_byte_size + LS-P-6/-7/-8/-9/-10/-11/-12/-13/-14/-15/-16/-17/-18/-19 #179 merges; findings ci: add release workflow #7/fix(ci): use macos-14 for x86_64-apple-darwin release build #8/Add Nix flake for reproducible development and build environment #9 (and any remainder) become their own PRs.
2. Disposition + merge fix(parser,adapter,resolver): canonical-ABI correctness sweep — flat_byte_size + LS-P-6/-7/-8/-9/-10/-11/-12/-13/-14/-15/-16/-17/-18/-19 #179 — apply mythos-pass-done (the human-review escape), track the remaining findings as separate work.
3. Keep grinding — fix fix(ci): use macos-14 for x86_64-apple-darwin release build #8 next (easiest), then Add Nix flake for reproducible development and build environment #9, then ci: add release workflow #7's design problem. Best estimate, several more commits before parser/adapter/resolver are fully clean.

I'm stopping the autonomous loop here pending a maintainer call. The five pushed fixes are independently valuable and tested — they're not held by which option you pick.

[avrabe]

mythos-auto post-LS-P-13 — 3 new findings (one false positive)

After LS-P-13 (a6cd2f3) the mythos verdict surfaced three more findings — one in each Tier-5 file again. Quick triage (code-read only; full clean-room verification not done for #10/#12 yet):

Finding #10 — adapter/fact.rs inner nested-list copy missing emit_overflow_guard (plausibly real)

Claim: "the inner nested-list copy loop computes buf_len = callee_len × sub_elem_size via a bare i32.mul with no emit_overflow_guard call; a callee-controlled len that causes 32-bit overflow wraps buf_len to a small value, the subsequent i32.add-based bounds check also wraps and is bypassed, the adapter allocates/copies only the wrapped byte count while the caller's bulk-copied len field retains the original large value — truncated nested list, semantic drift."

fact.rs has many I32Mul sites (~9 by grep). Some are gated on emit_overflow_guard (lines 1553, 1696 — the outer copy paths), some are not (e.g. lines 362, 372, 403 in the inner element-fixup helpers). Plausibly real — needs targeted code-read + clean-room verification.

Finding #11 — parser.rs::canonical_abi_size_unpadded Record/Tuple field accumulation (FALSE POSITIVE)

Claim: "the Record and Tuple cases advance the size accumulator by canonical_abi_element_size(field) — the trailing-padded element stride — instead of canonical_abi_size_unpadded(field) — the raw spec size(t) — inflating computed record sizes…"

The auto-runner has the Component Model spec terminology inverted. From canonical-abi.py:

def record_size(fields):
  s = 0
  for f in fields:
    s = align_to(s, alignment(f.t))
    s += size(f.t)
  return align_to(s, alignment_record(fields))   # <-- final align_to

The spec's size(record) is align_to(running_s, alignment_record) — WITH the trailing pad. In this codebase:

• canonical_abi_size_unpadded(t) = running_s before the final align_to = spec size(t) minus trailing pad.
• canonical_abi_element_size(t) = align_up(canonical_abi_size_unpadded(t), align(t)) = spec size(t).

The per-field accumulator s += size(f.t) should therefore add canonical_abi_element_size(f.t) — exactly what LS-P-8 fixed. The auto-runner's claim that _unpadded is "the raw spec size(t)" directly contradicts the spec. Reverting LS-P-8 would re-introduce a real bug.

The LS-P-8 PoC (ls_p_8_record_tuple_field_accumulation_uses_padded_field_size) pins spec-derived values: element_size(tuple<record{u32,u8}, u8>) == 12, params_area_byte_size([record{u32,u8}, tuple<R_in,u8>]) == 20, list<u32> after record{u32,u8} at offset 8. Those numbers are unambiguous spec outputs.

Disposition: dispute. No fix. Recommend either retraining the auto-runner's spec knowledge on this point, or adding a regression LS-N test the auto-runner can examine.

Finding #12 — resolver.rs::unwrap_or(true) resource-type bounds fallback (plausibly real, low impact)

Claim: "When pos.resource_type_id as usize exceeds component.component_type_defs.len(), the unwrap_or(true) fallback (line 1376) silently classifies the resource as callee-defined, causing wrong [resource-rep] / [resource-new] swap."

The code at 1373-1376:

component.component_type_defs
    .get(pos.resource_type_id as usize)
    .map(|def| !matches!(def, crate::parser::ComponentTypeDef::Import(_)))
    .unwrap_or(true)

Plausibly real — an out-of-bounds resource_type_id (parser bug, stale index, or adversarial input) does fall through to true ("callee-defined"). Reachability and severity need clean-room verification. Likely a defensive hardening like LS-P-11 rather than a memory-safety emergency.

Treadmill state

Nine fixes pushed (flat_byte_size + LS-P-6 through LS-P-13). 14 substantive CI checks green: Test, Clippy, Coverage, Bench, Format, all 4 fuzz, LS-N verification (27/27), Detect Tier-5, all 3 per-file Mythos passes. Two reds remain: the mythos aggregate verdict + the label-only gate. The auto-runner has now produced a demonstrable false positive (#11), which changes the calculus — the gate cannot be cleared by "fix what the auto-runner says" alone if it produces spec-contradicting findings.

I'm stopping the autonomous loop here. The three options stand:

1. Switch the mythos-auto gate to diff-scan — addresses both the whole-file-scan treadmill and reduces false-positive surface area per PR.
2. Disposition + merge fix(parser,adapter,resolver): canonical-ABI correctness sweep — flat_byte_size + LS-P-6/-7/-8/-9/-10/-11/-12/-13/-14/-15/-16/-17/-18/-19 #179 — apply mythos-pass-done (the human-review escape), dispute Rocq proofs for CopyLayout and recursive pointer fixup adapters #11 as wrong, track Add wit-bindgen fixtures for remaining type families #10 and CI: auto-generate wit-bindgen fixtures instead of checking in binaries #12 as separate work.
3. Keep grinding — verify and fix Add wit-bindgen fixtures for remaining type families #10 and CI: auto-generate wit-bindgen fixtures instead of checking in binaries #12 (and any feat(safety): STPA analysis, safety requirements, and 30 new tests #13 the next scan produces), dispute Rocq proofs for CopyLayout and recursive pointer fixup adapters #11.

I lean toward option 2 in the short term plus option 1 as the structural change, but the call is yours.