我感觉这个和“管家rfc”有点像，只是给管家增加了主动式的能力，看看要不要把这个rfc融合进管家rfc里

Exact-head review: #5384

Reviewed head: a7cd97d30e7bfb4735825ea487d456d97da29463; immutable base: f49b4a00870604d39fa4318da24d6dd35e72bb6e.

阻塞点：

1. [P1] 先对齐现有管家 RFC 的规范归属。 当前 head 尚未回应维护者在同一 head 的设计评审。独立检查也支持这个问题：已有 capable-manager-semantic-handoff-v0 §5.2/§5.3 定义 manager、typed coordination 和 scoped standing grants，§5.11 定义长期来源责任、receiver assessment、artifact/correction 与既有 schedule/event 路径。本 PR §5、§10、§11 重述这些 lifecycle/permission/return 约束，并引入 M1–M3，却没有链接管家 RFC 或将它们映射到其 canonical acceptance/checkpoint。只声明“不引入平行里程碑”不能消除两个规范 owner。请把通用持续跟进、准备/返回和授权约束归并到既有管家 RFC（同步中英文），这里保留有价值的 Lark 来源解释、个人 profile/use case 和评测计划，明确共享 acceptance 的对应关系；或者提出具体的独立边界与字段/验收映射，经维护者接受后再保留独立 RFC。无需把这个文档 PR 扩成完整产品实现。
2. [P2] 修复本 PR 引入的 docs-governance 回归。 base 的 uv run --extra test python examples/docs-governance-smoke.py 通过；head 在新增 RFC 的 mirror 检查失败：英文没有 semantic mirror，中文没有 语义镜像。独立执行 scripts/generate_rfc_status_index.py --check，base 通过、head 失败；两个 STATUS 的新行仍是 —，但新增 execution ledger 已有一条，应生成 [1 entry] / [1 条]。请补充双向语义镜像声明，并在最终 ledger 后重新生成两份索引，再跑上述两项。不要只依赖 index generator 的 13 个单元测试：它们通过不等于提交中的索引是最新的。

动机

个人消息中识别承诺、跟随截止时间变化、准备材料，并在原桌面对话返回可核查结果，确有普通用户价值。本 RFC 对错认责任人、把摘要当完成、重复 ingestion 和未授权发送这些风险有具体讨论。问题不是“文档尚未实现”，而是这些新增使用场景应如何扩展已经接受的管家方案；合入后的有效设计必须有一个可追溯规范 owner，否则后续作者需要同时同步两套流程和验收。

改动思路

设计复用 lark-event-inbox、manager-context、periodic-report、canonical User/Agent Todo 与原对话返回；Lark 是 optional provider，不新增 connector capability。提出完整 TS/TSX + Node 路径，包括 adapter/test；Python-only 依赖需在最小 cohesive owner 迁移后取得 parity，不能偷偷加 bridge。文档明确 merge 不授予账号读取、自动发送、部署或实现完成，这些边界应保留。

共享 lifecycle 与权威应由既有管家、work-item、App continuity owner 管理；Lark-specific commitment interpretation、来源覆盖与个人 attention-cost pilot 则适合作为该方案的 profile/use-case。README、总体 roadmap、STATUS、office use-case 入口必须指向同一设计基线，不应在索引把尚未对齐的独立方案直接当成另一个 canonical owner。

具体改动

全 PR 十个文件：双语 RFC 定义责任/来源、reviewed mutations、纠错/撤销/replay、原对话返回、完整 TS 实现约束、评测和 M1–M3；双语 ledger 记录 #5385 的 CLI prerequisite 和未交付部分；RFC README、两份 STATUS、两份总体 roadmap、office use-case README 更新发现入口。没有 runtime、schema、设置 UI 或账号接入代码。

关键内容讲解

