docs(rfc): record the shipped steward team intake and its multi-agent linkage

[huangruiteng]

Problem

The Steward Team Intake section of the steward host-selection RFC still described
the work as planned: it said the preview slice came next, that no materializer was
registered, and that the apply slice was future work. Those slices have shipped as
#4519 (contract and validator), #4522 (Chat admission) and #4524 (apply through the
canonical Todo owner), and one docstring in the governed-proposal owner still repeated
the old claim that this kind has no materializer and no settlement phase. The RFC
therefore contradicted the code it points at, and it recorded no relationship to the
multi-agent contracts the intake sits on top of.

What changed

• The section now states what is enforced and where: kind steward_team_plan_preview
  (steward_team_plan_preview_v0), the 8-lane limit, the P0..P3 priorities, the gap
  vocabulary (agent_not_registered, capability_not_granted, audience_not_authorized),
  declined_first_todo on a lane that cannot be staffed, and applies: false in the
  validated payload.
• It records the three shipped enforcement points with their commits: the validator, the
  admission gate that requires team_plan_context, and the PRE_SETTLEMENT apply that
  re-validates against the Goal's registered Agents and the shipped advancement action
  kinds before it creates any lane Todo (and does nothing for a gap lane).
• It states the part that is not done, so the section cannot be read as a delivered
  feature: nothing supplies team_plan_context in production yet, a confirmed Chat
  preview still needs the bridge into the governed capability journal's
  transition_proposals, the published receipt carries the first lane Todo's identity
  rather than every lane it created, and a multi-lane preview has no frontend
  confirmation surface yet. The receipt one is called out as a compatibility decision,
  because that receipt field set is closed and persisted.
• It places the intake against the multi-agent contracts: a user-layer affordance over
  the kernel defined by multi_agent_three_layer_minimality_contract_v0, joining
  multi_agent_visible_launcher_v0 by identity (goal, agent, first lane Todo) under the
  launcher's own rule against a leader agent, hidden scheduler, promotion authority or
  second source of truth.
• The mirrored Chinese edition carries the same content, and the stale validator
  docstring now describes validation as the one contract used at both ends.

Changed surfaces

• docs/architecture/rfcs/harness-selection-dsh-pi-v0.md,
  docs/architecture/rfcs/harness-selection-dsh-pi-v0.zh-CN.md (RFC section).
• loopx/control_plane/work_items/governed_transition_proposal.py (docstring only; no
  behavior change).

Validation

• examples/docs-governance-smoke.py: ok.
• tests/test_steward_team_plan_preview.py, tests/test_steward_team_plan_apply.py,
  tests/capabilities/test_steward_executor_machine_defaults.py: 19 passed.
• loopx canary premerge --from-git-diff: merge_gate_passed=true,
  self_merge_allowed=true, manual_holds=0; failures 0, one advisory inherited
  failure (examples/control_plane/control-plane-maintainability-ratchet-smoke.py,
  baseline, does not mention the changed files). Public boundary check passed on all
  three changed paths.

Boundaries

Documentation and one docstring only: no runtime behavior, no authority, no default
change. The RFC states residual gaps rather than presenting them as delivered, and it
records the receipt-readback gap as a compatibility decision instead of silently
widening a persisted contract.

[huangruiteng]

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

一、变更内容

• RFC（英文 harness-selection-dsh-pi-v0.md 与中文镜像）中的「管家团队入端口径」一节：标题去掉「规划中」，正文从"预览片是下一步、尚未注册 materializer"改为记录已经落地的三层强制点（校验器 #4519 / 3acd07697、聊天准入 #4522 / 3c8c832cb、PRE_SETTLEMENT 落地 #4524 / c159a15b3），并写明 kind 与 schema、8 条 lane 上限、P0..P3 优先级、gap 词表、declined_first_todo、applies: false。
• 同一节如实写明尚未完成的部分：生产上还没有任何调用方传 team_plan_context；被确认的 Chat 预览还缺进入受治理能力 journal transition_proposals 的那座桥；已发布回执只带第一条 lane Todo 的身份；多 lane 预览还没有前端确认面。其中回执那条被标注为兼容性决策，而不是未知项。
• 新增「与 multi-agent 契约的关系」小节：把入端口径定位为 multi_agent_three_layer_minimality_contract_v0 内核之上的用户层便利，并说明它与 multi_agent_visible_launcher_v0 按身份（goal、agent、lane 首个 Todo）相连，而不是互相调用；launcher 自己那条"不得成为 leader agent / 隐藏调度器 / 晋升权威 / 第二真源"的规则对入端口径同样成立。
• governed_transition_proposal.py：只改 docstring。原文写"该 kind 没有 materializer、没有结算相位"，与已落地的 PRE_SETTLEMENT 落地相矛盾；新表述说明校验是同一条契约用在两端（准入用它决定是否浮现，落地用它带宿主事实再次校验）。

