docs(release): record the LoopX 1.0.4 readiness entry

[huangruiteng]

Summary

Records the promoted v1.0.4 release in docs/product/release-readiness.md,
after the matching tag, release note, stable ref, update path, and focused
release canary all agreed.

The ledger entry describes the shipped surfaces and cites only PRs merged inside
the v1.0.3..v1.0.4 range:

• bounded local authority storage: compact operation deltas plus periodic
  checkpoints, separated storage/head/continuity integrity, one idempotent
  fail-closed V1 -> V2 migration with a plan/execute operator command
  (refactor(authority): bound the retained sqlite state log #4408, fix(sqlite): retain fast COUNT and add D2 qualification checks #4328, feat(coordination): add opt-in SQLite authority provider #4121);
• PostgreSQL authority admission as a service-owned boundary whose authority
  ladder runs against a real server in CI (feat(postgresql): add service-owned admission and restore-incarnation rotation #4334, ci(postgresql): qualify the authority path on a real server #4399);
• human-confirmed Goal Channel operations whose review decision travels with the
  operation (feat(lark): add human-confirmed Goal Channel operations #4275, refactor(presentation): share operation review semantics in TypeScript #4364, Add typed Goal lifecycle action catalog #4132);
• Todo, quota, lease, monitor, and decision-scope rules converging on shared
  typed owners (feat(todos): close canonical ownership update boundary #4273, refactor(todo): typed update intent and scope semantics #4289, refactor(todo): migrate declarative decision metadata #4292, feat(coordination): support canonical lease renewal #4348, refactor(todos): canonicalize Monitor configuration and plan local defaults #4351).

Validation

• examples/docs-governance-smoke.py ok
• examples/repository-hygiene-smoke.py ok
• every cited PR number verified as MERGED and inside the
  v1.0.3..v1.0.4 commit range (squash merges included)

[huangruiteng]

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

队列前言（loopx pr-review --state open --limit 200，complete=true，policy_revision=3，other-developers-first）：49 个 open PR 中 28 个需要处理。本卡覆盖 rank 28 的 #4431——authenticated_developer_owned、tier 2，且属于 author-owned PR（GitHub 不允许正式 self-approve，故以 COMMENTED 记录与 APPROVE 相同的结论）。下一张待办是 rank 1 的 #4341。

结论先行：在这个 exact head 上通过。 这是一次纯文档追加：把已发布的 v1.0.4 写进公开的 release readiness ledger，+15/−0，既有条目逐字节未动。

动机

v1.0.4 已经发布完成：tag b6d877b0c 上的 release body 已公开，11 个资产全部上传，三条发布工作流（Release Artifacts、Desktop Release Artifacts、Signed Desktop Updates）均为 success，stable 也从 0496975e（v1.0.3）快进到 b6d877b0c；下载回来的 wheel 版本与 SHA256SUMS 一致。但 docs/product/release-readiness.md 的最新条目仍停在 v1.0.3。

这不是「少写一行文档」而已。该文件在正文里明确要求：只有 tag、release note、stable ref、update path 与 focused release canary 全部一致后才在此登记，因此它的最新条目就是仓库侧的 canonical 发布索引。它停在 v1.0.3 的代价是可测的：任何审计者想知道 v1.0.4 到底发布了哪些面，只能手工翻 v1.0.3..v1.0.4 区间里的 107 个 PR，而发布叙事已经从公开owner 上消失。改动前后的对比很直接——before 视图里 v1.0.4 不存在，after 视图里它是一条带日期、tag 与引用清单的条目。

更小的修法我逐一排除过：什么都不做会让 ledger 永久缺失一次已完成的晋升；只改 GitHub release body 不够，因为远端 release body 不是仓库侧记录，clone 下代码的人仍然看不到；新增 CHANGELOG 或索引则是凭空造第二个 owner。该文件已经被 examples/release/release-readiness-doc-smoke.py 绑定为这道记录的唯一入口，所以在一行里补齐就是最小修法。

改动思路

入口是 docs/product/release-readiness.md 的 release ledger 列表；它被根 README、docs/index.md 与 product index 链接，并由 examples/release/release-readiness-doc-smoke.py 解析断言。权威输入不是这份文档，而是已经发生的发布事实：tag b6d877b0c、已发布的 release body、stable ref，以及区间内已合并的 PR 集合。决策 owner 依旧归打包元数据、tag 与 stable；文档只叙述一个已经做出的决定，不参与任何运行时判定，也不构成第二份真值——它引用 tag 与 PR 编号，而不是重新计算或复制那些事实的权威副本。

所有权代价被刻意压到最低：没有新增章节、字段、生成器、索引或 smoke，只是把一条 bullet 追加到既有列表末尾，并沿用 v1.0.3 条目的句式（日期 +08:00、tag 短哈希、发布面分组、产物核验声明）。正向路径是读者顺着 tag 与引用走到已发布的面上；负向路径则是引用错位——所以本轮不是相信 diff，而是从 release 区间重新推导了引用集合（详见下节与风险节）。

具体改动

1 个文件 +15/−0：docs/product/release-readiness.md 追加一条 v1.0.4 条目，其余部分完全未改（0 deletions，v1.0.3 段落逐字节保持）。

关键内容讲解

1. 首行绑定发布身份：v1.0.4 on 2026-09-15 14:19 +08:00 配合 tag 短哈希 b6d877b0c，与既有条目同形，让 ledger 的一行可以直接对应到一个 tag，而不是靠时间推断。
2. 三组发布面引用：#4408, #4328, #4121 对应 opt-in SQLite authority provider 的保留状态日志有界化（紧凑操作 delta + 周期 checkpoint）、storage/head/continuity 三层完整性分离、以及 V1 → V2 单次幂等 fail-closed 迁移与 plan/execute 操作命令；#4334, #4399 对应 PostgreSQL authority admission 成为 service-owned 边界、其 authority ladder 在 CI 里跑真实服务器；#4275, #4364, #4132 对应 human-confirmed 的 Goal Channel 操作，review decision 随操作本身走而不再按界面重新推导；#4273, #4289, #4292, #4348, #4351 对应 Todo、quota、lease、monitor 与 decision-scope 规则收敛到共享的 typed owner。
3. 末句与既有条目一致地声明产物核验：wheel、sdist、macOS、Windows、checksum、signed update 与 PyPI 均声明「在 stable 快进前已对照精确 release 源核验」，与 v1.0.3 条目同一句式。
4. 引用口径可复核：13 个引用我逐个解析过，全部为 MERGED 且落在 v1.0.3..v1.0.4 区间内。这里有一个容易误判的细节值得一提：只用 git log --merges 扫区间时其中 8 个（#4328、#4121、#4275、#4364、#4273、#4289、#4292、#4348）看起来「不在区间里」，原因是它们是 squash 合并而非 merge commit；把它们当成引用错误会得出相反结论。

对主干的风险

最强回归场景是「ledger 宣称了某个并未随 v1.0.4 发布的表面或 PR」，触发状态是从错误窗口抄来引用，或条目写在 tag 真正晋升之前——此时这份公开审计文件会变成误导性证据。影响面严格限于公开文档：没有运行时、打包或控制面路径，风险是解释性与信誉性的，不是运行时的。可观测性来自 smoke 退出码与渲染文本；回滚就是 revert 单个 commit 178bff007，文件回到只含 v1.0.3 的状态，无需后续收尾；最小修复是在同一条 bullet 内改正或删除该引用。

这里有一个必须点明的证据边界：现有 smoke 只断言这份文档被正确接线、且包含必需字符串，因此引用写错时它们照样会通过。所以本轮没有依赖它们来证明引用正确性，而是用真实边界重新推导：git log 0496975e..b6d877b0c（含 squash）加 gh pr view N --json state,mergedAt，13 个引用全部 MERGED 且在区间内。这条口径目前没有自动门禁，属于残余风险而非缺陷。

三道门禁在 head 178bff007 上均通过：release-readiness-doc-smoke ok、docs-governance-smoke ok、repository-hygiene-smoke ok。远端 checks（Sign-off、dependency-review、build、changes）在 review 时仍为 pending，其中 DCO 由本地 git log -1 --format=%(trailers) 直接确认（Signed-off-by 存在）。

我的整体评价

可观测语义是明确的新增而非漂移：同一份文件在 base 上最新条目是 v1.0.3，在 head 上出现 v1.0.4 条目，而既有条目逐字节未变；没有默认值、契约或能力被触碰。体量与问题相称到近乎平凡——一条 bullet、零新抽象、零新 smoke、零第二份真值，因此不构成「用文档膨胀掩盖产品变化」的形态。残余风险有两条，都不阻塞：引用口径缺少自动校验；以及条目末句「已对照精确 release 源核验」属于对发布轮证据的复述（当轮的 wheel 名称/版本与 SHA256SUMS 一致性已单独验证），本 PR 不重新证明产物身份。综合以上，本卡给通过结论；合并仍需单独跑 --check-merge-readiness 并走 loopx-pr-merge，本评论不构成合并授权。

English verdict: APPROVE at exact head 178bff0 — a docs-only, +15/−0 ledger entry that records the already-published v1.0.4 release (tag b6d877b0c, stable fast-forwarded from 0496975e) and leaves every earlier entry byte-unchanged. Validation on this head: release-readiness-doc-smoke ok, docs-governance-smoke ok, repository-hygiene-smoke ok, DCO trailer present; all 13 cited PR numbers independently re-resolved as MERGED inside v1.0.3..v1.0.4 (eight are squash merges, which is why a merge-only scan appears to miss them). No blocking findings. Residual risk: the citation set is verified manually rather than by a repository smoke that derives it from the tag range, and the artifact-identity claim restates the release round's verification rather than re-proving it here.