• §5 的 proposal→canonical User Todo→linked Agent preparation→evidence lineage 能防止把 Agent 完成当个人承诺完成；source/model 不能授予 authority。但通用部分需要关联管家 RFC 的同一 owner，而不止链接 implementation README。
• §9 的 frozen labels、责任人错误零容忍、precision/recall、changed-deadline 和七日 attention-cost 对照，是有价值的 Lark/profile 验收；这是 proposed qualification，不能拿 scripted CLI 当真实来源或 packaged desktop 成功。
• §11 的 M1 包含 frontend/Lark/CLI/correction/brief，M2 包含 artifact+restart+同对话 return，M3 包含 pilot/outage；完整 exit 比仅 serializer 更好，但需要与现有 manager acceptance/checkpoint 对应。
• Appendix B / 双语 ledger 诚实写明 #5385 不是完整 M1：没有 durable proposals、desktop adoption、live-provider qualification 或 packaged readback。作者记录的 91 个测试不是本评审执行结果，也不证明上述产品旅程。

正向设计 walkthrough 是 owner 选择来源→review proposal→应用 canonical Todo→授权准备→原对话核验；失败 walkthrough 是错责任人/撤销授权/重复来源/过期 deadline→拒绝或保留 proposal、无自动外发、通过既有 owner 修复。两者当前只是设计边界；没有将其称为已安装产品验证。

对主干的风险

即时 runtime 风险低，因为只是 docs；规范被接受后长期风险是同一 standing grant、任务返回和 schedule 规则出现双重解释。最小修复是 canonical ownership 与验收映射，不是再造 provider framework，也不是增加人工批准层。语义镜像及 stale ledger 索引则已经造成可复现仓库检查回归。

我实际执行：RFC index tests 13 passed；456 个 changed-doc relative link targets 存在；十文件 public-boundary scan 和 whitespace 通过。相同 docs-governance 与 index check 在 immutable base 通过、head 失败，属于本 PR 回归，不是无关 CI。生成器的 expected diff 仅显示新 ledger 行需从 — 改为一条链接。未查询/等待远端 CI，未运行 #5385 runtime、真实 Lark/model、packaged desktop 或七日 pilot，文档也没有声称它们完成。

我的整体评价

REQUEST_CHANGES。值得保留个人场景、source lineage、冻结评测和 attention-cost 验收，但当前设计归属尚未证明与已接受管家契约一致。未来重构 pass 建议在本 PR 压缩重复规范：共同 lifecycle 放回已有 owner，Lark/个人使用与评测留在有界文档及既有 ledger；无需新增跟踪体系。修复设计映射、双语声明和生成索引后重新做整包 review；现有维护者异议仍有效，不应撤销。

English verdict: REQUEST_CHANGES - a7cd97d30e7bfb4735825ea487d456d97da29463: reconcile the design with the accepted capable-manager RFC and its acceptance/checkpoints; fix bilingual mirror declarations and stale ledger status indexes. Native docs-governance/index checks pass on the immutable base and fail on this head. No runtime delivery or merge claim.

@huangruiteng 已在 620beb87c217e0ea675b6b6748f89856d731fd8a 修复本 PR 的两个问题；已同步当前 main ba443e2b9。

P1：规范归属已归并。 原 personal-follow-through-v0 双语 RFC 收敛为 Superseded 历史入口；管家 RFC 加入对应替代声明及 §5.11.1。飞书责任/截止时间解释、隐私、纯 TS/Node 要求、冻结语义评测和七日注意力成本试用保留在双语 profile。共享授权、状态、恢复、准备/返回沿用管家及既有 typed owner，场景逐项映射 A3/A5–A10/A13–A15/A20 与 M1–M4；原个人 M1–M3 仅保留历史含义。README、roadmap、STATUS 和 office 入口同步对齐。历史 ledger 未改写，新归并记录放入管家 ledger。

P2：本 PR 的镜像及索引回归已修复。 已补双向 semantic mirror / 语义镜像声明，两份 STATUS 与既有生成器 collect/render 输出逐字节一致，个人历史 ledger 为 1 条，管家 ledger 为 2 条。

验证结果：

