Issue #5 resolution: CM-4 review + wasmtime determinism evidence; IROH-1 sharpened

Spec-history review (operator prompt: is this wasmtime lagging a recent
spec change?): NO - both sides are ancient. The exclusivity model dates
to >=2025-08-20 (#553); sync-streams.wast's contrary assertion to
2025-09-05 (file birth); the in-window commits #650/#656 (May 2026)
renamed exclusive->exclusive_thread and refined the reentrance definition
without touching release points. ~11-month-old inconsistency.

Structural finding: nobody upstream can see it. Spec CI runs only
run_tests.py (the wast suite never executes against the reference);
wasmtime runs the suite via its tests/component-model submodule (e8d8005,
bumped 2026-07-24) with an exception ledger sync-streams is not on. Each
CI green against its own half.

Determinism (the operator's easier path, replacing the planned custom
wast): wasmtime's pass on the arbiter is deterministic BY CONSTRUCTION
(D.run never yields between rendezvous and the set call - no race exists
at the entry-gate check) and BY MEASUREMENT (50/50 identical passes,
wasmtime 49.0.0-dev; the 47.0.1 release CLI cannot parse post-#655 suite
syntax). The official test already contains the full IROH-1 shape - the
interloper is admitted, runs, and clobbers shared memory (address 16)
while the resolved task sits parked mid-frame - so no custom experiment
was needed: exams/wasmtime-exclusivity/ holds RESULTS.md + run.sh.

IROH-1 rewritten with the sharpened boundary: PRE-resolution blocks are
safe everywhere; POST-resolution blocks admit same-instance interleaving
per the suite-pinned semantics wasmtime and deltic both implement;
wasmtime's green endpoint row is survivorship under one deterministic
schedule, not a guarantee. CM-4 gains the review + evidence appendix.

Author: lann

exams/wasmtime-exclusivity/RESULTS.md

@@ -0,0 +1,78 @@
+# wasmtime exclusivity check — is the sync-streams pass deterministic?
+
+Evidence backing `upstream-component-model-repo-findings.md` CM-4's
+2026-08-09 review and the IROH-1 consumer finding. Question posed by the
+operator: wasmtime runs the official CM test suite — is *its* pass on the
+CM-4 arbiter (`test/async/sync-streams.wast`) itself scheduling accident?
+
+**Answer: no — deterministic semantics.** A custom counter-experiment wast
+was planned and then dropped as redundant: the official test already
+contains the full IROH-1 shape, and wasmtime's pass on it is deterministic
+by construction and by measurement.
+
+## What the official test already demonstrates
+
+`test/async/sync-streams.wast` (spec repo, e8d8005 vintage and current):
+
+1. `$C.get` calls `task.return` (RESOLVED) and then parks **mid-frame** in a
+   synchronous `stream.write` (first to the rendezvous).
+2. `$D.run` — sync-lowered, so it regains control at `get`'s *resolution*,
+   while `get`'s thread is still parked — rendezvous-reads, then calls
+   `$C.set` **without ever yielding in between** (straight-line core wasm).
+3. Line 145 asserts `set` reports **STARTED**: the same-instance task was
+   admitted, and its body *executed* (it runs its own `stream.read` and
+   memory traffic — clobbering address 16, which `get`'s parked frame also
+   uses — before blocking). Under `definitions.py`'s `exclusive_thread`
+   lifetime, `set` would be gated (STARTING) and the guest traps
+   `unreachable` at line 146.
+
+That is: entry admitted + interloper body run + shared state mutated, all
+while a resolved task sits parked mid-frame — the IROH-1 collision shape,
+in the official corpus, asserted as the *expected* behavior.
+
+## Why the pass is deterministic (structure)
+
+Between the rendezvous read and the `set` call, `$D.run` executes
+straight-line wasm with no suspension point; execution is single-threaded
+and cooperative. The machine state at the entry-gate check is therefore a
+pure function of the program, and STARTED-vs-gated is decided solely by the
+gating rule (wasmtime: `ConcurrentInstanceState.do_not_enter`, scoped to
+the sync-call span, ending at resolution). No race exists at the arbiter.
+
+## Measurement
+
+wasmtime 49.0.0-dev (`3ebfbe5af`, 2026-08-07 — a current-main dev release;
+the 47.0.1 release CLI cannot parse the post-#655 suite syntax):
+
+```sh
+./run.sh   # fetches nothing; expects `wasmtime` ≥ the 2026-07 suite syntax on PATH
+```
+
+Result: **50/50 identical silent passes** (exit 0) of
+`third_party/component-model/test/async/sync-streams.wast` with
+`-W component-model-async=y -W component-model-more-async-builtins=y`.
+
+deltic's own lane passes the same file deterministically (green under
+`DELTIC_SCHED_SEED=1` and `=4242`; see `harness/src/xfail.ts`'s
+sync-streams note and CI).
+
+## CI provenance (who actually runs this suite)
+
+- The spec repo's CI runs **only** `design/mvp/canonical-abi/run_tests.py`
+  — the wast suite is never executed against the reference.
+- wasmtime vendors the spec repo as the `tests/component-model` submodule
+  (bumped to e8d8005 on 2026-07-24, commit b6cb744) and runs the suite in
+  CI with an explicit exception ledger; `sync-streams.wast` is not on it.
+
+So the reference↔suite contradiction (CM-4) has no upstream detector: each
+CI is green against its own half.
+
+## The one true "scheduling accident" in the story
+
+Downstream only: the *semantics* (suite-pinned, wasmtime-implemented,
+deltic-implemented) **admit** same-instance task execution during a
+resolved task's mid-frame block; whether an admitted interleaving lands on
+a *colliding* point (polymorph-iroh's `RefCell` window, IROH-1) is a
+scheduler choice — deterministic per host, guaranteed by nothing. wasmtime's
+endpoint-matrix green and deltic's ~90% trap rate are the same semantics
+under different deterministic schedules.

exams/wasmtime-exclusivity/run.sh

@@ -0,0 +1,16 @@
+#!/usr/bin/env sh
+# Determinism check for wasmtime on the CM-4 arbiter (see RESULTS.md).
+# Requires a `wasmtime` new enough to parse the post-#655 suite syntax
+# (a 2026-08+ dev release works; the 47.0.1 release CLI does not).
+set -eu
+cd "$(dirname "$0")/../.."
+WAST=third_party/component-model/test/async/sync-streams.wast
+WASMTIME="${WASMTIME:-wasmtime}"
+"$WASMTIME" --version
+N="${N:-50}"
+i=1
+while [ "$i" -le "$N" ]; do
+  "$WASMTIME" wast -W component-model-async=y -W component-model-more-async-builtins=y "$WAST"
+  i=$((i + 1))
+done
+echo "$N/$N passes: deterministic"

upstream-component-model-repo-findings.md

@@ -212,6 +212,48 @@ Scope the reference's entry gate to the sync-call-in-progress span (release
 on resolution + block), or document the divergence and mark the suite test
 as the normative source.
 
+### 2026-08-09 review: not a recent-spec-change lag, and structurally invisible upstream
+
+Reviewed on operator prompt (3-month spec-history window + wasmtime CI
+provenance + determinism check; full transcripts in
+`exams/wasmtime-exclusivity/RESULTS.md`):
+
+- **Both sides are ancient.** The exclusivity model (`exclusive`, then
+  `exclusive_thread`) with the hold-for-the-activation lifetime dates to
+  ≥ 2025-08-20 (#553); `sync-streams.wast`'s contrary assertion dates to
+  the file's birth, 2025-09-05 (9b5aa62). The in-window commits — #650
+  (2026-05-21, `exclusive: Task` → `exclusive_thread: Thread` + the
+  entering-set reentrance definition) and #656 (2026-05-29, cooperative
+  thread built-ins) — refined granularity without touching the release
+  points. This is a ~11-month-old inconsistency, not wasmtime lagging a
+  recent change (nor the reverse).
+- **No CI cross-checks the two.** The spec repo's CI runs only
+  `run_tests.py` (definitions.py's own unit tests); the wast suite is
+  never executed against the reference. wasmtime runs the suite via a
+  `tests/component-model` submodule (currently e8d8005, bumped 2026-07-24)
+  with an explicit exception ledger for known misalignments (e.g.
+  `post-return.wast` pending #680 alignment) — `sync-streams.wast` is not
+  on it. So: wasmtime CI green, spec CI green, and the reference↔suite
+  contradiction has no detector by construction.
+- **wasmtime's pass is deterministic, not scheduling accident.**
+  Structurally: `$D.run` never yields between the first rendezvous and the
+  `$C.set` call, so the entry-gate check occurs at a fully deterministic
+  machine state — the STARTED-vs-gated outcome is a pure function of the
+  gating rule. Empirically: 50/50 identical passes under wasmtime
+  49.0.0-dev (3ebfbe5af, 2026-08-07) with
+  `-W component-model-async=y -W component-model-more-async-builtins=y`.
+  (Vintage note: the wasmtime 47.0.1 *release* CLI cannot even parse the
+  current suite text — its bundled wast crate predates the 2026-07 #655
+  syntax adherence pass — so any 47-era corroboration must use the crate
+  APIs or a dev build.)
+
+Net: the filing should present this as an internal spec-repo inconsistency
+(reference vs its own test corpus) that only external implementations can
+currently observe, propose the gate-scoping fix (or normative-source
+ruling), and suggest the structural fix — run the wast suite against the
+reference (or at least flag reference-affecting suite assertions) in the
+spec repo's own CI.
+
 ---
 
 ## NOTE-1: several official async tests assume the deterministic profile

upstream-consumer-findings.md

@@ -9,7 +9,7 @@ filing is the operator's (foreign repos).
 
 ---
 
-## IROH-1 — endpoint holds a `RefCell` borrow across a `block_on` yield (DRAFT)
+## IROH-1 — endpoint holds a `RefCell` borrow across a post-resolution `block_on` (DRAFT)
 
 **Repo:** polymorph-iroh. **Where:** `endpoint/src/endpoint_impl.rs:13`
 (claim: "the `RefCell` borrows never cross an await") vs the actual path:
@@ -21,9 +21,10 @@ State::drain()                      # under shared.borrow_mut()
       -> wit_bindgen::block_on(polymorph:webcrypto/signature#signing-key.sign)
 ```
 
-`block_on` on an async import is a yield point (callback-ABI activation
-returns to the host and resumes later), so other tasks run while the
-borrow is live. Every other endpoint task parks in `wait_until`
+`block_on` on an async import blocks the thread mid-frame (sync
+`waitable-set.wait` under the callback ABI); whether other same-instance
+tasks may run during that window is the load-bearing question — see the
+sharpened semantics below. Every other endpoint task parks in `wait_until`
 (`endpoint_impl.rs:939`) whose first act is `shared.borrow_mut()` →
 `RefCell already borrowed` → `unreachable` trap.
 
@@ -36,16 +37,45 @@ handshake. The 5 ms bounded-polling cadence (their jco workaround)
 re-arms `wait_until` on the same timescale as the signing window, making
 the collision near-certain on any host that interleaves there.
 
-**Why jco/wasmtime legs didn't surface it:** scheduling luck, not
-absence — holding a `RefCell` borrow across a yield is illegal on any
-conforming host. wasmtime's interleaving choices happen not to run the
-poller inside that window (their matrix row is green); deltic's
-do (see https://github.com/lann/deltic/issues/5 open question on the `bridge.ts` exclusivity
-divergence, which widens — but does not create — the window).
+**The precise semantics (sharpened 2026-08-09; see
+`upstream-component-model-repo-findings.md` CM-4 and
+`exams/wasmtime-exclusivity/RESULTS.md`):** the boundary is
+**resolution**.
+
+- *Before* `task.return`, a callback task's instance-entry gate holds
+  across mid-frame blocks on every implementation surveyed (deltic,
+  wasmtime, and `definitions.py` alike) — borrows held across a
+  pre-resolution `block_on` are safe.
+- *After* `task.return`, the semantics the official suite pins
+  (`test/async/sync-streams.wast:208` — the interloper task is admitted,
+  its body runs, and it touches shared instance memory while the resolved
+  task sits parked mid-frame; wasmtime runs this suite in CI via its
+  `tests/component-model` submodule and passes it **deterministically**,
+  50/50 measured on wasmtime 49.0.0-dev) **admit other same-instance
+  tasks running while the resolved task's thread is blocked mid-frame**.
+  wasmtime's own gate (`ConcurrentInstanceState.do_not_enter`) ends at
+  resolution. `definitions.py` as written disagrees (its
+  `exclusive_thread` is held for the whole activation) — that
+  contradiction is CM-4, a separate filing against the spec repo; the
+  suite + wasmtime are the operative semantics today, and deltic
+  implements them.
+
+The endpoint's pump does its `block_on(sign)` **after** `bind` resolved,
+inside that admitted window, with the `RefCell` borrow live.
+
+**Why the wasmtime leg is green anyway — deterministic schedule, not a
+guarantee:** wasmtime admits the same interleaving (its own suite asserts
+it); its particular deterministic scheduler simply never chooses the
+parked poller inside the signing window on this workload. deltic's
+deterministic scheduler does, ~90% of the time. Same semantics, different
+schedules — "works on wasmtime" is survivorship, and any scheduler change
+(wasmtime's included) can flip it.
 
 **Proposed fix (guest-side):** scope the borrow inside `drain`'s inner
 steps, or move signing out of the borrowed region (take what `sign`
-needs, release, sign, re-borrow).
+needs, release, sign, re-borrow). General rule: treat every
+**post-resolution** mid-frame block as a potential same-instance
+interleaving point.
 
 **Workaround in-tree:** the exam retries scenarios 2–4 (observed 8/20
 attempts trip it); residual all-attempts-fail probability < 1%.