From 47a51277107f59ede2e4412cc42c2103983287ce Mon Sep 17 00:00:00 2001
From: huangruiteng <14976749+huangruiteng@users.noreply.github.com>
Date: Wed, 16 Sep 2026 17:11:21 +0800
Subject: [PATCH] docs(rfc): record where the steward team intake is enforced

The steward's shipped guidance now carries one bounded team-plan procedure, but
that is guidance, not machine enforcement, and the RFC did not say where the
enforced contract belongs. Without that, the next slice would either invent a
command with no second caller or a builder module with no caller at all.

The RFC now records the decided boundary and the payload it must validate: the
intake is one proposal of a new kind admitted by the canonical governed-proposal
owner (kind dispatch, typed receipt with a proposal digest, and the Chat Turn's
existing proposal projection), never a parallel intake path. The validated
payload names each lane and its registered Agent, that lane's first bounded Todo
with priority and action kind, the quota or cadence envelope, the per-lane
acceptance signal, and the team stop condition; an unstaffable lane is a typed
gap naming the missing registration or grant. The plan is a preview that creates,
registers, and spends nothing, admits an apply only on the owner's confirmation
of that exact preview, applies through the canonical owners each effect already
has, reuses the names the preview gave, and returns one readback. Delivery is
two slices, preview-only first with no materializer registered, then the
materializer with its settlement phase.

Verified: `loopx check --scan-path` on both changed files is clean, and the
added sections are Markdown under existing headings. Not verified here: no
doc-render or link smoke was run for these paths.

Signed-off-by: huangruiteng <14976749+huangruiteng@users.noreply.github.com>
---
 .../rfcs/harness-selection-dsh-pi-v0.md       | 51 +++++++++++++++++++
 .../rfcs/harness-selection-dsh-pi-v0.zh-CN.md | 36 +++++++++++++
 2 files changed, 87 insertions(+)

diff --git a/docs/architecture/rfcs/harness-selection-dsh-pi-v0.md b/docs/architecture/rfcs/harness-selection-dsh-pi-v0.md
index 8a7c173f52..23c5b704f0 100644
--- a/docs/architecture/rfcs/harness-selection-dsh-pi-v0.md
+++ b/docs/architecture/rfcs/harness-selection-dsh-pi-v0.md
@@ -474,6 +474,57 @@ Validation: `tests/capabilities/test_steward_executor_machine_defaults.py`,
 `tests/capabilities/test_capability_configuration_ui.py`, and
 `examples/loopx-steward-channel-binding-smoke.py`.
 
+## Steward Team Intake (planned, 2026-09-16)
+
+The steward answers questions today, and since `2026-09-16` its shipped
+guidance carries one bounded procedure for a different request: one owner
+sentence that asks for a *team* rather than a task. That procedure is guidance,
+not machine enforcement, so this section records where the enforced contract
+belongs and what it must validate before any implementation lands.
+
+The intake boundary is the canonical governed-proposal owner
+(`loopx/control_plane/work_items/governed_transition_proposal.py`), not a new
+CLI command and not a new capability. That owner already dispatches proposals
+by kind, publishes a typed receipt with a proposal digest, and the Chat Turn
+already projects `response.proposals` into `proposal.ready` events. A team
+request is therefore one proposal of a new kind, not a parallel intake path
+beside the existing one. A command with no second caller, and a builder module
+with no caller at all, both stay out: this repository keeps an uncalled
+abstraction in design state until its call site exists.
+
+The proposal payload is validated before anything may be applied, and it names:
+
+- each lane and the Agent that runs it, resolved from Agents Core already
+  registers for the Goal;
+- that lane's first bounded Todo, with its declared priority, task class and
+  action kind;
+- the quota or cadence envelope that bounds the lanes;
+- the acceptance signal that ends each lane;
+- the stop condition that ends the team.
+
+A requested lane that cannot be staffed is a typed gap naming the missing
+registration or grant; it is never filled in by inventing an Agent, a Todo
+capability, or a lane the machine cannot run. The plan is a preview: it creates
+no Todo, registers no Agent, sets no quota, and spends none, and an owner's
+confirmation of that exact preview is the only thing that admits an apply.
+Apply routes to the canonical owners each effect already has -- Agent
+registration, Todo creation, quota or goal policy -- reuses the identities the
+preview named, and returns one readback of what exists. It may not widen the
+confirmed scope, and a team plan is never settled as if the work were done.
+
+Delivery is two slices, in this order:
+
+1. **Preview slice (next).** The typed payload contract and its validator, with
+   focused tests, and no materializer registered, so a preview cannot apply
+   even by mistake.
+2. **Apply slice.** A materializer for that kind, with its settlement phase and
+   readback, routed through the owners above.
+
+What this planned contract does not authorize: the steward still only proposes
+and delegates; selecting a steward executor or storing a credential grants none
+of these effects; and nothing here widens OS, provider, audience or work-state
+authority.
+
 ## Steward Channel Readiness by Milestone (2026-09-15)
 
 The steward channel consumes both this document's host selection and the manager
