feat: add Stack-chan WASM build support - #446

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

.github/workflows/build.yml (1)

64-67: ⚡ Quick win

Align SDK pinning with setup action input for deterministic caching.

Line 64-67 pins a SHA after setup, but setup/cache-key resolution still follows its default ref path. Pass the same SHA via target-branch so install + cache + build all use one source of truth.

Proposed change

-      - uses: ./.github/actions/setup
-      - name: Pin Moddable SDK
-        run: |
-          git -C "$HOME/.local/share/moddable" fetch origin b0411457e4577ea5560c780cb7824f3b00c2b2af
-          git -C "$HOME/.local/share/moddable" checkout --detach FETCH_HEAD
+      - uses: ./.github/actions/setup
+        with:
+          target-branch: b0411457e4577ea5560c780cb7824f3b00c2b2af

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.github/workflows/build.yml around lines 64 - 67, The workflow currently
pins the Moddable SDK by checking out a SHA in the "Pin Moddable SDK" step but
does not pass that SHA to the earlier setup action; update the setup/install
step for the Moddable SDK to receive the same SHA via the target-branch input so
install, cache-key resolution, and the later checkout use the same ref; locate
the setup action step (the Moddable SDK setup or install step) and add
target-branch: "<the same SHA currently used in the Pin Moddable SDK step>" so
the cache and build are deterministic.

firmware/stackchan/drivers/wasm/wasm-driver.ts (1)

28-31: ⚡ Quick win

Consider validating the rotation parameter structure.

The applyRotation method accepts a rotation parameter but does not validate that it contains valid numeric y, p, and r properties. If called with malformed data (e.g., missing fields, non-numeric values), the spread operation on line 29 would silently accept invalid state, and the host bridge might receive unexpected data.

🛡️ Proposed validation guard

 async applyRotation(rotation: Rotation, time?: number): Promise<void> {
+  if (typeof rotation.y !== 'number' || typeof rotation.p !== 'number' || typeof rotation.r !== 'number') {
+    throw new TypeError('Invalid rotation: y, p, r must be numbers')
+  }
   this.#rotation = { ...rotation }
   globalThis.Host?.Driver?.applyRotation?.({ rotation, time })
 }

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@firmware/stackchan/drivers/wasm/wasm-driver.ts` around lines 28 - 31, The
applyRotation method currently assigns and forwards whatever is passed, risking
invalid state; add a validation guard inside applyRotation to ensure the
rotation object has numeric y, p, and r properties (e.g., Number.isFinite
checks) before setting this.#rotation and calling
globalThis.Host?.Driver?.applyRotation; if validation fails, do not mutate
this.#rotation and either throw or log an error (use existing logging pattern)
so malformed inputs are rejected and the host bridge never receives invalid
data.