docs(release): record the LoopX 1.0.5 readiness entry

[huangruiteng]

Record the promoted v1.0.5 release in the readiness ledger.

The entry is added after the matching tag (0c3971fea), the GitHub release note, the stable fast-forward, and the focused release canary all agreed. It cites only PRs merged inside the v1.0.4..v1.0.5 range and describes the shipped surfaces: the registration-only first-connect contract, explicit managed-host and steward-executor selection, and the update/runtime reliability fixes.

Validation: examples/release/release-readiness-doc-smoke.py — ok (docs-only change; no runtime behavior, adapter, permission, or public-evidence boundary change).

[huangruiteng]

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

Exact head reviewed: e69479ee0 (re-read immediately before this verdict; codex/release-readiness-v1.0.5 at fa8a0b35b). Review policy revision 3.

动机

v1.0.5 已经发布：tag 0c3971fea、GitHub release body、stable ref、wheel/sdist/checksum 与 PyPI 制品都已落到同一个 release commit 上。仓库的 release readiness ledger 里还停在 v1.0.4 条目，读者无法从这份权威记录看到 1.0.5 发布了什么、依据哪次验证。受影响的是依赖 ledger 判断「哪个版本可信、为什么」的 operator 与后续维护者；compounding cost 是公开历史里出现一个已发布但无记录的版本，下一轮发布无法引用上一轮的验证口径。before/after 很直接：改前 ledger 最后一节是 1.0.4，改后增加 1.0.5 条目并引用 tag SHA 与区间内 PR。更小的修法不成立：不写就等于让 ledger 与实际发布状态不一致；写在 tag 之前则违反仓库既定顺序（tag、release note、stable ref、canary 全部一致后才补记录），也拿不到准确的 tag SHA。

改动思路

唯一被改的权威表面是 docs/product/release-readiness.md 的 promoted-release 列表；条目位置、句式与字段沿用 1.0.4 条目（v1.0.4 on <时间> … at the matching tag (b6d877b0c) … artifacts were verified against the exact release source before stable fast-forwarded）。决策边界是「记录事实」而不是「创造事实」：条目只陈述已经发生并可被公开验证的状态——tag 名与 SHA、区间内 PR 编号、制品校验与 stable 快进。复用判断：没有第二处需要同步的发布记录，docs/update-notes/ 是双周摘要而不是按版本条目（1.0.4 也未新增），因此不新增文件、不改模板、不动 smoke。正面路径是读者从 ledger 追到 tag、PR 与制品；负面路径见下节（写入尚未发布的版本会被 gate 拒绝）。

具体改动

1 个文件、+22 行，纯文档新增，没有控制流、schema、契约或默认值变化；changed_line_classification.behavior_role 记为 documentation-only。

关键内容讲解

