chore(release): prepare LoopX 1.0.4

[huangruiteng]

Release candidate

Prepare the immutable LoopX 1.0.4 release candidate from the latest main.
This change only moves the version identity; no first-screen, hero, or primary
CTA surface changes, so the presentation gate does not apply.

Product groups

• Local authority providers: every provider-first coordination command now
  resolves through one typed local-provider selection seam with File as the
  explicit default, SQLite as an opt-in bounded-retention candidate, and
  PostgreSQL behind service-owned admission and a real-server qualification
  lane.
• State kernel and control plane: Todo ownership, typed update intent,
  declarative decision metadata, monitor configuration, quota scope and receipt
  identity, and canonical lease renewal converge on shared typed owners instead
  of per-caller reconstruction.
• Capabilities and operations: human-confirmed Goal Channel operations, the
  typed Goal lifecycle action catalog, Manager handoff receipts with delegated
  outcomes, and revision-locked Goal/machine settings.
• Hosts and runtime: a Trae App heartbeat host, Node.js 22.18 as the
  enforced minimum, Codex provider SSE and original-session recovery, and Lark
  Card 2.0 callback normalization.
• Review and reliability: review-priority machine configuration, latest
  check attempts per head, exact-head review evidence before merge decisions,
  and delivery-revision-bound completion validation. This release makes no
  benchmark uplift claim.

发布分组

• **本地权威 provider：**所有 provider-first 命令经由同一个 typed provider
  选择边界解析，File 为显式默认，SQLite 为可选启用的有界保留 candidate，
  PostgreSQL 位于 service-owned admission 与真实服务器验证通道之后。
• **状态内核与控制平面：**Todo ownership、typed update intent、声明式 decision
  metadata、monitor 配置、quota scope 与 receipt identity、canonical lease renewal
  收敛到共享 typed owner，不再由各调用方重复推导。
• **能力与运营：**人确认的 Goal Channel operation、typed Goal lifecycle action
  catalog、Manager handoff receipt 与委派结果回传、revision-locked 的 Goal 与
  machine 设置。
• **宿主与 runtime：**Trae App heartbeat host、Node.js 22.18 最低运行时、Codex
  provider SSE 与 original-session recovery、Lark Card 2.0 callback 归一。
• **Review 与可靠性：**review priority machine configuration、按精确 head 选择
  最新 check attempt、merge 决策前的 exact-head review evidence、绑定 delivery
  revision 的完成校验。本版本不宣称 benchmark uplift。

Community Contributors

Prepared by @huangruiteng with @songoow, @LIHUA919, @Duang777, @cocolord,
@BigDataDZ, @xyx2002OvO, @xiaods, @huashuai, @Green-hats, @ehz0ah, @xiaoan17,
and @yilin-succeed. First-time contributors in this range: @ehz0ah, @xiaoan17,
and @yilin-succeed. The release note carries the per-contributor detail.

社区贡献者

本版本由 @huangruiteng 准备，社区贡献来自 @songoow、@LIHUA919、@Duang777、
@cocolord、@BigDataDZ、@xyx2002OvO、@xiaods、@huashuai、@Green-hats、@ehz0ah、
@xiaoan17、@yilin-succeed；其中 @ehz0ah、@xiaoan17、@yilin-succeed 为首次贡献。
逐项贡献说明见 release note。

Validation

• python3 examples/release/release-version-contract-smoke.py
• python3 examples/dev-book-publication-smoke.py
• python3 examples/release/release-readiness-doc-smoke.py

The complete release body is validated with
examples/release/release-readiness-doc-smoke.py --release-notes <file> before
publication, and again against the body read back from the published release.

Type of Change

• Documentation or release metadata only

[huangruiteng]

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

Exact head reviewed: b6d877b0c40eead6f5b3f6cd1b368aede8a46ce0 (re-read immediately before this verdict; unchanged). Review policy revision 3, scope fingerprint of the packet row 4424@b6d877b0c40eead6f5b3f6cd1b368aede8a46ce0.

动机

主分支上 1.0.4 的内容（本地 provider 边界、bounded SQLite 保留、人确认操作、Trae App host、review priority 等）已经合并，但仓库对外身份仍停留在 1.0.3：pyproject.toml、loopx/__init__.py、man page 与开发者手册锚点都还写着 1.0.3。受影响的是每一个 operator——loopx --version、loopx update check/apply 的判定，以及阅读已发布手册的人；compounding cost 是 tag、PyPI 制品与文档身份不一致，导致后续无法验证，并让 update 路径拿错版本比较。before/after 很直接：改前是「1.0.4 的内容 + 1.0.3 的身份」，改后是 packaging 元数据与运行时模块同时为 1.0.4，man page 与手册锚点跟随。更小的修法不成立：不做就等于用 1.0.3 的身份发布 1.0.4 的内容；只改一部分也不行，因为 version-contract 与 publication smoke 会按 pyproject.toml 逐个断言这些标记，部分修改会直接失败而不是静默通过。本次非目标明确：不动依赖、运行时行为、默认值、provider、capability，也不触碰首页/hero 展示面，所以 presentation gate 不适用。

改动思路

