opensource/proxycast

Fork 0

mirror of https://github.com/aiclientproxy/proxycast.git synced 2026-09-24 23:10:56 +08:00

Files

T

coso 9f31ba4cd7 feat: sync latest workspace changes

2026-04-19 18:50:13 +08:00

228 KiB

Raw Permalink Blame History

LimeNext 推进日志

注：自 2026-04-19 起，LimeNext current 前台主词固定为 技能 / 灵感库 / 生成。历史日志里若继续出现 SceneApp / 创作场景 / Project Pack / 复盘 / 记忆工作台 / 任务工作台 / 任务视图 等词，默认按当时实现阶段或 compat 旧称理解，不再代表 current 产品口径。

补充说明：2026-04-17 中段几次关于“纯标题目录 / 无图场景墙”的尝试，当前都已被后续 经营信号目录卡片 方案取代。阅读本日志时，凡旧条目仍写“纯标题目录”，都按已废弃试探理解；current 以最新“目录卡片经营信号回流”条目为准。

补充说明（2026-04-18）：旧 Ribbi 过渡目录已清理。历史条目若继续出现旧 Ribbi 路径，默认按“当时旧路径、现已由 docs/research/ribbi/* 替代”理解。

2026-04-19

已完成

把 P2：Skill-First 前台 当前被环境级验证阻塞的 verify:gui-smoke 恢复到“能自我避开损坏 cargo target”的状态，避免 GUI 交付链继续被旧 sqlite 半成品缓存卡死：
- 已更新：
  - scripts/verify-gui-smoke.mjs
  - docs/exec-plans/limenext-progress.md
- 当前统一结论：
  - verify:gui-smoke 当前新增 sqlite 构建产物自检；若目标 cargo target 下存在 debug/build/libsqlite3-sys-*/out 但缺少 bindgen.rs，脚本不再复用该目录，也不做破坏性删除，而是自动切到同级新的 *-rebuild-<timestamp>-<pid> target
  - 默认超时当前也会基于“最终实际使用的 cargo target”重新计算；未显式传 --timeout-ms 时，切到 fresh target 后会自动回到冷启动超时，不再沿用旧 warm target 的较短等待
  - 这一步属于 P2 的交付支撑修复，不是继续扩前台功能，而是把 current 主线从“代码已收口但 GUI smoke 受旧缓存污染”拉回“脚本可自我避险”
- 当前已确认通过：
  - node --check "scripts/verify-gui-smoke.mjs"
  - npx eslint "scripts/verify-gui-smoke.mjs"
  - node scripts/verify-gui-smoke.mjs --app-url "http://127.0.0.1:1421/" --timeout-ms 600000 --cargo-target-dir "/var/folders/87/s6cpr7hd1_v43cs833x4s_900000gn/T/lime-gui-smoke-target" 已实际打印：
    - 发现损坏 sqlite 构建缓存
    - 自动切换到新的 lime-gui-smoke-target-rebuild-* 目录
    - 开始用 fresh target 拉起 headless Tauri 编译链
- 当前剩余阻塞说明：
  - 在当前机器上，fresh headless 链继续向前时，beforeDevCommand 虽然已按 http://127.0.0.1:1421/ 等待新前端，但 Vite 实际仍报告 Port 1420 is already in use，说明本机已有 dev server / Vite 端口复用链还在影响隔离 smoke
  - 另一路复用现有 1420 + 3030 环境执行 npm run verify:gui-smoke -- --timeout-ms 1200000 时，链路已能稳定走到 smoke:agent-runtime-tool-surface-page，但最后仍卡在 Runtime 能力摘要出现，最后结果为 hasWorkbench=true 且其余摘要标记均为 false
  - 因此这次已确认“损坏 sqlite target”不再是当前唯一阻塞；剩余问题已收敛为两个独立问题：
    - 新链路隔离启动仍受本机现有 Vite/前端端口占用影响
    - 复用现有 dev 环境时，agent-runtime-tool-surface-page 仍未看到 runtime 摘要，需要单独检查 toolInventory / harness panel 页面态是否与 current 环境一致
把 P2：Skill-First 前台 里最后几条还没进入合同层的 current 前台入口继续收口，避免首页 continuation、技能页最近做法、我的方法库和输入层 installed skill 继续各说各的：
- 已更新：
  - src/components/skills/installedSkillPresentation.ts
  - src/components/skills/installedSkillPresentation.test.ts
  - src/components/agent/chat/components/EmptyState.tsx
  - src/components/agent/chat/components/EmptyState.test.tsx
  - src/components/agent/chat/skill-selection/inputCapabilitySections.ts
  - src/components/agent/chat/skill-selection/CharacterMention.test.tsx
  - src/components/skills/SkillsWorkspacePage.tsx
  - src/components/skills/SkillsWorkspacePage.test.tsx
  - docs/roadmap/limenextv2/implementation-roadmap.md
  - docs/roadmap/limenextv2/skill-first-system.md
  - docs/exec-plans/limenext-progress.md
- 当前统一结论：
  - installed skill 当前新增共享的轻量 projection helper，优先复用 metadata.lime_when_to_use / lime_argument_hint，兜底到 description + 对话里继续补充目标与约束 + 带着该方法进入生成主执行面
  - 首页 继续上次做法 当前不再只留标题；结果模板与 service skill 都会直接显示 需要 / 交付 缩略事实
  - 技能页 继续常用做法 当前补齐 你来给 / 会拿到 / 结果去向，我的方法库 也不再只是 名字 + 描述 + /key
  - @ / / 输入层里的 installed skill 当前也回到同一套轻量 skill 合同，不再保留一条纯 description 链
  - 这一步继续服务 P2 的主目标：让首页、技能页和输入层共享的不只是 capability id，而是统一的 current 前台 skill 解释层
- 当前已确认通过：
  - npm exec vitest run "src/components/skills/installedSkillPresentation.test.ts" "src/components/agent/chat/components/EmptyState.test.tsx" "src/components/agent/chat/skill-selection/CharacterMention.test.tsx" "src/components/skills/SkillsWorkspacePage.test.tsx"
  - npx eslint "src/components/skills/installedSkillPresentation.ts" "src/components/skills/installedSkillPresentation.test.ts" "src/components/agent/chat/components/EmptyState.tsx" "src/components/agent/chat/components/EmptyState.test.tsx" "src/components/agent/chat/skill-selection/inputCapabilitySections.ts" "src/components/agent/chat/skill-selection/CharacterMention.test.tsx" "src/components/skills/SkillsWorkspacePage.tsx" "src/components/skills/SkillsWorkspacePage.test.tsx"
  - npm run verify:local
- 当前阻塞说明：
  - verify:local 的前端、Vitest 与 cargo test --manifest-path src-tauri/Cargo.toml 均已实际通过
  - 但末尾 verify:gui-smoke 在独立临时 target 编译阶段失败，错误为 libsqlite3-sys 读取临时 OUT_DIR 下的 bindgen.rs 失败，导致 headless Tauri 在 DevBridge 就绪前退出
  - 因此本轮当前已达到“代码、类型、定向回归、Rust 单测通过”的门槛，但 GUI smoke 仍受环境级编译问题阻塞，需单独处理该 smoke target 的 sqlite/bindgen 构建稳定性
把 P2：Skill-First 前台 的 service skill 前台合同投影接回与 curated_task 同一套 current 事实源，避免首页、输入层、技能页继续各讲各的：
- 已更新：
  - src/components/agent/chat/service-skills/skillPresentation.ts
  - src/components/agent/chat/service-skills/skillPresentation.test.ts
  - src/components/agent/chat/components/EmptyState.tsx
  - src/components/agent/chat/components/EmptyState.test.tsx
  - src/components/agent/chat/skill-selection/inputCapabilitySections.ts
  - src/components/agent/chat/skill-selection/CharacterMention.test.tsx
  - src/components/skills/SkillsWorkspacePage.tsx
  - src/components/skills/SkillsWorkspacePage.test.tsx
  - docs/roadmap/limenextv2/implementation-roadmap.md
  - docs/roadmap/limenextv2/skill-first-system.md
  - docs/exec-plans/limenext-progress.md
- 当前统一结论：
  - service skill 当前新增共享的 capability description helper，统一输出 promise + 需要 + 交付
  - 首页 快捷做法 的缩略 meta、@ 面板里的 service skill 描述、技能页组内做法卡片，当前都改成围绕同一套合同事实表达
  - 技能页组内卡片当前不再写 入口，而是显式展示 你来给 / 会拿到 / 结果去向，开始和 curated_task 的 skill 合同体验靠拢
  - 这一步继续服务 P2 第 2 条目标：让技能页、新建任务页和输入层共享的不只是 skill id，而是统一的 current 前台 skill 解释层
- 当前已确认通过：
  - npm exec vitest run "src/components/agent/chat/service-skills/skillPresentation.test.ts" "src/components/agent/chat/components/EmptyState.test.tsx" "src/components/agent/chat/skill-selection/CharacterMention.test.tsx" "src/components/skills/SkillsWorkspacePage.test.tsx"
  - npx eslint "src/components/agent/chat/service-skills/skillPresentation.ts" "src/components/agent/chat/service-skills/skillPresentation.test.ts" "src/components/agent/chat/components/EmptyState.tsx" "src/components/agent/chat/components/EmptyState.test.tsx" "src/components/agent/chat/skill-selection/inputCapabilitySections.ts" "src/components/agent/chat/skill-selection/CharacterMention.test.tsx" "src/components/skills/SkillsWorkspacePage.tsx" "src/components/skills/SkillsWorkspacePage.test.tsx"
  - npm run verify:local
  - 本次 verify:local 已实际覆盖 verify:gui-smoke，并跑通 workspace-ready / browser-runtime / site-adapters / agent-service-skill-entry / agent-runtime-tool-surface / agent-runtime-tool-surface-page
把 P2：Skill-First 前台 里的 curated_task 启动事实与 skill 合同缩略投影继续收口到同一条 current 主链，避免首页、技能页、输入层只是“都能打开”，但仍各讲各的 skill：
- 已更新：
  - src/components/agent/chat/utils/curatedTaskTemplates.ts
  - src/components/agent/chat/components/EmptyState.tsx
  - src/components/agent/chat/skill-selection/inputCapabilitySections.ts
  - src/components/skills/SkillsWorkspacePage.tsx
  - src/components/agent/chat/skill-selection/CharacterMention.test.tsx
  - src/components/skills/SkillsWorkspacePage.test.tsx
  - docs/roadmap/limenextv2/implementation-roadmap.md
  - docs/roadmap/limenextv2/skill-first-system.md
  - docs/exec-plans/limenext-progress.md
- 当前统一结论：
  - 首页 结果入口 的缩略 meta 与 slash 面板里的结果模板描述，当前都改成共享 buildCuratedTaskCapabilityDescription；输入层里的结果模板不再只有一句 summary，而会同步暴露 需要 / 交付 的 current 缩略事实
  - 技能页桥接 curated_task 进入 生成 时，当前也会把 referenceEntries 一并带进 initialInputCapability.capabilityRoute，不再只有 referenceMemoryIds
  - 到这里为止，首页、slash、技能页三条结果模板入口共享的不只是 taskId + prompt，还包括可回放的引用对象事实；首屏恢复与二次编辑 launcher 时，不会再出现某条链只剩 id 的分叉
  - 这一步继续服务 P2 第 2 条目标：让技能页、新建任务页和输入层共享同一 skill 事实源，而不是只共享模板目录
- 当前已确认通过：
  - npm exec vitest run "src/components/skills/SkillsWorkspacePage.test.tsx" "src/components/agent/chat/skill-selection/CharacterMention.test.tsx" "src/components/agent/chat/components/EmptyState.test.tsx"
  - npx eslint "src/components/agent/chat/utils/curatedTaskTemplates.ts" "src/components/agent/chat/components/EmptyState.tsx" "src/components/agent/chat/skill-selection/inputCapabilitySections.ts" "src/components/skills/SkillsWorkspacePage.tsx" "src/components/agent/chat/skill-selection/CharacterMention.test.tsx" "src/components/skills/SkillsWorkspacePage.test.tsx"
  - npm run verify:local
  - npm run verify:gui-smoke 已包含在本次 verify:local 中，并实际跑通 workspace-ready / browser-runtime / site-adapters / agent-service-skill-entry / agent-runtime-tool-surface / agent-runtime-tool-surface-page
  - 这意味着之前日志里提到的 site_capability_service Rust 既有失败，当前已不再是本轮主线的有效阻塞状态
把 生成 后的 Team / Canvas / Inputbar 首层提示继续收口到和 GeneralWorkbench 一致的 current 主执行面，避免刚把工作台改成结果对象视角，team runtime 首层又长回第二套任务命名：
- 已更新：
  - src/components/agent/chat/utils/teamWorkspaceCopy.ts
  - src/components/agent/chat/components/TeamWorkbenchSummaryPanel.tsx
  - src/components/agent/chat/components/TeamWorkspaceDock.tsx
  - src/components/agent/chat/components/ChatSidebar.tsx
  - src/components/agent/chat/workspace/useWorkspaceCanvasSceneRuntime.tsx
  - src/components/agent/chat/components/Inputbar/components/InputbarWorkflowStatusPanel.tsx
  - src/components/agent/chat/components/CanvasWorkbenchLayout.tsx
  - src/components/agent/chat/components/team-workspace-board/TeamWorkspaceEmptyShellState.tsx
  - src/components/agent/chat/components/team-workspace-board/TeamWorkspaceCanvasToolbar.tsx
  - src/components/agent/chat/components/team-workspace-board/TeamWorkspaceCanvasStage.tsx
  - src/components/agent/chat/components/team-workspace-board/teamWorkspaceBoardPresentationSelectors.ts
  - src/components/agent/chat/team-workspace-runtime/formationDisplaySelectors.ts
  - src/components/agent/chat/utils/teamWorkspaceCanvas.ts
  - src/components/agent/chat/utils/contextualRecommendations.ts
  - src/components/agent/chat/utils/contextualRecommendations.test.ts
  - src/components/agent/chat/utils/agentTaskRuntime.test.ts
  - docs/exec-plans/claude-code-agent-task-runtime-alignment-plan.md
  - docs/roadmap/limenextv2/implementation-roadmap.md
  - docs/exec-plans/limenext-progress.md
- 当前统一结论：
  - Team Summary / Team Dock / Canvas team tab / workflow status 当前统一使用 生成工作台 / 当前进展，空态按钮与进入提示也不再把 team runtime 包装成另一套平级“任务视图”
  - 可继续稿件 / 可继续版本 / 产出记录 / 执行经过 这套结果对象语言，当前已经从首页、GeneralWorkbench 继续接到了 Team / Canvas / Inputbar 首层提示
  - 在用户已明确“不做兼容”的前提下，contextualRecommendations 当前也已删掉把 任务工作台 当成 team runtime 触发词的历史容忍，只保留 current 文案与真实 team 语义
  - 这一步继续服务 P1：前台口径收口，让 生成 后首层路径不再同时存在两套执行命名；current 事实源现在收敛为 生成 -> 生成工作台 -> 当前进展
- 当前已确认通过：
  - npm exec vitest run "src/components/agent/chat/components/TeamWorkspaceDock.test.tsx" "src/components/agent/chat/components/TeamWorkspaceBoard.test.tsx" "src/components/agent/chat/components/TeamWorkbenchSummaryPanel.test.tsx" "src/components/agent/chat/components/CanvasWorkbenchLayout.test.tsx" "src/components/agent/chat/components/Inputbar/index.test.tsx" "src/components/agent/chat/workspace/useWorkspaceCanvasSceneRuntime.test.ts" "src/components/agent/chat/components/team-workspace-board/TeamWorkspaceCanvasSurfaceCopy.test.tsx" "src/components/agent/chat/components/team-workspace-board/TeamWorkspaceTeamOverviewChrome.test.tsx" "src/components/agent/chat/components/team-workspace-board/teamWorkspaceBoardPresentationSelectors.test.ts" "src/components/agent/chat/components/team-workspace-board/useTeamWorkspaceBoardShellProps.test.tsx" "src/components/agent/chat/components/team-workspace-board/teamWorkspaceBoardPropBuilders.test.ts" "src/components/agent/chat/components/team-workspace-board/useTeamWorkspaceBoardCanvasRuntime.test.tsx" "src/components/agent/chat/team-workspace-runtime/formationDisplaySelectors.test.ts" "src/components/agent/chat/utils/contextualRecommendations.test.ts" "src/components/agent/chat/utils/agentTaskRuntime.test.ts"
  - npm run verify:local
把仓库其余仍会直接暴露给用户的旧 任务工作台 / 任务视图 文案继续收尾一刀，避免主链已换成 current 口径，旁路设置页还把用户拉回旧语境：
- 已更新：
  - src/components/settings-v2/system/automation/index.tsx
  - src/components/settings-v2/system/automation/index.test.tsx
  - docs/roadmap/limenextv2/implementation-roadmap.md
  - docs/exec-plans/limenext-progress.md
- 当前统一结论：
  - 自动化设置页当前不再暴露 打开任务工作台，而是统一改成 打开自动化工作台
  - workspace-only 描述当前也不再写 默认进入任务视图，而是改成 默认进入当前进展
  - 这一步属于 P1 的旁路收尾：不是继续扩主链，而是防止 current 主词在其他真实前台页面被旧词反向污染
- 当前已确认通过：
  - npm exec vitest run "src/components/settings-v2/system/automation/index.test.tsx"
  - npx eslint "src/components/settings-v2/system/automation/index.tsx" "src/components/settings-v2/system/automation/index.test.tsx"
把 team runtime 里仍像“第二套任务面板系统”的 copy 继续收口到 当前进展 语义，避免 生成工作台 下面又长出另一套旧前台命名：
- 已更新：
  - src/components/agent/chat/team-workspace-runtime/formationDisplaySelectors.ts
  - src/components/agent/chat/team-workspace-runtime/formationDisplaySelectors.test.ts
  - src/components/agent/chat/team-workspace-runtime/boardChromeSelectors.ts
  - src/components/agent/chat/team-workspace-runtime/boardChromeSelectors.test.ts
  - src/components/agent/chat/components/team-workspace-board/TeamWorkspaceCanvasToolbar.tsx
  - src/components/agent/chat/components/team-workspace-board/TeamWorkspaceEmptyShellState.tsx
  - src/components/agent/chat/components/team-workspace-board/SelectedSessionInlineHeader.tsx
  - src/components/agent/chat/components/team-workspace-board/teamWorkspaceBoardPresentationSelectors.ts
  - src/components/agent/chat/components/team-workspace-board/TeamWorkspaceTeamOverviewControls.tsx
  - src/components/agent/chat/components/team-workspace-board/TeamWorkspaceCanvasSurfaceCopy.test.tsx
  - src/components/agent/chat/components/team-workspace-board/TeamWorkspaceTeamOverviewChrome.test.tsx
  - src/components/agent/chat/components/team-workspace-board/teamWorkspaceBoardPresentationSelectors.test.ts
  - src/components/agent/chat/components/TeamWorkspaceBoard.test.tsx
  - docs/roadmap/limenextv2/implementation-roadmap.md
  - docs/exec-plans/limenext-progress.md
- 当前统一结论：
  - Team runtime 默认空态与画布提示当前不再写 任务面板 / 任务摘要视图，而是统一改成 当前进展面板 / 进展摘要视图
  - canvas toolbar 与紧凑控制条当前不再写 聚焦任务，而是统一改成 聚焦进展
  - lane 数、overview subtitle 与 selected session CTA 当前也不再写 X 项任务已接入 / 打开任务 / 切换任务，而是统一改成 X 条当前进展已接入 / 打开进展 / 切换进展
  - 这一步继续服务 P1：不是否认 team runtime 里真实存在的任务拆分，而是把用户一眼看到的执行对象继续固定回 当前进展
- 当前已确认通过：
  - npm exec vitest run "src/components/agent/chat/team-workspace-runtime/formationDisplaySelectors.test.ts" "src/components/agent/chat/team-workspace-runtime/boardChromeSelectors.test.ts" "src/components/agent/chat/components/team-workspace-board/TeamWorkspaceCanvasSurfaceCopy.test.tsx" "src/components/agent/chat/components/team-workspace-board/TeamWorkspaceTeamOverviewChrome.test.tsx" "src/components/agent/chat/components/team-workspace-board/teamWorkspaceBoardPresentationSelectors.test.ts" "src/components/agent/chat/components/team-workspace-board/useTeamWorkspaceBoardCanvasRuntime.test.tsx" "src/components/agent/chat/components/TeamWorkspaceBoard.test.tsx"
  - npx eslint "src/components/agent/chat/team-workspace-runtime/formationDisplaySelectors.ts" "src/components/agent/chat/team-workspace-runtime/boardChromeSelectors.ts" "src/components/agent/chat/components/team-workspace-board/TeamWorkspaceCanvasToolbar.tsx" "src/components/agent/chat/components/team-workspace-board/TeamWorkspaceEmptyShellState.tsx" "src/components/agent/chat/components/team-workspace-board/SelectedSessionInlineHeader.tsx" "src/components/agent/chat/components/team-workspace-board/teamWorkspaceBoardPresentationSelectors.ts" "src/components/agent/chat/components/team-workspace-board/TeamWorkspaceTeamOverviewControls.tsx" "src/components/agent/chat/team-workspace-runtime/formationDisplaySelectors.test.ts" "src/components/agent/chat/team-workspace-runtime/boardChromeSelectors.test.ts" "src/components/agent/chat/components/team-workspace-board/TeamWorkspaceCanvasSurfaceCopy.test.tsx" "src/components/agent/chat/components/team-workspace-board/TeamWorkspaceTeamOverviewChrome.test.tsx" "src/components/agent/chat/components/team-workspace-board/teamWorkspaceBoardPresentationSelectors.test.ts" "src/components/agent/chat/components/TeamWorkspaceBoard.test.tsx"
把 生成现场 与 topic switch 的边缘提示继续去任务化，避免主流程已经换词，继续入口和错误提示还在回退旧任务系统语境：
- 已更新：
  - src/components/agent/chat/components/ChatSidebar.tsx
  - src/components/agent/chat/components/ChatSidebar.test.tsx
  - src/components/agent/chat/workspace/useWorkspaceTopicSwitch.ts
  - docs/roadmap/limenextv2/implementation-roadmap.md
  - docs/exec-plans/limenext-progress.md
- 当前统一结论：
  - task-center continuation 的 fallback 动作当前不再写 打开任务，而是改成和 生成现场 对齐的 打开现场
  - topic switch 失败 toast 当前也不再写 切换任务失败 / 加载任务失败，而是统一改成 切换会话失败 / 加载会话失败
  - 这一步继续服务 P1 的边缘收口：哪怕只是在失败或 fallback 场景里，也尽量避免把默认 生成 链重新讲成任务系统
- 当前已确认通过：
  - npm exec vitest run "src/components/agent/chat/team-workspace-runtime/boardChromeSelectors.test.ts" "src/components/agent/chat/components/ChatSidebar.test.tsx"
  - npx eslint "src/components/agent/chat/team-workspace-runtime/boardChromeSelectors.ts" "src/components/agent/chat/team-workspace-runtime/boardChromeSelectors.test.ts" "src/components/agent/chat/components/ChatSidebar.tsx" "src/components/agent/chat/components/ChatSidebar.test.tsx" "src/components/agent/chat/workspace/useWorkspaceTopicSwitch.ts"
把 生成 后工作台里偏工程的对象名继续收口成结果对象视角，避免首页已经在讲“结果去向 / 继续上次做法”，一进入工作台又退回 任务 / 分支 / 过程记录 语境：
- 已更新：
  - src/components/agent/chat/components/GeneralWorkbenchSidebarShell.tsx
  - src/components/agent/chat/components/GeneralWorkbenchWorkflowPanel.tsx
  - src/components/agent/chat/components/GeneralWorkbenchSidebar.test.tsx
  - docs/roadmap/limenextv2/implementation-roadmap.md
  - docs/exec-plans/limenext-progress.md
- 当前统一结论：
  - 任务工作台 当前已改成 生成工作台，任务视图 当前已改成 当前进展，把 生成 固定为用户理解里的主执行面
  - 相关分支 / 相关版本 当前已收成 可继续稿件 / 可继续版本，让用户优先理解“从哪一稿继续”，而不是先理解工程分支对象
  - 任务记录 / 过程记录 当前已收成 产出记录 / 执行经过，并继续与首页 结果去向 的说明保持同一套结果对象语言
  - 这一步继续服务 P1：首页默认复杂度收口，但重点已经从首页进一步推进到 生成 后第一屏，让用户在执行面里也默认看到“结果 / 下一步 / 继续入口”，而不是后台对象名
- 当前已确认通过：
  - npm exec vitest run "src/components/agent/chat/components/GeneralWorkbenchSidebar.test.tsx"
  - npx eslint "src/components/agent/chat/components/GeneralWorkbenchSidebarShell.tsx" "src/components/agent/chat/components/GeneralWorkbenchWorkflowPanel.tsx" "src/components/agent/chat/components/GeneralWorkbenchSidebar.test.tsx"
  - npm run verify:local
  - npm run verify:gui-smoke 已包含在本次 verify:local 中，并实际跑通 workspace-ready / browser-runtime / site-adapters / agent-service-skill-entry / agent-runtime-tool-surface / agent-runtime-tool-surface-page
把 生成 后的进展摘要卡补成“结果去向 / 从哪里继续”的轻接线，避免首页提示一消失，用户又不知道结果会去哪：
- 已更新：
  - src/components/agent/chat/components/GeneralWorkbenchWorkflowPanel.tsx
  - src/components/agent/chat/components/GeneralWorkbenchSidebar.test.tsx
  - docs/roadmap/limenextv2/implementation-roadmap.md
  - docs/exec-plans/limenext-progress.md
- 当前统一结论：
  - 顶部摘要卡当前会继续提示：主稿、任务文件和运行产物会沉淀到下方 产出记录 / 执行经过
  - 需要继续修改时，用户当前也能直接从 可继续稿件/版本 或首页 继续上次做法 这两个入口理解“从哪里接着跑”
  - 这一步继续服务 P1：首页默认复杂度收口，但落点已经从首页延伸到 生成 后的结果/工作台首屏，让“结果不会丢、下次从哪里继续”不再只停留在首页一句提示里
- 当前已确认通过：
  - npm exec vitest run "src/components/agent/chat/components/GeneralWorkbenchSidebar.test.tsx"
  - npx eslint "src/components/agent/chat/components/GeneralWorkbenchWorkflowPanel.tsx" "src/components/agent/chat/components/GeneralWorkbenchSidebar.test.tsx"
  - npm run verify:local
  - npm run verify:gui-smoke 已包含在本次 verify:local 中，并实际跑通 workspace-ready / browser-runtime / site-adapters / agent-service-skill-entry / agent-runtime-tool-surface / agent-runtime-tool-surface-page
把 新建任务 首页剩余非核心块继续收成“有真实收益才露出”的 current 显隐规则：
- 已更新：
  - src/components/agent/chat/components/EmptyState.tsx
  - src/components/agent/chat/components/EmptyStateSceneAppsPanel.tsx
  - src/components/agent/chat/components/EmptyState.test.tsx
  - docs/roadmap/limenextv2/implementation-roadmap.md
  - docs/exec-plans/limenext-progress.md
- 当前统一结论：
  - 更多起手方式 当前不再因为“还有目录页可进”就默认露出；只有当前真有可直接启动的整套做法，或用户确实可以“继续最近做法”时，这块才出现
  - 支撑能力 当前也不再因为“系统里有技能”就默认露出；只有浏览器接入、站点自动接入型做法，或最近沉淀出的复用方法形成直接收益时，才继续显示摘要层
  - 这一步继续服务 P1：首页默认复杂度收口，目标是避免首页在推荐层收完之后，又被“目录入口 / 能力目录”重新长回平台分层感
- 当前已确认通过：
  - npm exec vitest run "src/components/agent/chat/components/EmptyState.test.tsx"
  - npx eslint "src/components/agent/chat/components/EmptyState.tsx" "src/components/agent/chat/components/EmptyStateSceneAppsPanel.tsx" "src/components/agent/chat/components/EmptyState.test.tsx"
  - npm run verify:local
  - npm run verify:gui-smoke 已包含在本次 verify:local 中，并实际跑通 workspace-ready / browser-runtime / site-adapters / agent-service-skill-entry / agent-runtime-tool-surface / agent-runtime-tool-surface-page
把 新建任务 首页 结果模板 从同权 6 条入口继续收成“首选结果 + 更多结果 + 快捷做法”的强弱分层：
- 已更新：
  - src/components/agent/chat/components/EmptyState.tsx
  - src/components/agent/chat/components/EmptyState.test.tsx
  - docs/roadmap/limenextv2/implementation-roadmap.md
  - docs/exec-plans/limenext-progress.md
- 当前统一结论：
  - 结果模板 当前不再把 4 条 curated task 与 2 条 service skill 以同一层级平铺给用户，而是改成：
    - 首选结果：默认先看最常用、最泛用的 2 条结果入口
    - 更多结果：保留其余结果模板，作为第二层补充选择
    - 快捷做法：把现成 service skill 收成捷径层，不再与结果模板混成同一层
  - 这一步继续服务 P1 的首页默认复杂度收口，只做首页结果 shelf 的层级优化，不改运行时协议、不改 skill / launcher 主链
  - 首页当前更接近“先给用户一个最该点的结果入口”，而不是“把所有能点的入口平铺出来”
