fix(manager): ship the typed team preview the steward channel admits

[huangruiteng]

动机

在已安装的管家通道上现场提一个团队规划请求（本机管家执行器为 dsh），管家给出的回答是对的——点名了 Goal、2 条 lane、每条 lane 的 Agent、首条有界 Todo、配额上限、验收与停止条件——但事件里 proposals=[]、gate=null：

answer.final proposals=[] gate=null protected=null message_len=2160
turn.completed proposals=[] ...

产品的确认卡片只能从机器可读的 proposals 里取出 kind=steward_team_plan_preview 那一项（loopx/chat.py 的准入只在这种项上跑校验）。而管家自己的指引（loopx-manager skill）从头到尾没有写这个项：它只描述要说什么。真正教 envelope 的是通用 turn prompt，而它的示例只给了 kind: "todo"。

结果：管家答得完全正确，业主却拿不到任何可以确认的东西——正是 todo_5713ec39c3f3 里"一句 owner 话 → 类型化预览 → 确认后经 canonical owner 落地"这段的最后缺口。

改动思路

指引的属主是管家 skill（团队预览是管家概念，不是通用传输概念），所以把类型化预览契约写在 skill 里，与已有的散文式字段顺序并列：同一个计划既出现在回答正文，也作为 proposals 里的一项出现。标识符不重新发明，全部对齐校验器常量。

具体改动

• loopx/capabilities/manager_context/skills/loopx-manager/SKILL.md：新增类型化预览块（kind=steward_team_plan_preview、schema_version=steward_team_plan_preview_v0、goal_id/objective/lanes[...]/quota_envelope/stop_condition），lane 内 lane_id/agent_id/acceptance/first_todo{text,priority,task_class:"advancement_task",action_kind}，gap lane 用 staffing_gap 三选一 reason 且不得带 first_todo，最多 8 条 lane；并写明"缺这一项／Goal 未授权／Agent 未注册"的预览会被丢弃而不是展示。
• tests/test_manager_team_plan_guidance.py：新增断言把指引里的标识符与校验器常量（kind、schema_version、lane 上限、gap reason 集合）钉在一起，措辞与契约不能再漂移。

对主干的风险

低。只改管家通道的指引文本与测试：不改准入、校验、materializer、权限或投递语义；预览仍然是 proposal，落地仍由既有的 owner-gated apply 完成。唯一影响是管家在回答团队请求时会附上机器可读的那一项。

我的整体评价

正向且 proportional。它把"指引"和"机器契约"接上：此前指引描述的形状无法被机器接受，机器接受的形状指引又没说，于是线上表现为"答得对但不可确认"。改动小、边界清楚，并且用常量交叉断言防漂移。

Validation:

• 现场取证（修复前）：answer.final proposals=[]（同一 turn 的正文是一份完整团队预览）。
• pytest tests/test_manager_team_plan_guidance.py tests/capabilities/test_capability_configuration_ui.py tests/test_chat_response_parsing.py → 19 passed。
• loopx canary premerge --from-git-diff → merge_gate_passed: true，surfaces python；advisory 为 clean origin/main 已知基线。
• 合并后 promote 本机安装，并再发一次同样的团队规划请求，读回 proposals 是否出现 steward_team_plan_preview。

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

English verdict: APPROVE

[huangruiteng]

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

Exact head reviewed: 1371149

动机

在已安装的管家通道上现场提一个团队规划请求（本机管家执行器 dsh），回答正确（Goal、2 条 lane、Agent、首条有界 Todo、配额上限、验收、停止条件），但事件里 proposals=[] gate=null。产品的确认卡片只能从 proposals 里取 kind=steward_team_plan_preview 的项，而管家自己的 skill 从未写这个项；真正教 envelope 的通用 turn prompt 示例只给 kind: "todo"。于是"答得对但不可确认"。

改动思路

指引属主是管家 skill（团队预览是管家概念）。把类型化预览契约写进 skill，与散文式字段并列：同一个计划既在正文，也作为 proposals 的一项；标识符全部对齐校验器常量，不重新发明。

具体改动

• SKILL.md：新增类型化预览块（kind/schema_version/goal_id/objective/lanes[]/quota_envelope/stop_condition），lane 内 lane_id/agent_id/acceptance/first_todo{text,priority,task_class,action_kind}，gap lane 用 staffing_gap 三选一且无 first_todo，最多 8 条 lane；并写明缺项／未授权 Goal／未注册 Agent 的预览会被丢弃而不是展示。
• tests/test_manager_team_plan_guidance.py：把指引标识符与校验器常量（kind、schema_version、lane 上限、gap reason 集合）钉在一起，防措辞与契约漂移。

对主干的风险

低。只改指引文本与测试：不改准入、校验、materializer、权限或投递语义；预览仍是 proposal，落地仍由既有 owner-gated apply 完成。

我的整体评价

正向且 proportional：把"指引描述的形状"和"机器接受的形状"接上，改动小、边界清楚，且用常量交叉断言防漂移。

Evidence:

• exact head 1371149
• 修复前现场取证：answer.final proposals=[]（同一 turn 正文是完整团队预览）
• pytest tests/test_manager_team_plan_guidance.py tests/capabilities/test_capability_configuration_ui.py tests/test_chat_response_parsing.py → 19 passed
• loopx canary premerge --from-git-diff: merge_gate_passed true, surfaces python；advisory 为已知基线
• 合并后 promote 并再发一次同样请求，读回 proposals 是否出现 steward_team_plan_preview

English verdict: APPROVE