二、依据与一致性

• 依据是已合并的三个 commit 与当前代码事实（STEWARD_TEAM_PLAN_LANE_LIMIT=8、STEWARD_TEAM_PLAN_GAP_REASONS、applies: false、_SETTLEMENT_PHASE_BY_PROPOSAL_KIND 中的 PRE_SETTLEMENT、_apply_team_plan 里的重新校验与 add_goal_todo 调用）。
• 与仓库文档治理一致：中文镜像同步更新，docs-governance-smoke 通过；被引用的 multi-agent 协议文档以仓库内相对路径引用，链接可解析。
• 与"未获调用的抽象留在设计态"的仓库规则一致：本次不新增任何命令、能力或 builder，也不把尚未接线的预览写成已交付特性。
• 边界：只动文档与一句 docstring，无运行时行为变更、无权限变更、无默认值变更。

三、验证

• examples/docs-governance-smoke.py：ok。
• tests/test_steward_team_plan_preview.py、tests/test_steward_team_plan_apply.py、tests/capabilities/test_steward_executor_machine_defaults.py：19 passed。
• loopx canary premerge --from-git-diff：merge_gate_passed=true、self_merge_allowed=true、manual_holds=0、failures 0；1 条 advisory 继承失败 examples/control_plane/control-plane-maintainability-ratchet-smoke.py（基线失败、未提及本 diff 文件，按门禁要求在此记录，不阻断）；public boundary 在三个改动路径上全部通过。

四、风险与残余缺口

• 文档描述的是"代码此刻的状态"，若接下来的接线切片改了 kind 语义或结算相位，本节必须同步更新；这是文档型变更的常规维护成本，不是隐藏风险。
• 回执只带第一条 lane Todo 这一条缺口本次没有修：回执字段集是封闭的（set(receipt) != _RECEIPT_FIELDS 即报错）且被持久化在 journal 里，扩字段需要一次显式的兼容性决定（TS 侧把 transition_receipts 当不透明数组透传，所以是 Python 侧有界变更）。本节把它写成待决项，而不是宣称已回读全部 lane。
• 同样未做且已写明：team_plan_context 的生产接线、Chat 确认到受治理 journal 的桥、多 lane 预览的前端确认面。

五、结论

批准以 admin squash 合并且以文档变更对待（self_merge_allowed=true）。改动单一目的、可回滚、无行为与权限变化；它修正的是"文档与已落地代码相互矛盾"这一具体问题，并把剩余接线显式留作后续切片。

English verdict: Approved for an admin squash merge. Documentation-only plus one docstring: the RFC section no longer describes shipped enforcement as planned work, it now names the three enforcement points with their commits, states the wiring and receipt gaps as open, and records how the intake relates to the multi-agent contracts instead of implying a second team runtime. Docs governance smoke passes, 19 focused tests pass, and the canary premerge gate passes with one unrelated advisory baseline failure.

[huangruiteng]

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

动机

这次改动修的是一个真实的自相矛盾：RFC 的 Steward Team Intake 一节仍写着"规划中"，说预览片是下一步、没有注册 materializer、落地片是未来工作，而它所指向的代码早已把这三种强制点都落地了（#4519 校验器、#4522 聊天准入、#4524 PRE_SETTLEMENT 落地）；同一 kind 的 docstring 也复述了"没有 materializer、没有结算相位"这个已经过时的说法。设计文档与它引用的代码不一致，代价不是美观问题：这条工作线的下一处改动会照着文档去错误的 owner（或重新实现一遍已落地的契约），而且读者会误以为在 Chat 里要一个团队现在就能建成 lane。

改动目标（把那节改成"已强制什么、在哪里强制、什么仍是惰性、还缺什么"，并补上与 multi-agent 契约的关系）与文档实际存在的缺口一致，没有顺手扩到运行时行为、schema 或前端。

改动思路

作者没有新开一页文档或新造协议 id，而是就地重写既有的那一节，并且以"交付顺序 + commit"的方式把已落地的三片串起来——读者可以顺着 3acd07697 / 3c8c832cb / c159a15b3 直接到代码里核对，这是文档能自我校验的关键。

