opensource/proxycast
3
0
Fork 0
mirror of https://github.com/aiclientproxy/proxycast.git synced 2026-09-24 23:10:56 +08:00
Code Issues Packages Projects Releases Wiki Activity
Files
v1.12.3
proxycast/docs/exec-plans/limenext-progress.md
T

88 KiB
Raw Permalink Blame History

LimeNext 推进日志

2026-04-16

已完成

  • 收口 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 生命周期

  • 把 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”

  • 在以下文档中引入统一口径：

  • 把 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 作为上位总纲已经成立
  • 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 与校验规则
Reference in New Issue View Git Blame Copy Permalink