docs(plan): record the MCP direction, the blank-session fix and the merge of #33 to #36 (plan r20) - #38

Summary

Plan r20. Only documents change (4 files, +100 −28; 2 commits). No code, no workflow and no tui/ file changes. The plan now says what happened after r19: the owner chose the MCP direction (an optional extension package), the release content for pi-mcp-py was added, #33 to #36 are merged, and the owner answered decisions 20 and 21. Two earlier statements are corrected.

docs/PLAN/PLAN-RUST-AGENT-RUNTIME-REMOVAL.md
├── status line, "当前状态"   r20: MCP direction, merge of #33–#36, CI on e0f2a36, the answers
├── decision 17               + correction (#34): session/load and session/resume open an empty
│                               session for a canonical UUID that has no file
├── decision 19  (new)        MCP = optional extension package           decided (owner, 2026-10-23)
├── decision 20  (new)        versions of the extension packages, core floors
│                               decided (owner, 2026-10-25: "follow your lean"): option (a)
├── decision 21  (new)        the 11 defaults of the MCP design (Q1–Q11)
│                               decided (owner, 2026-10-25: "follow your lean"): all defaults
├── V0.6 section              scope: 14 commits, + pi-mcp-py; conditions 1, 3, 5, 6; known issues
└── §7, appendix A.1/A.2, index, revision log, link definitions
docs/PLAN/archive/…-EXECUTION-LOG.md    new §10.23: cause, #34–#36, release content, merge, check of
                                         the trees, CI on main, floors, the answers, not verified
docs/specs/2026-10-23-mcp-extension-design.md   §10: one sentence, the owner confirmed the defaults
docs/TUI-AND-CODE-AGENT.md              "MCP servers are not connected" -> "need the optional package pi-mcp-py"

Two corrections:

• Decision 17 said a session has no file until the first message. For Zed this was wrong: Zed restarts and calls session/load with an id that has no file, and got resource_not_found. fix(cli): open a session in which nobody typed again with session/load and session/resume #34 fixed the code; the plan text now says so.
• r19 said the three published extension packages stay as they are in V0.6. That is wrong. The packaging test needs each core floor to equal the workspace version, so a core of 0.6.0 needs >=0.6.0 in all four extension packages. This is decision 20.

What the answers mean (nothing is changed in code yet):

decision 20 (a), done in the PR of V0.6 condition 5, not here
  pi-agent-core-lc / -harness-lc / -cli-lc   0.5.0 -> 0.6.0
  floor pi-agent-core-lc in all four extensions   >=0.5.0 -> >=0.6.0
  pi-web-access-py, pi-goal-x-py, pi-dynamic-workflows-py   0.2.0 -> 0.3.0   (as V0.5: 0.1.0 -> 0.2.0, 7e7d4d4)
  pi-mcp-py   stays 0.1.0 (first upload)
decision 21: Q1–Q11 stay as implemented in #36 (Q3: annotations are trusted; Q5: no server config in zypi)

The lean did not say which digit to raise for decision 20. 0.3.0 is my choice from the V0.5 precedent. The owner did not name it. The plan and the execution log say so. Change it if you want 0.2.1.

Evidence

• Before: the plan says the three extension packages stay.
  After: the plan says all four floors must change. I checked it with a temporary edit (reverted):

  pi_agent_core/tests/test_extension_packaging.py   (core version set to 0.6.0)
    -> 4 tests fail, one for each of pi-web-access-py, pi-goal-x-py, pi-dynamic-workflows-py, pi-mcp-py
  

• No other package pins the three published extensions. pi-web-access-py, pi-goal-x-py and pi-dynamic-workflows-py appear outside docs only as their own name and in pip install lines (no version); there is no uv.lock. So a bump touches only their own pyproject.toml.

• The merge facts in the text match GitHub. docs(plan): set the V0.6 release milestone and record the merge of #27 to #31 (plan r19) #33 ca2ab85, fix(cli): open a session in which nobody typed again with session/load and session/resume #34 fa4887b (PR head 79f41ad), feat(extensions): give extensions the MCP servers a client passes, a way to tell the user, and turn barriers #35 34c11d9 (d56e95e), feat(mcp): add pi-mcp-py, an extension that connects the MCP servers a client passes #36 e0f2a36 (eda4aac). Each squash commit has the tree of its PR head plus the two plan files of docs(plan): set the V0.6 release milestone and record the merge of #27 to #31 (plan r19) #33.

• CI on main at e0f2a36: CI passes (pytest 2,908 passed / 39 skipped / 31 deselected on Python 3.11, 3.12, 3.13). TUI CI passes (nextest 8,490 passed / 0 failed / 22 skipped; Gates: warnings 0, dependency graph 970/970, leader 243/243, x.ai 297/297).

• Links. A scratch checker (not in the repo) read the changed files: 0 undefined references and 0 wrong anchors or paths; the plan has 9 new link definitions and all are used. The checker finds planted defects (an undefined reference, a wrong anchor, a missing file, a wrong cross-file anchor).

• The files keep their CRLF line ends (no bare LF) and the diff has no whole-file rewrite.

• ruff check . and ruff format --check . pass.

Not verified: "from 0.6.0" in the docs is my assumption for the next release. I cannot check that PYPI_API_TOKEN may create a new PyPI project. #34 and pi-mcp-py are not tried in a real Zed (a real context7 server and a real model were tried in-process, see #36). The 0.3.0 digit is my choice (see above).

Merge Danger

Door: two-way. Only documents.

Blast Radius: readers of the plan.

• CI runs on this PR (ruff and pytest). TUI CI does not run: its path filter does not include docs/**.
• This PR changes no version number. The bump to 0.6.0, the new floors and the 0.3.0 versions belong to the PR of V0.6 condition 5, which is not open.
• The text describes main at e0f2a36 (for example "14 commits after v0.5.0"). If another PR merges first, those numbers need an update.