proxycast/docs/exec-plans/limenext-plan.md

LimeNext 总实施计划

状态：进行中
更新时间：2026-04-15
上位总纲：docs/roadmap/limenext/
目标：把 LimeNext 从“上位平台定义”推进到“可持续实施的主线计划”，统一产品对象、运行时骨架、远程入口、长时执行、证据治理与场景选品的推进顺序。

1. 先给结论

LimeNext 当前不是缺一篇愿景文档，而是缺一条能持续推进的平台主线。

本计划固定一个判断：

后续提到“推进 LimeNext”，默认不是泛泛优化平台，而是沿着 产品对象 -> 业务装配 -> 运行时骨架 -> 长时执行与远程 -> 证据治理 -> 场景选品 这条主线推进。

2. 当前基线

已经完成：

1. docs/roadmap/limenext/ 专题包已建立。
2. Lime 的 current 平台事实源已经分别收口到：
   • overview.md
   • query-loop.md
   • command-runtime.md
   • task-agent-taxonomy.md
   • remote-runtime.md
   • state-history-telemetry.md
   • skill-standard.md
3. ribbi/、command-runtime/、harness-engine/、product convergence、service skill cloud config 等子专题已被回挂到 LimeNext 总图。
4. sceneapp-capability-model.md 已补齐，固定了五类 SceneApp、五种 skill / scene 设计模式与九类底层能力模块的判断标准。
5. base-setup-decoupling.md 已把“基础设置包”和宿主内核边界单独收口。
6. 多模态组合型样板已进入 LimeNext 总纲，开始用 composition blueprint 统一表达组合蓝图。
7. composition-blueprint-schema.md 已补出文档级 schema 草案，后续可以继续下沉到 validator 与目录投影。
8. base-setup-package-schema.md 已把基础设置包补成顶层装配对象，开始明确“改包、改投影、改宿主”的判断线。
9. base-setup-projection-lifecycle.md 已把装配包发布、灰度、seeded 兜底与回滚链收口成可讨论的事实源。
10. base-setup-implementation.md 已把 validator / compiler / rollout gate 的第一版代码落点收口到现有 ServiceSkillCatalog 与 launch/runtime 锚点。
11. src/lib/base-setup/* 已新增第一版代码骨架，开始把基础设置包下沉到实际 TypeScript 模块与单测。

尚未完成：

1. 把 ServiceSkill 在产品面、目录面、运行时面和自动化面真正打通成同一个对象。
2. 让所有样板场景都按统一 SceneApp 类型与能力模块声明接入。
3. 把 SceneScorecard 与现有 evidence / tracker / artifact 数据链打通。
4. 在 docs/exec-plans/ 里建立 LimeNext 的持续推进日志与阶段风险管理。
5. 把已完成的样板进一步接到 Artifact + Evidence + Scorecard。
6. 把 SceneScorecard 从概念字段推进到可被聚合和查看的产品对象。
7. 把“主 App 宿主内核”与“基础设置包”分层固定下来，减少场景扩张对客户端发版的依赖。
8. 让基础设置包的 schema 继续下沉到 bootstrap / seeded catalog 可消费的目录投影。
9. 把 composition blueprint 从文档口径继续收口到可校验、可投影的装配对象。
10. 把 project pack 的最小交付合同继续对齐 artifact profile 与 viewer 主链。
11. 把装配包的 validator / projection compiler / rollout gate 真正落成代码或脚本。
12. 决定第一版是“客户端内编译 package”还是“服务端下发预编译 projection，客户端只做 gate + fallback”。
13. 决定 src/lib/base-setup/* 何时正式接入 src/lib/api/serviceSkills.ts，替换当前手写 catalog 来源。

3. 总目标

LimeNext 的实施总目标固定为：

目标输入 -> Scene / ServiceSkill -> Agent / Binding 执行 -> Artifact 交付 -> Evidence / Review 治理 -> Scorecard 评估 -> Keep / Incubate / Retire

4. 实施阶段

P0：总纲固化

目标：

• 让 LimeNext 平台定义稳定，不再来回摇摆。
• 固定 SceneApp 的能力分类，不再只停留在“场景工作台”的口号层。

已完成：

• docs/roadmap/limenext/ 专题包

退出条件：

• 后续讨论新专题时，能先声明它属于 LimeNext 哪一层。
• 新样板进入实施前，能先写出 sceneapp_type、pattern_primary / pattern_stack、infra_profile 与 composition_blueprint。

P1：产品对象收口

目标：

• 统一 ServiceSkill / Scene 的产品对象语义
• 把首页卡、技能页、slash scene、推荐方案挂到同一对象

依赖：

• docs/roadmap/ribbi/*
• docs/roadmap/lime-product-convergence-plan.md
• docs/roadmap/lime-service-skill-cloud-config-prd.md

退出条件：

• 前台不再把 skill bundle 和 ServiceSkill 混成一个词
• 首页与输入栏围绕同一场景对象表达

P1.5：业务装配收口

目标：

• 固定基础设置包与 composition blueprint 的角色边界
• 让多模态组合场景能优先通过装配层下发，而不是频繁改主 App

退出条件：

• 团队能明确回答“什么改动只改基础设置包，什么改动必须升级宿主”
• 第一条组合型样板能被写成标准设计卡，而不是口头 workflow

P2：运行时骨架收口

目标：

• 让 Scene / ServiceSkill 真正走统一运行时主链

依赖：

• docs/roadmap/gongneng/command-runtime/*
• docs/aiprompts/query-loop.md
• docs/aiprompts/command-runtime.md

退出条件：

• 至少一条 Agent + ServiceSkill 样板链路与一条 Agent + Task 样板链路稳定成立

当前状态：

• @配音 / voice_runtime / cloud-video-dubbing 已被选定并沉淀为第一条 Agent + ServiceSkill current 样板方案包
• x-article-export 已被沉淀为第二条 Agent + ServiceSkill current 样板方案包，并覆盖 site_adapter / browser_assist 分支

P3：长时执行与远程收口

目标：

• 把 subagent turn / automation job / channels runtime / browser connector 纳入统一平台解释与实施顺序

依赖：

• docs/aiprompts/task-agent-taxonomy.md
• docs/aiprompts/remote-runtime.md

退出条件：

• 团队不再把 OpenClaw compat shell 或 scheduler tick 当成长期主线

P4：证据与治理闭环

目标：

• 让 evidence / replay / review / dashboard 成为平台默认治理面

依赖：

• docs/aiprompts/state-history-telemetry.md
• docs/roadmap/harness-engine/*

退出条件：

• 失败场景可以稳定回挂到 evidence -> analysis/review -> fix -> regress 主链

P5：场景工厂

目标：

• 建立 SceneScorecard
• 固定 launch / keep / incubate / retire 规则

依赖：

• docs/roadmap/limenext/metrics-and-selection.md

退出条件：

• 平台能够系统性淘汰低价值场景，而不是只增不减

当前补充：

• Artifact / Evidence / Scorecard 的业务样板与图示已经建立
• Local Durable SceneApp 当前样板已固定为 每日趋势摘要 / 账号增长跟踪
• x-article-export 的当前产品合同已固定为“资料包优先 + 同一路径后处理”
• Base Setup 解耦规则已单独成文，开始固定“什么该下发，什么必须跟宿主升级”
• 下一步不再只是写定义，而是要明确具体聚合对象、入口和周会使用方式

5. 默认样板链路

后续实施默认至少推进五条样板：

1. Agent + ServiceSkill
   • 第一条 current 样板：@配音 / voice_runtime
   • 第二条 current 样板：x-article-export
2. Agent + Task
   • @配图
3. Prompt 型
   • @总结 或 @分析
4. automation job
   • 每日趋势摘要
   • 账号增长跟踪
5. Multimodal Composition
   • 文本 -> 线框图 -> 配乐 -> 剧本 -> 短视频草稿

固定补充规则：

• 每条样板都必须显式声明：
  • sceneapp_type
  • pattern_primary
  • pattern_stack
  • infra_profile
  • composition_blueprint
  • execution_entity
  • runtime_binding
  • storage_strategy
  • delivery_contract

推荐先从三句最短版开始写：

• 这是什么类型的 SceneApp
• 它内部主要按什么模式组织
• 它到底调用了哪些基础设施

6. 当前优先顺序

当前建议优先顺序固定为：

1. 先按 SceneApp 能力模型收口样板声明标准
2. 继续收口 ServiceSkill 作为产品对象
3. 以 @配音 / voice_runtime 作为第一条 Cloud-managed SceneApp 样板进入实施
4. 以 x-article-export 作为第一条 Browser-grounded SceneApp 样板进入实施
5. 以 每日趋势摘要 / 账号增长跟踪 作为第一条 Local Durable SceneApp 样板进入实施
6. 以多模态组合短视频草稿作为第一条 Hybrid SceneApp 样板进入实施
7. 把五条样板链路接到 Artifact + Evidence + Scorecard

当前不建议优先做：

1. 扩目录数量
2. 新增更多 compat 入口
3. 新造一层平行 runtime

7. 风险

风险 1：继续把 Lime 误讲成 skills runtime

处理：

• 所有执行文档都保持 Skill / ServiceSkill / Scene / Artifact / Evidence / Scorecard 分层

风险 2：把设计模式误当成产品对象

处理：

• 文档中固定区分 ServiceSkill / Scene 与 pattern_primary / pattern_stack
• 不再出现“这是个 Pipeline 产品”这类混层说法

风险 3：只做总纲，不接实施

处理：

• 本计划与进度日志持续更新
• 每进入实现阶段，回挂具体子专题与验证命令

风险 4：只做治理减法，不回主线交付

处理：

• 连续两轮主要在做治理后，下一轮必须回到样板场景交付

8. 当前下一刀

当前下一刀建议固定为：

把 composition blueprint 从文档对象继续收口到基础设置包 schema 与目录投影，再把 SceneScorecard 接到真实聚合来源、任务中心 / 场景看板入口与周会节奏；这样 LimeNext 才会从“样板闭环成立”继续推进到“经营面可执行”。