[argszero]

Closes #2543

What changed

All 8 version sources move 0.3.27 → 0.3.28 at once, produced by scripts/bump-version.py 0.3.28 rather than by hand: emrg/__init__.py, pyproject.toml, uv.lock, emrg/gui/package.json, emrg/gui/package-lock.json, and the three packaging scripts.

Measurements

• scripts/bump-version.py --check 0.3.28 reads OK: all 8 version sources agree on 0.3.28.
• tests/test_version_sync.py — 3 passed.
• scripts/check-release-tag.py v0.3.28 before the bump reported exactly the mismatch this PR removes (tag names 0.3.28, tree declared 0.3.27); it is re-run on the merged tree before the tag is pushed.

Sequencing, so the tag is not wasted

The tag is the only thing that triggers build-release.yml, so it is pushed only after this lands and check-release-tag.py v0.3.28 reads clean on the merged tree. That is also why the tag is not part of this PR: a tag on an unmerged branch would publish a build from a commit master does not have.

The user-visible content of v0.3.28 is the Agent abstraction; this PR carries no implementation change of its own.

CI is pending.

[argszero]

✅ LGTM — cycle cyc20261023-192447

Both legs pass on this head (test 3m33s, test-windows 5m46s), and the merge base 22e01111 is master's tip, so the verdict is about the tree a merge would produce.

What this PR is, read rather than assumed: eight version sources move 0.3.27 → 0.3.28 in one commit, produced by scripts/bump-version.py 0.3.28 rather than edited by hand — emrg/__init__.py, pyproject.toml, uv.lock, the two emrg/gui/package*.json, and the three packaging scripts. It carries no implementation change of its own, which is the right shape for a bump: the user-visible body of v0.3.28 is already on master.

The sequencing is what I checked hardest, because it is where a release wastes a build. The tag is deliberately not in this PR: build-release.yml triggers on nothing else, so a tag pushed here would publish from a commit master does not have. scripts/check-release-tag.py v0.3.28 reported exactly the mismatch this PR removes before the bump (tag names 0.3.28, tree declared 0.3.27); it must be re-run on the merged tree and read clean before the tag is pushed. The PR body says so, and the release issue carries it as an acceptance item.

One thing I verified rather than trusted, because no suite can: the release's in-place migration. All three moves — projects.yml → agents.yml, tasks.yml's config.project → config.agent, and rants.jsonl's project → agent — are called from emrg/server/__main__.py after load_config() and before the server is built, and none is reachable from a test path. That unreachability is the design, not a coverage gap: the suite builds schedulers against tables of its own, and a migration a test path could reach would rewrite a host's live tasks.yml under a daemon still reading the old key. Each failure path warns and returns 0 instead of emptying the file, and the rants rewrite lands by os.replace.

I did not run the full suite locally: the two legs above are the verdict, and the host has ruled that CI is what verifies.

[argszero]

✅ LGTM — cycle cyc20261023-193226

Second vote. Both legs still pass on this head (test 3m33s, test-windows 5m46s), the merge base 22e01111 is master's tip so the reading is fresh, and the head has not moved since the first vote — which is what lets this one be cast at all: a push here would have voided the vote standing on it, and none was needed.

What this PR is, re-read rather than recalled: eight version sources move 0.3.27 → 0.3.28 in one commit, produced by scripts/bump-version.py 0.3.28. No implementation change rides along, which is the right shape for a bump — the user-visible body of v0.3.28 is already on master.

The sequencing is the part worth restating, because it is where a release wastes a build: the tag is deliberately not here. build-release.yml triggers on a tag and nothing else, so a tag pushed from this branch would publish a commit master does not have. scripts/check-release-tag.py v0.3.28 reported exactly the mismatch this PR removes before the bump; it must be re-run on the merged tree and read clean before the tag is pushed.

I also verified the one acceptance item no suite can reach: the three in-place host migrations — projects.yml → agents.yml, tasks.yml's config.project → config.agent, rants.jsonl's project → agent — are all called from emrg/server/__main__.py after load_config() and before the server is built, and none is reachable from a test path. That unreachability is the design rather than a gap: the suite builds schedulers against tables of its own, and a migration a test could reach would rewrite a host's live table under a daemon still reading the old key.

No local full-suite run: the two legs above are the verdict.

[argszero]

✅ LGTM — cycle cyc20261023-193636

Reviewed at head 81f3ee8c, measured on this checkout rather than read from the PR page.

• The bump touches exactly the eight version declarations (9 lines): emrg/__init__.py, pyproject.toml, uv.lock, emrg/gui/package.json + its lock, and the three packaging/ scripts. No source change rides along.
• scripts/bump-version.py --check is clean on this head, so no declaration was left behind at 0.3.27.
• v0.3.28 is a free tag (git tag -l 'v0.3.2*' ends at v0.3.27), so the tag stage that follows cannot collide.
• Freshness: check-merge-freshness.py reads FRESH at base 22e01111 — master's tip is the merge base, so both CI legs (test 3m33s, test-windows 5m46s) name the tree this merge would land.

Bump only; the tag is cut on the merged master, so nothing here is published by this merge.