docs(rfc): record the live remote-source coverage acceptance

[huangruiteng]

Why

The steward-readiness table in this RFC is the document that says which steward-channel behaviours a milestone may rely on. Its M2 row recorded that "a provider read failure surfaces as raw error text instead of a typed source row". Two shipped changes moved that, and until now nobody had checked the answer rather than the code — which is exactly what the owner asked for after two live complaints ("ssh 没读到" and "下次没 kinit 这种原因要能反馈给管家").

What The Live Acceptance Showed

A manager-channel session on the running local service (release 20260916T123949Z, serving revision 55ebbc6b7, executor dsh, profile deepseek-v4-flash@high) was asked a question that requires its declared remote source. The answer:

• named the one declared remote source it read, and kept that read's freshness visible;
• stated its evidence window and the bounds it applied (per-day and total receipt caps, included versus omitted counts);
• listed the remote rows it included and how many Goals it excluded as stopped;
• said that hosts it did not read are outside coverage, and explicitly refused to present the remote Goal as having made no progress — the failure mode the owner complained about;
• separated "recorded, not independently verified" from verified results throughout.

What This Records

A dated subsection next to the table: the typed remote-source cause plus its repair supersedes the "raw error text" clause, the typed per-source coverage and freshness property the M2 row asked for is now accepted from a live read, and the other two halves of M2 (receiver resolution across registered running lanes, and a goal-level milestone the report can lead with) stay open.

It also states the honest limits of that evidence: this is a live channel read, so it is a recorded procedure rather than a CI job, and the failure half still needs an unreadable source to exercise — the observed run was the success path, where the source read cleanly.

Public-safe: no transcript, no audience identity, no dated incident, no operator-local path, no host name. English and Chinese stay in step.

Validation

• python3 examples/docs-governance-smoke.py — passed (RFC bilingual mirror, link and nav reachability).
• loopx canary premerge --from-git-diff — passed: diff hygiene, 4 catalog canaries (including the semantic-vocabulary and frontstage projection smokes), 8 risk-profile smokes, and the public/private boundary scan over exactly the two changed docs. One advisory: the known baseline maintainability ratchet.

[huangruiteng]

Approval conclusion (author-owned PR; GitHub blocks formal self-approval)
Reviewed exact head: e8a0e4fb67be96890c7564b1d4f1115263d44899

English verdict: APPROVE

动机

本 RFC 的"按里程碑看管家通道的就绪度"表是"某个里程碑现在可以依赖管家通道哪些行为"的依据文档；它的 M2 行写着"provider 读取失败以原始错误文本出现在回答里，而不是 typed 来源行"。两项改动已经改变了这一点，但从来没人验收过"回答本身"（只验收过代码）——而业主两次现场抱怨（"ssh 没读到"、"下次没 kinit 这种原因要能反馈给管家"）要的恰恰是回答层面的行为。

改动思路

• 以现场读取为证据，而不是代码推断：在本机运行中的管家通道上提问一个需要其已声明远端来源的问题（发布 ，服务修订 ，执行器 ，profile ）。
• 只记录产品契约级结论，不记录会话内容：不写原文、不写受众身份、不写带日期的具体事故、不写 operator 本机路径、不写主机名（与本节既有的公共边界声明一致）。
• 明确写出这次证据的边界：这是现场通道读取，不是 CI 任务；且这次观察到的是来源读取成功那一半，失败那一半还需要一个真正读不到的来源才能复现。

具体改动

• docs/architecture/rfcs/harness-selection-dsh-pi-v0.md（+26）与 .zh-CN.md（+18）：在 M2 表后新增 Remote-source coverage acceptance (2026-09-16) 小节，记录：typed 远端失败原因 + 修复动作取代"原始错误文本"；现场验收到的回答行为（点名实际读到的已声明来源并保留其新鲜度、说明证据窗口与所施加上限、列出纳入的远端行与排除的已停用 Goal、明确未读取的主机属于覆盖之外而不是"没有进展"、"已记录"与"已独立核验"分开表述）；以及 M2 另外两半仍然开放。

对主干的风险