入口是 packaging 所有者 pyproject.toml [project].version，运行时镜像 loopx/__init__.py __version__，其余五处是发布锚点（man page 标题、中英手册索引、中英阅读指南）。权威状态只有一个版本串，重复出现的每一处都由既有 smoke 读取，因此决策边界落在 release prep commit 本身，而不是任何运行时模块。消费方与回执同样既有：release-version-contract-smoke.py 绑定 pyproject 与运行时模块，dev-book-publication-smoke.py 把手册锚点绑回 pyproject，release workflow 在干净环境里断言安装后的 CLI 打印 tag 版本。

复用判断：对照上一版 release prep commit 9e7450360（v1.0.3）的文件集合，本次是同一 owner、同一形状，没有引入第二条身份路径；rg -n "1\.0\.3" 扫描后仅剩一条历史 release-readiness 记录和一个无关 npm 包版本。仓库没有共享的版本 bump 工具，为此新增一个自动化机制会比它服务的这次发布更大、更危险，因此不新增。正面路径是 operator 升级后 loopx --version 得到 1.0.4；负面路径是「部分更新」被拒绝（见下节实测）。

具体改动

7 个文件、+8/-8，全部是单串替换，没有控制流、schema、契约或默认值变化；changed_line_classification.behavior_role 因此记为 identity-only。

关键代码讲解

• pyproject.toml:7 [project].version：packaging 权威身份，1.0.3 -> 1.0.4。不变式是必须与 tag 一致，由 version-contract smoke 与 release workflow 的 wheel 断言共同守住；失败时不发布，修复方式是新的 commit + 新 tag，而不是改写已发布制品。
• loopx/__init__.py:5 __version__：运行时身份，"1.0.3" -> "1.0.4"，无逻辑变化。它与 pyproject 必须相等，examples/release/release-version-contract-smoke.py 同时断言两者。
• man/loopx.1:1 .TH LOOPX 1：手册标题身份，LoopX 1.0.3 -> LoopX 1.0.4，属于 publication smoke 家族断言的 release baseline 标记。
• docs/book/index.md:73 LoopX 发布锚点：中文手册锚点，v1.0.3 -> v1.0.4；examples/dev-book-publication-smoke.py（line 431）直接断言该标记文本，下面的负面走查证明不一致会失败。
• 其余三处同类锚点：docs/book/en/index.md、docs/book/chapters/00-reading-guide.md、docs/book/en/chapters/00-reading-guide.md，都是同一身份的发布面，改法一致。

对主干的风险

最强回归场景是「tag 落在一个身份与制品/文档不一致的提交上」，触发条件是部分 bump 或把 tag 打在过期基线上。防止它的代码路径是：同一 head 上的 version-contract 与 publication smoke，加 release workflow 在干净环境中断言 wheel 安装后 CLI 打印 tag 版本。影响半径仅限发布身份与 update 比较，不触及运行时行为、状态或权限面；可观测点是 loopx --version、workflow wheel 检查与三个 smoke；回退方式是新 commit + 新 tag。

负面走查已真实执行：把手册锚点改回 v1.0.3、让 pyproject 保持 1.0.4，再跑 dev-book-publication-smoke.py，得到 AssertionError: index.md: missing release-baseline marker LoopX 发布锚点：\v1.0.4` 且退出码 1，随后恢复文件、git status 干净。比例性方面：问题影响每次安装/更新，失败代价是发布阻断，最小可行修法就是这七处标记，没有新增机制、状态契约或 CLI 表面，维护成本为零，因此判定 proportionate。权限语义上，本 PR 不授予任何 actor、lease、quota 或 promotion 权限；发布权限仍属于维护者的 tag 与 release 动作，docs/product/release-readiness.md` 的 1.0.4 条目按仓库规则在 tag、release note、stable ref 与 canary 一致之后才补。default-off 隔离不适用：diff 中没有任何可选能力、开关、provider 或 host 面，disabled/enabled 路径都没有新增可分叉的对象。

我的整体评价

baseline 与 head 的对比是等价的：除了身份串，运行时语义没有变化；唯一「有意差异」就是 1.0.3 -> 1.0.4。验证结果：release-version-contract-smoke ok、dev-book-publication-smoke ok、release-readiness-doc-smoke ok，同一 head 上 CI 23 项全部通过（含 test-shard 1-4、stage2c e2e/installed/mutants、windows-powershell、node 最低/向前兼容、kernel static checks、dependency review）。代码量 7 文件/+8/-8，verdict necessary。残余风险只有一条：artifact 侧的 wheel 断言要等 tag 之后由 release workflow 执行，本 PR 只能证明 source 侧身份；因此后续 tag、release note、stable ref 与 readiness 条目仍需按顺序完成。结论：APPROVE。

English verdict: APPROVE for 4424@b6d877b0c40eead6f5b3f6cd1b368aede8a46ce0 — a seven-file, +8/-8 release-identity bump that keeps packaging, the runtime module, the man page and the developer-book anchors on one 1.0.4 identity; the strongest risk (tagging a partially bumped tree) is falsified by an executed negative walkthrough that fails dev-book-publication-smoke.py with a missing-marker assertion, and the same head passes the three release smokes plus the full CI gate. The only residual gap is that the installed-wheel identity assertion runs in the release workflow after the tag exists.