docs: establish the LoopX overall product and delivery roadmap

[huangruiteng]

Problem and result

LoopX direction is spread across RFCs, product plans and capability contracts. Recent steward slices also left conflicting maturity claims and gaps between confirmed team plans and actual work. This docs-only PR establishes a bilingual LoopX overall roadmap covering all 30 existing primary RFCs, important non-RFC domains, 13 portfolio streams, G0–G5 product milestones and R1–R7 executable core delivery cards.

Multi-LoopX-Agent collaboration is a core product gate: parallel joins, pipeline dependencies, peer help/review, semantic handoff, execution responsibility continuation and cross-host recovery. Real peer handoff is required in the first small-team milestone. Product, kernel/TS, authority, managed hosts, frontend/Lark, memory/materials, budget/fleet, extensions, privacy, reliability, research, releases, community and adoption have explicit next slices and acceptance boundaries.

The roadmap retains the source-backed steward assessment and corrects affected RFC checkpoints and technical-direction navigation. It incorporates the newer #4569 lane-gap/card changes. Domain RFCs retain authority and migration gates; S/G/R identifiers are planning references, not new runtime state. No provider promotion, new permissions, runtime fixes or resource launches are included.

Validation

• 185 focused tests passed after rebasing onto f1166e81e; the earlier audit separately records its 177-test baseline and four synthetic commitment/recovery counterexamples.
• Documentation governance/link validation passed; both mirrors cover all 30 existing primary RFCs and all S/G/R identifiers.
• Explicit public-boundary scan of 22 documentation paths and diff hygiene passed; one unrelated pre-existing local history-index warning remains outside this diff.
• Exact-scope change-quality receipt passed. Final risk-based premerge and exact-head review are recorded below before merge.
• No production code, installed skills, UI implementation or configuration changed. Existing frontend/Lark entrypoints are future acceptance subjects, so no packaged browser, live model/cloud, Lark or PostgreSQL qualification is claimed for this documentation batch.

Future-facing review: compressed competing progress narratives and reused domain owners; avoided new state, protocols and one-off retained text-matching tests. The broader roadmap scope is deliberate; implementation remains bounded by individual task acceptance and existing policy.

[huangruiteng]

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

评审 head：4d79b9c5d74b28e033d17b44a0d4f39ef907076d；base：main（merge-base 0aa6179de，已包含 #4572）。该 PR 在本轮 review 期间 head 曾前进（97759d054 → 4d79b9c5d，内容是把 #4572 的记录并入并 rebase 到新 main），本 review 的全部结论都在当前 head 上重新执行过。

动机

在改前，产品与交付的"当前状态"散落在多个索引与 RFC 正文里：RFC 索引、选择 RFC、technical-directions 各自维护一部分边界，而且文档自己记录的 F7 已经点名了三处互相矛盾的陈述——manager RFC 仍写着"delivery 是 proposal"、选择 RFC 仍写着"没有 frontend confirmation surface"、authority 引言仍写着 service admission 未交付，而别处段落已经在报告已交付进展。

后果是路由成本：贡献者要读完若干索引才能判断"哪件事已交付、哪件被门槛挡住、下一步该做哪张卡"，并且存在重复做或漏掉 gap 的风险。

更小的修法（只改正那三行）解决不了这个问题——它仍然没有"跨域排序"的 owner，下一位读者还得重新拼装。用一份路线图来承担排序与审计、同时把 domain RFC 保留为权限与验收 owner，是能解决该问题的最小结构。

改动思路

新的双语路线图 docs/architecture/rfcs/loopx-overall-roadmap-v0.md(+.zh-CN) 把既有 30 份主 RFC 与重要非 RFC 域映射到 13 条 stream、G0–G5 里程碑与 R1–R7 执行卡，并在第 8 节记录 steward 交付审计（F1–F7 及其后继卡）。索引层做三件事：RFC 索引增加路线图条目并改正四条状态边界；technical-directions 压缩成"指向路线图 + 保留贡献路由"；选择 RFC 把陈旧进度叙述收敛掉。

边界写得很清楚，也是我认可这份设计的关键：domain 契约（alignment、authority store、TS owner、capability gate）仍是各自权威；文档明确"合并本文档既没有完成 R1–R7，也没有提升任何 Draft 决策"，第 8 节也明确"运行期修复仍未完成，本次只是文档变更"。

具体改动

22 个文档文件、+877/-408：两份 324 行的双语路线图、约 120 行的索引与路由更新，以及选择 RFC 与 technical-directions 以删减为主的重写（-206/-139、-15/-13）；其余是 7 组 RFC 中每条 1–3 行的状态校正。

