Estate-wide re-validation of the #199/#205 closure ABI (was static-only until #225 PR2 ran it in a real wasm engine)

[hyperpolymath]

Problem

#225 PR2 surfaced that the #199 closure ABI / #205 Thenable path had never been executed in a real WebAssembly engine anywhere in the estate. PR1's skeleton was pure pass-through (no closure dispatch); PR2's continuation is the first true end-to-end exercise, and it immediately surfaced two latent defects that static verification had never caught:

• the module never exported __indirect_function_table (host dispatch impossible);
• closure_code used LocalTee where the surrounding code assumes LocalSet, leaving a 2-value stack imbalance (invalid wasm).

Both are fixed in PR #233. But the implication is estate-wide: every downstream consumer that "dogfooded" the #199/#205 surface (e.g. standards#123 rsr-certifier extension, idaptik, boj-server bridges) was static-only — compiled, never run in a wasm host. Their runtime correctness is unverified.

Proposed work

1. A minimal tests/codegen regression that exercises the Deno source-to-source host→guest callback ABI (blocks withProgress/registerCommand/onDidSave) #199 closure dispatch independent of the async transform (a plain captured-closure call through __indirect_function_table), so the shared path is protected for all closure users.
2. An audit pass: enumerate estate consumers of the Deno source-to-source host→guest callback ABI (blocks withProgress/registerCommand/onDidSave) #199/Wasm-path thenable-resolution: guest consuming a host Thenable result (blocks #103 pilot data path) #205 surface and add a real wasm-host smoke per consumer (or document why static is acceptable there).

Surfaced by #225 PR2. Refs #225, #199, #205.

[hyperpolymath]

Deliverable (1) shipped (PR #279): tests/codegen/closure_indirect_dispatch.{affine,mjs} — the #199 [fnId@0,envPtr@4] closure ABI is now engine-validated via the exported __indirect_function_table with no async/CPS transform involved (imports only env.invokeCallback, no thenableThen). This is the negative-control the http_cps_* tests cannot isolate; it protects the shared closure path for every consumer independent of #205. Full wasm harness + dune test --force 290 green.

Deliverable (2) — estate-consumer audit:

Consumer	Uses	Runtime-smoke needed?
rsr-certifier (standards#123, satellites/rsr-certifier/extensions/vscode/src/extension.affine)	full #199 closures + #205 httpPostJson/thenableThen/thenableResultJson/jsonField; ships its own wrapHandler clone (src/affine-vscode-adapter.cjs); zero wasm tests	YES — genuinely needs one (the only materially-exposed consumer; this is exactly the static-only blind spot that hid the PR2 defects)
my-lang (vscode-extension/src/extension.affine)	#199 registerCommand closures only, no #205	No — covered upstream by (1)
idaptik / reposystem	.ts generic vscode registerCommand — not the AffineScript wasm ABI	N/A
boj-server / gitbot-fleet	no .affine consumer (boj-server is the HTTP peer of httpPostJson)	N/A

Remaining tracked item: a runtime smoke for rsr-certifier in the standards repo (cross-repo; the ABI it depends on is now upstream-guaranteed by (1), so this is hardening, not a correctness gap). Leaving #235 open for that.

[hyperpolymath]

Status refresh (2026-05-30):

The original "surfaced by #225 PR2 → static-only until real-wasm-engine validation" framing is partly resolved: fix PR #233 merged 2026-05-19 with real-wasm-engine exercise of the #199/#205 closure ABI.

Remaining work on this issue:

• Estate-wide re-validation pass (run the validation rig against every .affine fixture across the estate, not just the one in stdlib Http: typed-wasm target (convergence ABI; shared with Ephapax) #225).
• Regression test capturing the failure mode that drove feat(codegen): #225 PR2 — WasmGC CPS transform, Async base case (ADR-013) #233.

Title could be re-scoped to Estate audit + regression test for #199/#205 closure ABI (post-#233) if that's clearer.

[hyperpolymath]

Re-measured the estate-wide half today (2026-09-19) — the language-side exercise is in place; the consumer side has no evidence, so this issue is currently the only tracker for it.

The thread's 2026-05-30 refresh records that #233 merged with real-wasm-engine exercise of the #199/#205 closure ABI, leaving "estate-wide re-validation" as the remaining work. Where that stands now:

Repo	files referencing the closure ABI / indirect function table
affinescript	14 — including tests/codegen/closure_indirect_dispatch.affine and lib/codegen.ml
typed-wasm	1 — spec/async-convergence-abi.adoc (spec text, not an executable exercise)
boj-server	0

So the producer side is exercised end-to-end, and I can find no consumer repo that runs the closure ABI through a real engine — typed-wasm carries only the spec. That matches the issue's own framing: it exists precisely because static verification missed two latent defects, and it is the only artifact tracking that consumers have not re-run since.

Suggested action to make it closable: convert it to an explicit per-consumer checklist (which repos consume the closure ABI, each with its own real-engine exercise), then close when the checklist is green. As written it cannot be finished, because "estate-wide" has no denominator.