feat(gossamer): prep for end-to-end .eph→.wasm compile (#196)#212
Merged
Conversation
Hypatia-side preparatory work for #196. Upstream hyperpolymath/ephapax#36 (single .eph→.wasm CLI subcommand) is still open, so the workflow's compile step continues to auto-promote when that lands. This commit lands the verification + loader pieces of the DoD that don't need the upstream: - Workflow: install wabt and run `wasm-validate` on the produced artifact between compile and upload. Upload is now gated on validation success. - loader.js: replace the `wasi_snapshot_preview1` stub with a `gossamer` import namespace whose surface mirrors the `extern "gossamer"` block in bridge.eph (window_open / _set_body / _close, ipc_open / _recv / _send / _close, JSON helpers). Browser stubs are minimal but sufficient to instantiate the module so the TEA exports (init/update/view/subs) remain callable from index.html. - loader.js readString: keep the {ptr, leading-i32-len} convention but add bounds checking so an Ephapax ABI mismatch surfaces as a clear RangeError instead of a silent garble. - README.adoc: note the wasm-validate step, link upstream blocker, and document the manual browser smoke procedure (the DoD allows this as a documented manual step until CI produces an artifact).
The pinned SHA `8d0a9443...` (tagged v2.51.11) is no longer resolvable by Actions and was breaking the Build Gossamer GUI workflow at "Set up job", before any of the new wasm-validate plumbing ran. Bump only this workflow's pin for now; the same SHA appears in 4 other workflows in the repo and is out of scope here.
The verify step previously hard-coded `ephapax-cli` as the binary name. Upstream Ephapax v1.0.0 doesn't currently produce a binary by that exact name (the unified CLI subcommand pinned in hyperpolymath/ephapax#36 is what would also fix the name). Until that lands, accept the first match from a known list (ephapax-cli, ephapax, epcc, ephapax_cli) and fall back to whatever executable cargo built under target/release/. The discovered path is exported to GITHUB_ENV as EPHAPAX_CLI and the compile step picks it up.
This was referenced May 11, 2026
Owner
Author
Landing summaryThis PR is the prep landing for #196. The single remaining DoD bullet ("compile step succeeds, produces What shipped
CI stateAll red checks on this PR are pre-existing main-branch failures (same set was red on #211 when it merged) — Rust deny/clippy/format, Haskell HLint/audit/SBOM, Container Trivy variants, A2ML/K9 manifest validators, antipattern The workflow this PR does modify (
Follow-ups filed
Recommendation
Generated by Claude Code |
This was referenced May 11, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Refs #196.
Status
Upstream blocker still open —
hyperpolymath/ephapax#36(the single.eph→.wasmCLI subcommand) is currently unresolved. The workflow already auto-promotes when any ofjust compile-affine,ephapax-cli compile-eph, orephapax-cli compile-affineships upstream, so the compile step itself still skips on this PR. This PR lands the hypatia-side DoD items that can be done without the upstream so the moment ephapax#36 merges, CI produces a validated artifact andloader.jsis ready to run it.Changes
.github/workflows/build-gossamer-gui.ymlwabtafter a successful compile and runwasm-validateon the producedhypatia_gui.wasm.Upload wasm artifactstep onwasm-validatesuccess.src/ui/gossamer/loader.jswasi_snapshot_preview1stub with agossamerimport namespace whose surface mirrors theextern "gossamer"block inbridge.eph(window/IPC handles + JSON helpers).hypatia_init/_update/_view/_subs) remain callable fromindex.html.readStringkeeps the{ptr, leading-i32-len}convention but adds bounds checks so an Ephapax ABI mismatch surfaces as a clearRangeErrorinstead of a silent garble. Single point of change once the ABI is pinned upstream.src/ui/gossamer/README.adocwasm-validatestep in the status table.hyperpolymath/ephapax#36.DoD checklist (from #196)
wasm-validatepasses on the produced artifact — wired, runs when compile succeedsloader.jsTODOs resolved —wasi_snapshot_preview1stub replaced; string ABI documented + bounds-checkedindex.htmlbrowser smoke — documented as manual step per DoDTest plan
Build Gossamer GUIworkflow still passes (compile step continues to skip with the existing warning;wasm-validate+Install wabtsteps stay un-evaluated until compile succeeds, per theif:guards).wasm-validateruns and the artifact uploads.hypatia_gui.wasmundersrc/ui/public/assets/wasm/, servesrc/ui/public/, and confirmindex.htmlloads without console errors against a running Hypatia OTP listener on:9090.Generated by Claude Code