Repository navigation
fix(release): zypi --version and ACP agentInfo show the release version (plan decision 16) - #17
Merged
Merged
Conversation
zy1233
added a commit
that referenced
this pull request
Oct 12, 2026
…entry in #15, condition 4 skipped) After the first push of this PR the owner answered three questions: - Decision 16 is done now, in its own PR (#17, stacked on #15): the plan item moves from "decided, not done" to "done", the known issue about the version numbers leaves the list (it comes back only if #17 is not merged before the tag), and the "not verified" text now says what the CI of #17 proved and what nobody has seen (the output of `zypi --version`). - The macOS arm64 binary entry went into #15 (CHANGELOG, README and docs/TUI-AND-CODE-AGENT.md, "built by CI, nobody has started it"): condition 5 says so, with the new entry counts (20 new entries; the release body is 45,076 B, and 45,855 B after #17). - Condition 4 (compare with v0.4.0) is skipped. V0.5 does not wait for it. The execution log gets a "续 2" part in section 10.15 with the answers, what changed, the tests (6 new, 8 mutations caught), the Windows and Linux numbers and the CI runs of #17. The index, the revision log and the link definitions follow. Only documents change.
This was referenced Oct 12, 2026
zy1233
added a commit
that referenced
this pull request
Oct 12, 2026
…s and the macOS binary (#15) ## Summary The release page of a tag shows only the `CHANGELOG.md` section that has the version of the tag (`release.yml` extracts it with `awk`). Today that section, `[0.5.0]`, has nothing about the work in `tui/`, and `[Unreleased]` has most of it. This PR makes `[0.5.0]` the text of the release. It is exit condition 5 of the V0.5 milestone ([v0.5.0](https://github.com/zy1233/pi-python/milestone/1)). Three files change: `CHANGELOG.md`, and, for the macOS binary, `README.md` and `docs/TUI-AND-CODE-AGENT.md`. The `CHANGELOG.md` diff is larger than the new text, because the moved bullets show as removed and added. - **Fold.** The 18 bullets of `[Unreleased]` (9 Added, 5 Changed, 4 Fixed) move into the matching groups of `[0.5.0]`, after the bullets that are already there. `[Unreleased]` is empty. The date of `[0.5.0]` is 2026-10-12. - **A summary paragraph** at the top of `[0.5.0]`: what the release is. - **20 new bullets** for things that were in neither section: | Group | New entries | |---|---| | Added | `/model` through ACP session config options; **a prebuilt `zypi` for macOS on Apple silicon** | | Changed | `zypi -p` refuses a sandbox and names the flags it ignores; `zypi` is the product name where a name is shown | | Removed (new group) | the Rust agent runtime (with the numbers); the screens, commands and flags that went with it | | Fixed | a tool left running after quit; `session/close` and `session/resume`; the title and time in `session/list`; `AGENTS.md` read twice on macOS; the `ssh-wrap` alias; messages that name things that do not exist | | Known issues (new group) | 8 items, from the list in the plan | - **The macOS binary** (the second commit; you chose this after the dry run in #14 passed). The Added entry, the Known issue "tested on Linux only", the install steps in the TUI guide, the platform table, the download paragraph of the README and its roadmap line say that `zypi-macos-arm64` exists, that CI builds it, and that nobody has started it. ## Where the facts come from - **2,500 to 1,755 `.rs` files, 1,620,612 to 1,021,067 lines** under `tui/crates`: `git grep -c -e "^"` at `v0.4.0` and at `main` (`4fc028a`). - **1,311 to 1,257 packages**: the `[[package]]` entries of `tui/Cargo.lock` at the same two revisions. - **470,461,776 to 420,767,096 bytes** (−10.6 %): the `release_baseline` run [38221952524](https://github.com/zy1233/pi-python/actions/runs/38221952524) on `4fc028a`. The same run builds in 1,195 s (v0.4.0: 1,647 s) and `--version` takes 23.4 ms. - **Removed flags** `--fork-session`, `--leader`, `--no-leader` and `--leader-socket`: I compared the long flags of `PagerArgs` (`pi-pager/src/app/cli.rs`) at `v0.4.0` and `main`. 7 flags were removed and none was added. The other 3 are the `--local-workspace*` flags, which a release build never had, so they are not in the entry. - **The macOS binary**: the dry run [38223353755](https://github.com/zy1233/pi-python/actions/runs/38223353755) (from the branch of #14) built `zypi-macos-arm64` on `macos-14` in 25 min. `release.yml` has no signing or notarization step. - **The other entries** come from the code and from sections 10.2, 10.7, 10.8 and 10.10 of `docs/PLAN/archive/PLAN-RUST-AGENT-RUNTIME-REMOVAL-EXECUTION-LOG.md`. I read the code again for `-p` (`print_mode.rs`), the `session/list` title (`session_list.py`), the `AGENTS.md` check (`context_files.py`) and the `session/close` flag (`__main__.py`). ## Decisions for you 1. **The date.** It is 2026-10-12 (today). If you tag on another day, change it before the tag. 2. **Known issues in the release text.** The release page will show the 8 items. They are true as far as I know, but they are your public statement. Cut any you do not want to publish. One of them (`Version numbers`) goes away with #17 (plan decision 16). #17 is stacked on this PR and merges right after it. ## Not verified - How GitHub shows the text. I ran the `awk` program of `release.yml` (Git for Windows `awk`) on this file: the body is 44 KB, has the 5 groups, and has no `## [` line. - The version claim in Known issues (`zypi --version` shows `1.0.8`) comes from the code (`build.rs`, `Cargo.toml`). I did not run a release binary when I wrote this. - Nobody has run the macOS binary. The advice about `xattr -d com.apple.quarantine` is general macOS behaviour. I did not test it. - No person other than me has read the new English text. ## Verification - Bullet lines before: 75. After: 95. The difference is the 20 new bullets. No bullet was lost or changed except the Known issue "tested on Linux only", which has one more sentence. The text from `## [0.4.0]` on is the same. - Every backtick and `**` pair in `CHANGELOG.md` is balanced. - `ruff check .` and `ruff format --check .`: clean (nothing in Python changes).
…on (plan decision 16) `zypi --version` printed 1.0.8, the version of the upstream project, and the ACP `agentInfo.version` was fixed at 0.1.0 in agent.py. Neither told a user which release they had. - The `pi-pager-bin` and `pi-version` crates, and their entries in tui/Cargo.lock, carry 0.5.0, the version of `pi-agent-cli-lc`. `zypi --version` prints `0.5.0 (<commit>)`. `pi-pager` and `pi-shell` keep 1.0.8: plan decision 16 does not cover them. - `agentInfo.version` reads the version of the installed `pi-agent-cli-lc`. A checkout that was never installed has no package metadata and gets `0.0.0+unknown`, which is still a valid version. - Tests: the agent reports the installed version; the two crates and Cargo.lock stay equal to the version of `pi-agent-cli-lc`; no workflow sets GROK_VERSION (that variable also marks a build as a release build, which turns the folder-trust prompt on). - CHANGELOG: a new Changed entry (with the behaviour change for a `[[version_overrides]]` patch above 0.5.0) and the "Version numbers" known issue is removed. The audit note that said `_AGENT_INFO` is hard-coded now says it changed later. Not run here: cargo build and cargo test, and `zypi --version` (WSL does not start on this machine). TUI CI builds the workspace and runs the Rust tests.
zy1233
force-pushed
the
fix/release-version-numbers
branch
from
October 12, 2026 10:00
b7567dd to
cb9a9b7
Compare
zy1233
added a commit
that referenced
this pull request
Oct 12, 2026
…entry in #15, condition 4 skipped) After the first push of this PR the owner answered three questions: - Decision 16 is done now, in its own PR (#17, stacked on #15): the plan item moves from "decided, not done" to "done", the known issue about the version numbers leaves the list (it comes back only if #17 is not merged before the tag), and the "not verified" text now says what the CI of #17 proved and what nobody has seen (the output of `zypi --version`). - The macOS arm64 binary entry went into #15 (CHANGELOG, README and docs/TUI-AND-CODE-AGENT.md, "built by CI, nobody has started it"): condition 5 says so, with the new entry counts (20 new entries; the release body is 45,076 B, and 45,855 B after #17). - Condition 4 (compare with v0.4.0) is skipped. V0.5 does not wait for it. The execution log gets a "续 2" part in section 10.15 with the answers, what changed, the tests (6 new, 8 mutations caught), the Windows and Linux numbers and the CI runs of #17. The index, the revision log and the link definitions follow. Only documents change.
zy1233
added a commit
that referenced
this pull request
Oct 12, 2026
…L2 (plan r12, part 3) #15, #17 and #14 are squash-merged (59545c1, d57fd9b, 0efd400). The plan and the execution log say so, and main is now 0efd400 in the current-state text. WSL2 works again. On 0efd400: Linux pytest 2,539 passed / 16 skipped / 31 deselected; `zypi --version` prints `zypi 0.5.0 (0efd400)` (a debug build on ext4, not the CI release-dist artifact); the PTY scripts pass, except one check of smoke.py, which is out of date since #12 (22/23). Section 10.15 gets a part 3 with these results and the leftovers; the "not verified" lines that said "WSL does not start" are brought up to date. Only documents change.
zy1233
added a commit
that referenced
this pull request
Oct 12, 2026
…(plan r12) (#16) ## Summary This PR records the V0.5 release in the plan: what the release is, what must be true before the tag, and what is known to be wrong. It is revision r12 of the plan for the removal of the Rust agent runtime. Only documents change. The milestone is on GitHub: [v0.5.0](https://github.com/zy1233/pi-python/milestone/1). Nothing is attached to it, because the conditions are written in one place (the plan). The three PRs that do the work of the conditions are merged before this one: #15 (`59545c1`), #17 (`d57fd9b`) and #14 (`0efd400`), in that order, each as one squash commit. This branch is rebased onto `0efd400`. - `docs/PLAN/PLAN-RUST-AGENT-RUNTIME-REMOVAL.md`: a new section "发布里程碑 V0.5" (what the release is, six exit conditions, known issues, what is not in it). The status, the next steps and the "not verified" list start from `main` at `0efd400`. Decision 16 is new, and #17 did it. - `docs/PLAN/archive/PLAN-RUST-AGENT-RUNTIME-REMOVAL-EXECUTION-LOG.md`: section 10.15, with the reasons, the figures, the follow-up work, your three answers (part "续 2"), and the merges and the WSL2 checks (part "续 3"). - `docs/baselines/tui.md`: the numbers of the new release measurement. ## The six exit conditions | # | Condition | State | |---|---|---| | 1 | CI is green on the commit that gets the tag | Green: `CI` on `0efd400`, `TUI CI` on `d57fd9b` (`0efd400` differs from it only in `release.yml`). Look again on the commit that gets the tag. | | 2 | The Linux release binary is not larger than v0.4.0 | **Done.** 420,767,096 B (v0.4.0: 470,461,776 B, 10.6 % smaller). Run [38221952524](https://github.com/zy1233/pi-python/actions/runs/38221952524). | | 3 | A dry run of the release build on Linux and macOS arm64 | **Done.** Run [38223353755](https://github.com/zy1233/pi-python/actions/runs/38223353755) built both and published nothing (27 min). The manual trigger is in #14, merged. | | 4 | The PTY scripts on the v0.4.0 binary and on the new binary | **Skipped by you.** V0.5 does not wait for it. Which known issues come from v0.4.0 stays a guess. | | 5 | The release notes | **Done** in #15, merged. They list the macOS binary and say that CI built it and nobody has started it. #17 added one entry and removed one known issue. | | 6 | The tag `v0.5.0` | Yours. | ## After the merges, with WSL2 working again You fixed WSL. These runs are on `0efd400` (details: section 10.15, part "续 3"). - Linux `pytest`: 2,539 passed / 16 skipped / 31 deselected. - `zypi --version` prints `zypi 0.5.0 (0efd400)`, exit 0. That is a debug build on ext4. It is not the `release-dist` file that CI builds. - `agentInfo.version` is `0.5.0` in a venv installed from the merged tree. An older editable install keeps the version it had when it was installed (the old `/tmp/wsl-venv`: 0.2.0). - PTY scripts: `exit_matrix.py` 12/12, `print_exit.py` 4/4, `resume_matrix.py` 10 PASS / 3 GAP (the known gaps), `mode_probe.py` as in #12, `status_line_probe.py` 4/4, `net_audit.py --mock` 13/13 and with `--no-network` 13/13. - **`smoke.py` is 22/23.** The failing check, "status line follows the switch", waits for the text `Second model` followed by a `·`. The screen shows the right label, `Second model`, the session file has the `model_change`, and the next turn answers. The check is out of date since #12. My inference, not tested on an old build: the `·` came from the `auto` flag, which #12 no longer shows in the normal mode. It is a script problem, not a TUI problem. It is not fixed here. The fix is one regular expression. ## Decisions for you - The plan decisions 6, 8, 14 and 15 should be made before the tag. If they are not, they go in the release as known issues. - The date of `[0.5.0]` in the changelog is 2026-10-12. Change it on the day of the tag. The known issues become public release text. ## Not verified - Nobody ran the `release-dist` binary that CI builds; only a debug build of `main` ran. Nobody ran the macOS binary. The changelog, the README and the TUI guide say so. - The two changed `if` lines of `release.yml` have run only on their false side. A tag push runs the true side. - This round did not run the Landlock layer (kernel 5.10 has none), `smoke.py --sandbox`, or the whole Rust test manifest on WSL2. CI ran the manifest on `d57fd9b`: 8,665 passed / 0 failed / 22 ignored. - The plan says that the version overrides of `pi-config` could stop working for a user config that needs a version above `0.5.0`. I found no default config that does, and I cannot see user configs. ## Verification - Link check of the plan and of the execution log: plan 149 local and 81 external links, 47 reference definitions; log 43 local and 58 external links; 0 unused, 0 problems. - `ruff check .` and `ruff format --check .`: clean (nothing in Python changes). - The test counts, run ids and times come from the job logs (`gh run view`) and from the output of the runs on WSL2. - The three merges used `--match-head-commit`. #15 and #17 merged with the tree that CI had tested (#17 was rebased onto `main` after #15, and `git diff` against its tested tip was empty). #14 merged onto a newer `main`, so `CI` ran again on the result, `0efd400`, and passed.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
zypi --versionprinted1.0.8, the version of the upstream project. The ACPagentInfo.versionwas fixed at0.1.0. Neither told a user which release they had. This PR makes both show the release version. This is plan decision 16, option (a): no stamp from the workflow.Stacked on #15, which is merged first (
59545c1); this branch is then rebased ontomainand its base moved there. The CHANGELOG hunks need the[0.5.0]section that #15 creates.What changes
pi-pager-binandpi-version(theCargo.tomlfiles and their two entries intui/Cargo.lock):1.0.8->0.5.0, the version ofpi-agent-cli-lc.zypi --versionprints0.5.0 (<commit>).pi_agent_cli/agent.py:agentInfo.versionreads the version of the installedpi-agent-cli-lc. A checkout that was never installed has no package metadata and gets0.0.0+unknown, which is still a valid version.CHANGELOG.md: a new Changed entry (with the behaviour change below), and the known issue "Version numbers" is removed.docs/AUDIT/AUDIT-PHASE6-PHASE7-2026-09-30.md, row 14: said that_AGENT_INFOis hard-coded and was left alone. It now says that this changed later.pi-pagerandpi-shellalso have version1.0.8. Decision 16 does not cover them, so they stay.Behaviour change
The version number is lower than before.
pi-configapplies a[[version_overrides]]patch only when the installed version is inside the range of the patch. A patch with aminimum_versionabove0.5.0no longer applies. No patch like that ships withzypi. A user may have written one in a config file, and nobody can find out. Auto-update is off (bg_update_rx = None), so the version checks ofpi-updateare not reached.Why the workflow does not set
GROK_VERSIONpi_version::IS_DEV_BUILDisoption_env!("GROK_VERSION").is_none(), andpi-workspacereads the same variable infolder_trust_inert(). A build that has the variable is a release build: folder trust is on (it prompts, and it gates repo-local.envrc, hooks, plugins, MCP and LSP), and thedev_buildtelemetry field changes. v0.3.0 and v0.4.0 were built without the variable, so folder trust is off in everyzypirelease so far. To turn it on is a change of behaviour that needs its own decision. So the version must come fromCargo.toml, and a test now fails if a workflow sets the variable.Tests
packages/pi-agent-cli/tests/test_agent_info.py:initializereports the installed version; the fallback is a valid version.scripts/tests/test_release_versions.py: the two crates andCargo.lockequal the version ofpi-agent-cli-lc(the message says what to change); no workflow setsGROK_VERSION.Mutation checks (each change was applied alone, the tests failed, the file was restored): agent version written into the source again; fallback not a valid version; wrong distribution name;
pi-versionoff by one patch;pi-pager-binback to1.0.8; each of the twoCargo.lockentries not updated; a workflow that setsGROK_VERSION. All 8 were caught.Checks that ran
ruff check .andruff format --check .pass. Fullpytest: 2,516 passed, 39 skipped, 31 deselected (real_llm), 299 s. The 6 new tests are in that number. The new tests failed on the old code (5 failed; theGROK_VERSIONguard passed, because no workflow sets it today).CI(run 38230414753): Ruff passes.pyteston Python 3.11, 3.12 and 3.13 on Linux: 2,516 passed, 39 skipped, 31 deselected each. These are the Windows numbers, so the new tests pass on Linux too.TUI CI(run 38230414764): Gates +cargo check2 m 46 s (dependency graph 980 packages, which is the ceiling).cargo test14 m 03 s: 8,665 passed, 0 failed, 22 ignored, withPI_E2E_REQUIRED=1(the end-to-end tests talk to the real Python agent). These are the numbers ofmainat4fc028a. So the manifest and lock edits build, and the Rust tests did not change.b7567dd). The branch was then rebased ontomainafter docs(release): fold [Unreleased] into [0.5.0], add the missing entries and the macOS binary #15's squash. The tree of the rebased commit (cb9a9b7) is the tree ofb7567dd(git diff b7567dd cb9a9b7is empty), so those results stand.Not verified
zypi --version. No test checks it. I did not run a binary when I wrote this. The CI shows that the workspace builds and that the tests pass, not what the binary prints. From the code, it prints0.5.0 (<12-character commit>). The first release build that is made after this PR shows it.GROK_VERSIONwas not asked for. It protects the choice of option (a). Droptest_no_workflow_sets_grok_versionif it is more than you want.