• RFC index tests：13 passed。
• 全部 RFC mirror、ledger convention 检查通过。
• 559 个改动文档本地链接目标、公共/私有边界扫描、whitespace 检查通过。
• 已实际运行完整 docs-governance smoke 和 index --check，两者仍失败。在未修改的最新 main ba443e2b9 复跑，失败相同：external-evidence-research-capability-v0 的中英文正文含日期 checkpoint 标题。该问题来自这次同步的主干，不再是本 PR 的个人 RFC 镜像或索引错误。--write 被该标题错误阻止，因此使用同一生成器的 collect/render API 生成索引，未修改生成器或绕过最终检查，也未宣称全库通过。

最终提交的 Standards 与 Spec 两路复核均未发现本次修复的剩余阻塞项。相关有界重构是删除重复规范归属，保留具体场景；没有 runtime、权限实现或默认行为变更。#5385 的模拟外部服务测试不构成真实飞书/模型或安装版桌面验收，本 PR 不关闭这些门槛。

English verdict: APPROVE for the documentation correction on this exact head; the full repository documentation checks remain blocked by the independently reproduced current-main header errors. This self-review does not dismiss the maintainer's prior REQUEST_CHANGES or authorize merge. Please re-review the consolidated design; no self-merge performed.

Reviewer: model_agent; gpt-6.1-sol; OpenAI; runtime_reported; reasoning effort xhigh

Exact head: 620beb87c217e0ea675b6b6748f89856d731fd8a; immutable diff base: ba443e2b9d096f5e6ec3c710ef68143ffff73448. Re-review also read both prior blocking reviews on a7cd97d30e7bfb4735825ea487d456d97da29463 and the whole current PR.

动机

维护和实现个人跟进场景的开发者，需要一个明确的通用规范归属。个人承诺跟进原提案重复定义管家已有的授权、持续工作和返回规则；本次将共享规则归回管家，只保留飞书来源解释和评测场景。当前文档已形成双向替代声明、共享验收映射及一致发现入口，旧镜像和索引回归已消除。个人承诺识别、改期与准备材料有具体价值，但后续实现不能同时遵循两套同义授权/恢复规则。不宣称真实飞书账号、模型语义质量、安装版桌面返回或完整管家验收完成。持久提议接入、真实来源/身份与模型资格、安装版桌面返回和场景试用仍由现有管家/work-item、personal-workspace 及 Lark extension owner 完成。

改动思路

归并后的通用生命周期、standing grants、准备、恢复与原会话返回仍由已接受的 capable-manager 与既有 typed owner 负责。原个人 RFC 成为历史 Superseded 入口，管家声明对应替代，飞书场景保留责任/截止时间解释、来源覆盖、隐私、纯 TS/Node 和冻结评测。此边界满足维护者要求的单一规范 owner，同时保留有价值的具体场景，而非删除整个使用需求。

最强反对意见是新 profile 继续暗中创建第二验收计划。我逐项对照改动前管家：profile 将场景映射到现有 A3/A5–A10/A13–A15/A20 及 M1–M4，原个人 M1–M3 仅历史名称；没有新 runtime status、scheduler 或 approval layer。一个 profile fixture 通过明确不能关闭整行 manager acceptance。

具体改动

整包十六文档 +501/-10，包括两份历史入口、两份场景 profile、管家双语新增 §5.11.1、双语 ledger、两份 STATUS、发现索引及 roadmap/office 路由。没有 runtime、权限实现、设置或账号操作。

关键内容讲解

• 原 personal-follow-through-v0 双语头部为 Superseded，指向 manager；manager 双语 Supersedes / closes 回指原提案。实现者因此能找到同一权威，而不是另一个可 claim 的个人规范。
• profile 的共享归属表对照既有授权、纠正、receipt、artifact 与 return owner；承诺是否完成仍须本人决定/既有可核验 criterion，对方验收不能被 Agent 草稿代替。
• 激活、私有报告、断开和来源撤回沿用现有 scope/revoke/retention/outbox；source/model text 不能授权外发。Off-state 和完整 packaged journey 是提案验收要求，不是本 docs PR 的安装 readback。
• 冻结至少 100 条消息/30 项承诺、precision/recall 和七日 attention-cost pilot 被标为尚未测量的 profile 目标。#5385 的 scripted 外部响应、CLI 与测试数量保留为历史，不能关闭产品或 live/provider gate。

