chore(deps): bump mymindstorm/setup-emsdk from 14 to 16

[dependabot]

Bumps mymindstorm/setup-emsdk from 14 to 16.

Release notes

Sourced from mymindstorm/setup-emsdk's releases.

Version 16

This is really just a no-op release to test publishing from the new location.

What's Changed

• mymindstorm/setup-emsdk -> emscripten-core/setup-emsdk by @​mymindstorm in emscripten-core/setup-emsdk#55
• Rename master branch to main by @​sbc100 in emscripten-core/setup-emsdk#57
• Use latest versions of github checkout and cache actions by @​sbc100 in emscripten-core/setup-emsdk#58
• Update versions uses in README file by @​sbc100 in emscripten-core/setup-emsdk#59

New Contributors

• @​sbc100 made their first contribution in emscripten-core/setup-emsdk#57

Full Changelog: emscripten-core/setup-emsdk@v15...v16

Version 15

What's Changed

• Updated all dependencies to their latest versions to fix breaking changes in actions/cache and the node runtime mymindstorm/setup-emsdk#48
• Added option to set emsdk version separately from emscripten version mymindstorm/setup-emsdk#54

Contributors

• @​agriyakhetarpal
• @​Danil42Russia
• @​slowriot
• @​OlegRa

Full Changelog: emscripten-core/setup-emsdk@v14...v15

Commits

• 4528d10 Update versions uses in README file (#59)
• f77ca22 Use latest versions of github checkout and cache actions (#58)
• fcab056 Rename master branch to main (#57)
• 81fcc1f mymindstorm/setup-emsdk -> emscripten-core/setup-emsdk (#55)
• eaddcae Update copyright year and holder in LICENSE file
• 667eb33 Add option to set emsdk version separately from emscripten version (#54)
• da8e6ae Fix breaking issues with action
• See full diff in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[dependabot]

Labels

The following labels could not be found: github-actions. Please create it before Dependabot can add it to a pull request.

Please fix the above issues or remove invalid values from dependabot.yml.

[srpatcha]

Approving. Target version verified to exist and be current, and the failing CI
here is not caused by this bump.

I checked every target in this batch against the upstream release list rather
than assuming Dependabot picked a real tag:

mymindstorm/setup-emsdk   v16   latest v16        exists
actions/setup-java        v6    latest v6.0.0     exists
pnpm/action-setup         v6    latest v6.0.10    exists
actions/checkout          v7    latest v7.0.1     exists

All current majors.

The red CI is not yours

Every job in this run fails with:

apps/epdf/epdf.h:5:10: fatal error: eapps_core.h: No such file or directory

master does not build, and has not for a while — 48 fatal errors from a clean
clone. The cause is .gitignore:61, a bare core rule intended for Unix core
dumps, which matches any file or directory named core at any depth and
therefore excluded core/, the source tree. core/common/include/eapps_core.h
is included by all 44 app targets and was never committed:

$ git ls-files | grep -c eapps_core.h
0

#42 fixes that. Once it lands, re-run these and the result will mean something.
Merging this before #42 is harmless — it cannot make a build that already fails
fail differently — but the check will stay red until #42 is in.

Worth noting for whoever triages these: a major-version bump of a GitHub Action
can carry breaking changes, and the usual way to find out is CI. That signal is
currently unavailable in this repository for reasons unrelated to any of these
four PRs, so approval here rests on the version existing and the diff being a
pure version string change — not on a green run.

[srpatcha]

Review — eApps#38 "chore(deps): bump mymindstorm/setup-emsdk from 14 to 16"

head: e316ddb author: app/dependabot ci: fail (11 of 11 jobs) — pre-existing on master, see below

Verdict: The bump is worth taking — v15 exists specifically to repair v14 against the current actions/cache service and Node runtime — but it should point at the action's new home, and it lands with no check able to exercise it: the one PR-gating job that uses emsdk is in a workflow that never runs on this repository's default branch, so the first automatic execution of @v16 is a nightly, and the first on the release path is a release.

Findings

#	Severity	File:line	Finding	Recommended fix
1	Medium	all 7 call sites (build-desktop.yml:306, ci-native.yml:63, nightly.yml:102, release-native.yml:218, release.yml:89, stable-release.yml:271, weekly.yml:116)	The action has moved repositories and this PR pins the old path. Verified: gh api repos/mymindstorm/setup-emsdk returns full_name=emscripten-core/setup-emsdk — the request is redirected — and v16's own release notes say it "is really just a no-op release to test publishing from the new location", listing mymindstorm/setup-emsdk -> emscripten-core/setup-emsdk. It works today only because GitHub keeps the redirect alive; Dependabot will keep watching the retired path, and provenance auditing of a redirected uses: is exactly the kind of indirection .github/STANDARDS.md cites OpenSSF Scorecard to remove. grep -rn emscripten-core/setup-emsdk eApps/ returns nothing, so no call site has been migrated yet.	Change the seven references to emscripten-core/setup-emsdk@v16, and update .github/dependabot.yml so future bumps track the new repository. Same diff size as the current one.
2	Medium	.github/workflows/ci-native.yml:3-4, :11-12	The emsdk step in the only PR-gating workflow is unreachable. ci-native.yml triggers on push: branches: [main] and pull_request: branches: [main], and this repository's default branch is master (verified: gh api repos/embeddedos-org/eApps --jq .default_branch → master; .github/STANDARDS.md "Release model" mandates master + release and defines no main). Its build-web job (:57-67) is the only WASM build in a PR-triggered workflow, and it has never run. Consequence for this PR, from reading the on: block of all seven edited files: nightly.yml and weekly.yml are schedule-driven and will pick the bump up; build-desktop.yml fires on tags, release.yml on tags, release-native.yml and stable-release.yml on manual dispatch or a published release. So four of the seven call sites first execute @v16 on a release path, and the lane that should have de-risked that is dead.	Change ci-native.yml's two branches: lists to [master] — ci.yml:7-9 already gets this right with [main, master, develop] / [main, master]. No open PR covers this in eApps (checked #38–#41), unlike the equivalent fix in eAI (#39) and the fix/ci-runs-on-master branches in eBrowser, eDB, eIPC, eNI and eOffice. It is a separate change from a version bump and should land on its own, because it alters what gates every PR in the repository.
3	Medium	ci-native.yml:63, nightly.yml:102, build-desktop.yml:306 vs release.yml:90-91, release-native.yml:219-220, stable-release.yml:272-273, weekly.yml:117-118	Emscripten version skew between the testing and release lanes. Three call sites pass no version: input at all and therefore take whatever emsdk is latest at run time; four pin version: "3.1.51". So the WASM artifacts that ship are built by a pinned toolchain that CI never exercises, and the WASM builds CI does run use a toolchain that never ships. §9.2 requires "reproducible lockfiles/manifests for production builds" and §3 records the Yocto lesson as "deterministic builds". This is pre-existing, but v15 added the ability to set the emsdk version separately from the emscripten version, so a v14 → v16 bump is precisely when the version: input's meaning should be re-read.	Pin all seven call sites to the same emscripten version from one place — a repository variable or a .emscripten-version file — so the release toolchain is the tested toolchain. Not this PR's job, but it is the reason the bump is hard to validate.

CI state

All 11 required checks are red, and none of it is this PR's doing. Verified:

• The 11 failing jobs on this PR (Native (ubuntu/windows/macos), Category (web/media/games/security/productivity/connectivity), Sanitizers, JS/TS lane) all belong to ci.yml, which does not use setup-emsdk anywhere. The bump cannot reach them.
• Master run 32813232464 (2026-08-25, six days before this PR was opened) failed on the identical 11 jobs at the identical 11 steps. This is the pre-existing state of the branch point, not a regression.
• Master has since partly recovered: run 33501131456 (2026-09-01) fails on only 2 jobs — Native (windows-latest) :: Build and JS/TS lane :: desktop-apps lint+build.

So rebasing this branch onto current master should take it from 11 red checks to 2, which is worth doing before anyone tries to interpret the result. It still will not exercise the bump — see finding 2.

Architecture conformance

Conforms. §21 places CI configuration in the Infrastructure tier; an action version is build-time only, never a runtime dependency, so §5.1's law is untouched and nothing in eApps' Tier-4/Tier-5 code changes. §20.1 is worth noting for context: eBrowser — whose WASM build these emsdk steps produce (build-desktop.yml:309, desktop-apps/ebrowser) — is a reference application proving platform capability, not a peer pillar, so a broken WASM lane is not a Tier-1 emergency. But §11.1 makes .eapp a first-class artifact type and §23.2 makes the package format a versioned contract, and finding 3 is where those bite: an artifact built by an unpinned toolchain has no reproducible provenance to version.

Proposed changes

In order, smallest first:

1. Retarget the seven uses: lines at emscripten-core/setup-emsdk@v16 and update .github/dependabot.yml (finding 1). This PR, same size.
2. Rebase onto current master so the check results mean something.
3. Separately: fix ci-native.yml's branch filters (finding 2). This is the change that makes every future emsdk, CMake or WASM change reviewable, and it is currently missing from eApps while five sibling repositories already have it in flight.
4. Separately: unify the emscripten version across all seven call sites (finding 3).

No fix PR opened. Finding 1 is a one-line-per-file edit but belongs in this PR rather than a competing one; findings 2 and 3 are Medium and change CI policy rather than repair a mechanical defect, which is outside what an unattended fix PR should carry.

Verification I ran

• Upstream release notes for both majors crossed. v15 (2026-04-05): "Updated all dependencies to their latest versions to fix breaking changes in actions/cache and the node runtime", plus "Added option to set emsdk version separately from emscripten version". That first line is the affirmative case for this PR — @v14 (2024-01-22) predates the cache-service and Node-runtime changes and is the version most likely to be quietly failing. v16 (2026-04-08): a no-op release marking the repository transfer.
• Repository transfer, finding 1: gh api repos/mymindstorm/setup-emsdk --jq .full_name → emscripten-core/setup-emsdk. gh api repos/emscripten-core/setup-emsdk/releases lists v16 (2026-04-08), v15 (2026-04-05), v14 (2024-01-22) — the same tags, from the new home.
• All seven call sites read, with their inputs, which is how findings 1 and 3 were established. The change is mechanically complete: no setup-emsdk@v14 remains.
• Trigger reachability of each edited file, read from its on: block: ci-native → branches: [main] only (dead); nightly, weekly → schedule + workflow_dispatch; build-desktop, release → tags; release-native → dispatch; stable-release → dispatch + release. Default branch confirmed as master via the API.
• CI attribution, as set out above: job-to-workflow mapping from ci.yml:20-95 (Native (…), Category (…), Sanitizers, JS/TS lane), and the master-run comparison via gh run view.
• Runner floor for the Node runtime change is satisfied: every runs-on: in eApps is a GitHub-hosted label (ubuntu-latest, windows-latest, macos-latest, or a matrix of those). No self-hosted runner needs upgrading first.

Not checked

• The bump in action. No check on this PR runs setup-emsdk (finding 2), and I did not dispatch nightly.yml or weekly.yml by hand. I have not observed @v16 install an SDK in this repository; the case for it rests on the v15 changelog, not an execution.
• Whether the WASM builds pass at all, at any version. ci-native.yml's build-web job has apparently never run (finding 2), so there is no baseline for @v14 either. Whether @v16 improves, breaks or leaves unchanged a job nobody has seen is Unknown, and that is the honest state of this bump.
• Whether emsdk 3.1.51 still installs under @v16. The four pinned call sites request a version from late 2023 through an action whose dependency stack was replaced in v15. I did not test that combination; it is the most likely place for this bump to bite, and it will bite during a release (finding 2).
• The root cause of the 11 pre-existing failures. I established that they pre-date this PR and are unreachable from it; I did not read the build logs or diagnose them. That belongs to whoever owns master.
• .github/dependabot.yml. I recommend updating it in finding 1 without having read it — I inferred its existence from the five dependabot PRs in flight and from the "labels could not be found: github-actions" comment dependabot left on each of them. Confirm the file's actual contents before editing.
• SHA pinning. Not changed here and not proposed; raised only as context for the Scorecard claim in STANDARDS.md.

---

Automated architecture review of e316ddb50517 — scheduled, model claude-opus-5, checked against the EmbeddedOS Master Design v2.0. Advisory only: this reviewer never approves, requests changes, or merges. Reply here to discuss or push back — a wrong finding is a bug worth reporting.