diff --git a/docs/architecture/rfcs/harness-selection-dsh-pi-v0.md b/docs/architecture/rfcs/harness-selection-dsh-pi-v0.md
index 526f78fa6d..dde20aef8d 100644
--- a/docs/architecture/rfcs/harness-selection-dsh-pi-v0.md
+++ b/docs/architecture/rfcs/harness-selection-dsh-pi-v0.md
@@ -548,28 +548,62 @@ those gaps: the apply publishes every lane Todo it ensured under a bounded
 persisted receipt field set so a receipt written before it still validates, and
 a team-plan receipt carries no monitor key because a plan is not a monitor.
 
-### Relationship to the multi-agent contracts
-
-The intake is a user-layer affordance over the kernel the multi-agent contracts
-already define; it adds no second team runtime.
-
-- Against `multi_agent_three_layer_minimality_contract_v0`
-  (`docs/reference/protocols/multi-agent-three-layer-minimality-v0.md`), the
-  owner's one sentence is the user layer, the steward's bounded procedure is the
-  preset layer, and lanes, first bounded Todos, quota envelope, acceptance and
-  stop condition are declared data the kernel mechanics consume. The intake must
-  not own a runner, panes, per-agent vision budgets or evidence loops; it
-  materializes goal work lanes through the canonical Todo owner, which is what
-  keeps a team request from becoming a product-specific runner.
-- Against `multi_agent_visible_launcher_v0`
-  (`docs/reference/protocols/multi-agent-visible-launcher-v0.md`), the launcher
-  starts visible local panes from a `generic_multi_agent_launch_spec_v0`, and
-  the intake is the same intent entered from Chat. They join by identity
-  (`goal_id`, `agent_id`, and the lane's first Todo), not by one calling the
-  other, and the launcher's own rule applies unchanged to the intake: no leader
-  agent, hidden scheduler, promotion authority or second source of truth. A plan
-  that needs visible panes, pane-local A2A ticks or promotion evidence has to
-  name that as a supported action kind instead of embedding it in the preview.
+### Relationship to the multi-agent and shared-authority contracts
+
+A team request staffs work that several Agents share; it does not create a
+second planning or authority model. The governing contract is
+[Shared Goal Alignment and Governed
+Amendment](./shared-goal-alignment-and-governed-amendment-v0.md), whose authority
+and storage boundary is owned by [Shared Control-Plane Authority and Pluggable
+State Providers](./shared-goal-authority-state-provider-v0.md).
+
+- **A plan is a staffing act on the shared work graph.** Each lane's first
+  bounded Todo is work-graph work that preserves canonical intent, which is why
+  the apply routes through the canonical Todo owner instead of writing a plan of
+  its own. The lanes are per-Agent frontiers over that one graph, so the intake
+  must not introduce a second graph, a second frontier, or a leader Agent.
+- **Intent and staffing are different acts.** The plan's objective, acceptance
+  and stop condition state what its lanes will do *inside* the Goal's canonical
+  intent envelope (`shared_goal_intent_v0`); they may not change the Goal's
+  objective, non-goals, acceptance, permissions or stop conditions. A request
+  that needs the acceptance refined is a `shared_acceptance` amendment, and one
+  that needs a new permission is `protected_authority`; both belong to
+  `GoalAmendmentAuthority` with its policy check, independent verification and
+  compare-and-set receipt, not to a team preview. This is the same fail-closed
+  rule the typed gaps already express at the lane layer
+  (`capability_not_granted`, `audience_not_authorized`), stated for the intent
+  layer.
+- **`peer_v1` is equal execution rank, not commit authority.** The steward
+  proposes and delegates. Confirming a preview does not make it a leader over
+  the lanes, give it priority on shared resources, or grant unilateral commit
+  authority; the alignment contract states that rule for every registered Agent,
+  and this intake is one more caller that has to respect it.
+- **The authoritative per-lane readback is the alignment projection.** Once a
+  plan lands, a lane's state is what `shared_goal_alignment_v0` reports for that
+  Agent (`loopx shared-goal-alignment --goal-id <goal> --agent-id <agent>`):
+  canonical revision, frontier basis, claims and lease facts, and eligible
+  unclaimed work. The apply's receipt names the lane Todos; it does not yet
+  project that per-Agent alignment state.
+
+Two gaps belong to this work and are named here rather than claimed as done: a
+materialized lane Todo does not yet carry the canonical intent revision it was
+intended to advance, so the edit is not traceable to an intent revision the way
+the alignment contract requires; and the intake reserves no work and takes no
+lease or fence, so a lane's first turn competes for quota through the ordinary
+path.
+
+The layering rules still hold beside that. Against
+`multi_agent_three_layer_minimality_contract_v0`
+(`docs/reference/protocols/multi-agent-three-layer-minimality-v0.md`), the
+owner's one sentence is the user layer, the steward's bounded procedure is the
+preset layer, and lanes, first bounded Todos, quota envelope, acceptance and
+stop condition are declared data the kernel mechanics consume; the intake owns
+no runner, panes, per-agent vision budgets or evidence loops. Against
+`multi_agent_visible_launcher_v0`
+(`docs/reference/protocols/multi-agent-visible-launcher-v0.md`), the launcher
+starts visible local panes from a `generic_multi_agent_launch_spec_v0` and the
+intake is the same intent entered from Chat; they join by identity (`goal_id`,
+`agent_id`, and the lane's first Todo), not by one calling the other.
 
 What this contract does not authorize: the steward still only proposes and
 delegates; selecting a steward executor or storing a credential grants none of
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 6b22459fe7..0fce316d8f 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
@@ -425,23 +425,45 @@ Todo 创建、quota 或 goal policy——复用预览点名的身份，不得扩
 发布出去；该字段是那个封闭且持久化的回执字段集的**唯一**加性例外，因此早前写下的回执仍然
 通过校验，而团队计划回执不带 monitor key——计划不是 monitor。
 
-### 与 multi-agent 契约的关系
-
-这条入端口径是既有 multi-agent 契约所定义内核之上的**用户层**便利：它不新增第二套团队
-runtime。
-
-- 对应 `multi_agent_three_layer_minimality_contract_v0`
-  （`docs/reference/protocols/multi-agent-three-layer-minimality-v0.md`）：业主那一句话是用户
-  层，管家那段有界流程是 preset 层，而 lanes、首个有界 Todo、quota 包络、验收与终止条件是
-  内核机制消费的声明数据。入端口径不得拥有 runner、pane、per-agent vision 预算或证据回路；
-  它只经 canonical Todo owner 建出 Goal 工作 lane，这正是它不会变成产品专用 runner 的原因。
-- 对应 `multi_agent_visible_launcher_v0`
-  （`docs/reference/protocols/multi-agent-visible-launcher-v0.md`）：launcher 从
-  `generic_multi_agent_launch_spec_v0` 启动可见本地 pane，而这条入端口径是同一意图从 Chat
-  进入。两者按身份相连（`goal_id`、`agent_id` 与该 lane 的首个 Todo），而不是互相调用；
-  launcher 自身那条规则对入端口径同样成立：不得成为 leader agent、隐藏调度器、晋升权威或
-  第二真源。需要可见 pane、pane 内 A2A tick 或晋升证据的计划，必须把它声明为受支持的
-  action kind，而不是塞进预览里。
+### 与 multi-agent / shared authority 契约的关系
+
+团队请求配的是**多个 Agent 共享的工作**，不是第二套规划或权威模型。它受
+[共享目标对齐与受治理修订](./shared-goal-alignment-and-governed-amendment-v0.zh-CN.md)
+约束，其权威与存储边界由
+[共享控制面权威与可插拔状态提供方](./shared-goal-authority-state-provider-v0.zh-CN.md)
+拥有。
+
+- **计划是共享工作图上的"配人"动作。** 每条 lane 的首个有界 Todo 属于共享工作图里保持
+  规范意图不变的工作，这正是落地走 canonical Todo owner、而不是自己写一份计划的原因。
+  lane 就是同一张图上的 per-Agent frontier，因此入端口径不得引入第二张图、第二个 frontier，
+  也不得引入 leader Agent。
+- **改意图与配人是两件事。** 计划里的 objective、acceptance、stop condition 声明的是各 lane
+  在 Goal **规范意图包络**（`shared_goal_intent_v0`）之内要做什么；它们不得改动 Goal 的
+  objective、non-goals、acceptance、权限或终止条件。需要细化验收条件的请求是一次
+  `shared_acceptance` 修订，需要新权限的请求是 `protected_authority` 修订，两者都属于
+  `GoalAmendmentAuthority`（含策略校验、独立验证与 CAS 回执），而不是属于团队预览。这与
+  lane 层已有的 fail-closed 规则（`capability_not_granted`、`audience_not_authorized`）是同
+  一条规则，只是作用在意图层。
+- **`peer_v1` 是平等执行位阶，不是提交权威。** 管家只提议与委托；确认预览不会让它成为各
+  lane 之上的 leader、不会给它共享资源上的优先权，也不会给它单方提交权威。对齐契约对每个
+  已注册 Agent 都这样规定，这条入端口径只是又一个必须遵守它的调用方。
+- **每条 lane 的权威回读是对齐投影。** 计划落地后，一条 lane 的状态就是该 Agent 的
+  `shared_goal_alignment_v0` 投影（`loopx shared-goal-alignment --goal-id <goal> --agent-id
+  <agent>`）：规范修订、frontier basis、claim 与租约事实、可领取的未认领工作。apply 的回执
+  点名 lane Todo，但还没有投影这份 per-Agent 对齐状态。
+
+有两处缺口属于这条工作线，这里如实点名而不当作已完成：已建出的 lane Todo 还没有携带它本应
+推进的规范意图修订，因此这次工作图编辑尚未像对齐契约要求的那样可追溯到某个意图修订；
+入端口径也不预留工作、不取租约或 fence，因此 lane 的首个 turn 仍走普通配额路径竞争。
+
+分层规则仍然并行成立。对应 `multi_agent_three_layer_minimality_contract_v0`
+（`docs/reference/protocols/multi-agent-three-layer-minimality-v0.md`）：业主那一句话是用户层，
+管家那段有界流程是 preset 层，lanes、首个有界 Todo、quota 包络、验收与终止条件是内核机制
+消费的声明数据；入端口径不拥有 runner、pane、per-agent vision 预算或证据回路。对应
+`multi_agent_visible_launcher_v0`
+（`docs/reference/protocols/multi-agent-visible-launcher-v0.md`）：launcher 从
+`generic_multi_agent_launch_spec_v0` 启动可见本地 pane，而这条入端口径是同一意图从 Chat 进入；
+两者按身份相连（`goal_id`、`agent_id` 与该 lane 的首个 Todo），而不是互相调用。
 
 这条契约不授权什么：管家仍然只提议与委托；选择管家执行器或存凭据都不带来这些 effect；
 这里也不会扩大 OS、provider、受众或工作状态权限。