- 当前已确认通过：
  - npm exec vitest run "src/components/agent/chat/components/EmptyState.test.tsx"
  - npx eslint "src/components/agent/chat/components/EmptyState.tsx" "src/components/agent/chat/components/EmptyState.test.tsx"
  - npm run verify:local
  - npm run verify:gui-smoke 已包含在本次 verify:local 中，并实际跑通 workspace-ready / browser-runtime / site-adapters / agent-service-skill-entry / agent-runtime-tool-surface / agent-runtime-tool-surface-page
把 新建任务 首页 结果入口 继续补成“知道怎么开始，也知道结果会去哪”的轻闭环提示：
- 已更新：
  - src/components/agent/chat/components/EmptyState.tsx
  - src/components/agent/chat/components/EmptyStateSceneAppsPanel.tsx
  - src/components/agent/chat/components/EmptyState.test.tsx
  - docs/roadmap/limenextv2/implementation-roadmap.md
  - docs/exec-plans/limenext-progress.md
- 当前统一结论：
  - 结果入口 当前已新增轻量 结果去向 提示，明确本轮产出会沉淀到当前任务/项目，跑通过的方法会回到 继续上次做法，参考与反馈会继续影响下一轮推荐
  - 这一步继续服务 P1 的首页默认复杂度收口：不是再开一个结果面，而是在首页先把“结果不会丢、下次从哪继续”说清楚
  - 更多起手方式 当前也把说明文案再压短一层，继续保持补位入口，不重新长成解释性大块
- 当前已确认通过：
  - npm exec vitest run "src/components/agent/chat/components/EmptyState.test.tsx"
  - npx eslint "src/components/agent/chat/components/EmptyState.tsx" "src/components/agent/chat/components/EmptyStateSceneAppsPanel.tsx" "src/components/agent/chat/components/EmptyState.test.tsx"
  - npm run verify:local
  - npm run verify:gui-smoke 已包含在本次 verify:local 中，并实际跑通 workspace-ready / browser-runtime / site-adapters / agent-service-skill-entry / agent-runtime-tool-surface / agent-runtime-tool-surface-page
把 新建任务 首页原来平级的 结果模板 + 继续上次做法 收成同一个 结果入口 shelf，继续减少首页块级切换感：
- 已更新：
  - src/components/agent/chat/components/EmptyState.tsx
  - src/components/agent/chat/components/EmptyState.test.tsx
  - docs/roadmap/limenextv2/implementation-roadmap.md
  - docs/exec-plans/limenext-progress.md
- 当前统一结论：
  - 首页 supporting 区当前不再把 结果模板 和 继续上次做法 渲染成两个平级面板，而是先收成一个总标题为 结果入口 的 unified shelf
  - 结果入口 内部当前分成两个 section：上半段负责“先拿什么结果”，下半段负责“最近跑过什么做法”；空态时也在同一个容器里提示，不再额外长出独立空块
  - 更多起手方式 与 支撑能力 当前都退到 结果入口 后面，首页默认视觉重心继续稳定在 目标输入 + 当前项目 + 结果入口
  - 这一步仍属于 P1 的首页默认复杂度收口，只改前台组合层，不改协议、不改后端、不改 curated_task capability route
- 当前已确认通过：
  - npm exec vitest run "src/components/agent/chat/components/EmptyState.test.tsx"
  - npx eslint "src/components/agent/chat/components/EmptyState.tsx" "src/components/agent/chat/components/EmptyState.test.tsx"
  - npm run verify:local
  - npm run verify:gui-smoke 已包含在本次 verify:local 中，并实际跑通 workspace-ready / browser-runtime / site-adapters / agent-service-skill-entry / agent-runtime-tool-surface / agent-runtime-tool-surface-page
把 新建任务 首页底部的能力目录感继续收口一刀，改成“默认结果入口 + 按需展开支撑能力”的 current 前台结构：
- 已更新：
  - src/components/agent/chat/components/EmptyState.tsx
  - src/components/agent/chat/components/EmptyStateHero.tsx
  - src/components/agent/chat/components/EmptyStateSceneAppsPanel.tsx
  - src/components/agent/chat/components/EmptyState.test.tsx
  - docs/roadmap/limenextv2/implementation-roadmap.md
  - docs/exec-plans/limenext-progress.md
- 当前统一结论：
  - 首页底部 我的方法 / 持续流程 / 任务拆分 / 浏览器接入 4 张大卡当前不再默认常显，而是收成一个轻量 支撑能力 摘要层；用户需要时再手动展开
  - 支撑能力 摘要层当前会保留 methodSummaryLabel，并继续提供轻量 连接浏览器 快捷入口，避免把能力完全藏死
  - EmptyStateHero 当前只会在确实有卡片需要显示时才渲染底部卡片区，不再为空壳占位
  - 原 创作场景 区当前进一步降成 更多起手方式，明确它只是补位入口；如果用户已经知道想拿什么结果，优先走上方结果模板
  - 这一步仍属于 P1 的首页默认复杂度收口，不改协议、不改后端，只继续压低首页“能力超市 / 平台目录”观感
- 当前已确认通过：
  - npm exec vitest run "src/components/agent/chat/components/EmptyState.test.tsx"
  - npx eslint "src/components/agent/chat/components/EmptyState.tsx" "src/components/agent/chat/components/EmptyStateHero.tsx" "src/components/agent/chat/components/EmptyStateSceneAppsPanel.tsx" "src/components/agent/chat/components/EmptyState.test.tsx"
  - npm run verify:local
  - npm run verify:gui-smoke 已包含在本次 verify:local 中，并实际跑通 workspace-ready / browser-runtime / site-adapters / agent-service-skill-entry / agent-runtime-tool-surface / agent-runtime-tool-surface-page
把 新建任务 首页默认复杂度继续收口一刀，减少折叠态运行时噪音，稳住 目标输入 + 项目 + 结果模板 主入口：
- 已更新：
  - src/components/agent/chat/components/EmptyStateComposerPanel.tsx
  - src/components/agent/chat/components/EmptyState.tsx
  - src/components/agent/chat/components/EmptyStateComposerPanel.test.tsx
  - src/components/agent/chat/components/EmptyState.test.tsx
  - docs/roadmap/limenextv2/implementation-roadmap.md
  - docs/exec-plans/limenext-progress.md
- 当前统一结论：
  - 首页输入区折叠态当前不再暴露 当前模型 轻提示，也不再在未展开时直接露出模型选择器；Provider / Model / 权限模式 / Team 继续统一收在 高级设置
  - 首页 hero 徽标当前不再默认暴露 执行模式 / 联网搜索 等运行时状态，减少“系统控制台”观感
  - supporting 区当前改成 结果模板 -> 继续上次做法 -> 创作场景补位 的顺序，先让默认视觉重心回到结果入口
  - 这一步属于 P1 的首页默认复杂度收口，不改协议、不改后端，只继续压缩前台默认暴露
- 当前已确认通过：
  - npm exec vitest run "src/components/agent/chat/components/EmptyStateComposerPanel.test.tsx" "src/components/agent/chat/components/EmptyState.test.tsx"
  - npm run verify:local
  - npm run verify:gui-smoke 已包含在本次 verify:local 中，并实际跑通 workspace-ready / browser-runtime / site-adapters / agent-service-skill-entry / agent-runtime-tool-surface / agent-runtime-tool-surface-page
把 curated task featured 推荐从“固定 4 张卡”推进成“静态 base + 当前参考/最近保存信号”的 P3 第二刀，打通 当前参考 / 保存灵感 -> 下一轮推荐 回流：
- 已更新：
  - src/components/agent/chat/utils/curatedTaskRecommendationSignals.ts
  - src/components/agent/chat/utils/curatedTaskRecommendationSignals.test.ts
  - src/components/agent/chat/utils/curatedTaskTemplates.ts
  - src/components/agent/chat/components/EmptyState.tsx
  - src/components/agent/chat/components/EmptyState.test.tsx
  - src/components/skills/SkillsWorkspacePage.tsx
  - src/components/skills/SkillsWorkspacePage.test.tsx
  - src/components/agent/chat/AgentChatWorkspace.tsx
  - docs/roadmap/limenextv2/implementation-roadmap.md
  - docs/roadmap/limenextv2/skill-first-system.md
  - docs/exec-plans/limenext-progress.md
- 当前统一结论：
  - 首页空态与技能页 先拿结果 当前都会围绕 projectId + 当前 referenceEntries + 最近保存灵感 重新计算 featured 推荐
  - 推荐信号当前分成两类：active_reference 负责表达当前线程/launcher 已带入的参考对象；saved_inspiration 负责表达最近保存到灵感库的条目
  - 保存到灵感库 成功后，当前会立刻记录推荐信号并广播刷新事件；featured 推荐不再依赖 memory 的旧 updated_at
  - 推荐排序继续保留默认 4 张结果模板的 base 骨架，但强信号可以把 account-project-review 等非默认模板抬进前排，并给出“围绕当前参考 / 围绕最近收藏或偏好”等理由提示
  - 到这里为止，P3 已从“灵感带入生成”继续推进到“生成内保存与当前带入，都会影响下一轮结果模板建议”
- 当前已确认通过：
  - npm exec vitest run "src/components/agent/chat/utils/curatedTaskRecommendationSignals.test.ts" "src/components/agent/chat/components/EmptyState.test.tsx" "src/components/skills/SkillsWorkspacePage.test.tsx"
  - npx eslint "src/components/agent/chat/utils/curatedTaskRecommendationSignals.ts" "src/components/agent/chat/utils/curatedTaskRecommendationSignals.test.ts" "src/components/agent/chat/utils/curatedTaskTemplates.ts" "src/components/agent/chat/components/EmptyState.tsx" "src/components/agent/chat/components/EmptyState.test.tsx" "src/components/skills/SkillsWorkspacePage.tsx" "src/components/skills/SkillsWorkspacePage.test.tsx" "src/components/agent/chat/AgentChatWorkspace.tsx"
  - npm run typecheck
  - npm run verify:local
把 creation_replay 从“后台预填对象”推进成 生成主执行面 里的 current 前台对象，并打通 灵感库 -> 生成 -> 结果模板默认引用回流 这条 P3 第一刀：
- 已更新：
  - src/components/agent/chat/utils/curatedTaskReferenceSelection.ts
  - src/components/agent/chat/utils/creationReplaySurface.ts
  - src/components/agent/chat/components/CuratedTaskLauncherDialog.tsx
  - src/components/agent/chat/skill-selection/inputCapabilitySelection.ts
  - src/components/agent/chat/skill-selection/CharacterMention.tsx
  - src/components/agent/chat/components/Inputbar/components/InputbarComposerSection.tsx
  - src/components/agent/chat/components/Inputbar/hooks/useInputbarController.ts
  - src/components/agent/chat/components/Inputbar/index.tsx
  - src/components/agent/chat/workspace/useWorkspaceInputbarSceneRuntime.tsx
  - src/components/agent/chat/components/EmptyStateComposerPanel.tsx
  - src/components/agent/chat/components/EmptyState.tsx
  - src/components/agent/chat/workspace/chatSurfaceProps.ts
  - src/components/agent/chat/workspace/WorkspaceConversationScene.tsx
  - src/components/agent/chat/workspace/useWorkspaceConversationSceneRuntime.tsx
  - src/components/agent/chat/AgentChatWorkspace.tsx
  - src/components/agent/chat/skill-selection/CharacterMention.test.tsx
  - src/components/agent/chat/components/EmptyState.test.tsx
  - src/components/agent/chat/components/Inputbar/index.test.tsx
  - src/components/agent/chat/components/EmptyStateComposerPanel.test.tsx
  - src/components/agent/chat/workspace/WorkspaceConversationScene.test.tsx
  - docs/roadmap/limenextv2/implementation-roadmap.md
  - docs/roadmap/limenextv2/skill-first-system.md
  - docs/exec-plans/limenext-progress.md
- 当前统一结论：
  - creation_replay 当前不再只在 scene gate / service skill 里被内部消费；生成主执行面 已开始把它显影成“当前带入灵感 / 技能草稿”对象
  - 首页空态输入区当前也会露出同一条轻量提示，避免用户只在 entry banner 里看一次就丢
  - 从灵感库进入 生成 时带入的 memory_entry creation_replay，当前会自动成为结果模板 launcher 的默认 reference seed
  - 这条默认 seed 既会作用于首页结果模板，也会作用于 slash 面板里的结果模板
  - launcher 当前会合并保留 seed entry 与最近灵感列表；即使该条灵感不在最近列表中，也不会被静默丢掉
  - curated_task capabilityRoute 当前也已开始保留 referenceEntries，保证页面 bootstrap / 首屏恢复 / 再次编辑 launcher 时不只剩 id
- 当前已确认通过：
  - npm exec vitest run "src/components/agent/chat/skill-selection/CharacterMention.test.tsx" "src/components/agent/chat/components/EmptyState.test.tsx" "src/components/agent/chat/components/Inputbar/index.test.tsx" "src/components/agent/chat/components/EmptyStateComposerPanel.test.tsx" "src/components/agent/chat/workspace/WorkspaceConversationScene.test.tsx"
  - npx eslint "src/components/agent/chat/utils/curatedTaskReferenceSelection.ts" "src/components/agent/chat/utils/creationReplaySurface.ts" "src/components/agent/chat/components/CuratedTaskLauncherDialog.tsx" "src/components/agent/chat/skill-selection/inputCapabilitySelection.ts" "src/components/agent/chat/skill-selection/CharacterMention.tsx" "src/components/agent/chat/components/Inputbar/components/InputbarComposerSection.tsx" "src/components/agent/chat/components/Inputbar/hooks/useInputbarController.ts" "src/components/agent/chat/components/Inputbar/index.tsx" "src/components/agent/chat/workspace/useWorkspaceInputbarSceneRuntime.tsx" "src/components/agent/chat/components/EmptyStateComposerPanel.tsx" "src/components/agent/chat/components/EmptyState.tsx" "src/components/agent/chat/workspace/chatSurfaceProps.ts" "src/components/agent/chat/workspace/WorkspaceConversationScene.tsx" "src/components/agent/chat/workspace/useWorkspaceConversationSceneRuntime.tsx" "src/components/agent/chat/AgentChatWorkspace.tsx" "src/components/agent/chat/skill-selection/CharacterMention.test.tsx" "src/components/agent/chat/components/EmptyState.test.tsx" "src/components/agent/chat/components/Inputbar/index.test.tsx" "src/components/agent/chat/components/EmptyStateComposerPanel.test.tsx" "src/components/agent/chat/workspace/WorkspaceConversationScene.test.tsx"
把 curated task 的“可选灵感引用”从静态文案补成 current typed contract，打通 launcher -> route -> request metadata -> 生成 最小闭环：
- 已更新：
  - src/components/agent/chat/utils/curatedTaskReferenceSelection.ts
  - src/components/agent/chat/utils/curatedTaskReferenceSelection.test.ts
  - src/components/agent/chat/utils/curatedTaskTemplates.ts
  - src/components/agent/chat/skill-selection/inputCapabilitySelection.ts
  - src/components/agent/chat/components/CuratedTaskLauncherDialog.tsx
  - src/components/agent/chat/components/EmptyState.tsx
  - src/components/agent/chat/skill-selection/CharacterMention.tsx
  - src/components/agent/chat/components/Inputbar/hooks/useInputbarController.ts
  - src/components/agent/chat/components/Inputbar/hooks/useInputbarSend.ts
  - src/components/skills/SkillsWorkspacePage.tsx
  - src/components/agent/chat/components/Inputbar/index.test.tsx
  - src/components/agent/chat/components/EmptyState.test.tsx
  - src/components/skills/SkillsWorkspacePage.test.tsx
  - src/components/agent/chat/skill-selection/CharacterMention.test.tsx
  - docs/roadmap/limenextv2/implementation-roadmap.md
  - docs/roadmap/limenextv2/skill-first-system.md
  - docs/exec-plans/limenext-progress.md
- 当前统一结论：
  - launcher 当前会从灵感库最近更新中拉取候选项，允许在启动时附带轻量灵感引用
  - 这些引用会一起编进首轮 prompt，不再只是“可选参考”的说明文案
  - curated_task capabilityRoute 当前会正式保留 referenceMemoryIds
  - 发送时会同步写入 requestMetadata.harness.curated_task
  - 若存在引用，当前会把首条引用写进 creation_replay，以便后续主链继续消费
  - 到这里为止，首页 / 技能页 / slash / 生成内编辑 四个结果模板入口，当前都已经共享 catalog + launcher + prompt compile + route + metadata 这条 current 主链
- 当前已确认通过：
  - npm exec vitest run "src/components/agent/chat/utils/curatedTaskReferenceSelection.test.ts" "src/components/skills/SkillsWorkspacePage.test.tsx" "src/components/agent/chat/components/Inputbar/index.test.tsx" "src/components/agent/chat/components/EmptyState.test.tsx"
  - npm exec vitest run "src/components/agent/chat/skill-selection/CharacterMention.test.tsx"
  - npx eslint "src/components/agent/chat/utils/curatedTaskReferenceSelection.ts" "src/components/agent/chat/utils/curatedTaskReferenceSelection.test.ts" "src/components/agent/chat/utils/curatedTaskTemplates.ts" "src/components/agent/chat/skill-selection/inputCapabilitySelection.ts" "src/components/agent/chat/components/CuratedTaskLauncherDialog.tsx" "src/components/agent/chat/components/EmptyState.tsx" "src/components/agent/chat/skill-selection/CharacterMention.tsx" "src/components/agent/chat/components/Inputbar/hooks/useInputbarController.ts" "src/components/agent/chat/components/Inputbar/hooks/useInputbarSend.ts" "src/components/skills/SkillsWorkspacePage.tsx" "src/components/agent/chat/components/Inputbar/index.test.tsx" "src/components/agent/chat/components/EmptyState.test.tsx" "src/components/skills/SkillsWorkspacePage.test.tsx" "src/components/agent/chat/skill-selection/CharacterMention.test.tsx"
  - npm run verify:local
把 生成主执行面 里已经激活的 curated task，补成“可重新编辑启动信息”的完整闭环，不再只支持首发 launcher：
- 已更新：
  - src/components/agent/chat/components/Inputbar/hooks/useInputbarController.ts
  - src/components/agent/chat/components/Inputbar/index.tsx
  - src/components/agent/chat/components/Inputbar/index.test.tsx
  - src/components/agent/chat/components/EmptyState.tsx
  - src/components/agent/chat/components/EmptyStateComposerPanel.tsx
  - src/components/agent/chat/components/EmptyState.test.tsx
  - src/components/agent/chat/components/CuratedTaskLauncherDialog.tsx
  - src/components/agent/chat/skill-selection/CuratedTaskBadge.tsx
  - src/components/agent/chat/skill-selection/inputCapabilitySelection.ts
  - src/components/agent/chat/skill-selection/CharacterMention.tsx
  - src/components/agent/chat/utils/curatedTaskTemplates.ts
  - docs/exec-plans/limenext-progress.md
  - docs/roadmap/limenextv2/skill-first-system.md
  - docs/roadmap/limenextv2/implementation-roadmap.md
- 当前统一结论：
  - curated_task capabilityRoute 当前会正式保留 launchInputValues
  - 首页、slash、技能页桥接进 生成 后，active curated_task badge 都能重新打开同一套 launcher
  - 重新编辑时会回填原始启动字段，并基于目录模板重新编译 prompt，不再拿“已经编译过一次的 prompt”继续套娃
  - Inputbar 与首页空态当前都共享这条“编辑 -> 回填 -> 更新 route”的 current 主链
- 当前已确认通过：
  - npm exec vitest run "src/components/agent/chat/components/Inputbar/index.test.tsx"
  - npm exec vitest run "src/components/agent/chat/components/EmptyState.test.tsx"
  - npx eslint "src/components/agent/chat/components/Inputbar/index.test.tsx" "src/components/agent/chat/components/EmptyState.test.tsx" "src/components/agent/chat/components/Inputbar/hooks/useInputbarController.ts" "src/components/agent/chat/components/Inputbar/index.tsx" "src/components/agent/chat/components/EmptyState.tsx" "src/components/agent/chat/components/EmptyStateComposerPanel.tsx" "src/components/agent/chat/components/CuratedTaskLauncherDialog.tsx" "src/components/agent/chat/skill-selection/CuratedTaskBadge.tsx" "src/components/agent/chat/skill-selection/inputCapabilitySelection.ts" "src/components/agent/chat/skill-selection/CharacterMention.tsx" "src/components/agent/chat/utils/curatedTaskTemplates.ts"
把 slash 输入层里的 curated task 结果模板，也正式收口到同一套 launcher -> curated_task capability -> 生成主执行面 主链，不再保留“选择即写 base prompt”的输入层例外：
- 已更新：
  - src/components/agent/chat/skill-selection/CharacterMention.tsx
  - src/components/agent/chat/skill-selection/CharacterMention.test.tsx
  - docs/exec-plans/limenext-progress.md
  - docs/roadmap/limenextv2/skill-first-system.md
  - docs/roadmap/limenextv2/implementation-roadmap.md
- 当前统一结论：
  - slash 面板里的结果模板当前不再在选择瞬间把模板 prompt 直接塞回输入框
  - 选择后会先打开和首页、技能页同一套轻量 launcher，补齐 1 到 2 个最小启动字段
  - 确认后才会把编译后的 prompt 回填到输入框，并继续挂上 typed curated_task capability
  - 到这里为止，首页 / 技能页 / slash 输入层 三个结果模板入口，当前已经同时共享 catalog + launcher + capability route 三层协议
- 当前已确认通过：
  - npm exec vitest run "src/components/agent/chat/skill-selection/CharacterMention.test.tsx"
  - npx eslint "src/components/agent/chat/skill-selection/CharacterMention.tsx" "src/components/agent/chat/skill-selection/CharacterMention.test.tsx"
把首页 结果模板 与 继续上次做法 里的结果模板，也正式收口到同一套 curated task launcher -> 生成主执行面 主链，不再保留“点卡片即直接写 prompt”的首页例外：
- 已更新：
  - src/components/agent/chat/components/EmptyState.test.tsx
  - docs/exec-plans/limenext-progress.md
  - docs/roadmap/limenextv2/skill-first-system.md
  - docs/roadmap/limenextv2/implementation-roadmap.md
- 当前统一结论：
  - 首页 结果模板、继续上次做法 里的结果模板，以及技能页 先拿结果，当前都已对齐到同一个轻量 launcher
  - launcher 仍只负责补 1 到 2 个最小启动字段，然后把编译后的 prompt 通过 typed curated_task capability 带进 生成
  - 因此首页不再是 curated task 主链里的特例；skill-first 前台当前对结果模板只有一条 current 启动协议
  - 文档里关于“首页继续快速起手、不走 launcher”的旧描述，当前也已同步清理
- 当前已确认通过：
  - npm exec vitest run "src/components/agent/chat/components/EmptyState.test.tsx"
  - npx eslint "src/components/agent/chat/components/EmptyState.tsx" "src/components/agent/chat/components/EmptyState.test.tsx"
  - npm run verify:local
把 curated task 从“展示 skill 合同”继续推进成“技能页可填写的最小 launcher”，让 requiredInputs 不再只是说明文案：
- 已更新：
  - src/components/agent/chat/utils/curatedTaskTemplates.ts
  - src/components/agent/chat/components/CuratedTaskLauncherDialog.tsx
  - src/components/agent/chat/skill-selection/inputCapabilitySelection.ts
  - src/components/skills/SkillsWorkspacePage.tsx
  - src/components/skills/SkillsWorkspacePage.test.tsx
  - src/components/agent/chat/components/Inputbar/index.test.tsx
  - docs/exec-plans/limenext-progress.md
  - docs/roadmap/limenextv2/skill-first-system.md
  - docs/roadmap/limenextv2/implementation-roadmap.md
- 当前统一结论：
  - curated task 现在除了 requiredInputs 文案，还新增了真实可填写的 requiredInputFields
  - 技能页 先拿结果 点击后，不再直接把模板 prompt 裸带进 生成，而是先打开轻量 launcher dialog
  - 当前每条 curated task 只收 1 到 2 个最小启动字段，避免在技能页复制一整套重型 slot gate
  - launcher 会通过 buildCuratedTaskLaunchPrompt(...) 把用户填写的启动信息编译进首轮 prompt，再继续走 typed curated_task capability
  - 这意味着 P2 当前已经从“skill 合同可见”推进到“skill 合同可启动”，而不是继续停留在卡片说明层
- 当前已确认通过：
  - npm exec vitest run "src/components/skills/SkillsWorkspacePage.test.tsx" "src/components/agent/chat/components/Inputbar/index.test.tsx"
  - npx eslint "src/components/agent/chat/utils/curatedTaskTemplates.ts" "src/components/agent/chat/components/CuratedTaskLauncherDialog.tsx" "src/components/agent/chat/skill-selection/inputCapabilitySelection.ts" "src/components/skills/SkillsWorkspacePage.tsx" "src/components/skills/SkillsWorkspacePage.test.tsx" "src/components/agent/chat/components/Inputbar/index.test.tsx"
  - npm run typecheck
  - npm run governance:legacy-report
  - npm run verify:local

2026-04-18

已完成

把 curated task 从“typed capability 可发送”继续推进成“前台可理解的 skill 合同对象”，补齐 你来给 / 可选参考 / 会拿到 / 下一步 四类事实，并同步回首页与技能页：
- 已更新：
  - src/components/agent/chat/utils/curatedTaskTemplates.ts
  - src/components/agent/chat/components/EmptyState.tsx
  - src/components/skills/SkillsWorkspacePage.tsx
  - src/components/agent/chat/skill-selection/inputCapabilitySelection.ts
  - src/components/agent/chat/components/EmptyState.test.tsx
  - src/components/skills/SkillsWorkspacePage.test.tsx
  - src/components/agent/chat/components/Inputbar/index.test.tsx
  - docs/exec-plans/limenext-progress.md
  - docs/roadmap/limenextv2/skill-first-system.md
  - docs/roadmap/limenextv2/implementation-roadmap.md
- 当前统一结论：
  - curated task 当前不再只有 title / summary / prompt 这类轻量模板字段，而是已补齐：
    - requiredInputs
    - optionalReferences
    - outputContract
    - followUpActions
  - 首页 结果模板 当前已开始展示“需要什么输入、会拿到什么交付”的缩略事实，不再只是标题列表
  - 技能页 先拿结果 当前已开始展示更完整的 skill 合同视图，用户能在进入 生成 之前先理解：
    - 自己需要补什么
    - 可选参考能带什么
    - 这条 skill 会产出什么
    - 产出后还能怎么继续
  - 因此 curated task 当前已更接近 V2 设定里的正式 skill launcher，而不是仅靠 prompt 命名的“结果模板按钮”
- 当前已确认通过：
  - npm exec vitest run "src/components/agent/chat/components/EmptyState.test.tsx" "src/components/skills/SkillsWorkspacePage.test.tsx" "src/components/agent/chat/components/Inputbar/index.test.tsx"
  - npx eslint "src/components/agent/chat/utils/curatedTaskTemplates.ts" "src/components/agent/chat/components/EmptyState.tsx" "src/components/skills/SkillsWorkspacePage.tsx" "src/components/agent/chat/skill-selection/inputCapabilitySelection.ts" "src/components/agent/chat/components/EmptyState.test.tsx" "src/components/skills/SkillsWorkspacePage.test.tsx" "src/components/agent/chat/components/Inputbar/index.test.tsx"
  - npm run typecheck
  - npm run governance:legacy-report
  - npm run verify:gui-smoke
把 curated task 从共享 prompt catalog 继续推进成 current typed capability，补齐 首页 / 技能页 / slash / Inputbar 首屏恢复 同一条 route：
- 已更新：
  - src/components/agent/chat/skill-selection/inputCapabilitySelection.ts
  - src/components/agent/chat/workspace/inputCapabilityRouting.ts
  - src/components/agent/chat/skill-selection/CuratedTaskBadge.tsx
  - src/components/agent/chat/components/Inputbar/hooks/useInputbarController.ts
  - src/components/agent/chat/components/EmptyStateComposerPanel.tsx
  - src/components/agent/chat/components/EmptyState.tsx
  - src/components/skills/SkillsWorkspacePage.tsx
  - src/components/agent/chat/skill-selection/CharacterMention.tsx
  - src/components/AppPageContent.tsx
  - src/components/agent/chat/components/Inputbar/index.test.tsx
  - src/components/agent/chat/components/EmptyStateComposerPanel.test.tsx
  - src/components/agent/chat/components/EmptyState.test.tsx
  - src/components/skills/SkillsWorkspacePage.test.tsx
  - src/components/agent/chat/skill-selection/CharacterMention.test.tsx
  - src/components/AppPageContent.test.tsx
  - docs/exec-plans/limenext-progress.md
  - docs/roadmap/limenextv2/skill-first-system.md
  - docs/roadmap/limenextv2/implementation-roadmap.md
- 当前统一结论：
  - curated task 当前已正式进入 InputCapabilitySelection / InputCapabilitySendRoute / initialInputCapability 主链，不再只是 prompt catalog
  - 首页点结果模板后，当前不只是把 prompt 写进输入框，也会挂上 curated_task active capability；发送时会透传结构化 route
  - 技能页 先拿结果 当前不再依赖 initialUserPrompt 进 生成，而是像 installed skill 一样走 typed initialInputCapability
  - slash 面板里的结果模板当前会同时做两件事：回填用户可见 prompt，并激活 curated_task capability
  - Inputbar 首屏恢复当前已支持 curated_task；如果输入为空，会自动预填 route 内 prompt，并展示 badge
  - AppPageContent 当前也已把 curated_task 纳入页面 key 序列化；切换不同模板时不会复用旧工作区实例
