Repository navigation
[Roadmap]: LoopX overall delivery program / LoopX 整体路线与交付总跟踪 #4574
Description
方向讨论 / Portfolio discussion: #4575
总目标 / Objective
通过本地前端或 Lark 提出、修订和验收复杂目标，由持久管家协调多个长程 LoopX Agent，在本地 managed 与云端 runtime 上完成可验证工作。先证明小团队协作、handoff 和恢复，再分级资格化百 Agent 并发。
Let an owner express, revise and accept complex goals through the local frontend or Lark, while a persistent steward coordinates long-running LoopX Agents across local managed and cloud runtimes. Prove small-team collaboration, handoff and recovery before hundred-Agent concurrency.
Canonical plan: 中文总纲 · English roadmap · merged #4570.
本 Issue 跟踪跨领域依赖与组合验收；领域 Issue/实际 Todo 跟踪可领取工作，避免重复建账。总纲覆盖原有 30 个主 RFC、13 条工作流及 RFC 外的重要领域，仍保留各领域 Draft/Accepted、权限、迁移和 provider 晋升门槛。
This umbrella tracks dependencies and portfolio acceptance. Domain issues/canonical Todos own claimable work. The roadmap covers all 30 pre-existing primary RFCs, 13 streams and important non-RFC areas without changing domain acceptance, permission or promotion gates.
组合里程碑 / Portfolio gates
- G0 — 可信基线 / Trustworthy baseline: 修复 R1 确认承诺丢失、stale basis、空成功与部分提交恢复；明确单 Agent 发布包旅程及成本未知项。 Repair R1 commitment/freshness/empty-success/recovery gaps and qualify the basic release-artifact journey.
- G1 — 小团队交付 / Small-team delivery: 管家 + 2–3 个长程 worker，至少两轮真实依赖产物和 peer handoff，含故障、用户补充与独立验收。 Two real cycles with dependencies, peer handoff, recovery, owner correction and independent acceptance.
- G2 — 可恢复协作工作台 / Recoverable workspace: R3 通用 peer 请求/复核/自动回报，R4 对齐与受治理修订，R5 本地 durable authority；frontend/Lark 同源回读。 General collaboration, alignment and qualified local durability with shared readback.
- G3 — 本地/云端协作 / Local-cloud work: R6 至少两真实 host，认证作用域、撤销、共享预算、网络恢复与旧 worker fence。 Two real hosts with authenticated scope, shared budget and recovery.
- G4 — 百 Agent 资格 / Hundred-Agent qualification: R7 按 10→30→100+ 活跃 cohort 验收预先冻结的成本、吞吐、延迟和恢复指标；注册数不等于并发执行。 Qualify active cohorts against frozen SLOs; registrations are not concurrency evidence.
- G5 — 可重复采用 / Repeatable adoption: 独立安装、升级、导出/回滚，工程及知识/研究两类案例，维护与支持成本可追溯；可从 G0 并行推进。 Independent adoption and repeatable cases can progress alongside G0, without waiting for G4.
首批执行顺序 / First execution sequence
- R1 / P0: 在最新 main 重现总纲 F1–F4，合并已存在修复，逐字段核对确认→持久工作→回读；再补同一路径的源基线、幂等和持久恢复。 Reproduce on current main, reconcile existing fixes, preserve confirmed semantics and qualify retry/recovery through the owning path.
- R2 + minimum R3 / P0: 使用真实合格 binding 验 2–3 worker。必须通过 Agent 间请求/产物交接推进依赖，不能以创建多条 Todo 或发送消息作为成功。 Require real inter-Agent dependency handoff, not just multiple Todos or sent messages.
- R3–R5 / P1: 完成 peer 协作/结果返回、共享修订及相关 TS 整笔事务/本地存储资格；不等待全量 TS 重写，也不复制 work/lease/effect authority。 Complete bounded transactions and qualifications without a second authority or full-rewrite prerequisite.
- R6–R7 / P2: 本地云端真实协作后扩规模；只读研究、材料、诊断、采用和发布质量按依赖同期推进。 Expand after real cross-host evidence; parallel streams retain their own gates.
Goal lifetime integration / Goal 生命周期联动
#5389 已合并 quota_settlement 实例归属隔离及双语规划更新；生命周期与恢复继续由 #5206 负责。沿用 R1–R3/G1 的创建 Goal → 创建/复用 Agent → 两轮依赖产物与 peer handoff → 中断纠偏 → 独立验收和原入口回报旅程。P1 接共享预算与 R5/M4 孤儿恢复，P2 接 R6/G3 跨主机；没有新增并行里程碑。
规范路线与验收顺序 · 具体 golden-query 场景。先验已支持 profile 的普通小团队；选定 source profile 的 owner/compatibility/drain 门槛通过后，再验隔离的同名重建和迟到结果。#5389 的组件验证不关闭 G1、M3/M4/M5，不激活 source-session profile，也不代替 packaged App、CLI、Lark 的组合回读。
Existing owners and trackers / 复用现有跟踪
| Area | Existing tracker |
|---|---|
| Manager and semantic peer handoff | #4339; continuation #4085 |
| TS kernel and shared authority | #3225, #3245; local durability #4224 |
| Shared intent and direction | #3836, #2831 |
| Goal lifetime, orphan recovery and creation/team integration | #5206; quota foundation #5389 |
| Frontend/Lark and review UX | #3244, #3786; computer use #4114 |
| Memory and cost | #3214, #3824, #3163 |
| Daemon and hooks | #3930, #3479 |
| Research and benchmark evidence | #3243, #3246, #4391 |
未列出的工作流仍在总纲 S1–S13 中有 owner/下一步；本表不声称每项 tracker 都已完成或立即可领取。其余已有 Issue/PR 先查重再拆分。
Other streams retain owners/next steps in S1–S13. Links do not establish completion or immediate claimability; reconcile existing work before opening child tasks.
Completion contract / 完成合同
每个后继 Issue/PR 写明 S/G/R 与领域验收编号、真实 caller/唯一 owner、当前 baseline、独立语义预期、失败/重试/越权反例、frontend/Lark/CLI 回读、验证范围、回滚及一个有界后继。记录已完成/失败/未测；字段、消息、receipt 或测试数量都不能单独证明完整能力。
Each successor names S/G/R and domain acceptance IDs, real caller/single owner, baseline, independent expected semantics, negative/recovery cases, entrypoint readback, evidence limits, rollback and a bounded successor. Mark passed/failed/untested honestly. Update the canonical roadmap when dependencies or portfolio gates change; do not copy long execution logs here.
Activity
huangruiteng commentedon Sep 27, 2026
RFC delivery task map / RFC 交付任务对应表（2026-09-28）
One RFC → one delivery issue/retained issue record. 39 accepted RFCs mapped: 17 new task issues and 22 reused records. This follows the contributor-task format used by the semantic-convergence program, without creating another roadmap or splitting every milestone into a new issue.
Audit basis: public
mainatce3862e33, open issues/PRs and current implementation ownership. RFC headings and old issue descriptions can lag shipped code; new tasks explicitly separate implemented foundations, remaining acceptance and promotion. Source inspection here is not a fresh runtime qualification.help wanted; propose a bounded milestone in the same issue before duplicating work.当前按“每份 RFC 一个任务”组织；已存在的任务直接复用，已交付部分不重新招领。新任务含当前实现、剩余工作、现有 PR 衔接与验收条件。没有新增子任务树；本表也不改变 RFC 的权限、预算、兼容和验收边界。
Use the RFC for design and acceptance, the linked task for milestone/PR evidence, and current execution ownership for assignment. Update the linked record when a boundary changes; do not infer completion from PR counts, stale “not implemented” text, or a design merge. A demonstrated complete scope can close with evidence instead of manufacturing follow-up work.