spec_ref docs/architecture/rfcs/capable-manager-semantic-handoff-v0.md，spec_revision ba443e2b9d096f5e6ec3c710ef68143ffff73448。按改动前 §5.2、§5.3、§5.11 核验单一 owner、权限与长期义务；当前文本映射满足这个文档纠正。A3/A5–A10/A13–A15/A20、M1–M4 的实际执行仍 deferred，未改写其 pass condition，也未声称部署完成。

旧 review 的 P1 与初始维护者异议已由 reciprocal consolidation、profile 映射及整包发现入口解决。P2 原 mirror 与 stale index 也独立解决：双向 semantic mirror/语义镜像声明存在，个人 ledger 一条、管家两条，两份 STATUS 与现有 collect/render 的输出逐字节相等。旧 head 年龄不是这个结论的依据。

对主干的风险

未发现当前文档 PR 的剩余阻塞项。即时 runtime 风险低，真正需守住的是以后不能拿 docs 归并或 CLI 演示宣称完整 profile。场景 payload 仍放在既有 proposal lifecycle，共享 canonical User/Agent Todo 与 receipt；来源缺失、撤权、错误责任人和并发纠正都要求实际 owning boundary 的测试。本文未把拟议评测阈值调整成已测通过结果。

实际本地检查：RFC status tests 13 passed；所有 RFC semantic mirrors 和 ledger conventions passed；559 个改动文档 local links 存在；十六文件 private-boundary 与 diff whitespace pass；提交的双语 STATUS 完全匹配同一生成器输出。首次命令误写测试路径，未跑到测试；已在 tests/architecture/test_rfc_status_index.py 正确复跑，保留错误与修正记录。

完整 docs-governance smoke 和 index --check 仍失败。相同命令在未修改 ba443e2b9d096f5e6ec3c710ef68143ffff73448 与 620beb87c217e0ea675b6b6748f89856d731fd8a 都仅报告 unchanged external-evidence-research-capability-v0 的中英文 dated checkpoint body headings。这些文件、generator 和 smoke 不在 diff，失败 signature 相同；changed invariant 独立通过。因此它是主干已有文档债，不应要求本主题扩大修复，也不宣称完整检查 green。未查询或等待 CI，未执行 live Lark/model、安装桌面或七日试用。

语义与 CI 对齐

规范关系复用既有 owner 与 durable acceptance IDs；局部 profile 没有新增并行生命周期 vocabulary。README、roadmap、STATUS 与 office route 均指向一致边界；历史 ledger 保留而现阶段证据归 manager ledger。公共链接和未来 proposed gates 不是账户权限、部署或工作完成回执。

我的整体评价

APPROVE，交付判断为 justified_increment。long_horizon improved：未来同一授权/恢复变更只需维护一个规范 owner；user_experience improved：用户结果、私有范围与尚缺旅程由同一 profile 解释，不要求运行态额外确认或配置。本次可独立 review/revert，但不完成管家父级验收。

未来重构 pass 在本 PR 应用为规范压缩和归并，保留有界 Lark 场景，而非增加第二 framework。旧两份 blocking reviews 的全部 finding 已实证解决，可依现有 owner 授权和实际 GitHub dismissal 权限做原生 closeout，保留讨论与验证；HTTP 成功后仍需 DISMISSED readback。合并是独立维护者步骤，本审查不自合并。

English verdict: APPROVE
The whole exact head resolves the prior normative-owner, mirror and stale-index findings. One accepted manager owns shared lifecycle and acceptance; the Lark profile preserves scenario detail without closing live or packaged gates. Full documentation checks remain red on identical unchanged main checkpoint headers, independently reproduced at base and head. No CI consultation or merge.