test(fact): LS-A-8 regression for inner-list rep_func selection by avrabe · Pull Request #169 · pulseengine/meld

avrabe · 2026-05-19T06:39:52Z

Summary

The final missing-bucket entry. Drives the LS-N verification gate to 19/19 verified — full coverage.

PR f0e981b fixed the resource_rep_imports.values().next() HashMap-iteration-order bug in analyze_call_site (inner-list borrow rep_func selection) by threading a pre-resolved rep_import: Option<(String, String)> through InnerResource and looking up per-type. The fix landed without a regression test; the LS-N verification gate has been flagging this since #161.

Why this matters

For list<record { x: borrow<A>, y: borrow<B> }>, the pre-fix code picked the same arbitrary rep_func for both A and B handles. Borrow handles of resource A then routed through resource B's rep_func (silent rep-vs-handle confusion across cross-component handle boundary, H-4 / H-4.2, UCA-A-7). Wasm validator accepts (both [resource-rep]X and [resource-rep]Y are (i32) -> i32); divergence only surfaces at downstream runtime execution.

Test approach

Test	What it pins
`ls_a_8_inner_list_rep_func_selected_by_type_not_iteration_order`	Adversarial 2-resource fixture, sampled 32× across rebuilt HashMaps (fresh hash seed per sample). If any residual iteration-order dependence leaked, at least one sample would pair wrongly; assertion pins the per-type lookup as deterministic.
`ls_a_8_no_rep_import_skips_fixup_rather_than_picking_arbitrary`	Pre-fix `.values().next()` fall-back-on-miss would fabricate a fixup pointing at an arbitrary rep_func when the resolver couldn't map the type id. The post-fix path correctly skips with `log::warn`. This test pins that skip-not-fabricate behaviour.

Gate verdict

State	Before	After
Verified	18/19	19/19
Missing	1 (LS-A-8)	0
Failed	0	0

Advisory missing-bucket is now empty. Every status: approved LS entry has a passing regression test.

Local test run

running 2 tests
..
test result: ok. 2 passed; 0 failed; 0 ignored; ...

Full lib: 237/237 → 239/239.

End-to-end mythos-auto status

This PR touches meld-core/src/adapter/fact.rs (Tier-5) so the auto-runner fires. Same unzip-missing infra block as PR #166 expected (#167). LS-A-9 test itself was admin-merged via #166; same path likely needed here.

🤖 Generated with Claude Code

Final missing-bucket entry. Drives the LS-N verification gate to 19/19 verified — full coverage. For a `list<record { x: borrow<A>, y: borrow<B> }>` (or any list whose elements carry borrows to multiple distinct resource types), `analyze_call_site` walks the inner-resources slot and emits a fixup per slot mapping its byte_offset to the merged-module index of the right `[resource-rep]` import. The pre-fix code did `resource_rep_imports.values().next()` — HashMap iteration order, so the rep_func picked for each slot was effectively random. Borrow handles of resource A then routed through resource B's rep_func and vice versa, producing silent rep-vs-handle confusion across the cross-component handle boundary (H-4 / H-4.2, UCA-A-7). Wasm validator accepts (both `[resource-rep]X` and `[resource-rep]Y` are `(i32) -> i32`); the divergence only surfaces when downstream runtimes execute the fused module against typed callers. Two tests: - `ls_a_8_inner_list_rep_func_selected_by_type_not_iteration_order` Adversarial fixture with two InnerResources at distinct byte_offsets, each pointing at a different rep_import key. Sampled 32× across rebuilt HashMaps (so each sample sees a fresh hash seed). If any residual iteration-order dependence leaked, at least one sample would pair wrongly; the assertion pins the per-type lookup as deterministic. - `ls_a_8_no_rep_import_skips_fixup_rather_than_picking_arbitrary` InnerResource.rep_import = None — the resolver couldn't map the type id to an import. Pre-fix `.values().next()` would fall back to whatever entry the HashMap iterated first, emitting a fixup pointing at the WRONG rep_func. The post-fix path correctly skips the slot (with a `log::warn`) rather than fabricating an arbitrary mapping. Gate verdict: 18/19 → 19/19 verified. The advisory missing-bucket is now empty. 237/237 → 239/239 in `meld-core --lib`. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

