loopx-project · huangruiteng · Sep 20, 2026 · Sep 20, 2026
@@ -5,7 +5,7 @@
   session and an end-to-end LoopX-managed desktop runtime
 - Initial attached runtime: Codex App / app-server
 - Initial managed runtimes: Pi and DeepSeek Harness (`dsh`)
-- Default managed provider profile: Volcengine Ark Agent Plan
+- Managed provider selection: explicit guided configuration and user intent; Agent allocation within authorized eligible profiles. Ark Agent Plan remains an optional distribution preset.
 
 ## Summary
 
@@ -16,9 +16,10 @@ LoopX Desktop should support two explicit execution frontend modes:
    process, conversation, interruption, resume, and execution-loop ownership.
 2. **Managed Agent Runtime.** LoopX Desktop launches and supervises Pi or
    DeepSeek Harness, selects an explicit provider profile, and advances work
-   through bounded `loopx_turn_v0` transactions. The default distribution
-   profile uses Volcengine Ark Agent Plan, while the runtime and provider
-   contracts remain replaceable.
+   through bounded `loopx_turn_v0` transactions. A distribution may offer
+   Volcengine Ark Agent Plan as a named preset. The operator's configuration and
+   explicit intent bound autonomous Agent allocation; no provider is a universal
+   product default. Runtime and provider contracts remain replaceable.
 
 Both modes present the same LoopX Goal, Todo, gate, quota, evidence, and status
 truth. They do not share process ownership. The frontend must never infer a
@@ -44,6 +45,46 @@ eligible, invokes the selected runtime adapter, validates its result, and
 commits accepted state. `loopx_turn_v0` remains one transaction rather than a
 second recurring scheduler.
 