- 当前已确认通过：
  - npm exec vitest run "src/components/agent/chat/components/Inputbar/index.test.tsx" "src/components/agent/chat/components/EmptyStateComposerPanel.test.tsx" "src/components/agent/chat/components/EmptyState.test.tsx" "src/components/skills/SkillsWorkspacePage.test.tsx" "src/components/agent/chat/skill-selection/CharacterMention.test.tsx" "src/components/AppPageContent.test.tsx"
  - npx eslint "src/components/agent/chat/skill-selection/inputCapabilitySelection.ts" "src/components/agent/chat/workspace/inputCapabilityRouting.ts" "src/components/agent/chat/skill-selection/CuratedTaskBadge.tsx" "src/components/agent/chat/components/Inputbar/hooks/useInputbarController.ts" "src/components/agent/chat/components/EmptyStateComposerPanel.tsx" "src/components/agent/chat/components/EmptyState.tsx" "src/components/skills/SkillsWorkspacePage.tsx" "src/components/agent/chat/skill-selection/CharacterMention.tsx" "src/components/AppPageContent.tsx" "src/components/agent/chat/components/Inputbar/index.test.tsx" "src/components/agent/chat/components/EmptyStateComposerPanel.test.tsx" "src/components/agent/chat/components/EmptyState.test.tsx" "src/components/skills/SkillsWorkspacePage.test.tsx" "src/components/agent/chat/skill-selection/CharacterMention.test.tsx" "src/components/AppPageContent.test.tsx"
  - npm run typecheck
  - npm run governance:legacy-report
  - npm run verify:gui-smoke
把 结果模板 从首页私有推荐 util 提升成共享 curated task catalog，并同时接回 新建任务 / 我的方法 / slash 输入层 三个前台入口：
- 已更新：
  - src/components/agent/chat/utils/curatedTaskTemplates.ts
  - src/components/agent/chat/components/EmptyState.tsx
  - src/components/skills/SkillsWorkspacePage.tsx
  - src/components/agent/chat/skill-selection/inputCapabilitySections.ts
  - src/components/agent/chat/skill-selection/CharacterMention.tsx
  - src/components/agent/chat/skill-selection/CharacterMentionPanel.tsx
  - src/components/agent/chat/components/EmptyState.test.tsx
  - src/components/skills/SkillsWorkspacePage.test.tsx
  - src/components/agent/chat/skill-selection/CharacterMention.test.tsx
  - docs/exec-plans/limenext-progress.md
  - docs/roadmap/limenextv2/skill-first-system.md
  - docs/roadmap/limenextv2/implementation-roadmap.md
- 当前统一结论：
  - 首页里的 结果模板 不再只是一组 EmptyState 私有 prompt 推荐；现在它已经被收成共享 curated task catalog
  - 我的方法 页右侧新增了 先拿结果 桥接区；因此结果模板不再只存在于首页，技能页也能用同一套 curated task 把用户带回 生成
  - @ / / 输入层当前也会展示同一套 curated task；slash 选择后会把模板 prompt 回填到输入框并记录最近使用，不再只有 runtime scene 能占据 结果模板 分组
  - 到这里为止，首页结果模板 / 技能页桥接入口 / slash 结果模板 已共用同一份前台事实源；结果模板 不再在三个入口里各讲各的话
- 当前已确认通过：
  - npm exec vitest run "src/components/agent/chat/components/EmptyState.test.tsx" "src/components/skills/SkillsWorkspacePage.test.tsx" "src/components/agent/chat/skill-selection/CharacterMention.test.tsx"
  - npx eslint "src/components/agent/chat/utils/curatedTaskTemplates.ts" "src/components/agent/chat/components/EmptyState.tsx" "src/components/agent/chat/components/EmptyState.test.tsx" "src/components/skills/SkillsWorkspacePage.tsx" "src/components/skills/SkillsWorkspacePage.test.tsx" "src/components/agent/chat/skill-selection/inputCapabilitySections.ts" "src/components/agent/chat/skill-selection/CharacterMention.tsx" "src/components/agent/chat/skill-selection/CharacterMentionPanel.tsx" "src/components/agent/chat/skill-selection/CharacterMention.test.tsx"
  - npm run typecheck
把 AppPageContent 这一层壳也补回 initialInputCapability current 主链，避免技能页直达生成时在页面分发层丢参或错误复用旧工作区实例：
- 已更新：
  - src/components/AppPageContent.tsx
  - src/components/AppPageContent.test.tsx
  - docs/exec-plans/limenext-progress.md
  - docs/roadmap/limenextv2/runtime-architecture.md
- 当前统一结论：
  - AgentPageParams.initialInputCapability 当前不再只停留在页面参数类型和 AgentChatPage 直接测试里；AppPageContent 已正式透传这层 bootstrap 给 AgentChatPage
  - AppPageContent 当前也已把 initialInputCapability 纳入 AgentChatPage key；因此从技能页或其他入口连续切换不同 installed skill / capability 时，会重建对应工作区实例，而不是偷偷复用上一条 current capability
  - 到这里为止，技能页 -> 页面路由 -> Agent 壳 -> Inputbar 首屏恢复 这条 current 主链已经闭合，不再只有中间层正确、页面壳层漏参
- 当前已确认通过：
  - npm exec vitest run "src/components/AppPageContent.test.tsx" "src/components/agent/chat/index.shell-routing.test.tsx" "src/components/skills/SkillsWorkspacePage.test.tsx"
  - npx eslint "src/components/AppPageContent.tsx" "src/components/AppPageContent.test.tsx"
  - npm run typecheck
  - npm run governance:legacy-report
  - npm run verify:gui-smoke
把 技能页 / 新建任务页 -> 生成 的 installed skill 入口也收口到 typed capability bootstrap，不再让“我的方法库”继续停留在被动展示：
- 已更新：
  - src/types/page.ts
  - src/components/agent/chat/agentChatWorkspaceContract.ts
  - src/components/agent/chat/workspaceEntry.ts
  - src/components/agent/chat/index.tsx
  - src/components/agent/chat/AgentChatWorkspace.tsx
  - src/components/agent/chat/workspace/useWorkspaceInputbarSceneRuntime.tsx
  - src/components/agent/chat/components/Inputbar/index.tsx
  - src/components/agent/chat/components/Inputbar/hooks/useInputbarController.ts
  - src/components/agent/chat/skill-selection/inputCapabilitySelection.ts
  - src/components/skills/SkillsWorkspacePage.tsx
  - src/components/agent/chat/workspaceEntry.test.ts
  - src/components/agent/chat/index.shell-routing.test.tsx
  - src/components/agent/chat/components/Inputbar/index.test.tsx
  - src/components/skills/SkillsWorkspacePage.test.tsx
  - docs/exec-plans/limenext-progress.md
  - docs/roadmap/limenextv2/runtime-architecture.md
  - docs/roadmap/limenextv2/skill-first-system.md
  - docs/roadmap/limenextv2/implementation-roadmap.md
- 当前统一结论：
  - service skill 继续通过 initialPendingServiceSkillLaunch 进入 生成 内 A2UI 补参主链；而 installed skill 当前则统一通过 initialInputCapability 恢复首屏 active capability
  - Inputbar 当前可以在首屏根据 typed capabilityRoute 恢复 builtin_command / installed_skill / runtime_scene，因此从技能页进入 生成 不再需要伪造 /<skill-key> 文本
  - 我的方法库 里的已安装 skill 当前已经不再只是目录卡，而是可以像 current curated service skill 一样，直接把用户带进 生成 主执行面
  - AgentChatPage / workspaceEntry 当前也已把 initialInputCapability 视为 direct workspace intent；因此新建任务入口不会再把这类请求误判成“空白首页”
- 当前已确认通过：
  - npm exec vitest run "src/components/agent/chat/workspaceEntry.test.ts" "src/components/agent/chat/index.shell-routing.test.tsx" "src/components/agent/chat/components/Inputbar/index.test.tsx" "src/components/skills/SkillsWorkspacePage.test.tsx"
  - npm run typecheck
  - npx eslint "src/types/page.ts" "src/components/agent/chat/skill-selection/inputCapabilitySelection.ts" "src/components/agent/chat/agentChatWorkspaceContract.ts" "src/components/agent/chat/workspaceEntry.ts" "src/components/agent/chat/index.tsx" "src/components/agent/chat/AgentChatWorkspace.tsx" "src/components/agent/chat/workspace/useWorkspaceInputbarSceneRuntime.tsx" "src/components/agent/chat/components/Inputbar/index.tsx" "src/components/agent/chat/components/Inputbar/hooks/useInputbarController.ts" "src/components/agent/chat/workspaceEntry.test.ts" "src/components/agent/chat/index.shell-routing.test.tsx" "src/components/agent/chat/components/Inputbar/index.test.tsx" "src/components/skills/SkillsWorkspacePage.tsx" "src/components/skills/SkillsWorkspacePage.test.tsx"
  - npm run governance:legacy-report
  - npm run verify:gui-smoke
把 EmptyStateComposerPanel -> CharacterMention 也收口到统一 capability 选择边界，不再让首页输入壳保留旧 onSelectSkill 主语义：
- 已更新：
  - src/components/agent/chat/components/EmptyState.tsx
  - src/components/agent/chat/components/EmptyStateComposerPanel.tsx
  - src/components/agent/chat/components/EmptyState.test.tsx
  - docs/exec-plans/limenext-progress.md
  - docs/roadmap/limenextv2/runtime-architecture.md
- 当前统一结论：
  - 首页输入壳当前也会像工作区 Inputbar 一样，把 CharacterMention 选择统一回调为 onSelectInputCapability
  - 首页当前不只支持已安装 skill 的结构化发送，也支持 builtin command / runtime scene 的激活态显示、清除与结构化 route 透传
  - 因此 EmptyState 不再是“发送链统一、输入选择层仍旧语义”的半收口状态；首页 capability 主链当前已从选择、展示到发送保持同一套判断
- 当前已确认通过：
  - npm exec vitest run "src/components/agent/chat/components/EmptyState.test.tsx" "src/components/agent/chat/components/EmptyStateComposerPanel.test.tsx"
  - npx eslint "src/components/agent/chat/components/EmptyState.tsx" "src/components/agent/chat/components/EmptyState.test.tsx" "src/components/agent/chat/components/EmptyStateComposerPanel.tsx" "src/components/agent/chat/components/EmptyStateComposerPanel.test.tsx"
  - npm run typecheck
把 Inputbar / EmptyState 运行时页面里的 skillSelection 直构造也回收到共享绑定边界，补齐 governance 收口：
- 已更新：
  - src/components/agent/chat/components/Inputbar/hooks/useInputbarController.ts
  - src/components/agent/chat/components/EmptyState.tsx
  - src/components/agent/chat/skill-selection/skillSelectionBindings.ts
  - docs/exec-plans/limenext-progress.md
  - docs/roadmap/limenextv2/runtime-architecture.md
- 当前统一结论：
  - Inputbar / EmptyState 当前不再在运行时代码里 direct createSkillSelectionProps(...)，而是统一回到共享 skillSelectionBindings 边界
  - 因此 current 主路径的页面层不再一边走 activeCapability，一边再偷偷拼一套旧 skill selection 运行时模型
  - 这一步补齐了治理守卫要求的 skill-selection-direct-construction-runtime-usage，避免后续 AI 继续从页面层长回旧选择协议
- 当前已确认通过：
  - npm exec vitest run "src/components/agent/chat/components/EmptyState.test.tsx" "src/components/agent/chat/components/EmptyStateComposerPanel.test.tsx" "src/components/agent/chat/components/Inputbar/index.test.tsx"
  - npx eslint "src/components/agent/chat/components/EmptyState.tsx" "src/components/agent/chat/components/EmptyState.test.tsx" "src/components/agent/chat/components/EmptyStateComposerPanel.tsx" "src/components/agent/chat/components/Inputbar/hooks/useInputbarController.ts" "src/components/agent/chat/skill-selection/skillSelectionBindings.ts"
  - npm run governance:legacy-report
  - npm run typecheck
把 EmptyState 首页入口也接回统一 capability 主链，不再把已安装 skill 降级成文本前缀发送：
- 已更新：
  - src/components/agent/chat/components/EmptyState.tsx
  - src/components/agent/chat/components/EmptyState.test.tsx
  - src/components/agent/chat/AgentChatWorkspace.tsx
  - src/components/agent/chat/workspace/useWorkspaceConversationSceneRuntime.tsx
  - docs/exec-plans/limenext-progress.md
  - docs/roadmap/limenextv2/runtime-architecture.md
- 当前统一结论：
  - 首页空态当前不再使用 useActiveSkill / wrapTextWithSkill 把已安装 skill 拼成 /<skill-key> ... 文本后再发送，而是改为与 Inputbar 同源的 capabilityRoute + displayContent
  - handleSendFromEmptyState 当前已支持把结构化 sendOptions 继续交给主发送链；因此首页入口与工作区输入栏不再各说一套发送协议
  - 首页在“先选 installed skill，再切到 service skill / 做法卡 / 服务技能入口”时，当前会主动清掉旧 capability，不再残留过期 skill route
  - 到这里为止，生成 current 主路径里至少两条核心入口已经统一到同一套 capability 语义：
    - 工作区 Inputbar
    - 首页 EmptyState
- 当前已确认通过：
  - npm exec vitest run "src/components/agent/chat/components/EmptyState.test.tsx" "src/components/agent/chat/workspace/useWorkspaceConversationSceneRuntime.test.ts"
  - npx eslint "src/components/agent/chat/components/EmptyState.tsx" "src/components/agent/chat/components/EmptyState.test.tsx" "src/components/agent/chat/AgentChatWorkspace.tsx" "src/components/agent/chat/workspace/useWorkspaceConversationSceneRuntime.tsx"
  - npm run typecheck
  - npm run verify:gui-smoke
把 CharacterMention -> Inputbar 的能力选择事件也收口成单一 current 边界，不再让 builtin / scene / installed skill 在主路径里各走一套接线：
- 已更新：
  - src/components/agent/chat/skill-selection/inputCapabilitySelection.ts
  - src/components/agent/chat/skill-selection/CharacterMention.tsx
  - src/components/agent/chat/skill-selection/CharacterMention.test.tsx
  - src/components/agent/chat/components/Inputbar/components/InputbarComposerSection.tsx
  - src/components/agent/chat/components/Inputbar/hooks/useInputbarController.ts
  - src/components/agent/chat/components/Inputbar/index.tsx
  - src/components/agent/chat/components/Inputbar/index.test.tsx
  - docs/exec-plans/limenext-progress.md
  - docs/roadmap/limenextv2/runtime-architecture.md
- 当前统一结论：
  - Inputbar 当前不再分别向 CharacterMention 透传 onSelectBuiltinCommand / onSelectSceneCommand / onSelectSkill 三套能力选择回调，而是统一改用 onSelectInputCapability
  - CharacterMention 当前已支持把 builtin_command / installed_skill / runtime_scene 统一回调给父层 current 主路径；因此 InputbarController 内部的 active capability 不再需要靠三条并行接线去维持
  - service skill / A2UI 补参分支仍然保持独立入口；这条例外只服务必填 slot gate，不再影响“生成只有一条 capability 主链”的判断
  - 到这里为止，current 主路径的统一 capability 边界已经同时进入：
    - 输入层 active capability 状态
    - 面板到输入栏的选择事件边界
    - 发送链的结构化 route 恢复
- 当前已确认通过：
  - npm exec vitest run "src/components/agent/chat/skill-selection/CharacterMention.test.tsx" "src/components/agent/chat/components/Inputbar/index.test.tsx"
  - npx eslint "src/components/agent/chat/skill-selection/CharacterMention.tsx" "src/components/agent/chat/skill-selection/CharacterMention.test.tsx" "src/components/agent/chat/components/Inputbar/components/InputbarComposerSection.tsx" "src/components/agent/chat/components/Inputbar/hooks/useInputbarController.ts" "src/components/agent/chat/components/Inputbar/index.tsx" "src/components/agent/chat/components/Inputbar/index.test.tsx"
  - npm run typecheck
  - npm run verify:gui-smoke
把 slash 面板里的已安装技能也接回 activeCapability，继续压缩“输入层文本回填”和“发送链结构化路由”之间的缝：
- 已更新：
  - src/components/agent/chat/skill-selection/CharacterMention.tsx
  - src/components/agent/chat/skill-selection/CharacterMention.test.tsx
  - docs/exec-plans/limenext-progress.md
  - docs/roadmap/limenextv2/runtime-architecture.md
- 当前统一结论：
  - slash 面板里的 installed skill 当前在存在父层 onSelectSkill 接管时，不再默认回填 /<skill-key> 文本，而是改成与 runtime_scene 相同的 active capability 语义
  - 最近使用的 slash skill 当前也会优先把 replayText 回填为用户可见正文，再切到 active skill；因此“最近使用”不再偷偷把内部 /skill-key 路由文本重新写回输入框
  - 未提供父层接管时，slash installed skill 仍保持原 fallback：继续回填 /<skill-key>，所以这刀没有打断独立 CharacterMention 的旧使用方式
  - 到这里为止，输入层的 current capability 语义已经对齐到三类主对象：
    - builtin_command
    - installed_skill
    - runtime_scene
- 当前已确认通过：
  - npm exec vitest run "src/components/agent/chat/skill-selection/CharacterMention.test.tsx" "src/components/agent/chat/components/Inputbar/index.test.tsx"
  - npx eslint "src/components/agent/chat/skill-selection/CharacterMention.tsx" "src/components/agent/chat/skill-selection/CharacterMention.test.tsx"
  - npm run typecheck
  - npm run verify:gui-smoke
把 slash 面板里的 runtime scene 选择正式接进 activeCapability，让输入层与发送层对 scene 的理解不再分叉：
- 已更新：
  - src/components/agent/chat/skill-selection/inputCapabilitySelection.ts
  - src/components/agent/chat/skill-selection/CharacterMention.tsx
  - src/components/agent/chat/skill-selection/CharacterMention.test.tsx
  - src/components/agent/chat/components/Inputbar/components/RuntimeSceneBadge.tsx
  - src/components/agent/chat/components/Inputbar/components/InputbarComposerSection.tsx
  - src/components/agent/chat/components/Inputbar/hooks/useInputbarController.ts
  - src/components/agent/chat/components/Inputbar/index.tsx
  - src/components/agent/chat/components/Inputbar/index.test.tsx
  - docs/exec-plans/limenext-progress.md
- 当前统一结论：
  - slash 面板里选择 scene command 时，如果不是“必填 slot 先交给 A2UI 补参”的场景，当前会像 builtin command 一样切换成 activeCapability，而不是继续把 /scene-key 前缀回填进输入框
  - runtime scene 当前已拥有和 builtin command / installed skill 对齐的输入层语义：
    - 选择后保留用户正文输入
    - 顶部显示可清除 badge
    - 发送时由 capabilityRoute 恢复内部路由文本
    - 成功后由发送链统一回写 slash recent usage
  - 最近使用的 scene 当前也会优先把 replayText 回填为用户可见正文，并同时挂上 runtime_scene active capability，不再重新把 /scene-key replayText 写回输入框
  - 需要 slot gate / A2UI 的 scene 当前保持原路径：仍优先交给 onSelectServiceSkill，这刀不把 scene 补参 UX 和 active capability 混成一团
- 当前已确认通过：
  - npm exec vitest run "src/components/agent/chat/skill-selection/CharacterMention.test.tsx" "src/components/agent/chat/components/Inputbar/index.test.tsx"
  - npx eslint "src/components/agent/chat/skill-selection/inputCapabilitySelection.ts" "src/components/agent/chat/skill-selection/CharacterMention.tsx" "src/components/agent/chat/skill-selection/CharacterMention.test.tsx" "src/components/agent/chat/components/Inputbar/components/RuntimeSceneBadge.tsx" "src/components/agent/chat/components/Inputbar/components/InputbarComposerSection.tsx" "src/components/agent/chat/components/Inputbar/hooks/useInputbarController.ts" "src/components/agent/chat/components/Inputbar/index.tsx" "src/components/agent/chat/components/Inputbar/index.test.tsx"
  - npm run typecheck
  - npm run verify:gui-smoke
把 capabilityRoute 从“发送前的结构化提示”继续推进成发送链内的第一版统一 capability router，并把 runtime scene 也纳入同一入口：
- 已更新：
  - src/components/agent/chat/skill-selection/inputCapabilitySelection.ts
  - src/components/agent/chat/workspace/inputCapabilityRouting.ts
  - src/components/agent/chat/workspace/useWorkspaceSendActions.ts
  - src/components/agent/chat/workspace/useWorkspaceSendActions.test.tsx
  - docs/exec-plans/limenext-progress.md
  - docs/roadmap/limenextv2/runtime-architecture.md
- 当前统一结论：
  - Inputbar 继续只传 displayContent + capabilityRoute，不再回退去预拼 @前缀、/skill-key 或 scene 文本；真正的内部执行文本恢复点现在固定在 useWorkspaceSendActions -> inputCapabilityRouting
  - inputCapabilityRouting 当前已统一承担三件事：恢复 builtin command / installed skill / runtime scene 的内部执行文本、推导 runtime scene 的结构化 route、产出 slash recent usage 的第一版统一结果
  - 纯文本输入的 /scene-key ... 当前也会在发送链内被推导成 runtime_scene route，再继续进入 service_scene_launch 主链；后续输入层如果直接给 scene route，也能复用同一条恢复逻辑
  - executeSendPlan 当前不再在发送后额外补一层“installed skill fallback usage”旁路；slash usage 统一从 plan 内的 completedSlashUsage 回写，避免 route 恢复与 usage 记录再次分叉
  - 当发送链因为默认参数补全等原因改写了真正 dispatch 文本时，displayContent 当前也会优先保留用户原始可见文案，不再被内部路由前缀污染
- 当前已确认通过：
  - npm exec vitest run "src/components/agent/chat/workspace/useWorkspaceSendActions.test.tsx"
  - npx eslint "src/components/agent/chat/skill-selection/inputCapabilitySelection.ts" "src/components/agent/chat/workspace/inputCapabilityRouting.ts" "src/components/agent/chat/workspace/useWorkspaceSendActions.ts" "src/components/agent/chat/workspace/useWorkspaceSendActions.test.tsx"
  - npm run typecheck
  - npm run verify:gui-smoke
把输入栏里“已选 capability 只是偷偷改写前缀文本”的旧做法继续收口成显式 dispatch route，并让发送链第一次吃到结构化的 active capability：
- 已更新：
  - src/components/agent/chat/skill-selection/inputCapabilitySelection.ts
  - src/components/agent/chat/hooks/handleSendTypes.ts
  - src/components/agent/chat/components/Inputbar/hooks/useInputbarSend.ts
  - src/components/agent/chat/components/Inputbar/hooks/useInputbarController.ts
  - src/components/agent/chat/components/Inputbar/index.tsx
  - src/components/agent/chat/components/Inputbar/index.test.tsx
  - src/components/agent/chat/workspace/useWorkspaceSendActions.ts
  - src/components/agent/chat/workspace/useWorkspaceSendActions.test.tsx
  - docs/exec-plans/limenext-progress.md
- 当前统一结论：
  - Inputbar 当前在发送 active capability 时，不再只把能力压扁成 @前缀 或 /skill-key 文本；现在会同时透传结构化 capabilityRoute
  - 已选 builtin command / installed skill 当前都会把原始输入保存在 displayContent 里，因此线程里展示给用户看的文案可以继续保持“我真正输入了什么”，而不是被路由前缀污染
  - useWorkspaceSendActions 当前已经开始消费这层 route：installed skill 成功发送后，会按显式 capabilityRoute 回写 slash 最近使用，不再只能依赖“用户是否手动输入了 /skill-key ...”去猜测
  - 这一步把 active capability -> 发送链 从“文本技巧”推进成了第一版结构化 current 路由，也给后面继续抽统一 capability router 留出了明确边界
- 当前已确认通过：
  - npm exec vitest run "src/components/agent/chat/components/Inputbar/index.test.tsx" "src/components/agent/chat/workspace/useWorkspaceSendActions.test.tsx"
  - npx eslint "src/components/agent/chat/skill-selection/inputCapabilitySelection.ts" "src/components/agent/chat/hooks/handleSendTypes.ts" "src/components/agent/chat/components/Inputbar/hooks/useInputbarSend.ts" "src/components/agent/chat/components/Inputbar/hooks/useInputbarController.ts" "src/components/agent/chat/components/Inputbar/index.tsx" "src/components/agent/chat/components/Inputbar/index.test.tsx" "src/components/agent/chat/workspace/useWorkspaceSendActions.ts" "src/components/agent/chat/workspace/useWorkspaceSendActions.test.tsx"
  - npm run typecheck
  - npm run verify:gui-smoke
把 runtime scene 的匹配规则从“面板一套、发送链一套”收口成共享 scene binding helper，并补上完整 current 门槛验证：
- 已更新：
  - src/components/agent/chat/service-skills/runtimeSceneBinding.ts
  - src/components/agent/chat/service-skills/runtimeSceneBinding.test.ts
  - src/components/agent/chat/skill-selection/CharacterMention.tsx
  - src/components/agent/chat/workspace/serviceSkillSceneLaunch.ts
  - src/components/agent/chat/workspace/serviceSkillSceneLaunch.test.ts
  - docs/exec-plans/limenext-progress.md
- 当前统一结论：
  - CharacterMention 当前不再自己维护 scene -> service skill 的匹配规则，slash 面板里“这个 scene 是否应回落成 service skill / A2UI 补参”统一改读 runtimeSceneBinding
  - serviceSkillSceneLaunch 当前也不再单独维护 scene token、alias 与 linkedSkillId 的另一套判断；UI 面板和发送链对 sceneKey / commandPrefix / aliases / linkedSkillId 的理解已对齐
  - 这一步把 生成 主链里最容易漂移的一段 current 事实源先钉住：slash 发现面、scene 发射器和后续 service skill 回落不再各自解释“什么叫同一个场景”
- 当前已确认通过：
  - npm exec vitest run "src/components/agent/chat/service-skills/runtimeSceneBinding.test.ts" "src/components/agent/chat/workspace/serviceSkillSceneLaunch.test.ts" "src/components/agent/chat/skill-selection/CharacterMention.test.tsx"
  - npx eslint "src/components/agent/chat/service-skills/runtimeSceneBinding.ts" "src/components/agent/chat/service-skills/runtimeSceneBinding.test.ts" "src/components/agent/chat/skill-selection/CharacterMention.tsx" "src/components/agent/chat/workspace/serviceSkillSceneLaunch.ts" "src/components/agent/chat/workspace/serviceSkillSceneLaunch.test.ts"
  - npm run typecheck
  - npm run verify:local
把 runtime capability catalog 从组件私有拼装继续收口成共享模块，并让输入面板与发送链各自读取同一套 current 目录选择器：
- 已更新：
  - src/components/agent/chat/skill-selection/runtimeInputCapabilityCatalog.ts
  - src/components/agent/chat/skill-selection/runtimeInputCapabilityCatalog.test.tsx
  - src/components/agent/chat/skill-selection/CharacterMention.tsx
  - src/components/agent/chat/workspace/useWorkspaceSendActions.ts
  - docs/exec-plans/limenext-progress.md
- 当前统一结论：
  - CharacterMention 当前不再自己订阅和组装 runtime skill catalog，而是统一改读 useRuntimeInputCapabilityCatalog；因此 @ / / 面板里的 builtin command 与 runtime scene 列表不再是组件内私有事实源
  - useWorkspaceSendActions 当前也不再直接扫 skillCatalog 自建 mention command 两张 Map，而是改读同模块下的 useRuntimeMentionCommandCatalog
  - 这一步特意把发送链做成“只拿自己真正需要的 mention 路由映射”，不再为了发送前补全 @命令 最近输入而顺手依赖整份 scene 列表；因此 current 主线更接近我们要的 typed capability registry，而不是继续把 UI 搜索目录和发送路由耦在一起
  - 到这里为止，@ / / current 主线已经形成三层同源收口：输入分组与激活态共享 capability section builder、scene 回落共享 runtime scene binding、发送链共享 runtime mention catalog
- 当前已确认通过：
  - npm exec vitest run "src/components/agent/chat/skill-selection/runtimeInputCapabilityCatalog.test.tsx" "src/components/agent/chat/skill-selection/CharacterMention.test.tsx" "src/components/agent/chat/workspace/useWorkspaceSendActions.test.tsx"
  - npx eslint "src/components/agent/chat/skill-selection/runtimeInputCapabilityCatalog.ts" "src/components/agent/chat/skill-selection/runtimeInputCapabilityCatalog.test.tsx" "src/components/agent/chat/skill-selection/CharacterMention.tsx" "src/components/agent/chat/workspace/useWorkspaceSendActions.ts"
  - npm run typecheck
  - npm run verify:gui-smoke
把 生成 输入层的选择态与分组态往统一 capability registry 收口了一刀，不再让内建命令与已安装 skill 各持一套独立选择状态：
- 已更新：
  - src/components/agent/chat/skill-selection/inputCapabilitySelection.ts
  - src/components/agent/chat/skill-selection/inputCapabilitySections.ts
  - src/components/agent/chat/skill-selection/CharacterMentionPanel.tsx
  - src/components/agent/chat/components/Inputbar/hooks/useInputbarController.ts
  - src/components/agent/chat/components/Inputbar/hooks/useInputbarSend.ts
  - src/components/agent/chat/components/Inputbar/index.test.tsx
  - docs/exec-plans/limenext-progress.md
