fix(meta-13010): rebuild sequent-core wasm so main ships #12975's fix

[vic3lord]

Closes sequentech/meta#13010. Unblocks CI on every open step PR.

This is not a stale lockfile

The obvious reading of the red checks is that packages/yarn.lock drifted. It's the other way round.

adc226f changed packages/sequent-core/src/util/voting_screen.rs and updated the lockfile to the hash of the rebuilt package — but did not commit the rebuilt tgz:

 packages/sequent-core/src/util/voting_screen.rs | 4 +++-
packages/yarn.lock | 6 +++---

So the four committed tgz copies stayed at cd416dc's build:

committed tgz (all 4): 9965f4fca902ff88492a298e67bddf8ba639fea0
packages/yarn.lock: f1b9927da27e25fc6d6d490e603ac07bc640d991

The pair had matched on 11 consecutive commits before that:

BROKEN adc226f tgz=9965f4fc lock=f1b9927d 2026-08-24 Voting Portal: Prevent advancing fr
OK cd416dc tgz=9965f4fc lock=9965f4fc 2026-08-23 Keycloak - Login and Registration t
OK a4eba05 tgz=4ff8b556 lock=4ff8b556 2026-08-22 Admin Portal: Configurable layout a
...

Why the easy fix would have been the wrong one

Setting the lockfile back to 9965f4fc turns both checks green in one line. It also leaves this out of what voters load:

}else{
- false
+ // An incomplete validation map is not proof that the contest is
+ // valid. Fail closed until its decoded state is available.
+ true}

check_voting_not_allowed_next_util is reachable from the browser — sequent-core/src/wasm/wasm.rs:929 exports it via #[wasm_bindgen], ui-core/src/services/wasm.ts wraps it, voting-portal/src/routes/VotingScreen.tsx calls it. The frontends consume sequent-core from the committed tgz, so #12975's guard has been fixed in source and merged but absent from the shipped artifact since 24 August.

How it was rebuilt

.devcontainer/scripts/build-sequent-core.sh, with only its hardcoded /workspaces/stepTARGET_DIR changed. Same wasm-pack build --mode no-install --out-name index --release --target web --features=wasmtest,default_features, same wasm-pack pack, same awk lockfile rewrite driven by the shasum: line, same copy to all four rust/ directories.

Toolchain matches flake.nix on both versions it pins:

	flake.nix	used here
rustc	1.96.0	1.96.0
wasm-bindgen	0.2.104	0.2.104
wasm-pack	nixpkgs	0.15.0 (crates.io)
wasm-opt	nixpkgs binaryen	132 (homebrew)

Installed via rustup rather than nix, so wasm-pack and wasm-opt are not the flake-pinned builds. Worth a reviewer's attention, though the resulting hash was never going to be f1b9927d regardless — the workflow already documents this build as environment-dependent:

Note: Commented out because this doesn't work, probably because the paths in the devcontainer and the GitHub Action runner are different, so the hash of the built package doesn't match the hash in yarn.lock.

and its check compares committed tgz against committed lockfile, not against a fresh build. If you'd rather the artifact came from the devcontainer, this PR is still the right diff — just rebuild and force-push over it.

Verification

All four tgz identical, and the workflow's own comparison run verbatim:

Hashes: |1c9e1d19...| |1c9e1d19...| |1c9e1d19...| |1c9e1d19...|
PASS: the hashes are equal

The wasm inside the committed tgz is byte-identical to a build from the fixed source (40ca56c9).

And to show the artifact carries the change rather than merely being newer — reverting the two-line fix and rebuilding produces a different wasm:

wasm from FIXED source (committed): 40ca56c9d259657ba63114a821400166a5717f8d
wasm from REVERTED source: d48b95da1d8146422f92c05359a8f036e6149db1

The lockfile diff is exactly three resolved fragments and nothing else; the tarball file list is unchanged.

Follow-up

meta#13010 also notes the gap that let this through: the build_wasm check verifies the lockfile describes the tgz in the tree, not that the tgz was built from the tree's sources. A commit touching sequent-core sources and neither of those two files would go green with a silently stale artifact. Re-enabling the disabled "compare against a fresh build" step is what closes it.

🤖 Generated with Claude Code

[Copilot]

Copilot wasn't able to review any files in this pull request.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[coderabbitai]

Important

Review skipped

Review was skipped as selected files did not have any reviewable changes.

💤 Files selected but had no reviewable changes (4)

• packages/admin-portal/rust/sequent-core-0.1.0.tgz
• packages/ballot-verifier/rust/sequent-core-0.1.0.tgz
• packages/ui-core/rust/sequent-core-0.1.0.tgz
• packages/voting-portal/rust/sequent-core-0.1.0.tgz

⛔ Files ignored due to path filters (1)

• packages/yarn.lock is excluded by !**/yarn.lock, !**/*.lock

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 39391a74-ad94-4967-bc69-0874722ad821

📥 Commits

Reviewing files that changed from the base of the PR and between adc226f and 17442f4.

⛔ Files ignored due to path filters (1)

• packages/yarn.lock is excluded by !**/yarn.lock, !**/*.lock

📒 Files selected for processing (4)

• packages/admin-portal/rust/sequent-core-0.1.0.tgz
• packages/ballot-verifier/rust/sequent-core-0.1.0.tgz
• packages/ui-core/rust/sequent-core-0.1.0.tgz
• packages/voting-portal/rust/sequent-core-0.1.0.tgz

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

_{Comment @coderabbitai help to get the list of available commands.}