+## Guided configuration, user intent and autonomous allocation
+
+This proposed selection rule refines the provider-default language; it does not
+change shipped runtime defaults or qualify new adapters. Reuse the existing
+machine/Goal capability editor, provider store, session binding and dispatch
+admission. It adds no capability id, provider implementation or routing service.
+
+- **Configuration makes choices usable.** Show detected installation and login,
+  supported tools, model/account, cost or unknown cost, host availability and
+  permission scope. Discovery does not grant access. A named preset is an
+  offered choice; it cannot override an existing configured selection.
+- **Explicit user intent binds the choice.** A fixed model/account, local-only
+  requirement, budget or member restriction applies at its declared scope.
+  A preference is not a hard lock unless the user made it one. Do not turn a
+  single user's Codex preference, or one distribution's Ark preset, into a
+  global provider rule. Unresolved conflicting instructions require clarification.
+- **The Agent allocates inside that boundary.** Choose eligible models/runtimes,
+  reuse or request workers and redistribute future work by task fit, tool access,
+  cost and observed availability. A flexible authorized pool does not need a
+  fresh confirmation for each assignment. Selection is semantic Agent judgment;
+  typed owners enforce eligibility, budget, authority and session fences.
+
+Project the effective runtime/model/profile, assignment reason and readiness in
+settings and the team detail. Recheck admission at dispatch. An unavailable pinned
+route blocks with a repair action; an unavailable member of a flexible pool may
+be replaced by another eligible route with visible readback. No substitution may
+expand data exposure, credentials, cost authority or supported tools. Active
+sessions retain their binding and context ownership; an authorized autonomous
+reassignment uses the existing explicit rebinding/continuation contract, not a
+silent session migration. New paid resources or scope changes retain their
+existing decision boundary.
+
+Qualify through packaged setup, Chat/steward and independent CLI: pinned choice
+wins over a preset; flexible allocation succeeds without repeated approval;
+unavailable pinned choice stays blocked; exhausted budget or an unauthorized
+fallback creates no execution; restart preserves the effective configuration.
+Optional Lark must project the same choice and its own audience restrictions.
+Until these cases pass, this is the allocation design, not a runtime guarantee.
+See the [near-term launch route](loopx-overall-roadmap-v0.md#near-term-local-agent-product-and-launch).
+
 ## Problem
 
 LoopX already has the pieces of two different products:
@@ -536,8 +577,8 @@ The managed desktop path is end to end:
 
 1. select or create a LoopX Goal and working Agent binding;
 2. select Pi or `dsh` as the runtime;
-3. select a managed provider profile, with Ark Agent Plan as the default
-   distribution profile;
+3. guide provider configuration and user constraints, then let the Agent select
+   within the authorized eligible profiles; offer Ark Agent Plan as a named preset;
 4. validate runtime installation, provider authentication, and advertised
    capabilities;
 5. launch one runtime and create one opaque resumable session;
@@ -596,9 +637,10 @@ for reconciliation, validation, and resume.
 
 ### Provider profile contract
 
-Runtime choice and provider choice are orthogonal. Ark Agent Plan is the
-default managed product profile, not a special case embedded throughout the
-LoopX kernel.
+Runtime choice and provider choice are orthogonal. Ark Agent Plan is a named
+managed-provider preset. Guided configuration, scoped user intent and Agent
+allocation select an eligible profile; no provider rule is embedded throughout
+the LoopX kernel.
 
 A provider profile must expose or resolve:
 
@@ -907,7 +949,7 @@ running.
 2. one Desktop runtime supervisor with start, interrupt, close, reconcile, and
    resume;
 3. `dsh` as the first reference runtime by reusing its accepted Turn adapter;
-4. Ark Agent Plan as the default configured provider profile;
+4. Ark Agent Plan as one explicitly selected provider preset;
 5. one resumable conversation and one-at-a-time bounded Turn execution; and
 6. joined runtime, Turn, and LoopX status in Desktop.
 

@@ -4,7 +4,7 @@
 - 决策边界：同时支持挂接到外部拥有的 Agent 会话，以及端到端由 LoopX 托管的桌面运行时
 - 初始挂接运行时：Codex App / app-server
 - 初始托管运行时：Pi 与 DeepSeek Harness（`dsh`）
-- 默认托管 provider 配置：火山方舟 Agent Plan
+- 托管 provider 选择：显式配置引导与用户意图约束，Agent 在已授权可用 profile 内自主分配；火山方舟 Agent Plan 保留为可选发行预设。
 
 ## 摘要
 
@@ -15,8 +15,9 @@ LoopX Desktop 应支持两种显式的执行前端模式：
    中断、恢复和执行循环的所有权。
 2. **托管 Agent 运行时（Managed Agent Runtime）**。LoopX Desktop 启动并
    监督 Pi 或 DeepSeek Harness，选择显式的 provider 配置，并通过有界的
-   `loopx_turn_v0` 事务推进工作。默认发行配置使用火山方舟 Agent Plan，
-   而运行时与 provider 契约保持可替换。
+   `loopx_turn_v0` 事务推进工作。发行版可提供命名的火山方舟 Agent Plan 预设，
+   操作者配置与明确意图约束 Agent 的自主分配；不把任何 provider 设为统一产品
+   默认。运行时与 provider 契约保持可替换。
 
 两种模式呈现相同的 LoopX Goal、Todo、gate、quota、evidence 和状态事实。
 它们不共享进程所有权。前端绝不能从聊天散文推断模式切换，也不得静默启动
@@ -36,6 +37,34 @@ manager Agent，也不把连接器硬编码到 Codex。
 下一个有界 Turn 是否有资格执行，调用所选运行时适配器，验证其结果，并提交
 被接受的状态。`loopx_turn_v0` 始终是一个事务，而不是第二个常驻调度器。
 
+## 显式配置引导、用户意图与自主分配
+
+这里细化 provider 默认策略，属于提案，不改变已发布运行时默认值，也不认证新
+适配器。复用现有 machine/Goal capability editor、provider store、会话绑定与
+调度准入，不新增 capability id、provider 实现或选路服务。
+
+- **配置让选择可用。** 展示已探测安装与登录、支持工具、模型/账户、费用或费用
+  未知、宿主在线条件和权限范围。发现不等于授权。命名预设是可选方案，不能覆盖
+  已有明确配置。
+- **用户明确意图约束选择。** 固定模型/账户、本地限定、预算和成员限制，按用户
+  声明的作用域生效。偏好不自动变成硬锁。不能把某位用户的 Codex 偏好，或某个
+  发行版的 Ark 预设，推广成全产品规则。未解决的明确约束冲突需要澄清。
+- **Agent 在范围内自主分配。** 按任务适配性、工具权限、成本和观测到的可用性，
+  选择可用模型/运行时、复用或请求 worker、重新分配后续工作。已授权的灵活资源池
+  不要求逐次确认。选择由 Agent 作语义判断；typed owner 执行资格、预算、权限和
+  会话 fence。
+
+在设置与团队详情投影有效 runtime/model/profile、分配理由和就绪状态，派发时
+重新验准入。锁定路径不可用就阻塞并给修复入口；灵活池中的成员不可用，可以选择
+另一条合格路径并明确回读。不能借替代扩大数据外发、凭证、费用权限或支持工具。
+活跃会话保留绑定与上下文所有权；已授权自主改派走现有显式重新绑定/continuation
+契约，不静默迁移会话。新增付费资源和范围变化保留原有决策边界。
+
+通过打包引导、Chat/管家和独立 CLI 验收：固定选择优先于预设；灵活分配不反复
+审批；锁定路径失效时保持阻塞；预算耗尽或未授权回退不产生执行；重启保持有效
+配置。可选 Lark 投影同一选择及自己的受众约束。用例通过前，这是分配设计而非
+运行保证。见[近期发布路线](loopx-overall-roadmap-v0.zh-CN.md#近期本地-agent-产品与发布路线)。
+
 ## 问题
 
 LoopX 已经拥有两个不同产品的零件：
@@ -446,7 +475,7 @@ managed 面板或 supervisor。
 
 1. 选择或创建 LoopX Goal 和工作 Agent 绑定；
 2. 选择 Pi 或 `dsh` 作为运行时；
-3. 选择托管 provider 配置，默认发行配置为 Ark Agent Plan；
+3. 引导配置 provider 与用户约束，由 Agent 在已授权可用 profile 内选择；提供命名的 Ark Agent Plan 预设；
 4. 验证运行时安装、provider 认证和已宣称能力；
 5. 启动一个运行时并创建一个不透明可恢复会话；
 6. 向同一会话发送用户输入；
@@ -497,8 +526,9 @@ Pi 和 `dsh` 实现同一个窄托管运行时契约，而不假装其内部循
 
 ### Provider 配置契约
 
-运行时选择与 provider 选择正交。Ark Agent Plan 是默认托管产品配置，而不是
-散落在 LoopX 内核各处的特例。
+运行时选择与 provider 选择正交。Ark Agent Plan 是命名的托管 provider 预设。
+显式配置引导、作用域内的用户意图与 Agent 自主分配共同选择合格 profile，
+不把 provider 规则散落在 LoopX 内核各处。
 
 一个 provider 配置必须暴露或解析：
 
@@ -770,7 +800,7 @@ executor 精确版本、完成情况、延迟、动作数、人工介入、禁
 2. 一个 Desktop 运行时监督器，支持 start、interrupt、close、reconcile 和
    resume；
 3. `dsh` 作为第一个参考运行时，复用其已被接受的 Turn 适配器；
-4. Ark Agent Plan 作为默认配置的 provider 配置；
+4. Ark Agent Plan 作为一个显式选择的 provider 预设；
 5. 一个可恢复对话和一次一个的有界 Turn 执行；以及
 6. 在 Desktop 中联合展示运行时、Turn 和 LoopX 状态。
 

@@ -309,12 +309,17 @@ Pausing the coordinator does not stop dispatched workers: name those workers and
 the remaining execution scope. If worker cancellation is unsupported, state it
 explicitly; a whole-team stop claim requires worker-owner termination readback.
 
-The current producer gap is substantive: `consume_return` records consumption,
-not version-bound requester adoption; research-specific adoption checks in an
-example are not a generic production projection. Extend the existing owning
-contract and its real caller where necessary, rather than inventing frontend
-completion from prose. Do not claim L1 complete until this gap is closed for the
-selected episode. Motion is retained only when it clarifies these transitions;
+Implementation checkpoint (2026-09-20): [#4762](https://github.com/loopx-project/loopx/pull/4762)
+is open and proposes version-bound response/revision/use inputs, explicit
+requester adoption into an accepted downstream artifact, evidence navigation,
+contextual feedback and scoped coordinator pause. File/SQLite, CLI/MCP and
+packaged-browser checks cover that local slice; the real GPT attempt stopped at
+MCP tool approval before an accepted artifact. This is neither shipped acceptance
+nor L1 qualification. Review and reuse that producer rather than rebuilding it.
+`consume_return` alone still means consumption, not version-bound adoption.
+Qualify the substantive independent objection, correction and useful synthesis
+through the selected real-model episode before claiming L1. Motion is retained
+only when it clarifies these transitions;
 remove effects that obscure absent execution, absent acceptance or source loss.
 Broader semantic zoom, extra actors and renderer experiments follow this exit.
 
@@ -354,6 +359,8 @@ sensitive event bodies in diagnostics.
 
 ## 11. Delivery order and relationship to aggressive R2 progress
 
+The [near-term local-agent launch](loopx-overall-roadmap-v0.md#near-term-local-agent-product-and-launch) uses L1 as its real-run demonstration and L2/G1 for sustained-team claims. Marketing preparation can run alongside implementation, but cannot advance these exits.
+
 | Slice | Complete useful result | Entry / exit | Owner and rollback |
 | --- | --- | --- | --- |
 | L0 Design and traceability | Interactive synthetic study, source audit and executable acceptance plan | Design review; V1/V3 concept checks; no live claim | Presentation; discard prototype, retain decisions |
@@ -403,7 +410,8 @@ motion, correction replay, evidence drill-down and degraded-state presentation.
 It launches no Agents and reads no private research data. It is not shipped in
 the product or used as live runtime evidence.
 
-**Current checkpoint:** L0 design proposal; L1–L3 unimplemented here. V1/V3 may be
+**Current checkpoint:** L0 design is merged; Section 9 records the open L1
+implementation candidate. Full L1 and L2–L3 remain unqualified. V1/V3 may be
 explored with the synthetic study; V2/V4/V5/V6/V7 remain unqualified until their
 required production or measured evidence exists. No G1/G3/G4 promotion follows.
 The exact delivery PR carries validation and review; roadmap pointers retain

@@ -252,10 +252,13 @@ session、提高历史 receipt 的语义强度或重置 provider。默认概览
 什么。暂停协调员不会停止已派发成员：须显示这些成员及仍在执行的范围。成员
 不支持取消时明确说明；宣称整队停止需要成员执行 owner 的终止回读。
 
-当前生产者缺口有实质意义：`consume_return` 只记录消费，不是绑定版本的请求方
-采用；示例中的投研专用采用检查，也不是通用生产投影。必要时扩展既有 owning
-contract 及其真实调用方，不能在前端从文字制造完成状态。所选过程补齐这些
-证据前，不宣称 L1 完成。动态只有让上述变化更清楚才保留；掩盖未执行、未验收
+实施检查点（2026-09-20）：[#4762](https://github.com/loopx-project/loopx/pull/4762)
+仍开放，提出版本绑定的响应/修订/使用输入、请求方对已验收下游产物的显式采用、
+证据导航、上下文反馈和范围限定的协调者暂停。File/SQLite、CLI/MCP 与打包浏览器
+检查覆盖本地切片；真实 GPT 尝试在产物被验收前被 MCP 工具审批拦截。这不代表
+已发布验收或 L1 资格。review 并复用该 producer，避免重做；`consume_return` 单独
+仍只代表消费。宣称 L1 前须以真实模型过程验收实质的独立异议、纠偏与有用综合。
+动态只有让上述变化更清楚才保留；掩盖未执行、未验收
 或来源失联的效果应移除。更广的语义缩放、成员扩张和 renderer 探索在此后推进。
 
 ### 资格化矩阵
@@ -288,6 +291,8 @@ V5 候选目标在实验前定稿：前台动态目标 60fps / 优雅降级底
 
 ## 11. 交付顺序与激进推进 R2 的关系
 
+[近期本地 Agent 发布路线](loopx-overall-roadmap-v0.zh-CN.md#近期本地-agent-产品与发布路线)以 L1 作为真实运行演示，以 L2/G1 支撑持续团队承诺。宣传准备可与实现同期推进，但不替代这些验收。
+
 | 切片 | 完整有用结果 | 进入 / 退出 | Owner 与回滚 |
 | --- | --- | --- | --- |
 | L0 设计与可追溯性 | 可交互合成研究、源审计、可执行验收计划 | 设计评审；V1/V3 概念检查；不声明 live | Presentation；丢弃原型，保留决策 |
@@ -325,6 +330,6 @@ SSE。第 6 节一手资料支撑设计选项，不构成产品验收。一个
 空间成员、单次交接动态、纠偏回放、证据深入与降级状态；不启动 Agent，不读取
 私人投研数据，未作为产品发布，也不充当真实 runtime 证据。
 
-**当前检查点：** L0 设计提案；本文未实现 L1–L3。合成研究可探索 V1/V3；
+**当前检查点：** L0 设计已合并；第 9 节记录开放中的 L1 实现候选。完整 L1 及 L2–L3 仍未验收。合成研究可探索 V1/V3；
 V2/V4/V5/V6/V7 在获得其要求的生产或测量证据前都未资格化。不晋升 G1/G3/G4。
 准确交付 PR 承载验证与 review；总路线只投影此边界，不再追加运行任务账本。