特别值得肯定的是"惰性"那段：它明确写出线上仍是 inactive（没有任何生产调用方传 team_plan_context），并列出两处仍缺的缺口，而不是把"契约已存在"讲成"能力已可用"。这与仓库"不要用文档把未完成说成已完成"的要求一致。事实性描述也做了收窄：原来写"quota 或节奏包络"，现在写"quota 包络"，与校验器里只接受 quota_envelope 一致；原来只说"类型化 gap"，现在点名三个 gap 码。

另外把 governed_transition_proposal.py 里那句过时 docstring 一起改掉是对的：它和 RFC 说的是同一件事，只改文档会留下代码继续自我否认。

具体改动

两个语言版本同步重写该节：标题去掉"planned"，三种强制点各带 commit，gap 词表、8 条 lane 上限、P0..P3、applies: false 写进正文，新增 "Relationship to the multi-agent contracts" 小节，把入端口径与 multi_agent_three_layer_minimality_contract_v0、multi_agent_visible_launcher_v0 按身份（goal_id、agent_id、lane 首个 Todo）相连；validate_steward_team_plan_preview 的 docstring 改成"准入与 PRE_SETTLEMENT 落地调的是同一份契约"。三文件 +147/-59，其中唯一的代码文件改动只发生在 docstring 内（+8/-5 行文本），没有任何可执行行变化。

我按 head 75d4fa18、base 27d05257 逐条核对了文中事实：STEWARD_TEAM_PLAN_LANE_LIMIT = 8、STEWARD_TEAM_PLAN_PRIORITIES = (P0..P3)、三个 gap 码、applies: False、STEWARD_TEAM_PLAN_PREVIEW_KIND -> PRE_SETTLEMENT 的相位映射、_apply_team_plan 内确实重新调用 validate_steward_team_plan_preview、chat.py::_validated_team_plan_preview 缺 team_plan_context 即返回 None 且正文仍到达业主，全部与文字一致；三个 commit 也都能对上。跑 examples/docs-governance-smoke.py → ok，pytest tests/test_steward_team_plan_preview.py tests/test_chat_manager_context.py → 29 passed，git diff --check 干净。

一个 P3（非阻塞，已记入 findings）：英文与中文那节都写成"配不齐的 lane 会把没配上人的工作留在 declined_first_todo"。这只对自动派生出的 agent_not_registered lane 成立；lane 自己声明 staffing_gap 时，校验器是拒绝 first_todo 并落到 {staffing: gap, gap_reason_code, gap_note}，没有 declined_first_todo。我在 head 上直接跑了一遍：capability_not_granted 的 lane 返回 gap_note，未知 Agent 的 lane 返回 declined_first_todo。代码是对的，参数化测试也覆盖了两条分支，问题只是散文把一条分支的字段推广到了三个码上——把这句收窄（agent_not_registered 对应 declined_first_todo、声明 gap 对应 gap_note）会让记录精确，因为这一节正是业主可见回读的设计依据。

顺带说明：本节列出的"回执只带第一条 lane Todo"缺口，在这个 head 上是准确的，#4528 随后既修了代码也把这一行从两个语言版本里删掉了——这属于按序交付的正常自我修复，不是文档漂移。

对主干的风险

风险极低且可完全回滚：diff 里没有一行可执行代码变化，唯一的代码文件改动在 docstring 内，因此不存在运行时行为、schema、权限、quota 或持久状态被改动的可能。文档治理 smoke 通过，中英两版同步更新，没有新增文档页、协议 id、命令或能力。

唯一需要留意的就是上面那条 P3：文档比代码多讲了一点，读者若照此实现回读投影，可能期待声明 gap 的 lane 也带结构化的工作文本。它不影响任何运行时路径，blast radius 限于文档准确性。

我的整体评价

这是一次方向正确、边界克制的文档修复：问题来自真实的文档/代码矛盾，修法沿用既有 owner 与既有名称，不新造页面或协议，把"已强制 / 仍惰性 / 还缺什么"讲清楚，并让读者能沿 commit 自行核对。中英两版同步、docs-governance-smoke 绿灯、引用事实逐条可验，验证证据与结论一致。

那条 P3 建议作为后续一句文案修正处理（把 declined_first_todo 与声明 gap 的 gap_note 分开表述），不构成合并阻塞。

English verdict: APPROVE (exact head 75d4fa1)