chore(release): prepare LoopX 1.0.6

[huangruiteng]

Goal

Prepare the next stable LoopX package identity, 1.0.6 / v1.0.6, from the current main release range after v1.0.5.

The range contains the governed team-plan and local delegation workflows, canonical coordination and completion consolidation, owner-configured Goal acceptance, Personal Workspace delivery readback, status/runtime efficiency fixes, and the bounded LHTB research publication. The release notes attribute all 68 merged community PRs from 11 contributors, including four first-time contributors.

Changes

• Bump loopx.__version__ and pyproject.toml together from 1.0.5 to 1.0.6.
• Regenerate the man-page version identity.
• Move the English and Chinese Dev Book release anchors to v1.0.6.

No runtime, protocol, persisted-state, permission, or provider-default behavior changes are introduced by this release-preparation diff.

Validation

• scripts/release_artifacts.py expected-tag → v1.0.6
• scripts/release_artifacts.py validate-tag v1.0.6 → passed
• examples/release/release-version-contract-smoke.py → passed
• examples/release-artifacts-smoke.py → passed
• release/install focused pytest → 148 passed, 1 conditional skip
• no-clone release verification → passed
• fresh-clone quickstart → passed
• update smoke → passed
• repository hygiene → passed
• generated manpage check → passed
• public/private scan of all seven changed files and the prepared release body → clean
• bilingual release-body usage gate → passed for Steward Team Plan Confirmation, Goal Acceptance Contracts, and Governed Local Delegation

The promotion canary passed its public-boundary, status, usage, and installer stages, then reproduced the current main Dashboard smoke:usage-progress TypeScript failure. #4718 contains the reviewed fix; its rebased exact head passes the focused counterfactual and premerge gate, while final GitHub CI is still running. It remains on the required non-author maintainer merge path. Release publication must wait for that PR to land and for the exact final release commit gates to be rerun.

The release-only live Codex and Doubao qualification credentials are not present in this environment. The default no-cost probes therefore reported skipped; publication must record a passing actual-default live receipt on the exact release commit rather than treating those skips as passes.

Release boundary

This PR only prepares the version identity. After merge, the release operator must bind all qualification receipts to the exact clean merged commit, replace the pending tag target in the prepared release body, create v1.0.6, publish the GitHub Release, verify immutable assets and PyPI, fast-forward stable, read the remote body back through the same release-note gate, and then record the public timeline entry.

Because this PR touches loopx/__init__.py, repository policy requires exact-head review and a non-author maintainer merge. It must not be self-merged.

[huangruiteng]

Approval conclusion (author-owned PR; GitHub blocks formal self-approval)

审阅对象：PR #4721（开放中，未合并），exact head ea115c5db6e534da40b641a74bc22f7d9b4fa955（作者 huangruiteng）。本文是该 exact head 的评审记录。

动机

下一个稳定发布身份要从 1.0.5 推进到 1.0.6 / v1.0.6，而"版本"在 LoopX 里由四处独立表面各自报告：打包元数据（pyproject.toml）、模块常量（loopx/__init__.__version__）、生成的 man 页头，以及中英双语 book 的发布锚点。任何一处落后，都会出现"已安装的包与它自己文档/自述版本不一致"的状态——这正是 named version 契约要防的情况（用户报 issue 时读的就是这个字符串）。

改动思路

只做身份对齐，不夹带任何功能或依赖变化：把六处 LoopX 版本字面量一次改全，并保持 man 页仍是生成物（render_manpage(version=__version__)）而不是手改文件。release 步骤的其余义务——GitHub release body 里可选能力的使用说明与社区贡献者致谢、以及 release-readiness.md 的时间线条目——都不属于本 PR：我查了 v1.0.5 的时间线条目，它是由之后一个独立 commit（"docs(release): record the LoopX 1.0.5 readiness entry"，2026-09-16）补写的，本来就带 tag 与日期，只能在打 tag 之后写。

具体改动

