chore(release): prepare 0.6.0 - versions, extension floors, changelog (V0.6 condition 5) - #39

Summary

V0.6 exit condition 5, plan decision 20 (owner, 2026-10-25: "follow your lean"; the text is in #38). Versions, requirements and release notes only. No code, no workflow. 11 files, +40 −22.

 pi-agent-core-lc          0.5.0 -> 0.6.0   extras pin harness and cli with ==
 pi-agent-harness-lc       0.5.0 -> 0.6.0   pins core with ==
 pi-agent-cli-lc           0.5.0 -> 0.6.0   pins core and harness with ==
 pi-pager-bin, pi-version  0.5.0 -> 0.6.0   and the two entries in tui/Cargo.lock (= pi-agent-cli-lc)
 pi-web-access-py          0.2.0 -> 0.3.0   core    >=0.5.0 -> >=0.6.0
 pi-goal-x-py              0.2.0 -> 0.3.0   core    >=0.5.0 -> >=0.6.0
 pi-dynamic-workflows-py   0.2.0 -> 0.3.0   core and harness  >=0.5.0 -> >=0.6.0
 pi-mcp-py                 0.1.0 (new)      core    >=0.5.0 -> >=0.6.0

CHANGELOG.md
├── ## [Unreleased]                 new, empty
└── ## [0.6.0] - 2026-10-25         was [Unreleased]
    ├── intro paragraph             (0.5.0 has one; the release page shows it first)
    ├── Added 3, Fixed 5, Removed 3 unchanged
    ├── Changed 6 + 1               new entry: version numbers and floors
    ├── Known issues (new, 9)       0.5.0 list minus the session item, plus 4 new items
    └── [0.6.0] link at the bottom

Why 0.3.0 for the three published extensions: publish-pypi uses skip-existing. With the same number, PyPI keeps the 0.2.0 files, which say >=0.5.0. Their code has not changed since v0.5.0 (git diff v0.5.0 main over the three packages: one test file, +13 lines). 0.3.0 is my choice of digit (V0.5 went 0.1.0 → 0.2.0 in 7e7d4d4); the owner chose option (a) and did not name the digit. Say so if you want 0.2.1.

Evidence

• Before: only the three core packages raised to 0.6.0 (throwaway worktree of main). test_extension_packaging.py and test_release_versions.py: 7 failed, 9 passed (the floor of each of the 4 extensions, pi-pager-bin, pi-version, tui/Cargo.lock).
  After: this branch: 16 passed.
• Full pytest in fresh venvs with the 7 packages installed editable, as ci.yml does: Windows 2,886 passed / 61 skipped / 31 deselected; WSL (Linux, Python 3.12) 2,912 passed / 35 skipped / 31 deselected.
• All 7 packages build with python -m build. The 14 files pass twine check --strict. The wheels say what the diff says (Requires-Dist: ==0.6.0 between the three core packages, >=0.6.0 in the four extensions). In a clean venv the built wheels install, uv pip check says "All installed packages are compatible", and the 4 extensions are found.
• cargo metadata --locked --offline in tui/: exit 0 and Cargo.lock unchanged, so the two hand-edited entries are what cargo writes.
• The awk of release.yml returns the [0.6.0] section: 33,725 bytes (the limit of a release body is 125,000 characters); 3 Added, 7 Changed, 3 Removed, 5 Fixed, 9 Known issues.
• ruff check . and ruff format --check . pass.
• CI on the head ae93ae4: CI: Ruff and pytest on Python 3.11, 3.12 and 3.13 pass (3.12: 2,908 passed / 39 skipped / 31 deselected, as on main). TUI CI: cargo nextest 8,490 passed / 0 failed / 22 skipped; Gates: warnings 0, dependency graph 970, leader 243, x.ai 297 (all as on main). The job Release build baseline is manual, so it was skipped.

Merge Danger

Door: two-way. A revert restores the 0.5.0 numbers. The tag v0.6.0 is the one-way door (PyPI keeps a version for good). This PR does not tag and does not publish: Release runs for a tag push only.

Blast Radius: packaging

• After the merge, main says 0.6.0 although nothing is released. A new local build of zypi and a re-installed agent report 0.6.0. An editable install that was made before the merge keeps the old metadata (the 0.5.0 numbers, consistent with each other) until you install again.
• The date in ## [0.6.0] - 2026-10-25 is the day of the tag. Change it in the tag commit if the tag is made on another day. The release page does not show the header (the notes start under it).
• The PR touches tui/ (two Cargo.toml files and Cargo.lock), so TUI CI runs (about 25 minutes).
• Still open after the merge: conditions 1 to 3 on the tagged commit (CI, the size of the release binary, a dry run of release.yml), and the owner's decisions on 4 (compare with v0.5.0) and 6 (who tags). pi-mcp-py is a new PyPI project, so PYPI_API_TOKEN must be able to create one. I cannot check that from here.