From 4d79b9c5d74b28e033d17b44a0d4f39ef907076d Mon Sep 17 00:00:00 2001 From: huangruiteng <14976749+huangruiteng@users.noreply.github.com> Date: Wed, 16 Sep 2026 23:31:48 +0800 Subject: [PATCH] docs: establish the LoopX overall product and delivery roadmap Signed-off-by: huangruiteng <14976749+huangruiteng@users.noreply.github.com> --- docs/architecture/rfcs/README.md | 34 +- .../rfcs/agent-session-execution-modes-v0.md | 6 + .../agent-session-execution-modes-v0.zh-CN.md | 6 + .../capable-manager-semantic-handoff-v0.md | 10 +- ...pable-manager-semantic-handoff-v0.zh-CN.md | 10 +- .../rfcs/desktop-execution-frontends-v0.md | 6 + .../desktop-execution-frontends-v0.zh-CN.md | 6 + .../rfcs/harness-selection-dsh-pi-v0.md | 284 ++++----------- .../rfcs/harness-selection-dsh-pi-v0.zh-CN.md | 174 ++-------- .../rfcs/loopx-overall-roadmap-v0.md | 324 ++++++++++++++++++ .../rfcs/loopx-overall-roadmap-v0.zh-CN.md | 324 ++++++++++++++++++ .../rfcs/manager-runtime-profile-v0.md | 4 + .../rfcs/manager-runtime-profile-v0.zh-CN.md | 4 + ...oal-alignment-and-governed-amendment-v0.md | 6 + ...ignment-and-governed-amendment-v0.zh-CN.md | 6 + ...shared-goal-authority-state-provider-v0.md | 13 +- ...-goal-authority-state-provider-v0.zh-CN.md | 12 +- .../typescript-control-plane-migration-v0.md | 6 + ...script-control-plane-migration-v0.zh-CN.md | 6 + docs/product/roadmaps/README.md | 4 + docs/project/technical-directions.md | 21 +- docs/project/technical-directions.zh-CN.md | 19 +- 22 files changed, 877 insertions(+), 408 deletions(-) create mode 100644 docs/architecture/rfcs/loopx-overall-roadmap-v0.md create mode 100644 docs/architecture/rfcs/loopx-overall-roadmap-v0.zh-CN.md diff --git a/docs/architecture/rfcs/README.md b/docs/architecture/rfcs/README.md index 8fb5f4d8f2..1691245074 100644 --- a/docs/architecture/rfcs/README.md +++ b/docs/architecture/rfcs/README.md @@ -46,6 +46,18 @@ This index was last audited against `main` on **2026-09-04**. Update an entry whenever its RFC status, promoted behavior, or meaningful delivery boundary changes. +## Overall Product and Delivery Roadmap + +- [LoopX Overall Roadmap v0](loopx-overall-roadmap-v0.md) + ([中文版](loopx-overall-roadmap-v0.zh-CN.md)) + - **RFC status:** Draft portfolio roadmap. + - **Delivery on `main`:** Planning and audit evidence, not runtime promotion. + - **Current boundary:** Maps all 30 pre-existing primary RFCs and important + non-RFC domains into 13 streams, G0–G5 product milestones and R1–R7 core + execution cards. Covers product, multi-LoopX-Agent collaboration/handoff, + kernel, hosts, memory, cost, security, operations, research, releases, + community and adoption. Domain contracts retain their authority gates. + ## Control-Plane Kernel, State, And Migration - [Human-confirmed domain operations v0](human-confirmed-domain-operations-v0.md) @@ -95,8 +107,10 @@ changes. default-off local shadow/cutover foundations are on `main` ([#3529](https://github.com/huangruiteng/loopx/pull/3529), [#3669](https://github.com/huangruiteng/loopx/pull/3669), - [#3798](https://github.com/huangruiteng/loopx/pull/3798)). No provider-first - runtime promotion or remote shared-authority service has shipped. + [#3798](https://github.com/huangruiteng/loopx/pull/3798)). In-process PostgreSQL + service admission and identity rotation also exist; + deployed authenticated remote service and provider promotion remain distinct + qualification gates. - [Shared Goal Alignment and Governed Amendment Protocol v0](shared-goal-alignment-and-governed-amendment-v0.md) ([中文版](shared-goal-alignment-and-governed-amendment-v0.zh-CN.md)) - **RFC status:** Draft, under maintainer review. @@ -173,7 +187,8 @@ changes. - [Capable Agent Manager and Semantic Work Handoff v0](capable-manager-semantic-handoff-v0.md) ([中文版](capable-manager-semantic-handoff-v0.zh-CN.md)) - **RFC status:** Draft, under maintainer review. - - **Delivery on `main`:** Proposal; existing manager/inbox foundations are reused. + - **Delivery on `main`:** Partial; private runtime profile, executor settings, + team-plan confirmation and initial Todo materialization shipped. - **Current boundary:** Proposes ordinary host-tool autonomy, persistent scoped conversations, long-horizon semantic continuation and automatic result delivery. Includes an official Grok Bot study distinguishing availability from goal @@ -181,7 +196,8 @@ changes. alignment, shared-authority and TS migration dependencies. Cross-session restoration, execution takeover and automatic return are specified separately, reusing #4094 with optional Obelisk gap recall under its own scope. - Runtime-profile promotion and generic handoff migration have not shipped. + Full runtime-profile qualification and generic handoff migration remain open. + - [Explicit Todo Continuation — Stage A](cross-session-memory-substrate-v0.md) ([中文版](cross-session-memory-substrate-v0.zh-CN.md)) @@ -296,10 +312,12 @@ changes. - [Long-Running Agent Reliability Diagnostics and Governed Delivery v0](long-running-agent-reliability-diagnostics-governed-delivery-v0.md) ([中文版](long-running-agent-reliability-diagnostics-governed-delivery-v0.zh-CN.md)) - **RFC status:** Draft, product direction and delivery contract. - - **Delivery on `main`:** Direction only. - - **Current boundary:** The observer-first adoption path, matched benchmark - qualification, and governed delivery package are proposed; no unified - product contract has been promoted. + - **Delivery on `main`:** Default-off L1 diagnostic prototype and first DSH + event-source adapter implemented. + - **Current boundary:** The capability-owned README records the prototype; + C0 adapter fidelity, C1 non-interference and measured overhead remain + required before P0 exit. Broader governed delivery and commercial adoption + remain proposals. RFCs must not contain internal conversations, private links, local filesystem paths, credentials, raw transcripts, or non-public organizational context. diff --git a/docs/architecture/rfcs/agent-session-execution-modes-v0.md b/docs/architecture/rfcs/agent-session-execution-modes-v0.md index 4703c15ba8..7195d557c5 100644 --- a/docs/architecture/rfcs/agent-session-execution-modes-v0.md +++ b/docs/architecture/rfcs/agent-session-execution-modes-v0.md @@ -454,6 +454,12 @@ at least one real-host row: a live process, a real bind, and a real restart. - **Recovery.** An interrupted executor turn is reconciled before retry. A validated result is journaled before lifecycle writeback. +### Long-horizon managed route (2026-09-16) + +[Roadmap](loopx-overall-roadmap-v0.md) R2 first qualifies a steward and 2–3 actual managed workers across Turns; R6 qualifies local/cloud execution on one authority, then R7 expands active scale. M1–M4 here retain host admission ownership. Team-plan `ready` cannot replace binding, qualification, claim/lease or actual process readback. + +DSH steward Chat is currently single-segment, read-only and without cross-turn host sessions; `turn run-once` is a separate bounded execution path. The next slice proves successor wake, cancellation/stop, crash recovery and returning stale-executor fences with packaged frontend/CLI/Lark readback. An executor name, one segment or multiple registrations cannot establish continuous managed execution. Disconnection never switches attached hosts to managed, and unqualified hosts retain their existing boundary. + ## 12. Normative delivery plan | Milestone | Shipped behavior | Entry gate | Exit evidence | Rollback | diff --git a/docs/architecture/rfcs/agent-session-execution-modes-v0.zh-CN.md b/docs/architecture/rfcs/agent-session-execution-modes-v0.zh-CN.md index bf832fb1a3..b0885874e7 100644 --- a/docs/architecture/rfcs/agent-session-execution-modes-v0.zh-CN.md +++ b/docs/architecture/rfcs/agent-session-execution-modes-v0.zh-CN.md @@ -364,6 +364,12 @@ claim 与完成回执，以及"只有经过验证的回写才推进工作"这一 - **恢复。** 被中断的执行器 turn 在重试前先被协调。经过验证的结果在生命周期回写之前 先被记录。 +### 长程 managed 执行路线（2026-09-16） + +[统一路线](loopx-overall-roadmap-v0.zh-CN.md) R2 先验一个管家与 2–3 个真实 managed worker 的跨 Turn 闭环；R6 再验本地/云端同 authority，R7 才扩大活跃规模。本 RFC M1–M4 继续拥有宿主接入，不用团队计划的 `ready` 取代 binding、资格、claim/lease 或实际进程读回。 + +目前 DSH 管家 Chat 是单段、只读、无跨 turn 宿主会话；`turn run-once` 是另一条有界执行路径。下一切片要证明 successor wake、取消/停止、崩溃恢复及旧执行器返回 fence，经 packaged frontend/CLI/Lark 回读真实状态。不能仅增加一个 executor 名称、启动一个片段或绑定若干 Agent 就声称持续 managed 模式完成。attached host 不因掉线而改为 managed，未验收宿主保持原资格边界。 + ## 12. 规范性交付计划 | 里程碑 | 交付行为 | 进入门槛 | 退出证据 | 回滚 | diff --git a/docs/architecture/rfcs/capable-manager-semantic-handoff-v0.md b/docs/architecture/rfcs/capable-manager-semantic-handoff-v0.md index d4e00a1b11..708f7dbbeb 100644 --- a/docs/architecture/rfcs/capable-manager-semantic-handoff-v0.md +++ b/docs/architecture/rfcs/capable-manager-semantic-handoff-v0.md @@ -1,7 +1,7 @@ # RFC: Capable Agent Manager and Semantic Work Handoff (v0) - **RFC status:** Draft, under maintainer review -- **Delivery maturity:** Proposal; existing foundations are identified in Section 4 +- **Delivery maturity:** Partial; private runtime profile, team-plan confirmation and Todo materialization shipped; complete M1–M4 remain unqualified. - **Authors / owners:** LoopX maintainers; manager engineering owner - **Created / last normative revision:** 2026-09-13 / 2026-09-15 - **Implementation baseline:** `7eb4b7bb1661bd5eff63a8725a33169792d5964b` @@ -61,6 +61,12 @@ Include global manager conversations, host-native investigation, ordinary author Do not build a replacement agent runtime, a second scheduler, an external-agent marketplace, a new repository API, a universal workflow DSL or a duplicate task database. A substantial refactor of the current manager, collaboration and adapter boundaries is explicitly in scope; conserving current code volume or module names is not an acceptance goal. Do not require OpenViking, a shared online database or A2A to make local handoffs correct. Do not copy private reasoning traces or complete historical transcripts into every request. Complex financial and other domain effects remain owned by their capabilities and execution adapters. +### Current cross-RFC route (2026-09-16) + +At `43d362532`, the private `manager_runtime` profile, steward executor configuration and team preview→frontend confirmation→initial Todo materialization have implementations. #4547/#4548/#4552 supply confirmation UI, bundle and browser fixture; they do not prove worker execution. DSH Chat remains a bounded read-only segment without cross-turn host sessions and cannot borrow Codex `trusted_owner` qualification. + +The [overall roadmap](loopx-overall-roadmap-v0.md) records verified F1–F7 and R1–R7. Repair R1 commitment preservation, stale basis and recovery first, then qualify R2 small teams; M2/M3 converge through R3, and M4 requires real user journeys. Section 4 retains its older baseline as migration input, not an override of this checkpoint. Partial merges do not complete M1–M4. Parallel joins, pipeline dependencies, peer help/review, execution responsibility continuation and cross-host collaboration between long-running LoopX Agents follow the roadmap Section 5 matrix. R2 requires real inter-Agent handoff; M2/M3 cannot reduce to steward broadcasts or one-turn forwarding. + ## 4. Current-system contract: audited facts The baseline already has substantial reusable machinery: @@ -501,7 +507,7 @@ If this program changes a provider, retention or authority-source profile, its a ### 11.2 Execution order and integration receipts -1. **Start M1; finish baseline reconciliation in that PR.** Record the exact source head and actual runtime/entrypoint call sites. Fix the owner-private profile and existing readback/feedback. Run A1–A3/A12. Do not deliver a standalone inventory framework. +1. **Complete and qualify M1 through R1/R2 without rebuilding shipped profiles/entrypoints.** Record the exact source head and actual runtime/entrypoint call sites. Fix the owner-private profile and existing readback/feedback. Run A1–A3/A12. Do not deliver a standalone inventory framework. 2. **Replace one complete M2 request transaction, then attach receivers.** Begin from `manager_context` request/tracking/return producers and both real consumers, including the shipped #4094 CLI continuation adapter (§5.13). Publish the before/after ownership map, migration mapping and the migration economics review artifact (§5.12). Preserve accepted work state through existing commands; qualify crash-between-commits and legacy/promoted sources before widening producer rollout. Use existing alignment source-basis reads, not a copied classifier. 3. **Close M3 automatic return and user visibility.** Independent reply recovery can ship in parallel with steps 1–2. Integrate the generic producer only after its receipt contract is stable; exercise A8–A10, A13–A16 and A17/A20 across the actual entrance/receiver/return paths. With the source session gone, verify the same committed result/outbox identity, reconnect recovery and audience isolation through packaged frontend, Lark and CLI readback. 4. **Promote a named M4 cohort and remove the replaced paths.** Keep provider default, Goal-intent authority and capability qualifications explicit. Shared-amendment commit integration follows its upstream readiness; until then the UI says proposal/admission or unsupported commit, never “Goal changed.” Provider source migration follows the shared-authority program rather than this release. diff --git a/docs/architecture/rfcs/capable-manager-semantic-handoff-v0.zh-CN.md b/docs/architecture/rfcs/capable-manager-semantic-handoff-v0.zh-CN.md index 9f1be01f1a..6a328c6db4 100644 --- a/docs/architecture/rfcs/capable-manager-semantic-handoff-v0.zh-CN.md +++ b/docs/architecture/rfcs/capable-manager-semantic-handoff-v0.zh-CN.md @@ -1,7 +1,7 @@ # RFC：强能力 Agent 管家与语义工作交接（v0） - **RFC 状态：** Draft，待维护者审阅 -- **交付成熟度：** 提案；已有基础见第 4 节 +- **交付成熟度：** Partial；私人运行 profile、团队计划确认与 Todo 物化已交付，完整 M1–M4 未验收。 - **作者 / 责任人：** LoopX 维护者、管家工程负责人 - **创建 / 最近规范修订：** 2026-09-13 / 2026-09-15 - **实现基线：** `7eb4b7bb1661bd5eff63a8725a33169792d5964b` @@ -61,6 +61,12 @@ 不重造 Agent runtime、第二套调度器、外部 Agent 市场、新仓库 API、通用工作流 DSL 或任务数据库。明确允许对现有管家、协作和 adapter 边界大幅重构；保住现有代码体积或模块名字不是验收目标。本地交接正确性不依赖 OpenViking、在线共享数据库或 A2A。每个请求不携带私人推理轨迹和完整历史。复杂金融等垂域效果继续归各 capability 和执行 adapter。 +### 跨 RFC 当前路线（2026-09-16） + +在 `43d362532`，本 RFC 的私人 `manager_runtime` profile、管家执行器配置，以及团队计划预览→前端确认→首批 Todo 物化已有实现。#4547/#4548/#4552 提供确认 UI、打包产物及 browser fixture；它们不证明 worker 已运行。DSH Chat 仍是只读有界片段，无跨 turn 宿主会话，不能借用 Codex `trusted_owner` 的资格。 + +[整体路线总纲](loopx-overall-roadmap-v0.zh-CN.md) 记录已复核 F1–F7 与 R1–R7 执行卡。优先修 R1 承诺保留、stale basis 和恢复，再验 R2 小团队；M2/M3 按 R3 收敛，M4 需真实用户旅程。第 4 节的旧基线保留为迁移输入，不能覆盖本检查点；不因局部切片合并将 M1–M4 标为完成。 多个长程 LoopX Agent 的并行汇合、流水线依赖、peer 求助/复核、执行责任接续和跨 host 协作，统一按路线第 5 节协作矩阵验收；R2 必须包含真实 Agent 间 handoff，M2/M3 不能退化为管家广播或单轮转发。 + ## 4. 当前系统：已核对的基线事实 已有大量基础应该复用： @@ -501,7 +507,7 @@ M1 不必等通用 handoff 重构。M3 独立的格式/投递修复可先用已 ### 11.2 执行顺序与衔接回执 -1. **启动 M1，在该 PR 内完成基线对齐。** 记录精确 source head、真实 runtime/入口 caller；修主人私人 profile 和已有读回/反馈；验 A1–A3/A12。不单独交付盘点框架。 +1. **按 R1/R2 补齐并验收 M1，不重建已交付 profile/入口。** 记录精确 source head、真实 runtime/入口 caller；修主人私人 profile 和已有读回/反馈；验 A1–A3/A12。不单独交付盘点框架。 2. **替换一个完整 M2 请求事务，再接接收方。** 从 `manager_context` request/tracking/return producer 和两种真实消费者开始，提交前后 owner 图、迁移映射、migration economics 审阅工件（§5.12）。工作状态继续走已有命令；扩大 producer 上线前验提交间崩溃和 legacy/promoted source。复用 alignment source-basis 读取，不复制分类器。 显式纳入已交付 #4094 CLI 接续 adapter（§5.13）。 3. **收口 M3 自动回传和用户可见性。** 独立正文恢复可与前两步并行；通用 producer 待回执契约稳定再接。沿真实入口/接收方/返回路径验 A8–A10、A13–A16、A17/A20；在来源 session 已消失时，通过 packaged frontend、飞书、CLI 读回核实同一已提交结果/outbox 身份、重连恢复和受众隔离。 4. **晋级指定 M4 cohort，并删除被替换路径。** 明确 provider 默认、Goal-intent authority、capability 资格。共享 amendment commit 待上游就绪；此前 UI 只能说提案/准入或不支持提交，不能说“Goal 已修改”。provider source 迁移按 shared-authority 计划，不夹进本次发布。 diff --git a/docs/architecture/rfcs/desktop-execution-frontends-v0.md b/docs/architecture/rfcs/desktop-execution-frontends-v0.md index 7393192ccf..8bd428e18e 100644 --- a/docs/architecture/rfcs/desktop-execution-frontends-v0.md +++ b/docs/architecture/rfcs/desktop-execution-frontends-v0.md @@ -768,6 +768,12 @@ trust binding fails closed. - Use synthetic provider fixtures for committed tests and make live provider tests explicit and opt-in. +### Team coordination product loop (2026-09-16) + +#4547/#4548/#4552 delivered team-preview confirmation UI, packaged resources and a browser fixture; the confirmation entry is no longer unimplemented. Follow [roadmap](loopx-overall-roadmap-v0.md) R1 for semantically accurate partial/gap/stale readback, R2 for actual worker execution and R3 for automatic return/restart recovery. The confirmation fixture does not prove the complete Lark loop. + +Frontend/Lark consume the same proposal, receipt and audience projection; confirmed plans cannot imply execution. Every implementation includes real packaged-frontend interaction and applicable Lark qualification, or explicitly names the untested surface. First-viewport/primary-CTA implementation changes still require concrete preview approval. This revision edits RFCs only, not UI. + ## Delivery slices ### Slice A: Agent-scoped Lark connection diff --git a/docs/architecture/rfcs/desktop-execution-frontends-v0.zh-CN.md b/docs/architecture/rfcs/desktop-execution-frontends-v0.zh-CN.md index 48fae6b85f..bb01935762 100644 --- a/docs/architecture/rfcs/desktop-execution-frontends-v0.zh-CN.md +++ b/docs/architecture/rfcs/desktop-execution-frontends-v0.zh-CN.md @@ -638,6 +638,12 @@ executor 精确版本、完成情况、延迟、动作数、人工介入、禁 - 不把私有部署或协作上下文复制到公共 fixtures、截图、示例或文档中。 - 已提交测试使用合成 provider fixtures，并把真实 provider 测试设为显式可选。 +### 团队协调的产品闭环（2026-09-16） + +#4547/#4548/#4552 已交付团队预览确认 UI、打包资源及 browser fixture，不再把确认入口列为未实现。按[统一路线](loopx-overall-roadmap-v0.zh-CN.md) R1 补语义一致的 partial/gap/stale 回读，R2 验 worker 实际执行，R3 验自动回报和重启恢复。现有确认 fixture 不能证明 Lark 端完整闭环。 + +前端/Lark 消费同一 proposal、receipt 和 audience projection；运行状态不能由计划已确认推断。每个实现批次含 packaged frontend 的实际交互和 Lark 适用路径验收，或明确说明未验收。涉及首屏/主 CTA 的实现继续先展示具体预览并获批准；本次仅更新 RFC，不修改 UI。 + ## 交付切片 ### 切片 A：Agent 级 Lark 连接 diff --git a/docs/architecture/rfcs/harness-selection-dsh-pi-v0.md b/docs/architecture/rfcs/harness-selection-dsh-pi-v0.md index 4ab60498e3..aa145d5b9f 100644 --- a/docs/architecture/rfcs/harness-selection-dsh-pi-v0.md +++ b/docs/architecture/rfcs/harness-selection-dsh-pi-v0.md @@ -512,217 +512,69 @@ header chip resolved `dsh` while the picker previously reported `Codex`. ## Steward Team Intake (2026-09-16) -The steward answers questions. Since `2026-09-16` its shipped guidance also -carries one bounded procedure for a different request: one owner sentence that -asks for a *team* rather than a task. This section records the enforced contract -for that intake, which part of it is already shipped, and which part is still -missing. - -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. - -A proposal of kind `steward_team_plan_preview` (`steward_team_plan_preview_v0`) -is validated before anything may be applied, and a validated preview names, and -may not invent: - -- the exact Goal the plan staffs, so the admission that validates its lanes and - the settlement that materializes them describe one Goal rather than two; -- each lane and the Agent that runs it, resolved from the Agents Core already - registers for the Goal, at most 8 lanes; -- that lane's first bounded Todo, with its declared priority (P0..P3), task - class and action kind; -- the quota 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 -- `agent_not_registered`, -`capability_not_granted` or `audience_not_authorized`, plus the host's own -`action_kind_not_supported` -- and the gap keeps the work it did not staff under -`declined_first_todo`, so the owner sees what was asked for and what is missing -instead of a lane that was quietly filled in or dropped. The reasons a plan may -declare for a lane it cannot staff itself and the reasons the host reports about -one are two vocabularies: a plan cannot claim the host's verdict about its own -lane, and a reader can tell a declared gap from a staffability verdict Core made. - -Two facts about *one lane* can make it unstaffable: this Goal does not register -its Agent, or this host does not ship the action kind the lane asked for. Both -are lane facts, so both become the same typed gap and neither refuses the plan: -a plan whose first lane cannot be staffed is still the owner's request, and its -staffable lanes are exactly what the owner asked to review. Refusing the whole -plan for one lane's kind is what made a live steward answer a one-sentence team -request correctly and still offer the owner nothing to confirm. - -A lane that declares a gap may not declare work. The plan is a preview: -the validated payload carries `applies: false`, 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, may not widen -the confirmed scope, and a team plan is never settled as if the work were done. -The confirmed payload is therefore a fixed point of the validator: validating an -admitted preview again returns the same lanes, and a lane the preview reported as -unstaffed is preserved as a gap rather than re-derived from the host's *current* -facts, so an apply can never staff a lane the owner was shown as unstaffed. - -Shipped enforcement, in delivery order: - -1. **Contract and validator** (`#4519`, `3acd07697`). The kind, its schema, the - lane limit, the priority and gap vocabularies, public-safe text, and the - refusal to invent staffing. -2. **Chat admission** (`#4522`, `3c8c832cb`). `normalize_agent_response` admits a - preview only when the host supplies `team_plan_context` -- this Goal's - registered Agents and this host's supported advancement action kinds -- and - drops it otherwise, exactly like any other proposal it cannot accept, while - the answer text still reaches the owner. -3. **Apply** (`#4524`, `c159a15b3`). The governed transition owner dispatches the - kind at `PRE_SETTLEMENT`. The apply re-validates the proposal against the - Goal's registered Agents and the shipped advancement action kinds, creates - the first bounded Todo of each *ready* lane through the canonical Todo owner, - creates nothing for a gap lane, refuses an unknown Goal before any write, and - refuses a plan whose named Goal differs from its settlement, so a plan - admitted against one Goal's Agents cannot be retargeted into another's. - The receipt records the proposal digest, so a replayed settlement reuses the - same lane Todo instead of adding a second row, and the receipt names every - lane Todo the settlement ensured. -4. **Admission facts.** The manager channel's Turn attaches a per-Goal lookup to - the segment that parses the answer, so a preview is validated against the - Agents of the Goal it names: the owner's own channel resolves any registered - Goal, an external manager channel resolves only the Goals it is bound to, and - a Goal the registry does not know - or one outside that channel's scope - - drops the preview instead of validating it against another Goal's Agents. - The shipped steward guidance requires the plan to name that Goal, because a - plan that does not name it is dropped rather than shown. -5. **Confirmed apply from Chat.** The typed Chat action surface owns a - `team.plan` action. Its preview validates the plan against that Goal's - registered Agents and the host's advancement action kinds, and its apply - re-validates the same payload through the governed transition owner at - `PRE_SETTLEMENT`, so one owner confirmation creates each ready lane's first - bounded Todo and returns the lane readback. A registration change between - preview and apply makes the proposal stale rather than applying a plan whose - staffing has drifted. -6. **Admitted preview to confirmable card.** The owner's own local manager - channel projects the preview it admitted into the typed action store, so the - product surface the owner already reads lists exactly one `team.plan` card - scoped to the Goal the plan staffs. The projection is idempotent per plan, so - a replayed Turn or a repeated ask reuses the card instead of stacking a - second one; it creates no work, and it grants nothing that confirming the card - would not grant. A Turn response now carries the preview beside its Todo - proposals, so the surfaces read one response shape instead of deciding which - kinds of answer may arrive. -7. **The answer says where the confirmation is.** Every manager answer that - admitted a preview carries one channel-authored pointer line naming the Goal - whose workspace holds the card and the fact that no lane exists before that - confirmation. It is a receipt, not a rewrite: the steward's prose is - preserved, and a Goal channel is never annotated. A remote manager audience - receives the pointer as well, which is what makes one manager answer - actionable even where the audience that asked cannot itself confirm. - -The owner's own channel ships both the card and the sentence that explains it: -the admitted preview reaches the typed action store, the card renders the same -click path a single-lane `team.plan` card already had, and the answer the owner -reads names the Goal whose workspace holds that card. That sentence is the -channel's, not the model's, and a remote manager audience receives it too -- -one manager answer is therefore actionable for every audience that can read it, -because the audience that asked may not be the audience that can confirm. -What is still missing is the remote audience's *own* confirmation surface: a -Lark manager channel has no card of its own, so nothing is written on its -behalf, and its owner confirms in the LoopX workspace the answer named. -Traceability is recorded rather than implied: the settlement reads -the Goal's canonical source basis before it writes, and the receipt carries it as -a bounded `intent_basis`, so each lane Todo can be tied to the revision it was -meant to advance even though the Todo row itself does not carry the field. The -readback is no longer a gap either: the apply publishes every lane Todo it ensured -under a bounded `lane_todo_ids` field, both fields are additive exceptions to the -closed, persisted receipt field set so a receipt written before them still -validates, and a team-plan receipt carries no monitor key because a plan is not a -monitor. - -### 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 steward's "who else is working" ability is the peer-directory contract.** - The steward and the lanes it staffs are two callers of - [`peer_agent_directory_v0`](../../reference/protocols/peer-agent-directory-and-observation-v0.md): - the steward is the manager-channel audience, scoped by its channel's Goal - binding, and each lane is a `peer_v1` audience, scoped by the Goal's registered - Agents. One contract answers both, at three layers -- typed state and governed - commands, the in-space skill a running Agent loads, and a provider surface that - may supply live presence and nothing else -- so this intake does not grow a - steward-only directory beside the peer one. Both audiences obey the same - limits: observation and delivery grant nothing, a bounded wait pins the - identity it resolved and requires the observed state to move, and a "who needs - a decision now" rollup orders attention without assigning work. - The contract's first local producer ships as `loopx agent-directory --goal-id - [--agent-id ]`, which re-projects the existing agent management - projection instead of reading the registry twice, reports no presence while no - presence provider is registered, and returns a typed scope gap instead of rows - to a caller that is not a registered Agent of that Goal. -- **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 --agent-id `): - 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 -these effects; and nothing here widens OS, provider, audience or work-state -authority. - -## Steward Channel Readiness by Milestone (2026-09-15) +Audited at `43d362532`. Team intake has shipped a bounded preview, owner +confirmation and first-Todo materialization. It has not qualified a running, +budget-enforced or intent-aligned team. The [overall roadmap](loopx-overall-roadmap-v0.md) +owns cross-RFC priorities and F1–F7/R1–R7; this selection RFC owns runtime +selection and its qualification evidence, not a separate team architecture. + +The shipped boundary is `steward_team_plan_preview_v0`, kind +`steward_team_plan_preview`, dispatched through +`loopx/control_plane/work_items/governed_transition_proposal.py` and Chat +`team.plan`. It names an exact Goal, 1–8 lanes, registered Agent identities, +first Todo text/priority/class/action, acceptance, quota envelope and stop +condition. Validation produces `applies: false`. Preview is not execution. + +| Boundary | Shipped behavior | Remaining limitation | +| --- | --- | --- | +| Validation/admission (#4519/#4522/#4532/#4533) | Exact Goal, registered Agents, supported advancement kinds and bounded public-safe fields; channel-scoped Goal lookup; unavailable facts drop the proposal while preserving answer text | `ready` checks registration/action support, not executor health, tool eligibility or budget admission | +| Staffing gaps | Unknown Agent produces `agent_not_registered` and retains `declined_first_todo`; explicit `capability_not_granted` / `audience_not_authorized` gaps admit no work | These reason codes do not prove all capability/audience conditions are automatically detected | +| Materialization (#4524/#4528/#4535/#4538) | Revalidates the named Goal; calls canonical Todo owner per ready lane; records proposal digest and bounded `lane_todo_ids`; existing receipt shape remains readable; no monitor key | Confirmed priority is dropped; acceptance/quota/stop are not execution constraints on this path; no atomic team commit or automatic partial-recovery proof | +| Confirmation (#4547/#4548/#4552) | Existing frontend displays lanes/gaps and submits `team.plan`; bundle and browser fixture shipped | Lark and real worker execution were not qualified by this fixture; all-gap apply currently reports `team_plan_lanes_already_present` with no Todos | +| Freshness | Registry byte changes make the Chat preview stale; optional `intent_basis` reads alignment source facts before materialization | No exact Goal-intent/authorization/work precondition at commit; `intent_basis` is neither the full intent revision nor a CAS fence | + +Unchanged-plan retries are covered by focused tests. Do not generalize those +tests to concurrent plans, interrupted multi-lane commits or intervening Todo +edits. R1 qualifies those cases through the actual action and recovery paths. + +Latest integration checkpoint: #4569 (`f1166e81e`) keeps unsupported action kinds as lane-local gaps, distinguishes declared gaps from host verdicts, preserves admitted gaps on revalidation and projects admitted plans into local owner-channel cards. A blocked lane no longer rejects the whole plan. The Lark manager audience still has no corresponding card. These fixes do not establish plan execution or resolve the baseline F1–F4 commitment/recovery findings. + +Subsequent #4572 (`0aa6179de`) appends a channel-authored confirmation-location pointer to manager answers, naming the Goal workspace. Local and remote manager audiences receive it; Goal channels are not annotated. A remote pointer does not create a Lark card or prove card persistence/team execution; model prose is preserved. + +### Relationship to multi-agent and shared authority + +The [alignment RFC](shared-goal-alignment-and-governed-amendment-v0.md) owns +shared intent and governed amendments; [shared authority](shared-goal-authority-state-provider-v0.md) +owns persistence/promotion. A team plan proposes work inside accepted intent; +it cannot change permissions, shared acceptance or terminal conditions by +placing prose in its envelope. Stage 3 amendment commit remains unshipped. +The optional receipt `intent_basis` is the existing `source_basis_digest`, +not a version of that unimplemented full intent envelope. Historical receipts +must not acquire stronger semantics through a rename. + +`peer_v1` permits a steward to organize, delegate and synthesize, without +unilateral write, claim, priority or preemption authority. Lanes refer to the +same canonical graph and per-Agent frontier. Creating `claimed_by` Todos does +not acquire task leases, launch workers or reserve distributed quota. + +The [peer directory](../../reference/protocols/peer-agent-directory-and-observation-v0.md) +is shared by manager and peer callers. `loopx agent-directory --goal-id +[--agent-id ]` reuses the management projection, caps local rows at 24, +reports omitted rows, has no pagination or presence provider and does not +project lease epochs. A supplied unregistered caller gets a scope gap. Local +CLI membership checks do not authenticate a remote caller; any future remote +entry must derive caller identity from a verified binding. + +Per-Agent readback uses `loopx shared-goal-alignment --goal-id --agent-id +`, within its Stage 1/2 source-facts boundary. The plan receipt does not +project that entire state. The [three-layer contract](../../reference/protocols/multi-agent-three-layer-minimality-v0.md) +and [visible launcher](../../reference/protocols/multi-agent-visible-launcher-v0.md) +remain independent owners: user intent, preset procedure and kernel declarations +join by Goal/Agent/Todo identity, not by creating another runner, pane owner, +vision budget or evidence loop. Selecting an executor or storing credentials +grants none of these effects. + +## Steward Channel Readiness by Milestone (2026-09-16) The steward channel consumes both this document's host selection and the manager milestones in @@ -732,20 +584,18 @@ on today and which stay unverified. It states product contracts, not conversatio content: no live channel transcript, audience identity, dated incident or operator-local path is recorded here. -| Milestone | Steward-channel contract in scope | Evidence state on 2026-09-15 | +| Milestone | Steward-channel contract in scope | Evidence state on 2026-09-16 | | --- | --- | --- | | Manager M1 — useful host agent | The channel resolves and reports its effective executor, model, reasoning effort and source, the executor selection does not follow a credential, and a host that cannot launch fails with a typed reason instead of a silent individual-login fallback | Shipped: selected endpoint with its source and default-rule reason, the executor's `execution_profile`, `executor_kind`, and the `channel_binding` readback (PR #4446 with the Turn-side readback in PR #4443; the unconditional default and the segment transport land with this change). The upstream **session identity** is still not projected to the channel, so a channel answer cannot yet prove which session served it | -| Manager M2 — semantic continuation | Receiver resolution across registered running lanes; typed per-source coverage and freshness; a goal-level milestone the report can lead with instead of coverage disclaimers | Not implemented. Delegation resolves against the supplied delegation catalog, so a request whose owning lane is absent from that catalog is refused or routed to an unrelated lane; a provider read failure surfaces as raw error text instead of a typed source row; the manager context exposes deliveries and coverage but no goal-level milestone field to synthesize from | +| Manager M2 — semantic continuation | Receiver resolution across registered running lanes; typed per-source coverage and freshness; a goal-level milestone the report can lead with instead of coverage disclaimers | Partially implemented. Typed source failures and one real source read are recorded below; the local peer directory is shipped. Cross-directory receiver resolution, complete semantic requests/return and a synthesizable Goal-level milestone remain open. Source reading does not complete M2 | | Manager M3 — automatic complete exchange | A persisted answer that exceeds or violates the channel's outbound text contract is split and re-sent under a stable answer identity; an ambiguous or failed send is reconciled instead of replaced by a local notice; the return path survives a transport restart; rich markdown renders as structured text | Partially mitigated. `loopx/extensions/lark/outbound.py` fails closed on an over-limit or malformed payload, and the channel reports that local failure without re-delivering the persisted answer; one answer carries no idempotency identity, so a retry can duplicate it; structured rendering is not guaranteed | | Host modes M0-M1 | The channel's executor selection and its bounded one-segment execution | Selection is covered by PR #4446 and the Turn-side selection by PR #4443; bounded one-segment execution is covered by the Mode B acceptance above. The channel itself now reaches the managed host through the segment transport, so the managed host's own one-segment execution is reachable from the channel; what remains open is that the segment is not a session, so cross-turn host continuity is still not offered | | Host modes M2-M3 | Attached-host parity, typed unavailability, and mode-aware projection with no mode inference and no second executor | Partly shipped: the channel's managed segment transport holds one executor per binding, refuses a second start with the typed `managed_host_chat_segment_in_flight`, and discards an interrupted segment's answer instead of letting it enter visible history. The channel readback also carries the mode-aware projection: it quotes the Session's own `session_mode` and `status`, reads a channel with no Session as `unbound`, and names a mode outside the closed set as `unrecognized` instead of deriving a mode from the executor it resolved. Still not implemented: attached-host parity, and an external audience still degrades to `restricted` | ### Remote-source coverage acceptance (2026-09-16) -The M2 row above recorded that "a provider read failure surfaces as raw error -text instead of a typed source row". Two shipped changes moved that, and the -behaviour is now accepted from a live channel read rather than inferred from the -code: +Typed M2 source failures have shipped. The following preserves one historical +live-channel read and its acceptance boundary; this roadmap audit did not rerun it: - a declared remote source that cannot be read reports a typed cause together with the repair that clears it (an authorization that lapsed, a remote client 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 4af3cfb10d..5f09627334 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 @@ -401,150 +401,35 @@ journal 与配额语义；B 作为上游接口出现时的低成本替代；只 ## 管家团队入端口径（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 模块都不新增：本仓库要求未获调用的抽象先留在设计态。 - -kind 为 `steward_team_plan_preview`（`steward_team_plan_preview_v0`）的提案，在任何落地 -之前先被校验；校验通过的预览必须点名、且不得编造： - -- 这次配人的**确切 Goal**，使"验证 lanes 的准入"与"建成 lanes 的结算"描述的是同一个 Goal - 而不是两个； -- 每条 lane 及其运行的 Agent，且只能来自 Core 已为该 Goal 注册的 Agent，最多 8 条 lane； -- 该 lane 的首个有界 Todo，含其声明优先级（P0..P3）、task class 与 action kind； -- 约束这些 lane 的 quota 包络； -- 结束每条 lane 的验收信号； -- 结束整个团队的终止条件。 - -配不齐的 lane 是类型化的 gap——`agent_not_registered`、`capability_not_granted`、 -`audience_not_authorized`，以及宿主自己的 `action_kind_not_supported`——并且该 gap 会把没 -配上人的那份工作留在 `declined_first_todo` 里，让业主看到"要了什么、缺了什么"，而不是一条 -被悄悄填上或被丢掉的 lane。计划可以为自己的 lane 声明 gap 理由，但不得冒用宿主对这条 lane -的判断：声明用一套词表，宿主回报用另一套，读者因此能区分"计划自述的 gap"和"Core 做出的 -可配人性判断"。 - -让**一条 lane** 配不齐的事实有两种：本 Goal 没注册它的 Agent，或者本机不 ship 它要的 -action kind。两者都是 lane 级别的事实，因此都变成同一种类型化 gap，且都不拒绝整份计划： -第一条 lane 配不齐的计划仍然是业主的请求，而它可配齐的那些 lane 正是业主要审的东西。当初 -正是"因为一条 lane 的 kind 而拒绝整份计划"，让线上管家把一句话团队请求答对了，却什么也给不 -出确认。 - -声明 gap 的 lane 不得再声明工作。计划是**预览**：校验通过的载荷带 `applies: false`；只有 -业主对这份确切预览的确认，才允许进入落地。落地只经各 effect 既有的 canonical owner—— -Agent 注册、Todo 创建、quota 或 goal policy——复用预览点名的身份，不得扩大已确认范围，也不 -得把团队计划当作工作已完成的结算。因此，这份被确认的载荷在校验器下是**不动点**：对已准入的 -预览再校验一次会得到同样的 lanes，而预览已报为 unstaffed 的 lane 会被保留成 gap，而不是 -按宿主**当前**事实重新推导，所以落地永远不会去给一条业主看到的是 gap 的 lane 配上人。 - -按交付顺序，已经落地并受强制的部分： - -1. **契约与校验器**（`#4519`，`3acd07697`）：kind、schema、lane 上限、优先级与 gap 词表、 - 公开安全文本，以及"拒绝编造 staffing"的行为。 -2. **聊天准入**（`#4522`，`3c8c832cb`）：`normalize_agent_response` 只在宿主提供 - `team_plan_context`（本 Goal 已注册 Agent + 本机支持的 advancement action kind）时才让 - 预览通过；否则与其它无法接受的提案一样被丢弃，而答案正文仍然到达业主。 -3. **落地**（`#4524`，`c159a15b3`）：受治理提案所有者在 `PRE_SETTLEMENT` 相位分派该 kind， - 落地时重新按本 Goal 已注册 Agent 与本机 shipment 的 advancement action kind 校验，经 - canonical Todo owner 为每条 **ready** lane 创建首个有界 Todo，gap lane 不创建任何东西， - 未知 Goal 在任何写入前就被拒绝，且**点名 Goal 与结算 Goal 不一致的计划会被拒绝**，因此 - 按某个 Goal 的 Agent 通过准入的计划无法被改投到另一个 Goal；回执记录 proposal digest， - 因此重放结算复用同一条 lane Todo 而不会新增第二行，并且回执点名这次确保的每一条 lane - Todo。 -4. **准入事实。** 管家通道的 Turn 会给"解析答案的那一段"挂上一个按 Goal 解析的查询，因此 - 预览只会用**它点名那个 Goal** 的 Agent 来校验：业主自己的通道可解析任意已注册 Goal， - 外部管家通道只解析它被绑定的 Goal，而 registry 不认识的 Goal——或超出该通道范围的 - Goal——会让预览被丢弃，而不是拿另一个 Goal 的 Agent 去校验它。 - 出厂的管家指引要求计划**点名**那个 Goal，因为不点名 Goal 的计划会被丢弃而不是被展示。 -5. **从 Chat 确认落地。** 类型化 Chat action 面拥有一个 `team.plan` 动作：它的预览用该 Goal - 已注册 Agent 与本机 advancement action kind 校验计划，它的落地则把同一份载荷交给受治理 - 提案所有者在 `PRE_SETTLEMENT` 相位重新校验，因此**一次业主确认**就会为每条 ready lane - 建出首个有界 Todo 并返回 lane 回读。预览与落地之间若发生注册变化，提案会变为 stale，而 - 不是把 staffing 已经漂移的计划落地。 -6. **从准入预览到可确认卡片。** 业主自己的本地管家通道会把它已准入的预览投影进类型化 - action store，因此业主本就在读的产品面上会列出**恰好一张** `team.plan` 卡片，且作用域是 - 计划点名的那个 Goal。投影按计划幂等：重放的 Turn 或重复的请求复用同一张卡片，而不会叠出 - 第二张；它不创建工作，也不授予任何"确认卡片"之外的东西。Turn 响应现在把预览与 Todo 提案 - 放在同一形状里，因此产品面读一种响应形状，而不是自己判断"哪种答案可能出现"。 -7. **回答本身说明去哪确认。** 每一份准入过团队预览的管家回答，都会带上**一句由通道写入**的 - 指引：点名那张卡片所在的 Goal，并说明确认之前不存在任何 lane。它是回执，不是改写：管家的 - 正文原样保留，Goal 通道永远不会被加上这句。远端管家受众同样会收到这句指引——这正是让 - "同一份管家回答"在"提问的受众自己无法确认"时仍然可行动的原因。 - -业主自己那条通道已经把卡片和解释卡片的那句话一起落地：准入预览到达类型化 action store， -卡片走的正是单 lane `team.plan` 卡片本就有的点击路径，而业主读到的回答会点名那张卡片所在的 -Goal。这句话属于**通道**而不是模型，远端管家受众同样收得到——因为提问的受众未必是能确认的 -受众，一句管家回答要对每个能读到它的受众都可行动。仍然缺的是远端受众**自己的确认面**： -Lark 管家通道在它自己的面上还没有卡片，因此不会替它写下卡片，它的业主按回答点名的 Goal 到 -LoopX 工作区确认。可追溯性已经被记录而不是被暗示：结算在写入**之前**读取该 Goal 的规范 -source basis，回执以有界字段 `intent_basis` 携带它，因此每条 lane Todo 都能被追溯回它本应 -推进的那个修订——尽管 Todo 行本身还不携带该字段。回读也不再是缺口：落地会把这次确保的每一条 -lane Todo 以有界字段 `lane_todo_ids` 发布出去；这两个字段都是那个封闭且持久化的回执字段集的 -加性例外，因此早前写下的回执仍然通过校验，而团队计划回执不带 monitor key——计划不是 monitor。 +在 `43d362532`，团队入端已交付有界预览、业主确认与首批 Todo 物化；尚未验收正在运行、预算受约束或完整意图对齐的团队。[整体路线总纲](loopx-overall-roadmap-v0.zh-CN.md) 拥有跨 RFC 优先级及 F1–F7/R1–R7；本文保留 runtime 选型及其资格证据，不另建团队架构。 + +已交付边界为 `steward_team_plan_preview_v0`、kind `steward_team_plan_preview`，经 `loopx/control_plane/work_items/governed_transition_proposal.py` 与 Chat `team.plan` 分派。计划点名确切 Goal、1–8 条 lane、注册 Agent、首个 Todo 的 text/priority/class/action、acceptance、quota envelope 与 stop condition。校验结果 `applies: false`；预览不等于执行。 + +| 边界 | 已交付行为 | 剩余限制 | +| --- | --- | --- | +| 校验/准入（#4519/#4522/#4532/#4533） | 确切 Goal、注册 Agent、支持的 advancement kind、有界公开安全字段；按通道范围查询 Goal；缺少事实时丢弃提案并保留答案正文 | `ready` 只校验注册/action 支持，不证明执行器健康、工具资格或预算准入 | +| Staffing gap | 未注册 Agent 产生 `agent_not_registered` 并保留 `declined_first_todo`；显式 `capability_not_granted` / `audience_not_authorized` gap 不允许工作 | 存在这些 reason code 不证明全部 capability/audience 条件已经自动检测 | +| 物化（#4524/#4528/#4535/#4538） | 重新校验点名 Goal，逐 ready lane 调 canonical Todo owner；回执保存 proposal digest 与有界 `lane_todo_ids`，兼容旧回执且没有 monitor key | 确认的 priority 丢失；acceptance/quota/stop 未成为此路径的执行约束；没有整队原子提交或自动 partial recovery 证明 | +| 确认（#4547/#4548/#4552） | 现有前端展示 lanes/gaps 并提交 `team.plan`，bundle 与 browser fixture 已交付 | 此 fixture 未验收 Lark 或真实 worker 执行；all-gap apply 仍以零 Todo 返回 `team_plan_lanes_already_present` | +| 新鲜度 | registry bytes 变化会使 Chat preview stale；可选 `intent_basis` 在物化前读取 alignment source facts | commit 未绑定精确 Goal intent/授权/工作前置条件；`intent_basis` 不是完整意图修订或 CAS fence | + +现有测试覆盖未变化计划的重复提交，不能推广到并发计划、多 lane 中断或中途 Todo 被编辑的情况。R1 通过实际 action/recovery 路径补这些资格。 + +最新集成检查点：#4569（`f1166e81e`）将不支持的 action kind 保留为 lane 级 gap，区分计划声明的 gap 与 host 判断，复验不把已确认的 gap 静默转为工作，并将 admitted plan 投影到本地 owner channel 卡片。一条 lane 无法承接不再拒绝整份计划；Lark manager audience 仍无对应卡片。这些修复不代表团队已执行，也未闭合基线 F1–F4 的承诺与恢复问题。 + +后续 #4572（`0aa6179de`）在 manager 回答中追加 channel-authored 的确认位置提示，指出目标 Goal 工作区；本地与远端 manager 均收到提示，Goal channel 不追加。远端提示不等于在 Lark 生成卡片，也不证明卡片写入或团队执行成功；原模型正文保留。 ### 与 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 都这样规定，这条入端口径只是又一个必须遵守它的调用方。 -- **管家"谁还在干活"的能力就是 peer-directory 契约。** 管家与它配出的各 lane 是 - [`peer_agent_directory_v0`](../../reference/protocols/peer-agent-directory-and-observation-v0.md) - 的同一批调用方里两类受众：管家是 manager-channel 受众，范围由 channel 的 Goal 绑定划定； - 每条 lane 是 `peer_v1` 受众，范围由该 Goal 已注册的 Agent 划定。一条契约同时回答两者， - 且可以在三个层次抵达——typed state 与受治理命令、运行中 Agent 加载的 in-space skill、 - 以及只提供实时 presence 的 provider 面——所以这条入端口径不会在 peer directory 之外再长 - 出一个管家专用 directory。两类受众遵守同样的边界：观察与投递不授予任何东西；一次有界 - 等待会 pin 它已解析的身份、并要求观察到的状态确实向前变过；"现在谁需要决策"的 rollup - 只排序注意力，不分配任何工作。 - 该契约的首个本地 producer 已出货：`loopx agent-directory --goal-id - [--agent-id ]`，它复用既有的 agent management projection 而不第二次读取 - registry；在没有 presence provider 注册时不报告 presence；调用方若不是该 Goal 的已注册 - Agent，得到的是 typed scope gap 而不是行。 -- **每条 lane 的权威回读是对齐投影。** 计划落地后，一条 lane 的状态就是该 Agent 的 - `shared_goal_alignment_v0` 投影（`loopx shared-goal-alignment --goal-id --agent-id - `）：规范修订、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、受众或工作状态权限。 - -## 按里程碑看管家通道的就绪度（2026-09-15） +[对齐 RFC](shared-goal-alignment-and-governed-amendment-v0.zh-CN.md) 拥有共享意图及受治理修订；[共享权威 RFC](shared-goal-authority-state-provider-v0.zh-CN.md) 拥有持久化/晋升。团队计划只提议已接受 intent 内的工作，不能靠 envelope 散文修改权限、共享验收或终止条件。Stage 3 amendment commit 仍未交付。回执可选 `intent_basis` 是既有 `source_basis_digest`，不是尚未实现的完整 intent envelope 版本，不能通过改名赋予历史回执更强语义。 + +`peer_v1` 允许管家组织、委托和综合，但不授予单方写入、claim、优先权或抢占权。lanes 指向同一 canonical 图与 per-Agent frontier；创建带 `claimed_by` 的 Todo 不等于取得 lease、启动 worker 或预留分布式 quota。 + +[Peer directory](../../reference/protocols/peer-agent-directory-and-observation-v0.md) 供 manager 与 peer 共用。`loopx agent-directory --goal-id [--agent-id ]` 复用 management projection，本地最多 24 行并报告省略数；没有分页、presence provider 或 lease epoch。传入未注册 caller 得到 scope gap。本地 CLI membership 检查不认证远端 caller；未来远端入口必须从可验证 binding 派生身份。 + +每 lane 通过 `loopx shared-goal-alignment --goal-id --agent-id ` 回读，仍限 Stage 1/2 source-facts 语义，计划 receipt 不投影完整状态。[三层合同](../../reference/protocols/multi-agent-three-layer-minimality-v0.md) 与[可见 launcher](../../reference/protocols/multi-agent-visible-launcher-v0.md) 保留独立归属：用户意图、preset 流程、kernel 声明按 Goal/Agent/Todo 身份连接，不再建 runner、pane owner、vision budget 或 evidence loop。选择执行器和保存凭据都不授予这些效果。 + +## 按里程碑看管家通道的就绪度（2026-09-16） 管家通道同时消费本文的宿主选型与 [管家语义交接](./capable-manager-semantic-handoff-v0.zh-CN.md) 中的管家里程碑。 @@ -552,18 +437,17 @@ lane Todo 以有界字段 `lane_todo_ids` 发布出去；这两个字段都是 契约，不写会话内容：不记录真实会话原文、受众身份、带日期的具体事故，或 operator 本机路径。 -| 里程碑 | 管家通道在范围内的契约 | 2026-09-15 的证据状态 | +| 里程碑 | 管家通道在范围内的契约 | 2026-09-16 的证据状态 | | --- | --- | --- | | 管家 M1 — 可用的宿主 agent | 通道解析并回报其生效执行器、模型、推理档位与来源，执行器选型不跟随凭据；无法启动的宿主以 typed reason 失败，而不是静默回落到个人登录 | 已交付：带来源与默认规则原因的已选端点、执行器的 `execution_profile`、`executor_kind`、`channel_binding` 读取（PR #4446 与 PR #4443 的 Turn 侧读取；无条件默认值与单段传输随本次变更落地）。上游**会话身份**尚未投影到通道，因此通道回答还无法证明是哪一次会话给出的 | -| 管家 M2 — 语义续接 | 跨所有已注册运行中 lane 的接收者解析；按来源的 typed 覆盖与新鲜度；报告可以先用目标级里程碑开头，而不是先给覆盖免责声明 | 未实现。委托只按传入的委托目录解析，因此拥有该事项的 lane 不在目录中时会被拒绝或投给无关 lane；provider 读取失败以原始错误文本出现在回答里，而不是 typed 来源行；管家上下文只提供交付与覆盖，没有可综合的目标级里程碑字段 | +| 管家 M2 — 语义续接 | 跨所有已注册运行中 lane 的接收者解析；按来源的 typed 覆盖与新鲜度；报告可以先用目标级里程碑开头，而不是先给覆盖免责声明 | 部分已实现。typed 来源失败与一次真实来源读取已记录在下节；本地 peer directory 已交付。跨目录的 receiver 解析、完整语义请求/回传及可综合的目标级里程碑仍未闭合，不把 source read 等同于 M2 完成 | | 管家 M3 — 自动完成一次交流 | 超出或违反通道出站文本契约的已保存回答，按稳定答案身份分片重发；含糊或失败的发送要协调而不是用本地提示替代；回传路径要能跨传输重启存活；富文本要渲染成结构化文本 | 部分缓解。`loopx/extensions/lark/outbound.py` 在超限或载荷不合法时 fail closed，通道只回报这个本地失败、不重新投递已保存的回答；一条回答没有幂等身份，重试可能重复发送；结构化渲染没有保证 | | 宿主模式 M0-M1 | 通道的执行器选型与其有界单段执行 | 选型由 PR #4446 覆盖，Turn 侧选型由 PR #4443 覆盖；有界单段执行由上面的 Mode B 验收覆盖。通道本身现在经单段传输抵达托管宿主，因此托管宿主自己的单段执行已可从通道抵达；仍未提供的是跨 turn 宿主连续性——片段不是会话 | | 宿主模式 M2-M3 | attached-host 对齐、typed 不可用，以及不做模式推断、不引入第二执行器的模式感知投影 | 部分已实现：通道的托管段传输为每个绑定只保留一个执行器，第二次启动以 typed `managed_host_chat_segment_in_flight` 拒绝，被中断段的回答会被丢弃而不会进入可见历史。通道读回也带上了模式感知投影：引用 Session 自己的 `session_mode` 与 `status`，没有 Session 的通道读作 `unbound`，闭集之外的模式命名为 `unrecognized`，而不是从已解析的执行器反推模式。仍未实现：attached-host 对齐；外部受众仍降级为 `restricted` | ### 远程来源覆盖的现场验收（2026-09-16） -上面 M2 行记录过"provider 读取失败以原始错误文本出现在回答里，而不是 typed 来源行"。 -两项已交付改动改变了这一点，而且现在是从**一次真实通道读取**中验收，而不是从代码推断： +M2 的 typed 来源失败已交付；以下保留一次历史真实通道读取的验收边界，本次路线审计未复跑： - 声明了却读不到的远端来源，会回报 typed 原因与清除该原因的修复动作（授权过期、 远端客户端缺失、远端协议不可用、主机不可达），而不是一句没有类型的不可用； diff --git a/docs/architecture/rfcs/loopx-overall-roadmap-v0.md b/docs/architecture/rfcs/loopx-overall-roadmap-v0.md new file mode 100644 index 0000000000..9f9fd05460 --- /dev/null +++ b/docs/architecture/rfcs/loopx-overall-roadmap-v0.md @@ -0,0 +1,324 @@ +# LoopX Overall Roadmap v0: Product, Collaboration, Technology and Delivery + +- Status: Draft overall roadmap; no automatic domain-RFC acceptance, provider promotion or permission-default change. +- Scope baseline: 2026-09-16, `0aa6179de`; steward reproduction baseline is preserved separately in Section 8. +- Ownership: overall product outcomes, cross-domain dependencies, priorities and portfolio acceptance here; concrete rules in domain RFCs/stable protocols; execution state in canonical Todos. +- Language: [中文版](loopx-overall-roadmap-v0.zh-CN.md) is the semantic mirror. + +## 1. Overall Objective and Product Routes + +LoopX aims to let people express, revise and accept complex goals through a local frontend or Lark, while a persistent steward coordinates long-running LoopX Agents with independent work commitments across local managed and cloud runtimes. Single-Agent long-horizon reliability is the foundation. Multi-Agent collaboration, handoff, recovery and convergence on shared goals are core capabilities. Hundred-Agent scale is a separate system qualification. + +Product success means **accepted outcomes within constraints, human attention cost and recovery capability**. Online counts, generated text, tool calls and PR counts are process signals. Models, runtimes, storage providers, IM and memory services can change; Goal/Todo/claim/lease/quota/effect and acceptance rules retain explicit, traceable single owners. + +| User and work | Shortest value path | Required accepted outcome | +| --- | --- | --- | +| Individual developer/researcher | Connect a project→existing or managed Agent→continued work→interruption recovery | Reproducible installation/first useful action; visible work, artifacts, cost and next step without learning every RFC | +| Project owner/steward operator | Goal and constraints→small team→dependent artifacts→direction correction→aggregate acceptance | Understand responsibility, blockers and decisions; direct worker conversations remain available | +| Multi-project/multi-host operator | Scoped parent/child goals→local/cloud division→shared authority/budget→overall return | Peer work, isolation, fairness and recovery hold; coordination roles do not grant global administrator authority | +| Adopter with existing agent systems | L1 passive diagnostics→L2 advice→authorized L3 seams→optional L4 control plane | Prove non-interference and diagnostic value before control effects; support adoption without replacing the native runtime | +| Capability/host/provider developer | Minimal adapter→compatibility/permission checks→qualification→install/uninstall | Extensions do not copy kernel truth, off-state preserves core behavior, versions and supported capabilities are discoverable | + +Product scope includes reusable engineering delivery, research, material/knowledge work and office/content workflows. First prove transfer through one engineering and one knowledge/research journey. Domain behavior belongs to capabilities/packages; scenario scoring, stages and private semantics cannot become generic kernel rules. Protected external effects, including finance, qualify through separate domain contracts and simulated adapters; a general steward gains no such execution permission. + +Two adoption routes share engineering assets but qualify independently: **native LoopX long-horizon coordination** prioritizes G1/G2; **observer-first reliability diagnostics** can demonstrate value without waiting for hundred-Agent scale or a shared service. Paid deployments, enterprise offerings and hosted services remain product hypotheses, not demonstrated market fit or operating commitments. + +### Relationship to Existing Documents + +- This is the product, engineering, research and adoption roadmap. Section 2 defines S1–S13 streams; Section 3 defines G0–G5 portfolio milestones; Section 4 maps every RFC; Sections 5–6 detail the multi-Agent core path; Section 8 preserves the focused audit. +- [Technical directions](../../project/technical-directions.md) owns public contribution routes and trackers; the [RFC index](README.md) owns domain navigation. They project the cross-domain ordering here while domain RFCs retain their T/M/D/A identifiers and authority gates. +- [Product vision](../../product/vision.md), the [capability catalog](../../../loopx/capabilities/README.md), [stable protocols](../../reference/protocols/README.md) and released versions retain their scopes. This roadmap creates no second task ledger, state schema or release-support declaration. + +## 2. Portfolio Streams: Outcomes, Gaps and Executable Slices + +P0 blocks correctness or continuity in the current user journey. P1 enables repeatable delivery and collaboration. P2 expands scale, scenarios or adoption after evidence. P3 retains design pending a demand trigger. Priority guides work selection without overriding safety gates or live quota. Owners are module/capability boundaries, not predetermined models or individuals. + +| Stream | Outcome and existing foundation | Next complete slice, dependencies and exit evidence | +| --- | --- | --- | +| **S1 Product and persistent steward · P0** | Request, investigation, decomposition, acceptance and return; manager runtime, team intake and settings exist, continuous end-to-end work is unqualified | R1/R2 first: preserve commitments, run bound workers and continue after owner corrections; qualify CLI/packaged frontend/Lark separately. Close a minimum journey through two cycles of dependent artifacts and independent acceptance | +| **S2 Typed kernel and durable authority · P0/P1** | Effect/Todo/quota/recovery owners, TS migration and store candidates exist; writer cutover/provider promotion remain incomplete | Migrate one real transaction/recovery lifecycle at a time, with semantic counterexamples before cutover/deletion. R1 correctness precedes migration volume. Require real backend, concurrency/fence, ambiguous commit, retention/export recovery, bridge costs and D1–D3 evidence | +| **S3 Goal planning and multi-Agent collaboration · P0/P1** | Vision/replan, peer frontiers, claim/lease, directory, manager_context and explicit continuation exist; general handoff/shared amendment remain incomplete | R2 proves peer dependency; R3 closes parallel joins, pipelines, help/review, continuation and automatic return; R4 delivers one intent-preserving amendment class. Cover cycles, invalidated inputs, rejection/deferral, lease transfer, competing bases and aggregate acceptance | +| **S4 Runtime/host/daemon · P0/P1** | Attached/managed, Turn, broker, runtime connectors and Desktop repairs exist; registration does not establish executable capacity | Qualify multi-Turn supervision for one real supported combination; restart/cancel/drain/stop retain work and fence old executors. Then expand host parity, unique service-profile ownership, clean installation and upgrades; show unsupported adapter capabilities | +| **S5 Frontend, Lark and human interaction · P0/P1** | Local chat, settings, proposals and partial Goal Channel verticals exist; shared audience/session/work readback needs qualification | One journey spans settings, work graph, handoff, blockers, cost, corrections, artifacts and return. Shared typed projections; reconnect/repeated-click/stale/original-route cases. Then intelligent review, keyboard accessibility, bilingual terminology, actionable errors and offline degradation; interrupt only for actual decisions | +| **S6 Materials, evidence, memory and learning · P1** | Authority registry, material lifecycle/frontier, decision context, reward memory and turn recall exist; direction baseline and parts of attribution remain proposed | Connect material revision→same-Agent read→decision reference→artifact/outcome. Expose expiry/revocation/source loss and forgetting policy. Handoff preserves decision-relevant summaries and authorized artifacts; qualify OpenViking/Obelisk as optional providers. Prove causal utility with controls, not relevance alone | +| **S7 Budget, scheduling and fleet scale · P0 observation/P1–P2 expansion** | Quota/scheduler and partial usage aggregates exist; full provider cost, distributed reservations and hundred-Agent concurrency need evidence | Separate configured budget, admission, consumption and estimates; unknown is not zero and replay cannot double-charge. R7 pagination/bounded summaries, provider/host limits, fairness, backpressure, event wake and isolation; report registration/activity/throughput and cost per accepted outcome separately | +| **S8 Capabilities, extensions and domain integration · P1/P2** | Capability catalog, extension lifecycle, hooks, engineering/research/content/office capabilities and computer-use contracts exist | First exercise the shared control plane with existing issue-fix/PR-review and material/research callers. Every provider has readiness/version/permissions/default-off/uninstall/rollback/isolation and real-entry evidence. New domain effects start with one simulated operation, not a marketplace or workflow DSL | +| **S9 Identity, authority, privacy and trust · continuous P0/P1–P2 remote** | Public/private scope, capability gates, fencing and confirmation contracts belong to existing owners | R1/R3 cover sender/audience/artifact scope and stale authority; R6 authenticates tenant/Goal/actor/host, rotation/revocation and least privilege. Qualify credential custody, untrusted tool/document inputs, dependency supply chain, audit retention/deletion and vulnerability response through real paths; roles/messages/memory mint no write authority | +| **S10 Reliability, diagnostics and operations · P0/P1** | Recovery/canary, read-only diagnostics prototype and DSH event adapter exist; C0/C1, overhead and full operations qualification are open | Failure classification→observable state→recovery drill→regression prevention; process/storage/network/delivery failures and data growth. Freeze SLO/RPO/RTO/capacity/retention boundaries and measure before qualification. Runbooks include upgrade, restore, stop and human takeover; test counts do not prove recovery | +| **S11 Evaluation and scientific research · continuous P1/P2 research** | Benchmark toolkit, Explore, long-horizon portfolio and ten frontier-science tracks have designs/partial implementations | Pin native/passive/governed arms, model/harness/budget/task split and evaluator; report native scores, cost, failures, attention and uncertainty. Prioritize sequential evidence, continuation and stride; memory, formal kernel, curriculum/evolution, active experiments and multiscale state follow T01–T10 gates without automatic production treatment | +| **S12 Release, developer experience and community governance · P0 hygiene/P1** | Install/source validation, registration, DCO/PR, test layers, contributor routes and bilingual docs exist | Qualify first work and upgrade/rollback from clean machines/release artifacts; host/OS support follows the release contract. Reduce localization/test/review effort for useful changes; preserve exact-head evidence, fixtures, compatibility, maintainer routing and contributor credit; retire duplicate protocols/stale evidence | +| **S13 Adoption, ecosystem and sustainability · P1 discovery/P2 pilots** | Public adoption loop, showcases, licensing/governance and observer-first product contract exist; paid PMF is unproven | Gather independent first/repeat usage and exit reasons; reproducible cases and pilots with fixed budgets/acceptance/rollback. Retain reusable adapters/delivery guides. Account for model/compute/storage/support and maintenance costs; only repeated demand justifies commercial hosting/support/distribution decisions, with no invented SLA or open-source-term change | + +### Important Areas Outside RFCs and Their Owning Sources + +These directly determine whether a long-running team is usable. A directory or README provides an implementation/contract entry, not installed readiness; read availability from `loopx capability list/show` and the selected release. + +| Area and existing entry | Streams | Next requirement in this roadmap | +| --- | --- | --- | +| [Goal Vision/replan](../../reference/protocols/goal-vision-replan-contract-v0.md), [work graph](../../reference/protocols/task-graph-projection-v0.md), [peer runtime](../../reference/protocols/peer-agent-runtime-v1.md), [supervisor](../../reference/protocols/peer-supervisor-v0.md) | S2/S3 | Exercise dependencies, replanning, acceptance and handoff in one real case; aggregate closeout consumes acceptance facts | +| [Quota](../../quota-allocation.md), [cadence](../../operations/long-task-cadence-policy.md), [attention](../../operations/attention-queue.md) | S5/S7 | Budget exhaustion, deferral and blocking expose next triggers/readback; scale without frequent full-state polling | +| [Material lifecycle](../../reference/protocols/material-lifecycle-architecture-v0.md), [material frontier](../../reference/protocols/agent-material-frontier-v0.md), [authority registration](../../operations/authority-source-registration.md) | S6 | Agents discover roadmap/RFC revisions and record reads; reading grants neither agreement nor authority; archival preserves raw-source ownership | +| [Decision Context](../../../loopx/capabilities/decision_context/README.md), [Reward Memory](../../../loopx/capabilities/reward_memory/README.md), [Semantic Preference](../../../loopx/capabilities/semantic_preference/README.md), [Turn Recall](../../../loopx/capabilities/agent_turn_recall/README.md) | S6/S11 | Distinguish facts/preferences/advice/attribution/authority; scoped recall, expiry and outcome-feedback counterexamples first | +| [Issue Fix](../../../loopx/capabilities/issue_fix/README.md), [PR Review](../../../loopx/capabilities/pr_review_queue/README.md), [Change Quality](../../../loopx/capabilities/change_quality/README.md), [Integration Branch](../../../loopx/capabilities/integration_branch/README.md), [Change Window](../../../loopx/capabilities/repository_change_window/README.md) | S8/S12 | Engineering caller: issue→implementation→independent review→validation→authorized delivery; source-head drift invalidates old evidence | +| [Explore](../../../loopx/capabilities/explore/README.md), [Benchmark Toolkit](../../../loopx/capabilities/benchmark_toolkit/README.md), [auto-research](../../product/use-cases/auto-research/README.md) | S8/S11 | Second collaboration journey: question/hypothesis→parallel experiments→independent interpretation→successor; no uplift/failure remain valid outcomes | +| [Content Operations](../../../loopx/capabilities/content_ops/README.md), [Periodic Report](../../../loopx/capabilities/periodic_report/README.md), [office operations](../../product/use-cases/office-operations/README.md), [domain packs](../../product/domain-capability-packs.md) | S5/S8 | Public-safe projections feed sinks; separate drafts/review/publish authority/outcomes; generic sinks do not depend on project-private documents | +| [Extensions](../../reference/extensions.md), [runtime catalog](../../integrations/runtime-connector-catalog.md), [host surface](../../reference/protocols/host-integration-surface-v0.md), [skill delivery](../../../loopx/capabilities/project_skill_delivery/README.md) | S4/S8/S12 | Minimal adapter examples match registration readback; test compatibility/upgrade/disable/uninstall; host skills are not another kernel | +| [Computer Use](../../reference/protocols/computer-use-runtime-v0.md), [operator credentials](../../reference/operator-model-credential.md), [private boundary](../../public-private-boundary.md) | S8/S9 | Qualify actual host restrictions and sensitive-operation grants; external text cannot escalate authority; isolate and bound screenshot/log/credential retention | +| [Testing/quality](../../development/testing-and-quality.md), [CI impact](../../development/ci-impact-selection.md), [source correctness](../../reference/protocols/local-state-write-correctness-v0.md), [release readiness](../../product/release-readiness.md) | S2/S10/S12 | Independent expected semantics, real backend/install entry, negative/mutation cases; control validation cost without treating skipped checks as passed | +| [Install](../../guides/installing-loopx.md), [newcomer path](../../guides/newcomer-command-path.md), [design](../../development/design.md), [user guide](../../guides/personal-workspace-user-guide.md) | S1/S5/S12 | First-value path, error recovery, supported platforms, accessibility and bilingual consistency; existing design/first-screen review for UI changes | +| [Public adoption](../../product/public-adoption-loop.md), [scenario gaps](../../product/scenario-capability-gap-map.md), [SaaS assessment](../../product/roadmaps/saas-opportunity-assessment.md), [licensing](../../project/licensing.md), [governance](../../../.github/GOVERNANCE.md) | S12/S13 | Traceable public outcomes/failure feedback; independently qualify commercial hypotheses; existing license/credit/community-authority policies remain authoritative | + +## 3. Portfolio Milestones, Resource Ordering and Completion + +S streams describe ongoing ownership, G milestones qualify a product combination, and R cards specify the current core implementation slices. These are cross-references, not a runtime state machine. Progress is evidence-gated rather than date-promised. Changes in capacity or business priority update canonical Todos rather than assuming every stream starts simultaneously. + +| Milestone | Product exit | Required streams / core path | +| --- | --- | --- | +| **G0 Trustworthy baseline** | Discoverable behavior/defaults/qualification; reproduced lost commitments, stale basis, empty success and partial commits repaired with regressions; release-artifact single-Agent loop and unknown costs visible | S1/S2/S7/S9/S10/S12; R1. Merging this roadmap does not complete it | +| **G1 Small-team delivery** | Steward and 2–3 long-running LoopX workers complete two real collaboration cycles with dependent artifacts, peer handoff, recovery, owner correction and independent acceptance; single-Agent path preserved | G0; S3/S4/S5; R2 plus minimum existing R3 path, without waiting for general migration/new store | +| **G2 Recoverable collaboration workspace** | General peer requests/review/return, session continuation and material/direction lineage; frontend/Lark consume the same facts; local durable profile passes applicable qualification | G1; S2–S7/S9/S10; R3/R4/R5. D3 and other explicit promotions remain separate decisions | +| **G3 Shared local/cloud work** | Two real hosts including cloud; authenticated scope, revocation, network failure, shared budget and returning-worker fences; recoverable cross-host dependent artifacts and returns | Relevant G2 contracts; S3/S4/S7/S9/S10; R6 | +| **G4 Hundred-Agent qualification** | Active cohorts 10→30→100+ meet frozen throughput/latency/cost/recovery SLOs; macro-goals converge through direction changes without steward message bottlenecks | G3; R7; S5/S7/S10/S11. A hundred registrations are insufficient | +| **G5 Repeatable adoption and ecosystem** | Independent install/reproduction/upgrade/export/rollback; verified engineering and knowledge/research journeys; recorded support costs, maintenance ownership and pilot outcomes | S8/S10–S13 start alongside G0; bounded adoption need not wait for G4. Commercial services require additional operational/licensing boundaries | + +First resource ordering: complete R1 commitments/recovery, then qualify G1. One adjacent TS transaction/delivery repair and one read-only diagnostic/material qualification slice may prepare alongside it without hiding P0. Each implementation slice has one primary owner/outcome and explicit dependencies. Work in progress follows actual review/validation capacity rather than filling a board to match Agent count. + +Pause/downscope when a design duplicates authority or widens defaults, real-backend qualification is missing, rollback is not independently possible, cost/attention grows uncontrollably with scale, benchmark integrity fails, or users cannot explain work and blockers. Preserve facts/receipts, stop affected new admission and repair rules or reduce the cohort. Do not weaken acceptance, remove failed samples, refresh test expectations or rename a stage into completion. + +### Cross-Domain Measurement and Validation + +| Dimension | Shared definition | Minimum evidence | +| --- | --- | --- | +| Outcomes/convergence | Accepted-outcome rate, Goal closeout quality, invalidated-artifact rework; separate no uplift, failure and unknown | Independent verifier/acceptance owner; complete failure denominators, Goal/input versions | +| Collaboration/continuation | Adoption latency, dependency waits, first useful action after handoff, original-route return fulfillment, duplicate protected effects | Request/work/artifact/receipt lineage; refusal, source loss, interrupted replay and old-lease counterexamples | +| Human attention/UX | Time to first useful outcome, interventions/decisions per accepted outcome, time to locate blockers | Real local/Lark journeys, explicit authority boundaries and untested entrypoints | +| Resources/scale | Host/provider concurrency, queue p50/p95, successful throughput, tokens/cost/storage, cost per outcome | Separate observed/estimated/unknown and registered/active; frozen load/budget/price source/sample window | +| Reliability/security | Stale/unauthorized rejection, duplicate effects, RPO/RTO, recovery latency, isolation/deletion results | Fault injection plus isolated real backend/hosts; restore and credential-revocation drills | +| Engineering/adoption | Compatibility/upgrades, module/bridge simplification, reproduction time, independent first/repeat use, support cost | Released artifact rather than source alone; redacted traceable cases/feedback; installs do not establish PMF | + +Do not invent unmeasured performance targets. Before each experiment/pilot, its owner freezes thresholds, baseline, budget, stop conditions and evidence scope. A post-result threshold change belongs to a new experiment. G4 correctness requires no duplicate protected effects or stale/unauthorized commits; performance and cost thresholds require separate measured qualification. + + +## 4. Every RFC: Ownership and Next Step + +This maps **all 30 primary RFCs** at the scope baseline, counting language mirrors once; this roadmap is the new 31st entry. Accepted, partial, research and Held directions remain visible without making every row active work. Status is based on RFC/reference inspection and selected source checks; full runtime qualification of every subsystem was not performed. Section 8 records the focused audit. + +| RFC | Stream | Current boundary | Next slice / acceptance | +| --- | --- | --- | --- | +| [Agent Loop Effect Interpreter](agent-loop-effect-interpreter-v0.md) | S2 | Accepted; core implemented, adoption continues | P0: reuse effect/recovery, cover R1 partial commits; retain domain-local replan ACK | +| [TypeScript Control-Plane Migration Direction v0](typescript-control-plane-migration-v0.md) | S2 | Accepted; whole-transaction migration active | P0/P1: R1–R4 hot transactions first; T0–T4 caller/deletion/cost evidence; no full rewrite prerequisite | +| [Semantic Vocabulary Convergence and Commit-Time Drift Checks (v0)](semantic-vocabulary-convergence-v0.md) | S2 | Draft; registry/inventory/drift and subsequent typed slices exist | P1: converge by semantic role and active producer/consumer; no name-based enum merging; review schema changes separately | +| [LoopX Shared Control-Plane Authority and Pluggable State Providers (v0)](shared-goal-authority-state-provider-v0.md) | S2/S3/S7 | Draft; stores, local transactions and service-admission foundations exist | P1→P2: R5 local D1–D3, R6 authenticated hosts; real backend/soak/recovery before promotion | +| [Shared Goal Alignment and Governed Amendment Protocol (v0)](shared-goal-alignment-and-governed-amendment-v0.md) | S3 | Draft; Stage 1/2, full intent/commit incomplete | P1: R4 one work-graph amendment class; CAS/lease impact, conflicts and lost-response receipts | +| [Goal Direction Baseline (v0)](goal-direction-baseline-v0.md) | S3/S6 | Draft; read-model proposal | P1: synthetic fixtures for same-Agent/current-revision material use; no Vision writer or automatic Todo | +| [Goal Artifact Lifecycle Projection (milestone / guard / next-transition) v0](goal-artifact-lifecycle-projection-v0.md) | S3/S5 | Draft; read-model proposal | P1: derive milestone/guard/next transition from typed facts; no process engine | +| [Capable Agent Manager and Semantic Work Handoff (v0)](capable-manager-semantic-handoff-v0.md) | S1/S3 | Draft; partial profile/intake, M1–M4 not fully qualified | P0→P1: R1/R2 real teams, R3 semantic peer work and durable return; continuation matrix and A1–A20 | +| [Manager runtime profile v0](manager-runtime-profile-v0.md) | S1/S4 | Draft; private Codex profile exists, general qualification incomplete | P0: real tools/session/recovery and scoped authority; runtime labels do not qualify behavior | +| [DSH / Pi: L1 Observation and Managed Runtime Selection](harness-selection-dsh-pi-v0.md) | S4 | Selection record; bounded runtime/team-card evidence | P0: R2 on qualified bindings; qualify harness/model/profile/host separately, not from one smoke | +| [Explicit Todo continuation: Stage A](cross-session-memory-substrate-v0.md) | S3/S6 | Stage A shipped; filename does not imply general memory substrate | P1: R3 reuses prepare/inspect/adopt; retain same-host/unleased limits until replacement qualifies | +| [Agent Session Execution Modes (v0)](agent-session-execution-modes-v0.md) | S4 | Draft; partial attached binding/broker/fence | P0→P2: one executor per binding, managed supervision, then cross-host admission; no implicit mode changes | +| [Single-Owner Local Daemon (v0)](single-owner-local-daemon-v0.md) | S4/S10 | Draft; Desktop ownership repair does not establish loopxd | P1: service-profile owner/readiness/drain/restart for one composition; no second scheduler | +| [LoopX Desktop Execution Frontends v0](desktop-execution-frontends-v0.md) | S4/S5 | Draft; attached/managed/UI foundations, full journey unqualified | P0→P1: packaged settings→binding→team→correction→recovery→return; retain direct worker conversations | +| [Goal Channel Collaboration v0](goal-channel-collaboration-v0.md) | S5 | Draft; partial Lark vertical shipped | P1: qualify team card/return/idempotency/audience; distinguish Goal channels from Agent session bindings | +| [Provider-Neutral Turn-Start Inbox Hook v0](provider-neutral-turn-start-inbox-hook-v0.md) | S3/S8 | Implemented with explicit configuration | P0 hardening: bounded read→semantic triage→ACK/replay; preserve default-off and private provider cursors | +| [Provider-Neutral Post-Writeback Capability Hooks v0](provider-neutral-post-writeback-capability-hooks-v0.md) | S3/S8 | Draft; first periodic-report vertical implemented | P1: R3 return/successors reuse durable intent; isolate hook failure, no primary-transaction coupling/direct effects | +| [Agent IM, LoopX, And OpenViking Collaboration v0](agent-im-openviking-collaboration-v0.md) | S3/S6/S8 | Draft; three-owner integration unqualified | P1/P2: separate IM delivery, LoopX work authority and OV context; reconnect/revoke/source-loss cases | +| [Per-Goal Usage, Token, and Cost Surfacing v0](goal-usage-token-cost-v0.md) | S7/S5 | Draft; Codex aggregate/cost display slice exists | P0 observation→P1 provider coverage: unknown is not zero, deduplicate accounting, price source/freshness; usage grants no budget | +| [Intelligent Review and Dynamic Presentation Surfaces v0](intelligent-review-presentation-surfaces-v0.md) | S5 | Draft; typed proposal inputs exist, general compiler unshipped | P1: one real decision-frame vertical, stale state and optimistic rollback; avoid redundant confirmation | +| [Human Attention Wishlist v0](human-attention-wishlist-v0.md) | S5/S11 | Draft; Held | P3: reopen only on repeated second real need; sidecar cannot alter gates/quota/scheduling | +| [Human-confirmed domain operations (v0)](human-confirmed-domain-operations-v0.md) | S8/S9 | Draft; proposal only | P2: simulated immutable confirmation→effect→reconciliation→return; finance provider separate, no broader coordination grant | +| [Research Exploration Control Plane v0](research-exploration-control-plane-v0.md) | S11/S3 | Draft; partial M2 composition/successor | P1: independently verify observation/write-time gate/closure basis; defer inferred triggers and model selection | +| [Hierarchical Agent Stride Control v0](hierarchical-agent-stride-control-v0.md) | S11/S7 | Draft; M1 read-only observation | P2: matched shadow stride experiment with costs/events; no direct production cadence change | +| [Post-Outcome Memory Utility Attribution v0](post-outcome-memory-utility-attribution-v0.md) | S6/S11 | Draft; Stage 1 verified-outcome binding | P1 read-only reducer→P2 pilot: distinguish recalled/applied/utility, no automatic ranking change | +| [Obelisk Session Evidence Provider v0](obelisk-session-evidence-provider-v0.md) | S6/S8 | Draft; optional read-only evaluation | P2: explicit gap recall with resolvable provenance/access, off-path parity; no work authority | +| [Frontier Science Research Program v0](frontier-science-research-program-v0.md) | S11 | Draft; ten-track research proposal | P2: sequential evidence/continuation/stride first; T01–T10 use existing owners and frozen experiment/promotion gates | +| [Long-Horizon Harness Benchmark and Research Program v0](long-horizon-harness-benchmark-research-program-v0.md) | S11 | Draft; active research program | P1 ongoing: native ALE/LHTB/DeepSWE outcomes, matched arms/cost/recovery; research runners outside product runtime | +| [Benchmark Study Upload and Dashboard Projection v0](benchmark-study-upload-dashboard-v0.md) | S11/S5 | Draft; manifest/upload projection proposal | P2: compact public-safe study→readback; native score authority; explicit upload opt-in | +| [Long-Running Agent Reliability Diagnostics and Governed Delivery v0](long-running-agent-reliability-diagnostics-governed-delivery-v0.md) | S10/S13 | Draft; default-off L1 prototype/DSH event adapter exist, P0 unqualified | P1: C0 adapter fidelity/C1 non-interference/overhead; then L2 advice/L3 seams/L4 adoption | + +The shared-authority [evidence companion](shared-goal-authority-state-provider-v0-evidence.zh-CN.md) belongs to S2/S10 backend/soak qualification. The [template](TEMPLATE.md) and [index](README.md) are S12 maintenance contracts, not additional product capabilities. Every new primary RFC adds a row; retirement/merger preserves a successor pointer. Historical filenames never raise delivery maturity. + +## 5. Multi-LoopX-Agent Architecture and Collaboration + +```mermaid +flowchart TD + UI[Local frontend / Lark] --> M[Persistent steward Agent] + M --> C[Shared requests / assessments / results] + C --> K[TS Goal / Todo / lease / quota / effect owners] + K --> A[Selected authority provider] + K --> H[Managed supervisor / attached adapter] + H --> L[Local Agents] + H --> R[Cloud Agents] + L --> K + R --> K + K --> C + C --> O[Durable outbox / audience projection] + O --> UI +``` + +This is the target dependency graph, not a claim that every seam exists. + +| Boundary | Owner / placement | Forbidden substitute authority | +| --- | --- | --- | +| User intent and shared amendment | Alignment RFC's Goal intent/amendment owner | Chat summary, plan digest, manager persona or provider revision authorizing an amendment | +| Work, dependencies, claim, lease, quota and terminal state | Existing typed control-plane bounded contexts | Manager task DB, Python decision mirror or host-local work truth | +| Request, receiver assessment and result relationships | Collaboration boundary converged from `manager_context`; shared by manager→worker and worker→worker | Treating sent as adopted/completed or copying the Todo state machine | +| Processes and sessions | Session mode plus actual host adapter/supervisor | Presence-based takeover or implicit managed/attached switching | +| Persistence and cross-host admission | `AuthorityStore` and selected provider/service | Agents writing databases directly, or placing arbitrary Goal state in the coordination head | +| Presentation and return | Packaged frontend, Lark adapter and existing outbox | Independent frontend/Lark copies of plans, permissions or execution truth | + +This change adds no capability/provider. R1/R3 should extend existing work-items/collaboration ownership; runtime profiles reuse `manager_runtime`, executor choice reuses `steward_executor`, and sessions reuse the current controller. Independently distributed cloud adapters belong in extensions/packages; generic registration/lifecycle belongs in `loopx/extensions/`. Each implementation PR records its placement rationale first. + +Steward coordination permits logical goal decomposition, priority suggestions, delegation and synthesis. `peer_v1` does not prohibit that product role; it prohibits the role conferring unilateral writes, preemption or elevated authority. Macro-goals spanning Goals use existing Goal relationships and scoped requests. Where cross-Goal dependencies or aggregate acceptance lack an owner, deliver a bounded contract with a real caller first, not a global scheduling DSL. + +### Collaboration and Handoff Between LoopX Agents + +Participants are long-running LoopX Agents with their own goals, commitments, frontiers and execution bindings, not merely temporary subtasks inside the steward process. Manager→worker and worker→worker share one collaboration contract. Workers can request help, provide results, challenge dependencies and propose replanning without asking the steward to relay every message. The steward owns overall progress and synthesis, not a serial transit point for every message or commit. + +| Collaboration pattern | Durable relationship and correctness | Minimum real acceptance / route | +| --- | --- | --- | +| Parallel work and join | Branch identities, input versions, artifact/acceptance references and join conditions belong to the canonical work graph; message completion does not satisfy a join | Two workers supply independently accepted outputs to a third integration step; one failure cannot report overall success and independent branches continue. R2/R3 | +| Pipeline handoff | A's accepted result binds B's input; B accepts or reports a gap; upstream revision invalidates affected consumption bases | A→B→C progresses for at least two cycles; B rejects incomplete output and requests clarification from A. Three simultaneously created Todos are insufficient. R2/R3 | +| Peer help and independent review | Requests/replies reference original work and owed return, preserving existing commitments and audience scope; reviewing grants no commit authority | A worker requests bounded help/review from a peer; rejection, deferral and unreadable evidence are observable, with aggregate blockers visible to the steward. R3 | +| Execution responsibility continuation | Semantic context and ownership transfer are separate facts; receiving a message does not transfer claim/lease. Existing work/lease owners decide release, reacquisition or fenced transfer for active work | A is interrupted and B resumes eligible transferred work from durable context; returning A cannot duplicate a commit. #4094 only proves a narrow same-host, unleased path, not this full capability. R3/R4/R6 | +| Cross-Goal / cross-host work | Explicitly authorized parent/child goals or requests, artifacts and return relationships; authority owners validate remote identity, access and commit | Local planning/integration and cloud execution share verifiable dependencies; network replay, revocation and source-session disappearance preserve return obligations. R6 | + +Minimum semantic handoff facts are Goal/request/work identity, sender/receiver, intent and input basis, purpose and decisions, constraints/non-goals, completed and remaining work, authorized resolvable artifacts/evidence, acceptance/return requirements and current claim/lease disposition. Carry them through existing contracts rather than creating an envelope for every table row. Exchange bounded work summaries, not raw session data or private reasoning traces. Request receipt, work adoption, effect commit, result acceptance and answer delivery are distinct facts; reuse their owners' receipts and idempotency identities. Timeout alone establishes neither rejection, failure nor successful takeover. + +R2's dependency must use real requests/artifact handoff between LoopX Agents. This is a P0 small-team exit gate, not work deferred until hundred-Agent scale. R3 completes general peer collaboration, durable return and recovery migration; R4/R6 qualify leased and cross-host transfers. Detect dependency cycles, rejection, timeout and invalidated inputs as steward-visible blockers and resolve through existing replan ownership, not another global scheduler. Frontend and Lark should expose request→adoption→work→artifact→acceptance→return relationships and current blockers, not only online counts or message history. + +## 6. Core Delivery Path: R1–R7 Execution Cards + +| Card | Priority / accepted outcome | Hard prerequisites | Work that can progress alongside it | +| --- | --- | --- | --- | +| R1 | P0: confirmed commitments survive materialization; failure/retry is recoverable | Current main and F1–F4 regressions | Other TS transactions and provider promotion | +| R2 | P0: one steward drives 2–3 bound managed workers through continued work | R1 and real selected runtime/profile qualification | Full collaboration migration and PostgreSQL | +| R3 | P1: semantic handoff and automatic return survive restart without owner polling | Existing inbox/outbox; new generic producers require transaction migration | Early answer/transport recovery can start with R1/R2 | +| R4 | P1: shared intent/work basis and governed amendment close the loop | Alignment Stage 1/2 and affected TS transactions | R1–R3 that preserve shared intent | +| R5 | P1: durable local authority and long-horizon storage qualification | Affected T0–T3 transactions and D1/D2/D3 | Preparation alongside R1–R4; no full TS rewrite prerequisite | +| R6 | P2: local and cloud workers share authority and recover execution | R2/R3, selected shared profile, authenticated service and applicable R4 contracts | PostgreSQL service engineering can start earlier without promotion | +| R7 | P2: staged 10 / 30 / 100+ scale with capacity/recovery evidence | R1–R6 appropriate to the cohort | Early pagination/performance work; larger prompts or raised caps are insufficient | + +These priorities do not change live Goal quota or authorize experiments/cloud resources. A small local team can use an already supported authority profile without waiting for a new provider. Changing profile or retention retains the original real-backend, soak and explicit promotion requirements. + +### R1: Reliable Team-plan Commit + +- **Entrypoint/owner:** `ChatActionService`, governed proposals, canonical Todo writer, frontend confirmation/readback; any Lark entry uses the same service. +- **Reproduce first:** F1–F4, then equal text on different lanes, an existing Todo completed/edited before retry, concurrent confirmations and response loss after receipt commit. +- **Smallest complete change:** classify every plan field as an execution constraint, retained acceptance reference or advisory fact. Preserve priority through the existing Todo contract. Quota/stop consume existing policy owners; unsupported enforced constraints must be rejected before confirmation, not merely stored as JSON. Retain lane→Todo→acceptance relationships. +- **Transaction:** bind relevant Goal/authorization/work facts and revalidate at commit; hashing the whole registry is insufficient. Use an existing suitable atomic transaction or a recoverable workflow with durable per-lane identity/receipts, recovery cursor and execution barrier. Declare the atomicity boundary. A function named settle is not proof of atomicity. Reuse Effect recovery, not a second scheduler. +- **Exit:** independent readback proves retained commitments; distinguish all-gap/partial/stale/rejected/committed; recovery neither duplicates nor expands work, and the initiating surface displays the exact outcome. Add independent semantic counterexamples, not only row-existence assertions. +- **Rollback:** stop new plan production, keep old previews/receipts readable and unfinished reconciliation available; do not delete materialized work. + +### R2: Continuous Small-team Execution + +- **Entrypoint/owner:** existing session binding, Turn driver, quota/scheduler and manager runtime configuration; reuse the current settings editor/profile owner. +- **Delivery:** distinguish registered, addressable, bound, launchable, executing and blocked. Plan readiness cannot imply running work. For authorized, qualified managed bindings, launch the next bounded Turn through existing launch/supervision. Attached hosts retain their original execution driver. +- **Qualification:** use the actual selected runtime for at least two work→artifact→independent validation→settlement→successor cycles; interrupt/restart one worker while another progresses. Verify returning stale-executor fences, cancellation and no new launches after stop. Qualify DSH single-segment read-only Chat separately from Codex `trusted_owner`. +- **Exit:** 2–3 workers, one dependency, one failure and one direction correction; inspect through packaged frontend and independent CLI readback. An authorized Lark entry reads the corresponding audience-visible feedback. Untested Lark remains explicitly unqualified. +- **Rollback:** stop new admission, drain accepted work and retain bindings/receipts; attached fallback cannot be used to simulate availability. + +### R3: Semantic Requests and Automatic Return + +- **Owner:** manager RFC M2/M3; migrate existing `manager_context` request/tracking/return into one typed collaboration transaction, incorporating the #4094 adapter. +- **Delivery:** preserve purpose, decisions, constraints, evidence references and expected return. Receivers independently adopt/defer/reject/replan. Accepted work, committed result and delivered answer are separate facts; existing outbox provides automatic return. +- **Exit:** actual manager→worker and worker→worker callers; follow-up messages, lost source session, oversized answer, duplicate callback, successful send with lost ACK and transport restart. CLI, packaged frontend and Lark read back the same result with audience isolation. Ordinary already-authorized work gains no second confirmation. +- **Migration/rollback:** characterize first, record old writer/reader mappings and deletion payoff; disabling new production must leave old requests drainable. Do not retain two writable lifecycles. + +### R4: Shared Goal Alignment and Evolution + +- **Owner:** alignment RFC Stage 3–5 and TS Goal/work-graph owners. +- **First correction:** `intent_basis` remains the existing source-facts digest. Preserve compatible readers; introducing a real intent revision requires versioning and producer/reader inventory. Renaming cannot give historical receipts stronger semantics. +- **Order:** establish root intent/permissions/acceptance/stop authority, then one intent-preserving work-graph commit class. Ordinary Todo edits retain existing owners; do not require amendment for every add. Changes to shared commitments consume scoped policy, required verifier, exact CAS and lease-impact disposition. +- **Exit:** competing peers at the same basis produce at most one conflicting commit; response loss returns the original receipt; leased work receives explicit continue/rebase/stop handling; affected frontiers update or are gated. Permission expansion is rejected; unrelated peers continue without unanimous voting. +- **Rollback:** disable the commit class, retain effect-free proposals; do not restore old revisions or relax fences. + +### R5: TS Convergence and Local Persistence + +- **Owner:** TS T0–T4 and shared-authority D1–D3; retain their numbering and gates. +- **Selection:** prioritize an entire hot-path transaction or recovery lifecycle used by R1–R4. Record before/after callers, owners, crossings, actual deletions and performance. Stop adding per-field Python→TS RPCs; do not rebuild the merged Todo update. +- **Delivery:** qualify full-source reads, one-way Markdown projection, event/receipt retention, restart recovery, capacity and long-term cost on the selected local profile. Source failure cannot fall back to legacy. R1 cannot put large plan bodies into the coordination head. +- **Exit:** affected real CLI/backend, immutable baseline versus candidate comparison, negative/mutation coverage, three-arm rehearsal and applicable D2 soak of at least ten days. D3 retains explicit cutover approval. This audit runs no new soak and promotes no provider. +- **Rollback:** reviewed fenced export/import and schema-aware downgrade; replacing a binary cannot restore old write authority. + +### R6: Local/Cloud Convergence + +- **Owner:** shared-authority provider/service, session host adapters and collaboration. Extend existing PostgreSQL admission/identity-rotation foundations; do not rebuild the store. +- **Delivery:** authenticated transport, tenant/Goal/actor authorization, host identity and capability admission. Cross-host request/receipt/wake flows use their owners. Handle disconnection, lease expiry, stale workers, service restart/restore incarnation and ambiguous commit. +- **Exit:** at least two real hosts, including one cloud worker, collaborate in an isolated tenant; wrong-tenant/actor, revocation and split-brain negatives pass. Shared budgets/admission have explicit ownership; local quota is not a distributed resource reservation. +- **Rollback:** stop remote admission, retain committed facts and drain; do not import or rebind another host's raw session data. + +### R7: Hundred-Agent Qualification + +- **Owner:** existing directory/projection, quota/scheduler, authority/provider and host supervisor. The manager consumes bounded summaries, pages and evidence on demand. +- **Order:** make the 25th and later registered Agents discoverable by stable identity/pagination, then qualify concurrent cohorts of 10, 30 and 100+. Retain the bounded eight-lane plan contract; organize larger work as traceable batches/subgoals rather than changing the limit to 100. +- **Scheduling:** coalesce wakeups, back off, bound provider/host admission and budgets, preserve fairness and isolate failures. The existing scheduler remains the only scheduling owner. Completion/failure/decision events drive attention; periodic readback repairs gaps. Do not put every peer into every Agent's prompt each turn. +- **Exit:** at each size record registered/active counts, passed/failed/untested cases, p50/p95 queue/recovery latency, time to first useful action, duplicate effects, rejected stale writes, cost per accepted artifact, human interventions and queue/history growth. Freeze budget, load and SLO before experiments; do not tune thresholds after seeing results. +- **Final acceptance:** users submit and revise a macro-goal through both entries; heterogeneous local/cloud workers deliver dependent artifacts continuously. The manager detects blockers, replans within grants, reports and closes the Goal through independent acceptance. No duplicate protected effects or stale/unauthorized commits; performance claims need real measurements. Run synthetic pressure before an explicitly authorized live cohort. This plan starts no hundred-Agent paid run. +- **Rollback:** reduce concurrency/admission while retaining registrations, history and reconciliation; never weaken correctness gates. + +## 7. Execution and Review Contract + +Select one complete, verifiable slice whose prerequisites hold. Check latest main and canonical Todos first; qualify existing work instead of rebuilding it, update existing tasks and retain supersession lineage. These cards are a static roadmap. Actual assignees, status, PRs and blockers belong in LoopX Todos. + +Each implementation Todo/PR must answer: + +1. **Outcome:** user action and before/after behavior; R card and owning RFC acceptance ID. +2. **Facts:** baseline/head, shipped dependencies and unresolved fields/states; inspect code, not PR titles. +3. **Ownership:** one semantic owner, provider/profile and real callers; deleted decisions/writers and compatibility callers retained for a concrete reason. +4. **Invariants:** independent expected outcomes before characterization/negative tests; repair incorrect rules rather than updating goldens to hide defects. +5. **Failure:** select applicable no-effect rejection, concurrency, timeout, partial commit, crash/replay, stale-basis and default-off parity cases. +6. **Product:** CLI/managed, packaged frontend and Lark interaction, readback and feedback; verify why companion work is unnecessary, and label untested surfaces. +7. **Delivery:** explicit staging, DCO, relevant canary, public-boundary scan and PR; retain real authority and first-screen review gates. +8. **Continuation:** one executable successor, changed dependencies/blockers and rollback. Fields, passing tests or an arbitrary receipt do not establish a full milestone. + +Less capable execution Agents can repair specified counterexamples and perform mechanical migration within this contract. New authority, state machines, cross-host identities and incompatible schema changes require the relevant owner's review of the exact diff, rules and evidence; model class or Agent self-assessment is not the oracle. The bounded future-facing pass should remove duplicate knowledge; larger adjacent refactors become scoped successors. + +Recommended first batches: R1 semantic/readback repairs as a cohesive change; then durable recovery and source-basis constraints on the same path; then R2 small-team acceptance. Existing-result delivery repairs under R3 and selected-profile qualification preparation under R5 may proceed in other tasks without concealing R1 blockers. + +## 8. Recent Steward Delivery Audit and Evidence + +Current main has a steward channel, executor configuration, team-plan confirmation, initial Todo materialization and a local peer directory. Recent delivery is useful: it reuses the canonical Todo owner and preserves same-Goal validation and audience boundaries. It has not yet demonstrated a steward coordinating continuously working Agents through independent Goal acceptance and automatic return. Existing tests mainly prove local paths; some plan commitments disappear at materialization, and unsuccessful outcomes are not fully distinguished from success. + +The target is an owner expressing goals, adding constraints and changing direction through the local frontend or Lark, while a persistent steward investigates, organizes work, coordinates local managed and cloud Agents, recovers failures and reports verifiable outcomes. The scale target starts with hundreds of registered Agents, then qualifies hundreds of simultaneously active Agents. Registration count, active executors and measured throughput must be reported separately. + +Progress means another independently reproducible user journey, not more fields or merged PRs. This assessment concerns commits and implementation. It does not infer quality from model or author identity, or attribute adjacent contributors' changes to one Agent. + +### Useful Delivery and Its Limits + +| Area | Reusable facts | What they do not establish | +| --- | --- | --- | +| Channel and configuration | `steward_executor` machine configuration and channel readback; private Codex `trusted_owner` in `manager_runtime`; #4510, #4557 | Equivalent capable, persistent tool sessions through single-segment DSH Chat | +| Team intake | #4519/#4522/#4524/#4535/#4538: bounded plan, Goal identity, registration validation, Todo owner and receipts; #4547/#4548/#4552: frontend confirmation and browser fixture | Team launch, enforced budget, Goal-intent alignment or the same qualified Lark path | +| Peer discovery | #4544: same-Goal local directory, 24-row cap, explicit presence/lease coverage gaps | Complete discovery of 100 Agents, authenticated remote identities or takeover/lease authority | +| TS kernel | Typed owners and partial whole-transaction cutovers for Todo, lease, quota/replan | Every writer migrated, or new Python orchestration automatically satisfying replacement-first | +| Shared authority | `AuthorityStore`, File/SQLite candidates, PostgreSQL store/service admission seam, recovery and conformance foundations | A deployed authenticated cross-host service, a promoted default provider or distributed quota | +| Alignment | Stage 1/2 source-basis reader and amendment admission/retention | A full Goal-intent revision in `source_basis_digest`, or Stage 3 automatic commit | +| Managed execution | `turn run-once`, managed step, attached broker and executor fences | Unattended long-horizon supervision from one bounded segment, or a healthy executor for every registered Agent | + +### Verified Findings + +These are synthetic-fixture results at the exact baseline, without live user content. F1–F4 exercise existing `ChatActionService.preview/apply` with isolated Goals. F4 injects failure immediately before the second Todo write; the other writes use the actual local Todo writer. F5–F7 are source/contract findings. Runtime repairs are outstanding; this documentation change does not implement them. + +| ID / Priority | Trigger, result and consequence | Location and successor | +| --- | --- | --- | +| F1 / P0 | A plan declares P0, apply succeeds, and `list_goal_todos` returns null `priority`. Lane acceptance, quota envelope and stop condition also do not enter this apply path's work/execution constraints. Confirmed commitments differ from actual work. | `governed_transition_proposal.py::_apply_team_plan` passes text/action/claim; `team-plan-preview.ts` displays the declarations. → R1 | +| F2 / P0 | Change the active-state objective after preview without changing registry bytes; the old plan still returns `team_plan_applied`. Preview binds registry bytes, not intent or relevant work/authorization facts. | `chat_actions.py::_registry_fingerprint`, `_apply_team_plan`; `_intent_basis_for` reads only at apply and may omit the result. It is not a commit precondition. → R1/R4 | +| F3 / P1 | Every lane is unregistered and zero Todos are created, but the result is `team_plan_lanes_already_present`, `projection_verified: true`, and an empty Todo id. Success language hides missing staffing. | `chat_actions.py::_apply_team_plan`; the existing gap test checks only the empty list. → R1 | +| F4 / P0 | Failure on the second lane leaves the first Todo committed, the Chat proposal `applying`, and no complete receipt. Manual retry fills the gap; durable per-lane reconciliation, automatic recovery, an execution barrier and replay after intervening work changes are not demonstrated. | Multiple `add_goal_todo` calls precede checkpoint; the Chat caller supplies empty receipts and a no-op checkpoint. → R1 | +| F5 / P1 | `intent_basis` and prose calling it a canonical intent revision overstate the evidence. Alignment explicitly defines a source-facts/event-axis digest, plus the applicable Todo revision, rather than the complete intent envelope. | `goals/shared_goal_alignment.py` module contract and the old harness-selection team section. → documentation correction here + R4 | +| F6 / P1 | `ready` validates registration and action kind, not runtime binding, actual tool eligibility or configured execution capacity. Having gap reason codes does not prove those conditions are machine-detected. | `validate_steward_team_plan_preview`; `agents/directory.py` explicitly has no presence provider. → R2 | +| F7 / P1 | The manager RFC still calls delivery a proposal, the selection RFC still says no frontend confirmation surface, and later paragraphs separately add shipped progress. The authority introduction still says service admission is unshipped. This can cause duplicate work or skipped gaps. | This revision aligns checkpoints, compresses stale progress and establishes one roadmap. Do not repair competing current truths by appending another dated paragraph. | + +The assessment is to retain the useful local implementation and boundary discipline, while strengthening cross-module semantic preservation, recovery, current-state maintenance and whole-journey acceptance. The current product is suitable for bounded trials and hardening. Plan confirmation, one answer or a test count cannot substantiate hundred-Agent long-horizon coordination. + +At the stated baseline with source-checkout Python 3.13.13, these groups returned **69 passed** and **108 passed**, respectively: + +```sh +uv run --extra test python -m pytest -q tests/test_steward_team_plan_preview.py tests/test_steward_team_plan_apply.py tests/test_chat_team_plan_action.py tests/test_manager_team_plan_guidance.py tests/test_manager_channel_binding.py tests/control_plane/test_peer_agent_directory.py tests/capabilities/test_steward_executor_machine_defaults.py tests/capabilities/test_manager_runtime_profile.py +uv run --extra test python -m pytest -q tests/test_turn_managed_executor_binding.py tests/test_loopx_turn_managed_step.py tests/test_attached_session_cli.py tests/test_manager_context_handoff.py tests/test_manager_context_roundtrip.py tests/control_plane/test_shared_goal_alignment.py tests/control_plane/test_shared_goal_alignment_cli.py +``` + +These 177 tests are not a full repository run or live cloud/model, packaged-browser, Lark or PostgreSQL qualification. The #4552 browser fixture and live source-read record in the selection RFC are historical evidence, not rerun here, and do not qualify team execution. F1–F4 reproduction steps are fixed in the findings table; implementation should add the corresponding independent semantic regressions to existing tests, not commit temporary diagnostic scripts or private run logs. + +Update the current assessment, card boundaries and qualifying evidence in place. Move long historical ledgers to companions and keep domain RFC status synchronized. If domain state/authority/migration contracts conflict, stop affected implementation and repair the documents rather than overriding accepted authority through this roadmap. Merging this document makes the route discoverable; it neither completes R1–R7 nor promotes Draft decisions. diff --git a/docs/architecture/rfcs/loopx-overall-roadmap-v0.zh-CN.md b/docs/architecture/rfcs/loopx-overall-roadmap-v0.zh-CN.md new file mode 100644 index 0000000000..36ec530bdb --- /dev/null +++ b/docs/architecture/rfcs/loopx-overall-roadmap-v0.zh-CN.md @@ -0,0 +1,324 @@ +# LoopX 整体路线总纲 v0：产品、协作、技术与交付 + +- 状态：Draft 总体路线；不自动接受领域 RFC、不晋升 provider、不改变默认权限。 +- 范围基线：2026-09-16，`0aa6179de`；管家故障复现基线单独保留在第 8 节。 +- 责任：总纲拥有产品目标、跨领域依赖、优先级和组合验收；领域 RFC/稳定协议拥有具体规则；运行 Todo 拥有执行状态。 +- 语言：[English](loopx-overall-roadmap-v0.md) 与本文互为语义镜像。 + +## 1. 总目标与产品路线 + +LoopX 的目标是让人用本地前端或 Lark 提出、修订和验收复杂目标，由持久管家协调多个拥有独立工作承诺的长程 LoopX Agent，在本地 managed 与云端 runtime 上持续完成可验证的工作。单 Agent 的长程可靠性是基础，多个 Agent 的协作、handoff、恢复和共享目标收敛是核心能力，百 Agent 规模是需要独立证明的系统资格。 + +产品成效以**在约束内交付的已验收成果、人的注意力成本和恢复能力**衡量。在线 Agent 数、生成内容量、工具调用数和 PR 数是过程信号。模型、runtime、存储 provider、IM 或 memory 服务可以替换；Goal/Todo/claim/lease/quota/effect 与验收规则必须保持明确、可追溯的唯一 owner。 + +| 用户与工作 | 最短价值路径 | 必须能验收的结果 | +| --- | --- | --- | +| 个人开发者/研究者 | 连接项目→一个现有或 managed Agent→连续工作→中断接续 | 安装与首次有效动作可复现；工作、产物、成本和下一步可读；不用理解全部 RFC | +| 项目负责人/管家操作者 | 目标与约束→小团队→依赖产物→方向补充→综合验收 | 能看清谁负责什么、为什么阻塞、需要什么判断；直接与 worker 对话仍可用 | +| 多项目/多主机操作者 | 有范围父子目标→本地/云端分工→共享权威与预算→整体回报 | peer 协作、隔离、公平性和恢复成立；不能因角色变成全局超级管理员 | +| 已有 agent 系统的采用者 | L1 被动诊断→L2 建议→经授权的 L3 seam→可选 L4 控制面 | 先证明无干扰和诊断价值，再证明控制效果；支持不替换原 runtime 的采用路径 | +| 能力/host/provider 开发者 | 最小 adapter→兼容与权限检查→资格证据→安装/卸载 | 扩展不复制内核真相，关闭不影响核心；版本与能力支持可发现 | + +产品范围包括工程交付、研究探索、材料与知识工作、office/content 工作等可复用场景。先用一个工程交付案例和一个知识/研究案例证明可迁移性；领域能力归 capability/package，不能把某个场景的评分、阶段或私有语义写入通用内核。金融等受保护外部效果按独立领域合同模拟资格化，不能借“通用管家”直接取得执行权限。 + +两条采用路线共用工程资产但分别验收：**原生 LoopX 长程协调**优先完成 G1/G2；**observer-first 可靠性诊断**可并行证明价值，不等待百 Agent 或 shared service。收费部署、企业功能和托管服务仍是产品假设，不能把架构规划写成已有市场验证或运营承诺。 + +### 总纲与现有文档的关系 + +- 本页是跨产品、工程、研究和采用的路线总纲；第 2 节定义 S1–S13 工作流，第 3 节定义 G0–G5 组合里程碑，第 4 节映射全部 RFC，第 5–6 节细化多 Agent 核心路径，第 8 节保存可复核审计。 +- [技术方向页](../../project/technical-directions.md) 维护公开贡献入口与 tracker，[RFC 索引](README.md) 维护领域路由；它们投影本页的跨域次序，领域 RFC 保持自己的 T/M/D/A 编号和权限门槛。 +- [产品愿景](../../product/vision.md)、[能力目录](../../../loopx/capabilities/README.md)、[稳定协议](../../reference/protocols/README.md) 和已发布版本定义各自范围。总纲不创造第二套任务账本、状态 schema 或 release 支持声明。 + +## 2. 全领域工作流：目标、缺口与执行切片 + +优先级定义：P0 是当前用户旅程的正确性/连续性阻塞；P1 是可重复交付与协作基础；P2 是有证据后扩展规模、场景或采用；P3 保持设计、等待需求触发。优先级表示工作选择，不覆盖安全门槛或既有运行 quota。负责方指模块/能力 owner，不预先指定某个模型或个人。 + +| 工作流 | 目标及当前基础 | 下一完整切片、前置与退出证据 | +| --- | --- | --- | +| **S1 产品与持久管家 · P0** | 从需求、调查、分解到验收回报；现有 manager runtime、team intake 和 settings 是基础，端到端持续工作未完整证明 | 以 R1/R2 为第一批：承诺保留、已绑定 worker 实际推进、用户补充方向后继续；CLI/packaged frontend/Lark 分别标记资格。以两轮依赖产物及独立验收关闭最小旅程 | +| **S2 typed 内核与 durable authority · P0/P1** | Effect/Todo/quota/recovery owner、TS 事务迁移与 store 候选已存在；writer 和 provider 晋升仍未全闭合 | 每次迁移一个真实事务/恢复生命周期，先语义反例再切换/删除旧 owner；R1 正确性先于迁移数量。真实 backend、并发/fence、ambiguous commit、保留/导出恢复、bridge 成本及 D1–D3 资格 | +| **S3 目标规划与 multi-Agent 协作 · P0/P1** | Vision/replan、peer frontier、claim/lease、directory、manager_context 和显式接续有基础；通用 handoff/共享修订未闭环 | R2 必须证明 peer 依赖；R3 完成并行汇合、流水线、求助/复核、接续、自动回报；R4 做一个保持 intent 的 amendment class。检查依赖环、输入失效、拒绝/延期、lease 转移、同基线竞争及 aggregate acceptance | +| **S4 runtime/host/daemon · P0/P1** | attached/managed、Turn、broker、runtime connector 和 Desktop 修复存在；“registered”不等于可执行 | 选择一个真实合格组合完成多 Turn supervision；restart/cancel/drain/stop 不丢工作且旧 executor 被 fence。之后扩 host parity、service-profile 唯一 owner、干净安装与版本升级；按 adapter 能力显示不支持项 | +| **S5 前端、Lark 与人机交互 · P0/P1** | 本地对话、settings、proposal 和部分 Goal Channel vertical 已有；统一受众/会话/工作回读仍需资格 | 用一个团队旅程贯穿设置、工作图、handoff、阻塞、成本、修订、产物和回报；共享 typed projection，验证重连/重复点击/stale/原路反馈。再做 intelligent review、无障碍键盘流程、中英术语、错误可恢复和离线降级；只在真实决策处打断人 | +| **S6 材料、证据、记忆与学习 · P1** | authority registry、material lifecycle/frontier、decision context、reward memory、turn recall 已有；方向基线和部分归因仍是提案 | 先打通“材料 revision→同 Agent 阅读→决策引用→产物/结果”；失效、撤销、来源消失与遗忘策略可回读。handoff 保存影响决策的摘要与授权 artifact；OpenViking/Obelisk 按可选 provider 资格化。utility 的因果收益另以对照证明，不把相关性当提升 | +| **S7 预算、调度与 fleet 规模 · P0 观测/P1–P2 扩展** | quota/scheduler 与部分 usage aggregate 存在；全 provider 成本、分布式资源预留及百 Agent 并发尚需证据 | 先区分配置预算、准入、消耗与估算；未知成本不记零、重复事件不双记。R7 分页/有界摘要、provider/host 限流、公平性、背压、事件唤醒与失败隔离；分别报告注册数/活跃数/吞吐量和每个验收成果成本 | +| **S8 能力、扩展与领域集成 · P1/P2** | 已有 capability catalog、extension 生命周期、hook、工程/研究/content/office 能力及 computer-use 合同 | 优先用现有 issue-fix/PR-review 和材料/研究 caller 检验共享控制面；每个 provider 带 readiness、版本、权限、默认关闭、卸载/回滚、失败隔离与真实入口证据。新 domain effect 从模拟单操作闭环开始，不先建市场或通用工作流 DSL | +| **S9 身份、权限、隐私与信任 · P0 持续/P1–P2 远端** | public/private 边界、作用域、capability gate、fence 与确认合同分布在已有 owner | 随 R1/R3 验 sender/audience/artifact scope 和 stale authority；远端 R6 必须认证 tenant/Goal/actor/host、轮换撤销与最小权限。凭据保管、非可信工具/文档输入、依赖供应链、审计留存/删除及漏洞响应纳入真实路径；角色、消息或 memory 不铸造写权限 | +| **S10 可靠性、诊断与运行运营 · P0/P1** | recovery/canary、read-only diagnostics 原型及 DSH event adapter 已有；C0/C1、开销和完整运营资格仍未闭合 | 故障分类→可观察状态→恢复演练→防复发；覆盖进程/存储/网络/投递故障和数据增长。定义并冻结 SLO、RPO/RTO、容量/保留边界，实测后标 qualified；运行手册含升级、备份恢复、停止与人工接管，不以测试数代替恢复结果 | +| **S11 评测与科学研究 · P1 持续/P2 研究** | benchmark toolkit、Explore、长程 portfolio 与十轨 frontier science 有设计/局部实现 | 固定 native/passive/governed arm、模型/harness/预算/task split 与 evaluator；报告原生分数、成本、失败、人工介入和不确定性。sequential evidence、continuation、stride 为早期研究；memory、formal kernel、curriculum/evolution、主动实验与多尺度状态按 T01–T10 分阶段，不自动影响生产 | +| **S12 发布、开发体验与社区治理 · P0 卫生/P1** | 安装、源码验证、扩展注册、DCO/PR、测试层级、contributor route 与双语文档已存在 | 从干净机器/发布包验一条首次工作和一次升级/回滚；host/OS 支持以 release contract 为准。缩短合理改动的定位、测试和 review 成本；公开精确 head、可重复 fixture、兼容窗口、维护者路由和贡献归属，退休重复协议及过时证据 | +| **S13 采用、生态与商业可持续性 · P1 发现/P2 试点** | 公开 adoption loop、showcase、license/governance、observer-first 产品合同已存在；付费 PMF 未证明 | 先收集真实独立首次使用/重复使用/退出原因，做可复现案例和有固定预算/验收/回滚的试点；沉淀 reusable adapter 与交付手册。核算模型/计算/存储/支持成本及维护负担；满足重复需求后再决策商业托管边界、支持等级和分发，不承诺 SLA 或擅改开源条款 | + +### RFC 之外的关键覆盖与 owning sources + +下列不是可忽略的配套事项；它们直接决定一个长程团队是否可用。目录或 README 证明的是可发现的实现/合同入口，具体安装可用性仍从 `loopx capability list/show` 与选定版本读取。 + +| 领域与已有入口 | 所属工作流 | 当前总纲要求的下一步 | +| --- | --- | --- | +| [Goal Vision/replan](../../reference/protocols/goal-vision-replan-contract-v0.md)、[work graph](../../reference/protocols/task-graph-projection-v0.md)、[peer runtime](../../reference/protocols/peer-agent-runtime-v1.md)、[监督](../../reference/protocols/peer-supervisor-v0.md) | S2/S3 | 将跨工作依赖、重规划、验收与 handoff 放进同一个真实案例；aggregate closeout 必须消费验收事实 | +| [quota](../../quota-allocation.md)、[cadence](../../operations/long-task-cadence-policy.md)、[attention](../../operations/attention-queue.md) | S5/S7 | 预算耗尽/延期/被阻塞时有明确下一次触发及用户回读；百 Agent 不靠高频全文轮询 | +| [材料生命周期](../../reference/protocols/material-lifecycle-architecture-v0.zh-CN.md)、[材料 frontier](../../reference/protocols/agent-material-frontier-v0.md)、[authority 注册](../../operations/authority-source-registration.md) | S6 | 路线/RFC 更新能由 Agent 按 revision 发现并登记阅读；read receipt 不表示同意或获得权限；归档不丢原始来源 | +| [Decision Context](../../../loopx/capabilities/decision_context/README.md)、[Reward Memory](../../../loopx/capabilities/reward_memory/README.md)、[Semantic Preference](../../../loopx/capabilities/semantic_preference/README.md)、[Turn Recall](../../../loopx/capabilities/agent_turn_recall/README.md) | S6/S11 | 区分事实、偏好、建议、归因和权威；同一 scope 的回忆/失效/结果反馈负例先行 | +| [Issue Fix](../../../loopx/capabilities/issue_fix/README.md)、[PR Review](../../../loopx/capabilities/pr_review_queue/README.md)、[Change Quality](../../../loopx/capabilities/change_quality/README.md)、[Integration Branch](../../../loopx/capabilities/integration_branch/README.md)、[Change Window](../../../loopx/capabilities/repository_change_window/README.md) | S8/S12 | 作为工程团队的端到端 caller：问题→实现→独立 review→验证→批准范围内交付；head 漂移不复用旧证据 | +| [Explore](../../../loopx/capabilities/explore/README.md)、[Benchmark Toolkit](../../../loopx/capabilities/benchmark_toolkit/README.md)、[auto-research](../../product/use-cases/auto-research/README.md) | S8/S11 | 作为第二类协作旅程：问题/假设→并行实验→独立解释→后继；无提升/失败也形成有效结果 | +| [Content Operations](../../../loopx/capabilities/content_ops/README.md)、[Periodic Report](../../../loopx/capabilities/periodic_report/README.md)、[office operations](../../product/use-cases/office-operations/README.md)、[domain packs](../../product/domain-capability-packs.md) | S5/S8 | 公共投影驱动显示；草稿、review、发布权限与结果分离；不将 generic sink 绑定项目私有文档 | +| [Extensions](../../reference/extensions.md)、[runtime catalog](../../integrations/runtime-connector-catalog.md)、[host surface](../../reference/protocols/host-integration-surface-v0.md)、[skill delivery](../../../loopx/capabilities/project_skill_delivery/README.md) | S4/S8/S12 | 最小 adapter 示例与注册 readback 一致；兼容矩阵、升级/禁用/卸载有实测；host skill 不成为第二内核 | +| [Computer Use](../../reference/protocols/computer-use-runtime-v0.md)、[operator credential](../../reference/operator-model-credential.md)、[private boundary](../../public-private-boundary.md) | S8/S9 | 按实际 host 限制与敏感操作授权验收；外部文本无法自行提升权限，截图/日志与凭据有隔离和留存边界 | +| [Testing/quality](../../development/testing-and-quality.md)、[CI impact](../../development/ci-impact-selection.md)、[source correctness](../../reference/protocols/local-state-write-correctness-v0.md)、[release readiness](../../product/release-readiness.md) | S2/S10/S12 | 独立语义预期、真实 backend 与安装入口、负例/mutation；控制验证成本，但不把 skipped 当通过 | +| [Install](../../guides/installing-loopx.md)、[newcomer path](../../guides/newcomer-command-path.md)、[design](../../development/design.md)、[user guide](../../guides/personal-workspace-user-guide.md) | S1/S5/S12 | 首次价值路径、错误修复、支持平台、可访问性和双语一致性；UI 变化使用既有 design 和 first-screen review | +| [Public adoption](../../product/public-adoption-loop.md)、[scenario gaps](../../product/scenario-capability-gap-map.md)、[SaaS assessment](../../product/roadmaps/saas-opportunity-assessment.zh-CN.md)、[licensing](../../project/licensing.md)、[governance](../../../.github/GOVERNANCE.md) | S12/S13 | 公开成果与失败反馈可追溯；商业假设独立验收，license/贡献者归属/社区权限按既有政策，不由总纲改写 | + +## 3. 组合里程碑、资源次序与完成定义 + +S 工作流表示长期责任，G 里程碑表示一次可验收的产品组合，R 卡表示当前主线实现切片。三者互相引用，不新增运行状态机。未列日期表示按证据晋级；可用资源和业务优先级改变时更新 canonical Todo，而不是假定全部同期开工。 + +| 里程碑 | 产品退出条件 | 必须闭合的工作流 / 核心路径 | +| --- | --- | --- | +| **G0 可信基线** | 当前功能/默认值/资格可读；已复现承诺丢失、stale、空成功、部分提交等错误有回归和修复；发布包的单 Agent 基本循环及成本未知项显式可见 | S1/S2/S7/S9/S10/S12；R1。不会因总纲合并自动完成 | +| **G1 小团队交付** | 管家和 2–3 个长程 LoopX worker 至少两轮真实协作，含依赖产物、peer handoff、故障恢复、用户补充与独立验收；单 Agent 路径继续可用 | G0；S3/S4/S5；R2 + R3 的最小现有路径，不等通用迁移或新 store | +| **G2 可恢复的协作工作台** | 通用 peer 请求/复核/结果返回、会话接续、材料与方向基线可追溯；本地前端/Lark 使用相同事实；本地 durable profile 通过适用资格 | G1；S2–S7/S9/S10；R3/R4/R5。D3 等显式晋升仍单独决策 | +| **G3 本地/云端共同工作** | 至少两真实 host（含云端），认证作用域、撤销、网络故障、共享预算与旧 worker fence 成立；依赖产物和回报跨 host 可恢复 | G2 相关合同；S3/S4/S7/S9/S10；R6 | +| **G4 百 Agent 资格** | 10→30→100+ 的活跃 cohort 分级满足预先冻结的吞吐/延迟/成本/恢复 SLO；宏观目标经历方向变化仍收敛，管家不成为消息瓶颈 | G3；R7；S5/S7/S10/S11。注册百行不能替代该门槛 | +| **G5 可重复采用与生态** | 外部用户可独立安装、复现、升级、导出/回滚；至少工程及知识/研究两类旅程形成可验证案例；支持成本、维护归属、试点成效有记录 | S8/S10–S13 从 G0 并行投入；小范围采用不等待 G4。商业服务须额外明确运营与许可边界 | + +首批资源顺序：先完成 R1 的用户承诺与恢复闭环，再验 G1 的真实小团队；允许一个相邻 TS 事务/投递修复切片和一个只读诊断/材料资格切片同期准备，但不得让后续设计掩盖 P0。每个实现切片只有一个主 owner、一个主验收结果和明确依赖；同时进行多少项按实际 review 与验证容量决定，不按 Agent 数填满任务板。 + +暂停/降级条件：新方案复制权威或扩大默认权限、真实 backend 资格缺失、改动无法独立回滚、成本或人工干预随规模失控、benchmark integrity 失败、用户无法解释当前工作与阻塞。保留事实/回执，停止相关新 admission，修复规则或缩小 cohort；不能靠放松验收、删失败样本、刷测试预期或换名晋级。 + +### 跨领域指标与验证矩阵 + +| 维度 | 统一口径 | 最低证据 | +| --- | --- | --- | +| 成果/收敛 | 已验收成果率、目标关闭质量、失效产物重做率；分开无提升、失败和未知 | 独立 verifier/验收 owner；完整失败分母、目标与输入版本 | +| 协作/接续 | 请求采纳延迟、依赖等待、交接后首次有效动作、原路回报达成率、重复受保护效果 | request/work/artifact/receipt lineage；接收方拒绝、来源消失、中断重放及旧 lease 反例 | +| 人的注意力/UX | 首次有效成果时间、每个已验收成果的人工介入/决策次数、阻塞定位时间 | 本地与 Lark 真实旅程；授权边界与未测试入口分别记录 | +| 资源/规模 | host/provider 并发、队列 p50/p95、成功吞吐、tokens/费用/存储、成本/成果 | 区分观测/估算/未知、registered/active；冻结负载、预算、价格来源和样本窗口 | +| 可靠性/安全 | stale/越权拒绝、重复效果、RPO/RTO、恢复时延、隔离/删除结果 | 故障注入 + 隔离真实 backend/host；备份恢复与密钥撤销演练 | +| 工程/采用 | 兼容与升级成功、模块/bridge 简化、复现时间、独立首次/重复使用、支持成本 | 发布 artifact 而非只验源码；公开脱敏案例、可追溯反馈；不凭安装数宣布 PMF | + +不预先发明未经测量的性能数字。每个实验/试点开始前，由对应 owner 固定目标阈值、基线、预算、停止条件与证据范围；结果出炉后改变阈值应作为新实验。G4 correctness 要求无重复受保护效果和过期/越权提交，性能/成本阈值另行测量资格化。 + + +## 4. 全部 RFC 的落位与下一步 + +下表覆盖范围基线目录内的 **30 个主 RFC**，中英镜像合并计数；本总纲是新增的第 31 项。它同时记录已接受、局部实现、研究和 Held 方向，不表示全部立即开工。状态来自 RFC/现有 reference 与重点源码核对；除第 8 节外，未做每个子系统的完整运行资格。 + +| RFC | 工作流 | 当前边界 | 下一切片 / 验收要求 | +| --- | --- | --- | --- | +| [Agent Loop Effect Interpreter](agent-loop-effect-interpreter-v0.zh-CN.md) | S2 | Accepted；核心已实现，继续采用 | P0：复用 effect/recovery，先补 R1 部分提交反例，保持 replan ACK domain-local | +| [TypeScript Control-Plane Migration Direction v0](typescript-control-plane-migration-v0.zh-CN.md) | S2 | Accepted；整笔事务迁移中 | P0/P1：R1–R4 热事务优先；T0–T4 caller/删除/成本证据；不是百 Agent 前全量重写 | +| [Semantic Vocabulary Convergence and Commit-Time Drift Checks (v0)](semantic-vocabulary-convergence-v0.zh-CN.md) | S2 | Draft；registry/inventory/drift 与后续 typed 切片存在 | P1：按语义角色收敛 vocabulary；盘点真实 producer/consumer；不凭枚举同名合并，schema 改动单独审阅 | +| [LoopX Shared Control-Plane Authority and Pluggable State Providers (v0)](shared-goal-authority-state-provider-v0.zh-CN.md) | S2/S3/S7 | Draft；store、局部事务和 service admission 基础已存在 | P1→P2：R5 本地 D1–D3；R6 认证跨 host；真实 backend/soak/恢复资格后才晋升 | +| [Shared Goal Alignment and Governed Amendment Protocol (v0)](shared-goal-alignment-and-governed-amendment-v0.zh-CN.md) | S3 | Draft；Stage 1/2，完整 intent/commit 未闭合 | P1：R4 一个 work-graph amendment class；CAS/lease impact、冲突及丢响应回执 | +| [Goal Direction Baseline (v0)](goal-direction-baseline-v0.zh-CN.md) | S3/S6 | Draft；只读设计 | P1：合成 fixture 验同 Agent/current revision 的材料阅读；不写 Vision、不自动建 Todo | +| [Goal Artifact Lifecycle Projection (milestone / guard / next-transition) v0](goal-artifact-lifecycle-projection-v0.zh-CN.md) | S3/S5 | Draft；只读设计 | P1：从现有 typed facts 显示 milestone/guard/next transition；不加流程引擎 | +| [Capable Agent Manager and Semantic Work Handoff (v0)](capable-manager-semantic-handoff-v0.zh-CN.md) | S1/S3 | Draft；profile/intake 局部交付，M1–M4 未完整验收 | P0→P1：R1/R2 真实团队，R3 语义 peer 协作与持久回报；接续矩阵及 A1–A20 | +| [Manager runtime profile v0](manager-runtime-profile-v0.zh-CN.md) | S1/S4 | Draft；private Codex profile 已有，通用资格未完成 | P0：真实工具/会话/恢复与权限分级；runtime label 不代替资格 | +| [DSH / Pi: L1 Observation and Managed Runtime Selection](harness-selection-dsh-pi-v0.zh-CN.md) | S4 | 持续选型记录；局部 runtime 与 team card 证据 | P0：沿已合格 binding 验 R2；按 harness/model/profile/host 记录资格，不据一次 smoke 统一晋级 | +| [Explicit Todo continuation: Stage A](cross-session-memory-substrate-v0.zh-CN.md) | S3/S6 | Stage A 已交付；文件名不代表通用 memory substrate | P1：R3 复用 prepare/inspect/adopt；同机无 lease 限制保留至新接续路径验收 | +| [Agent Session Execution Modes (v0)](agent-session-execution-modes-v0.zh-CN.md) | S4 | Draft；attached binding/broker/fence 局部实现 | P0→P2：一个 binding 一个 executor，managed supervision，再做跨 host admission；禁止静默模式切换 | +| [Single-Owner Local Daemon (v0)](single-owner-local-daemon-v0.md) | S4/S10 | Draft；现有 Desktop ownership repair 不等于 loopxd | P1：按 service-profile 唯一 owner/readiness/drain/restart 验最小组合；无第二 scheduler | +| [LoopX Desktop Execution Frontends v0](desktop-execution-frontends-v0.zh-CN.md) | S4/S5 | Draft；attached/managed/UI 基础存在，统一旅程未完整验收 | P0→P1：本地设置→绑定→团队→修订→恢复→回报，packaged frontend 实测；保留直接 worker 对话 | +| [Goal Channel Collaboration v0](goal-channel-collaboration-v0.zh-CN.md) | S5 | Draft；Lark vertical 局部已交付 | P1：team card/回报/幂等/受众实测；Goal channel 与 Agent session binding 不混同 | +| [Provider-Neutral Turn-Start Inbox Hook v0](provider-neutral-turn-start-inbox-hook-v0.md) | S3/S8 | 显式配置下已实现 | P0 硬化：有界读→语义 triage→ACK/replay；默认关闭与 provider 私有 cursor 保持 | +| [Provider-Neutral Post-Writeback Capability Hooks v0](provider-neutral-post-writeback-capability-hooks-v0.zh-CN.md) | S3/S8 | Draft；periodic-report 首个 vertical 已实现 | P1：R3 返回/后继复用 durable intent；hook 失败隔离，不能加入主事务或直接执行 effect | +| [Agent IM, LoopX, And OpenViking Collaboration v0](agent-im-openviking-collaboration-v0.md) | S3/S6/S8 | Draft；三 owner 集成仍待资格 | P1/P2：IM 投递、LoopX work authority、OV context 分离；断线重放/权限撤销/来源失效 | +| [Per-Goal Usage, Token, and Cost Surfacing v0](goal-usage-token-cost-v0.md) | S7/S5 | Draft；Codex aggregate/cost 展示已有切片 | P0 观测→P1 多 provider：未知不作零、重复扣费去重、价格来源/时效；usage 不自动授权预算 | +| [Intelligent Review and Dynamic Presentation Surfaces v0](intelligent-review-presentation-surfaces-v0.zh-CN.md) | S5 | Draft；typed proposal 输入存在，通用 compiler 未交付 | P1：一个真实决策帧纵切，状态 stale 与 optimistic rollback；减少无意义二次确认 | +| [Human Attention Wishlist v0](human-attention-wishlist-v0.zh-CN.md) | S5/S11 | Draft；Held | P3：第二个重复真实需求出现才重开；sidecar 不改变 gate/quota/调度 | +| [Human-confirmed domain operations (v0)](human-confirmed-domain-operations-v0.zh-CN.md) | S8/S9 | Draft；proposal only | P2：模拟 adapter 的一次不可变确认→effect→对账→原路回报；金融 provider 独立包，不扩普通协调权限 | +| [Research Exploration Control Plane v0](research-exploration-control-plane-v0.zh-CN.md) | S11/S3 | Draft；M2 composition/successor 局部实现 | P1：observation/write-time gate/closure basis 独立验证；自选模型和推断触发继续 defer | +| [Hierarchical Agent Stride Control v0](hierarchical-agent-stride-control-v0.zh-CN.md) | S11/S7 | Draft；M1 只读观测 | P2：matched shadow stride 实验，定义代价与事件；不直接改变生产节奏 | +| [Post-Outcome Memory Utility Attribution v0](post-outcome-memory-utility-attribution-v0.zh-CN.md) | S6/S11 | Draft；Stage 1 verified-outcome 绑定 | P1 只读 reducer→P2 pilot：区分 recalled/applied/utility，归因不自动改 ranking | +| [Obelisk Session Evidence Provider v0](obelisk-session-evidence-provider-v0.zh-CN.md) | S6/S8 | Draft；可选只读评估 | P2：显式 gap recall、来源与权限可解析、关闭不影响主流程；不当 work authority | +| [Frontier Science Research Program v0](frontier-science-research-program-v0.zh-CN.md) | S11 | Draft；十轨研究提案 | P2：优先 sequential evidence/continuation/stride；T01–T10 按现有 owner、冻结实验与升降级门槛 | +| [Long-Horizon Harness Benchmark and Research Program v0](long-horizon-harness-benchmark-research-program-v0.zh-CN.md) | S11 | Draft；active research program | P1 持续：ALE/LHTB/DeepSWE 原生结果、matched arms、成本/恢复，研究环境不进入产品运行面 | +| [Benchmark Study Upload and Dashboard Projection v0](benchmark-study-upload-dashboard-v0.md) | S11/S5 | Draft；manifest/upload projection 提案 | P2：紧凑 public-safe study→readback，保留 benchmark-native score authority；显式 opt-in upload | +| [Long-Running Agent Reliability Diagnostics and Governed Delivery v0](long-running-agent-reliability-diagnostics-governed-delivery-v0.zh-CN.md) | S10/S13 | Draft；L1 default-off 原型与 DSH event adapter 存在，P0 未验收 | P1：C0 adapter fidelity/C1 non-interference/overhead；再讨论 L2 advice/L3 governed seams/L4 adoption | + +共享权威的[证据 companion](shared-goal-authority-state-provider-v0-evidence.zh-CN.md) 属于 S2/S10 的 backend/soak 资格；[RFC 模板](TEMPLATE.md) 和[索引](README.md) 属于 S12 的维护合同，不作为额外产品能力。未来新增主 RFC 必须补一行，删除/合并必须保留替代指针；历史文件名不能提升交付成熟度。 + +## 5. 多 LoopX Agent 的架构与协作验收 + +```mermaid +flowchart TD + UI[本地前端 / Lark] --> M[持久管家 Agent] + M --> C[共享请求 / 判断 / 结果] + C --> K[TS Goal / Todo / lease / quota / effect owner] + K --> A[已选择的 authority provider] + K --> H[managed supervisor / attached adapter] + H --> L[本地 Agent] + H --> R[云端 Agent] + L --> K + R --> K + K --> C + C --> O[持久 outbox / 受众投影] + O --> UI +``` + +这张图是目标依赖图，不能读作所有接缝已经实现。 + +| 边界 | Owner / 落位 | 禁止的替代权威 | +| --- | --- | --- | +| 用户意图与共享修订 | alignment RFC 的 Goal intent/amendment owner | 聊天摘要、计划 digest、管家人格或 provider revision 直接批准修订 | +| 计划、依赖、claim、lease、quota、终态 | 既有 typed control-plane bounded contexts | 新增管家 task DB、Python 决策镜像、host-local 工作真相 | +| 请求、接收方判断、结果关系 | 从 `manager_context` 收敛的 collaboration 边界；manager→worker 与 worker→worker 共用 | 用消息 sent 表示 adopted/completed，或复制 Todo 状态机 | +| 进程与会话 | session mode + 实际 host adapter/supervisor | 根据在线 presence 接管；managed/attached 静默切换 | +| 持久化与跨主机准入 | `AuthorityStore` 与所选 provider/service | Agent 直写数据库，或把所有 Goal 状态随意塞入 coordination head | +| 显示与回传 | packaged frontend、Lark adapter、已有 outbox | 前端/Lark 各存一份计划、权限或运行状态 | + +本次只修改设计文档，不新增 capability/provider。后续 R1/R3 优先扩展既有 work-items/collaboration owner；runtime profile 复用 `manager_runtime`，执行器选择复用 `steward_executor`，会话生命周期复用既有 controller。云端 provider adapter 若独立分发，归 extension/package；generic registration/lifecycle 才归 `loopx/extensions/`。每个实现 PR 先写 placement rationale。 + +“管家协调”允许逻辑上的目标分解、优先级建议、委托和综合；`peer_v1` 不禁止这种产品角色，但禁止因角色获得单方写入、抢占或提权。跨多个 Goal 的宏观目标应通过已有 Goal 关系和有范围请求关联；跨 Goal 依赖或汇总验收若缺少 owner，先交付一个有真实 caller 的有界合同，不能先造全局调度 DSL。 + +### 多个 LoopX Agent 的协作与 handoff 验收 + +协调对象是各自持有目标、承诺、frontier 与执行绑定的长程 LoopX Agent，不只是管家进程中的临时子任务。管家→worker 与 worker→worker 使用同一协作合同；worker 可以主动求助、提供结果、质疑依赖和提出重规划，无需每次让管家转发。管家负责整体推进与综合，不能成为每条消息或每次状态提交的串行中转站。 + +| 协作方式 | 持久关系与正确性 | 最小真实验收 / 路线 | +| --- | --- | --- | +| 并行分工后汇合 | 分支工作身份、输入版本、产物/验收引用及 join 条件属于 canonical work graph；消息完成不满足 join | 两个 worker 独立产物进入第三个集成步骤；一个失败时不误报整体成功，互不依赖分支继续。R2/R3 | +| 流水线依赖交接 | A 的已验收结果绑定 B 的输入；B 自行接受或报告缺口；上游修订使相关消费基线失效 | A→B→C 至少两轮推进，B 拒绝不完整产物并向 A 请求补充；不能只演示三条 Todo 同时创建。R2/R3 | +| 同伴求助与独立复核 | 请求/回复关联原工作与期望回报；保留各自已有承诺和受众边界；复核不自动取得提交权 | worker→worker 发起有界求助/复核，拒绝、延期和证据不可读都可回读，管家看到聚合卡点。R3 | +| 执行责任接续 | 语义包与所有权转移分别记录；接收消息不转移 claim/lease。活动工作交接由现有 work/lease owner 决定释放、重获或 fenced transfer | A 中断，B 根据允许转移的工作和持久上下文恢复；旧 A 返回不能重复提交。#4094 仅证明同机无 lease 的窄路径，不能冒充该完整能力。R3/R4/R6 | +| 跨 Goal / 跨 host 协作 | 显式授权的父子目标/请求、产物与回报关系；远端身份、访问和提交经 authority owner 校验 | 本地规划/集成与云端执行共享可验证依赖，断网重放、撤销权限及来源会话消失均不丢失回报义务。R6 | + +语义 handoff 的最小信息是目标/请求/工作身份、来源与接收者、意图及输入基线、目的与已作决策、约束/非目标、已完成和剩余工作、可授权解析的产物与证据、验收/回报要求及当前 claim/lease disposition。由已有合同承载这些事实，不能为表中每项新造一个 envelope。只交公共工作摘要，不复制原始 session 数据或私人推理轨迹。请求接收、工作采纳、效果提交、结果验收和答案送达是不同事实，复用各自 owner 的回执及幂等身份；超时不能凭空代表拒绝、失败或接管成功。 + +R2 的一条依赖必须通过真实 LoopX Agent 间的请求/产物交接完成；这是 P0 小团队退出门槛，不能推迟到百 Agent 阶段。R3 补齐通用 peer 协作、持久返回和恢复迁移；R4/R6 再资格化有 lease 与跨主机转移。所有阶段禁止循环等待无人发现：依赖环、拒绝、超时与失效输入需成为管家可见阻塞，沿已有 replan owner 求解，不能另建全局调度器。前端与 Lark 应显示请求→采纳→工作→产物→验收→回报的关系和当前阻塞，不能只显示 Agent 在线数或消息历史。 + +## 6. 核心交付路径：R1–R7 执行卡 + +| 卡 | 优先级 / 可验收结果 | 硬前置 | 可同时推进但无需等待 | +| --- | --- | --- | --- | +| R1 | P0：确认内容与工作落盘一致，失败/重试可恢复 | 当前 main + F1–F4 回归 | TS 其余事务、provider 晋升 | +| R2 | P0：一个管家驱动 2–3 个已绑定 managed worker 完成连续工作 | R1；选定 runtime/profile 的真实资格 | 通用 collaboration 全迁移、PostgreSQL | +| R3 | P1：语义交接与自动回报，重启后不用人追问 | 现有 inbox/outbox；通用 producer 依赖事务迁移 | 早期正文/传输恢复可与 R1/R2 同期 | +| R4 | P1：共享意图/工作基线与受治理修订形成闭环 | alignment Stage 1/2、相关 TS 事务 | 不阻塞不改变共享意图的 R1–R3 | +| R5 | P1：本地 durable authority + 长程存储资格 | T0–T3 受影响事务、D1/D2/D3 | 与 R1–R4 同期准备，不把全部 TS 重写设为前置 | +| R6 | P2：本地与云端使用同一权威、可恢复执行 | R2/R3；所选 shared profile、认证服务与相关 R4 合同 | PostgreSQL service 工程可早做；不得提前晋升 | +| R7 | P2：分级扩到 10 / 30 / 100+，有容量和恢复证据 | 对应规模的 R1–R6 闭合 | 分页/性能诊断可早做，不以大 prompt 或提高 cap 代替设计 | + +这些优先级是产品推进次序，不改变现有 Goal 的运行 quota，也不授权启动实验或云端资源。安全的本地小团队使用已支持的 authority profile，无需等待新 provider；改变 profile 或保留策略时，原有真实 backend、soak 与显式晋升条件继续是硬门槛。 + +### R1：可靠的团队计划提交 + +- **真实入口与 owner：** `ChatActionService`、受治理 proposal、canonical Todo writer，以及前端的确认/回读；Lark 有对应入口时使用同一服务。 +- **先复现：** F1–F4；另外覆盖相同 text 的不同 lane、已有 Todo 在 retry 前完成/修改、两个确认并发、receipt 写入后响应丢失。 +- **最小完整修改：** 对计划字段逐个明确是执行约束、持久验收引用还是 advisory。priority 通过现有 Todo 合同保留；quota/stop 只能消费已有 policy owner，未支持的强制项须在确认前报不支持，不能只存一份 JSON。保留 lane→Todo→acceptance 的关系。 +- **事务要求：** 基线绑定相关 Goal/授权/工作事实，在 commit 时复验；不能只 hash 整个 registry。选用已有可支持的整笔事务，或有逐 lane 身份/receipt、持久恢复游标及执行屏障的可恢复流程，明确原子性边界。不能因 API 名字叫 settle 就声称原子。复用 Effect recovery，不建第二 scheduler。 +- **退出：** 独立回读证明承诺保留；all-gap/partial/stale/rejected/committed 区分；中断后恢复不复制、不扩大工作，原接收界面显示精确结果。新增独立语义反例，不能只断言一行存在。 +- **回滚：** 停新计划 producer，保留可读旧预览/receipt 及未完成对账；不删除已经形成的工作。 + +### R2：小团队持续执行 + +- **入口与 owner：** 现有 session binding、Turn driver、quota/scheduler、manager runtime 配置；复用已有设置 editor，不新建 profile。 +- **交付：** 区分 registered、可接收请求、已绑定、可启动、正在执行和阻塞；计划 ready 不能暗示正在工作。对已授权且具备资格的 managed binding，沿现有 launch/supervision 路径启动下一有界 Turn。attached host 继续由其原 host 驱动。 +- **资格：** 用真实选定 runtime 执行至少两轮“取工作→产物→独立验证→settle→下一工作”，中断并重启一个 worker，另一个保持推进；验证旧执行器返回时的 fence、取消及停止后不再启动。DSH 单段 read-only Chat 与 Codex `trusted_owner` 分别验收，不互借资格。 +- **退出：** 2–3 worker、一个依赖、一个故障、一个方向补充，经 packaged frontend 查看，同一状态能从 CLI 读回；Lark 的授权入口能读到对应受众可见反馈。无 Lark 实测则该入口标为未验收。 +- **回滚：** 停止新增 admission，drain 已接受工作并保留绑定/receipt；不能借 attached fallback 保持“在线”。 + +### R3：语义请求与自动回报 + +- **Owner：** 管家 RFC M2/M3；从已有 `manager_context` request/tracking/return 迁移到单一 typed collaboration 事务，纳入 #4094 adapter。 +- **交付：** 交接保存目的、决策、约束、证据引用和期望回报；receiver 读取后自行 adopt/defer/reject/replan。用独立事实表示 accepted work、result committed、answer delivered；从已有 outbox 自动回传。 +- **退出：** manager→worker 和 worker→worker 两个真实 caller，补充消息、来源会话消失、超长答案、重复回调、发送成功但 ACK 丢失及传输重启；同一结果在 CLI、packaged frontend、Lark 回读一致且受众隔离。普通已授权工作不增加第二次人工确认。 +- **迁移/回滚：** characterization 先行，记录旧 writer/reader 映射与删除收益；关新 producer 后可 drain 旧请求。不要同时保留两份可写生命周期。 + +### R4：共享目标对齐与演化 + +- **Owner：** alignment RFC Stage 3–5；TS Goal/work-graph owner。 +- **先收口：** `intent_basis` 仅是现有 source-facts digest；保留兼容 reader，真正引入 intent revision 时单独版本化并盘点 producer/reader。不得改名后假装历史回执拥有新语义。 +- **交付次序：** 明确 root intent/permissions/acceptance/stop 的 authority；先做保持 intent 的一个 work-graph commit class。普通 Todo 编辑仍走现有 owner，不能给每次 add 强加 amendment 流程。跨共享承诺修改才消费有范围 policy、必要的 verifier、精确 CAS 与 lease-impact disposition。 +- **退出：** 两个 peer 在同基线竞争最多一个冲突提交成功；响应丢失返回原 receipt；已租用工作明确继续/重基/停止；所有受影响 frontier 更新或被 gate。扩张权限拒绝；无关 peer 继续，不等待全员投票。 +- **回滚：** 停该 commit class，新 proposal 保留且不产生 effect；不恢复旧 revision 或放松 fence。 + +### R5：TS 收敛与本地持久化 + +- **Owner：** TS RFC T0–T4、shared-authority D1–D3；保留两套编号及原门禁。 +- **选择规则：** 优先迁移 R1–R4 热路径的一笔完整事务或恢复生命周期，附前后 caller/owner/crossing 表、实际删除和性能证据。不要继续按单字段增加 Python→TS RPC；不要重建已合入的 Todo update。 +- **交付：** 用已选本地 profile 验证完整来源读取、单向 Markdown 投影、event/receipt 保留、重启恢复、容量与长期成本；source 失败不能回退 legacy。R1 不能把大计划正文塞入 coordination head。 +- **退出：** 相关真实 CLI/backend、不可变 baseline 与候选对照、负例/mutation、三臂演练及适用 D2 至少十日 soak；D3 切换保留明确批准。此次审计没有执行新的 soak，也未晋升 provider。 +- **回滚：** 按已审阅的 fenced export/import 和 schema-aware downgrade，不能靠替换二进制恢复旧写权威。 + +### R6：本地与云端汇合 + +- **Owner：** shared-authority provider/service、session host adapter、collaboration；基础是已有 PostgreSQL admission/identity-rotation seam，不重写 store。 +- **交付：** 真正的认证传输、tenant/Goal/actor 权限、host identity 和 capability admission；跨主机 request/receipt/wake 只通过各 owner。处理断网、租约过期、旧 worker 回归、service restart/restore incarnation、ambiguous commit。 +- **退出：** 至少两个真实 host（含一个云端 worker）在隔离 tenant 上协作；错 tenant/actor、撤销与 split-brain 负例通过；共享预算与 admission 有明确 owner，不能声称本地 quota 就是分布式资源预留。 +- **回滚：** 停远端 admission，保留已提交事实并 drain；不导入或重绑另一 host 的原始 session 数据。 + +### R7：百 Agent 资格化 + +- **Owner：** 现有目录/投影、quota/scheduler、authority/provider 和 host supervisor；管家只消费有界摘要、分页及按需证据。 +- **交付次序：** 先让第 25 个及以后注册 Agent 可通过稳定身份/分页发现，再在 10、30、100+ cohort 验并发。保留 8-lane 计划的有界合同，较大工作按可追溯批次/子目标组织；不能只改成 100。 +- **调度：** 合并唤醒、退避、每 provider/host admission、预算与公平性、隔离失败；已有 scheduler 是唯一调度 owner。采用完成/失败/需决策事件驱动关注，周期读回只作修复。不得让每个 Agent 每轮把所有同伴状态放进 prompt。 +- **退出：** 每一级记录注册数/活跃数、成功/失败/未测、p50/p95 排队与恢复时间、首次有效动作时延、重复效果、过期写拒绝、成本/已验收产物、人工介入率、队列/历史增长。进入实验前冻结预算、负载与 SLO；不在结果出来后调阈值。 +- **最终验收：** 用户从两个入口下达与修订宏观目标，本地/云端异构 worker 持续交付依赖产物；管家自行发现卡点、按授权重规划、回报并最终按独立验收关闭目标。无重复受保护效果、无过期/越权提交；性能目标须由真实测量资格化。先完成合成压力再运行明确授权的真实 cohort，本计划不启动百个付费 Agent。 +- **回滚：** 降低并发/admission，保留注册、历史和在途对账，不降低 correctness 门槛。 + +## 7. 执行与审阅合同 + +每次只选择一个已满足前置条件的、完整可验收切片。先查最新 main 与 canonical Todo，已有工作补验证，已有任务更新并保留 supersedes 关系，不能凭本文件创建重复任务。执行卡是静态路线，实际负责人、状态、PR 和阻塞保存在 LoopX Todo。 + +实施 Todo/PR 必须回答： + +1. **结果：** 用户做什么、前后行为是什么、属于 R 卡及原 RFC 哪个验收 ID。 +2. **事实：** baseline/head、已交付依赖、未闭合字段/状态；不以 PR 标题代替代码。 +3. **归属：** 一个 semantic owner、provider/profile、真实 caller；哪些旧 decision/writer 被删除，哪些因真实兼容调用保留。 +4. **不变量：** 先写独立 expected outcomes，再做 characterization/负例；现状有错先修规则，不刷新 golden 掩盖。 +5. **故障：** 无副作用拒绝、并发、超时、部分完成、crash/replay、stale basis、default-off parity；按涉及边界选取。 +6. **产品：** CLI/managed、packaged frontend、Lark 的入口、状态回读和反馈；不需要 companion 修改时给出已核实原因，未测就写未测。 +7. **交付：** 精确路径 staging、DCO、相关 canary、公开边界扫描、PR；保留真实权限与 first-screen review gate。 +8. **接续：** 一个可执行后继、依赖/阻塞变化、回滚办法；禁止“字段存在/测试通过/有回执”直接推出完整里程碑通过。 + +能力较弱的执行 Agent 可以在这套合同内修复已定义反例和进行机械迁移。新增 authority、状态机、跨 host 身份、schema 不兼容变化必须由相应 owner 审阅；审阅的是精确 diff、规则及证据，不是 Agent 自评或模型等级。bounded future-facing pass 优先删除重复知识；较大的邻接重构只登记有范围后继。 + +推荐首批：R1 的语义与回读修复作为一个内聚批次；随后完成同路径的持久恢复与源基线约束，再验 R2 小团队闭环。R3 的既有结果投递修复和 R5 已选 profile 资格准备可由不同任务同期执行，不能用它们掩盖 R1 阻塞。 + +## 8. 管家近期交付审计与证据 + +当前 main 已具备管家通道、执行器配置、团队计划确认、首批 Todo 物化和本地 peer directory。近期交付有实际价值，保留了 canonical Todo owner、同 Goal 校验及受众边界；但还没有证明“管家协调一组持续工作的 Agent，直到目标验收并自动回报”。现有测试主要证明局部链路，团队承诺的部分语义在落盘时丢失，错误结果与成功结果也没有完整区分。 + +目标是：用户从本地前端或 Lark 表达目标、补充约束和调整方向，管家持续调查、组织工作、协调本地 managed 与云端 Agent、处理失败并汇总可验证成果。规模目标为上百个注册 Agent，随后资格化上百个同时活跃的 Agent；注册数量、活跃执行器数量和已验证吞吐必须分别报告。 + +推进标准从“合入了多少字段和 PR”改为“又有哪条用户旅程可以独立复现”。本路线评价提交及实现，不从提交者或模型名称推断质量，也不把相邻作者的工作全部归给同一个 Agent。 + +### 已有进展及其边界 + +| 领域 | 可复用的事实 | 当前不能据此声称 | +| --- | --- | --- | +| 管家入口与配置 | `steward_executor` 机器配置、通道执行器读回；`manager_runtime` 的 Codex 私人 `trusted_owner` profile；#4510、#4557 | DSH 单段 Chat 已成为同等强能力、持久工具会话 | +| 团队入端 | #4519/#4522/#4524/#4535/#4538：有界计划、Goal 身份、注册校验、Todo owner、回执；#4547/#4548/#4552：前端确认与浏览器 fixture | 团队已启动、预算已生效、已完成 Goal-intent 对齐，或已验证 Lark 同路径 | +| peer 发现 | #4544：同 Goal 本地 directory，24 行上限，明确 presence/lease coverage 缺口 | 100 Agent 可完整发现；远端身份可信；可据此接管或取得 lease | +| TS 内核 | Todo、lease、quota/replan 等已有 typed owner 与部分整笔事务切换 | 所有 writer 已迁移；新增 Python 编排天然符合 replacement-first | +| shared authority | `AuthorityStore`、File/SQLite 候选与 PostgreSQL store/service admission 接缝、恢复及 conformance 基础 | 已部署 authenticated 跨主机服务；已晋升任一默认 provider；分布式 quota 已成立 | +| alignment | Stage 1/2 source-basis reader 与 amendment admission/retention | `source_basis_digest` 是完整 Goal intent revision；Stage 3 自动 commit 已成立 | +| managed | `turn run-once`、managed step、attached broker 及单执行器围栏已有实现 | 有界片段等于无人值守长程监督；每个注册 Agent 都有健康执行器 | + +### 已复核的问题 + +以下是精确基线上的合成 fixture 结果，不含线上用户内容。F1–F4 用现有 `ChatActionService.preview/apply` 及隔离 Goal 复核；F4 只在第二次 Todo 写入前注入失败，其余走实际本地 Todo writer。F5–F7 是源码/合同审计。它们是修复优先级，尚未在本次文档修改中修复运行时。 + +| ID / 优先级 | 触发、结果与影响 | 定位与修复卡 | +| --- | --- | --- | +| F1 / P0 | 计划声明 P0，apply 成功，`list_goal_todos` 中该 Todo 的 `priority` 为 null。`acceptance`、quota envelope、stop condition 也未进入该 apply 的工作/执行约束路径。用户确认的计划与实际工作不一致。 | `governed_transition_proposal.py::_apply_team_plan` 只传 text/action/claim；`team-plan-preview.ts` 展示这些声明。→ R1 | +| F2 / P0 | 预览后改变 active-state 的 objective、保持 registry 不变，旧计划仍返回 `team_plan_applied`。预览锁的是 registry bytes，未锁 Goal 意图或相关工作/授权基线。 | `chat_actions.py::_registry_fingerprint`、`_apply_team_plan`。`_intent_basis_for` 在 apply 时才读取且可省略；不是 commit precondition。→ R1/R4 | +| F3 / P1 | 全部 lane 未注册、零 Todo 创建，仍返回 `team_plan_lanes_already_present`、`projection_verified: true` 和空 todo id。成功文案掩盖了缺人。 | `chat_actions.py::_apply_team_plan`；现有 gap 测试只断言空列表。→ R1 | +| F4 / P0 | 第二条 lane 写入失败后，第一条 Todo 已存在，Chat proposal 为 `applying` 且没有完整 receipt。手动 retry 可以补齐；没有证明逐 lane 持久对账、自动恢复、执行前屏障或中途工作被修改后的幂等性。 | 多次 `add_goal_todo` 后才 checkpoint；Chat caller 用空 receipts 和 no-op checkpoint。→ R1 | +| F5 / P1 | `intent_basis` 名称与“规范意图修订”文案过强。alignment owner 明确其 digest 仅覆盖 source facts/事件轴及适用的 Todo revision；它不是完整 intent envelope。 | `goals/shared_goal_alignment.py` 模块合同；harness 选型文档旧团队段。→ 本次文档纠偏 + R4 | +| F6 / P1 | `ready` 只证明注册和 action kind 通过校验；不检查 runtime binding、实际工具资格或已配置执行容量。gap reason 的存在不证明这些条件都被机器检测。 | `validate_steward_team_plan_preview`；`agents/directory.py` 明示无 presence provider。→ R2 | +| F7 / P1 | 管家主 RFC 仍称提案，选型 RFC 仍说无前端确认面，新增交付又留在后续段落；共享权威开头仍说 service admission 未交付。后续 Agent 会重做已有工作或跳过真实缺口。 | 本次统一检查点、压缩旧进度段并建立本路线；不得靠再追加一段更晚日期维持双重真相。 | + +评估结论：局部实现与边界意识值得保留；跨模块的语义追踪、故障恢复、现状维护和完整旅程验收需要补强。当前适合有限范围试用与硬化，不能以计划确认、一次回答或测试数量宣传百 Agent 长程协调已就绪。 + +在上述基线、source-checkout Python 3.13.13 下执行以下两组，分别 **69 passed** 和 **108 passed**： + +```sh +uv run --extra test python -m pytest -q tests/test_steward_team_plan_preview.py tests/test_steward_team_plan_apply.py tests/test_chat_team_plan_action.py tests/test_manager_team_plan_guidance.py tests/test_manager_channel_binding.py tests/control_plane/test_peer_agent_directory.py tests/capabilities/test_steward_executor_machine_defaults.py tests/capabilities/test_manager_runtime_profile.py +uv run --extra test python -m pytest -q tests/test_turn_managed_executor_binding.py tests/test_loopx_turn_managed_step.py tests/test_attached_session_cli.py tests/test_manager_context_handoff.py tests/test_manager_context_roundtrip.py tests/control_plane/test_shared_goal_alignment.py tests/control_plane/test_shared_goal_alignment_cli.py +``` + +这 177 项不是全仓测试，也不是云端、真实模型、packaged browser、Lark 或 PostgreSQL 现场资格。#4552 的 browser fixture 与选型 RFC 记录的既有现场读取为历史证据，本轮未复跑，不能推广到团队执行验收。F1–F4 的复现步骤在上表固定，实施时将对应的独立语义反例加入已有测试，不提交本次临时诊断脚本或私有运行日志。 + +维护规则：本页只更新当前判断、卡的边界及通过证据；历史长账本移至 companion，领域 RFC 的状态与这里同步。领域状态/权限/迁移规则发生冲突时，停相关实现并修正文档，不用本路线覆盖已接受的 authority 合同。该文档合并表示路线可发现，不表示 R1–R7 已完成或 Draft 决策已晋升。 diff --git a/docs/architecture/rfcs/manager-runtime-profile-v0.md b/docs/architecture/rfcs/manager-runtime-profile-v0.md index 1ea518a5b8..cfdac324ee 100644 --- a/docs/architecture/rfcs/manager-runtime-profile-v0.md +++ b/docs/architecture/rfcs/manager-runtime-profile-v0.md @@ -63,6 +63,10 @@ This slice implements only the private-owner M1 journey in It does not implement the M2 collaboration request, the M3 outbox, or treat manager Session fields as work, request, or delivery authority. +### Implementation and successor (2026-09-16) + +`43d362532` contains the machine profile, controller integration and focused tests; passing them here is not deployment or full M1 qualification. The `restricted` default, Codex-only private `trusted_owner` and external-audience downgrade remain. Selecting DSH does not inherit that capable profile. Follow [roadmap](loopx-overall-roadmap-v0.md) R2 for actual tool/session/continued-execution and settings readback, without a second machine configuration. + ### Acceptance 1. A default installation starts `restricted` with no implicit grant. diff --git a/docs/architecture/rfcs/manager-runtime-profile-v0.zh-CN.md b/docs/architecture/rfcs/manager-runtime-profile-v0.zh-CN.md index 0822d2120b..60f8a28bf3 100644 --- a/docs/architecture/rfcs/manager-runtime-profile-v0.zh-CN.md +++ b/docs/architecture/rfcs/manager-runtime-profile-v0.zh-CN.md @@ -52,6 +52,10 @@ profile 或权限状态，但当前外部 audience 会明确降级为 `restricte 的 M1 私有 Owner 旅程，目标验收为 A1–A3/A12。它不实现 M2 collaboration request、M3 outbox，也不把管家 session 字段当成工作、请求或送达权威。 +### 实现与后继（2026-09-16） + +`43d362532` 已有 machine profile、controller 集成与聚焦测试；本次复跑通过不等于本机部署或完整 M1 资格。`restricted` 默认、仅 Codex 支持私人 `trusted_owner` 及外部受众降级保持。DSH 通道选择不继承该强能力 profile。按[统一路线](loopx-overall-roadmap-v0.zh-CN.md) R2 补真实工具/会话/连续执行与设置读回；不得新建第二份机器配置。 + ### 验收 1. 默认安装启动 `restricted`，没有隐式授权。 diff --git a/docs/architecture/rfcs/shared-goal-alignment-and-governed-amendment-v0.md b/docs/architecture/rfcs/shared-goal-alignment-and-governed-amendment-v0.md index e4e97ac1d3..c7d2b74c13 100644 --- a/docs/architecture/rfcs/shared-goal-alignment-and-governed-amendment-v0.md +++ b/docs/architecture/rfcs/shared-goal-alignment-and-governed-amendment-v0.md @@ -613,6 +613,12 @@ lane/proposal/stale-basis negatives and later qualifies the supported commit path. This RFC retains Stage 3–5 implementation and promotion ownership; manager readiness cannot silently mark those stages done. +### Steward execution integration (2026-09-16) + +[Roadmap](loopx-overall-roadmap-v0.md) R1 repairs team-plan source-basis preconditions; R4 supplies the product continuation for Stage 3–5. The current team receipt `intent_basis` only reuses `source_basis_digest`, a source-facts summary that does not cover the full objective/non-goals/acceptance/permissions/stop envelope. It may be absent and is not a CAS precondition. Do not claim full canonical intent binding. + +First connect existing commitments/work basis to commit-time validation. Then version intent in this owner and implement one intent-preserving work-graph amendment class with policy/verifier, lease impact, conflicts and receipt recovery. Ordinary Todo edits retain their writer rather than being forced into amendments. A steward may organize and synthesize peer work without gaining leader write authority. Stage 1/2 and the local 24-row directory exist; Stage 3, presence/lease epoch and pagination gaps remain explicit. + ## 10. Staged delivery 1. **Stage 0 — characterization and RFC.** Record own-lane, unclaimed, diff --git a/docs/architecture/rfcs/shared-goal-alignment-and-governed-amendment-v0.zh-CN.md b/docs/architecture/rfcs/shared-goal-alignment-and-governed-amendment-v0.zh-CN.md index a0b954601c..01d76c12de 100644 --- a/docs/architecture/rfcs/shared-goal-alignment-and-governed-amendment-v0.zh-CN.md +++ b/docs/architecture/rfcs/shared-goal-alignment-and-governed-amendment-v0.zh-CN.md @@ -526,6 +526,12 @@ proposal/admission 与提交不可用边界，无关工作继续。验收后， 随后验证已支持 commit 路径。本文保留 Stage 3–5 的实现与晋级责任；管家就绪不能 悄悄把这些阶段标为完成。 +### 管家执行衔接（2026-09-16） + +[统一路线](loopx-overall-roadmap-v0.zh-CN.md) R1 修复团队计划的源基线约束，R4 拥有本 RFC Stage 3–5 的产品接续。当前 team-plan receipt 的 `intent_basis` 仅复用 `source_basis_digest`；后者是来源事实摘要，不覆盖完整 objective/non-goals/acceptance/permissions/stop envelope。该字段可缺失且不是 CAS precondition；不得声称计划已绑定完整 canonical intent revision。 + +先把现有承诺/工作基线与 commit-time 校验接好，再在本 owner 版本化 intent 和一个保持 intent 的 work-graph amendment class，验证 policy/verifier、lease impact、冲突与 receipt recovery。普通 Todo 编辑继续走自己的 writer，不被强行升级为 amendment。管家可组织和综合 peer 工作，但不因此拥有 leader 写权威。Stage 1/2 以及本地 24 行 directory 已有实现；Stage 3 未交付、无 presence/lease epoch 和分页的部分继续显式列缺口。 + ## 10. 分阶段交付 1. **Stage 0 — characterization 与 RFC。** 记录 own-lane、unclaimed、 diff --git a/docs/architecture/rfcs/shared-goal-authority-state-provider-v0.md b/docs/architecture/rfcs/shared-goal-authority-state-provider-v0.md index d0b8a4ef45..7e446bdf44 100644 --- a/docs/architecture/rfcs/shared-goal-authority-state-provider-v0.md +++ b/docs/architecture/rfcs/shared-goal-authority-state-provider-v0.md @@ -15,13 +15,20 @@ - PostgreSQL baseline: the TypeScript Stage 2B candidate implements the store contract, transaction-local tenant context, forced row-level security, and bounded canonical commit admission, and has passed a real PostgreSQL 16 - transaction matrix. No shared authority service, runtime caller, principal - authentication/tenant authorization, measured capacity/retention profile, or - authority promotion ships yet + transaction matrix. Subsequent delivery adds in-process service admission, + principal/tenant verification injection points and restore-incarnation rotation. + Deployed authenticated transport, cross-host runtime callers, measured + capacity/retention and authority promotion are not established by those seams - Language note: the [Chinese version](./shared-goal-authority-state-provider-v0.zh-CN.md) and this English version are semantic mirrors. A difference between them is a defect. +## Persistence route for steward scale (2026-09-16) + +[Roadmap](loopx-overall-roadmap-v0.md) R5 reuses D1 projection, D2 real-backend/capacity/applicable ten-day soak and D3 fenced cutover. R6 connects the selected shared profile to authenticated local/cloud execution. R1–R3 can advance on supported profiles without waiting for PostgreSQL or whole-Goal default promotion. + +`e94759d88` adds [PostgreSQL service admission](../../reference/postgresql-authority-service-v0.md), with authentication/tenant verification injection and identity rotation. It is an in-process service boundary, not a deployed network service. The P lane should reuse it and finish transport, real identity policy, pool/cancellation/failover and operations qualification rather than rebuilding admission. R7 must separately report registration, active executors and measured capacity. Directory, presence, a plan or one source read grants no shared authority. Existing fail-closed source, receipt/replay and rollback contracts remain. + ## Current implementation checkpoint The machine-owned coordination projection now has one packaged, diff --git a/docs/architecture/rfcs/shared-goal-authority-state-provider-v0.zh-CN.md b/docs/architecture/rfcs/shared-goal-authority-state-provider-v0.zh-CN.md index 5e9d3dd8cb..873a9ddb2a 100644 --- a/docs/architecture/rfcs/shared-goal-authority-state-provider-v0.zh-CN.md +++ b/docs/architecture/rfcs/shared-goal-authority-state-provider-v0.zh-CN.md @@ -14,12 +14,18 @@ 或 authority promotion - PostgreSQL 基线：TypeScript Stage 2B candidate 已实现 store contract、 transaction-local tenant context、forced row-level security 与有界 canonical - commit admission，且已通过真实 PostgreSQL 16 transaction matrix；shared - authority service、runtime caller、principal authentication/tenant authorization、 - 实测 capacity/retention profile 与 authority promotion 均尚未交付 + commit admission，且已通过真实 PostgreSQL 16 transaction matrix。后续已交付进程内 service admission、principal/tenant 校验注入点 + 与 restore-incarnation rotation；真实认证传输部署、跨主机 runtime caller、 + 实测 capacity/retention profile 与 authority promotion 仍未由这些接缝证明 - 语言说明：[英文版](./shared-goal-authority-state-provider-v0.md)与本中文版互为 语义镜像；两者不一致属于缺陷 +## 管家规模化的持久化路线（2026-09-16） + +[统一路线](loopx-overall-roadmap-v0.zh-CN.md) R5 复用本 RFC 的 D1 投影、D2 真实 backend/容量/适用十日 soak、D3 fenced cutover；R6 再把所选 shared profile 接入认证的本地/云端路径。R1–R3 可在已支持 profile 上前进，不等待 PostgreSQL 或整 Goal 默认晋升。 + +`e94759d88` 已增加 [PostgreSQL service admission](../../reference/postgresql-authority-service-v0.zh-CN.md)，包含认证/tenant 验证注入与 identity rotation；它是进程内服务边界，不是已部署网络服务。后续 P lane 复用它，补 transport、真实身份策略、pool/cancellation/failover 与运维资格，不能从零重造 admission。R7 百 Agent 资格需独立报告注册数、活跃执行器和实测容量；目录、presence、管家计划或一次 source read 不授予 shared authority。既有 source-failure fail-closed、receipt/replay 和 rollback 合同保持。 + ## 当前实现检查点 machine-owned coordination 投影现已有一份由 Python 与 TypeScript 共享的、随包 diff --git a/docs/architecture/rfcs/typescript-control-plane-migration-v0.md b/docs/architecture/rfcs/typescript-control-plane-migration-v0.md index 8c7d7f8fb0..89b30e4790 100644 --- a/docs/architecture/rfcs/typescript-control-plane-migration-v0.md +++ b/docs/architecture/rfcs/typescript-control-plane-migration-v0.md @@ -14,6 +14,12 @@ --- +## Cross-RFC execution priority (2026-09-16) + +[Roadmap](loopx-overall-roadmap-v0.md) R1–R5 are current product consumers of T0–T4, not another migration ladder. Close one hot-path team confirmation/materialization/recovery transaction first: `governed_transition_proposal.py` still validates plans in Python and calls Todo per lane. Calling a typed Todo owner does not migrate the entire team transaction. + +Retain T0 caller/parity inventory, T1/T2 transaction/effect convergence, T3 complete-source consumption and T4 deletion conditions. #4472 is merged; inspect `todos/public_update.ts` and actual callers before rebuilding Todo update. Converge new team domain rules in existing typed work-items/collaboration ownership; Python retains input/IO adaptation. R1 independent counterexamples and real-path verification gate delivery. More leaf RPCs, enums or files are not migration payoff. Shared-authority retains D1–D3. + ## Current implementation checkpoint The projection-delivery stage now closes the cross-language boundary: typed diff --git a/docs/architecture/rfcs/typescript-control-plane-migration-v0.zh-CN.md b/docs/architecture/rfcs/typescript-control-plane-migration-v0.zh-CN.md index 88bba64be1..7f67f49f6c 100644 --- a/docs/architecture/rfcs/typescript-control-plane-migration-v0.zh-CN.md +++ b/docs/architecture/rfcs/typescript-control-plane-migration-v0.zh-CN.md @@ -13,6 +13,12 @@ --- +## 跨 RFC 的执行优先级（2026-09-16） + +[统一路线](loopx-overall-roadmap-v0.zh-CN.md) 的 R1–R5 是 T0–T4 的当前产品消费者，不另设一套迁移阶段。先闭合团队计划确认/物化/恢复热路径的一笔事务：`governed_transition_proposal.py` 仍在 Python 校验计划并逐 lane 调 Todo，不能把调用了 typed Todo owner 等同于整笔团队事务已迁到 TS。 + +保留 T0 caller/parity 盘点、T1/T2 事务与 effect 收敛、T3 完整来源消费、T4 删除条件。#4472 已合入，执行前核验 `todos/public_update.ts` 和实际 caller，不能重建 Todo update。新增团队领域规则应在现有 typed work-items/collaboration 归属中收敛；Python 保留输入/IO adapter。R1 的独立反例与 real-path 验证是交付条件；不以更多 leaf RPC、enum 或文件数量记迁移收益。D1–D3 仍由 shared-authority RFC 拥有。 + ## 当前实现检查点 投影交付阶段现已闭合跨语言边界：typed TypeScript mutation 结果与 Python diff --git a/docs/product/roadmaps/README.md b/docs/product/roadmaps/README.md index 528ba18953..58be58fd82 100644 --- a/docs/product/roadmaps/README.md +++ b/docs/product/roadmaps/README.md @@ -7,3 +7,7 @@ These documents describe staged proposals, not current runtime guarantees. - [Dreaming exploration lane](dreaming-exploration-lane.md) - [Experiment controller milestone](experiment-controller-milestone.md) - [SaaS opportunity assessment](saas-opportunity-assessment.md)（[中文版](saas-opportunity-assessment.zh-CN.md)） + +The [LoopX overall roadmap](../../architecture/rfcs/loopx-overall-roadmap-v0.md) +([中文版](../../architecture/rfcs/loopx-overall-roadmap-v0.zh-CN.md)) connects these +product explorations to all RFCs, core delivery gates and contribution streams. diff --git a/docs/project/technical-directions.md b/docs/project/technical-directions.md index e68a552a36..921b755ca5 100644 --- a/docs/project/technical-directions.md +++ b/docs/project/technical-directions.md @@ -43,13 +43,15 @@ strategic program. Their reliability work continues through the and the `control-plane` label. It is ongoing product hardening, not a competing source of direction. +Cross-domain ordering, complete RFC coverage and product acceptance are maintained in the [LoopX overall roadmap](../architecture/rfcs/loopx-overall-roadmap-v0.md). This page retains contribution routing; S streams, G milestones and R cards do not replace domain contracts or actual Todos. + ## Strategic Programs | Direction | Outcome | Stage | Start here | | --- | --- | --- | --- | | Long-Horizon Benchmarks and Evidence | Produce benchmark-native, reproducible evidence for long-horizon capability and use controlled tasks to study mechanisms. | Active research | [Tracker #3243](https://github.com/huangruiteng/loopx/issues/3243) · [RFC](../architecture/rfcs/long-horizon-harness-benchmark-research-program-v0.md) | | Reliability Diagnostics and Governed Delivery | Prove an observer-first product entry that diagnoses long-running workflows without changing agent execution, then adds authority only at accepted seams. | Draft product direction / delivery qualification | [RFC](../architecture/rfcs/long-running-agent-reliability-diagnostics-governed-delivery-v0.md) | -| Operator Surface and IM Integration | Make goals, sessions, decisions, evidence, and bounded collaboration legible through a coherent operator workspace. | Incubating on an integration branch | [Tracker #3244](https://github.com/huangruiteng/loopx/issues/3244) · [integration branch](https://github.com/huangruiteng/loopx/tree/frontend-control-plane-im-prototype-rfc) | +| Operator Surface and IM Integration | Make goals, sessions, decisions, evidence, and bounded collaboration legible through a coherent operator workspace. | Partial delivery / unified-journey qualification | [Tracker #3244](https://github.com/huangruiteng/loopx/issues/3244) · [integration branch](https://github.com/huangruiteng/loopx/tree/frontend-control-plane-im-prototype-rfc) | | Shared Goal Authority and Cross-host Coordination | Coordinate explicitly shared goals across hosts without turning a provider or host session into control-plane authority. | Draft contract / provider qualification | [Tracker #3245](https://github.com/huangruiteng/loopx/issues/3245) · [RFC](../architecture/rfcs/shared-goal-authority-state-provider-v0.md) | | Architecture and Research Incubator | Qualify architectural changes and research mechanisms before they expand production scope. | Mixed; see the portfolio below | [Tracker #3246](https://github.com/huangruiteng/loopx/issues/3246) · [RFC index](../architecture/rfcs/README.md) | @@ -72,7 +74,7 @@ official scoring, and unpublished comparisons remain maintainer-owned. ## Reliability Diagnostics And Governed Delivery -This product direction turns the broader commercialization thesis into a +A default-off L1 prototype and DSH event adapter exist in the [capability README](../../loopx/capabilities/reliability_diagnostics/README.md); C0/C1 and overhead qualification remain open. This product direction turns the broader commercialization thesis into a bounded entry offer. Its first operating level is a shadow observer between a native harness and full LoopX adoption: it consumes one-way events, writes an independent diagnostic ledger, and may not inject prompts, schedule, retry, @@ -89,13 +91,7 @@ service before the promotion gates pass. ## Operator Surface And IM Integration -The current frontend and IM work is an incubation program, not shipped `main` -behavior. The primary implementation package is -[#3167](https://github.com/huangruiteng/loopx/pull/3167), led by -[`@maxliux5`](https://github.com/maxliux5), on the -[`frontend-control-plane-im-prototype-rfc`](https://github.com/huangruiteng/loopx/tree/frontend-control-plane-im-prototype-rfc) -integration branch. [#3200](https://github.com/huangruiteng/loopx/pull/3200) -is a separate event-driven proposal currently under requested changes. +At `f1166e81e`, local steward chat, executor settings, team-plan confirmation, attached/managed foundations and partial Lark verticals exist on `main`. The complete cross-entry execution/recovery journey remains unqualified. [#3167](https://github.com/huangruiteng/loopx/pull/3167) and its integration branch are historical incubation inputs, not evidence that every current frontend is unshipped. Use the [Desktop RFC](../architecture/rfcs/desktop-execution-frontends-v0.md), selected release artifact and roadmap S4/S5 entrypoint qualification. Promotion to `main` follows this ledger: @@ -121,12 +117,7 @@ the authority itself. Agents do not connect directly to NoKV. Run history, status, quota, scheduler state, host sessions, and evidence retain their existing owners. -The next qualifying slice is provider-neutral: extract one compact -command/precondition/receipt/outcome core, qualify a file-backed provider on -the same `claim_work` contract, and prove target-scoped conflicts plus atomic -original-receipt replay. Live NoKV qualification, renew/reclaim semantics, -distributed quota, authentication, high availability, and broader state sync -remain later explicit decisions. +Provider-neutral stores, File/SQLite candidates, PostgreSQL conformance and in-process service admission/identity rotation already exist. Next are roadmap R5 local D1–D3 durability qualification and R6 authenticated real cross-host service, distributed budgets and recovery. Do not repeat the initial `claim_work` extraction or treat a service seam as a deployment. NoKV and other provider promotions retain their real-backend, compatibility, retention and explicit-approval gates. ## Architecture And Research Incubator diff --git a/docs/project/technical-directions.zh-CN.md b/docs/project/technical-directions.zh-CN.md index e0ee86dec5..bdd7f46d8f 100644 --- a/docs/project/technical-directions.zh-CN.md +++ b/docs/project/technical-directions.zh-CN.md @@ -42,13 +42,15 @@ recovery 与 host parity 是所有战略方向共用的底座。其可靠性工 和 `control-plane` label 推进；这是持续的产品 hardening，不是另一套方向事实源。 +跨领域交付次序、全部 RFC 覆盖和产品组合验收统一见 [LoopX 整体路线总纲](../architecture/rfcs/loopx-overall-roadmap-v0.zh-CN.md)。本页继续维护贡献入口；总纲中的 S 工作流、G 里程碑和 R 执行卡不替代领域合同与实际 Todo。 + ## 战略方向 | 方向 | 目标 | 阶段 | 从这里开始 | | --- | --- | --- | --- | | 长程 Benchmark 与证据 | 产出 benchmark-native、可复现的长程能力证据，并用受控任务研究机制。 | Active research | [Tracker #3243](https://github.com/huangruiteng/loopx/issues/3243) · [RFC](../architecture/rfcs/long-horizon-harness-benchmark-research-program-v0.zh-CN.md) | | 可靠性诊断与治理交付 | 证明 observer-first 产品入口：先在不改变 Agent 执行的前提下诊断长程 workflow，再只在验收通过的 seam 增加 authority。 | Draft 产品方向 / 交付 qualification | [RFC](../architecture/rfcs/long-running-agent-reliability-diagnostics-governed-delivery-v0.zh-CN.md) | -| Operator Surface 与 IM Integration | 通过一致的 operator workspace，让 goal、session、decision、evidence 和有界协作清晰可操作。 | 在 integration branch 孵化 | [Tracker #3244](https://github.com/huangruiteng/loopx/issues/3244) · [integration branch](https://github.com/huangruiteng/loopx/tree/frontend-control-plane-im-prototype-rfc) | +| Operator Surface 与 IM Integration | 通过一致的 operator workspace，让 goal、session、decision、evidence 和有界协作清晰可操作。 | 局部已交付 / 统一旅程 qualification | [Tracker #3244](https://github.com/huangruiteng/loopx/issues/3244) · [integration branch](https://github.com/huangruiteng/loopx/tree/frontend-control-plane-im-prototype-rfc) | | Shared Goal Authority 与跨 Host 协作 | 让多 host 围绕显式共享 goal 协作，同时避免 provider 或 host session 变成控制面权威。 | Draft contract / provider qualification | [Tracker #3245](https://github.com/huangruiteng/loopx/issues/3245) · [RFC](../architecture/rfcs/shared-goal-authority-state-provider-v0.zh-CN.md) | | 架构与研究孵化器 | 在扩大生产代码范围之前验证架构演进与研究机制。 | 混合成熟度，见下表 | [Tracker #3246](https://github.com/huangruiteng/loopx/issues/3246) · [RFC 索引](../architecture/rfcs/README.md) | @@ -69,7 +71,7 @@ trajectory、verifier output、upload、官方 scoring 和未公开比较仍由 ## 可靠性诊断与治理交付 -该产品方向把更广的商业化判断收窄成一个有边界的 entry offer。第一个 operating level +已有 default-off L1 原型与 DSH event adapter，见 [capability README](../../loopx/capabilities/reliability_diagnostics/README.zh-CN.md)；C0/C1 与开销资格仍未完成。该产品方向把更广的商业化判断收窄成一个有边界的 entry offer。第一个 operating level 是在 native harness 与完整 LoopX adoption 之间的 shadow observer：它单向消费 event、 写入独立 diagnostic ledger，不得注入 prompt，也不得 schedule、retry、stop、resume、 gate 或修改 worker state。在考虑任何 control authority 前，必须用 matched native/passive @@ -83,12 +85,7 @@ matched baseline（或显式标为更弱的 baseline）、acceptance criteria、 ## Operator Surface 与 IM Integration -当前前端与 IM 工作是孵化计划，不是 `main` 已交付行为。主要实现包是由 -[`@maxliux5`](https://github.com/maxliux5)主导的 -[#3167](https://github.com/huangruiteng/loopx/pull/3167)，基于 -[`frontend-control-plane-im-prototype-rfc`](https://github.com/huangruiteng/loopx/tree/frontend-control-plane-im-prototype-rfc) -集成分支。[#3200](https://github.com/huangruiteng/loopx/pull/3200) 是另一项仍处于 -requested changes 的 event-driven 提案。 +截至 `f1166e81e`，本地管家对话、executor settings、team-plan 确认、attached/managed 基础及部分 Lark vertical 已进入 `main`；统一跨入口执行与恢复仍未完整验收。[#3167](https://github.com/huangruiteng/loopx/pull/3167) 与其集成分支是历史孵化输入，不能代表当前所有前端能力都未交付。以 [Desktop RFC](../architecture/rfcs/desktop-execution-frontends-v0.zh-CN.md)、选定发布包和总纲 S4/S5 的逐入口验收为准。 进入 `main` 的 promotion ledger 为： @@ -111,11 +108,7 @@ requested changes 的 event-driven 提案。 Run history、status、quota、scheduler state、host session 与 evidence 继续由原有 边界负责。 -下一项 qualification 必须先保持 provider-neutral：抽取紧凑的 -command/precondition/receipt/outcome core，让 file-backed provider 通过相同的 -`claim_work` 契约，并证明 target-scoped conflict 与 atomic original-receipt -replay。真实 NoKV qualification、renew/reclaim、distributed quota、认证、HA 与更 -广泛的状态同步都是后续显式决策，不属于隐含 scope。 +当前已有 provider-neutral store、File/SQLite 候选、PostgreSQL conformance 与 in-process service admission/identity rotation 基础。下一阶段是总纲 R5 的本地持久化 D1–D3 资格，以及 R6 的真实认证跨 host 服务、分布式预算与恢复；不重做已交付的初始 `claim_work` 提取，也不把 service seam 当作已部署服务。NoKV 或其他 provider 的晋升继续服从各自真实 backend、兼容、保留与明确批准门槛。 ## 架构与研究孵化器