7 个文件、+8/-8。pyproject.toml 与 loopx/__init__.py 各 1 行；man/loopx.1 头行 LoopX 1.0.5 → 1.0.6；docs/book/index.md、docs/book/en/index.md 与两份 00-reading-guide.md 的发布锚点同步（运行前提 Python 3.11+ / Node.js 22.18.0+ 不变）。

我的验证：在评审 worktree 里读回 loopx.__version__ == 1.0.6、pyproject project.version == 1.0.6；man/loopx.1 与 render_manpage() 逐字节一致（10317 字节）且头行是 LoopX 1.0.6；含隐藏文件的全树检索 1.0.5 后逐条确认剩余命中都与 LoopX 包身份无关（pgpass、content-type 依赖钉版，Tauri 桌面端自身版本及其升级 fixture，lark-cli 1.0.56）；cli-version-command-modularization-smoke: ok。

需要点明的一处红：cli-help-manpage-smoke 在本 head 上失败，报 {'unclassified': ['goal-acceptance'], ...}。这是 base 上就存在的 main 失败——我在本 PR 的 merge base（96364a3844c）验证过那里 loopx/help_surface.py 同样没有该条目，而修复它的 PR 是 #4718；本 PR 没有任何 help surface 文件改动，因此不归因于它。

对主干的风险

纯身份字面量替换，无运行时、权限、配额或持久状态影响，回滚即退七文件，且此时 tag 尚未存在、没有需要回收的发布状态。两条有界风险：其一，若将来 bump 只改部分表面，会被 man 页字节比对与版本 smoke 抓到的只有"生成物/CLI"两处，book 锚点仍靠评审兜底（本仓库目前没有把 README/书锚点纳入版本一致性检查）；其二，剪贴"1.0.5"做全局替换时容易误伤第三方依赖版本号——本 diff 正确地没有碰它们。证据边界：我没有构建 wheel、也没有执行 tag 与 release workflow，因此 release body 的能力说明与贡献者致谢门槛仍留在维护者的打 tag 步骤。

我的整体评价

结论 APPROVE。这是一次必要且最小的身份推进：六处一致、生成物仍与生成源逐字节一致、无关的 1.0.5 全部保留不动，并且把"另一处红不是本 PR 造成的"这条归因核实到了 base。它本身不是面向用户的新能力，合并后由维护者打 tag、并在 release body 里补齐能力使用说明与社区贡献者归属即可。合并仍归维护者。

语义与 CI 对齐

判定 reuse_existing：受影响契约是 loopx/__init__.py::__version__、pyproject.toml::project.version、生成物 man/loopx.1 与四份 book 锚点；未新增任何语义或 schema，也未触碰 loopx/semantics/** 的任何注册表。CI 侧：cli-version-command-modularization-smoke 在本 head 通过；cli-help-manpage-smoke 的失败已在 base 复现，属于 #4718 修复的既有 main 缺口，与本 diff 无关。

English verdict: APPROVE - Review of open PR #4721 at exact head ea115c5 (author-owned; recorded as a COMMENTED approval because GitHub blocks formal self-approval). The PR advances the package identity to 1.0.6 across the four independent surfaces that report the LoopX version: pyproject metadata, loopx.version, the generated man page header, and the bilingual book anchors. I read back 1.0.6 from both programmatic sources, confirmed man/loopx.1 is byte-identical to render_manpage() (10317 bytes) with a 1.0.6 header, verified with a hidden-file-inclusive search that every remaining "1.0.5" belongs to another subject (pgpass/content-type pins, the Tauri desktop app version and its update fixtures, lark-cli 1.0.56), and ran cli-version-command-modularization-smoke (ok). One red check is present on this head - cli-help-manpage-smoke reporting {'unclassified': ['goal-acceptance']} - and I verified it is the pre-existing main gap that PR #4718 repairs (the entry is also absent at this PR's merge base 96364a3, and this diff touches no help-surface file), so it is not attributable here. The release-step obligations for the tag (release-body optional-capability guidance, community-contributor attribution, and the release-readiness timeline entry, which for v1.0.5 was added by a separate later commit) are correctly outside this PR and are recorded as boundaries rather than claimed. No blocking finding. Merges remain with the maintainer.