diff --git a/docs/architecture/rfcs/harness-selection-dsh-pi-v0.zh-CN.md b/docs/architecture/rfcs/harness-selection-dsh-pi-v0.zh-CN.md
index cbc192c647..eb26f0f0a7 100644
--- a/docs/architecture/rfcs/harness-selection-dsh-pi-v0.zh-CN.md
+++ b/docs/architecture/rfcs/harness-selection-dsh-pi-v0.zh-CN.md
@@ -373,6 +373,42 @@ journal 与配额语义；B 作为上游接口出现时的低成本替代；只
 `tests/capabilities/test_capability_configuration_ui.py`，以及
 `examples/loopx-steward-channel-binding-smoke.py`。
 
+## 管家团队入端口径（规划中，2026-09-16）
+
+管家今天回答问题；自 2026-09-16 起，它的出厂指引里已带一段有界流程，用于另一类请求：
+业主一句话要的是**团队**而不是单个任务。那段流程是指引，不是机器强制，因此本节记录被强制
+的契约属于哪里、以及实现落地前必须校验什么。
+
+入端口径是既有的受治理提案所有者
+（`loopx/control_plane/work_items/governed_transition_proposal.py`），不是新的 CLI 命令，
+也不是新的能力。该所有者本就按 kind 分派提案、产出带 proposal digest 的类型化回执，而
+Chat Turn 也早已把 `response.proposals` 投影成 `proposal.ready` 事件。因此"团队请求"是
+**一种新 kind 的提案**，而不是在既有路径旁再开一条入端口。没有第二个调用方的命令、以及
+完全没有调用方的 builder 模块都不新增：本仓库要求未获调用的抽象先留在设计态。
+
+在允许任何落地之前先校验提案载荷，它必须点名：
+
+- 每条 lane 及其运行的 Agent，且只能来自 Core 已为该 Goal 注册的 Agent；
+- 该 lane 的首个有界 Todo，含其声明优先级、task class 与 action kind；
+- 约束这些 lane 的 quota 或节奏包络；
+- 结束每条 lane 的验收信号；
+- 结束整个团队的终止条件。
+
+配不齐的 lane 是类型化的 gap（缺哪个注册或授予），不允许靠编造 Agent、Todo 能力或本机跑不动
+的 lane 来填。计划是**预览**：不建 Todo、不注册 Agent、不设 quota、不扣额度；只有业主对这
+份确切预览的确认，才允许进入落地。落地只经各 effect 既有的 canonical owner——Agent 注册、
+Todo 创建、quota 或 goal policy——复用预览点名的身份，并返回一份"现在存在什么"的回读；不得
+扩大已确认范围，也不得把团队计划当作工作已完成的结算。
+
+按此顺序分两片交付：
+
+1. **预览片（下一步）**：类型化载荷契约与其校验器，配聚焦测试，且不注册 materializer，
+   使预览即使被误用也无法落地。
+2. **落地片**：该 kind 的 materializer，含其结算相位与回读，并按上文经既有 owner 路由。
+
+这条规划契约不授权什么：管家仍然只提议与委托；选择管家执行器或存凭据都不带来这些 effect；
+这里也不会扩大 OS、provider、受众或工作状态权限。
+
 ## 按里程碑看管家通道的就绪度（2026-09-15）
 
 管家通道同时消费本文的宿主选型与