1. 纯文档：不改代码、不改默认行为；新增内容是对已发生验收的记录，并与既有表格明确互为补充（不删旧行，避免改写历史结论）。
2. 公共/私有边界：新增文本已通过 loopx check 精确扫描；其中没有主机名、会话 id、原文或本机路径。
3. 是否夸大：本 PR 明确把这次验收限定在"来源读取成功"这一半，并点名失败那一半仍需可复现条件；没有把 M2 整行标为已实现（接收者解析与目标级里程碑仍开放）。
4. 双语一致性：中英同步新增同一小节，docs-governance-smoke 通过。

我的整体评价

正向且 proportional：44 行、单一目的，把一次真实验收固化成可引用的产品级结论，并诚实标注了证据边界。

验证：docs-governance-smoke 通过；canary premerge 通过（diff hygiene、4 个 catalog canaries、8 个 risk-profile smokes、公共/私有边界扫描；唯一 advisory 为已知基线 maintainability ratchet）。

作为作者自有 PR，GitHub 不允许正式 self-approve，故以本 COMMENTED review 作为放行结论。

[huangruiteng]

Approval conclusion (author-owned PR; GitHub blocks formal self-approval)
Reviewed exact head: e8a0e4fb67be96890c7564b1d4f1115263d44899

English verdict: APPROVE

(This review replaces the previous comment, whose code spans were mangled by an unquoted heredoc.)

动机

本 RFC 的"按里程碑看管家通道的就绪度"表是"某个里程碑现在可以依赖管家通道哪些行为"的依据文档；它的 M2 行写着"provider 读取失败以原始错误文本出现在回答里，而不是 typed 来源行"。两项已交付改动改变了这一点，但从来没人验收过"回答本身"（只验收过代码）——而业主两次现场抱怨（"ssh 没读到"、"下次没 kinit 这种原因要能反馈给管家"）要的恰恰是回答层面的行为。

改动思路

• 以现场读取为证据，而不是代码推断：在本机运行中的管家通道上提问一个需要其已声明远端来源的问题（发布 20260916T123949Z，服务修订 55ebbc6，执行器 dsh，profile deepseek-v4-flash@high）。
• 只记录产品契约级结论，不记录会话内容：不写原文、不写受众身份、不写带日期的具体事故、不写 operator 本机路径、不写主机名（与本节既有的公共边界声明一致）。
• 明确写出这次证据的边界：这是现场通道读取，不是 CI 任务；且这次观察到的是来源读取成功那一半，失败那一半还需要一个真正读不到的来源才能复现。

具体改动

• docs/architecture/rfcs/harness-selection-dsh-pi-v0.md（+26）与 .zh-CN.md（+18）：在 M2 表后新增 Remote-source coverage acceptance (2026-09-16) 小节，记录：typed 远端失败原因 + 修复动作取代"原始错误文本"；现场验收到的回答行为（点名实际读到的已声明来源并保留其新鲜度、说明证据窗口与所施加上限、列出纳入的远端行与排除的已停用 Goal、明确未读取的主机属于覆盖之外而不是"没有进展"、"已记录"与"已独立核验"分开表述）；以及 M2 另外两半仍然开放。

对主干的风险

1. 纯文档：不改代码、不改默认行为；新增内容是对已发生验收的记录，并与既有表格明确互为补充（不删旧行，避免改写历史结论）。
2. 公共/私有边界：新增文本已通过 loopx check 精确扫描；其中没有主机名、会话 id、原文或本机路径。
3. 是否夸大：本 PR 明确把这次验收限定在"来源读取成功"这一半，并点名失败那一半仍需可复现条件；没有把 M2 整行标为已实现（接收者解析与目标级里程碑仍开放）。
4. 双语一致性：中英同步新增同一小节，docs-governance-smoke 通过。

我的整体评价

正向且 proportional：44 行、单一目的，把一次真实验收固化成可引用的产品级结论，并诚实标注了证据边界。

验证：docs-governance-smoke 通过；canary premerge 通过（diff hygiene、4 个 catalog canaries、8 个 risk-profile smokes、公共/私有边界扫描；唯一 advisory 为已知基线 maintainability ratchet）。

作为作者自有 PR，GitHub 不允许正式 self-approve，故以本 COMMENTED review 作为放行结论。