- 当前统一结论：
  - @ / / 面板当前已开始消费同一份前端 capability section builder：最近使用、内建命令、推荐技能、技能组、快捷操作、结果模板等分组不再散落在 CharacterMentionPanel 内部各自维护
  - 输入栏当前的“已选 capability”不再拆成 activeBuiltinCommand + activeSkill 两套状态，而是统一收口成单一 active capability；因此“先选内建命令再选 skill”这类链路会以后一次选择为准，不会再残留旧能力覆盖发送文本
  - 这一步仍属于前端 current 路径的第一版 unified capability registry：先收口输入层事实源与激活态，不引入新的后端协议，也不扩第二套执行系统
- 当前已确认通过：
  - npm exec vitest run "src/components/agent/chat/skill-selection/CharacterMention.test.tsx" "src/components/agent/chat/components/Inputbar/index.test.tsx"
  - npx eslint "src/components/agent/chat/skill-selection/inputCapabilitySelection.ts" "src/components/agent/chat/skill-selection/inputCapabilitySections.ts" "src/components/agent/chat/skill-selection/CharacterMentionPanel.tsx" "src/components/agent/chat/components/Inputbar/hooks/useInputbarController.ts" "src/components/agent/chat/components/Inputbar/hooks/useInputbarSend.ts" "src/components/agent/chat/components/Inputbar/index.test.tsx"
把 unified capability registry 这一刀补齐到“能完整过当前统一门槛”，并顺手修掉服务技能入口残留旧 capability 的发送链污染：
- 已更新：
  - src/components/agent/chat/skill-selection/inputCapabilitySections.ts
  - src/components/skills/WorkflowProgress.test.tsx
  - src/components/agent/chat/components/Inputbar/hooks/useInputbarController.ts
  - src/components/agent/chat/components/Inputbar/index.test.tsx
  - docs/exec-plans/limenext-progress.md
- 当前统一结论：
  - inputCapabilitySections 里最近使用分组的联合类型已经显式收口，不再因为 flatMap 首分支推断过窄，把 service_skill / scene_command / installed_skill 误判成非法返回值
  - WorkflowProgress.test.tsx 已补齐当前 WorkflowStepInfo.dependencies 与 StepResult.step_name 契约，verify:local 不再被落后的测试夹具卡住
  - 输入栏当前在“先选 @命令，再切到服务技能入口”时会主动清掉旧 active capability，不再把前一次 builtin command 前缀偷偷带进后续发送
  - 这一步继续沿着 V2 的同一条主线推进：@ / / 不只是 UI 分组统一，还要保证 capability 激活态、服务技能入口和最终发送链属于同一套 current 行为
- 当前已确认通过：
  - npm run verify:local
  - npm run typecheck
  - npm exec vitest run "src/components/agent/chat/components/Inputbar/index.test.tsx" "src/components/skills/WorkflowProgress.test.tsx"
  - npx eslint "src/components/agent/chat/skill-selection/inputCapabilitySections.ts" "src/components/agent/chat/components/Inputbar/hooks/useInputbarController.ts" "src/components/agent/chat/components/Inputbar/index.test.tsx" "src/components/skills/WorkflowProgress.test.tsx"
- 当前补充说明：
  - npm run verify:local 是在“服务技能入口清空旧 capability”这一记收尾补丁之前启动的，但该补丁只落在输入栏前端 current 主链；补丁本身已经额外通过定向 typecheck / vitest / eslint，因此本轮交付按“统一入口通过 + 收尾补丁定向门槛通过”共同记录
把 Ribbi 命令研究正式收口成统一事实源，并同步回挂到 LimeNext V2 路线图，避免研究层与规划层再次分叉：
- 已更新：
  - docs/research/ribbi/command-inventory.md
  - docs/research/ribbi/README.md
  - docs/research/ribbi/agent-tool-orchestration.md
  - docs/roadmap/limenextv2/README.md
  - docs/roadmap/limenextv2/product-principles.md
  - docs/roadmap/limenextv2/information-architecture.md
  - docs/roadmap/limenextv2/runtime-architecture.md
  - docs/roadmap/limenextv2/skill-first-system.md
  - docs/roadmap/limenextv2/lime-vs-ribbi.md
  - docs/roadmap/limenextv2/implementation-roadmap.md
  - docs/exec-plans/limenext-progress.md
- 当前统一结论：
  - Ribbi 的命令、agent、tool、sandbox、preview、publish 当前统一以 docs/research/ribbi/command-inventory.md 为唯一研究事实源，不再允许在其他文档里散写另一套命令口径
  - LimeNext V2 当前已明确：生成 不只是主执行面，还是统一调用面；@ / / 只是 生成 内的 typed capability registry 交互壳，不再被写成第二套执行系统
  - 技能 与 命令层 当前已被明确拆分：技能 负责发现与启动，命令层 负责在线程内调用 skill、model agent、sandbox、search/read、media transform、preview/publish 等具体能力
  - 这一步把 V2 从“像 Ribbi 一样做闭环”的抽象描述，推进到了“Ribbi 的命令层如何影响 Lime 前台、IA 和运行时骨架”的可执行规划阶段
把 新建任务 首页里落后的硬编码精选 skill 逻辑收口成共享的 current curated helper，不再单独维护一套首页 skill 事实源：
- 已更新：
  - src/components/agent/chat/service-skills/homeEntrySkills.ts
  - src/components/agent/chat/service-skills/useServiceSkills.ts
  - src/components/agent/chat/components/EmptyState.tsx
  - docs/exec-plans/limenext-progress.md
- 当前统一结论：
  - 首页精选 service skill 当前不再依赖硬编码 skill ID，而是复用同一份 service skill 目录、surface scope 与推荐分桶规则
  - 首页若当前运行时目录里没有可展示的 home 精选 skill，会用同一条 seeded service skill 事实源补齐精选位，而不是在 EmptyState 里手写一套单独对象
  - useServiceSkills 与 新建任务 首页当前共享同一条“首页可展示 skill”过滤规则；旧的首页精选硬编码实现已移除
  - 这一步把 技能页 / 新建任务 的 skill-first 收口往前推进了一刀：至少首页精选 skill 不再是独立维护的旧链
- 当前已确认通过：
  - npm exec vitest run "src/components/agent/chat/components/EmptyState.test.tsx" "src/components/agent/chat/service-skills/useServiceSkills.test.tsx"
  - npx eslint "src/components/agent/chat/service-skills/homeEntrySkills.ts" "src/components/agent/chat/service-skills/useServiceSkills.ts" "src/components/agent/chat/components/EmptyState.tsx"
- 当前补充说明：
  - npm run typecheck 这轮未通过，但阻塞点在既有 src/components/skills/WorkflowProgress.test.tsx 类型不匹配：WorkflowStepInfo.dependencies 与 StepResult.step_name 缺失，当前判断不是这次首页 skill 收口改动引入的新问题
把“上一版无人使用时不背历史包袱”的原则正式写回仓库级约束，避免后续继续给旧实现续命：
- 已更新：
  - AGENTS.md
  - docs/aiprompts/governance.md
  - .codex/skills/lime-governance/SKILL.md
  - .codex/skills/lime-command-boundary/SKILL.md
  - .codex/skills/lime-quality-workflow/SKILL.md
  - docs/exec-plans/limenext-progress.md
- 当前统一结论：
  - 当用户已明确“上一版无人使用 / 不用兼容 / 旧实现阻碍主线”时，旧实现默认不再继续修补，而是按 dead 或带退出条件的 deprecated 收口
  - legacy current reference 统一只表示历史实现锚点，不再被解释成可以继续往旧页面、旧命令、旧协议上加功能
  - 后续若命中旧实现与 current 规划冲突，默认动作应先删旧实现和封旧路，再继续补主链
把 生成主执行面 的 最近发布产物 从“只列出文件”继续补成“带轻量发布态判断”的 current 结果区：
- 已更新：
  - src/components/agent/chat/workspace/sceneAppExecutionContentPosts.ts
  - src/components/agent/chat/workspace/sceneAppExecutionContentPosts.test.ts
  - src/components/agent/chat/workspace/SceneAppExecutionSummaryCard.tsx
  - src/components/agent/chat/workspace/SceneAppExecutionSummaryCard.test.tsx
  - docs/exec-plans/limenext-plan.md
  - docs/exec-plans/limenext-progress.md
  - docs/roadmap/limenext/README.md
- 当前统一结论：
  - sceneAppExecutionContentPosts 当前不再只聚合 发布稿 / 渠道预览稿 / 上传稿 三张文稿，还会顺手检查同名 *.cover.json / *.publish-pack.json 伴随文件
  - 生成 页执行摘要卡里的 最近发布产物 现在会直接显示 可继续发布 / 优先渠道预览 / 优先上传整理 / 待补封面信息、发布包 等轻量就绪态，并把 封面信息 / 发布包 作为 companion 芯片带出来
  - 这一步仍只消费现有 content-posts 文件命名约定与 metadata，不新增新的发布状态协议；旧日志里若继续写“最近发布产物当前只是三个文件入口”，都按已过时理解
- 当前已确认通过：
  - npm exec vitest run "src/components/agent/chat/workspace/sceneAppExecutionContentPosts.test.ts" "src/components/agent/chat/workspace/SceneAppExecutionSummaryCard.test.tsx"
  - npx eslint "src/components/agent/chat/workspace/sceneAppExecutionContentPosts.ts" "src/components/agent/chat/workspace/sceneAppExecutionContentPosts.test.ts" "src/components/agent/chat/workspace/SceneAppExecutionSummaryCard.tsx" "src/components/agent/chat/workspace/SceneAppExecutionSummaryCard.test.tsx"
  - npm run typecheck
把 生成主执行面 从“能发起发布后动作”继续补成“也能直接消费这些动作产物”：
- 已更新：
  - src/components/agent/chat/workspace/sceneAppExecutionContentPosts.ts
  - src/components/agent/chat/workspace/sceneAppExecutionContentPosts.test.ts
  - src/components/agent/chat/workspace/SceneAppExecutionSummaryCard.tsx
  - src/components/agent/chat/workspace/SceneAppExecutionSummaryCard.test.tsx
  - src/components/agent/chat/AgentChatWorkspace.tsx
  - docs/exec-plans/limenext-plan.md
  - docs/exec-plans/limenext-progress.md
  - docs/roadmap/limenext/README.md
