docs(release): fold [Unreleased] into [0.5.0], add the missing entries and the macOS binary - #15

…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.

…on (plan decision 16) (#17)

## Summary

`zypi --version` printed `1.0.8`, the version of the upstream project. The ACP `agentInfo.version` was fixed at `0.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 onto `main` and its base moved there. The CHANGELOG hunks need the `[0.5.0]` section that #15 creates.

## What changes

- `pi-pager-bin` and `pi-version` (the `Cargo.toml` files and their two entries in `tui/Cargo.lock`): `1.0.8` -> `0.5.0`, the version of `pi-agent-cli-lc`. `zypi --version` prints `0.5.0 (<commit>)`.
- `pi_agent_cli/agent.py`: `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.
- `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_INFO` is hard-coded and was left alone. It now says that this changed later.

`pi-pager` and `pi-shell` also have version `1.0.8`. Decision 16 does not cover them, so they stay.

## Behaviour change

The version number is lower than before. `pi-config` applies a `[[version_overrides]]` patch only when the installed version is inside the range of the patch. A patch with a `minimum_version` above `0.5.0` no longer applies. No patch like that ships with `zypi`. 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 of `pi-update` are not reached.

## Why the workflow does not set `GROK_VERSION`

`pi_version::IS_DEV_BUILD` is `option_env!("GROK_VERSION").is_none()`, and `pi-workspace` reads the same variable in `folder_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 the `dev_build` telemetry field changes. v0.3.0 and v0.4.0 were built without the variable, so folder trust is off in every `zypi` release so far. To turn it on is a change of behaviour that needs its own decision. So the version must come from `Cargo.toml`, and a test now fails if a workflow sets the variable.

## Tests

- `packages/pi-agent-cli/tests/test_agent_info.py`: `initialize` reports the installed version; the fallback is a valid version.
- `scripts/tests/test_release_versions.py`: the two crates and `Cargo.lock` equal the version of `pi-agent-cli-lc` (the message says what to change); no workflow sets `GROK_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-version` off by one patch; `pi-pager-bin` back to `1.0.8`; each of the two `Cargo.lock` entries not updated; a workflow that sets `GROK_VERSION`. All 8 were caught.

## Checks that ran

- Windows (local): `ruff check .` and `ruff format --check .` pass. Full `pytest`: 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; the `GROK_VERSION` guard passed, because no workflow sets it today).
- `CI` ([run 38230414753](https://github.com/zy1233/pi-python/actions/runs/38230414753)): Ruff passes. `pytest` on 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](https://github.com/zy1233/pi-python/actions/runs/38230414764)): Gates + `cargo check` 2 m 46 s (dependency graph 980 packages, which is the ceiling). `cargo test` 14 m 03 s: 8,665 passed, 0 failed, 22 ignored, with `PI_E2E_REQUIRED=1` (the end-to-end tests talk to the real Python agent). These are the numbers of `main` at `4fc028a`. So the manifest and lock edits build, and the Rust tests did not change.
- Both runs are on the commit as first pushed (`b7567dd`). The branch was then rebased onto `main` after #15's squash. The tree of the rebased commit (`cb9a9b7`) is the tree of `b7567dd` (`git diff b7567dd cb9a9b7` is empty), so those results stand.

## Not verified

- **Nobody has seen the output of `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 prints `0.5.0 (<12-character commit>)`. The first release build that is made after this PR shows it.
- The guard test for `GROK_VERSION` was not asked for. It protects the choice of option (a). Drop `test_no_workflow_sets_grok_version` if it is more than you want.

…(plan r12)

Define what V0.5 is from the state of the Rust agent runtime removal on
main (4fc028a; CI and TUI CI are green on it): the untagged 0.5.0 plus
the TUI side of r3-r11. The scope follows the status table. The plan now
holds the six exit conditions, the known issues that ship with the
release and the items that do not ship. The evidence is in section 10.15
of the archived execution log.

Found while checking the release path:
- release.yml had no manual trigger, and its macOS arm64 job had never
  run in a release (PR #14 adds the trigger);
- the CHANGELOG had no entry for the removal itself (PR #15 adds it);
- zypi --version and "is this a release build" share GROK_VERSION, so the
  obvious fix for the version string would turn folder trust on (new plan
  decision 16).

The follow-ups that were chosen are recorded here, not done here:
- release size (condition 2): 420,767,096 B, 10.6 % below v0.4.0, from the
  release_baseline run 38221952524; docs/baselines/tui.md has the numbers;
- dry run (condition 3): run 38223353755, started from the PR branch,
  built Linux x86_64 and macOS arm64 and published nothing;
- release notes (condition 5): PR #15;
- decision 16: option (a) chosen, not implemented.
The comparison with v0.4.0 (condition 4) is not done. WSL does not start on
this machine, so no release binary was run.

A GitHub milestone v0.5.0 was created next to this change. Nothing is
attached to it. Nothing under tui/, packages/ or .github/ changes.

…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.

…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.

…(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.