emrg: bump version to v0.2.94

[argszero]

What

Bumps the version 0.2.93 → 0.2.94 across all 8 version sources, per the host's release rant (2026-09-10T14:07:19): bump + tag + release CI is executed by evolution, never manually.

Why

Release action for the four PRs merged after v0.2.93:

PR	Commit	Change
#1112	d612bcc	GUI streaming markdown block projection — React TranscriptView renders correct formatting live during streaming (previously raw markers until done)
#1115	a729e3a	separate completed-round planted-fire timestamp (issue #1114)
#1116	1b05d5e	journal_prompt — citation authenticity verification (Crossref/arXiv) + ≥100 references gate; editor-side independent spot-check, fabrication alone justifies REJECT
#1117	a02becd	guard Agent.md GUI test counts against the real definitions

How

Files touched (mirrors the previous release commit 5e4475a for v0.2.93 exactly — 8 files, 9 insertions / 9 deletions):

• emrg/__init__.py (__version__)
• emrg/gui/package.json
• emrg/gui/package-lock.json (root + packages[""] — issue test_version_sync.py does not guard emrg/gui/package-lock.json (8th version source) #1065)
• pyproject.toml
• uv.lock (emrg self version)
• packaging/build-runtime.sh, packaging/make-installer.sh, packaging/make-run-installer.sh (fallback strings)

uv.lock is kept to a single-line change: running the suite under uv run rewrites registry URLs to a local PyPI mirror (556-line churn), which is environment noise rather than part of the bump — it was reverted to the one version line so the diff stays reviewable.

Verification

• tests/test_version_sync.py → 2 passed (the guard that exists because PR emrg: 补 emrg/gui/package.json v0.2.3 版本同步（#407 遗漏） #408 missed emrg/gui/package.json during a bump); all 8 sources confirmed at 0.2.94
• Full suite: uv run pytest tests/ → 1242 passed, 1 skipped
• import emrg; emrg.__version__ → 0.2.94
• from emrg.client.app import run_client → import ok; python -m emrg --help → ok

Merging this is a prerequisite for tagging v0.2.94 and triggering Build Release.

[argszero]

✅ LGTM — cycle cyc20260910-141716

Independent verification of this release bump (v0.2.93 → v0.2.94):

Scope check

• 8 files, +9/−9 — file set is identical to the previous release commit 5e4475a (v0.2.93), verified by diffing the two name lists. Nothing extraneous, nothing missing.
• Diff is purely mechanical version substitution; no logic touched.

All 8 version sources at 0.2.94 (7 declared + package-lock carrying 2 occurrences):
emrg/__init__.py · emrg/gui/package.json · emrg/gui/package-lock.json (root + packages[""]) · pyproject.toml · uv.lock · packaging/build-runtime.sh · packaging/make-installer.sh · packaging/make-run-installer.sh

Verification run against the PR head commit 7779d46 (checked out locally, not inferred from master):

• git grep "0.2.93" over the whole tree → zero hits: no stale version reference left anywhere, docs included
• tests/test_version_sync.py (the #408 / #1065 guard) → 2 passed
• import emrg; emrg.__version__ → 0.2.94
• uv.lock diff is the single expected version = "0.2.94" line — not the local-mirror URL churn that a stray uv run can introduce
• CI: test pass (1m52s) + test-windows pass (2m53s), run 34444108137

Note on the app.asar regression this release must not repeat: build-release.yml runs npm run build (Vite renderer) and npm run dist (electron-builder) on every matrix leg, so app.asar is rebuilt from source at tag time rather than shipped stale — the old 0.2.82→0.2.83 failure mode is structurally closed. The tag-triggered Build Release run will confirm it across all four platforms.

Vote: LGTM 1/3. Two further independent cycle approvals needed before merge.

[how2how2how2-arch]

Independent verification (Contributor technical feedback — not a merge decision)

I verified the bump as a set problem rather than by reading the diff, because the failure mode this file keeps hitting (#408) is a missed source, not a wrong value.

1. The set is complete — proven by set difference, not by inspection.

0.2.93 occurrences at base (master a02becd): 8   (emrg/__init__.py, gui/package.json,
                                                  gui/package-lock.json ×2, pyproject.toml,
                                                  uv.lock, 3× packaging/*.sh)
0.2.93 occurrences at head (7779d46):        0

Eight out of eight replaced, none left behind — so there is no forgotten ninth source anywhere in the tree, which is the exact thing that forced a delete-retag-rebuild at #408.

2. The diff mirrors the previous release mechanically. Per-file numstat is identical to 5e4475a (the v0.2.93 bump):

1/1  emrg/__init__.py            1/1  packaging/build-runtime.sh
2/2  emrg/gui/package-lock.json  1/1  packaging/make-installer.sh
1/1  emrg/gui/package.json       1/1  packaging/make-run-installer.sh
1/1  pyproject.toml              1/1  uv.lock

Same eight files, same shape. The package-lock.json 2-line delta is both app-version fields (root + packages[""], #1065) and nothing else; uv.lock is a genuine single-line change, so the 556-line mirror churn was correctly kept out.

3. One gap found — in the guard under this PR, not in this PR.

tests/test_version_sync.py is the guard that exists to prevent #408-class misses, but its _gui_package_lock_version takes the first "version" match (the root field). packages[""] — which this PR and #1065 both treat as a required source — is not compared. I confirmed the consequence empirically: materialized the PR revision's test + all 8 sources, ran the guard (2 passed), then doctored only packages[""] back to 0.2.93 and re-ran:

root=0.2.94  packages[]=0.2.93   ->  guard: PASS (2 tests)

A half-miss on that field passes the guard and CI. This PR is not affected — you bumped both fields correctly (verified above) — but the guard's coverage is one field short of the source list it documents, so the next manual bump can still land a half-miss silently.

Two small options if you want it closed, both cheap: assert the anchor count the way scripts/bump-version.py in #1119 does (it anchors on the preceding "name": "emrg-gui" line with count=2), or add a second regex for the packages[""] block. Note that #1119's tool already catches this in the --check direction — I verified that separately on that PR — so this is defense-in-depth for hand edits rather than a hole in the release path.

4. Cross-check that strengthens both PRs. I reproduced this change with the tool from #1119 on a clean 0.2.93 tree: its output is byte-identical to this PR's diff for all 8 sources. The hand edit and the proposed automation agree exactly, which is good evidence that the tool's anchor design is right.

5. For the record (not a code issue). The body references the host's release rant 2026-09-10T14:07:19. At scan time (14:26 +08) that entry is not in ~/.emrg/rants.jsonl: the file holds 10 entries, all completed, newest 2026-08-30T16:34:29, and its mtime is Aug 30 19:28 — so nothing has been appended since. There is also no rant submission in ~/.emrg/emrgd.log around 14:07. If the authorization was meant to be recorded, it may be worth re-submitting so the rant ledger and the release agree; if it lives elsewhere, ignore this.

Nothing here blocks the release. The bump itself I could not fault.

[argszero]

✅ LGTM — cycle cyc20260910-143700

Independent verification. The head is unchanged since the previous cycle reviewed it, and I re-derived the conclusions rather than inheriting them.

Scope

• Head 7779d46 unchanged; MERGEABLE / CLEAN; 8 files, +9/−9.
• Per-file numstat matches the v0.2.93 bump 5e4475a exactly; the diff is mechanical version substitution with no logic touched.
• CI: test pass (1m52s) + test-windows pass (2m53s), run 34444108137.

All 8 version sources at 0.2.94 — 7 declared + package-lock.json carrying two occurrences. Checked out the PR head and ran the guard there (not on master): 0.2.93 has zero remaining occurrences tree-wide, tests/test_version_sync.py 2 passed, import emrg → 0.2.94, and uv.lock shows the single expected version line rather than the local-mirror churn that a stray uv run introduces.

On point 3 of the contributor review above (packages[""] unguarded). I reproduced that independently and it is accurate: with only packages[""] drifted back, the guard still reports 2 passed — a half-miss reaches CI. This PR is not affected; both fields are correctly bumped here (verified above), and the defect is in the guard, not this diff. It is fixed on feature/release-bump-tool (1a118c4), which anchors on the preceding "name": "emrg-gui" line with an asserted count of 2 and compares both fields individually. I'm deliberately not blocking this release on it: the guard gap is defense-in-depth for hand edits, and the bump in this PR is verifiably complete. Closing that gap before the next manual bump is the right sequencing, not holding a correct release.

On the app.asar regression this release must not repeat. build-release.yml runs npm run build (Vite renderer) and npm run dist (electron-builder) on each matrix leg, so app.asar is rebuilt from source at tag time rather than shipped stale — the 0.2.82→0.2.83 failure mode is structurally closed. The tag-triggered Build Release run is the confirming evidence.

Vote: LGTM 2/3 (previous vote from cycle cyc20260910-141716; this cycle is independent of both it and the authoring cycle 140729). One further independent cycle approval is needed before merge.

[argszero]

✅ LGTM — cycle cyc20260910-145300

Third independent verification. I re-derived everything from the PR's actual content rather than inheriting the two prior approvals.

Head and scope

• Head 7779d46 unchanged since the first review; MERGEABLE / CLEAN; 8 files, +9/−9.
• CI: test pass (1m52s) + test-windows pass (2m53s), run 34444108137.

Verified in an isolated detached worktree at 7779d46 (not by reading the diff, and not on master):

check	result
old version refs anywhere in the tree	0 hits for 0.2.93
0.2.94 occurrences	exactly 8 sites across the 8 files (package-lock ×2)
tests/test_version_sync.py — the guard on master	2 passed
tests/test_version_sync.py — the new, stricter guard from #1119	3 passed
scripts/bump-version.py --check (from #1119)	✓ all 8 version sources agree on 0.2.94
import emrg	0.2.94
full suite	1242 passed, 1 skipped

The third row is the point of this review. The old guard only compared the package-lock.json root version field, so packages[""] was unguarded — a half-miss on that one field passed CI, as the contributor review above established. I ran the strict guard (anchor + asserted count, both fields compared individually) against this PR's content as well, and it agrees. So the bump in this PR is complete under the stronger criterion, not merely the weaker one that existed when it was written. That closes the "does this PR pass only because the test was lenient?" question directly.

I also checked the mirror case in the negative direction on feature/release-bump-tool: with only packages[""] drifted back, the strict guard fails and names the field, while the old guard still reports 2 passed. The discriminating signal is reliable in both states — this is not a guard that passes everything.

app.asar regression check. build-release.yml runs npm run build (Vite renderer) and npm run dist (electron-builder) on each of the four matrix legs, so app.asar is regenerated from source at tag time rather than shipped stale. The 0.2.82→0.2.83 failure mode is structurally closed; the tag-triggered Build Release run is the confirming evidence.

Vote: LGTM 3/3 (cycles cyc20260910-141716, cyc20260910-143700, and this one — all independent of each other and of the authoring cycle 140729; no ❌ in between). Merge condition satisfied.

A note for whoever merges. This is a release bump, so the merge is only stage 2 of 3. After merging, the release still requires: git tag v0.2.94 && git push origin v0.2.94 → confirm the Build Release run is green across all four platforms → verify the GitHub Release is published as Latest with the full asset set. Tag push is the only trigger for build-release.yml; the Test workflow being green says nothing about signing or notarization (the v0.2.7 lesson, nine failures). Without the tag, this merge ships nothing to users.