• docs/product/release-readiness.md 新增 v1.0.5 条目：时间、主题（首连登记式契约 + 显式 host 选择 hot-fix）、v1.0.5 tag 与短 SHA 0c3971fea，并把主体改动归因到区间内 PR：首连契约与 harness（#4465）、托管 Turn host（#4443、#4451）、steward executor（#4446、#4419）、PR review CI 等待（#4452、#4434）、不可变 source commit 资格与 runtime 身份（#4460、#4423）、quota window clamp（#4384）、held fence（#4429）、frontier 诊断（#4341），以及社区贡献的 #4396、#4398、#4428、#4372、#4433、#4453、#4442。
• 归因只使用 v1.0.4..v1.0.5 区间内已合并的 PR：区间由 git log v1.0.4..origin/main 的 merge commit 与 squash 形式的 (#N) 后缀合并得到，共 43 个 PR，其中社区贡献 22 个（12 位作者）。未列出 @huangruiteng，符合仓库对社区贡献小节的边界要求。
• 末尾沿用既有句式记录制品验证：wheel、source distribution、checksum 与 PyPI 制品在 stable 快进前已按精确 release source 验证。本次实际制品为 loopx-1.0.5-py3-none-any.whl、loopx-1.0.5.tar.gz、SHA256SUMS 与桌面产物（dmg/msi/exe/app zip/sig/updater），PyPI 1.0.5 的 wheel/sdist 已可读取。

对主干的风险

最强回归场景是 ledger 里出现一条与真实发布不一致的记录（错误 tag、错误 SHA、或引用未合并 PR），它不会破坏运行时，但会污染公开历史并误导后续发布判断。防止它的路径是条目在 tag、release note、stable 与 canary 全部一致之后写入，并且只引用区间内 PR；可观测点是 examples/release/release-readiness-doc-smoke.py 与公开 tag/PR 元数据；回退方式是 revert 这一个文档 commit。影响半径仅限文档可信度，不触及运行时行为、状态、权限或制品。负面走查由一个独立事实核对完成：条目的 tag 0c3971fea 与 origin/stable 当前值一致、与 release 的 targetCommitish 一致；列出的 43 个 PR 全部来自 v1.0.4..v1.0.5 区间。比例性：问题的代价是公开记录失真，最小可行修法就是这一条记录，新增机制、状态契约或 CLI 表面为零，判定 proportionate。权限语义不适用（不新增 actor/authority/coordination 语义）；default-off 隔离不适用（没有可选能力或开关）。

验证结果：examples/release/release-readiness-doc-smoke.py ok；loopx canary premerge --from-git-diff --timeout-seconds 400 0 failures（8 个 catalog canary、8 个 risk-profile smoke、public-boundary loopx check --scan-path docs/product/release-readiness.md、direct diff checks 全过）；同一 head 上 CI 的必需检查全部通过（文档变更下大多数 job 按路径跳过，merge-gate 与 Sign-off、build、dependency-review 通过）。

我的整体评价

这是一条只记录已发生事实的账本条目，与 1.0.4 条目同形同位置，不引入新机制。baseline/head 对比中唯一差异就是新增条目本身；代码量 1 文件/+22，verdict necessary。残余风险只有一条：条目描述的是发布事实，若后续对 1.0.5 做补丁发布，需要新的 tag 与新条目，而不是改写这一条。结论：APPROVE。

English verdict: APPROVE for e69479ee0 on codex/release-readiness-v1.0.5 — a one-file, +22-line documentation-only ledger entry that records the already-published v1.0.5 (tag 0c3971fea, matching stable, matching release target commit) with PR attribution restricted to the v1.0.4..v1.0.5 range and the same grouping, ordering and artifact-verification sentence as the v1.0.4 entry. No runtime, schema, default, permission or artifact change; the strongest risk (a record that disagrees with the real release) is bounded by the tag/stable/target-commit agreement check and by examples/release/release-readiness-doc-smoke.py, and the same head passes a clean loopx canary premerge --from-git-diff (0 failures across 8 catalog canaries, 8 risk-profile smokes and the public-boundary scan) plus the required CI checks. Residual risk: any later 1.0.5 patch needs its own tag and its own ledger entry rather than an edit to this one.

[huangruiteng]

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

Exact head reviewed: e69479ee0c9466bf80c662a4f7d5fdfd4e11def3 on codex/release-readiness-v1.0.5 (base fa8a0b35b, re-read immediately before this verdict). Review policy revision 3.

动机

v1.0.5 已经发布：tag 0c3971fea、GitHub release body、stable ref、wheel/sdist/checksum 与 PyPI 制品都已落到同一个 release commit 上。仓库的 release readiness ledger 里还停在 v1.0.4 条目，读者无法从这份权威记录看到 1.0.5 发布了什么、依据哪次验证。受影响的是依赖 ledger 判断「哪个版本可信、为什么」的 operator 与后续维护者；compounding cost 是公开历史里出现一个已发布但无记录的版本，下一轮发布无法引用上一轮的验证口径。before/after 很直接：改前 ledger 最后一节是 1.0.4，改后增加 1.0.5 条目并引用 tag SHA 与区间内 PR。更小的修法不成立：不写就等于让 ledger 与实际发布状态不一致；写在 tag 之前则违反仓库既定顺序（tag、release note、stable ref、canary 全部一致后才补记录），也拿不到准确的 tag SHA。

改动思路

唯一被改的权威表面是 docs/product/release-readiness.md 的 promoted-release 列表；条目位置、句式与字段沿用 1.0.4 条目（v1.0.4 on <时间> … at the matching tag (b6d877b0c) … artifacts were verified against the exact release source before stable fast-forwarded）。决策边界是「记录事实」而不是「创造事实」：条目只陈述已经发生并可被公开验证的状态——tag 名与 SHA、区间内 PR 编号、制品校验与 stable 快进。复用判断：没有第二处需要同步的发布记录，docs/update-notes/ 是双周摘要而不是按版本条目（1.0.4 也未新增），因此不新增文件、不改模板、不动 smoke。正面路径是读者从 ledger 追到 tag、PR 与制品；负面路径见下节（写入尚未发布的版本会被 gate 拒绝）。

具体改动

1 个文件、+22 行，纯文档新增，没有控制流、schema、契约或默认值变化；changed_line_classification.behavior_role 记为 documentation-only。

关键内容讲解

• docs/product/release-readiness.md 新增 v1.0.5 条目：时间、主题（首连登记式契约 + 显式 host 选择 hot-fix）、v1.0.5 tag 与短 SHA 0c3971fea，并把主体改动归因到区间内 PR：首连契约与 harness（#4465）、托管 Turn host（#4443、#4451）、steward executor（#4446、#4419）、PR review CI 等待（#4452、#4434）、不可变 source commit 资格与 runtime 身份（#4460、#4423）、quota window clamp（#4384）、held fence（#4429）、frontier 诊断（#4341），以及社区贡献的 #4396、#4398、#4428、#4372、#4433、#4453、#4442。
• 归因只使用 v1.0.4..v1.0.5 区间内已合并的 PR：区间由 git log v1.0.4..origin/main 的 merge commit 与 squash 形式的 (#N) 后缀合并得到，共 43 个 PR，其中社区贡献 22 个（12 位作者）。未列出 @huangruiteng，符合仓库对社区贡献小节的边界要求。
• 末尾沿用既有句式记录制品验证：wheel、source distribution、checksum 与 PyPI 制品在 stable 快进前已按精确 release source 验证。本次实际制品为 loopx-1.0.5-py3-none-any.whl、loopx-1.0.5.tar.gz、SHA256SUMS 与桌面产物（dmg/msi/exe/app zip/sig/updater），PyPI 1.0.5 的 wheel/sdist 已可读取。

对主干的风险

最强回归场景是 ledger 里出现一条与真实发布不一致的记录（错误 tag、错误 SHA、或引用未合并 PR），它不会破坏运行时，但会污染公开历史并误导后续发布判断。防止它的路径是条目在 tag、release note、stable 与 canary 全部一致之后写入，并且只引用区间内 PR；可观测点是 examples/release/release-readiness-doc-smoke.py 与公开 tag/PR 元数据；回退方式是 revert 这一个文档 commit。影响半径仅限文档可信度，不触及运行时行为、状态、权限或制品。负面走查由一个独立事实核对完成：条目的 tag 0c3971fea 与 origin/stable 当前值一致、与 release 的 targetCommitish 一致；列出的 43 个 PR 全部来自 v1.0.4..v1.0.5 区间。比例性：问题的代价是公开记录失真，最小可行修法就是这一条记录，新增机制、状态契约或 CLI 表面为零，判定 proportionate。权限语义不适用（不新增 actor/authority/coordination 语义）；default-off 隔离不适用（没有可选能力或开关）。

验证结果：examples/release/release-readiness-doc-smoke.py ok；loopx canary premerge --from-git-diff --timeout-seconds 400 0 failures（8 个 catalog canary、8 个 risk-profile smoke、public-boundary loopx check --scan-path docs/product/release-readiness.md、direct diff checks 全过）；同一 head 上 CI 的必需检查全部通过（文档变更下大多数 job 按路径跳过，merge-gate 与 Sign-off、build、dependency-review 通过）。

我的整体评价

这是一条只记录已发生事实的账本条目，与 1.0.4 条目同形同位置，不引入新机制。baseline/head 对比中唯一差异就是新增条目本身；代码量 1 文件/+22，verdict necessary。残余风险只有一条：条目描述的是发布事实，若后续对 1.0.5 做补丁发布，需要新的 tag 与新条目，而不是改写这一条。结论：APPROVE。

English verdict: APPROVE for e69479ee0c9466bf80c662a4f7d5fdfd4e11def3 on codex/release-readiness-v1.0.5 — a one-file, +22-line documentation-only ledger entry that records the already-published v1.0.5 (tag 0c3971fea, matching stable, matching release target commit) with PR attribution restricted to the v1.0.4..v1.0.5 range and the same grouping, ordering and artifact-verification sentence as the v1.0.4 entry. No runtime, schema, default, permission or artifact change; the strongest risk (a record that disagrees with the real release) is bounded by the tag/stable/target-commit agreement check and by examples/release/release-readiness-doc-smoke.py, and the same head passes a clean loopx canary premerge --from-git-diff (0 failures across 8 catalog canaries, 8 risk-profile smokes and the public-boundary scan) plus the required CI checks. Residual risk: any later 1.0.5 patch needs its own tag and its own ledger entry rather than an edit to this one.