fix(resource_graph): #295 — rep-backed Defines authoritative over export-inferred terminal (LS-A-17 hardening)

[avrabe]

What

Closes the #295 follow-up: defensive hardening of ResourceGraph::build's definer attribution. The terminal-exporter pass ran defines_cache.insert / definer_cache.insert before the rep-backed defines_candidates were merged with .or_insert, so an export-name terminal holding no ResourceRep could silently override a genuine rep-backed definer for the same (iface, rn).

Why it's hardening, not a correctness fix

Reachability to a live misroute was REFUTED (#295): the resolver consumes resource_definer only as .is_some(), and the routing override at resolver.rs:3116 is downgrade-only + heuristic-gated, so a wrong definer value can't steer a route. This makes the resource queries robust against future consumers; it changes no current routing.

Fix

Compute rep_backed_resources (the (iface,rn) set with a rep-backed Defines candidate) and skip export-inferred attribution for those — rep-backed Defines is authoritative; export-inference fills only the genuine no-rep (flattened-canonical) case it exists for. Behaviour-unchanged where the terminal exporter is the rep holder (the verified-correct LS-A-17/18 + live-routing cases); only the rep-vs-export conflict resolves toward the rep holder.

Oracle (proven red→green)

ls_a_17_rep_backed_definer_authoritative_over_export_terminal: a rep holder (comp 0) + a no-rep export terminal (comp 1) for the same interface → asserts resource_definer == Some(0), defines_resource(0)=true, defines_resource(1)=false. Confirmed FAILING (Some(1)) on the pre-fix code, passing after.

Traceability & verification

• LS-A-17 Fix section extended with the resource_graph: two latent resource-attribution weaknesses (reachability unconfirmed) — Mythos sweep 2026-06-17 #295 hardening + a residual note (the no-rep-collision last-wins determinism, .is_some()-immune at every consumer). Honest framing: robustness, reachability-refuted — not a new loss path.
• resource_graph 4/0; full meld-core suite 0 failed; clippy -D warnings + fmt clean; LS-N gate 57/0/0 (LS-A-17 already gated; the new ls_a_17_ test adds coverage); rivet validate 0 broken cross-refs.

Scope

Tier-5 (resource_graph.rs) → Mythos clean-room delta-pass + mythos-pass-done label before merge.

🤖 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/resource_graph.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

✅ 57/57 approved LS entries verified

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

[avrabe]

Mythos clean-room delta-pass — VERDICT: REFUTED (hardening sound, behaviour-preserving)

A fresh-context adversarial verifier attacked the change (bounded; throwaway probes reverted, tree clean):

1. Oracle honesty — disabled ONLY the new guard (left the committed test) → ls_a_17_rep_backed_definer_authoritative_over_export_terminal fails with exactly left: Some(1), right: Some(0) (the claimed pre-fix value); the other ls_a_17_*/ls_a_18_* still pass. Genuinely red→green, non-tautological.
2. Behaviour-preservation — full meld-core suite passes unchanged post-fix (0 failed). No real resolver-produced topology changes its resource_definer/defines_resource answers.
3. Cleanup-purge attack (the dangerous case for this change) — built the exact input: a rep holder whose own same-interface import resolves to a peer, so the re-exporter cleanup purges its rep-backed entry and the new guard has already skipped export-inference → post-fix leaves the resource with no definer (None) vs pre-fix Some(1). Not a confirmed regression: the input is spec-contradictory and not resolver-producible (a genuine rep holder exports the interface, it doesn't wire its own same-interface import to a sibling), and the pre-fix Some(1) was itself the wrong re-exporter attribution — so it's a change between two degenerate answers on an unreachable input, corroborated by 0 integration-suite failures.

Additional safety note: even if that degenerate input were somehow reachable, post-fix (None) degrades to a loud missing-table trap at resolver.rs:1891, whereas pre-fix (Some(1)) was a silent wrong-attribution — so the change is safe-or-better (fail-loud beats silent-wrong) in the worst case.

No failing reachable test could be constructed → REFUTED. The hardening is sound. Working tree confirmed clean.

[github-actions]

Mythos delta-pass (auto)

✅ NO FINDINGS across 1 Tier-5 file(s)

File	Verdict	Hypothesis
``	✅ NO FINDINGS	—

_{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]

Iteration: mythos-auto caught an [export]-prefix gap my manual clean-room pass missed

The mythos-auto discover pass flagged a real incompleteness in the first commit (c29d962): the rep_backed_resources guard used exact interface-string keys, but defines_resource/resource_definer and the terminal-exporter iface_matches are [export]-prefix-insensitive. So a rep holder registered under svc:lib/api failed to match a terminal whose resource node is keyed [export]svc:lib/api, defeating the guard in the [export]-alias case → defines_resource(no_rep_terminal, "svc:lib/api", "thing") wrongly returned true.

Verified the finding (not taken on faith): added ls_a_17_rep_backed_guard_is_export_prefix_insensitive, confirmed it FAILS on c29d962, then fixed by [export]-normalising the prefix on both the set keys and the membership check (matching defines_resource's semantics). Now red→green (commit f964a6b).

This is the dual-gate working as intended — the automated discover caught what the bounded manual pass missed. Honest note for the record: my earlier "REFUTED" verdict was sound for the cases it tested but incomplete; the [export] variant is now covered by a dedicated oracle.

Re-verification on f964a6b: resource_graph 5/0; full meld-core suite 0 failed; clippy -D warnings + fmt clean; LS-N 57/0/0; rivet 0 broken cross-refs. The fresh auto-discover on this push should report NO FINDINGS.