fix(steward): teach the team procedure to name its Goal and its receipt

[huangruiteng]

Problem

The team preview contract requires the plan to name the Goal it staffs (#4532), and the confirmation
now arrives as a typed team.plan action (#4535). The shipped steward guidance said neither, so a
preview authored by the steward would be refused for the missing Goal, and the model had no way to
know that a confirmation arrives from the product surface rather than from itself. With every other
part of the intake in place, this was the last reason it would still never fire in practice.

What changed

The shipped loopx-manager guidance now:

• requires naming the exact Goal the plan staffs, and says that a plan that does not name it, or
  that names a Goal outside the authorized scope, is dropped instead of shown;
• states that the owner's confirmation arrives as one typed team-plan action from the product
  surface, and that the steward never creates lanes itself;
• forbids claiming that a lane exists, or that a team is running, before the apply receipt
  returns — including when the confirmation was refused or the plan went stale because the Agents
  it named changed.

The RFC notes the same requirement in both editions.

Validation

• tests/test_manager_team_plan_guidance.py (extended with the new markers and the existing ordering
  assertions), tests/test_steward_team_plan_preview.py, tests/test_chat_team_plan_action.py:
  18 passed.
• examples/docs-governance-smoke.py: ok.
• examples/loopx-steward-managed-chat-smoke.py: ok (real dsh segment completes with the updated
  guidance).
• loopx canary premerge --from-git-diff: merge_gate_passed=true, self_merge_allowed=true,
  failures 0.

Boundaries

Guidance and tests only: no new authority, no new field, no behavior change in the contract or the
apply path. The guidance describes the contract that already ships, which is why the change is
small.

[huangruiteng]

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

一、变更内容

• loopx/capabilities/manager_context/skills/loopx-manager/SKILL.md（出厂管家指引）三处补齐：
  1. 要求点名确切 Goal，并写明"不点名 Goal、或点名超出授权范围的 Goal 的计划会被丢弃而不是展示"；
  2. 写明业主确认是"来自产品面的一个 typed team-plan action"，管家自己永不建 lane；
  3. 新增诚实性规则：在 apply 回执返回前，不得声称某条 lane 已存在或团队已在运行；确认被拒或计划因点名的 Agent 变化而 stale 时，要如实说明。
• tests/test_manager_team_plan_guidance.py 增加对应断言（保留原有的顺序断言）。
• RFC 双语各加一句：出厂指引要求计划点名其 Goal。

二、依据与一致性

• 这是"契约已就位但最后一公里缺失"的具体问题：#4532 让预览必须点名 Goal（否则校验器拒绝），#4535 让确认走 team.plan typed action；而指引两者都没说，因此管家写出的预览会被拒、模型也不知道确认从哪来——intake 在实践上仍不会触发。
• 与既有指引结构一致：仍然先预览后生效、gap 如实命名、经 canonical owner 落地、不为预览扣额度；本次只把"要点名 Goal"和"回执才算成立"补进同一段。
• 与仓库"文档与代码一致"规则一致：指引描述的就是已经 ship 的契约，故改动很小；同时 RFC 也被同步，避免出现第三份说法。

三、验证

• tests/test_manager_team_plan_guidance.py（新增标记断言）、tests/test_steward_team_plan_preview.py、tests/test_chat_team_plan_action.py：18 passed。第一次改写把原有的 charge quota for the preview itself 折行拆断，被该测试自身抓到并已修（保留原标记在单行）。
• examples/docs-governance-smoke.py：ok；examples/loopx-steward-managed-chat-smoke.py：ok（真实 dsh segment 用更新后的指引仍完整跑完）。
• loopx canary premerge --from-git-diff：merge_gate_passed=true、self_merge_allowed=true、failures 0。

四、风险与残余缺口

• 风险低：只改指引文本与断言，不动契约、不动落地路径、不加字段。
• 仍是"指引而非机器强制"：模型是否真的点名 Goal 取决于它遵守指引；但验证层已经是机器强制——不点名就会被准入丢弃，因此这条指引的偏离是可观测的，而不是静默通过。
• 仍未做：前端确认面；lane Todo 的意图修订绑定。

五、结论

批准以 admin squash 合并（self_merge_allowed=true）。它把"契约已备但实践不触发"这一具体缺口补上，且没有引入任何新权限或新状态。

English verdict: Approved for an admin squash merge. The shipped steward guidance now requires naming the exact Goal the plan staffs (a plan without it is dropped rather than shown), states that the owner's confirmation arrives as one typed team-plan action from the product surface, and forbids claiming a lane or team exists before the apply receipt returns. 18 focused tests pass with the new markers, both smokes pass, and the canary premerge gate is green.

[huangruiteng]

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

动机

漂移描述得准确：团队预览契约要求计划点名 Goal（#4532），确认又以类型化 team.plan action 抵达（#4535），而出厂的管家指引两件事都没说——模型实际遵循的那份指令面还在描述已被取代的流程。代价正是前几片刚关掉的那类失败：模型写出没点名 Goal 的预览，准入会把它丢掉，而模型不知道为什么，只能反复重试；更糟的是指引没有禁止"确认前就宣称 lane 已存在"。

改动思路

三处修补都直接对应一个具体漂移，而不是泛泛加强语气：

• 点名 Goal：写清"计划必须点名所配人的确切 Goal"，并给出后果——不点名、或点名了授权范围外的 Goal，会被丢弃而不是展示。这正是校验器与准入的实际行为，所以是描述强制而非新增强制。
• 确认通道：明确确认以"产品面发出的一个类型化 team-plan action"抵达，且管家自己从不建 lane，从而把"谁写 lane"钉在 canonical owner 上。
• 回执边界：确认前不得声称 lane 已存在或团队在运行，必须等 apply 回执返回；被拒或计划因所点名的 Agent 变化而 stale 时，就如实说明。这条是面向模型回答的指引，文本也确实是这么表述的。

具体改动

loopx/capabilities/manager_context/skills/loopx-manager/SKILL.md 十行改写（+10/-4），RFC 中英两版各加一句"出厂管家指引要求计划点名 Goal，因为不点名的计划会被丢弃而不是展示"，tests/test_manager_team_plan_guidance.py 增加 8 条断言。四文件 +21/-4，无 runtime 代码。

验证：pytest tests/test_manager_team_plan_guidance.py tests/test_chat_manager_context.py → 21 passed（含既有的顺序断言：lanes → 每条 lane 首个 Todo → 包络 → 验收 → 终止条件，说明改写没有打乱原流程），examples/docs-governance-smoke.py ok，git diff --check 干净。我也对照代码核对了新句子所描述的强制：validate_steward_team_plan_preview 确实要求 goal_id 且做形状校验，Chat 准入对无法解析的 Goal 返回 None（丢弃），team.plan 的落地只经受治理 owner——因此"dropped instead of shown"与"never create lanes yourself"都是对既有行为的准确描述。

一个 P3（非阻塞，已记入 findings，属本次改动未修的历史措辞）：预览段仍写 the quota or cadence envelope，而契约只接受 quota_envelope，校验器没有任何 cadence 字段，校验后的预览也只回 quota_envelope；指引测试还把这句话原文钉住了。这属于"指令面与契约不一致"的同一类别——恰好是这次 PR 要修的问题类别。建议删掉 "or cadence"，或说明 cadence 属于 lane 的 Todo/quota 配置而不是预览载荷。

另外记录但不作为 findings：指引写"confirmation arrives as one typed team-plan action from the product surface"，而 RFC 仍把"发出确认的前端面"列为未交付；这里的表述是在讲通道（管家应把它当作类型化 action，而不是自己去建 lane），不是宣称该 UI 已存在，所以我认为可接受，但值得在后续前端面落地时回看这句。

对主干的风险

风险极低：改动全部是指引文本、RFC 句子与测试断言，没有任何 runtime 代码、schema、action kind 或 transport 变化。指令面是共享的（每个管家 turn 都会加载这份 skill），但本次只改了团队流程那两段，且该文件其它测试（例如 executor 拒绝措辞那条）仍然通过，说明相邻指引未被波及。

强制执行面没有变化：计划少 Goal 仍被校验器拒绝、准入仍丢弃、lare 仍只能由受治理 owner 创建。新的"不得提前宣称效果"是面向模型的指引而非新的机器检查，文本与 RFC 都把它当作指引表述，没有把 advisory 说成 obligation。

我的整体评价

方向正确、粒度合适：它把三条真实漂移（Goal 名、确认通道、回执边界）分别补进出厂指引，每条都能对到既有强制行为，且保留了原有流程顺序（被测试断言住）。21 passed + docs smoke ok，我逐条核对过新句子描述的强制确实存在。

建议顺手修掉同段里的 quota or cadence envelope（P3），不构成合并阻塞。

English verdict: APPROVE (exact head fd03aa4)