github-actions · 2026-05-19T06:40:09Z

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

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

Follow scripts/mythos/discover.md
— one fresh agent session per touched Tier-5 file.
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).
Attach a comment on this PR with either the findings
(formatted per discover.md's output schema) or
NO FINDINGS.
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 · 2026-05-19T11:33:52Z

LS-N verification gate

✅ 19/19 approved LS entries verified

	count
Passed (≥1 test, all green)	19
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.}

After the unzip block on rust-cpu runners cleared (#167), PR #169's mythos-auto matrix scan ran far enough to expose a third plumbing issue: ``` error: Error message: Unable to get ACTIONS_ID_TOKEN_REQUEST_URL env variable at <anonymous> (.../@actions/core/lib/oidc-utils.js:71:27) ... Attempt 3 failed: Could not fetch an OIDC token. Did you remember to add `id-token: write` to your workflow permissions? ``` claude-code-action calls `core.getIDToken()` early in `setupGitHubToken` (entry point: `src/github/token.ts:15`). The OIDC issuer URL is injected as the `ACTIONS_ID_TOKEN_REQUEST_URL` environment variable, but only when the workflow has `permissions.id-token: write`. mythos-auto.yml's permissions block had `contents: read` and `pull-requests: write` but not `id-token: write`. The action retries 3× via its `retryWithBackoff` helper and then aborts before running its prompt. The sticky-comment + label flow then short-circuits and the placeholder-FINDING fallback fires. Adds the permission with an inline comment explaining the requirement. The token is workflow-scoped and signed by GitHub; it does not grant access to anything beyond what the workflow already has. Bundled with the fuzz.yml musl drop on this PR — both are CI workflow plumbing fixes uncovered by the same Tier-5 PR (#169).

avrabe · 2026-05-19T12:36:48Z

Admin-merge per #139 + #170 follow-up

10 of 14 checks green:

Test ✓, Clippy ✓, Coverage ✓, Bench ✓, LS-N gate ✓, Format ✓
Detect Tier-5 ✓ (actor gate works), all 4 fuzz smokes green (3/4 done, 1 still queued but will pass)

The 3 failing checks are all the mythos-auto trio:

Mythos pass (meld-core/src/adapter/fact.rs) — claude-code-action aborts with Could not fetch an OIDC token. Did you remember to add 'id-token: write' to your workflow permissions?
Aggregate findings + label — cascade
Mythos delta-pass gate — cascade (label not applied)

The OIDC permission fix lives in PR #170, which adds id-token: write to mythos-auto.yml. The 3 mythos failures CANNOT pass on this branch because the fix isn't here. Once #170 merges, every subsequent Tier-5 PR will run mythos-auto cleanly end-to-end.

The LS-A-8 regression test itself is sound (239/239 in meld-core --lib, both new tests green locally + on this PR's Test job).

Admin-merge counter for #139:

PR test(fact): LS-A-8 regression for inner-list rep_func selection #169 — admin-merged (this PR, +1)

Drives the LS-N verification gate to 19/19 verified — full coverage. Advisory missing-bucket is now empty.

After the unzip block on rust-cpu runners cleared (#167), PR #169's mythos-auto matrix scan ran far enough to expose a third plumbing issue: ``` error: Error message: Unable to get ACTIONS_ID_TOKEN_REQUEST_URL env variable at <anonymous> (.../@actions/core/lib/oidc-utils.js:71:27) ... Attempt 3 failed: Could not fetch an OIDC token. Did you remember to add `id-token: write` to your workflow permissions? ``` claude-code-action calls `core.getIDToken()` early in `setupGitHubToken` (entry point: `src/github/token.ts:15`). The OIDC issuer URL is injected as the `ACTIONS_ID_TOKEN_REQUEST_URL` environment variable, but only when the workflow has `permissions.id-token: write`. mythos-auto.yml's permissions block had `contents: read` and `pull-requests: write` but not `id-token: write`. The action retries 3× via its `retryWithBackoff` helper and then aborts before running its prompt. The sticky-comment + label flow then short-circuits and the placeholder-FINDING fallback fires. Adds the permission with an inline comment explaining the requirement. The token is workflow-scoped and signed by GitHub; it does not grant access to anything beyond what the workflow already has. Bundled with the fuzz.yml musl drop on this PR — both are CI workflow plumbing fixes uncovered by the same Tier-5 PR (#169).

…#168) (#170) * fix(ci): drop musl target from fuzz.yml, bust cache key Fixes #168 root cause per smithy's analysis on the issue thread: The "sanitizer is incompatible with statically linked libc" error on fuzz_parse_component / fuzz_resolver_terminates jobs was NOT runner config drift. All 7 rust-cpu runners have identical toolchains and configs. The actual problem: `dtolnay/rust-toolchain@nightly with: targets: x86_64-unknown-linux-musl` installed the musl toolchain target. cargo-fuzz's `--release` reuse path can pick up a musl-built artifact on cache restore, and musl statically links libc which is incompatible with the AddressSanitizer cargo-fuzz injects via `-Z sanitizer=address`. The failure mode then propagates from any runner that happened to receive a musl-contaminated cache key. Fix: - Drop `targets: x86_64-unknown-linux-musl` from the toolchain install step. cargo-fuzz uses the host gnu target by default, which is sanitizer-compatible. - Version-bump the actions/cache key from `${{ runner.os }}-fuzz-` to `${{ runner.os }}-fuzz-v2-` to invalidate ALL existing cache snapshots once, including any that captured musl artifacts. - Document the rationale inline so a future change doesn't reintroduce the targets line without checking. The musl target isn't referenced anywhere else in the repo — verified with `grep -r musl meld-core/ fuzz/` (no matches outside this workflow). Dropping it is a strict simplification. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> * fix(ci): mythos-auto needs `id-token: write` for OIDC token After the unzip block on rust-cpu runners cleared (#167), PR #169's mythos-auto matrix scan ran far enough to expose a third plumbing issue: ``` error: Error message: Unable to get ACTIONS_ID_TOKEN_REQUEST_URL env variable at <anonymous> (.../@actions/core/lib/oidc-utils.js:71:27) ... Attempt 3 failed: Could not fetch an OIDC token. Did you remember to add `id-token: write` to your workflow permissions? ``` claude-code-action calls `core.getIDToken()` early in `setupGitHubToken` (entry point: `src/github/token.ts:15`). The OIDC issuer URL is injected as the `ACTIONS_ID_TOKEN_REQUEST_URL` environment variable, but only when the workflow has `permissions.id-token: write`. mythos-auto.yml's permissions block had `contents: read` and `pull-requests: write` but not `id-token: write`. The action retries 3× via its `retryWithBackoff` helper and then aborts before running its prompt. The sticky-comment + label flow then short-circuits and the placeholder-FINDING fallback fires. Adds the permission with an inline comment explaining the requirement. The token is workflow-scoped and signed by GitHub; it does not grant access to anything beyond what the workflow already has. Bundled with the fuzz.yml musl drop on this PR — both are CI workflow plumbing fixes uncovered by the same Tier-5 PR (#169). --------- Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>

avrabe mentioned this pull request May 19, 2026

fix(ci): drop musl target from fuzz.yml + add id-token to mythos-auto (#168) #170

Merged

4 tasks

avrabe merged commit ca28ce5 into main May 19, 2026
11 of 14 checks passed

avrabe deleted the test/ls-a-8-inner-list-rep-func branch May 19, 2026 12:37

avrabe mentioned this pull request May 20, 2026

chore: release v0.9.0 #176

Merged

2 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

test(fact): LS-A-8 regression for inner-list rep_func selection#169

test(fact): LS-A-8 regression for inner-list rep_func selection#169
avrabe merged 1 commit into
mainfrom
test/ls-a-8-inner-list-rep-func

avrabe commented May 19, 2026

Uh oh!

github-actions Bot commented May 19, 2026

Uh oh!

github-actions Bot commented May 19, 2026

Uh oh!

avrabe commented May 19, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Conversation

avrabe commented May 19, 2026

Summary

Why this matters

Test approach

Gate verdict

Local test run

End-to-end mythos-auto status

Uh oh!

github-actions Bot commented May 19, 2026

Mythos delta-pass required

Uh oh!

github-actions Bot commented May 19, 2026

LS-N verification gate

Uh oh!

avrabe commented May 19, 2026

Admin-merge per #139 + #170 follow-up

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant