The MSYS2 package: a real Windows lore scenario — user-space GNU Make on ARM64 #599

Feature (USER scenario, 2026-08-21; parked — chartered now, worked later). A devlore package, authored
as a lore scenario, that bootstraps a portable MSYS2 environment on Windows ARM64 into ~/.local/opt/MSYS2,
installs the native Clang ARM64 GNU Make (mingw-w64-clang-aarch64-make), and exposes make from
~/.local/bin — no admin, no registry, no C:\ pollution. The flagship pairing with #598: that chore
cross-compiles our binaries for Windows; this package delivers GNU Make to Windows, closing the
"no common tools" gap from the other side.

Source spec (Gemini-generated, reviewed and corrected)

1. Directories: ensure ~/.local/opt/MSYS2/ and ~/.local/bin/.
2. Acquire base (idempotent — skip when msys2_shell.cmd already present): download
   https://repo.msys2.org/distrib/msys2-base-aarch64-latest.sfx.exe (the original instruction's URL was
   markdown-mangled; this is the clean form), extract into ~/.local/opt/ mapping the archive's root folder
   to MSYS2/ (verify at build: the amd64 SFX extracts to msys64/; the aarch64 layout's folder name
   is asserted, not confirmed), remove the installer.
3. Toolchain: initialize and update via pacman, then install mingw-w64-clang-aarch64-make.
   Correction: a single pacman -Syu --noconfirm is not sufficient — MSYS2's core update can terminate
   the shell mid-transaction; the automation pattern is two passes (core, then full) with the first pass's
   exit tolerated. Keyring init is automatic on modern base archives; do not script pacman-key blindly.
4. Expose make: the installed binary is ~/.local/opt/MSYS2/clangarm64/bin/mingw32-make.exe.
   Correction — symlinks are the wrong default on Windows (the The store writes latest.yaml as a symlink an ordinary Windows user cannot create #438 class: ordinary users cannot create
   them). Candidates, to be ruled at build time: NTFS hardlink (same volume, unprivileged, no DLL
   concern — likely winner), a make.cmd shim, or copy (the spec's own verification criterion — "no
   missing-DLL errors" — exists because copying a mingw binary out of its bin tree risks exactly that).
   PATH activation of ~/.local/bin belongs to writ's dotfiles layer, not this package.
5. Verification: make --version from a standard shell prints GNU Make's version, native ARM64.

Provider mapping (surveyed 2026-08-21 — every step has a home)

appnet.download (acquire) · archive.extract/extract_stream (payload; whether the 7z-SFX reads
directly or runs via shell is a build-time call) · flow.choose (idempotency probes) · shell.exec /
powershell.exec (pacman passes) · file.mkdir / file.link (dirs; link ruling above) · pkg.install
exists but pacman is not a platform manager — raw shell now, with an option worth weighing then: register
MSYS2/pacman as a platform package manager (3.4's Composite router), making step 3 a first-class
pkg.install.

Constraints and blockers

• Home-scope only (~/.local/*) — runs on today's single-root model; no Design: the RuntimeEnvironment holds a named set of roots — (root-name, rel) identity #597 dependency.
• ARM64 target: CI runners are amd64 — CI can plan and dry-run the graph; execution verifies on the
  Parallels VM (Windows-on-ARM). Fits the judgment-scenario pattern: predictions first, VM run as evidence.
• Blocked by Epic: lore packaging and the registry #446's FalseSuccess lifecycle commands (prepare/install/provision/verify must be honest
  before a package can claim this scenario end-to-end).
• Author after Identity is rel: git-model plan-space paths; migrate the authoring surfaces #584 PR 2 (the plan-space path grammar) so the package's paths are born in the ruled
  little language rather than migrated.

Relations

#598 (the complementary chore) · #446 (packaging machinery this consumes) · #438 (the symlink class the
link step must respect) · #542 sits adjacent — a new Windows machine acquiring its toolchain in user-space
is a "new hire, day one" beat, and this scenario can feed that demo.

Epic: #539