core: give Bridge an executor for late registration replies, and re-measure what a local dispatch allocates (fixes #588, refs #572)

[Yaraslaut]

Two tickets on the core dispatch tree, one commit each. One lands, one is handed
back with the measurement that says it should be.

• core: give Bridge an executor bound to its own thread, so the threading guarantee is structural for Bridge-mediated calls too #588 — Bridge gets an executor for the registration replies that outlive
  their dispatch frame. Landed (fixes #588).
• core: a call pays the remote path's cost whether or not it takes it — 19 allocations, two CompletionStates, two strings per dispatch #572 — the remote path's cost per dispatch. Re-measured, not built.
  The instrument is committed; the numbers and the re-scope are
  on the issue.
  No fixes trailer: the ticket stays open.

Filed while here: #660 (StrandExecutor rebuilds a model's Strand on every
serial dispatch — 4 allocations, 752 of the 1995 bytes per local call).

---

#588 — the bridge's own executor

Bridge issues registrations on its own behalf and was the only caller in the
framework that could not say where their completions are delivered: its five
dispatch sites name exec::detail::inlineExecutor(), so a reply is published on
whichever thread the backend settled it on. That is the thread morph#486's
use-after-free is about — each of those callbacks asks "is the Bridge still
alive" and then touches it.

The constructor now takes an optional IExecutor* bridgeExec, and
detail::deliverLate routes a late reply to it. Null — the default — runs it
inline, byte for byte what happened before, so nothing that does not ask for the
new argument changes.

Where this deviates from the ticket, and why

#588 asks for the five inlineExecutor() arguments to be replaced. They are
not, and that is the one deliberate deviation. Naming a posting executor on the
bindModel/promoteModel call breaks two things:

1. registerHandler() stops being synchronous for every backend that binds
   inline. The settle becomes a queued task, claimHandoff finds nothing parked,
   and the caller gets an unbound handler from a call that has always returned a
   bound one.
2. A kCallerMayBlock backend deadlocks when the dispatching thread is the
   executor's thread: awaitHandoff waits for a task only that thread could run.
   A GUI embedder passing its GUI executor is exactly that case.

An inline settle has to reach parkIfInFrame inside the dispatch frame, and the
dispatching frame then publishes it on the dispatching thread. Only the late
reply has a delivery thread left to choose, and that is the one the new executor
gets. assignHandlerPrimary grew an AsyncDispatchHandoff for that reason — it
had no way to tell the two cases apart, and posting both would have made an
inline promote asynchronous (which BridgeHandler::execute's onResult relies
on not being).

Both triage comments on #588 were read. The first one's objection — that "an
executor bound to the thread that runs ~Bridge" asks for an affinity
concurrency_and_lifetimes.md §"teardown is order-independent, on any thread"
spent two sections arguing against — is why the executor is supplied, not
owned: Bridge still has no thread, spawns none (it could not, in an Emscripten
build with no pthreads), and imposes no affinity. Capturing the constructing
thread was rejected for the same reason the first triage gives: it names a thread
nobody promised would be the destroying one.

The one claim the safety rests on

Only the late-delivery path changed; the in-frame path is untouched. A reply
that settles inside the dispatch call is parked by parkIfInFrame and published
by the dispatching frame exactly as before, so every synchronous registration
contract in the tree holds unchanged. If that claim is wrong, registerHandler()
silently stops binding — which is what the second new test case exists to catch.

What it buys, stated as narrowly as it is true

The morph#486 window is closed for an embedder whose executor runs on a thread
that cannot run ~Bridge concurrently: the callback and the destructor are then
two tasks on one thread. An executor on an unrelated thread satisfies the type
and closes nothing; it makes nothing worse either, since the existing
CallbackToken/BridgeLifetime gates are untouched. The three specs now say
that, rather than an unqualified "the guarantee is structural".

Review reasoning, inline (no /code-review, per the lane's bounds)

• Can the posted task outlive the bridge? Yes, and it always could — that is
  what the gates are for. What changed is that _bridgeExec is read once at
  dispatch and captured by value, never from inside the callback: reading
  this->_bridgeExec in a callback that can run after ~Bridge would be a read
  of destroyed memory ahead of the gate that exists to prevent one. The member
  comment says so.
• Does the executor widen the active()-then-touch window? For a null
  executor, not at all. For a non-null one it defers the whole body to the
  executor's thread, which is the point; the gates run inside the deferred body.
• assignHandlerPrimary's new handoff. _attachMtx is released before the
  dispatch (it was already), so publishing the parked outcome after
  claimHandoff takes the same lock the callback would have taken, on the same
  thread, at the same point in the frame. Behaviour is unchanged for every
  backend that settles inline; attachHandler + bindingPrimary() is asserted
  in the new tests.
• Allocation shape. deliverLate is a template with a forwarding reference,
  not a std::function parameter, so the null path type-erases nothing and
  allocates nothing. The first version took a std::function and broke
  morph#108's OOM-injection case — the injected failure hit the new 256-byte
  capture copy instead of the target allocation. That is now a comment in the
  code, and primaryCopy is moved rather than copied into the deferred body.
  onDone cannot be moved the same way (captured from a const& parameter, so
  the capture is const) — clang-tidy's performance-move-const-arg caught the
  attempt.

Verification

• morph_tests: 1561 cases, 22972 assertions, all pass (one deliberate
  expected failure, [ERROR] default-sink-coverage). GCC 16.2.1, Release.
• Mutation-checked, per AGENTS.md. Making deliverLate ignore its executor
  and always run inline fails the late-reply case:

  tests/test_async_registration.cpp:2483: FAILED:
    CHECK( binding->currentId.load() == 0U )
  with expansion:  100 == 0
  tests/test_async_registration.cpp:2484: FAILED:
    REQUIRE( bridgeExec.queued() == 1 )
  with expansion:  0 == 1
  

  Restored, re-run, green. The three cases pin the three halves: a late reply
  goes through the executor, an in-frame bind and a keyed attach do not (with an
  executor that never drains), and no executor means the old behaviour.
• Gates run locally, all green: check_mutation_survivors.py,
  check_nolint_directives.sh, check_bidi_controls.py,
  check_spec_citations.sh, check_spec_sync.sh (real path list),
  clang-format --dry-run -Werror over exactly the touched files.
• clang-tidy 22.1.8 against a clang-configured compile database: no finding
  on any changed line. Three findings remain in bridge.hpp on lines this
  branch does not touch (performance-unnecessary-value-param ×3), which
  clang-tidy-diff does not report and which are present on master.
• No gate repoint was needed: no check_mutation_survivors.py or
  branch_partial_allowlist.json citation moved.

---

#572 — re-measured, handed back

The ticket's scope is a number taken on 4017228d; #639, #649 and #654 rewrote
the dispatch path afterwards. The commit adds
tests/bench/bench_dispatch_allocations.cpp (morph_bench_alloc, under the
existing MORPH_BUILD_LOAD_TESTS) so the number is re-checkable in one command,
and records what it says.

On f24e225a, x86-64 Linux, GCC 16.2.1 / libstdc++, -O2 -DNDEBUG,
Ping{int} -> Pong{int} through LocalBackend, 50 warm-up calls excluded, 200
counted:

local execute round-trips  : 200
heap allocations total     : 4165 (20.82 per call)
bytes allocated total      : 398912 (1994.6 per call)

allocations in one steady-state call: 21

Against the ticket's 19.2 / 1983: 20.8 and 1995. The total holds — the path
did not get cheaper. The attribution does not, and the attribution is what
scopes the fix:

• "two strings" → one, on a workload whose ids straddle libstdc++'s 15-byte
  SSO threshold; 0–2 in general. The SSO caveat the ticket applies to Part C
  applies to Part A too.
• "3 std::functions" → two. deserializeResult is captureless and fits the
  small buffer; it does not appear in the census.
• "two CompletionStates" → confirmed, both still there.
• Unrecorded by the ticket, and the largest single cluster: four allocations
  and 752 of the 1995 bytes are StrandExecutor rebuilding the model's Strand
  every call. Filed as core: StrandExecutor rebuilds a model's Strand on every serial dispatch -- 4 allocations and 752 of the 1995 bytes per local call #660, not folded in.
• Consequence: Part A is worth 2–4 and Part B ~6, so A+B land at 11–13 per
  call, not the "2-3" the ticket targets. Building them as scoped would be work
  measured against a target it cannot reach.

Per the dispatch's own instruction — if the figure has materially changed, stop
and report; do not build a fix against a number you have just disproved — the
fix is not attempted here. The full per-line table, the re-scope proposal and the
"not verified" list (Part C was not re-measured; one toolchain only) are in
the issue comment.

morph_bench_alloc is an instrument, not a control: not registered with ctest,
asserts nothing unless --budget=<n> is passed, and both arms of that budget
were exercised (--budget=5 exits 1 and names the overrun, --budget=40 exits
0). It is a separate binary from morph_bench because it replaces the global
operator new/delete, which is process-wide and would perturb the latency
benchmark sharing the binary. Its one warning suppression
(-Wno-mismatched-new-delete, GCC pairing an inlined new with the std::free
inside the replaced operator delete) is scoped to that one target.

---

Not verified

• CI has not run. Reporting immediately per the lane's hand-off rule; no
  check results are included below the line.
• Qt, net, ladder and examples were not built locally (MORPH_BUILD_TESTS +
  LOAD_TESTS only). The Bridge constructor change is source-compatible — a
  defaulted trailing parameter — but that is an inference from the signature, not
  a measurement of those builds.
• The new bench was run on one toolchain and one platform. libc++ and MSVC have
  different SSO thresholds and std::function buffer sizes, so the census will
  differ there. That is exactly why it has no default ceiling.
• Windows/macOS behaviour of a global operator new replacement in that target
  is untested; it compiles nowhere but where CI builds load tests.

🤖 Generated with Claude Code

https://claude.ai/code/session_01VptDWG2fKr2vBnLSJcgzgW

---

CI repair pass (3 commits on top, rebased onto 7ab4c7a9)

The first push was verified with GCC and morph_tests, and all three red legs
were things that build never ran. Rebased onto 7ab4c7a9 (#657) first; the
branch touched none of what #657 moved and the rebase was clean.

One commit per cause, on top of the original two — neither of which was
rewritten. da9deb52 still says refs #572, not fixes: that ticket stays
open on its re-measurement.

Red leg	Cause	Commit
Build the ladder's WASM clients	four -Wshadow init-captures	b64c1e9a
clang-tidy-diff	attachHandlerAsync cognitive complexity 28 > 25	194c2d12
Linux / clang-coverage	two stale branch-allowlist line hints	7b7e052a

1. -Wshadow — and why the local clang build was also clean

Renamed the four init-captures to registered/bound/failed. The fifth
(bridge.hpp:1208) is left alone: its onFailed is a plain local, not a
structured binding, and neither toolchain diagnoses it.

The rename cannot change which object is moved from. An init-capture's
initializer is looked up in the enclosing scope, so [x = std::move(x)] and
[y = std::move(x)] both move from the enclosing x. Checked with a tracked
type on clang 22.1.8 rather than argued from the standard — the two forms
produce byte-identical traces, enclosing copy left moved-from, inner callable
holding the live value:

A: shadowing form [f = std::move(f)]        B: renamed form [g = std::move(f)]
  copy  of OUTER(gen1)                        copy  of OUTER(gen1)
  move  -> gen1                               move  -> gen1
  after move, enclosing f.tag=<moved-from>    after move, enclosing f.tag=<moved-from>
  call  tag=OUTER gen=1                       call  tag=OUTER gen=1

This was never a GCC/clang split. A full clang 22.1.8 -Weverything -Werror
build is also silent here, so "build with clang" would not have caught it
either. Local clang 22.1.8 files this diagnostic under
-Wshadow-uncaptured-local, which compiler_options.cmake suppresses tree-wide;
emsdk 3.1.56's clang files the identical construct under plain -Wshadow, which
nothing suppresses. Both legs pass the same -Wno-shadow-uncaptured-local. The
WASM leg is therefore the only leg in CI enforcing this diagnostic class, and no
local build on morph's usual toolchain can reproduce it. Filed as #662, not
folded in.

Verified by dropping that one suppression from the project's own flags for a TU
that includes bridge.hpp, everything else identical:

before: shadows a local variable: 18   shadows a structured binding: 4
after:  shadows a local variable: 18

Same 18 pre-existing local-variable shadows either side; all four
structured-binding shadows gone; none introduced.

2. Cognitive complexity — extraction, not a wider gate

Neither the threshold nor a NOLINT was touched. Following #615's remedy in this
same file, but extracting the shape attachHandlerAsync shares with
ensureBoundAsync rather than lifting one body: both run the same four steps
on an out-of-frame reply (Bridge alive? binding alive? backend still active?
report through onDone), differing only in what a success publishes. That is
now publishLateBindReply's Publish parameter, and two ~30-line bodies — two
copies of the stale-backend reasoning and of its error string — became one.

assignHandlerPrimary is deliberately not routed through it: having no
onDone, it drops a stale reply silently rather than reporting it, so folding
it in would mean a second mode for a helper whose contract is "report exactly
once".

Publish is a template parameter, not a std::function, so the late path
type-erases and allocates nothing — the constraint morph#108's OOM-injection
case already put on deliverLate.

Measured with clang-tidy 22.1.8 (CI's pinned major — there is no version
skew; local clang-tidy --version is 22.1.8 and CLANG_VERSION: "22"):

	before	after
attachHandlerAsync	28	13
ensureBoundAsync	20	9
publishLateBindReply	–	7
assignHandlerPrimary	19	19 (untouched)

ensureBoundAsync at 20 was five under the gate and next in line; this takes
both off it. The exact command that reported the 28 now reports nothing on
bridge.hpp, and clang-tidy-diff against the base reports nothing on any
changed line.

Behaviour is unchanged, with one narrow exception stated rather than
glossed: the shared helper wraps the publish in try/catch for
attachHandlerAsync's two std::string assignments, so ensureBoundAsync —
which previously had none — now stores its atomic currentId inside one. An
integral store is noexcept, so that handler is unreachable there. Lock
scope, lock ordering and "onDone outside the lock" are identical at both sites.

3. Linux / clang-coverage — what the log actually said

Not the compile errors, and not the hypothesis that a new partial line or a
breached floor did it. All 2926 tests passed and no floor was breached
(include/morph/core 94.90% against a 94% floor). The entire failure was the
allowlist audit in scripts/check_branch_coverage.py:

error: include/morph/core/bridge.hpp:1557 has moved to line 1709. The text still matches, so nothing is wrong with the disposition -- update the `line` hint.
error: include/morph/core/bridge.hpp:1679 is allowlisted by a source line that appears 3 times (lines [1832, 1856, 1945]), and none of them is 1679, so which one is meant is not decidable. Make the entry unambiguous.

Both dispositions are still correct; only the hints drifted, because this branch
inserted lines above them. Repointed against the branch's final tree (the
two commits before it moved them again): 1557 → 1733, 1679 → 1856.

The ambiguous one was resolved by reading all three candidates, not by taking
the first match. All three are in executeVia: the catch block that undoes
_pendingCalls before rethrowing, the .then() disarm, and the .onError()
disarm. Three independent lines of evidence agree on the first:

1. The entry's own reason says so outright — "This entry is specifically the
   exception-path use of the guard (the catch block that undoes
   _pendingCalls and cancels the deadline before rethrowing)" — and then
   explicitly disclaims the other two as a different, reachable guard.
2. Read directly: line 1856 is that catch block.
3. On master, where the gate is green, hint 1679 is an exact match on the first
   of the three, and the other two sit at the offsets the reason names.

Worth being explicit: the resolver accepts any hint matching any occurrence,
so "all 22 entries resolve cleanly" is not evidence the right one was
picked — hence the three checks above. The audit's other direction (the resolved
line must still be partial in the LCOV report) would catch a wrong pick, and
that half needs a coverage run this pass did not make.

Two bare line numbers inside the reason prose were already stale and are removed
rather than restated — the file's own header calls a comment citing a bare line
number the defect this repository has found three times, and the structural
naming beside them identifies the sites without rotting.

Review reasoning, inline (no /code-review, per the lane's bounds)

• Does the helper widen any lock scope? No. It takes _attachMtx at the
  same point both inlined bodies did, and releases it before onDone on every
  path that calls onDone at all. The only paths that skip onDone are the two
  that skipped it before (Bridge gone, binding gone).
• Can publish run after ~Bridge? Same as before: the liveness token is
  checked first and the whole body runs on whatever thread deliverLate chose.
  The helper changed where the code lives, not which thread runs it.
• Does taking Publish&& and std::forwarding it once risk a double-move?
  It is invoked at most once, on the success arm only, and the two call sites
  pass lambdas that own nothing needing a move.
• Do the renamed captures still move rather than copy? Yes — verified above,
  and primaryCopy is still moved into the deferred body, so morph#108's
  OOM-injection case still sees the same allocation shape.

What was measured this pass, and on what

All on 7b7e052a unless stated, x86-64 Linux, clang 22.1.8:

• clang -Weverything -Werror (the project's own Clang branch) build of
  morph_tests and morph_bench_alloc: zero diagnostics. The bench had
  never been compiled by clang before — the previous pass used GCC and its
  target needs MORPH_BUILD_LOAD_TESTS=ON to exist at all.
• Suite green: 1561 cases, 22971 assertions, one deliberate expected failure
  ([ERROR] default-sink-coverage).
• clang-tidy 22.1.8 against a clang compile database: nothing on bridge.hpp;
  clang-tidy-diff against the base finds nothing on any changed line of
  bridge.hpp or the two changed test sources.
• clang-format --dry-run -Werror over exactly the touched files: clean.
• Doxygen WARN_AS_ERROR=FAIL_ON_WARNINGS: clean.
• Gates: check_bidi_controls.py, check_mutation_survivors.py,
  check_spec_citations.sh, check_spec_sync.sh (real path list),
  check_nolint_directives.sh, check_rung_filters.sh (58 checks, incl.
  ci/testkit: three gates that did not cover what they appeared to (fixes #651, fixes #652, fixes #655) #657's new check-5). All green.
• The complexity and shadow fixes were each mutation-checked: reverting the
  rename restores all four structured-binding diagnostics; the command that
  reported complexity 28 reported it again on the pre-fix tree and reports
  nothing after.

Still not verified

• No Emscripten toolchain is available here, so the WASM leg itself was
  not built. Its fix rests on a local proxy — the same diagnostic, on a
  different clang, with one suppression dropped — not on running that leg.
• No coverage build was run. The allowlist citations were verified against
  check_branch_coverage.py's own resolver; the partial-line half of the audit,
  and this branch's effect on the subsystem floors, are unmeasured.
• Qt, net and the ladder were not built locally.
• CI has not been waited on; the check counts reported with this push are
  incomplete by construction.
• ladder: the ledger scenario corpus fails intermittently with "database is locked" — observed once, not reproduced #658 (SQLite database is locked in the ledger scenario corpus) is a known
  flake: an Application ladder failure with that signature is not this branch.

[Yaraslaut]

Runner verification

The measurement-first condition on #572 did its job, and the result is more useful than either outcome I expected. I dispatched it expecting the number to have gone stale after #639, #649 and #654 rewrote the dispatch path. It has not: 20.8 allocations / 1995 bytes per call against the ticket's 19.2 / 1983 — the total held. What is wrong is the attribution, in three separate ways, and the attribution is what scopes the fix:

• "two strings" → one here, 0–2 in general (the ids straddle libstdc++'s 15-byte SSO threshold — the caveat the ticket applies to Part C applies to Part A too)
• "3 std::functions" → two (deserializeResult is captureless)
• and the largest single cluster is unrecorded: 4 allocations / 752 of 1995 bytes, 38%, from StrandExecutor rebuilding a model's Strand every call.

So Part A + Part B land at 11–13 per call, not the 2–3 the ticket targets. Building them as scoped would have been real work measured against an unreachable target — which is precisely the waste Step 6's re-measure rule exists to prevent, arriving by a route I did not anticipate.

Handed back correctly. Commit dbe10202 says refs #572, not fixes; #572 is still OPEN; the measurement is on the issue; #660 is filed for the StrandExecutor cluster with no triage: label. That is the right shape for "the ticket is not what it thought it was".

Committing the instrument is the part that compounds. tests/bench/bench_dispatch_allocations.cpp under the existing MORPH_BUILD_LOAD_TESTS, asserting nothing unless --budget=<n> is passed, with both arms exercised (--budget=5 → exit 1, --budget=40 → exit 0). The next person re-measures with one command instead of rebuilding the apparatus — and a bench that asserts nothing by default cannot become a flaky gate.

On #588's deliberate deviation

Verified rather than taken on trust: 16 occurrences of inlineExecutor() remain in bridge.hpp, so the five bindModel/promoteModel sites were genuinely left alone. The stated reason holds — replacing them would make registration asynchronous for every inline-binding backend and deadlock a kCallerMayBlock backend whose dispatching thread is the executor's thread. A ticket's text asking for a change that would deadlock is the case AGENTS.md is about, and departing from it with the reason written down is right.

The no-op claim checks out:

explicit Bridge(std::unique_ptr<IBackend> backend,
                ::morph::exec::IExecutor* bridgeExec MORPH_LIFETIMEBOUND = nullptr)

A defaulted trailing parameter, so existing callers are unaffected, and MORPH_LIFETIMEBOUND puts the borrow in the type rather than only in prose.

The narrower secondary claim is the honest one: morph#486's window closes only for an embedder whose executor runs on a thread that cannot run ~Bridge; an executor on an unrelated thread satisfies the type and closes nothing. Saying that in the spec, rather than "the guarantee is now structural", is the difference between a spec that holds and one that reads well.

The finding I most want kept

taking std::function in deliverLate put an allocation on the default (null-executor) path, which broke tests/test_async_registration.cpp's morph#108 OOM-injection case — the injected failure caught the new capture copy instead of the target allocation.

An OOM-injection test that fails because a new, unrelated allocation appeared upstream of the injection point is doing something most tests cannot: detecting a change in allocation behaviour nobody asserted. That it caught a defect in the first draft, and that the fix (a forwarding-reference template, moving primaryCopy rather than copying) makes the default path allocate nothing, is worth more than the feature. It should not be weakened when it next gets in someone's way — and it will.

Not verified by me: the allocation measurements themselves (they need the bench built), the mutation check on deliverLate, and the Qt/net/ladder/WASM builds the lane did not run — source compatibility of the defaulted parameter is by inspection there, not measurement.

Not merged: CI incomplete at hand-off. Worktree pruned.

🤖 Generated with Claude Code

https://claude.ai/code/session_01VptDWG2fKr2vBnLSJcgzgW

[Yaraslaut]

Runner, sweep 10:41 — three failures, three different causes

gh pr checks 661: 36 pass, 3 fail, 2 pending. They are not one problem.

1. Build the ladder's WASM clients — four -Wshadow errors, mechanical

include/morph/core/bridge.hpp:2112:38: error: declaration shadows a structured binding [-Werror,-Wshadow]
include/morph/core/bridge.hpp:2118:50: error: declaration shadows a structured binding [-Werror,-Wshadow]
include/morph/core/bridge.hpp:2297:50: error: declaration shadows a structured binding [-Werror,-Wshadow]
include/morph/core/bridge.hpp:2303:50: error: declaration shadows a structured binding [-Werror,-Wshadow]

Exactly four, all the new init-captures — [onRegistered = std::move(onRegistered), newId] and [onFailed = std::move(onFailed), failure] — shadowing the structured binding they are initialised from. The WASM leg compiles with -Weverything -Werror; GCC does not diagnose this, which is why a GCC-only local build reported clean.

2. clang-tidy-diff — a threshold this branch crossed, not a style nit

From the run's artifact (the run itself is stalled, so the log is unreachable):

include/morph/core/bridge.hpp:776:10: error: function 'attachHandlerAsync' has
    cognitive complexity of 28 (threshold 25)
    [readability-function-cognitive-complexity,-warnings-as-errors]

This is not fixable by renaming anything. attachHandlerAsync was under the threshold before and the executor branch pushed it over. #615 hit the identical wall in this file and the answer there was extraction — rebindThroughSurface / stageRebinds / rollbackStaged / commitRebinds — so there is a precedent in the same function family.

3. Linux / clang-coverage — cause unknown, and I am not guessing

It failed after 40m57s, which means it got a long way in, so it is unlikely to be the compile errors above. The run holding it has been in_progress with no update for ~50 minutes, its log is unreachable, and it published no coverage-report artifact — only clang-tidy-report and clang-format-report. So I have nothing to read.

The leading hypothesis, stated as a hypothesis: this branch adds tests/bench/bench_dispatch_allocations.cpp and a new executor branch in bridge.hpp, and the lane's own notes say it ran no coverage build. A new partial line or a moved allowlist citation would fail this leg without touching any other. That is a guess. It must be checked against the log, not assumed.

What I am not doing

I am not pushing the four renames now. Two of the three failures are diagnosed and one is not, and ci.yml sets cancel-in-progress: true — a push cancels the stalled run and purges whatever the coverage leg would have told us. That trade cost this session nothing on #654 and gained the actual diagnosis; the same reasoning applies.

Dispatching a lane whose whole batch is this PR, with all three findings and the instruction to get the coverage log before touching it.

🤖 Generated with Claude Code

https://claude.ai/code/session_01VptDWG2fKr2vBnLSJcgzgW

[Yaraslaut]

Runner verification — and my dispatch was wrong about the cause

I told this lane "GCC does not diagnose this, which is why the GCC-only local build was clean." That explanation is false, and the lane checked rather than accepting it. cmake/compiler_options.cmake:

161:  -Wno-shadow-uncaptured-local    # lambda param shadowing an uncaptured local
233:  -Wshadow

The project enables -Wshadow and suppresses -Wshadow-uncaptured-local tree-wide. clang 22 files this construct under the suppressed flag; emsdk 3.1.56's older clang files the identical construct under plain -Wshadow. So a full local clang -Weverything -Werror build is also silent, and building with clang — which is what I told the lane would have caught it — would not have.

The consequence is the real finding, and #662 records it: the WASM leg is currently the only leg in CI enforcing this diagnostic class, by accident of which clang version files it under which flag. That is a gate whose coverage nobody chose, and it is exactly the class of thing this repository files issues about.

Rebase integrity verified rather than trusted:

#588 commit content identical after rebase (f0f4be90 vs 69a697db): True
#572 commit content identical after rebase (da9deb52 vs dbe10202): True

and da9deb52 still says refs #572, with #572 still OPEN — the hand-back is intact, which was the thing most at risk in a five-commit rebase.

On the coverage log — my hypothesis was also wrong

I guessed new partial lines from the bench file or the executor branch. It was neither: 2926 tests passed, no floor breached (include/morph/core 94.90% against a 94% floor), and the entire failure was the allowlist audit — two stale line hints in bridge.hpp, one of them ambiguous across three occurrences. I labelled that a guess when I wrote it, which is the only reason it did no harm.

Two things the lane did there are worth keeping:

• It resolved the ambiguous citation by three independent checks that agree — the entry's own reason naming the catch block and explicitly disclaiming the other two candidates; the line at 1856 being that catch; and hint 1679 matching the first occurrence on master where the gate is green. That is how a deliberately-ambiguous entry is supposed to be resolved.
• It then stated the limit of its own evidence: "the resolver accepts any hint matching any occurrence, so 'all 22 resolve cleanly' is not evidence the right one was picked." A green gate that cannot distinguish right from plausible is worth saying out loud.

On the complexity fix

Extraction, not a NOLINT and not a threshold change — and the split was chosen to cover ensureBoundAsync (20, five under the gate and next in line) as well as attachHandlerAsync (28 → 13). Excluding assignHandlerPrimary with a stated reason (no onDone, drops stale replies silently, would need a second mode) is the right kind of restraint.

The behaviour note is the part I would have wanted flagged and was: ensureBoundAsync's atomic currentId store now sits inside the helper's try/catch, and an integral store is noexcept, so that handler is unreachable there. Stated rather than glossed.

Residual risk, in the lane's words and mine: no coverage build was run, so the partial-line half of the allowlist audit is unmeasured — and that half is precisely what would catch a wrong pick among the three candidates. No Emscripten either, so the leg whose failure started this was not re-run locally; the -Wshadow fix rests on a local proxy with the suppression removed (before: 18 local + 4 structured-binding; after: 18 + 0).

Not merged: CI incomplete at hand-off. Worktree pruned.

🤖 Generated with Claude Code

https://claude.ai/code/session_01VptDWG2fKr2vBnLSJcgzgW

[Yaraslaut]

Runner, 11:09 — the four new red legs look like an upstream outage, not this branch

After the fix push: 18 pass, 4 fail, 19 pending. The four are Build documentation, Linux / gcc-release, Valgrind memcheck, find_package(morph CONFIG) consumability — all of them different from the three that were red before, and all failing at ~5 minutes, which is the shape of a setup step rather than a build or a test.

Build documentation lives in its own workflow, so its log is readable while the ci.yml run is still going, and it says:

E: Failed to fetch https://ppa.launchpadcontent.net/ubuntu-toolchain-r/test/ubuntu/pool/main/g/gcc-16/libgcc-s1_16-…_amd64.deb   503  Service Unavailable
E: Failed to fetch …/gcc-15/cpp-15-x86-64-linux-gnu_15.2.0-…_amd64.deb                                                          503  Service Unavailable
E: Failed to fetch …/gcc-16/libubsan1_16-…_amd64.deb                                                                            503  Service Unavailable
##[error]Process completed with exit code 100

The ubuntu-toolchain-r/test PPA is returning 503. Nothing to do with the code.

The other three are inference, not measurement, and I am saying so rather than rolling them up: their logs are unreachable while the run has 19 checks outstanding. What supports the guess is that all four install the GCC toolchain from that same PPA and all four died at the same ~5-minute mark. What would refute it is any of them showing a compile error instead once the run completes.

No action taken. Re-running now would hit the same outage, and pushing would cancel the 19 in-flight checks — including the legs that were the actual subject of this fix. The next sweep reads the completed logs and re-runs the affected legs if the PPA has recovered.

Worth noting for the record: this is the second infrastructure-shaped failure this session, after #658's SQLite database is locked. Neither is a defect in any branch, and both cost a diagnosis cycle on an unrelated PR. If a third appears it is worth asking whether the ladder and toolchain legs should distinguish "the environment failed" from "the change failed" in their exit status, rather than every consumer re-deriving it from a log.

🤖 Generated with Claude Code

https://claude.ai/code/session_01VptDWG2fKr2vBnLSJcgzgW

[codecov]

Codecov Report

❌ Patch coverage is 92.50000% with 6 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
include/morph/core/bridge.hpp	92.50%	4 Missing and 2 partials ⚠️

📢 Thoughts on this report? Let us know!