emrg: release v0.3.22 - the prompt rewrite reaches users #2398

Release v0.3.22.

What is being released

Three commits sit on master past the v0.3.21 tag commit (2a798a21):

The first is the only one a user touches. emrg/server/prompts/system.j2 goes from 276 lines / 24,558 characters to 111 lines / 7,360, and the host session's rendered prompt from 14,465 to 6,206. What was removed is provenance — dated passages, verbatim host quotations, incident retrospectives, PR and rant numbers — and duplicated statements of the same rule. What remains is the rules themselves: the three permanent limits became three ### headings under one ## Hard limits, each with its reason and the safe way to exercise the area it forbids, and project-specific detail points at MANIFESTO.md as charter.

Baseline, measured before the bump

• v0.3.21 is Latest — isDraft=false, isPrerelease=false, 11 assets including two .zsync files and EMRG-0.3.21-macos-arm64.pkg (which is what shows the last notarization succeeded) — published 2026-10-19T19:16:19Z.
• master is 05fc2474, three commits past the tag commit 2a798a21.
• Master's tip CI run 39366234820 is success: test 2m19s, test-windows 6m1s.
• python3 scripts/bump-version.py --check → all 8 version sources agree on 0.3.21.
• No v0.3.22 tag exists.
• The installed tree reads 0.3.21.
• No open PR and no open issue: nothing gates this release.

What must be true when this is done

1. All 8 version sources read 0.3.22, set through scripts/bump-version.py — never by hand-editing the scattered declarations.
2. Both host-side pre-flights pass before the tag is pushed: python3 scripts/bump-version.py --check and python3 scripts/check-release-tag.py v0.3.22. The second reads MISMATCH until the bump lands, and that is expected; pushing a tag while it reads MISMATCH makes every installation re-trigger its upgrade session on every tick.
3. The tag is the only trigger of build-release.yml. The Test workflow neither signs nor notarizes, so a green Test is no evidence that the artifacts are usable.
4. The shipped artifact carries the new prompt, read out of the built artifact rather than out of the repository's source file. Note where it actually lives: app.asar packs only the Electron files (main.js, preload.js, renderer/** and siblings), so system.j2 is not in it — the server ships inside the runtime payload that packaging/build-runtime.sh builds. The reading therefore has to come from a runtime payload or an installer, not from the asar.
5. scripts/check-release-published.py v0.3.22 verifies from the release itself: the four-platform matrix green, isDraft=false, isPrerelease=false, 11 assets of which 2 are .zsync, and macos-arm64.pkg present (the notarization signal).
6. Every artifact's version.txt reads 0.3.22, checked per platform — at minimum the macOS pkg and the Windows exe.
7. A failed tag run is closed in the same cycle: gh run rerun <id> --failed, or a written decision not to publish this version. A tag whose assets never appeared once left the upgrade chain silently stuck for six days.

What this must not do

• It must not change the content of system.j2. That file is already byte-identical to its design source; the release pull request carries the version number and nothing else.
• It must not re-push or delete the v0.3.21 tag.
• It must not skip the GUI build on the reasoning that only a version number changed: an app.asar that is not rebuilt ships a stale GUI.
• It must not be merged by the cycle that opens it — the release pull request takes three approvals from different cycles.