关键代码讲解

docs/architecture/rfcs/README.md 新增路线图条目，并把"Delivery on main"改写为可核验的边界（例如共享权威那一条从"No provider-first runtime promotion…has shipped"改成"In-process PostgreSQL service admission and identity rotation also exist; deployed authenticated remote service and provider promotion remain distinct qualification gates"）。这类改写正是 F7 要消除的"多处当前真相"。

docs/project/technical-directions.md 保留贡献路由，把跨域排序让渡给路线图，并显式声明"S streams / G milestones / R cards 不替代 domain 契约或真实 Todo"——这条免责是必要的，否则路线图会变成第二个权威。

第 8 节的 F1–F7 表用"可复用事实 / 未建立什么"两列组织，并给出代码路径（如 governed_transition_proposal.py::_apply_team_plan、chat_actions.py::_registry_fingerprint）与后继卡（R1/R4），最后声明 177 条测试只是局部证据、不是全仓或 live 资格。这是文档里最容易变成"自我表扬"的部分，作者按证据与缺口分开写了。

对主干的风险

最强回归是"路线图变成不会被刷新的第二权威"：一旦 domain 变更合并而路线图不更新，读者会同时看到两套说法。防线目前只有文档自己写下的 update-in-place 规则和索引里的审计日期——docs-governance-smoke 检查的是信息架构（root docs、导航结构），不检查状态句子的真伪，所以这条风险是真实存在的，属于维护纪律而非本 PR 的缺陷。

我做了三项独立核验：其一，路线图声称覆盖全部既有主 RFC——我用文件清单与第 4 节表格做了集合比较，30 行 ↔ 30 份主 RFC 完全对应（唯二未映射的是 TEMPLATE.md 与路线图自身）；其二，新写入的状态声明有代码支撑——postgresql_authority_service.ts 明确是 in-process service admission、postgresql_authority_store.ts 带 identity rotation 结果码，loopx/capabilities/reliability_diagnostics/README.md 记录了 L1 shadow observer 与首个 DSH event-source；其三，双语一致性（两份 22 个标题）、私有上下文扫描（新增行没有内部链接、本地路径或凭据）。

实测：docs-governance-smoke ok；docs-asset-integrity-smoke ok（6 个资产，PNG 哈希互异）。未跑：三份 mkdocs build --strict（本机没装 mkdocs，ModuleNotFoundError）——CI 的 frontstage-pages 是权威运行，且本 PR 未触碰 mkdocs 配置与导航清单。另注意该 PR 与 main 的关系：head 已 rebase，但合并前仍需按当时 head 重新确认。

P3（非阻塞）：第 8 节把 F1–F4 标为 P0/P1（计划声明的 priority 在 list_goal_todos 丢失、陈旧 intent basis 仍被接受、空成功被报成 applied、部分提交无对账），后继指向 R1。我在公开 issue 里没有搜到对应的 open 追踪项，所以这些 P0 目前只存在于文档。建议给 F1–F4 挂一个受跟踪的 agent/owner 条目（issue 或 Todo），或第 7 节直接写明由哪条 lane 承担修复。

我的整体评价

baseline（0aa6179de）与 head（4d79b9c5d）对比：从"多处索引各自维护当前真相"变成"一份 owner 明确的路线图 + domain 契约保留权威"，三处被点名的矛盾陈述被改成带剩余门槛的表述，且没有删除任何既有文档、没有改动导航配置。文档级检查全绿，声称的覆盖与状态声明经我独立抽样核对成立。

对文档类改动而言，这份 diff 的体量与收益匹配：新增两篇双语权威文档，其余基本是删减与对齐（净效果是压缩，而不是追加）。风险是维护纪律（路线图的准确性没有机器门禁），这一点已在上面作为残余风险与 P3 写明。结论：按当前 head 通过 review，非阻塞建议一条。

English verdict: APPROVE - exact head 4d79b9c; this docs batch establishes one bilingual overall roadmap (13 streams, G0-G5, R1-R7, all 30 primary RFCs mapped) and corrects the three contradictory status statements its own F7 named, while leaving domain contracts as the authority. Independently verified: 30/30 RFC coverage by set comparison, added status claims backed by shipped code (in-process PostgreSQL service admission/identity rotation; L1 diagnostics with a DSH event source), 22/22 bilingual headings, no private context in the added lines, docs-governance and docs-asset-integrity smokes green. Not verified locally: the three strict MkDocs builds (mkdocs absent here; CI frontstage-pages remains authoritative). One non-blocking P3: the audit's P0 findings F1-F4 are documented but not linked to any tracked open item.