docs(rfcs): align autonomous managed teams and continuation ownership

Signed-off-by: huangruiteng <14976749+huangruiteng@users.noreply.github.com>

Author: huangruiteng

docs/architecture/rfcs/agent-im-openviking-collaboration-v0.md

@@ -112,6 +112,21 @@ Both ingress paths use the same transition contract:
 - command-specific evidence;
 - an accepted, rejected, conflict, or already-applied receipt.
 
+Use the [shared ingress policies](desktop-execution-frontends-v0.md#agent-scoped-bot-ingress-modes)
+for Agent messages as well as human-origin events: inbox persists for explicit
+drain, queue schedules subsequent input, and steer targets a supported safe
+point in the active execution. Preserve requested/effective mode, dedupe and
+consumption readback; an IM acknowledgement is not work adoption. Pending tools
+do not permit fabricated results or silent interrupt-as-steer fallback.
+
+The [session RFC](agent-session-execution-modes-v0.md#reusable-agent-operations-and-continuation-ownership)
+owns creation/attachment and one continuation owner per binding. Any authorized
+peer may coordinate another level through the handoff contract; IM topology
+grants neither extra permission nor a fresh team budget. A scoped facade to one
+supported local authority can precede shared-service deployment; it is not
+independent multi-host authority qualification. The direct Agent work path and
+the three-plane ownership model above remain unchanged.
+
 ## Projection Contract
 
 An IM room may display a compact projection such as:

docs/architecture/rfcs/agent-session-execution-modes-v0.md

@@ -221,6 +221,54 @@ monitor, or lifecycle truth; conversation text as a receipt; a second scheduler
 for the same binding; a Goal-wide default binding; and a mode change inferred
 from a probe, a transport, or a prompt.
 
+### Reusable Agent operations and continuation ownership
+
+This proposed extension refines the managed-team delivery contract; it does not
+add CLI flags, promote a host, or change existing session/profile defaults.
+Keep three identities separate: the registered Agent, its current host session
+and execution generation, and each work request/attempt. Creating an Agent is
+not starting a process, attaching a session is not claiming work, and a returned
+artifact is not accepted work.
+
+| Operation family | Existing owner to reuse | Required observation |
+| --- | --- | --- |
+| Discover/create/reuse an Agent | Registry, directory, onboarding and configured execution profile | Stable Agent identity, effective scope and supported capabilities; repeated creation does not duplicate the identity |
+| Attach/start/resume/stop | This RFC's binding and the selected host adapter | Exact session/generation, actual running or blocked state, cancellation and replacement readback; attached hosts never acquire a substitute executor |
+| Send/receive/return | Collaboration request owner and the [ingress policies](desktop-execution-frontends-v0.md#agent-scoped-bot-ingress-modes) | Requested/effective inbox, queue or steer semantics; delivery, consumption and work adoption remain distinct |
+| Claim/validate/settle | Existing Todo, lease, acceptance and quota owners | Current execution proof and independent acceptance; a host cannot certify its own completion |
+
+These are semantic operation families, not a new universal adapter API. Both a
+lead Agent and an authorized managed worker may call them. Host lifecycle
+differences remain explicit; a coordination role grants no extra authority.
+
+**Continuation ownership is a separate axis from session mode and provider.**
+Each binding has one qualified owner of the next execution opportunity:
+
+- **LoopX-governed Turn:** the existing runtime/scheduler admits a complete
+  bounded work unit; the host runs its own model/tool loop and returns a typed
+  candidate for independent validation and settlement. Local and cloud hosts
+  may implement the same contract. A Turn is not one model call or a scripted
+  business phase; the Agent may investigate, delegate and revise within scope.
+- **Native Goal runtime:** submit one Goal/task body and let that runtime own
+  continuation, with qualified handling of LoopX continue/defer/complete,
+  cancellation, budget and result readback. A prompt alone is not a scheduler;
+  provider Goal evaluation does not replace LoopX work acceptance.
+- **Same-session host driver:** an explicitly activated host integration can
+  obtain fresh LoopX admission and enqueue the next task in the existing
+  session. Qualify this separately from a provider's native Goal evaluator.
+
+Never wrap a self-continuing native Goal in repeated externally driven Turns on
+the same binding. To change the continuation owner, stop new admission, reconcile
+pending tools and uncertain effects, fence the old executor, and read back the
+new binding before execution. Disconnection does not authorize that switch.
+
+For the first mixed managed cohort, qualify a cloud adapter against the same
+governed Turn contract as the local worker before expanding native Goal profiles.
+This is a delivery priority, not a default migration. The
+[harness selection RFC](harness-selection-dsh-pi-v0.md) owns provider qualification.
+Reuse the existing profile editor and session projections; do not add a
+manager-only creation service, task ledger or scheduling loop.
+
 ### State model and schema
 
 The binding is the unit of mode ownership. Its canonical fields:
@@ -307,11 +355,12 @@ it may not claim an executing session binding.
 
 ### Capability and delivery-mode orthogonality
 
-Five axes that are frequently confused, each with one owner:
+Six axes that are frequently confused, each with one owner:
 
 | Axis | Values | Owner |
 | --- | --- | --- |
 | Execution mode | `managed_runtime`, `attached_host` | This RFC |
+| Continuation owner (proposed) | LoopX Turn driver, native Goal runtime, same-session host driver | This RFC; qualification per selected profile, never inferred from provider or location |
 | Transport | web chat, Lark, CLI | Desktop frontends RFC; transports never change mode |
 | Event source | group message, document comment, monitor observation, inbound file | Connector and collaboration contracts |
 | Ingress/delivery mode | `live_steering`, `session_queue`, `async_inbox` | Desktop frontends RFC, gated per binding |
@@ -433,6 +482,14 @@ future evidence and must not be reported as green.
 Deterministic package tests are not sufficient for admission. A new host needs
 at least one real-host row: a live process, a real bind, and a real restart.
 
+The proposed continuation extension also requires an installed local/cloud pair
+to use the same admission/result/independent-validation contract, a managed
+worker to request and adopt another worker's artifact, and a driver-switch race
+to reject the old executor. Test ordinary waiting, pending tools, budget
+exhaustion and native Goal defer/terminal handling separately. None of these
+rows is qualified by registration, HTTP acknowledgement or a fixed phase script.
+Preserve feature-off behavior for every existing profile and entrypoint.
+
 ## 11. Operational contract
 
 - **Observability.** Session readback exposes mode, host surface, executor

docs/architecture/rfcs/agent-session-execution-modes-v0.zh-CN.md

@@ -176,6 +176,46 @@ claim 与完成回执，以及"只有经过验证的回写才推进工作"这一
 对话文本作为回执；同一绑定上的第二个调度器；Goal 级默认绑定；以及从探测、传输或
 提示词推断出的模式变更。
 
+<a id="reusable-agent-operations-and-continuation-ownership"></a>
+
+### 可复用的 Agent 操作与续跑归属
+
+本提案细化 managed 团队的交付契约，不新增 CLI 参数、不晋升宿主，也不改变现有
+会话/profile 默认。区分三组身份：已注册 Agent、其当前宿主会话与执行代际、每次工作
+请求/尝试。创建 Agent 不等于启动进程，挂接会话不等于领取工作，返回产物不等于工作验收。
+
+| 操作族 | 复用的现有 owner | 必须读回的事实 |
+| --- | --- | --- |
+| 发现/创建/复用 Agent | Registry、directory、onboarding 和配置的 execution profile | 稳定 Agent 身份、生效范围和支持能力；重复创建不产生第二身份 |
+| 挂接/启动/恢复/停止 | 本 RFC 的 binding 与选定 host adapter | 精确会话/代际、实际执行或阻塞、取消和替换读回；attached host 不获得替身执行器 |
+| 发送/接收/返回 | Collaboration request owner 与[入口策略](desktop-execution-frontends-v0.zh-CN.md#agent-scoped-bot-ingress-modes) | 请求/实际 inbox、queue、steer 语义；投递、消费、工作采用仍是不同事实 |
+| 领取/验证/结算 | 既有 Todo、lease、acceptance、quota owner | 当前执行 proof 与独立验收；宿主不能自行证明工作完成 |
+
+这些是语义操作族，不是新增的万能 adapter API。主 Agent 和获授权的 managed worker
+都可调用；宿主生命周期差异保持显式，协调角色不增加权限。
+
+**续跑归属是独立于 session mode 和 provider 的轴。** 每个 binding 只有一个经过
+资格化的下一执行机会 owner：
+
+- **LoopX 受控 Turn：** 既有 runtime/scheduler 准入一次完整的有界工作；宿主运行
+  自己的模型/工具循环，返回 typed candidate，经独立验证后结算。本地和云端宿主可
+  实现同一合同。Turn 不是一次模型调用或脚本业务 phase；Agent 可在范围内调查、
+  委派和修订。
+- **原生 Goal runtime：** 一次提交 Goal/task body，由该 runtime 拥有续跑；必须
+  验证其处理 LoopX continue/defer/complete、取消、预算和结果读回。Prompt 本身
+  不是调度器，provider Goal 自评不替代 LoopX 工作验收。
+- **同会话 host driver：** 显式激活的宿主集成可取得新鲜 LoopX 准入，将下一任务排入
+  原会话。它与 provider 原生 Goal evaluator 分别资格化。
+
+禁止在同一 binding 上，一边重复外部受控 Turn，一边包裹会自行续跑的原生 Goal。
+更换续跑 owner 前，停止新增准入、对账未决工具和不确定副作用、fence 旧执行器，
+再读回新绑定后执行；断连不授权该切换。
+
+首个混合 managed cohort 优先让云端 adapter 与本地 worker 通过同一 governed Turn
+合同，再扩展 native Goal profile。这是交付优先级，不是默认迁移；provider 资格由
+[harness 选型 RFC](harness-selection-dsh-pi-v0.zh-CN.md)负责。复用现有 profile editor
+和会话投影，不新建管家专属创建服务、任务账本或调度循环。
+
 ### 状态模型与 schema
 
 绑定是模式归属的单元。其规范字段：
@@ -242,11 +282,12 @@ claim 与完成回执，以及"只有经过验证的回写才推进工作"这一
 
 ### 能力与投递模式的正交性
 
-经常被混淆的五个轴，每个轴有唯一属主：
+经常被混淆的六个轴，每个轴有唯一属主：
 
 | 轴 | 取值 | 属主 |
 |---|---|---|
 | 执行模式 | `managed_runtime`、`attached_host` | 本 RFC |
+| 续跑 owner（提案） | LoopX Turn driver、原生 Goal runtime、同会话 host driver | 本 RFC；按选定 profile 验证，不从 provider 或部署位置推断 |
 | 传输 | web chat、Lark、CLI | 桌面执行前端 RFC；传输绝不改变模式 |
 | 事件源 | 群消息、文档评论、monitor 观察、入站文件 | 连接器与协作契约 |
 | 入口/投递模式 | `live_steering`、`session_queue`、`async_inbox` | 桌面执行前端 RFC，按绑定门控 |
@@ -349,6 +390,11 @@ claim 与完成回执，以及"只有经过验证的回写才推进工作"这一
 确定性的包测试不足以支撑接入。新宿主至少需要一条真实宿主行：一个真实进程、一次真实
 绑定、一次真实重启。
 
+续跑扩展还要求：已安装的本地/云端组合使用同一准入/结果/独立验证合同；普通 managed
+worker 请求并采用另一 worker 的产物；driver 切换竞态拒绝旧执行器。普通等待、未决
+工具、预算耗尽、native Goal defer/终态处理分别验证。注册、HTTP ACK 或固定 phase
+脚本都不能满足这些尚未资格化的项目；每个现有 profile 和入口保持 feature-off 行为。
+
 ## 11. 运维契约
 
 - **可观测性。** 会话回读暴露模式、宿主面、执行器端点、能力、状态、活跃 turn 与稳定

docs/architecture/rfcs/capable-manager-semantic-handoff-v0.md

@@ -152,6 +152,14 @@ The durable semantic context consists of a small typed identity/control header p
 
 Prefer one cohesive replacement to compatibility wrappers that preserve duplicate decisions. Inventory every existing producer/reader, migrate with lossless mappings, switch one writer and delete the replaced rules. Reusing contracts and data is required; reusing every current class, JSON directory and prompt is not.
 
+The lead Agent owns task decomposition, investigation, delegation, revision and
+synthesis. Host services execute admitted operations and recover their receipts;
+they do not encode the scenario's next business phase. A managed worker may
+coordinate other Agents through the same scoped creation, session and request
+operations defined by the [session execution RFC](agent-session-execution-modes-v0.md#reusable-agent-operations-and-continuation-ownership).
+Keep the manager application thin and shared state transitions in their typed
+owners. Do not build a second scheduler in the manager or provider adapter.
+
 ### 5.3 Authority that enables work
 
 Resolve a request from authenticated principal, origin/audience, resource scope and requested effect, then match the existing persistent grant. A grant is reused across turns and restarts until revoked, expired or outside scope. Authorized delegation may carry an attenuated reference to a real standing grant; handoff is not inherently powerless. The receiver verifies the grant chain, target/action scope and its own host authority. It neither trusts a model-written permission string nor requires the user to approve the same in-scope work again. Read-only discovery, direct reversible effects and protected operations keep their actual permission semantics; none is forced through a second confirmation merely because the entrypoint is chat.
@@ -212,6 +220,32 @@ At-least-once delivery with idempotent Core effects is the target. Do not promis
 
 The receiver commits result/evidence links and audience-ready text. The manager may synthesize multiple worker outcomes into one answer, maintaining request-level coverage. A deterministic outbox delivers an already committed result even if the manager model is unavailable. If synthesis is required, persist that duty; do not let an optional synthesis step erase the worker's result. Model retries never replay an already accepted action.
 
+#### Hierarchical delegation and autonomous progress
+
+An Agent may delegate a bounded subproblem and remain responsible for integrating
+its result. Record parent/request lineage without treating it as a grant. At
+each hop, scope, allowed effects, depth, total fanout and shared budget remain
+within effective authorization; child creation does not multiply the team's
+resource allowance. Reuse an existing peer when appropriate. Cancelling one
+request affects only its owned descendant executions, not a shared Agent's
+unrelated work. Detect wait cycles and release unnecessary execution slots
+while awaiting children, so parents cannot consume all child capacity.
+
+Return follows the real dependency: child artifact -> receiver validation and
+adoption/rejection -> parent integration -> original requester. Directly
+forwarding a grandchild's output to the lead does not prove the intermediate
+Agent coordinated or accepted it. Messages use the shared inbox/queue/steer
+policies; receiving a message cannot grant a claim, alter intent or accept work.
+
+Extend A6/A8/A13 with a three-level synthetic journey and two input revisions.
+The lead retains substantive work of its own; an intermediate worker decides
+whether another peer is needed. Freeze the objective, constraints and injected
+failure, not the team roster or phase sequence. At least one revised delegation
+must originate from an Agent's response to contradictory evidence. Record
+request/decision references and adoption facts, not private reasoning traces.
+The harness may inject faults and check invariants; it must not supply every
+next phase, manually forward results or certify success from message counts.
+
 ### 5.7 Session and product continuity
 
 **Cross-session continuation is a first-class product journey, not transcript forwarding.** A user can ask “continue in another session/agent and report back here” once. Within existing authorization, the host prepares the context, selects the supported continuation path, presents it to the receiver and returns the conclusion automatically. The receiver reassesses the work; the user need not export JSON, repeat the background or approve routine restoration. This applies to manager and worker sessions alike.