- 当前统一结论：
  - 生成 页执行摘要卡当前已新增 最近发布产物 区块，会直接聚合当前会话里的 发布稿 / 渠道预览稿 / 上传稿
  - 聚合逻辑当前只消费带 contentPostIntent / contentPostLabel metadata 的 current 发布产物，不会把普通 content-posts/*.md 误判成投放结果
  - 打开链继续复用现有工作区预览主链：优先打开当前内存里的 task file / artifact，没有时再回落到 session file 读取；因此这一步没有新增新的 viewer 或发布协议
  - 旧日志里若继续写“生成页当前只能触发发布动作、不能直接消费发布稿结果”，当前都按已被本条替代的过时阶段理解
- 当前已确认通过：
  - npm exec vitest run "src/components/agent/chat/workspace/sceneAppExecutionContentPosts.test.ts" "src/components/agent/chat/workspace/SceneAppExecutionSummaryCard.test.tsx"
  - npx eslint "src/components/agent/chat/workspace/sceneAppExecutionContentPosts.ts" "src/components/agent/chat/workspace/sceneAppExecutionContentPosts.test.ts" "src/components/agent/chat/workspace/SceneAppExecutionSummaryCard.tsx" "src/components/agent/chat/workspace/SceneAppExecutionSummaryCard.test.tsx" "src/components/agent/chat/AgentChatWorkspace.tsx"
  - npm run typecheck
- GUI 校验补充说明：
  - npm run verify:gui-smoke 这轮未通过，阻塞在启动期环境探测：脚本先误判 http://127.0.0.1:1420/ 存在可复用前端壳，但 180 秒内实际无法连通该地址，随后 headless Tauri 在 DevBridge 就绪前提前退出（exitCode=1）
  - 同轮补查 1420 / 3030 端口时都无法直接连接，说明这次失败属于本地 GUI smoke 环境启动问题，而不是“最近发布产物”这一条业务链本身在断
把 创作场景 -> 持续流程 -> 创作场景 的快速切换从局部 pending 修补收口成全局导航事务：
- 已更新：
  - src/hooks/useAppNavigation.ts
  - src/hooks/useAppNavigation.test.tsx
  - src/App.tsx
  - src/components/AppSidebar.tsx
  - src/components/AppPageContent.tsx
  - src/components/AppPageContent.test.tsx
  - src/components/sceneapps/SceneAppsPage.tsx
  - src/components/sceneapps/useSceneAppsPageRuntime.ts
  - src/components/sceneapps/SceneAppsPage.test.tsx
  - docs/exec-plans/limenext-plan.md
  - docs/exec-plans/limenext-progress.md
- 当前统一结论：
  - 全局导航当前固定为 requestedPage / requestedPageParams 与 currentPage / pageParams 双态；侧栏高亮与主内容区优先按最新请求态渲染，快速连点时以最后一次点击为准
  - SceneAppsPage 保留 keep-alive，但旧页失去导航所有权后不再回写 sceneapps 参数、也不再写 recent visit，因此不会再把页面抢回 创作场景
  - 创作场景 -> 持续流程 -> 创作场景 的快切链路当前已从“局部 pending 态互相覆盖”收口到“单一全局导航事实源”，不再出现闪动、空白或左侧导航短暂消失
- 当前已确认通过：
  - npm exec vitest run "src/hooks/useAppNavigation.test.tsx" "src/components/AppSidebar.test.tsx" "src/components/AppPageContent.test.tsx" "src/components/sceneapps/SceneAppsPage.test.tsx"
  - npm run verify:local
  - npm run verify:gui-smoke
- 当前补充说明：
  - 额外盘点了仓库里其余 onNavigate(...) 调用点；当前未发现第二条与 SceneApps keep-alive + 非激活态异步回写 同型的导航抢写链路
  - 2026-04-18 追加复跑最新工作树的 npm run verify:gui-smoke 时，headless Tauri 启动阶段一直未等到 DevBridge 健康检查就绪，最终按 bridge:health 超时退出；当前判断这次阻塞发生在环境 / 启动期，不是导航链路的定向回归，因为同轮导航 Vitest 仍是 58/58 通过
  - 如果后续再出现同类闪回，下一步应优先继续排查是否还有页面在非激活态 effect 中自动回写全局导航
把 生成主执行面 的 同聊推进 从“发布前整理”继续扩到现有 渠道预览 / 上传稿 主链：
- 已更新：
  - src/lib/sceneapp/executionPromptActions.ts
  - src/lib/sceneapp/executionPromptActions.test.ts
  - src/components/agent/chat/workspace/SceneAppExecutionSummaryCard.test.tsx
  - docs/exec-plans/limenext-plan.md
  - docs/exec-plans/limenext-progress.md
  - docs/roadmap/limenext/README.md
- 当前统一结论：
  - 生成 页执行摘要卡当前不再只停在 补齐缺失部件 / 发布前检查 / 进入发布整理，而是继续补到了 生成渠道预览稿 / 整理上传稿
  - 这两条动作继续复用仓库里已经存在的 @渠道预览 / @上传 命令面与 content_post_with_cover 主链，不新增新的投放协议或平行发布系统
  - 生成渠道预览稿 / 整理上传稿 与 进入发布整理 一样，当前都会按缺件和失败信号自动禁用并显式提示阻塞原因
- 当前已确认通过：
  - npm exec vitest run "src/lib/sceneapp/executionPromptActions.test.ts" "src/components/agent/chat/workspace/SceneAppExecutionSummaryCard.test.tsx"
  - npx eslint "src/lib/sceneapp/executionPromptActions.ts" "src/lib/sceneapp/executionPromptActions.test.ts" "src/components/agent/chat/workspace/SceneAppExecutionSummaryCard.tsx" "src/components/agent/chat/workspace/SceneAppExecutionSummaryCard.test.tsx" "src/components/agent/chat/AgentChatWorkspace.tsx"
  - npm run typecheck
  - npm run verify:gui-smoke
- 当前补充说明：
  - 本轮第一次 verify:gui-smoke 在 smoke:agent-runtime-tool-surface-page 遇到一次 bridge cooldown active 环境抖动；未改代码重跑后完整 GUI smoke 已通过
  - 因此这次结论按“重跑后的完整 smoke 通过”记录，不把第一次环境性抖动误记成主线回归
把 生成主执行面 的 生成后动作编排 继续补到“同聊推进”层，而不再停在治理材料和页面跳转：
- 已更新：
  - src/lib/sceneapp/executionPromptActions.ts
  - src/lib/sceneapp/executionPromptActions.test.ts
  - src/lib/sceneapp/index.ts
  - src/components/agent/chat/workspace/SceneAppExecutionSummaryCard.tsx
  - src/components/agent/chat/workspace/SceneAppExecutionSummaryCard.test.tsx
  - src/components/agent/chat/AgentChatWorkspace.tsx
  - docs/exec-plans/limenext-plan.md
  - docs/exec-plans/limenext-progress.md
  - docs/roadmap/limenext/README.md
- 当前统一结论：
  - 生成 页执行摘要卡当前已新增 同聊推进 分组，可直接触发 补齐缺失部件 / 发布前检查 / 进入发布整理 / 生成渠道预览稿 / 整理上传稿
  - 发布前检查 / 进入发布整理 / 生成渠道预览稿 / 整理上传稿 继续复用现有 @发布合规 / @发布 / @渠道预览 / @上传 主链，AgentChatWorkspace 直接把动作 prompt 发送到当前会话，不新增新的 viewer 或发布协议
  - 进入发布整理 / 生成渠道预览稿 / 整理上传稿 当前都会按缺件和失败信号自动禁用，并显式提示阻塞原因；因此“先治理、先预览还是先整理上传稿”不再只靠用户自己判断
  - 旧结论里若继续写“生成后动作编排还停在准备治理材料 + 恢复底层入口”，当前都按已过时理解
- 当前已确认通过：
  - npm exec vitest run "src/lib/sceneapp/executionPromptActions.test.ts" "src/components/agent/chat/workspace/SceneAppExecutionSummaryCard.test.tsx"
  - npx eslint "src/lib/sceneapp/executionPromptActions.ts" "src/lib/sceneapp/executionPromptActions.test.ts" "src/lib/sceneapp/index.ts" "src/components/agent/chat/workspace/SceneAppExecutionSummaryCard.tsx" "src/components/agent/chat/workspace/SceneAppExecutionSummaryCard.test.tsx" "src/components/agent/chat/AgentChatWorkspace.tsx"
  - npm run typecheck
  - npm run verify:gui-smoke
- 当前补充说明：
  - 本轮第一次 verify:gui-smoke 曾被旧的本地 lime 调试进程占住 3030/8999 端口，导致新的 headless Tauri 半启动、workspace smoke 长时间挂起；清掉残留验证进程并重跑后，完整 GUI smoke 已通过
  - 因此这次交付结论以“重跑后的完整 GUI smoke 通过”为准，而不是以第一次被本地残留进程污染的结果为准
把 生成主执行面 继续补成第一批 生成后动作编排，不再只是“打开结果文件 + 跳回创作场景”：
- 已更新：
  - src/lib/sceneapp/runEntryNavigation.ts
  - src/lib/sceneapp/runEntryNavigation.test.ts
  - src/lib/sceneapp/index.ts
  - src/lib/sceneapp/product.ts
  - src/components/sceneapps/useSceneAppsPageRuntime.ts
  - src/components/agent/chat/AgentChatWorkspace.tsx
  - src/components/agent/chat/workspace/SceneAppExecutionSummaryCard.tsx
  - src/components/agent/chat/workspace/SceneAppExecutionSummaryCard.test.tsx
  - docs/exec-plans/limenext-plan.md
  - docs/exec-plans/limenext-progress.md
  - docs/roadmap/limenext/README.md
- 当前统一结论：
  - 生成 页执行摘要卡当前会直接展示第一批推荐去向：周会复盘 / 生成 / 看板 / 持续流程 / 自动化 / 结果编辑 / 发布
  - 生成页当前可直接执行 准备周会复盘包 / 准备结构化治理包 / 打开基础治理材料 / 恢复底层运行入口
  - 上面这组动作当前已不再是终点；同一张摘要卡里已经继续补上 补齐缺失部件 / 发布前检查 / 进入发布整理
  - AgentChatWorkspace 与 SceneAppsPage 当前共享 resolveSceneAppRunEntryNavigationTarget + prepareSceneAppRunGovernanceArtifact(s) current 主链，不再各自维护一套 run entry 恢复逻辑
  - 这一步把 生成 从“摘要页 + 导航中转站”推进为第一批真正的统一编排面，也把之前“只支持页面跳转”的旧判断标记为已过时
- 当前已确认通过：
  - npm exec vitest run "src/lib/sceneapp/runEntryNavigation.test.ts" "src/components/agent/chat/workspace/SceneAppExecutionSummaryCard.test.tsx" "src/components/agent/chat/workspace/useSceneAppExecutionSummaryRuntime.test.tsx"
  - npm exec vitest run "src/components/sceneapps/SceneAppsPage.test.tsx"
  - npx eslint "src/lib/sceneapp/runEntryNavigation.ts" "src/lib/sceneapp/runEntryNavigation.test.ts" "src/components/sceneapps/useSceneAppsPageRuntime.ts" "src/components/agent/chat/workspace/SceneAppExecutionSummaryCard.tsx" "src/components/agent/chat/workspace/SceneAppExecutionSummaryCard.test.tsx" "src/components/agent/chat/AgentChatWorkspace.tsx" "src/lib/sceneapp/product.ts"
  - npm run typecheck
  - npm run verify:gui-smoke
- 当前补充说明：
  - 本轮 verify:gui-smoke 已完整通过，说明这次 生成后动作编排 与共享 run entry 导航 helper 没有把 GUI 主路径打断
  - 旧日志里若继续出现“生成页当前还只支持页面跳转”之类说法，当前都按已被本条替代的过时阶段理解
把 生成主执行面 正式接到 current Project Pack 最近结果入口，而不再只停留在顶部摘要文案：
- 已更新：
  - src/lib/sceneapp/runtimeResults.ts
  - src/lib/sceneapp/index.ts
  - src/lib/sceneapp/product.ts
  - src/components/agent/chat/workspace/useSceneAppExecutionSummaryRuntime.ts
  - src/components/agent/chat/workspace/useSceneAppExecutionSummaryRuntime.test.tsx
  - src/components/agent/chat/workspace/SceneAppExecutionSummaryCard.tsx
  - src/components/agent/chat/workspace/SceneAppExecutionSummaryCard.test.tsx
  - src/components/agent/chat/AgentChatWorkspace.tsx
  - src/components/sceneapps/SceneAppProjectPackRuntimePanel.tsx
  - src/components/sceneapps/useSceneAppsPageRuntime.ts
  - docs/exec-plans/limenext-plan.md
  - docs/roadmap/limenext/README.md
- 当前统一结论：
  - useSceneAppExecutionSummaryRuntime 当前不再只回流 runtimeBackflow，还会同步回流最近可消费的 Project Pack 结果样本，以及“当前 run 无文件时回退到最近已交付样本”的状态
  - SceneAppExecutionSummaryCard 已新增 最近可消费结果 区块，生成 页可以直接打开结果文件，不再逼用户先跳回 创作场景 子页
  - SceneAppsPage 与 生成主执行面 当前共享同一套 findLatestSceneAppPackResultRun + resolveSceneAppRuntimeArtifactOpenTarget + deliveryArtifactEntries current 打开链，不再各自维护一份结果入口协议
  - 这一步已经把 创作场景 -> 生成 -> Project Pack -> 复盘 里的“结果消费”真正补到 生成 主舞台，而不是继续停在准备页、评分页和治理页的旁路消费
- 当前已确认通过：
  - npm exec vitest run "src/components/agent/chat/workspace/useSceneAppExecutionSummaryRuntime.test.tsx"
  - npm exec vitest run "src/components/agent/chat/workspace/SceneAppExecutionSummaryCard.test.tsx"
  - npm exec vitest run "src/components/sceneapps/SceneAppsPage.test.tsx"
  - npx eslint "src/components/agent/chat/AgentChatWorkspace.tsx" "src/components/agent/chat/workspace/SceneAppExecutionSummaryCard.tsx" "src/components/agent/chat/workspace/useSceneAppExecutionSummaryRuntime.ts" "src/components/agent/chat/workspace/SceneAppExecutionSummaryCard.test.tsx" "src/components/agent/chat/workspace/useSceneAppExecutionSummaryRuntime.test.tsx" "src/components/sceneapps/useSceneAppsPageRuntime.ts" "src/components/sceneapps/SceneAppProjectPackRuntimePanel.tsx" "src/lib/sceneapp/product.ts" "src/lib/sceneapp/runtimeResults.ts"
  - npm run typecheck
  - npm run verify:gui-smoke
- 当前补充说明：
  - npm run verify:gui-smoke 这轮已实际通过，说明 生成主执行面 与 SceneApps 共用的 current 结果入口链没有把 GUI 主路径打断
  - npm run verify:local 这轮未能整体通过，但失败点来自仓库里与本轮无关的既有 lint 问题：
    - src/components/agent/chat/workspace/useWorkspaceSendActions.ts
    - src/components/agent/chat/workspace/workspaceSendHelpers.ts
  - 当前没有证据表明这些失败与本轮 Project Pack 结果入口改动相关，因此主线交付结论以 定向回归 + typecheck + GUI smoke 为准
把 生成主执行面 继续补成“结果消费 + 回闭环动作”入口，而不再让用户自己找回 创作场景 页：
- 已更新：
  - src/components/agent/chat/AgentChatWorkspace.tsx
  - src/components/agent/chat/workspace/SceneAppExecutionSummaryCard.tsx
  - src/components/agent/chat/workspace/SceneAppExecutionSummaryCard.test.tsx
  - docs/exec-plans/limenext-plan.md
  - docs/exec-plans/limenext-progress.md
  - docs/roadmap/limenext/README.md
- 当前统一结论：
  - 生成页执行摘要卡当前已新增 回生成准备 / 去治理复盘 两个继续动作
  - 去治理复盘 当前会优先带到最近可消费样本对应的 run，而不是只盯着当前可能仍在执行的 run；因此结果消费与人工复核、轻量判断、治理动作已经开始接上同一条闭环
  - 生成页当前还能直接触发 填写人工复核 / 可继续复用 / 继续观察 / 补证据 / 先别继续，继续复用现有 review decision 主链与 RuntimeReviewDecisionDialog
  - 这一步继续复用 SceneAppsPage 既有准备页与治理页，以及已有 review decision 协议，不在 claw 内再复制一套平行治理 UI，保持 current 事实源单一
- 当前已确认通过：
  - npm exec vitest run "src/components/agent/chat/workspace/SceneAppExecutionSummaryCard.test.tsx"
  - npm exec vitest run "src/components/agent/chat/workspace/useSceneAppExecutionSummaryRuntime.test.tsx" "src/components/agent/chat/workspace/SceneAppExecutionSummaryCard.test.tsx"
  - 定向 eslint
- 当前补充说明：
  - 这一步主要补的是 生成 -> 创作场景 的回流动作层与直接复盘动作，没有新增新的运行态协议或页面对象
  - npm run typecheck 这轮未能整体通过，但失败点来自仓库里与本轮无关的既有问题：
    - src/components/onboarding/steps/VoiceShortcutTestStep.test.tsx
  - npm run verify:gui-smoke 这轮也未能完成，阻塞点仍是已有 headless 构建环境里的 libsqlite3-sys 临时 target bindgen.rs 缺失，不是这轮 生成 -> 创作场景 深链动作回归

2026-04-17

已完成

把 Project Pack 的结果消费入口从 治理复盘 / 运行详情 继续扩到 生成准备 / 经营评分：
- 已更新：
  - src/components/sceneapps/SceneAppProjectPackRuntimePanel.tsx
  - src/components/sceneapps/SceneAppDetailPanel.tsx
  - src/components/sceneapps/SceneAppScorecardPanel.tsx
  - src/components/sceneapps/SceneAppsPage.tsx
  - src/components/sceneapps/useSceneAppsPageRuntime.ts
  - src/components/sceneapps/SceneAppsPage.test.tsx
  - docs/roadmap/limenext/README.md
  - docs/exec-plans/limenext-plan.md
- 当前统一结论：
  - 生成准备 与 经营评分 当前不再只展示 Project Pack 的查看方式文案，而会直接回流最近可消费样本的结果入口
  - 当最新运行仍在执行、或没有带回结果文件路径时，页面会自动回退到最近一轮已交付样本，避免准备页和评分页只剩静态规划信息
  - 结果入口继续复用 SceneAppRunDetailViewModel.deliveryArtifactEntries -> Agent 文件预览打开链，没有新增新的 Project Pack viewer 协议
- 当前已确认通过：
  - npm exec vitest run "src/components/sceneapps/SceneAppsPage.test.tsx"
  - npx eslint "src/components/sceneapps/SceneAppProjectPackRuntimePanel.tsx" "src/components/sceneapps/SceneAppDetailPanel.tsx" "src/components/sceneapps/SceneAppScorecardPanel.tsx" "src/components/sceneapps/SceneAppsPage.tsx" "src/components/sceneapps/useSceneAppsPageRuntime.ts" "src/components/sceneapps/SceneAppsPage.test.tsx"
  - npm run typecheck
- GUI 续测结论：
  - npm run verify:gui-smoke 当前不再卡 libsqlite3-sys；本轮失败点转为复用环境下的 smoke:browser-runtime 清理旧 session_id 时 close_cdp_session 返回“未找到 session”，属于浏览器运行时清理链问题，不是 sceneapps 主路径回归
  - 已改用真实页面续测补一刀：打开 http://127.0.0.1:1420/，进入 创作场景 -> 生成准备 / 治理复盘，确认 最近结果入口 / 最近可消费结果 面板已出现，控制台无新增 error，仅保留既有 i18n warn
  - 当前 seed 运行样本在真实 GUI 环境里还没有带回可打开的结果文件路径，所以真实页面续测主要证明入口渲染与回退语义；“点击主稿文件即可打开”继续由新增的定向 Vitest 回归断言兜底
把 创作场景 目录分页正式接到 current descriptor + latest run + scorecard 同一事实源：
- 已更新：
  - src/lib/sceneapp/product.ts
  - src/components/sceneapps/useSceneAppsPageRuntime.ts
  - src/components/sceneapps/SceneAppsCatalogPanel.tsx
  - src/components/sceneapps/SceneAppsPage.tsx
  - src/components/sceneapps/SceneAppsPage.test.tsx
  - docs/roadmap/limenext/README.md
  - docs/exec-plans/limenext-plan.md
- 当前统一结论：
  - 场景目录卡片当前不再只是静态标题列表，而会同时回流 delivery contract / latest run / scorecard action / top failure signal / operating summary
  - useSceneAppsPageRuntime 当前会在目录层聚合所有 descriptor 对应的 latest run + scorecard，并把这些经营信号压到同一份 SceneAppCatalogCardViewModel
  - 目录卡片、生成页顶部执行摘要与自动化详情当前共享同一组 descriptor + latest run + scorecard 语义，不再各讲各的“当前状态”
  - 这意味着 创作场景 目录已经从“选一个标题进去”推进到“先看哪条场景值得继续推进、该先补什么”这一层产品判断
- 当前已确认通过：
  - npm exec vitest run "src/components/sceneapps/SceneAppsPage.test.tsx" "src/lib/sceneapp/product.test.ts"
  - npx eslint "src/components/sceneapps/SceneAppsCatalogPanel.tsx" "src/components/sceneapps/SceneAppsPage.tsx" "src/components/sceneapps/useSceneAppsPageRuntime.ts" "src/lib/sceneapp/product.ts" "src/components/sceneapps/SceneAppsPage.test.tsx" "src/lib/sceneapp/product.test.ts"
  - npm run typecheck
- 当前仍待继续：
  - 本条能力本身已被后续更完整的 GUI 续测覆盖；当前整套 verify:gui-smoke 的最新阻塞已不再是 libsqlite3-sys，而是复用环境下 smoke:browser-runtime 清理旧会话失败
把 持续流程 / 自动化 详情页正式接到 current 创作场景 -> 生成 -> Project Pack -> 复盘 同一事实源：
- 已更新：
  - src/lib/sceneapp/automation.ts
  - src/lib/sceneapp/automation.test.ts
  - src/components/settings-v2/system/automation/useAutomationSceneAppRuntime.ts
  - src/components/settings-v2/system/automation/index.tsx
  - src/components/settings-v2/system/automation/index.test.tsx
  - src/components/settings-v2/system/automation/AutomationJobDetailsDialog.tsx
  - src/components/automation/AutomationPage.tsx
  - docs/roadmap/limenext/README.md
  - docs/exec-plans/limenext-plan.md
- 当前统一结论：
  - 自动化详情弹窗当前不再只看 调度状态 / payload / run history；如果任务来自创作场景派生，它会按 job metadata 回查同一条 SceneApp descriptor / project pack plan / run summary / scorecard
  - 弹窗里已新增 创作场景闭环 摘要块，能直接回到 创作场景准备 或 治理复盘
  - 结果文件、治理文件与治理动作当前已复用 SceneAppRunDetailViewModel + sceneapp_prepare_run_governance_artifact(s) 主链，不再额外发明 automation 专用 pack / governance 协议
  - SceneApp 在这条链里继续只承担内部画像与运行时合同；自动化前台看到的仍是 创作场景 闭环，而不是新的对外主词
- 当前已确认通过：
  - npm exec vitest run "src/lib/sceneapp/automation.test.ts" "src/components/settings-v2/system/automation/index.test.tsx"
  - npm exec vitest run "src/components/settings-v2/system/automation/AutomationJobDetailsDialog.test.tsx"
  - npx eslint "src/lib/sceneapp/automation.ts" "src/lib/sceneapp/automation.test.ts" "src/components/settings-v2/system/automation/useAutomationSceneAppRuntime.ts" "src/components/settings-v2/system/automation/index.tsx" "src/components/settings-v2/system/automation/index.test.tsx" "src/components/settings-v2/system/automation/AutomationJobDetailsDialog.tsx" "src/components/automation/AutomationPage.tsx"
  - npm run typecheck
- 当前仍待继续：
  - npm run verify:gui-smoke 本轮连续两次都卡在本地 headless Tauri Rust 构建环境，libsqlite3-sys 在临时 target 目录缺失 bindgen.rs，导致 DevBridge 未就绪；这次阻塞发生在 GUI smoke 启动期，而不是自动化 / 创作场景业务断链
  - npm run verify:local 本轮未继续执行，因为当前会被同一条 GUI smoke 环境故障阻塞
把生成页顶部的 创作场景执行摘要 从启动静态卡继续补成“启动基线 + 运行态回流”的 current 主链：
- 已更新：
  - src/lib/sceneapp/product.ts
  - src/lib/sceneapp/product.test.ts
  - src/components/agent/chat/workspace/useSceneAppExecutionSummaryRuntime.ts
  - src/components/agent/chat/workspace/useSceneAppExecutionSummaryRuntime.test.tsx
  - src/components/agent/chat/AgentChatWorkspace.tsx
  - src/components/agent/chat/workspace/SceneAppExecutionSummaryCard.tsx
  - src/components/agent/chat/workspace/SceneAppExecutionSummaryCard.test.tsx
  - src/components/AppPageContent.tsx
  - src/components/AppPageContent.test.tsx
  - docs/roadmap/limenext/README.md
  - docs/exec-plans/limenext-plan.md
- 当前统一结论：
  - 生成 页顶部的执行摘要当前不再只展示 sceneapp_plan_launch 时刻的 planning 快照，还会按当前 sessionId -> sceneapp run 回查最近运行，并把交付完成度、证据链、治理材料与失败信号继续回流到同一张摘要卡
  - Project Pack / scorecard / governance 这条运行态回流当前已开始直接进入 生成主执行面，用户不用再先跳回 创作场景 / 复盘 才能看到最近一次运行的主链状态
  - 为了守住 keep-alive 主路径，AppPageContent.tsx 当前已把 sceneapps 常驻节点固定在稳定树位，创作场景 -> 持续流程 -> 创作场景 往返时不会再重挂载目录页
- 当前已确认通过：
  - npm exec vitest run "src/lib/sceneapp/product.test.ts" "src/components/agent/chat/workspace/SceneAppExecutionSummaryCard.test.tsx" "src/components/agent/chat/workspace/useSceneAppExecutionSummaryRuntime.test.tsx" "src/components/AppPageContent.test.tsx"
  - npx eslint "src/components/agent/chat/AgentChatWorkspace.tsx" "src/components/agent/chat/workspace/SceneAppExecutionSummaryCard.tsx" "src/components/agent/chat/workspace/useSceneAppExecutionSummaryRuntime.ts" "src/components/agent/chat/workspace/useSceneAppExecutionSummaryRuntime.test.tsx" "src/lib/sceneapp/product.ts" "src/lib/sceneapp/product.test.ts" "src/components/AppPageContent.tsx" "src/components/AppPageContent.test.tsx"
  - npm run typecheck
  - npm run verify:gui-smoke
把 创作场景 -> 生成 的执行摘要真正接进 current 生成主执行面，不再只把一段 prompt 丢给 claw：
- 已更新：
  - src/lib/sceneapp/product.ts
  - src/lib/sceneapp/launch.ts
  - src/types/page.ts
  - src/components/AppPageContent.tsx
  - src/components/agent/chat/AgentChatWorkspace.tsx
  - src/components/agent/chat/workspace/useWorkspaceConversationSceneRuntime.tsx
  - src/components/agent/chat/workspace/WorkspaceConversationScene.tsx
  - src/components/agent/chat/workspace/SceneAppExecutionSummaryCard.tsx
  - src/lib/sceneapp/launch.test.ts
  - src/components/agent/chat/workspaceEntry.test.ts
  - src/components/AppPageContent.test.tsx
  - src/components/agent/chat/workspace/useWorkspaceConversationSceneRuntime.test.ts
  - src/components/agent/chat/workspace/SceneAppExecutionSummaryCard.test.tsx
  - docs/roadmap/limenext/README.md
  - docs/exec-plans/limenext-plan.md
- 当前统一结论：
  - 创作场景 进入 生成 时，Project Pack / scorecard / context baseline 已通过 initialSceneAppExecutionSummary 进入生成页顶部，而不是再混进 runtime request metadata
  - initialAutoSendRequestMetadata 当前也已显式透传到 AgentChatPage，cloud_scene / browser_assist 这类自动发送首刀不再丢失 metadata 主链
  - 生成 页顶部现在会先展示“创作场景执行摘要”，再进入 step progress、timeline 与继续执行，用户可以直接看见当前场景的执行主链、上下文分层、Project Pack 合同与 scorecard 口径
- 当前已确认通过：
  - npm exec vitest run "src/lib/sceneapp/launch.test.ts" "src/components/agent/chat/workspaceEntry.test.ts" "src/components/AppPageContent.test.tsx" "src/components/agent/chat/workspace/useWorkspaceConversationSceneRuntime.test.ts" "src/components/agent/chat/workspace/SceneAppExecutionSummaryCard.test.tsx"
修掉 治理复盘 带 runId 重新进入时会在 runs 列表加载阶段回退到首条运行的状态抖动：
- 已更新：
  - src/components/sceneapps/useSceneAppsPageRuntime.ts
  - src/components/sceneapps/SceneAppsPage.test.tsx
  - src/components/AppPageContent.test.tsx
- 当前统一结论：
  - 目录刚加载完、场景选择还未落稳的过渡帧，runtime 不会再提前清空已有 selectedRunId
  - 带 runId 重进 治理复盘 时，右侧运行详情会继续稳定指向该 run，而不是被 runs 列表里的首条记录覆盖
  - AppPageContent 的页面挂载回归也已同步修正，verify:gui-smoke 不会再在 agent-service-skill-entry 阶段被旧测试写法误伤
- 当前已确认通过：
  - npm exec vitest run "src/components/sceneapps/SceneAppsPage.test.tsx" -t "带 runId 重新进入治理页时不应在运行列表加载阶段回退到首条运行"
  - npm exec vitest run "src/components/AppPageContent.test.tsx"
  - npm run verify:gui-smoke
把 agentEntry=claw 的 current 前台产品定义收口为 生成主执行面，不再继续用 任务中心 作为主叙事：
- 已更新：
  - src/lib/navigation/sidebarNav.ts
  - src/types/page.ts
  - src/components/agent/chat/workspace/chatSurfaceProps.ts
  - src/components/agent/chat/components/MessageList.tsx
  - src/components/agent/chat/components/ChatSidebar.tsx
  - src/components/agent/chat/components/Inputbar/components/InputbarComposerSection.tsx
  - src/components/agent/chat/service-skills/skillPresentation.ts
  - src/components/sceneapps/SceneAppsPage.tsx
  - src/components/sceneapps/SceneAppDetailPanel.tsx
  - src/lib/sceneapp/presentation.ts
  - docs/roadmap/limenext/README.md
  - docs/roadmap/limenext/prd.md
  - docs/roadmap/limenext/architecture.md
  - docs/roadmap/limenext/context-layer.md
  - docs/roadmap/limenext/sceneapp-business-flows.md
  - docs/roadmap/limenext/sceneapp-fullstack-implementation-plan.md
  - 旧 Ribbi 对位文档已清理；相关判断现统一收口到 docs/research/ribbi/* 与 docs/roadmap/limenextv2/*
- 当前统一结论：
  - 侧边栏与前台 current 主词现在固定为 新建任务 / 生成 / 我的方法 / 创作场景 / 消息渠道 / 资料库 / 灵感库
  - agentEntry=claw 继续保留为内部实现 route，但前台已统一按 生成 理解
  - 创作场景 页当前明确退回执行前选路、planning 和上下文基线装配页，不再承担长期主执行面职责
  - 生成 当前是 Lime 创作闭环唯一主执行面，继续承接执行过程、继续旧历史、最近结果与后续结果回流
把 sceneapp_plan_launch 与 sceneapp_save_context_baseline 的语义彻底拆开，收口成 latest-only 的显式场景基线主链：
- 已更新：
  - src-tauri/src/sceneapp/application.rs
  - src-tauri/src/commands/sceneapp_cmd.rs
  - src-tauri/src/app/runner.rs
  - src-tauri/src/dev_bridge/dispatcher/sceneapp.rs
  - src-tauri/src/dev_bridge/dispatcher.rs
  - src/lib/api/sceneapp.ts
  - src/lib/governance/agentCommandCatalog.json
  - src/lib/dev-bridge/mockPriorityCommands.ts
  - src/lib/tauri-mock/core.ts
  - src/lib/tauri-mock/core.test.ts
  - src/lib/api/sceneapp.test.ts
  - src/components/sceneapps/useSceneAppsPageRuntime.ts
  - src/components/sceneapps/SceneAppDetailPanel.tsx
  - src/components/sceneapps/SceneAppsPage.tsx
  - src/components/sceneapps/SceneAppsPage.test.tsx
  - docs/aiprompts/commands.md
  - docs/roadmap/limenext/README.md
  - docs/roadmap/limenext/context-layer.md
  - docs/roadmap/limenext/inspiration-library-and-taste-profile.md
  - docs/roadmap/limenext/sceneapp-fullstack-implementation-plan.md
  - docs/roadmap/limenext/sceneapp-runtime-contract.md
- 当前统一结论：
  - sceneapp_plan_launch 现在只负责 preview 当前 planning，并读取已有项目级 Context Snapshot
  - sceneapp_save_context_baseline 才代表把当前灵感对象、输入摘要与风格偏好显式写回 .lime/sceneapp/context/<sceneapp-id>.json
  - 创作场景 详情页已新增“写入当前场景基线”按钮，不再把 preview planning 伪装成自动资产沉淀
  - 浏览器 mock、DevBridge、Tauri 注册、治理目录册与前端 API 网关都已同步到同一条 current 命令链
- 当前已确认通过：
  - cargo test --manifest-path "src-tauri/Cargo.toml" sceneapp::
  - npm exec vitest run "src/lib/api/sceneapp.test.ts" "src/lib/tauri-mock/core.test.ts" "src/components/sceneapps/SceneAppsPage.test.tsx"
把 创作场景治理页 / 运行详情 -> 轻量反馈按钮 接回 current review decision 主链：
- 已更新：
  - src/components/sceneapps/useSceneAppsPageRuntime.ts
  - src/components/sceneapps/SceneAppsPage.tsx
  - src/components/sceneapps/SceneAppGovernancePanel.tsx
  - src/components/sceneapps/SceneAppRunDetailPanel.tsx
  - src/components/sceneapps/SceneAppsPage.test.tsx
  - docs/roadmap/limenext/README.md
  - docs/roadmap/limenext/inspiration-library-and-taste-profile.md
  - docs/roadmap/limenext/metrics-and-selection.md
  - docs/roadmap/limenext/sceneapp-fullstack-implementation-plan.md
  - docs/roadmap/limenext/sceneapp-runtime-contract.md
- 当前统一结论：
  - 可继续复用 / 继续观察 / 补证据 / 先别继续 四个轻量判断按钮，当前已经落到治理看板与运行详情
  - 这些按钮不会新造 sceneapp_feedback_* 协议，而是先复用 agent_runtime_export_review_decision_template / agent_runtime_save_review_decision
  - 保存后仍会沿用同一条 review decision -> Context Snapshot -> planning 刷新 主链
  - 完整人工复核入口继续保留；轻量判断只负责把高频结论更快写回 current 资产链
- 当前已确认通过：
  - npm exec vitest run "src/components/sceneapps/SceneAppsPage.test.tsx"
  - npm run typecheck
补齐 SceneApp current 命令 -> DevBridge browser 开发模式 的最后一段桥接，修掉创作场景页在浏览器模式下的 unknown command 断链：
- 已更新：
  - src-tauri/src/dev_bridge/dispatcher/sceneapp.rs
  - src-tauri/src/dev_bridge/dispatcher.rs
- 当前统一结论：
  - sceneapp_list_catalog / sceneapp_get_descriptor / sceneapp_plan_launch / sceneapp_save_context_baseline / sceneapp_create_automation_job / sceneapp_list_runs / sceneapp_get_run_summary / sceneapp_prepare_run_governance_artifact / sceneapp_get_scorecard 在 current 不只注册在 Tauri generate_handler!，也已显式接入 DevBridge dispatcher
  - 浏览器开发模式下的 创作场景 页面已不再出现 sceneapp_plan_launch / sceneapp_list_runs / sceneapp_get_scorecard 的 未知命令
  - current sceneapp_* 现在在桌面壳与浏览器开发模式下共享同一条 SceneApp 真相链，不再出现“合同存在但 DevBridge 少桥一半”的断层
- 当前已确认通过：
  - cargo test --manifest-path "src-tauri/Cargo.toml" sceneapp_
  - npm run test:contracts
  - 直接打开 http://127.0.0.1:1420/，进入 创作场景 页面后，控制台只剩 i18n warning，不再出现 sceneapp_* unknown command
  - npm run verify:gui-smoke -- --reuse-running --timeout-ms 600000
- 本轮额外确认：
  - 中途曾出现一次 smoke:agent-service-skill-entry 串联超时，表面报错是 src/components/agent/chat/index.test.tsx 的 beforeAll hook timeout
  - 随后定向复跑 node scripts/agent-service-skill-entry-smoke.mjs 与整套 verify:gui-smoke 已恢复通过，说明这次更像运行时抖动，而不是 SceneApp / DevBridge current 主链回归
把 review decision -> 项目级 Context Snapshot 的显式人工复核入口接回 current 主链：
- 已更新：
  - src-tauri/src/commands/aster_agent_cmd/command_api/runtime_api.rs
  - src-tauri/src/sceneapp/application.rs
  - src/components/sceneapps/useSceneAppsPageRuntime.ts
  - src/components/sceneapps/SceneAppsPage.tsx
  - src/components/sceneapps/SceneAppGovernancePanel.tsx
  - src/components/sceneapps/SceneAppRunDetailPanel.tsx
  - src/lib/sceneapp/product.ts
  - src/lib/sceneapp/product.test.ts
  - src/components/sceneapps/SceneAppsPage.test.tsx
- 当前统一结论：
  - agent_runtime_save_review_decision 保存完成后，会尝试按 session_id -> sceneapp run 反查当前运行，并把人工复核结论同步回 .lime/sceneapp/context/<sceneapp-id>.json
  - ReferenceItem.lastFeedbackLabel 当前可直接承接 人工接受 / 人工延后 / 人工否决 / 人工补证据 等显式人工结论
  - TasteProfile.feedbackSummary / feedbackSignals / lastFeedbackAt 当前会同时承接自动反馈与人工复核，不再额外新增 sceneapp_feedback_* 协议
  - 创作场景治理页已经复用现有 RuntimeReviewDecisionDialog，保存后会刷新当前 planning 基线
- 当前已确认通过：
  - cargo test --manifest-path "src-tauri/Cargo.toml" sceneapp::
  - npm exec vitest run "src/lib/sceneapp/product.test.ts" "src/components/sceneapps/SceneAppsPage.test.tsx"
  - npm run typecheck
  - npm run test:contracts
- 当前仍待继续：
  - GUI smoke 当前被复用中的 DevBridge health 阻塞，尚未完成这轮 GUI 交付验证
把 灵感库 -> 创作场景 的正式引用对象链补齐到 current 主链：
- 已更新：
  - src/components/memory/MemoryPage.tsx
  - src/components/sceneapps/useSceneAppsPageRuntime.ts
  - src/lib/sceneapp/navigation.ts
  - src/lib/sceneapp/launch.ts
  - src/lib/sceneapp/launcher.ts
  - src-tauri/src/sceneapp/application.rs
  - src-tauri/src/sceneapp/context/compiler.rs
  - src-tauri/src/sceneapp/runtime.rs
  - src-tauri/src/sceneapp/adapters.rs
  - src/lib/tauri-mock/core.ts
- 当前统一结论：
  - referenceMemoryIds 已成为 灵感库 -> 创作场景 的 current 正式入口
  - prefillIntent 继续保留，但只做输入补充，不再承担“唯一灵感对象载体”
  - sceneapp_plan_launch 已能按 reference_memory_ids 读取统一记忆条目，并编译成 contextOverlay.snapshot.referenceItems
  - 编译结果会继续进入 TasteProfile、projectPackPlan 与 runtime adapter metadata / launch payload；显式落盘当前改由 sceneapp_save_context_baseline
  - 浏览器 mock 已与 Rust current 合同对齐，不再只在真实后端链路里有 reference_memory_ids
- 当前已确认通过：
  - npm exec vitest run "src/lib/tauri-mock/core.test.ts" "src/lib/api/sceneapp.test.ts" "src/components/memory/MemoryPage.test.tsx" "src/components/sceneapps/SceneAppsPage.test.tsx" "src/lib/sceneapp/storage.test.ts" "src/lib/sceneapp/launch.test.ts"
  - cargo test --manifest-path "src-tauri/Cargo.toml" sceneapp::
- 当前仍待继续：
  - 如何让自动反馈回写与前台显式操作进一步统一成稳定资产链
  - provider 裁剪和更稳定的跨场景 taste 经营链
把 运行 / scorecard / governance -> 项目级 Context Snapshot 的自动反馈回写补齐到 current 主链：
- 已更新：
  - src-tauri/src/sceneapp/application.rs
  - src-tauri/src/sceneapp/context/dto.rs
  - src-tauri/src/sceneapp/context/compiler.rs
  - src-tauri/src/sceneapp/context/store.rs
  - src/lib/context-layer/types.ts
  - src/lib/sceneapp/product.ts
  - src/components/sceneapps/SceneAppDetailPanel.tsx
  - src/components/sceneapps/SceneAppScorecardPanel.tsx
  - src/components/sceneapps/SceneAppGovernancePanel.tsx
  - src/components/sceneapps/SceneAppRunDetailPanel.tsx
- 当前统一结论：
  - ReferenceItem 已直接承接 usageCount / lastUsedAt / lastFeedbackLabel
  - TasteProfile 已直接承接 feedbackSummary / feedbackSignals / lastFeedbackAt
  - sceneapp_get_run_summary / sceneapp_prepare_run_governance_artifact / sceneapp_get_scorecard 会把最近运行的交付缺口、失败信号与治理判断自动回写到 .lime/sceneapp/context/<sceneapp-id>.json
  - 详情、评分、运行复盘、治理面当前都会继续消费同一套 Planning 基线 + 最近反馈 事实源
  - V2 current first cut 已不再依赖“像我 / 不像我”按钮才能形成反馈闭环；当前显式人工复核继续复用 review decision 主链补到同一份 snapshot
- 当前已确认通过：
  - cargo test --manifest-path "src-tauri/Cargo.toml" sceneapp::
  - npm exec vitest run "src/lib/sceneapp/product.test.ts" "src/components/sceneapps/SceneAppsPage.test.tsx"
  - npm run typecheck
  - npm run test:contracts
- 当前仍待继续：
  - provider 裁剪和更稳定的跨场景 taste 经营链
把 LimeNext V2 的 current 文档事实源收口到 创作场景 / 灵感库 主线：
- 已更新：
  - docs/roadmap/limenext/README.md
  - docs/roadmap/limenext/inspiration-library-and-taste-profile.md
  - docs/roadmap/limenext/context-layer.md
  - docs/roadmap/limenext/sceneapp-fullstack-implementation-plan.md
- 当前统一结论：
  - 前台主词固定为 创作场景 / 灵感库 / 生成 / Project Pack / 复盘
  - SceneApp 继续保留为内部场景画像与运行时合同，不再作为前台主叙事
  - 灵感库 当前是 Memory Layer + Taste Layer 的前台投影层，底层事实源仍在 Memory Layer
  - 灵感库 -> 创作场景 已进入 current 前台主链：灵感条目可带着 referenceMemoryIds + prefillIntent 进入场景 planning
  - 当前真正缺口已从“有没有前台入口”收口为“如何把前台操作正式回写到 ReferenceItem / TasteProfile，以及如何补齐 provider 裁剪与反馈编译”
- 本轮额外沉淀：
  - V2 不应再把“灵感库”与“记忆工作台”混成同一层；前台要讲投影层，底层要讲事实源与诊断层
  - SceneApp 这个词保留工程价值，但不应继续主导对外命名
把 compat 旧文档继续标注清理，避免旧图示覆盖 current 口径：
- 已更新：
  - docs/roadmap/limenext/sequences.md
  - docs/roadmap/limenext/flowcharts.md
- 当前固定规则：
  - 这两份文档继续保留为 compat reference
  - 文中若继续出现 场景应用、旧“场景工厂”等词，只按 compat 旧称理解，不能覆盖 current 的 创作场景 / 灵感库 / Project Pack / 复盘
收掉 SceneAppsPage 剩余两条旧文案测试断言，避免 current 命名继续被旧 SceneApp 文案拖回去：
- 已更新：
  - src/components/sceneapps/SceneAppsPage.test.tsx
- 当前已确认通过：
  - npm exec vitest run "src/components/sceneapps/SceneAppsPage.test.tsx"
  - npm run typecheck

2026-04-16

已完成

收口 SceneApp / Context Layer 当前 latest-only 产品面，不再给旧 projectPackPlan 单独消费模型留历史包袱：
- src/lib/sceneapp/product.ts 已把 contextPlan 改成显式复用 contextBaseline 组装，清掉依赖隐式 spread 的旧空值心智
- src/lib/sceneapp/product.test.ts 已统一改到 planResult 主签名，并补齐：
  - detail / scorecard / run detail / governance 四个消费面的 contextBaseline 断言
  - referenceItems / tasteKeywords / avoidKeywords / scopeLabel 断言
- src/components/sceneapps/SceneAppsPage.test.tsx 已补齐当前页面事实源断言：
  - 详情页 reference items / taste / avoid
  - 评分卡 context baseline
  - 治理页 context baseline
  - 运行详情 context baseline
- 顺手清掉一个测试历史噪音：
  - “继续最近”用例已补 act + flushEffects，不再在定向回归里持续刷 React act(...) 警告
- 当前已确认通过：
  - npm exec vitest run "src/lib/sceneapp/product.test.ts"
  - npm exec vitest run "src/components/sceneapps/SceneAppsPage.test.tsx"
  - npm run typecheck
  - cargo test --manifest-path "src-tauri/Cargo.toml" sceneapp::
  - npm run verify:gui-smoke -- --reuse-running --timeout-ms 600000
- 当前额外确认：
  - npm run verify:local 在仓库全量 Rust 阶段失败于未改动模块 services::site_capability_service::tests::should_report_requires_browser_runtime_when_no_attached_session_exists
  - 这轮 SceneApp / Context Layer 主线的前端、GUI 与 sceneapp:: 定向 Rust 校验已通过，当前阻塞不是本轮 latest-only 收口引入
收口 SceneApp / Context Layer 这轮尾部校验，把最终阻塞从“实现错误”纠偏为“测试契约与 smoke 串联稳定性”：
- src/components/agent/chat/utils/clawWorkspaceProviderSelection.test.ts 已补齐 normalizeFetchProviderModelsSource mock，避免 provider API fallback 分支被旧测试契约静默吞掉
- 之前 verify:local 首次失败里的两类红灯现已分别确认：
  - clawWorkspaceProviderSelection 两条失败是测试 mock 落后，不是当前 provider 选择实现回退
  - Rust media_task_cmd 两条 image task 失败是受限环境里的端口绑定权限问题；在当前无沙箱环境下定向 cargo test --manifest-path "src-tauri/Cargo.toml" execute_image_generation_task_should_ 已通过
- GUI smoke 首次卡在 smoke:agent-runtime-tool-surface-page 的 browser_execute_action / close_cdp_session / close_chrome_profile_session -> fetch failed，但单独复跑该 smoke 与随后复跑整套 verify:gui-smoke -- --reuse-running --timeout-ms 600000 已全部通过，说明更像一次串联波动，而不是 SceneApp 主链回归
- 当前已确认通过：
  - npm exec vitest run "src/components/agent/chat/utils/clawWorkspaceProviderSelection.test.ts"
  - cargo test --manifest-path "src-tauri/Cargo.toml" execute_image_generation_task_should_
  - npm run verify:gui-smoke -- --reuse-running --timeout-ms 600000
  - npm run verify:local
- 本轮额外沉淀：
  - SceneApp / Context Layer 主线已经达到 Lime 当前本地可交付门槛，剩余重点不再是补兼容，而是继续把 page smoke 的串联稳定性保持住
  - 遇到 fetch failed 一类 GUI smoke 假红时，先拆成“单条 smoke / DevBridge 健康 / 定向 Rust 用例”三段验证，再决定是不是实现回退
修掉 SceneAppsPage 点击“继续最近”后因同页重复导航导致的持续闪屏：
- 根因不是纯样式问题，而是 useSceneAppsPageRuntime 在显式恢复最近参数后，search / prefillIntent 的 debounced 同步又拿旧值触发了一轮同页 onNavigate("sceneapps", ...)
- 当前已改成：
  - 当本地 searchQuery / launchInput 与外部 pageParams 一致时，优先用当前值参与同步
  - 不再让 debounce 落后的旧值在“继续最近”后触发第二轮同页导航
- 已补稳定回归：
  - src/components/sceneapps/SceneAppsPage.test.tsx
  - 新增“点击继续最近场景后不应因为搜索与输入 debounce 再次重复导航”断言
- 当前已确认通过：
  - npm test -- "src/components/sceneapps/SceneAppsPage.test.tsx"
  - npx eslint --no-warn-ignored "src/components/sceneapps/useSceneAppsPageRuntime.ts" "src/components/sceneapps/SceneAppsPage.test.tsx"
[已被后续经营信号目录卡片方案替代] 把 SceneApps 目录页从“无图场景墙”进一步纠偏到“纯标题目录”：
- 删除目录分页里大外框、大卡片和“场景选品墙”式陈列
- 最近访问入口继续保留，但已压缩成同一块目录里的纯文字标题入口
- 场景目录当前只保留标题点击，不再在目录页展示产出、模式、基础设施与 CTA 块
- 已同步更新：
  - src/components/sceneapps/SceneAppsCatalogPanel.tsx
  - src/components/sceneapps/SceneAppsPage.test.tsx
  - docs/aiprompts/design-language.md
- 本轮额外沉淀：
  - 对“目录页”来说，真正的合并不是把两组卡片放进一个组件，而是把它们收成同一种文字语义
  - 如果页面目标只是快速选场景，宁可退成纯标题目录，也不要继续保留 SceneApp 大框
把首页 SceneApps 入口从“大卡片推荐面板”继续收口成“纯文字标题目录”：
- 命中组件是 src/components/agent/chat/components/EmptyStateSceneAppsPanel.tsx，不是 SceneAppsPage
- 首页入口当前只保留：
  - 标题说明
  - 继续最近场景 / 查看全部场景
  - 一行可直接点击启动的场景标题目录
- 删除首页入口里的：
  - SceneApp 大卡片
  - 产出 / 模式 / 基建 / 来源信息块
  - 深色主 CTA 按钮
- 已同步更新：
  - src/components/agent/chat/components/EmptyStateSceneAppsPanel.tsx
  - src/components/agent/chat/components/EmptyState.test.tsx
  - docs/aiprompts/design-language.md
- 本轮额外沉淀：
  - 首页场景入口和场景目录页都应共享“纯标题目录”语义，不能一个已经去框化，另一个还保留老式卡片
把 SceneAppsPage 首屏壳层从“大框工作台”继续收口成纯文字导航：
- 删除首屏 hero 外框、四张统计卡、当前场景摘要卡和 WORKFLOW PATH 三步卡
- 当前只保留：
  - 页面标题与说明
  - 刷新目录文字入口
  - 目录 / 详情 / 治理的文字型分页切换
  - 当前场景的一行文字状态与最小动作入口
- 已同步更新：
  - src/components/sceneapps/SceneAppsPage.tsx
  - src/components/sceneapps/SceneAppsPage.test.tsx
  - docs/aiprompts/design-language.md
- 本轮额外沉淀：
  - SceneAppsPage 的“分页”与“卡片化壳层”不是一回事；保留分页不等于必须保留大块容器
  - 如果用户目标是快速选场景，顶层工作台也应回到文字导航，而不是继续展示经营看板式首屏
把 browser runtime 会话稳定性从“依赖首个 launcher 子进程存活”收口成“按 profile_key 管理当前活跃 session”：
- src-tauri/src/commands/webview_cmd.rs 已修正：
  - Chrome profile 存活判断不再只依赖最初 launcher 子进程
  - 未受管 / 扩展附着 session 发现不再把 /json/list 瞬时失败直接判死
  - close_browser_runtime_session_for_profile_key(...) 现在会清这个 profile 的全部 runtime session
- src-tauri/crates/browser-runtime/src/manager.rs 已修正：
  - 新增 open_session_gate，串行化同一 profile_key 的 open_session
  - find_session_by_profile_key(...) 优先返回最新的 connected session
  - 新增 close_sessions_by_profile_key(...)，避免旧 session 残留
- 本轮已确认通过：
  - env CARGO_TARGET_DIR="/tmp/lime-browser-runtime-verify" cargo test --manifest-path "src-tauri/Cargo.toml" -p lime-browser-runtime
  - npm run smoke:agent-runtime-tool-surface-page -- --timeout-ms 180000 --interval-ms 1000
  - npm run smoke:browser-runtime -- --timeout-ms 180000 --interval-ms 1000 --headless
  - npm run verify:gui-smoke -- --reuse-running --timeout-ms 600000
- 本轮额外沉淀：
  - 页级 runtime smoke 不应继续被旧 session / 孤儿 profile 清理策略拖垮
  - browser runtime 的事实源应围绕 profile_key 当前活跃会话，而不是某一次 launcher 生命周期
[已被 current 目录经营卡片方案替代] 把 SceneApps 目录页从“最近场景 + 目录卡片”双块结构收口成统一的无图场景选品墙：
- 最近访问入口不再单独占一块面板，而是并入 SceneAppsCatalogPanel
- 目录卡片已补充：
  - 产出
  - 模式
  - 基建
  - 业务动作
- 当前目录页结构固定为：
  - 顶部搜索与双层筛选
  - 同语义的“继续最近工作”
  - 同语义的“按结果挑场景”
- 已同步更新：
  - src/components/sceneapps/SceneAppsCatalogPanel.tsx
  - src/components/sceneapps/SceneAppsPage.tsx
  - src/components/sceneapps/SceneAppsPage.test.tsx
  - src/lib/sceneapp/product.ts
  - docs/aiprompts/design-language.md
- 当前已确认通过：
  - npm test -- "src/components/sceneapps/SceneAppsPage.test.tsx"
  - npx eslint --no-warn-ignored "src/components/sceneapps/SceneAppsCatalogPanel.tsx" "src/components/sceneapps/SceneAppsPage.tsx" "src/components/sceneapps/SceneAppsPage.test.tsx" "src/lib/sceneapp/product.ts"
  - npm run verify:gui-smoke -- --reuse-running --timeout-ms 600000
- 本轮额外沉淀：
  - 目录页要让用户感觉自己在“选场景”，而不是在“最近记录区”和“目录区”之间切换
  - 没有图片时，也可以靠结果、模式、基建和当前状态做出 marketplace 式层级，但仍要保持 Lime 的桌面产品气质
把 smoke:agent-runtime-tool-surface-page 继续从“依赖全局配置写入”收口成“页面级调试覆盖 + 阶段日志”：
- 新增前端 workspace harness 调试覆盖读取：
  - src/lib/developerFeatures.ts
  - src/hooks/useDeveloperFeatureFlags.ts
- 当前支持通过 localStorage["lime:debug:workspace-harness-enabled:v1"] 临时打开处理工作台，而不必为了 smoke 去调用 save_config
- 这让页级 smoke 不再为了打开工作台去碰全局配置文件和环境变量应用链，进一步符合 LimeNext 当前主线里的“场景页 / smoke / 基础设置解耦”原则
- scripts/agent-runtime-tool-surface-page-smoke.mjs 已同步改成：
  - 仅注入本地 localStorage 调试覆盖
  - 不再在 finally 里回写全局配置
  - 每个关键阶段都会输出 stage=... 日志，便于继续定位真实卡点
- 已补最小回归：
  - src/lib/developerFeatures.test.ts
- 当前已确认通过：
  - npm test -- "src/lib/developerFeatures.test.ts"
  - npx eslint --no-warn-ignored "src/lib/developerFeatures.ts" "src/lib/developerFeatures.test.ts" "src/hooks/useDeveloperFeatureFlags.ts" "scripts/agent-runtime-tool-surface-page-smoke.mjs"
- 当前未完成但已确认环境状态：
  - 正在重新拉起隔离 headless Tauri 环境，当前还卡在冷编译阶段，http://127.0.0.1:3030/health 暂未恢复
  - 下一步继续等 DevBridge 就绪后重跑 npm run smoke:agent-runtime-tool-surface-page -- --timeout-ms 180000 --interval-ms 1000
重新执行 npm run verify:gui-smoke，当前主链进度已经前推到页级 runtime tool surface，而不再卡在最早的 bridge:health：
- 已确认通过：
  - smoke:workspace-ready
  - smoke:browser-runtime
  - smoke:site-adapters
  - smoke:agent-service-skill-entry
  - smoke:agent-runtime-tool-surface
- 当前最终阻塞已缩小到：
  - smoke:agent-runtime-tool-surface-page
  - 具体现象：
    - browser_execute_action 持续 fetch failed
    - close_cdp_session 持续 fetch failed
    - close_chrome_profile_session 持续 fetch failed
- 这说明本轮 SceneApp 分页改动没有把前面的 GUI 壳主链打断，剩余阻塞更像是页级浏览器动作链与 DevBridge/CDP 清理的稳定性问题
把 SceneAppsPage 的跨页路径继续从“标签切页”推进到“业务向工作流导轨”：
- 新增 SceneAppsWorkflowRail，固定把 SceneApp 主路径表达为：
  - 选场景
  - 补启动
  - 看治理
- 导轨不只是展示步骤，还会根据当前上下文给出不同动作：
  - 已有运行样本时可直接进入治理
  - 还没有运行样本时，治理步骤会回指详情页先完成首轮启动
  - 没有选中场景时，详情与治理步骤会明确回到目录
- 已同步更新：
  - src/components/sceneapps/SceneAppsWorkflowRail.tsx
  - src/components/sceneapps/SceneAppsPage.tsx
  - src/components/sceneapps/SceneAppsPage.test.tsx
  - docs/aiprompts/design-language.md
  - docs/exec-plans/limenext-plan.md
- 当前已确认通过：
  - npm test -- "src/components/sceneapps/SceneAppsPage.test.tsx"
  - npx eslint --no-warn-ignored "src/components/sceneapps/SceneAppsWorkflowRail.tsx" "src/components/sceneapps/SceneAppsPage.tsx" "src/components/sceneapps/SceneAppsPage.test.tsx"
- 本轮额外沉淀：
  - 复杂分页工作台不应只给标签页，还应给任务路径导轨
  - 跨页按钮要根据业务状态自适应目标页，而不是机械地固定跳某一页
把 SceneAppsPage 的分页式工作台继续补成“可回退、可引导”的分页级空态，而不只是标签切页：
- 新增 SceneAppsPageEmptyState，统一承接 detail / governance 两页的分页级空态
- detail 分页在没有匹配 SceneApp 时，会明确提示这是筛选结果为空，而不是继续落到“左侧目录”这种旧布局文案
- 当前已支持一键：
  - 回到场景目录
  - 清空筛选并返回目录
- governance 分页在还没有任何运行样本时，不再只显示空表，而是明确引导用户先回到详情页启动首轮结果链
- 已同步更新：
  - src/components/sceneapps/SceneAppsPageEmptyState.tsx
  - src/components/sceneapps/SceneAppsPage.tsx
  - src/components/sceneapps/useSceneAppsPageRuntime.ts
  - src/components/sceneapps/SceneAppDetailPanel.tsx
  - src/components/sceneapps/SceneAppsPage.test.tsx
- 当前已确认通过：
  - npm test -- "src/components/sceneapps/SceneAppsPage.test.tsx"
  - npx eslint --no-warn-ignored "src/components/sceneapps/SceneAppsPageEmptyState.tsx" "src/components/sceneapps/SceneAppsPage.tsx" "src/components/sceneapps/SceneAppDetailPanel.tsx" "src/components/sceneapps/useSceneAppsPageRuntime.ts" "src/components/sceneapps/SceneAppsPage.test.tsx"
- 本轮额外沉淀：
  - 分页工作台不能只把内容拆开，还要把“当前无数据时下一步去哪”直接写进页面
  - 治理页的首轮空态默认应回指详情页启动，而不是把用户留在没有运行样本的复盘页里
把 SceneAppsPage 从“同页堆叠目录 + 详情 + 治理”继续收口成“分页式信息架构”：
- 当前固定拆成三页：
  - 场景目录
  - 场景详情
  - 治理复盘
- 顶部继续保留统一 当前场景 摘要和跨页入口，避免切页后丢失业务上下文
- 目录卡片点击现在会直接进入对应详情分页，不再只是停留在选中态边框
- 自动化摘要卡片与治理摘要的读模型残留问题已顺手收口：
  - 修掉 buildSceneAppAutomationWorkspaceCardViewModel(...) 对 getSceneAppPatternSummary(...) 的错误入参
  - 删除 buildSceneAppGovernancePanelViewModel(...) 重构后遗留的未使用局部变量
- 已同步更新：
  - src/components/sceneapps/SceneAppsCatalogPanel.tsx
  - src/components/sceneapps/useSceneAppsPageRuntime.ts
  - src/components/sceneapps/SceneAppsPage.test.tsx
  - src/lib/sceneapp/product.ts
  - src/lib/sceneapp/product.test.ts
  - docs/aiprompts/design-language.md
  - docs/exec-plans/limenext-plan.md
- 当前已确认通过：
  - npm test -- "src/lib/sceneapp/product.test.ts" "src/components/sceneapps/SceneAppsPage.test.tsx"
  - npx eslint --no-warn-ignored "src/lib/sceneapp/product.ts" "src/lib/sceneapp/product.test.ts" "src/components/sceneapps/useSceneAppsPageRuntime.ts" "src/components/sceneapps/SceneAppsCatalogPanel.tsx" "src/components/sceneapps/SceneAppsPage.test.tsx"
- 本轮额外沉淀：
  - 复杂工作台默认按任务阶段分页，不再把目录、详情、治理继续堆在一屏
  - 承担导航职责的目录卡片必须有明确点击结果，不能只保留“选中态”伪反馈
把 SceneApp project pack 的治理闭环从“单次运行详情”推进到“页面级治理看板”：
- 新增 SceneAppGovernancePanel，不再只在运行详情里解释治理动作
- buildSceneAppGovernancePanelViewModel(...) 已把：
  - run summary
  - scorecard
  - evidence / review 收口成同一份业务向治理视图
- 页面级治理看板当前已经能表达：
  - 当前治理状态
  - 当前适合投放到哪里
  - 周会材料 / 结构化治理 / 请求链路 / 结果校验是否已齐
  - 推荐治理动作与继续处理入口
- 页面级治理动作继续复用既有主链：
  - prepareSceneAppRunGovernanceArtifacts(...)
  - prepareSceneAppRunGovernanceArtifact(...)
  - initialProjectFileOpenTarget
  - open automation job / agent session / browser runtime
- 已同步更新：
  - src/lib/sceneapp/product.ts
  - src/lib/sceneapp/product.test.ts
  - src/components/sceneapps/SceneAppGovernancePanel.tsx
  - src/components/sceneapps/SceneAppsPage.tsx
  - src/components/sceneapps/useSceneAppsPageRuntime.ts
  - src/components/sceneapps/SceneAppsPage.test.tsx
  - docs/exec-plans/limenext-plan.md
- 当前已确认通过：
  - npx eslint --no-warn-ignored "src/lib/sceneapp/product.ts" "src/lib/sceneapp/product.test.ts" "src/components/sceneapps/SceneAppGovernancePanel.tsx" "src/components/sceneapps/SceneAppsPage.tsx" "src/components/sceneapps/useSceneAppsPageRuntime.ts" "src/components/sceneapps/SceneAppsPage.test.tsx"
  - npm test -- "src/lib/sceneapp/product.test.ts" "src/components/sceneapps/SceneAppsPage.test.tsx"
- 当前已发起但尚未拿到最终结果：
  - npm run verify:gui-smoke
  - 本机冷编译阶段长时间卡在 bridge:health -> DevBridge 启动前，日志持续显示 rustc 编译与 fetch failed，暂时无法给出 smoke 通过结论
把 SceneApp project pack 第二阶段从 metadata artifact_paths 启发式推进到 session / evidence 事实源：
- runtime_evidence_pack_service 已抽出可复用 helper：
  - resolve_runtime_export_workspace_root(...)
  - build_runtime_evidence_sceneapp_snapshot(...)
- SceneApp 运行摘要在拿到 sessionId 时，已优先读取：
  - SessionDetail
  - AgentRuntimeThreadReadModel
  - 最近 FileArtifact
  - verification failure outcomes
- SceneApp project pack 不再默认先信 AgentRun.metadata.artifact_paths，而是改成：
  - 有 runtime evidence 时优先用真实会话产物
  - 只有缺少 session evidence 时才回退 metadata
- 交付覆盖率判断已纠正：
  - 如果 session evidence 明确存在但没有产物，现在会把覆盖率视为“已知为 0”，而不是继续落成“未知”
  - 因此运行详情能够明确给出 missing parts / 0% / pack_incomplete
- verification failure outcomes 已开始回挂到 SceneApp 失败信号：
  - 即使部件齐全，只要 runtime evidence 里还有未恢复校验失败，也会标记为 review_blocked
- SceneAppService 已统一改走 build_sceneapp_run_summary_from_agent_run_with_db(...)，避免 tracker 和 automation 侧继续各自走旧启发式
- 已补 Rust 定向回归：
  - runtime evidence 优先于 metadata artifact 列表
  - runtime verification failure 会回挂成 review_blocked
- 已同步更新：
  - src-tauri/src/services/runtime_evidence_pack_service.rs
  - src-tauri/src/commands/aster_agent_cmd/command_api/runtime_api.rs
  - src-tauri/src/sceneapp/adapters.rs
  - src-tauri/src/sceneapp/application.rs
  - src-tauri/src/services/execution_tracker_service.rs
- 本轮校验已确认通过：
  - cargo fmt --manifest-path "src-tauri/Cargo.toml" 已执行
  - cargo test --manifest-path "src-tauri/Cargo.toml" sceneapp::adapters -- --nocapture
  - cargo test --manifest-path "src-tauri/Cargo.toml" sceneapp::governance -- --nocapture
把 SceneApp project pack 的结果入口从“viewer 文案”推进到“稳定可打开的交付文件引用”：
- Rust SceneAppRunSummary 已新增 deliveryArtifactRefs
- 结果入口聚合规则已固定为：
  - 有 runtime evidence 时优先读取真实 FileArtifact
  - 缺少 session evidence 时再回退 metadata artifact_paths
  - 继续在 DTO 层暴露 relativePath / absolutePath / partKey / projectId / workspaceId / source
- 前端运行详情页已新增“结果入口”区块：
  - 会按 primaryPart 优先标记主稿
  - 点击后继续复用现有 Agent initialProjectFileOpenTarget 打开结果文件
  - 不新增新的 SceneApp viewer 协议，也不让 UI 直接解读底层 metadata
- 已同步更新：
  - src-tauri/src/services/runtime_evidence_pack_service.rs
  - src-tauri/src/sceneapp/dto.rs
  - src-tauri/src/sceneapp/adapters.rs
  - src-tauri/src/sceneapp/application.rs
  - src-tauri/src/sceneapp/governance.rs
  - src/lib/sceneapp/types.ts
  - src/lib/sceneapp/product.ts
  - src/components/sceneapps/SceneAppRunDetailPanel.tsx
  - src/components/sceneapps/useSceneAppsPageRuntime.ts
  - src/components/sceneapps/SceneAppsPage.tsx
- 当前已确认通过：
  - cargo fmt --manifest-path "src-tauri/Cargo.toml"
  - npx eslint "src/lib/sceneapp/types.ts" "src/lib/sceneapp/product.ts" "src/lib/sceneapp/product.test.ts" "src/components/sceneapps/SceneAppRunDetailPanel.tsx" "src/components/sceneapps/SceneAppsPage.tsx" "src/components/sceneapps/useSceneAppsPageRuntime.ts" "src/components/sceneapps/SceneAppsPage.test.tsx" "src/lib/tauri-mock/core.ts"
  - npm test -- "src/lib/sceneapp/product.test.ts" "src/components/sceneapps/SceneAppsPage.test.tsx"
  - cargo test --manifest-path "src-tauri/Cargo.toml" sceneapp::adapters -- --nocapture
  - cargo test --manifest-path "src-tauri/Cargo.toml" sceneapp::governance -- --nocapture
- Rust 定向测试最终结果已确认通过：
  - cargo test --manifest-path "src-tauri/Cargo.toml" sceneapp::adapters -- --nocapture
  - cargo test --manifest-path "src-tauri/Cargo.toml" sceneapp::governance -- --nocapture
把 SceneApp project pack 的治理面继续从“有证据文案”推进到“有治理入口文件引用”：
- Rust SceneAppRunSummary 已新增 governanceArtifactRefs
- 适配层会按 sessionId 组装三类稳定治理路径：
  - .lime/harness/sessions/{sessionId}/evidence/summary.md
  - .lime/harness/sessions/{sessionId}/review/review-decision.md
  - .lime/harness/sessions/{sessionId}/review/review-decision.json
- 前端运行详情页已在“证据与复核”区块新增“治理入口”卡片：
  - 证据摘要
  - 人工复核记录
  - 复核 JSON
- 点击后继续复用现有 Agent initialProjectFileOpenTarget 打开文件，不新增新的 SceneApp viewer 协议，也不让 UI 直接拼底层 metadata
- 已同步更新：
  - src-tauri/src/sceneapp/dto.rs
  - src-tauri/src/sceneapp/adapters.rs
  - src-tauri/src/sceneapp/application.rs
  - src-tauri/src/sceneapp/governance.rs
  - src/lib/sceneapp/types.ts
  - src/lib/sceneapp/product.ts
  - src/components/sceneapps/SceneAppRunDetailPanel.tsx
  - src/components/sceneapps/SceneAppsPage.tsx
  - src/components/sceneapps/useSceneAppsPageRuntime.ts
  - src/components/sceneapps/SceneAppsPage.test.tsx
  - src/lib/sceneapp/product.test.ts
  - src/lib/tauri-mock/core.ts
- 当前已确认通过：
  - cargo fmt --manifest-path "src-tauri/Cargo.toml"
  - npx eslint "src/lib/sceneapp/types.ts" "src/lib/sceneapp/product.ts" "src/lib/sceneapp/product.test.ts" "src/components/sceneapps/SceneAppRunDetailPanel.tsx" "src/components/sceneapps/SceneAppsPage.tsx" "src/components/sceneapps/SceneAppsPage.test.tsx" "src/components/sceneapps/useSceneAppsPageRuntime.ts" "src/lib/tauri-mock/core.ts"
  - npm test -- "src/lib/sceneapp/product.test.ts" "src/components/sceneapps/SceneAppsPage.test.tsx"
- 当前未完成但已定位的阻塞：
  - cargo test --manifest-path "src-tauri/Cargo.toml" sceneapp::adapters -- --nocapture
  - cargo test --manifest-path "src-tauri/Cargo.toml" sceneapp::governance -- --nocapture
  - 两条 Rust 定向测试都会被仓库里无关编译错误挡住：
    - crates/services/src/api_key_provider_service.rs:1152
    - cannot find value 'provider_type' in this scope
把 SceneApp project pack 的治理入口继续从“可打开”推进到“缺失时自动补生成”：
- 新增当前命令：
  - sceneapp_prepare_run_governance_artifact
- 命令职责固定为：
  - evidence_summary 只补导出 evidence pack
  - review_decision_markdown / review_decision_json 走统一 review decision 模板导出链
- 这样 SceneApp 页面不需要直接调用 agent_runtime_export_evidence_pack / agent_runtime_export_review_decision_template
- 前端交互已改成：
  - 点击治理入口时先调用 src/lib/api/sceneapp.ts
  - 导出成功后继续复用 initialProjectFileOpenTarget 打开对应治理文件
- 命令边界已同步更新：
  - src-tauri/src/commands/sceneapp_cmd.rs
  - src-tauri/src/app/runner.rs
  - src/lib/api/sceneapp.ts
  - src/lib/api/sceneapp.test.ts
  - src/lib/dev-bridge/mockPriorityCommands.ts
  - src/lib/governance/agentCommandCatalog.json
  - src/lib/tauri-mock/core.ts
- 页面与回归已同步更新：
  - src/components/sceneapps/useSceneAppsPageRuntime.ts
  - src/components/sceneapps/SceneAppsPage.test.tsx
  - src/lib/sceneapp/product.ts
- 当前已确认通过：
  - cargo fmt --manifest-path "src-tauri/Cargo.toml"
  - npx eslint --no-warn-ignored "src/lib/api/sceneapp.ts" "src/lib/api/sceneapp.test.ts" "src/lib/sceneapp/product.ts" "src/lib/sceneapp/product.test.ts" "src/components/sceneapps/useSceneAppsPageRuntime.ts" "src/components/sceneapps/SceneAppsPage.test.tsx" "src/lib/dev-bridge/mockPriorityCommands.ts" "src/lib/tauri-mock/core.ts"
  - npm test -- "src/lib/api/sceneapp.test.ts" "src/lib/sceneapp/product.test.ts" "src/components/sceneapps/SceneAppsPage.test.tsx"
  - npm run test:contracts
- 当前未完成但已定位的阻塞：
  - cargo test --manifest-path "src-tauri/Cargo.toml" sceneapp::adapters -- --nocapture
  - 仍会被仓库里无关编译错误挡住：
    - crates/services/src/api_key_provider_service.rs:1439
    - cannot find value 'provider_type' in this scope
把 SceneApp project pack 的治理面继续从“文件入口”推进到“业务动作”：
- 前端运行详情页已新增 治理动作 区块，而不只是列出治理文件：
  - 准备周会复盘包
  - 准备结构化治理包
- 当前动作语义固定为：
  - 周会复盘包：批量补齐 evidence_summary + review_decision_markdown，随后直接打开人工复核记录
  - 结构化治理包：批量补齐 evidence_summary + review_decision_markdown + review_decision_json，随后直接打开复核 JSON
- 批量治理仍继续经由 src/lib/api/sceneapp.ts 网关串行调用当前 sceneapp_prepare_run_governance_artifact，不让页面直接耦合底层 runtime export 命令名
- 运行详情文案已开始改成业务向表达：
  - 什么动作适合周会复盘
  - 什么动作适合生成 / 看板 / 后续自动治理消费
- 已同步更新：
  - src/lib/api/sceneapp.ts
  - src/lib/api/sceneapp.test.ts
  - src/lib/sceneapp/product.ts
  - src/lib/sceneapp/product.test.ts
  - src/components/sceneapps/SceneAppRunDetailPanel.tsx
  - src/components/sceneapps/SceneAppsPage.tsx
  - src/components/sceneapps/useSceneAppsPageRuntime.ts
  - src/components/sceneapps/SceneAppsPage.test.tsx
  - docs/exec-plans/limenext-plan.md
- 当前已确认通过：
  - npx eslint --no-warn-ignored "src/lib/api/sceneapp.ts" "src/lib/api/sceneapp.test.ts" "src/lib/sceneapp/product.ts" "src/lib/sceneapp/product.test.ts" "src/components/sceneapps/SceneAppRunDetailPanel.tsx" "src/components/sceneapps/SceneAppsPage.tsx" "src/components/sceneapps/useSceneAppsPageRuntime.ts" "src/components/sceneapps/SceneAppsPage.test.tsx"
  - npm test -- "src/lib/api/sceneapp.test.ts" "src/lib/sceneapp/product.test.ts" "src/components/sceneapps/SceneAppsPage.test.tsx"
- 正在补充：
  - npm run verify:gui-smoke
  - 当前仍在冷启动 Rust GUI smoke 编译链，尚未拿到最终结果

2026-04-15

已完成

把 SceneApp project pack 从“目录描述”推进到“真实运行与经营聚合”，不再只靠静态 profile 讲故事：
- Rust run summary 已补齐业务级交付字段：
  - deliveryRequiredParts
  - deliveryCompletedParts
  - deliveryMissingParts
  - deliveryCompletionRate
  - deliveryPartCoverageKnown
  - failureSignal
- AgentRun.metadata.artifact_paths 与 AutomationJob.last_delivery 现在都会统一装配到同一份 delivery state，前端不再只看到 artifactCount
- project pack 的 scorecard 已改成专用聚合，而不是继续混在通用成功率面板里：
  - complete_pack_rate
  - review_pass_rate
  - publish_conversion_rate
  - observedFailureSignals
  - topFailureSignal
- SceneApp 运行详情页已能直接解释：
  - 这次交齐了几项
  - 还缺哪些部件
  - 当前卡在哪个失败信号
- 经营评分页已能同时区分：
  - 基础设置包声明的静态经营口径
  - 真实运行样本回流出来的实际失败信号
- 已同步更新：
  - src-tauri/src/sceneapp/dto.rs
  - src-tauri/src/sceneapp/adapters.rs
  - src-tauri/src/sceneapp/application.rs
  - src-tauri/src/sceneapp/governance.rs
  - src/lib/sceneapp/types.ts
  - src/lib/sceneapp/product.ts
  - src/components/sceneapps/SceneAppRunList.tsx
  - src/components/sceneapps/SceneAppRunDetailPanel.tsx
  - src/components/sceneapps/SceneAppScorecardPanel.tsx
  - src/lib/tauri-mock/core.ts
- 本轮已确认通过：
  - npx eslint "src/lib/sceneapp/product.ts" "src/lib/sceneapp/product.test.ts" "src/components/sceneapps/SceneAppRunList.tsx" "src/components/sceneapps/SceneAppRunDetailPanel.tsx" "src/components/sceneapps/SceneAppScorecardPanel.tsx" "src/components/sceneapps/SceneAppsPage.test.tsx" "src/lib/tauri-mock/core.ts"
  - npm test -- "src/lib/sceneapp/product.test.ts" "src/components/sceneapps/SceneAppsPage.test.tsx"
  - npm run test:contracts
- Rust 定向测试已发起，但当前本机还有另一条长时间运行的 cargo 编译链占用构建资源，SceneApp 相关测试还在等待最终结果，后续需要补回最终通过记录
把多模态 SceneApp 的 project pack 合同正式接到统一目录、产品视图与 GUI 主链，而不是继续停留在 blueprint ref / profile ref 级别：
- src/lib/sceneapp/types.ts
- src/lib/sceneapp/catalog.ts
- src/lib/sceneapp/product.ts
- src/components/sceneapps/SceneAppDetailPanel.tsx
- src/components/sceneapps/SceneAppScorecardPanel.tsx
- 当前 SceneAppDescriptor 已新增三块稳定结构：
  - deliveryProfile
  - compositionProfile
  - scorecardProfile
- project pack 相关的：
  - artifact profile
  - viewer kind
  - required parts
  - composition steps
  - failure signals 现在都能从编译层一路进入业务向详情面板和经营评分面板
- 目录页不再只展示技术 ref，而会明确表达：
  - 最终交付什么项目包
  - 这条链分几步完成
  - 当前经营判断重点看什么
- SceneApp 的 mock 与 Tauri seeded DTO 也已同步对齐，避免只在前端测试环境里有字段、真实命令却没有：
  - src/lib/tauri-mock/core.ts
  - src-tauri/src/sceneapp/dto.rs
  - src-tauri/src/sceneapp/catalog.rs
- 定向回归已覆盖：
  - src/lib/sceneapp/catalog.test.ts
  - src/lib/sceneapp/product.test.ts
  - src/components/sceneapps/SceneAppsPage.test.tsx
- 本轮已确认通过：
  - npm test -- "src/lib/sceneapp/catalog.test.ts" "src/lib/sceneapp/product.test.ts" "src/components/sceneapps/SceneAppsPage.test.tsx"
  - npx eslint "src/lib/sceneapp/types.ts" "src/lib/sceneapp/catalog.ts" "src/lib/sceneapp/presentation.ts" "src/lib/sceneapp/product.ts" "src/lib/sceneapp/catalog.test.ts" "src/lib/sceneapp/product.test.ts" "src/components/sceneapps/SceneAppDetailPanel.tsx" "src/components/sceneapps/SceneAppScorecardPanel.tsx" "src/components/sceneapps/SceneAppsPage.test.tsx" "src/lib/tauri-mock/core.ts"
  - npm run test:contracts
  - rustfmt --check "src-tauri/src/sceneapp/dto.rs" "src-tauri/src/sceneapp/catalog.rs"
- 当前仓库级阻塞仍存在：
  - npm run typecheck 会被无关现有错误挡住：
    - src/components/provider-pool/api-key/ProviderConfigForm.ui.test.tsx
    - src/components/settings-v2/general/memory/index.tsx
  - npm run verify:gui-smoke 在 smoke:browser-runtime 阶段被现有环境问题挡住：
    - launch_browser_session 持续超时，180000ms 内未收到 DevBridge 响应
    - 日志中还出现 libsqlite3-sys ... bindgen.rs: No such file or directory 的临时构建噪音，需要后续单独排查
把 SceneApp 前端启动编排继续收口成共享 runtime，而不是让目录页和聊天空态各写一套 launch 分支：
- 新增共享启动状态机与错误格式化：
  - src/lib/sceneapp/error.ts
  - src/lib/sceneapp/launcher.ts
- 把前端 action bridge 正式迁到共享层：
  - src/lib/sceneapp/launchBridge.ts
  - src/components/agent/chat/workspace/sceneAppLaunch.ts
- 统一由共享层负责：
  - sceneAppLaunchingId
  - 自动化弹窗开关与初始值
  - automation workspace 加载
  - workspace_entry / automation_job 启动收口
  - SceneApp 相关错误文案格式化
- 两个高频入口现在都已消费同一套共享 runtime：
  - src/components/agent/chat/workspace/useWorkspaceSceneAppEntryActions.ts
  - src/components/sceneapps/useSceneAppsPageRuntime.ts
- sceneAppLaunch.ts 旧路径暂时保留为 re-export，避免现有调用方与测试路径立刻断裂
完成 SceneApp 统一启动 runtime 的一轮针对性校验：
- npm test -- "src/components/agent/chat/workspace/sceneAppLaunch.test.ts" "src/components/agent/chat/workspace/useWorkspaceSceneAppEntryActions.test.tsx" "src/components/sceneapps/SceneAppsPage.test.tsx" "src/lib/sceneapp/product.test.ts" 通过
- npx eslint "src/lib/sceneapp/error.ts" "src/lib/sceneapp/launchBridge.ts" "src/lib/sceneapp/launcher.ts" "src/components/agent/chat/workspace/useWorkspaceSceneAppEntryActions.ts" "src/components/sceneapps/useSceneAppsPageRuntime.ts" "src/components/agent/chat/workspace/sceneAppLaunch.ts" 通过
- npm run typecheck 通过
- npm run verify:gui-smoke 在沙箱内仍会因为 listen EPERM: operation not permitted 127.0.0.1:1420 失败
- 提权后重跑 npm run verify:gui-smoke 已证明：
  - 前端壳就绪
  - workspace-ready 通过
  - browser-runtime 通过
  - site-adapters 通过
  - agent-service-skill-entry 通过
  - agent-runtime-tool-surface 通过
  - agent-runtime-tool-surface-page 通过
- 仓库级页面 smoke 阻塞已收口：
  - scripts/agent-runtime-tool-surface-page-smoke.mjs 现在补齐了首页 origin / storage 就绪门禁
  - browser_execute_action 增加了针对 CDP 调试端口不可用 的重试
  - 首页输入提交改成 focus + native setter + input/change + 短暂让步 + 鼠标事件链，避免卡在发送按钮未真正推进运行态
- 当前这条 GUI 主路径已完成最终验证：
  - npm run verify:gui-smoke 通过
  - npm run smoke:agent-runtime-tool-surface-page -- --timeout-ms 180000 --interval-ms 1000 通过
新增基础设置包第一版代码骨架：
- src/lib/base-setup/types.ts
- src/lib/base-setup/validator.ts
- src/lib/base-setup/compiler.ts
- src/lib/base-setup/rolloutGate.ts
- src/lib/base-setup/compat/serviceSkillCatalogProjection.ts
- 固定第一版先把 Base Setup Package 编译成 compat ServiceSkillCatalog
- 固定 runtime 侧暂不新增执行链，继续只吃 current request_metadata
新增基础设置包主链接线模块：
- src/lib/base-setup/storage.ts
- src/lib/base-setup/bootstrap.ts
- src/lib/base-setup/serviceSkillCatalogAdapter.ts
- 固定“解析 package -> gate -> compile -> 生成快照”由基础设置层统一负责
- 固定基础设置快照与当前激活目录一起落缓存，避免后续 scene / command projection 再次各自找事实源
把基础设置包正式接回当前目录主链：
- src/lib/api/serviceSkills.ts
- src/lib/serviceSkillCatalogBootstrap.ts
- 远端 refresh、本地 save、bootstrap sync 都已支持直接消费 Base Setup Package
- 普通 catalog 覆盖时会清理旧基础设置快照，保证当前激活目录与装配快照一致
把基础设置包继续接到统一 skill / command / scene 目录主链：
- src/lib/base-setup/compat/sceneCatalogProjection.ts
- src/lib/api/skillCatalog.ts
- src/lib/skillCatalogBootstrap.ts
- Base Setup Package 现在已经不只会编译 compat ServiceSkillCatalog，也会继续投影到真实 SkillCatalog
- 显式 scene_catalog projection 已能进入 slash / scene 面板真实消费链，而不是只停在 schema 或 compat 层
- skillCatalog 的 refresh、本地 save、bootstrap sync 现在都支持直接消费 Base Setup Package
- 显式 scene projection 会优先覆盖 compat 自动 scene，避免场景面板继续吃到旧的 auto scene 文案
把 Base Setup Package -> command_catalog projection 正式接回当前输入触发层，而不是继续停在 seeded 手写 command 定义：
- src/lib/base-setup/compat/commandCatalogProjection.ts
- src/lib/api/skillCatalog.ts
- src/lib/skillCatalogBootstrap.ts
- src/components/agent/chat/workspace/useWorkspaceSendActions.ts
- skillCatalog 现在会和 scene_catalog 一样继续编译显式 command_catalog
- 显式 command projection 会优先覆盖 seeded command 定义，避免同一 commandKey 继续双轨并存
- 工作区发送层不再只读模块加载时的 seeded command map，而会按当前目录快照解析 mention -> commandKey -> bound skill
- 这一步把 LimeNext 从“目录主链回到装配层”继续推进到了“现有命令语义的输入触发层也开始回到装配层”
把剩余 seeded command fallback 也迁回基础设置包事实源，清掉 SEEDED_COMMAND_ENTRY_DEFINITIONS 这条 compat 双轨：
- src/lib/base-setup/types.ts
- src/lib/base-setup/serviceSkillCatalogAdapter.ts
- src/lib/base-setup/validator.ts
- src/lib/base-setup/compat/commandCatalogProjection.ts
- src/lib/base-setup/seededCommandPackage.ts
- src/lib/api/skillCatalog.ts
- command_catalog projection 现在支持命令侧显式 commandBinding / commandRenderContract
- seeded fallback 不再维护手写 command entry 数组，而是直接编译 seeded Base Setup Package
- 这一步把 LimeNext 从“显式 command projection 可覆盖 seeded”继续推进到了“seeded command 事实源本身也回到装配层”
把默认云端 seeded 目录迁到装配层事实源：
- src/lib/base-setup/seededServiceSkillPackage.ts
- src/lib/api/serviceSkills.ts
- 默认 7 个内置云端场景不再手写为 ServiceSkillCatalog，而是改成手写 Base Setup Package 后编译出 compat catalog
把 seeded 本地 local_custom 项也迁到装配层事实源：
- src/lib/base-setup/seededServiceSkillPackage.ts
- src/lib/base-setup/compat/serviceSkillCatalogProjection.ts
- src/lib/api/serviceSkills.ts
- x-article-export 不再手写为 ServiceSkillItem 补丁，而是改成手写 Base Setup Package 后编译出 local_custom 目录项
- 当前 seeded 目录已经从“编译产物 + 手写补丁”推进到“云端默认包编译产物 + 本地定制包编译产物”
- 同步纠正了 sceneBinding 不应强行把 runnerType 覆盖成 managed 的 compat 编译逻辑
新增基础设置包单测：
- src/lib/base-setup/validator.test.ts
- src/lib/base-setup/compiler.test.ts
- src/lib/base-setup/rolloutGate.test.ts
- src/lib/base-setup/storage.test.ts
- src/lib/base-setup/bootstrap.test.ts
- src/lib/base-setup/seededServiceSkillPackage.test.ts
- 证明结构校验、引用校验、catalog projection 与 rollout gate 决策已跑通
新增 scene_catalog 接线回归：
- src/lib/api/skillCatalog.test.ts
- src/lib/skillCatalogBootstrap.test.ts
- 证明 Base Setup Package -> SkillCatalog 已跑通
- 证明 bootstrap payload 直接下发 baseSetupPackage 时，scene_catalog projection 与基础设置快照都能落到真实消费链
- 证明显式 scene projection 已能覆盖 compat 自动 scene
新增 seeded 本地定制装配回归：
- src/lib/base-setup/seededServiceSkillPackage.test.ts
- src/lib/api/serviceSkills.test.ts
- 证明 x-article-export 已由本地定制基础设置包编译生成，而不是继续依赖手写补丁
- 证明 local_custom 来源、browser_assist binding、sceneBinding 与 skill bundle metadata 都已稳定保留
新增基础设置包实现设计专题：
- base-setup-implementation.md
- 固定第一版先以 Base Setup Package -> compat ServiceSkillCatalog projection 落地
- 固定第一版不重写产品面 API，而是先改 ServiceSkillCatalog 背后的编译来源
- 固定 validator / compiler / rollout gate 的建议模块拆分与接线顺序
新增基础设置包投影与发布生命周期专题：
- base-setup-projection-lifecycle.md
- 固定装配包从编写、校验、投影编译、灰度发布、bootstrap 拉取、seeded 兜底到回滚的完整链路
- 固定最小 validator 分层：L0 结构 / L1 装配 / L2 宿主边界
- 固定“只要 L2 不通过，就必须升级主 App”的门禁
新增基础设置包顶层 schema：
- base-setup-package-schema.md
- 固定 Base Setup Package 的 v1 顶层字段、目录投影、profile 结构与最小 validator 口径
- 固定“改包、改投影、改宿主”的判断表
新增组合蓝图 schema 草案：
- composition-blueprint-schema.md
- 固定 composition blueprint 的 v1 顶层字段、步骤字段、校验规则与 project_pack 最小合同
- 固定 v1 只支持“有序步骤链”，不先做通用 DAG
继续收口 LimeNext 总纲，明确平台主张不仅是“场景工作台”，也是“快捷组合多模态能力的 SceneApp factory”
在以下文档中引入统一口径：
- README.md
- prd.md
- architecture.md
- sceneapp-capability-model.md
- sceneapp-blueprints.md
- flowcharts.md
- sequences.md
- artifact-evidence-scorecards.md
- metrics-and-selection.md
- execution-plan.md
- base-setup-decoupling.md
- agent-skills-profile.md
把 composition blueprint 固定为基础设置包中的通用装配对象：
- recipe 只保留为别名
- 不新增 runtime taxonomy
- 不新增第六种 binding family
把第一条组合型样板正式收口为：
- 文本 -> 线框图 -> 配乐 -> 剧本 -> 短视频草稿
- 归类为 Hybrid / Multimodal Composition SceneApp
- 交付合同固定为 project pack
把 LimeNext 业务图和业务时序继续改成“非技术同学也能看懂”的版本：
- 增加多模态组合业务流图
- 增加基础设置包如何下发组合场景的技术图
- 增加组合蓝图编排多模态结果链的业务 / 技术时序
更新执行计划与总实施计划：
- execution-plan.md
- limenext-plan.md
- 明确多模态组合样板成为第五条默认样板链路
- 明确当前下一刀已经切到“seeded 事实源迁移 + scene / command projection 扩展”
把 SceneApp 第一阶段全栈骨架正式落地到当前代码主链：
- src/lib/sceneapp/*
- src/lib/api/sceneapp.ts
- src-tauri/src/sceneapp/*
- src-tauri/src/commands/sceneapp_cmd.rs
- docs/roadmap/limenext/sceneapp-*.md
- 固定 SceneApp 不新增 runtime taxonomy，继续只作为 Scene / ServiceSkill + 执行实体 + 基础设施画像 + 交付治理 的装配层
把第一条真实 SceneApp adapter 固定为 SceneApp -> automation job：
- sceneapp_create_automation_job 已接通 automation draft / tracker metadata / run summary 主链
- daily-trend-briefing 已作为 Local Durable SceneApp 的 seeded descriptor、mock catalog 与测试样板统一事实源
- browser_assist / cloud_scene / native_skill / agent_turn 其他 adapter 继续留在下一阶段推进
把 sceneapp_plan_launch 从抽象 planner 推进到半结构化 adapter planner：
- SceneAppPlanResult.plan.adapterPlan 已能明确输出 runtimeAction / targetRef / requestMetadata / launchPayload
- 当前已覆盖 cloud_scene / browser_assist / automation_job / native_skill / agent_turn 五类 adapter draft
- 这让后续 SceneApp UI 和执行入口可以复用 current runtime，而不是再拼第二套 SceneApp 执行协议
把 SceneAppPlanResult.plan.adapterPlan 继续收口成前端统一执行 facade：
- src/lib/sceneapp/launch.ts
- buildSceneAppExecutionDraft(...) 现已固定输出两类 current runtime 草稿：
  - workspace_entry
  - automation_job
- workspace_entry 继续复用当前工作区启动语义：
  - prompt
  - initialAutoSendRequestMetadata
  - projectId / contentId
  - openBrowserAssistOnMount
- automation_job 同时兼容当前两条自动化主链：
  - SceneAppAutomationIntent
  - AutomationJobRequest
  - AutomationJobDialogInitialValues
- 这意味着 SceneApp 前端后续接线时，不必再让各个页面自己理解 adapterPlan.launchPayload 的 snake_case 草稿
- 新增 SceneApp 执行 facade 回归：
- src/lib/sceneapp/launch.test.ts
- 覆盖 cloud_scene / browser_assist / automation_job 三条主链翻译
- 证明 story-video-suite / x-article-export / daily-trend-briefing 已有可复用的前端执行草稿
把 SceneApp 前端执行草稿继续接到真实前端 action bridge：
- src/components/agent/chat/workspace/sceneAppLaunch.ts
- 当前已形成统一 SceneApp launch action bridge：
  - resolveSceneAppLaunchAction(...)
  - executeSceneAppLaunchAction(...)
- workspace_entry 现在会继续翻译成真实 resolveWorkspaceEntry(...) 结果，而不是让 UI 自己再拼导航参数
- automation_job 现在支持两条 current 前端路径：
  - 打开标准自动化表单
  - 直接调用 sceneapp_create_automation_job
- 这让未来的 SceneApp 目录页、详情页、推荐位都可以复用同一套启动动作桥，而不是各写一份 launch 分支
新增 SceneApp action bridge 回归：
- src/components/agent/chat/workspace/sceneAppLaunch.test.ts
- 覆盖：
  - workspace_entry -> agent navigation
  - workspace_entry -> missing project
  - workspace_entry -> missing navigate callback
  - automation_job -> open dialog
- automation_job -> create job
- 再补 workspaceEntry.test.ts 联动回归，证明新桥未偏离现有工作区导航合同
把 SceneApp 统一启动桥真正接到主工作区空态入口：
- src/components/agent/chat/workspace/useWorkspaceSceneAppEntryActions.ts
- src/components/agent/chat/components/EmptyStateSceneAppsPanel.tsx
- src/components/agent/chat/sceneappEntryTypes.ts
- src/components/agent/chat/components/EmptyState.tsx
- src/components/agent/chat/workspace/chatSurfaceProps.ts
- src/components/agent/chat/workspace/WorkspaceConversationScene.tsx
- src/components/agent/chat/workspace/useWorkspaceConversationSceneRuntime.tsx
- src/components/agent/chat/AgentChatWorkspace.tsx
- 当前 SceneApp 已不再只停在库层：
  - story-video-suite 会从空态推荐位直接进入当前会话继续
  - daily-trend-briefing 会直接打开标准自动化表单
  - x-article-export 会在检测到 URL 上下文时进入推荐位
- 固定 SceneApp 自动化仍复用标准 AutomationJobDialog 与 create_automation_job 主链，只在 UI 层补回 sceneapp metadata，不新增第二套 editor
新增 SceneApp 工作区入口回归：
- src/components/agent/chat/workspace/useWorkspaceSceneAppEntryActions.test.tsx
- src/components/agent/chat/components/EmptyState.test.tsx
- src/components/agent/chat/workspace/useWorkspaceConversationSceneRuntime.test.ts
- 覆盖：
  - featured SceneApp 卡片分类
  - URL 条件显示 x-article-export
  - workspace_entry -> agent 导航
  - automation_job -> 标准自动化表单 -> create_automation_job
把 SceneApp 从“空态推荐位”推进成真正的目录工作台：
- 新增独立页面与信息架构入口：
  - src/components/sceneapps/SceneAppsPage.tsx
  - src/components/sceneapps/useSceneAppsPageRuntime.ts
  - src/components/sceneapps/SceneAppsCatalogPanel.tsx
  - src/components/sceneapps/SceneAppDetailPanel.tsx
  - src/components/sceneapps/SceneAppScorecardPanel.tsx
  - src/components/sceneapps/SceneAppRunList.tsx
  - src/components/sceneapps/index.ts
  - src/types/page.ts
  - src/components/AppPageContent.tsx
  - src/lib/navigation/sidebarNav.ts
- 当前目录页已经具备完整闭环：
  - 业务向目录检索与模式筛选
  - 详情页、启动输入、项目工作区选择
  - workspace_entry -> agent 启动
  - automation_job -> AutomationJobDialog -> create_automation_job
  - scorecard + recent runs 统一回流展示
- 同时把 SceneApp 展示语义和自动化辅助从聊天工作区抽成共享层：
  - src/lib/sceneapp/presentation.ts
  - src/lib/sceneapp/automation.ts
- 这意味着后续再扩：
  - 首页推荐位
  - 目录页
  - 详情页
  - 未来更多入口都不需要各写一份 SceneApp 文案、seed、project gate、automation metadata merge
把 SceneApp 目录页入口继续收口成可恢复的跨入口协议：
- src/lib/sceneapp/entry.ts
- src/lib/sceneapp/storage.ts
- 当前已固定三种目录进入模式：
  - browse
  - resume_latest
  - prefer_latest
- 这让侧边栏、聊天空态、未来插件入口都不需要自己拼“最近访问优先还是浏览目录”的判断
- 最近访问存储同时新增统一订阅能力，跨入口 UI 可以感知“是否存在可恢复场景”，而不用自己读取 localStorage 细节
把 SceneApp 最近恢复能力接回两个高频入口：
- src/lib/navigation/sidebarNav.ts
- src/components/AppSidebar.tsx
- src/components/agent/chat/AgentChatWorkspace.tsx
- src/components/agent/chat/components/EmptyStateSceneAppsPanel.tsx
- src/components/agent/chat/components/EmptyState.tsx
- src/components/agent/chat/workspace/chatSurfaceProps.ts
- src/components/agent/chat/workspace/WorkspaceConversationScene.tsx
- src/components/agent/chat/workspace/useWorkspaceConversationSceneRuntime.tsx
- 当前交互已经更清楚：
  - 侧边栏“场景应用”默认恢复最近一次 SceneApp 上下文
  - 聊天空态显式区分“继续最近场景”和“查看全部场景”
  - 浏览目录与恢复上次上下文不再共用一个语义模糊的按钮
新增最近恢复链路回归：
- src/lib/sceneapp/entry.test.ts
- src/lib/sceneapp/storage.test.ts
- src/components/AppSidebar.test.tsx
- src/components/agent/chat/components/EmptyState.test.tsx
- 证明：
  - 最近访问订阅已生效
  - 侧边栏点击会优先恢复最近 SceneApp
  - 空态会显式暴露“继续最近场景”动作
把 SceneApp 目录页继续推进到独立的产品视图模型层：
- src/lib/sceneapp/product.ts
- src/components/sceneapps/useSceneAppsPageRuntime.ts
- src/components/sceneapps/SceneAppsPage.tsx
- src/components/sceneapps/SceneAppsCatalogPanel.tsx
- src/components/sceneapps/SceneAppDetailPanel.tsx
- src/components/sceneapps/SceneAppScorecardPanel.tsx
- src/components/sceneapps/SceneAppRunList.tsx
- src/components/sceneapps/SceneAppRunDetailPanel.tsx
- 当前 SceneAppsPage 已不再让组件自己直接解释底层 DTO：
  - workbench summary stats
  - catalog card copy
  - detail panel copy
  - scorecard view
  - run list / run detail 都统一收口到 SceneApp product view model
- 这让后续首页推荐位、独立详情页、经营面板可以复用同一层业务解释，而不是重复从 descriptor / run / scorecard 重新拼 UI
新增产品视图模型回归：
- src/lib/sceneapp/product.test.ts
- src/components/sceneapps/SceneAppsPage.test.tsx
- 证明目录统计、详情视图和运行详情已经可以通过共享产品层稳定产出
把空态 SceneApp 面板补上“查看全部场景”入口，并接到统一 sceneapps 目录页：
- src/components/agent/chat/components/EmptyStateSceneAppsPanel.tsx
- src/components/agent/chat/components/EmptyState.tsx
- src/components/agent/chat/workspace/chatSurfaceProps.ts
- src/components/agent/chat/workspace/WorkspaceConversationScene.tsx
- src/components/agent/chat/workspace/useWorkspaceConversationSceneRuntime.tsx
- src/components/agent/chat/AgentChatWorkspace.tsx
- 现在用户可以：
  - 在聊天空态直接启动精选 SceneApp
  - 或跳到完整目录页再选型、看 scorecard、看 runs、再启动
新增 SceneApp 目录页回归与路由回归：
- src/components/sceneapps/SceneAppsPage.test.tsx
- src/components/AppPageContent.test.tsx
- src/hooks/useAppNavigation.test.tsx
- src/lib/navigation/sidebarNav.test.ts
- 覆盖：
  - 目录页渲染与详情联动
  - workspace_entry -> agent
  - automation_job -> 标准自动化弹窗
  - 侧边栏与页面分发接线
把 SceneApp 目录页继续补到“运行详情可经营”的状态：
- src/components/sceneapps/SceneAppRunDetailPanel.tsx
- src/components/sceneapps/SceneAppRunList.tsx
- src/components/sceneapps/useSceneAppsPageRuntime.ts
- src/lib/sceneapp/presentation.ts
- 当前目录页已经形成：
  - runs -> selected run -> run summary 的独立状态流
  - scorecard 与 runs 解耦加载，不再因为一个接口失败把另一块也清空
  - 运行来源、运行阶段、下一步动作的共享解释层
- 这意味着目录页不再只展示“最近运行列表”，而开始具备真实的运行复盘面板
- 后续再接首页推荐位、运营面板或更细颗粒的 evidence 视图时，可以继续复用同一套 run presentation 语义
把 SceneApp 目录页继续补到“状态可恢复、可分享”的状态：
- src/components/sceneapps/useSceneAppsPageRuntime.ts
- src/components/sceneapps/SceneAppsPage.test.tsx
- src/components/AppPageContent.test.tsx
- src/types/page.ts
- 当前目录页现在已经支持把以下状态安全回写到 pageParams：
  - sceneappId
  - runId
  - projectId
  - search
  - prefillIntent
  - typeFilter / patternFilter
- 同时补了反向回灌：
  - 同页再次导航到 sceneapps 时，目录页会用新的 pageParams 覆盖本地状态
把 SceneApp 运行详情继续补到“可回到业务入口”的状态：
- src/lib/sceneapp/types.ts
- src/lib/sceneapp/product.ts
- src/components/sceneapps/SceneAppRunDetailPanel.tsx
- src/components/sceneapps/useSceneAppsPageRuntime.ts
- src/components/sceneapps/SceneAppsPage.tsx
- src-tauri/src/sceneapp/dto.rs
- src-tauri/src/sceneapp/adapters.rs
- src-tauri/src/sceneapp/application.rs
- 当前目录页已经不再只是解释“这次跑完了什么”，还开始解释“现在该回哪里继续”：
  - SceneAppRunSummary 新增 sourceRef
  - 运行详情视图模型新增 entryAction
  - 第一条真实恢复动作先固定为 automation -> job detail
  - 第二条真实恢复动作已补成 chat / skill -> agent session
- 目录页运行详情现在可以直接跳回对应自动化任务：
  - source=automation
  - sourceRef=jobId
  - 页面 runtime 会统一翻译成 automation / selectedJobId / workspaceTab=tasks
- 目录页运行详情现在也可以直接回到对应 Agent 会话：
  - SceneAppRunSummary 新增 sessionId
  - Agent 页新增 initialSessionId
  - source=chat / skill 且存在 sessionId 时，会统一翻译成 agent -> initialSessionId
- 这一步把 SceneApp 从“可启动、可复盘”继续推进到“可恢复到业务入口”，为后续 agent / browser runtime 深链收口留出统一合同
把 browser_assist 场景的运行恢复也接回统一协议，而不是继续由 UI 猜测浏览器上下文：
- src/lib/sceneapp/types.ts
- src/lib/sceneapp/product.ts
- src/components/sceneapps/useSceneAppsPageRuntime.ts
- src/components/sceneapps/SceneAppsPage.test.tsx
- src-tauri/src/sceneapp/dto.rs
- src-tauri/src/sceneapp/adapters.rs
- src-tauri/src/commands/aster_agent_cmd/run_metadata/social_artifacts.rs
- src-tauri/src/commands/aster_agent_cmd/tests.rs
- 当前已固定第一版浏览器恢复对象为：
  - browserRuntimeRef = { profileKey, sessionId, targetId }
- 运行详情视图模型新增 open_browser_runtime 动作：
  - 浏览器场景存在 browserRuntimeRef 时，优先回到 browser-runtime
  - 没有浏览器引用时，chat / skill -> agent session 仍作为稳定兜底
- Rust 侧运行摘要现在会统一合并两类事实源：
  - 运行终态 metadata 里的 browser_runtime_ref / browser_session
  - request metadata 里的 browser_assist
- 运行观测层也开始把 tool result metadata 中的浏览器会话回写到 run metadata：
  - profile_key
  - session_id
  - target_id
- 这意味着 x-article-export 这类 Browser-grounded SceneApp 终于可以从目录页直接回到真实浏览器运行时，而不是只回聊天页
把 cloud_scene / native_skill 也补进同一套 SceneApp 启动与恢复合同，而不是继续在 UI 层分散猜测 metadata：
- src/lib/sceneapp/types.ts
- src/lib/sceneapp/product.ts
- src/lib/sceneapp/launch.ts
- src/components/sceneapps/useSceneAppsPageRuntime.ts
- src/components/agent/chat/workspaceEntry.ts
- src/components/agent/chat/workspace/useWorkspaceServiceSkillEntryActions.ts
- src/components/agent/chat/AgentChatWorkspace.tsx
- src/types/page.ts
- src-tauri/src/sceneapp/dto.rs
- src-tauri/src/sceneapp/adapters.rs
- 当前已固定两类新恢复引用：
  - cloudSceneRuntimeRef
  - nativeSkillRuntimeRef
- 当前目录页运行详情新增两类结构化业务动作：
  - open_cloud_scene_session
  - open_native_skill_session
- cloud_scene 现在不再只回退到普通会话：
  - 有 sessionId 时优先回到原 Agent 会话
  - 没有 sessionId 时，会基于 service_scene_launch 结构化引用重新恢复云端 Scene 上下文
- native_skill 启动桥也不再伪装成普通 prompt：
  - SceneApp launch facade 现在会产出 initialPendingServiceSkillLaunch
  - AgentPendingServiceSkillLaunch 新增 skillKey / launchUserInput
  - 挂起技能入口现在可以保留原始 SceneApp 用户意图和已补齐 slots，再交给现有服务技能主链继续执行
- Rust 侧运行摘要现在会统一提取两类事实源：
  - service_scene_launch
  - sceneapp_native_skill_launch
- 这意味着 SceneApp 的五类 current 执行体已经全部进入统一协议：
  - automation_job
  - agent_turn
  - browser_assist
  - cloud_scene
  - native_skill
把 SceneApp 运行复盘与评分从 seeded 模板推进到真实聚合：
- src-tauri/src/sceneapp/adapters.rs
- src-tauri/src/sceneapp/application.rs
- src-tauri/src/sceneapp/governance.rs
- src-tauri/src/commands/sceneapp_cmd.rs
- sceneapp_list_runs 现在会统一聚合：
  - ExecutionTracker 里的 chat / skill / automation 真实运行
  - 自动化任务的 durable job 记录
  - 没有真实样本时才回退 seeded baseline
- sceneapp_get_scorecard 现在会基于真实 runs 计算：
  - 运行样本充足度
  - 执行成功率
  - 结果产出率
  - 重复使用率
- 推荐动作也不再只按 sceneapp_type 写死，而会根据真实运行表现切到：
  - launch
  - keep
  - optimize
  - retire
- 同时补了 Rust 定向回归，覆盖：
  - artifact count 从 run metadata / automation delivery 提取
  - scorecard 的 keep / seeded fallback / retire 决策
  - 不再只在首次挂载时读取参数
- 固定实现规则：
  - 文本类参数使用轻量防抖同步，避免输入时触发导航风暴
  - 统一 normalize + serialize 单一键值比较，不让页面和导航层各自发明一套相等性判断
- 这意味着未来再做：
  - 最近访问的 SceneApp 恢复
  - 可复制的目录页深链接
  - 从聊天页/推荐位/运营面板跳回目录的状态保持都可以继续复用当前参数协议
把 SceneApp 前台继续接到 Base Setup Package 的 scorecard / composition 装配层：
- src/lib/sceneapp/catalog.ts
- src/lib/sceneapp/product.ts
- src/components/sceneapps/SceneAppDetailPanel.tsx
- src/components/sceneapps/SceneAppScorecardPanel.tsx
- src/components/sceneapps/useSceneAppsPageRuntime.ts
- src/lib/sceneapp/catalog.test.ts
- src/lib/sceneapp/product.test.ts
- src/components/sceneapps/SceneAppsPage.test.tsx
- 当前目录页已经不再只显示 seeded 业务文案，而会继续暴露基础设置包里的：
  - compositionBlueprintRef / compositionStepCount
  - scorecardProfileRef / scorecardMetricKeys
- 详情面板现在可以直接看到组合蓝图和评分 profile
- 评分面板现在也会沿 view model 主链显示当前 scorecard profile 与 metric keys，而不是重新耦合 raw descriptor
- 即使还没有真实评分样本，评分面板也会先保留基础设置包里的观察口径，不再整块退回“纯空态”
- 即使评分接口暂时失败，评分面板也会继续保留当前 profile 与指标口径，不再因为 error state 把装配层上下文一起抹掉
- 这意味着 Base Setup Package -> SceneApp descriptor -> product view model -> SceneAppsPage 这条前台消费链已经闭环
把 SceneApp 目录页继续补到“最近访问 / 一键继续”的状态：
- src/lib/sceneapp/navigation.ts
- src/lib/sceneapp/storage.ts
- src/lib/sceneapp/storage.test.ts
- src/components/sceneapps/SceneAppsRecentPanel.tsx
- src/components/sceneapps/useSceneAppsPageRuntime.ts
- 当前目录页现在已经具备：
  - SceneApp 最近访问记录的统一本地事实源
  - sceneappId + projectId 维度去重更新，而不是无上限堆积重复记录
  - “继续上次上下文”与最近场景列表的业务入口
- 同时补了一个重要门禁：
  - 空参打开目录页时，默认首项自动选中不会立刻写回导航和最近访问
  - 只有显式页面参数或用户真实交互后，才会触发同步与持久化
- 这意味着后续再接：
  - 侧边栏空参进入后的恢复入口
  - 首页推荐位跳转后的回流继续
  - 场景运营面板的最近活跃列表都可以复用同一套 SceneApp page state + recent visit 协议

当前判断

LimeNext 现在不该再被理解成“很多单点场景的目录”，而应被理解成“场景对象 + 组合蓝图 + 结果包”的装配平台
composition blueprint 这层已经进入正式文档口径，后续可以继续下沉到 schema、投影和校验规则
composition blueprint 现在已经不只是术语，而有了 v1 schema 草案和最小 validator 口径
Base Setup Package 现在也不再只是概念层，而有了顶层对象、目录投影和兼容性校验口径
基础设置包现在不仅回答“长什么样”，也开始回答“怎么发布、怎么灰度、怎么回滚”
基础设置包这条线现在也开始回答“第一版先改什么代码、先不改什么代码”
基础设置包这条线现在已经不只是文档设计，而有了第一版代码骨架和最小单测闭环
基础设置包这条线现在也不再只是“独立模块可跑”，而是已经接回 serviceSkills.ts 与 bootstrap 的真实主链
基础设置包这条线现在还开始接管默认 seeded 云端目录，说明装配层已经不再只是“远端来的东西才走”
基础设置包这条线现在也开始接管 seeded 本地定制项，说明内置目录的主要来源已经都回到装配层
基础设置包这条线现在也已经接回 skillCatalog.ts 与 skillCatalogBootstrap.ts，说明 scene_catalog 不再只是未来规划，而是进入真实产品入口
SceneApp 这一层现在也不再只是路线图术语，而已经具备前后端统一 descriptor、命令边界、durable adapter 与治理 metadata 主链
SceneApp planner 现在也不再只会输出“解释性步骤”，而开始输出可执行的 current runtime adapter draft
SceneApp 前端现在也不再只有 planner 结果，而开始具备统一 execution draft facade，说明 adapterPlan 已经进入可接线阶段
SceneApp 前端现在也不再只有 execution draft facade，而开始具备真实 action bridge 与首个空态业务入口，说明“库层桥接”这一刀已经完成
SceneApp 统一恢复协议现在也不再只覆盖前三条浅链，而是已经把 browser_assist / cloud_scene / native_skill 的深链恢复一起收口
当前 SceneApp 首页入口已经开始用业务语言而不是 runtime 术语表达：
- 多模态组合
- 资料沉淀
- 持续研究
SceneApp 消费层现在已经不再只有空态推荐，而开始具备真正的目录工作台、详情页、scorecard 和 recent runs 视图
当前四类样板已经覆盖：
- 浏览器采集导出
- 云端托管媒体生产
- 本地持续跟踪
- 多模态组合结果链
基础设置包现在已经不只是“目录下发”，还承担多步骤组合链的业务装配语义
durable 场景的 automation 装配现在也不再只靠 slot.type=schedule_time 和运行时临时拼装：
- Base Setup Package 已新增 automationProfiles[]
- catalogProjection.automationProfileRef 已进入 validator / parser / projection metadata / snapshot index
- 每日趋势摘要 / 账号增长跟踪 seeded durable 样板已显式声明 automation profile
- service-skills/automationDraft.ts 现在会优先消费装配层的 schedule / delivery / retry / enabled 预设，再回退到旧的 slot fallback
durable 场景的 automation fallback 现在也开始回到同一装配主链：
- src/lib/base-setup/automationProjection.ts 已成为统一解析层
- 当前 durable 启动不再需要直接读页面层或手写 seeded 补丁来猜 automation 默认值
- service_skill.request_metadata.base_setup 也开始携带稳定的 package / projection / automation profile 引用，方便后续 automation detail / SceneApp run / scorecard 继续对齐同一事实源

风险

如果后续只把 composition blueprint 写成单一场景私有 workflow，通用装配层会再次失效
如果后续让 catalog projection、binding profile、artifact profile 分别在不同文档里各说各话，基础设置包会再次失去顶层约束
如果后续只写 schema，不把 validator / rollout / seeded fallback 做成真实门禁，团队还是会退回“改了文档等于完成”
如果后续跳过 compat projection，直接要求所有前台入口原生理解 Base Setup Package，改动面会过大，容易再次拖慢主线
如果后续 command_catalog 或 automation projection 继续停在手写补丁层，装配主线仍然会长期半双轨
如果后续把新增 command_catalog projection 误判成“已经支持任意新命令 DSL”，会高估当前阶段；现阶段仍主要服务现有命令语义的事实源收口
如果后续 SceneApp UI 又回到从 serviceSkills.ts、skillCatalog.ts、selector 各自拼语义，统一 descriptor 主链会再次失效
如果后续给组合型场景单独发明 viewer 或 binding，宿主边界会再次变模糊
如果后续只看最终视频草稿成败，不看 project pack 接受率与阶段返工率，组合场景很容易被误判

下一刀

durable 场景的 automation projection / fallback 已收口到装配主链，下一步转为：
- 基于 base-setup-implementation.md 决定第一版真实实现路线：客户端编译，还是服务端预编译 + 客户端 gate
- 把多模态组合样板的 project pack 接到真实 artifact / viewer / scorecard 聚合入口
- 把 SceneScorecard 与周会模板、场景看板和生成口径继续打通
- 继续把 automation detail / SceneApp run / scorecard 聚合层消费同一组 base-setup refs，而不是各自回退到运行时猜测
SceneApp 恢复协议当前已稳定收口到：
- sourceRef
- sessionId
- browserRuntimeRef
- cloudSceneRuntimeRef
- nativeSkillRuntimeRef
browser-runtime GUI smoke 当前也已恢复通过，所以后续主线不再是“先救 smoke 环境”，而是“把组合交付和经营聚合真正接起来”

验证

已执行：
- npm run harness:doc-freshness
- 结果：clean
- npm test -- "src/lib/base-setup/validator.test.ts" "src/lib/base-setup/compiler.test.ts" "src/lib/base-setup/rolloutGate.test.ts" "src/lib/base-setup/storage.test.ts" "src/lib/base-setup/bootstrap.test.ts" "src/lib/base-setup/seededServiceSkillPackage.test.ts" "src/lib/api/serviceSkills.test.ts" "src/lib/serviceSkillCatalogBootstrap.test.ts"
- 结果：8 files / 34 tests passed
- npm test -- "src/lib/api/skillCatalog.test.ts" "src/lib/skillCatalogBootstrap.test.ts"
- 结果：2 files / 9 tests passed
- npm test -- "src/components/agent/chat/workspace/useWorkspaceSceneAppEntryActions.test.tsx" "src/components/agent/chat/components/EmptyState.test.tsx" "src/components/agent/chat/workspace/sceneAppLaunch.test.ts"
- 结果：3 files / 33 tests passed
- npm test -- "src/lib/sceneapp/product.test.ts" "src/lib/sceneapp/launch.test.ts" "src/components/agent/chat/workspace/sceneAppLaunch.test.ts" "src/components/agent/chat/workspaceEntry.test.ts" "src/components/sceneapps/SceneAppsPage.test.tsx" "src/lib/api/sceneapp.test.ts"
- 结果：6 files / 47 tests passed
- cargo test --manifest-path "src-tauri/Cargo.toml" sceneapp::adapters
- 结果：5 tests passed
- cargo test --manifest-path "src-tauri/Cargo.toml" sceneapp::governance
- 结果：3 tests passed
- npm run typecheck
- 结果：passed
- npm test -- "src/components/agent/chat/workspace/useWorkspaceConversationSceneRuntime.test.ts"
- 结果：1 file / 7 tests passed
- npx eslint "src/components/agent/chat/workspace/useWorkspaceSceneAppEntryActions.ts" "src/components/agent/chat/workspace/useWorkspaceSceneAppEntryActions.test.tsx" "src/components/agent/chat/components/EmptyStateSceneAppsPanel.tsx" "src/components/agent/chat/components/EmptyState.test.tsx" "src/components/agent/chat/components/EmptyState.tsx" "src/components/agent/chat/AgentChatWorkspace.tsx" "src/components/agent/chat/workspace/useWorkspaceConversationSceneRuntime.tsx" "src/components/agent/chat/workspace/WorkspaceConversationScene.tsx" "src/components/agent/chat/workspace/chatSurfaceProps.ts"
- 结果：passed
- npm test -- "src/lib/base-setup/seededServiceSkillPackage.test.ts" "src/lib/api/serviceSkills.test.ts" "src/lib/api/skillCatalog.test.ts" "src/lib/serviceSkillCatalogBootstrap.test.ts" "src/lib/skillCatalogBootstrap.test.ts"
- 结果：5 files / 32 tests passed
- npm test -- "src/lib/base-setup/compat/commandCatalogProjection.test.ts" "src/lib/api/skillCatalog.test.ts" "src/lib/skillCatalogBootstrap.test.ts" "src/components/agent/chat/workspace/useWorkspaceSendActions.test.tsx"
- 结果：4 files / 94 tests passed
- npx eslint "src/lib/base-setup/compat/commandCatalogProjection.ts" "src/lib/base-setup/compat/commandCatalogProjection.test.ts" "src/lib/api/skillCatalog.ts" "src/lib/api/skillCatalog.test.ts" "src/lib/skillCatalogBootstrap.test.ts" "src/components/agent/chat/workspace/useWorkspaceSendActions.ts" "src/components/agent/chat/workspace/useWorkspaceSendActions.test.tsx"
- 结果：passed
- npm run verify:gui-smoke
- 结果：通过
- npm run verify:local
- 结果：通过
- npm test -- "src/lib/base-setup/automationProjection.test.ts" "src/lib/base-setup/validator.test.ts" "src/lib/base-setup/compiler.test.ts" "src/lib/base-setup/storage.test.ts" "src/lib/base-setup/seededServiceSkillPackage.test.ts" "src/components/agent/chat/service-skills/automationDraft.test.ts"
- 结果：6 files / 21 tests passed
- npm run typecheck
- 结果：通过
- npx eslint "src/lib/base-setup/types.ts" "src/lib/base-setup/serviceSkillCatalogAdapter.ts" "src/lib/base-setup/validator.ts" "src/lib/base-setup/compat/serviceSkillCatalogProjection.ts" "src/lib/base-setup/seededServiceSkillPackage.ts" "src/lib/base-setup/automationProjection.ts" "src/lib/base-setup/automationProjection.test.ts" "src/lib/base-setup/storage.test.ts" "src/lib/base-setup/seededServiceSkillPackage.test.ts" "src/lib/base-setup/validator.test.ts" "src/lib/sceneapp/catalog.test.ts" "src/components/agent/chat/service-skills/automationDraft.ts" "src/components/agent/chat/service-skills/automationDraft.test.ts"
- 结果：通过
- npm run verify:local
- 结果：未通过；当前仓库另一路改动在 src/components/settings-v2/general/memory/index.tsx:269 存在已有 lint parse error，阻塞全仓门槛，但不在本轮 base-setup automation projection / durable automation draft 变更范围内
- npm test -- "src/lib/sceneapp/product.test.ts" "src/components/sceneapps/SceneAppsPage.test.tsx" "src/lib/api/sceneapp.test.ts"
- 结果：3 files / 13 tests passed
- npm test -- "src/components/AppPageContent.test.tsx" "src/components/agent/chat/workspace/useWorkspaceInitialSessionNavigation.test.tsx"
- 结果：2 files / 12 tests passed
- cargo check --manifest-path "src-tauri/Cargo.toml"
- 结果：通过
- npm run test:contracts
- 结果：通过
- npm run verify:gui-smoke
- 结果：失败；smoke:browser-runtime 持续卡在 launch_browser_session 超时，180000ms 内未收到 DevBridge 响应
- npm run verify:local
- 结果：失败；同样阻塞于 smoke:browser-runtime，非本轮 SceneApp / Agent session 恢复代码直接触发的断言失败
- npm run typecheck
- 结果：通过
- npm test -- src/lib/sceneapp/catalog.test.ts src/lib/api/sceneapp.test.ts src/lib/dev-bridge/mockPriorityCommands.test.ts src/lib/tauri-mock/core.test.ts
- 结果：4 files / 18 tests passed
- cargo check --manifest-path "src-tauri/Cargo.toml"
- 结果：通过
- npm test -- "src/components/sceneapps/SceneAppsPage.test.tsx"
- 结果：1 file / 4 tests passed
- npx eslint "src/components/sceneapps/SceneAppsPage.tsx" "src/components/sceneapps/useSceneAppsPageRuntime.ts" "src/components/sceneapps/SceneAppRunList.tsx" "src/components/sceneapps/SceneAppRunDetailPanel.tsx" "src/lib/sceneapp/presentation.ts" "src/components/sceneapps/SceneAppsPage.test.tsx"
- 结果：通过
- npm run typecheck
- 结果：通过
- npm run verify:gui-smoke
- 结果：未通过；当前环境无法监听 127.0.0.1:1420，报错 listen EPERM: operation not permitted 127.0.0.1:1420
- npm test -- "src/components/sceneapps/SceneAppsPage.test.tsx" "src/components/AppPageContent.test.tsx"
- 结果：2 files / 14 tests passed
- npx eslint "src/components/sceneapps/useSceneAppsPageRuntime.ts" "src/components/sceneapps/SceneAppsPage.test.tsx" "src/components/AppPageContent.test.tsx" "src/types/page.ts"
- 结果：通过
- npm run typecheck
- 结果：通过
- npm run verify:gui-smoke
- 结果：未通过；当前环境无法监听 127.0.0.1:1420，报错 listen EPERM: operation not permitted 127.0.0.1:1420
- npm test -- "src/lib/sceneapp/storage.test.ts" "src/components/sceneapps/SceneAppsPage.test.tsx" "src/components/AppPageContent.test.tsx"
- 结果：3 files / 18 tests passed
- npx eslint "src/lib/sceneapp/navigation.ts" "src/lib/sceneapp/storage.ts" "src/lib/sceneapp/storage.test.ts" "src/components/sceneapps/useSceneAppsPageRuntime.ts" "src/components/sceneapps/SceneAppsRecentPanel.tsx" "src/components/sceneapps/SceneAppsPage.tsx" "src/components/sceneapps/SceneAppsPage.test.tsx" "src/components/AppPageContent.test.tsx" "src/types/page.ts"
- 结果：通过
- npm run typecheck
- 结果：通过
- npm run verify:gui-smoke
- 结果：未通过；当前环境无法监听 127.0.0.1:1420，报错 listen EPERM: operation not permitted 127.0.0.1:1420
- npm test -- src/lib/api/sceneapp.test.ts src/lib/tauri-mock/core.test.ts
- 结果：2 files / 14 tests passed
- npm test -- "src/lib/sceneapp/launch.test.ts" "src/lib/api/sceneapp.test.ts" "src/lib/tauri-mock/core.test.ts"
- 结果：3 files / 17 tests passed
- npm test -- "src/components/agent/chat/workspace/sceneAppLaunch.test.ts" "src/lib/sceneapp/launch.test.ts" "src/lib/api/sceneapp.test.ts"
- 结果：3 files / 13 tests passed
- npm test -- "src/components/agent/chat/workspaceEntry.test.ts" "src/components/agent/chat/workspace/sceneAppLaunch.test.ts"
- 结果：2 files / 14 tests passed
- npx eslint "src/components/agent/chat/workspace/sceneAppLaunch.ts" "src/components/agent/chat/workspace/sceneAppLaunch.test.ts" "src/lib/sceneapp/launch.ts"
- 结果：通过
- npx eslint "src/lib/sceneapp/launch.ts" "src/lib/sceneapp/launch.test.ts" "src/lib/sceneapp/types.ts" "src/lib/api/sceneapp.ts"
- 结果：通过
- npm run test:contracts
- 结果：通过
- npm test -- "src/components/sceneapps/SceneAppsPage.test.tsx" "src/components/AppPageContent.test.tsx" "src/hooks/useAppNavigation.test.tsx" "src/lib/navigation/sidebarNav.test.ts" "src/components/agent/chat/components/EmptyState.test.tsx" "src/components/agent/chat/workspace/useWorkspaceSceneAppEntryActions.test.tsx" "src/components/agent/chat/workspace/sceneAppLaunch.test.ts" "src/lib/sceneapp/launch.test.ts"
- 结果：8 files / 56 tests passed
- npx eslint "src/components/sceneapps/SceneAppsPage.tsx" "src/components/sceneapps/SceneAppsPage.test.tsx" "src/components/sceneapps/SceneAppsCatalogPanel.tsx" "src/components/sceneapps/SceneAppDetailPanel.tsx" "src/components/sceneapps/SceneAppScorecardPanel.tsx" "src/components/sceneapps/SceneAppRunList.tsx" "src/components/sceneapps/useSceneAppsPageRuntime.ts" "src/components/AppPageContent.tsx" "src/components/AppPageContent.test.tsx" "src/components/agent/chat/components/EmptyState.tsx" "src/components/agent/chat/components/EmptyState.test.tsx" "src/components/agent/chat/components/EmptyStateSceneAppsPanel.tsx" "src/components/agent/chat/workspace/useWorkspaceSceneAppEntryActions.ts" "src/components/agent/chat/workspace/useWorkspaceSceneAppEntryActions.test.tsx" "src/components/agent/chat/workspace/sceneAppLaunch.test.ts" "src/components/agent/chat/workspace/WorkspaceConversationScene.tsx" "src/components/agent/chat/workspace/useWorkspaceConversationSceneRuntime.tsx" "src/components/agent/chat/workspace/chatSurfaceProps.ts" "src/components/agent/chat/AgentChatWorkspace.tsx" "src/lib/navigation/sidebarNav.ts" "src/lib/navigation/sidebarNav.test.ts" "src/types/page.ts" "src/lib/sceneapp/presentation.ts" "src/lib/sceneapp/automation.ts" "src/lib/sceneapp/launch.ts" "src/lib/sceneapp/launch.test.ts"
- 结果：通过
- npm run typecheck
- 结果：通过
- npm run verify:gui-smoke
- 结果：失败，当前环境无法监听 127.0.0.1:1420，报错 listen EPERM: operation not permitted 127.0.0.1:1420
- npm run verify:local
- 结果：失败，但失败项仍为仓库已有无关问题，不在本轮 SceneApp execution facade 改动范围：
  - src/components/agent/chat/hooks/agentStreamFlowControl.test.ts
  - src/components/agent/chat/utils/turnSummaryPresentation.ts
  - src/lib/api/serviceSkills.ts
  - src/lib/base-setup/serviceSkillCatalogAdapter.ts
- npm run lint
- 结果：失败，但当前失败项为仓库已有无关问题，不在本轮 SceneApp 改动范围：
  - src/components/agent/chat/hooks/agentStreamFlowControl.test.ts
  - src/components/agent/chat/utils/turnSummaryPresentation.ts
  - src/lib/api/serviceSkills.ts
  - src/lib/base-setup/serviceSkillCatalogAdapter.ts
- npm test -- "src/lib/sceneapp/product.test.ts" "src/components/sceneapps/SceneAppsPage.test.tsx" "src/lib/api/sceneapp.test.ts"
- 结果：3 files / 24 tests passed
- cargo test --manifest-path "src-tauri/Cargo.toml" browser_runtime_ref
- 结果：2 tests passed
- cargo check --manifest-path "src-tauri/Cargo.toml"
- 结果：通过
- npm run typecheck
- 结果：通过
- npx eslint "src/lib/sceneapp/types.ts" "src/lib/sceneapp/product.ts" "src/components/sceneapps/useSceneAppsPageRuntime.ts" "src/lib/sceneapp/product.test.ts" "src/components/sceneapps/SceneAppsPage.test.tsx" "src/lib/api/sceneapp.ts"
- 结果：通过
- npm run verify:gui-smoke
- 结果：失败；smoke:browser-runtime 仍阻塞于 launch_browser_session，报错 读取 CDP 标签页失败: error sending request for url (http://127.0.0.1:14509/json/list)

2026-04-14

已完成

建立 LimeNext 上位总纲专题包：
在 docs/README.md 增加 LimeNext 总纲入口，确保文档中心可发现
完成一轮文档新鲜度校验：
- npm run harness:doc-freshness
- 结果：clean
根据反馈把 LimeNext 定义改成更容易传播的三层版本：
- 给所有人看的白话版
- 给产品团队看的版本
- 给工程团队看的版本
新增本执行计划与进度日志：
- limenext-plan.md
- limenext-progress.md
补齐 SceneApp 能力模型总纲：
- sceneapp-capability-model.md
- 固定五类 SceneApp 分类
- 固定五种 Skill / Scene 编排模式
- 固定九类底层能力模块范围
- 明确 server skill / CLI / browser / cron / db / markdown / json 的适用边界
把 skill 设计模式正式写回基础标准与运行时标准：
- skill-standard.md
- command-runtime.md
- 明确 Skill Bundle 不是产品对象
- 明确新增样板至少要声明 sceneapp_type + pattern_primary / pattern_stack + infra_profile
在 SceneApp 总纲里增加常见组合原型，避免分类只停在抽象概念
新增 SceneApp 样板蓝图：
- sceneapp-blueprints.md
- 用 x-article-export、@配音、每日趋势摘要 / 账号增长跟踪 三条样板补齐业务图、业务时序和经营指标
更新 LimeNext 总纲图示：
- flowcharts.md
- sequences.md
- architecture.md
- 补齐“业务图在前、技术图在后”的双层表达
选定 LimeNext 第一条 Agent + ServiceSkill 样板为 @配音 / voice_runtime / cloud-video-dubbing
重写 docs/prd/gongneng/peiyin/ 六件套，形成完整实施级方案包：
新增 docs/prd/gongneng/x-article-export/ 六件套，形成完整实施级方案包：
修正文档入口与引用，确保 x-article-export 作为 Browser-grounded SceneApp 样板可被发现：
新增 Artifact / Evidence / Scorecard 业务样板文档，并把它回挂到 LimeNext 总纲：
把第三条 Local Durable SceneApp 样板固定到真实仓库锚点：
- daily-trend-briefing
- account-performance-tracking
- useWorkspaceServiceSkillEntryActions.ts
- AutomationJobDialog.tsx
- automation_service/mod.rs
新增通用解耦专题，明确“主 App 宿主内核”与“基础设置包”的边界：
- base-setup-decoupling.md
- 固定“换装配优先不升级主 App，换内核才升级”
- 固定基础设置包不是新 runtime，也不是新产品对象
把 x-article-export 的产品合同从“待澄清”收口为固定口径：
- 先交付 index.md + images/ + meta.json
- 若带 target_language，只在同一路径 Markdown 上继续后处理
- 若未来要支持“纯原文模式”，必须显式分流入口
完成第二轮文档新鲜度校验：
- npm run harness:doc-freshness
- 结果：clean

当前判断

LimeNext 作为上位总纲已经成立
SceneApp 已不再只是一个抽象词，而有了统一能力模型
SceneApp 现在同时有“运行形态 + 编排模式 + 基础设施画像”三轴分类
Skill 设计模式已经不再只是经验说法，而进入了正式工程字段与设计卡
LimeNext 图示已经不再只有技术分层图，开始具备业务、产品、运营可读的总图与时序
LimeNext 现在不只有抽象分类，还有三条业务样板蓝图可以直接拿来对齐讨论
第一条 Agent + ServiceSkill 样板已经不再空缺，当前由 @配音 / voice_runtime 承担
第二条 Agent + ServiceSkill 样板也已不再空缺，当前由 x-article-export 承担
第三条 Local Durable SceneApp 样板也不再只是概念词，当前由 每日趋势摘要 / 账号增长跟踪 承担
Browser-grounded SceneApp 已经不再停留在蓝图层，而有了完整实施级方案包
当前最重要的问题不再是“第二条样板怎么补”，而是“样板如何接到 Artifact + Evidence + Scorecard”
Artifact / Evidence / Scorecard 三层现在已经不再只是抽象词，而有了业务样板和图示
x-article-export 的产品合同也已不再摇摆，当前口径是“资料包优先 + 同一路径后处理”
“尽量不升级主 App 也能使用基础设置” 这条原则也已不再只是口头要求，而被收口成通用分层规则
当前还需要继续明确：
- SceneScorecard 后续具体落到哪些真实聚合对象与看板入口

风险

如果后续继续只写总纲与治理，而不落样板链路，LimeNext 很容易再次变成抽象平台叙事
如果后续只停在 @配音 一条云端样板，LimeNext 仍然会被误解成“只适合云端场景”
如果后续不把 Local Durable 的经营口径接进真实看板，团队还是容易把它误讲成“只是定时任务”
如果后续把“基础设置包”写成某个单场景私有配置，解耦层会再次失效
如果后续重新把 Skill、ServiceSkill、Scene 混成一个词，总纲会迅速失效

下一刀

把 SceneScorecard 聚合对象继续接到生成 / 场景看板 / 周会模板
把三条样板的经营信号进一步映射到真实数据源与产品入口
继续把结果卡文案从“技术摘要”升级成“业务可理解的交付说明”
把基础设置包收口成更明确的 schema 与校验规则

228 KiB Raw Permalink Blame History Unescape Escape

LimeNext 推进日志

2026-04-19

已完成

2026-04-18

已完成

2026-04-17

已完成

2026-04-16

已完成

2026-04-15

已完成

当前判断

风险

下一刀

验证

2026-04-14

已完成

当前判断

风险

下一刀

228 KiB

Raw Permalink Blame History