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

release: v1.12.0

Browse Source
This commit is contained in:
coso
2026-04-16 23:32:03 +08:00
parent dfca03a5e5
commit 558e80e5a7
1775 changed files with 64611 additions and 15755 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/README.md
+1
View File
@@ -37,6 +37,7 @@
- `aiprompts/task-agent-taxonomy.md`：Task / Agent / Coordinator current taxonomy 与边界归属
- `aiprompts/remote-runtime.md`：Remote runtime current 主链、current/compat 分类与远程入口归属
- `aiprompts/memory-compaction.md`：Memory / Compaction current 主链、来源链/持久记忆/压缩边界与 current/compat 分类
- `aiprompts/persistence-map.md`：Runtime 文件快照持久化主链、FileArtifact/sidecar/version/checkpoint 边界
- `aiprompts/state-history-telemetry.md`：State / History / Telemetry current 主链、session/thread/request/evidence/history 边界与 current/compat 分类
- `develop/scheduler-task-governance-p1.md`：调度任务治理 P1（连续失败、自动停用、冷却恢复）
- `roadmap/lime-skills-standardization-roadmap.md`：Skills 标准化与产品化路线图
docs/aiprompts/README.md
+2
View File
@@ -20,6 +20,7 @@
- `task-agent-taxonomy.md` - Task / Agent / Coordinator current taxonomy、current/compat 分类与协调边界
- `remote-runtime.md` - Remote runtime current 主链、远程入口 current/compat 分类与控制面归属
- `memory-compaction.md` - Memory / Compaction current 主链、来源链/持久记忆/压缩边界与 current/compat 分类
- `persistence-map.md` - Runtime 文件快照持久化主链、artifact sidecar/version/checkpoint 边界
- `state-history-telemetry.md` - State / History / Telemetry current 主链、session/thread/request/evidence/history 边界与 current/compat 分类
- `governance.md` - 新旧并存治理、迁移收口、禁止回流
- `harness-engine-governance.md` - Harness Engine 事实源、evidence pack、replay / analysis / review 治理规范
@@ -67,6 +68,7 @@
- **改 subagent / automation / execution tracker / scheduler taxonomy**：先读 `task-agent-taxonomy.md`
- **改 channels / browser connector / DevBridge / OpenClaw remote runtime**：先读 `remote-runtime.md`
- **改记忆来源链 / working memory / durable memory / Team Memory / compaction**：先读 `memory-compaction.md`
- **改 FileArtifact / artifact sidecar / versions / file checkpoint / evidence 中的文件快照**：先读 `persistence-map.md`
- **改 session detail / thread read / requestTelemetry / evidence / history-record**：先读 `state-history-telemetry.md`
- **改 Tauri 命令 / Bridge / mock**：先读 `commands.md`，再看 `quality-workflow.md`
- **改 `@` / `/` / 轻卡 / viewer / ServiceSkill 场景**：先读 `command-runtime.md`
docs/aiprompts/commands.md
+16
View File
@@ -97,6 +97,22 @@
- 若服务端下发的 `renderContract` 超出 Lime 当前支持范围，优先由服务端回退到已支持类型，客户端也必须退化到通用 timeline / artifact 展示
- `scene` 的展示命名、推荐文案和补参标题应继续围绕创作生产语义收敛；`@发布合规` 只是发布前风控检查，不应被产品文案扩写成独立“法务场景”，也不要在目录里长出“建立”这类脱离创作目标的泛入口
`SceneApp` 的统一目录与运行前规划命令同样只允许走单一网关。当前前端主入口为 `src/lib/api/sceneapp.ts`，统一承接：
- `sceneapp_list_catalog`
- `sceneapp_get_descriptor`
- `sceneapp_plan_launch`
- `sceneapp_create_automation_job`
- `sceneapp_list_runs`
- `sceneapp_get_run_summary`
- `sceneapp_get_scorecard`
固定约束：
- `SceneApp` 命令当前属于目录查询、运行前规划与治理摘要主链，不应在页面组件里直接裸 `invoke`
- 新的 SceneApp UI 先消费 `SceneAppDescriptor / SceneAppPlanResult / SceneAppScorecard`，不要重新从 `serviceSkills.ts`、`skillCatalog.ts`、卡片配置和 selector 里各自拼语义
- 真正的执行仍应通过 runtime adapter 继续挂回现有 `agent turn / browser_assist / automation_job / cloud_scene` 主链；`sceneapp_*` 不用于重新发明第二套 runtime taxonomy
技能脚手架创建同样只允许走当前命令网关主链：
- 前端统一经由 `src/lib/api/skills.ts -> create_skill_scaffold_for_app`
docs/aiprompts/design-language.md
+21
View File
@@ -106,12 +106,28 @@ Lime 的整体界面应当接近以下气质：
每一层都要有独立职责，不要把标题、筛选、统计、主操作全挤进一行。
复杂工作台默认再加一层判断：
- 如果页面同时承载“目录、详情、治理、自动化、历史运行”等不同任务阶段，不要继续堆在同一屏
- 优先拆成分页、子页或明确的二级导航，而不是靠一长页从上往下堆卡片
- 一个分页只回答一类核心问题：
- 目录页回答“选哪条场景”
- 详情页回答“这条场景如何启动、交付什么、依赖什么”
- 治理页回答“最近运行是否值得继续放量、问题卡在哪里”
- 分页切换后仍要保留“当前场景”摘要，避免用户在子页里失去上下文
- 复杂工作台的默认目标是降低认知切换成本，而不是在一屏里展示更多信息
- 分页级空态不能只写“暂无数据”；必须明确告诉用户下一步该回目录、清空筛选，还是先去详情页完成首轮启动
- 如果分页之间的先后关系明确，优先提供工作流导轨或分步卡，让用户知道自己正处在“选品 / 启动 / 治理”的哪一步
### 3. 卡片型列表页
- 卡片页优先考虑桌面端横向效率
- 列数根据容器宽度自适应
- 卡片之间的间距要比普通表单更大
- 同一行卡片高度尽量对齐
- 如果卡片承担“进入下一层”的职责，必须提供明确导航语义
- 不要只给“选中态边框”却没有后续页面变化，避免用户误以为点击无效
- 可点击卡片应直接进入详情、配置或治理下一层；提示文案要和点击结果一致
## 文字排版
@@ -223,6 +239,11 @@ Lime 的整体界面应当接近以下气质：
- 工作台主操作应与统计信息分栏，而不是挤成一行
- 分组标题应使用“中文主标题 + 英文辅助标签”的组合，而不是反过来
- Team Workspace / 浮层类界面应避免半透明主体和多层套卡，否则会放大遮挡感与层级混乱
- `SceneApp` 这类复杂工作台不应把“场景目录、场景详情、治理复盘”继续堆在同一页里，而应按用户任务路径拆成分页
- 目录卡片如果承担“进入详情”的职责，就应点击后直接切页，不要停留在只有选中态的伪交互
- 分页工作台要在顶部持续展示“当前场景”摘要，让用户在目录、详情、治理之间切换时始终知道自己正在处理哪条场景
- 分页工作台的空态也必须按任务路径设计，直接把用户引回“回目录选场景 / 清空筛选 / 先做首轮运行”这些下一步动作
- 分页工作台如果存在天然顺序，就应用业务向的 step rail 或流程导轨把“先选场景、再补启动、最后看治理”直接说清楚
## 关联文档
docs/aiprompts/memory-compaction.md
+9 -2
View File
@@ -55,14 +55,19 @@
当前这里负责：
1. 解析 managed / user / project / local / rules / durable / additional 记忆来源。
2. 读取与写入自动记忆入口 `MEMORY.md` 及主题 note。
2. 初始化 `memdir` 套件，并读取与写入 `MEMORY.md`、四类 `README.md` 与 topic note。
3. 生成 `.lime/AGENTS.md` / `.lime/AGENTS.local.md` 模板与 `.gitignore` 守卫。
4. 为 runtime prefetch 和 Memory 页面提供统一来源链读模型。
4. 为 `feedback / project` 写入执行结构化约束，并拒绝相对日期项目记忆。
5. `memory_cleanup_memdir` 负责去重索引、裁剪 README 历史段落，并把旧 topic 日志收口为当前有效版本。
6. 为 runtime prefetch 和 Memory 页面提供统一来源链读模型，包括 `source_bucket / provider / memory_type / updated_at` 等 memdir 元数据。
固定规则：
- 来源链解析统一收口到 `resolve_effective_sources(...)`。
- 自动记忆目录定位与入口索引统一收口到 `auto_memory_service.rs`。
- `memdir` 默认以 `MEMORY.md -> user|feedback|project|reference` 四类目录组织；topic 文件必须继续挂在这条索引主链下。
- typed topic note 默认按“同 topic 一条当前记忆”维护，后续写入应覆盖旧内容，而不是无限追加时间戳历史。
- `memory_cleanup_memdir` 只做治理减法：清掉重复链接、缺失链接、过旧 README 历史段落和 topic 日志，不再额外长第二套归档真相。
- 页面、Hook 或 runtime 不允许再各自扫描另一套“真实来源链”。
### 2. 单回合 prefetch、工作记忆与压缩状态
@@ -148,11 +153,13 @@
2. 设置页复用同一套来源链、自动记忆与命中层状态，而不是再长另一份配置解释。
3. 线程可靠性面板与记忆预演卡片继续消费 `memory_runtime_prefetch_for_turn` 的结果。
4. DevBridge dispatcher、mock priority 和默认 mock 只为 current 命令提供桥接与兜底，不构成新的事实源。
5. `MemorySettings` 里的 `整理 memdir` 入口必须继续直连 `memory_cleanup_memdir`，不能在前端本地伪造“已整理”状态。
固定规则：
- 页面层只消费 `memory_runtime_*` / `unified_memory_*` 输出，不自己读磁盘或数据库重组另一套真相。
- 浏览器模式下的 mock priority 只允许模拟 current 命令结果，不能发明额外字段或第二套状态含义。
- memdir prompt source 的 linked item 预取优先级应继续偏向“更具体的 topic note + 最近更新时间”，而不是把 README 索引长期压过真正的当前记忆。
## current / compat / deprecated / dead
docs/aiprompts/persistence-map.md
+110
View File
@@ -0,0 +1,110 @@
# Runtime Persistence Map
本文件定义 Lime 当前与 Claude Code 持久化对齐相关的单一事实源，重点回答：
- 线程里的文件快照到底从哪里来
- `SessionDetail / thread_read / export / replay` 各自应该消费哪层事实
- 哪些路径属于 current，哪些只是 sidecar 或兼容辅助层
## Current 主链
当前文件持久化主链固定为：
`runtime_turn ArtifactSnapshot -> AgentTimeline FileArtifact -> artifact_document_service sidecar versions -> SessionDetail / AgentRuntimeThreadReadModel / agent_runtime_* -> evidence / replay`
含义如下：
1. `RuntimeAgentEvent::ArtifactSnapshot` 是运行时写入文件快照的唯一事件入口
2. 时间线里的 `AgentThreadItemPayload::FileArtifact` 是线程侧唯一事实源
3. `artifact_document_service` 负责把当前文档与 `versions/vNNNN.artifact.json` 历史快照落到工作区 sidecar
4. `AgentRuntimeThreadReadModel.file_checkpoint_summary` 只做轻量摘要，不复制第二套 transcript
5. 深一点的读取统一走：
- `agent_runtime_list_file_checkpoints`
- `agent_runtime_get_file_checkpoint`
- `agent_runtime_diff_file_checkpoint`
6. `runtime_evidence_pack_service` 与 `runtime_replay_case_service` 统一消费同一份 file checkpoint 读模型，不再各自重新解析 artifact 状态
## 事实源分层
### 1. Timeline facts
文件：
- `src-tauri/src/services/agent_timeline_service.rs`
- `src-tauri/crates/core/src/database/dao/agent_timeline.rs`
职责：
- 记录线程里“有哪份文件快照”
- 保留 `path / source / content / metadata`
- 为 `SessionDetail.items` 与 `thread_read` 提供稳定事实
约束：
- 不再为“文件持久化”新增第二套并列事件模型
- 不从 UI 状态反写 timeline 真相
### 2. Sidecar snapshot store
文件：
- `src-tauri/src/services/artifact_document_service.rs`
职责：
- 把当前 artifact 文档落到工作区
- 维护 `artifactVersion*` metadata 与历史 `versions/` 快照
- 提供 `artifactVersionDiff / artifactVersions / artifactDocument / previewText`
约束：
- sidecar 负责详情补充，不单独定义 thread 真相
- 当前 / 历史版本路径都必须继续走工作区相对路径
### 3. Runtime read models
文件：
- `src-tauri/src/services/runtime_file_checkpoint_service.rs`
- `src-tauri/src/commands/aster_agent_cmd/dto.rs`
- `src/lib/api/agentRuntime/threadClient.ts`
职责：
- 把 `FileArtifact + metadata + sidecar snapshot` 收敛成统一读模型
- 在线程面板暴露“最近文件快照”摘要
- 给前端、导出与后续治理提供稳定命令边界
约束：
- `thread_read` 只保留轻摘要
- list / detail / diff 复用同一 service，不在各个导出服务重复解析
## Export / Replay 消费口径
文件：
- `src-tauri/src/services/runtime_evidence_pack_service.rs`
- `src-tauri/src/services/runtime_replay_case_service.rs`
当前约束：
1. `runtime.json` 与 `artifacts.json` 必须带 `fileCheckpoints / fileCheckpointCount`
2. replay `input.json` 必须带 `fileCheckpoints / fileCheckpointCount`
3. `recentArtifacts` 继续保留，用于路径级快速摘要；`fileCheckpoints` 才是正式快照读模型
## 非 current 路径
以下不再视为文件持久化 current 主链：
- 组件本地推导的 artifact 状态
- 额外维护一套 Claude Code 式 transcript 文件真相
- analysis / replay / review 各自单独扫描工作区再猜“最新版本”
如果需要补持久化能力，优先继续扩展：
- `runtime_file_checkpoint_service`
- `AgentRuntimeThreadReadModel.file_checkpoint_summary`
- `agent_runtime_*file_checkpoint*` 命令边界
而不是再开平级旁路。
docs/aiprompts/terminal.md
+2 -6
View File
@@ -2,7 +2,7 @@
## 概述
Lime 仍保留终端底层能力，用于复用运行时、诊断与会话管理；独立前端 `terminal / sysinfo / files / web` 页面已经下线，不再保留 `src/components/terminal/` 页面模块。
Lime 仍保留终端底层能力，用于复用运行时、诊断与会话管理；独立前端 `terminal / sysinfo / files / web` 页面已经下线，旧 `src/components/terminal/` 页面模块与 `src/lib/terminal/` 状态侧链都已删除。
## 目录结构
@@ -14,10 +14,6 @@ src-tauri/src/terminal/
└── commands.rs # 终端命令
src/lib/api/terminal.ts
src/lib/terminal/
├── store/ # 终端状态与输入态
├── stickers/ # 终端贴纸状态
└── vdom/ # VDOM 状态与类型
```
## PTY 管理
@@ -53,7 +49,7 @@ impl PtyManager {
## 前端边界
前端当前只允许通过 `src/lib/api/terminal.ts` 和 `src/lib/terminal/*` 复用终端会话、事件和状态能力，不再新增独立页面壳。
前端当前只允许通过 `src/lib/api/terminal.ts` 复用终端会话与事件能力；旧 `src/lib/terminal/*` 状态、VDOM、贴纸侧链已删除，不再恢复。
## Tauri 命令
docs/exec-plans/claude-code-agent-task-runtime-alignment-plan.md
+1 -1
View File
@@ -79,7 +79,7 @@
### 已完成
- `npx vitest run "src/components/agent/chat/components/Inputbar/index.test.tsx" "src/components/agent/chat/components/MessageList.test.tsx" "src/components/agent/chat/utils/agentTaskRuntime.test.ts"`
- `npx eslint "src/components/agent/chat/components/AgentTaskRuntimeCard.tsx" "src/components/agent/chat/components/Inputbar/index.tsx" "src/components/agent/chat/components/Inputbar/components/InputbarComposerSection.tsx" "src/components/agent/chat/components/MessageList.tsx" "src/components/agent/chat/workspace/useWorkspaceInputbarSceneRuntime.tsx" "src/components/agent/chat/utils/agentTaskRuntime.ts"`
- `npx eslint "src/components/agent/chat/components/Inputbar/index.tsx" "src/components/agent/chat/components/Inputbar/components/InputbarComposerSection.tsx" "src/components/agent/chat/components/MessageList.tsx" "src/components/agent/chat/workspace/useWorkspaceInputbarSceneRuntime.tsx" "src/components/agent/chat/utils/agentTaskRuntime.ts"`
### 进行中
docs/exec-plans/limenext-plan.md
+103 -7
View File
@@ -1,7 +1,7 @@
# LimeNext 总实施计划
> 状态：进行中
> 更新时间：2026-04-15
> 更新时间：2026-04-16
> 上位总纲：`docs/roadmap/limenext/`
> 目标：把 LimeNext 从“上位平台定义”推进到“可持续实施的主线计划”，统一产品对象、运行时骨架、远程入口、长时执行、证据治理与场景选品的推进顺序。
@@ -35,6 +35,59 @@ LimeNext 当前不是缺一篇愿景文档，而是缺一条能持续推进的
9. `base-setup-projection-lifecycle.md` 已把装配包发布、灰度、seeded 兜底与回滚链收口成可讨论的事实源。
10. `base-setup-implementation.md` 已把 validator / compiler / rollout gate 的第一版代码落点收口到现有 `ServiceSkillCatalog` 与 launch/runtime 锚点。
11. `src/lib/base-setup/*` 已新增第一版代码骨架，开始把基础设置包下沉到实际 TypeScript 模块与单测。
12. `src/lib/base-setup/storage.ts`、`bootstrap.ts` 已落地，把基础设置包快照、bootstrap 提取与 compat 编译链收口成独立模块。
13. `src/lib/api/serviceSkills.ts`、`src/lib/serviceSkillCatalogBootstrap.ts` 已正式接入 `Base Setup Package` 主链，远端刷新与 bootstrap 同步都能直接消费装配包并落基础设置快照。
14. 默认云端 seeded 目录已从手写 `ServiceSkillCatalog` 迁到手写 `Base Setup Package` + compat 编译产物，开始把装配层推进为真正的内置事实源。
15. seeded 本地 `local_custom` 项也已迁到手写 `Base Setup Package` + compat 编译产物，`x-article-export` 不再依赖手写 `ServiceSkillItem` 补丁。
16. `SceneApp` 的 `project pack` 合同已经从基础设置编译层正式接到产品读模型、目录详情页和经营评分页：
- 统一暴露 `deliveryProfile / compositionProfile / scorecardProfile`
- 目录页已经能说明最终交付部件、组合步骤和经营关注点
- mock 与 Tauri seeded DTO 已同步对齐，避免只在前端测试里存在结构字段
17. `project pack` 已继续接到真实 `run summary / scorecard` 聚合：
- `artifactCount` 不再是唯一运行结果语义
- 运行详情已经能解释“交齐几项、还缺什么、卡在哪个失败信号”
- `project pack` 经营评分已改成 `complete_pack_rate / review_pass_rate / publish_conversion_rate`
- `observedFailureSignals / topFailureSignal` 已从真实运行样本回流到产品面
18. `project pack` 第二阶段已开始接到 `session / evidence` 主链：
- `SceneApp run summary` 在拿到 `sessionId` 时会优先读取真实 `SessionDetail + FileArtifact`
- runtime verification failure 已开始回挂到 `review_blocked`
- 只有缺少 session evidence 时才回退 `AgentRun.metadata.artifact_paths`
19. `project pack` 已开始补齐结构化结果入口，而不是只在运行详情里展示 viewer 文案：
- `SceneAppRunSummary` 已新增稳定 `deliveryArtifactRefs`
- 结果入口会优先从 runtime evidence 解析真实会话产物，并在缺失 session evidence 时回退 metadata artifact path
- 前端已改为复用现有 Agent 文件预览入口打开主稿 / 结果文件，不新增新的 viewer 协议
20. `project pack` 已把治理入口接到 SceneApp 运行详情，而不再只展示“已接入会话证据”的文字判断：
- `SceneAppRunSummary` 已新增稳定 `governanceArtifactRefs`
- Rust 会按 `sessionId` 组装 `evidence/summary.md` 与 `review/review-decision.*` 的稳定引用
- 前端继续复用现有 Agent 文件预览入口打开证据摘要、人工复核记录与复核 JSON，不新增新的 SceneApp viewer 协议
21. `project pack` 已开始把治理入口从“可打开”推进到“缺失时自动补生成”：
- 新增 `sceneapp_prepare_run_governance_artifact` 当前命令
- SceneApp 页面点击治理入口时会先按制品类型触发 evidence / review 导出，再继续打开对应文件
- 页面仍只消费 `src/lib/api/sceneapp.ts` 网关，不直接耦合 `agent_runtime_export_*` 命令名
22. `project pack` 已继续把治理入口从“单文件打开”推进到“业务动作”：
- 运行详情已新增 `治理动作` 区块，而不只是列出治理文件
- 当前已支持：
- `准备周会复盘包`
- `准备结构化治理包`
- 两类动作都会先经由 `src/lib/api/sceneapp.ts` 批量补齐 evidence / review 制品，再打开对应主治理文件
- SceneApp 页面仍不直接理解底层 runtime export 命令，也不自己拼接治理路径
23. `project pack` 已开始把治理能力从“单次运行详情”推进到“页面级治理看板”：
- `SceneAppsPage` 已新增独立 `治理看板`
- 当前会把 `run + scorecard + evidence / review` 翻译成业务向状态，而不是只展示底层技术字段
- 目录主视图已经能判断这条场景当前更适合：
- 周会复盘
- 任务中心 / 看板消费
- 自动化任务跟进
- 结果编辑 / 发布
- 页面级治理动作继续复用 `src/lib/api/sceneapp.ts` 与既有文件打开链，不新增平行协议
24. `SceneAppsPage` 已开始从“单页堆叠工作台”收口到“分页式信息架构”：
- 当前固定拆成 `场景目录 / 场景详情 / 治理复盘` 三个分页
- `catalog` 只负责选品与筛选，不再同时承载详情和治理解释
- 目录卡片点击后会直接进入对应 `detail` 分页，而不是只停留在选中态
- 顶部继续保留“当前场景”摘要，确保分页切换时不丢业务上下文
- `detail / governance` 已补齐分页级空态与回退动作，不再让用户停在无下一步的空白页
- 顶部已新增业务向工作流导轨，明确表达 `选场景 -> 补启动 -> 看治理` 的跨页顺序
- 这条规则已经同步写回 `docs/aiprompts/design-language.md`，作为后续复杂工作台默认设计约束
尚未完成：
@@ -47,10 +100,12 @@ LimeNext 当前不是缺一篇愿景文档，而是缺一条能持续推进的
7. 把“主 App 宿主内核”与“基础设置包”分层固定下来，减少场景扩张对客户端发版的依赖。
8. 让基础设置包的 schema 继续下沉到 bootstrap / seeded catalog 可消费的目录投影。
9. 把 `composition blueprint` 从文档口径继续收口到可校验、可投影的装配对象。
10. 把 `project pack` 的最小交付合同继续对齐 artifact profile 与 viewer 主链。
11. 把装配包的 validator / projection compiler / rollout gate 真正落成代码或脚本。
12. 决定第一版是“客户端内编译 package”还是“服务端下发预编译 projection，客户端只做 gate + fallback”。
13. 决定 `src/lib/base-setup/*` 何时正式接入 `src/lib/api/serviceSkills.ts`，替换当前手写 catalog 来源。
10. 继续把 `project pack` 的结构化读模型从当前已接通的 `session / evidence + deliveryArtifactRefs` 优先聚合，扩展到更完整的 `artifact validator / request telemetry / evidence summary` 主链。
11. 把 `project pack` 的治理闭环从当前已接通的“页面级治理看板 + 周会复盘包 / 结构化治理包”继续扩展到自动化任务中心、场景选品与更强的 evidence/review 闭环。
12. 把装配包从已接通的 `service_skill_catalog + scene_catalog` 继续扩到 `command_catalog` 投影代码。
13. 决定第一版是“客户端内编译 package”还是“服务端下发预编译 projection，客户端只做 gate + fallback”。
14. 把剩余 seeded 来源继续收口，重点转到 `command` 与 automation 相关入口，不再保留新的手写 `local_custom` 补丁。
15. 把分页式 `SceneAppsPage` 继续补成真正的多页面工作台；当前跨页入口、分页级空态和工作流导轨已补齐，剩余重点转到 GUI smoke 交付证明与更强的子页级信息头部。
## 3. 总目标
@@ -178,7 +233,15 @@ LimeNext 的实施总目标固定为：
- `Local Durable SceneApp` 当前样板已固定为 `每日趋势摘要 / 账号增长跟踪`
- `x-article-export` 的当前产品合同已固定为“资料包优先 + 同一路径后处理”
- `Base Setup` 解耦规则已单独成文，开始固定“什么该下发，什么必须跟宿主升级”
- 下一步不再只是写定义，而是要明确具体聚合对象、入口和周会使用方式
- `project pack` 已不再只是 schema 词汇，而是已经进入 SceneApp 目录和经营评分读模型
- `project pack` 已进一步接到真实 `run summary / scorecard` 聚合对象
- `project pack` 已开始改成 `session / evidence` 优先聚合，而不是只看 tracker metadata
- `project pack` 已开始把真实结果文件入口接到 SceneApp 运行详情，不再只展示 viewer kind 文案
- `project pack` 已开始把证据摘要 / 人工复核记录 / 复核 JSON 接到同一条运行详情治理面
- `project pack` 已开始在治理入口点击时自动补生成 evidence / review 文件，而不是让用户先回到 Agent 手动导出
- `project pack` 已开始把治理面升级成业务动作，当前可直接准备周会复盘包与结构化治理包
- `project pack` 已开始把治理面抬到 SceneApp 页面级看板，而不再只停留在单次运行详情里
- 下一步不再只是补页面，而是要把这套治理看板继续接到任务中心、选品口径和后续自动治理主链
## 5. 默认样板链路
@@ -266,4 +329,37 @@ LimeNext 的实施总目标固定为：
当前下一刀建议固定为：
**把 `composition blueprint` 从文档对象继续收口到基础设置包 schema 与目录投影，再把 `SceneScorecard` 接到真实聚合来源、任务中心 / 场景看板入口与周会节奏；这样 LimeNext 才会从“样板闭环成立”继续推进到“经营面可执行”。**
**把 LimeNext 从“durable automation 已回到装配主链”推进到“gate 定版与组合交付主链收口”。**
当前已经成立的恢复协议：
1. `automation -> automation job`
2. `chat / skill -> agent session`
3. `browser_assist -> browser runtime`
4. `cloud_scene -> structured cloud scene resume`
5. `native_skill -> structured service skill resume`
当前已经补齐的装配收口：
1. 保持 `SceneAppRunSummary` 继续只暴露稳定恢复引用，而不是让 UI 直接理解底层 metadata：
- `sourceRef`
- `sessionId`
- `browserRuntimeRef`
- `cloudSceneRuntimeRef`
- `nativeSkillRuntimeRef`
- `deliveryArtifactRefs`
2. durable 场景的 automation projection / fallback 已继续收回同一装配主链：
- `Base Setup Package` 已支持 `automationProfiles[]`
- `catalogProjection.automationProfileRef` 已进入 validator / parser / projection metadata / snapshot index
- durable seeded 样板已显式声明 automation profile
- `service-skills/automationDraft.ts` 现已优先消费装配层 schedule / delivery / retry / enabled 预设
3. `browser-runtime` GUI smoke 与 `verify:local` 当前已重新通过，GUI 交付门槛不再被此前的 CDP 环境问题卡住
当前下一步转为：
1. 决定客户端编译 vs 服务端预编译 gate 的最终定版位置
2. 把多模态组合样板的 `project pack` 从已接通的真实 artifact + 页面级治理看板继续扩到任务中心与自动治理消费入口
3. 把 `SceneScorecard` 与周会模板、页面级治理看板和任务中心口径继续打通
4. 继续让 automation detail / SceneApp run / scorecard 聚合消费同一组 base-setup refs，而不是回退到运行时猜测
这样 LimeNext 才会从“目录、启动、复盘、恢复、durable 装配都闭环”继续推进到“装配 gate 定版、组合交付与经营聚合也闭环”。
docs/exec-plans/limenext-progress.md
+984 -11
View File
File diff suppressed because it is too large Load Diff
docs/exec-plans/upstream-runtime-alignment-progress.md
+145 -3
View File
@@ -1,15 +1,155 @@
# 参考运行时主链对齐进度日志
## 2026-04-16
### 已完成
- 在 [auto_memory_service.rs](../../src-tauri/src/services/auto_memory_service.rs) 把 `memdir` 从“无限追加日志”收成“有界目录”：
- `feedback / project / user / reference` 的 typed topic note 现在按“同 topic 一条当前记忆”覆盖更新，不再持续追加时间戳段落
- 新增 `cleanup_memdir(...)`，统一负责去重入口链接、裁剪 README 历史段落，并把旧 topic 日志收口为当前有效版本
- `MEMORY.md` 入口的时间戳 note 现在会在写入时自动去重并保留有界窗口，避免入口长期劣化成无上限流水账
- 在 [memory_management_cmd.rs](../../src-tauri/src/commands/memory_management_cmd.rs)、[memory_runtime.rs](../../src-tauri/src/dev_bridge/dispatcher/memory_runtime.rs)、[runner.rs](../../src-tauri/src/app/runner.rs)、[memoryRuntime.ts](../../src/lib/api/memoryRuntime.ts)、[memoryRuntimeTypes.ts](../../src/lib/api/memoryRuntimeTypes.ts)、[core.ts](../../src/lib/tauri-mock/core.ts) 与 [mockPriorityCommands.ts](../../src/lib/dev-bridge/mockPriorityCommands.ts) 补齐 `memory_cleanup_memdir` 这条 current control-plane 命令，不再让 memdir 整理只停留在本地脚本或人工编辑
- 在 [memory_source_resolver_service.rs](../../src-tauri/src/services/memory_source_resolver_service.rs) 调整 memdir linked item 的 prompt 预取优先级：具体 topic note 会优先于类型 `README.md`，同层内优先看最近更新时间，减少索引文件长期压过真正当前记忆的噪音
- 在 [index.tsx](../../src/components/settings-v2/general/memory/index.tsx) 补上真实的 `整理 memdir` 入口，并把“同一 topic 会覆盖旧内容”的行为写回设置页说明；MemorySettings 不再只是能写、能初始化，还能直接治理已有脏记忆
- 补回归：
- [auto_memory_service.rs](../../src-tauri/src/services/auto_memory_service.rs) 新增 typed topic overwrite 与 memdir cleanup 定向测试
- [memory_source_resolver_service.rs](../../src-tauri/src/services/memory_source_resolver_service.rs) 新增“具体 topic 优先于 README”测试
- [memoryRuntime.test.ts](../../src/lib/api/memoryRuntime.test.ts) 与 [index.test.tsx](../../src/components/settings-v2/general/memory/index.test.tsx) 新增 `memory_cleanup_memdir / 整理 memdir` 前端链路回归
- 已执行校验：
- `npx prettier --write "src/lib/api/memoryRuntime.ts" "src/lib/api/memoryRuntimeTypes.ts" "src/lib/api/memoryRuntime.test.ts" "src/lib/tauri-mock/core.ts" "src/lib/dev-bridge/mockPriorityCommands.ts" "src/components/settings-v2/general/memory/index.tsx" "src/components/settings-v2/general/memory/index.test.tsx"` 通过
- `rustfmt --edition 2021 "src-tauri/src/services/auto_memory_service.rs" "src-tauri/src/services/memory_source_resolver_service.rs" "src-tauri/src/commands/memory_management_cmd.rs" "src-tauri/src/dev_bridge/dispatcher/memory_runtime.rs" "src-tauri/src/app/runner.rs"` 通过
- `npm exec vitest run "src/lib/api/memoryRuntime.test.ts" "src/components/settings-v2/general/memory/index.test.tsx" "src/lib/dev-bridge/mockPriorityCommands.test.ts"` 通过（`18 passed`）
- 在 [verify-gui-smoke.mjs](../../scripts/verify-gui-smoke.mjs) 收紧 `waitForBridgeHealth` 的启动判定：不再把 `tauri dev` 父进程退出直接等同为失败，而是继续观察 GUI smoke 进程组是否仍有活跃 `cargo/rustc/tauri` 链路；同时把“编译结束后的 boot grace”放宽到“父进程仍活着或进程组仍活着”两种场景，避免冷启动时因为父进程提前退场而误判 `headless Tauri 在 DevBridge 就绪前提前退出`
- 已重新执行 `npm run verify:gui-smoke -- --timeout-ms 1200000 --cargo-target-dir "/tmp/lime-gui-smoke-target-debug-parent-exit"` 并通过：`workspace-ready`、`browser-runtime`、`site-adapters`、`agent-service-skill-entry`、`agent-runtime-tool-surface`、`agent-runtime-tool-surface-page` 全链路冒烟通过，GUI smoke 主路径重新恢复到 Lime 可交付门槛
- 已再次核对 smoke Chrome profile 清理收口：GUI smoke 收尾后 `find "$HOME/Library/Application Support/lime/chrome_profiles" -maxdepth 1 -type d \( -name 'smoke-browser-runtime*' -o -name 'smoke-agent-runtime-tool-surface-page*' \) | sort` 结果为空；本轮预清理日志显示共回收 `78` 个历史 profile、结束 `264` 个残留进程，收尾阶段再清掉本轮新增的 `5` 个 profile 与 `2` 个残留进程
- 在 [webview_cmd.rs](../../src-tauri/src/commands/webview_cmd.rs)、[runner.rs](../../src-tauri/src/app/runner.rs)、[bridge.rs](../../src-tauri/src/dev_bridge/dispatcher/browser/bridge.rs) 与 [core.ts](../../src/lib/tauri-mock/core.ts) 补上 `cleanup_gui_smoke_chrome_profiles` 这条 DevBridge current 清理命令：它只识别 `smoke-browser-runtime*` 与 `smoke-agent-runtime-tool-surface-page*` 两类 GUI smoke 专用 Chrome profile，统一收口“关闭受管 session / 关闭 runtime session / 杀掉孤儿 Chrome 进程 / 清 singleton 锁 / 删除 profile 目录”，不再把历史遗留清理逻辑散落在脚本层自己拼 `ps/find/rm`
- 在 [verify-gui-smoke.mjs](../../scripts/verify-gui-smoke.mjs) 接上新的清理主链：health URL 现在会自动推导 `invoke` 地址，bridge 就绪后会先做一次历史 `smoke-*` Chrome profile 预清理，所有 smoke 结束后再做一次收尾清理，失败场景也会走兜底清理日志；后续 GUI smoke 不再只解决“本轮别再新增泄漏”，而是开始回收旧 profile 垃圾
- 在 [webview_cmd.rs](../../src-tauri/src/commands/webview_cmd.rs) 补定向回归：新增 `is_gui_smoke_chrome_profile_key_should_only_match_expected_prefixes` 与 `cleanup_gui_smoke_chrome_profiles_should_remove_only_smoke_dirs`，锁定只清 GUI smoke profile、不误删普通浏览器资料的边界
- 已执行校验：
- `node --check "scripts/verify-gui-smoke.mjs"` 通过
- `env CARGO_TARGET_DIR="/tmp/lime-target-gui-smoke-cleanup" cargo test --manifest-path "src-tauri/Cargo.toml" cleanup_gui_smoke_chrome_profiles_should_remove_only_smoke_dirs --lib -- --nocapture` 通过（`1 passed`）
- `npm run test:contracts` 通过
- `npm run verify:gui-smoke -- --timeout-ms 1200000 --cargo-target-dir "/tmp/lime-gui-smoke-target-debug-parent-exit"` 通过
### 当前观察
- `verify:gui-smoke` 这条质量门槛本轮已经恢复为绿色，不再阻塞 `memdir` / memory 主线继续推进
- 本次长冷启动通过时，现场另一个本地 `lime` 进程最终占住了 `127.0.0.1:3030`（当前可见 PID `32676`），因此我这条独立 headless binary 在真正启动后记录了 `Dev Bridge 启动失败: Address already in use (os error 48)`；也就是说，这次通过证明了脚本不会再因为冷启动等待而误判失败，但若后续要证明“本实例独占 3030 也能启动”，仍应在更干净的本地环境或独立端口策略下复验
### 继续推进（file checkpoint UI）
- 在 [AgentThreadFileCheckpointDialog.tsx](../../src/components/agent/chat/components/AgentThreadFileCheckpointDialog.tsx) 新增最小 file checkpoint dialog，直接消费 `agent_runtime_list_file_checkpoints / agent_runtime_get_file_checkpoint / agent_runtime_diff_file_checkpoint` 这条 current 主链；弹窗打开时拉 list，默认选中最近 checkpoint，并在切换条目时并行刷新 detail / diff，不再只停留在可靠性面板上的单条“最近文件快照”摘要
- 在 [AgentThreadReliabilityPanel.tsx](../../src/components/agent/chat/components/AgentThreadReliabilityPanel.tsx) 给“最近文件快照”卡片补上 `查看快照详情` 入口，并把弹窗状态维持在面板当前上下文内：只有存在 `diagnosticRuntimeContext.sessionId` 时才暴露入口，继续沿当前 thread/session 真相消费，不额外长第二套文件持久化读模型
- 在 [AgentThreadReliabilityPanel.test.tsx](../../src/components/agent/chat/components/AgentThreadReliabilityPanel.test.tsx) 补上 file checkpoint 交互回归，覆盖入口出现、打开弹窗后拉 list、默认选中最近 checkpoint 拉 detail/diff，以及切换到旧版本 checkpoint 后重新刷新 detail/diff 与关键字段渲染
- 在 [agent_sessions.rs](../../src-tauri/src/dev_bridge/dispatcher/agent_sessions.rs) 把 `agent_runtime_list_file_checkpoints / agent_runtime_get_file_checkpoint / agent_runtime_diff_file_checkpoint` 接回 browser DevBridge current 分发，不再让真实 GUI 在弹窗打开后掉回 `[DevBridge] 未知命令`
- 在 [dispatcher.rs](../../src-tauri/src/dev_bridge/dispatcher.rs) 补上 `agent_runtime_file_checkpoint_commands_are_bridged` 定向回归，锁定这 3 个命令至少已经进入 `agent_sessions` bridge 分支；即使测试态没有 `AppHandle`，也应报 `Dev Bridge 未持有 AppHandle`，而不是回退成 unknown command
- 为恢复本地真实 GUI 续测，又顺手收掉了当前工作区里会卡死 `tauri:dev:headless` 的一组 Rust 编译半状态：当前确认需要把 [api_key_provider_service.rs](../../src-tauri/crates/services/src/api_key_provider_service.rs) 中 `test_codex_responses_endpoint(...)` 的签名与 3 处调用点对齐到同一套 5 参链路，避免 `provider_type` 在调用侧 / 定义侧来回失配把整条 DevBridge 启动链卡死
- 已用真实 GUI 复测打通 file checkpoint 弹窗主链：本地 `npm run tauri:dev:headless` 已成功启动 `target/debug/lime`，`npm run bridge:health -- --timeout-ms 30000` 返回 `status=ok`；随后在历史会话 `Hello greeting`（`session=6e7f8e4b-129a-4f78-9ad0-41d8a7a801ec`）里进入 `任务中心 -> 切换历史 -> Hello greeting -> 展开工作台 -> 线程可靠性 -> 查看快照详情`，弹窗已真实显示 `共 1 个` checkpoint、默认选中 `v1`、标题 `你好！👋`、状态 `draft`、`live_path / snapshot_path / currentVersionId` 以及完整 `ArtifactDocument` JSON，说明 browser DevBridge 已经从“unknown command”前进到真实 `list / detail / diff` 数据面
- 已执行校验：
- `npx vitest run "src/components/agent/chat/components/AgentThreadReliabilityPanel.test.tsx"` 通过（`15 passed`）
- `npm run test:contracts` 通过
- `npm run typecheck` 通过
- `npm run tauri:dev:headless` 通过增量重编成功启动 `target/debug/lime`
- `npm run bridge:health -- --timeout-ms 30000` 通过（`status=ok`）
- `npm run verify:local` 已尝试执行，但当前仓库存在 `291` 个脏改，smart 模式被放大为全仓 workflow；本轮仅确认其已通过 `verify:app-version / lint / typecheck` 并进入 `vitest-smart` 多批次执行，随后为避免被无关改动长期占用而手动停止
- `npm run verify:gui-smoke` 的这轮旧阻塞已在本节上方收口；当前 file checkpoint 弹窗链路也已补到真实 GUI 证据，不过现场仍可见与本轮主线无关的 browser DevBridge 缺口：`sceneapp_list_catalog`、`gateway_channel_status` 仍报 unknown command；其中历史会话里 `agent_runtime_update_session` 的 `full-access` / `full_access` 枚举别名 warning 已开始在 current DTO/agent runtime 边界收口，尚未单独做一次真实 GUI 复测
### 继续推进（recent_access_mode alias cleanup）
- 在 [session_execution_runtime.rs](../../src-tauri/crates/agent/src/session_execution_runtime.rs) 把 `SessionExecutionRuntimeAccessMode` 的 serde 口径从只认 `snake_case` 收口为 `kebab-case` current 真相，并为历史 `read_only / full_access` 增加兼容 alias；后续 `recent_access_mode` 的序列化结果会稳定回到前端与运行时元数据已经在使用的 `read-only / current / full-access`
- 在 [tests.rs](../../src-tauri/src/commands/aster_agent_cmd/tests.rs) 补上 `agent_runtime_update_session` 的 `recentAccessMode` 反序列化回归，锁定 browser DevBridge / GUI 历史会话当前实际发送的 `full-access` 不会再因为 Rust DTO 只认 `full_access` 而掉 warning
- 已执行校验：
- `rustfmt --edition 2021 "src-tauri/crates/agent/src/session_execution_runtime.rs" "src-tauri/src/commands/aster_agent_cmd/tests.rs"` 通过
- `npx vitest run "src/components/agent/chat/components/AgentThreadReliabilityPanel.test.tsx"` 通过（复跑，`15 passed`）
- `src-tauri/target/debug/deps/lime_lib-f738bc5b97ece89b --exact commands::aster_agent_cmd::tests::test_agent_runtime_update_session_request_deserializes_recent_access_mode_aliases --nocapture` 通过（`1 passed`）
- 已做真实 GUI 续测：`npm run bridge:health -- --timeout-ms 15000` 返回 `status=ok` 后，复用 `http://127.0.0.1:1420/` 现有页签重载首页，再沿 `任务中心 -> 切换历史 -> Hello greeting -> 展开工作台 -> 查看快照详情` 复走 file checkpoint 弹窗链路；控制台只剩既有的 `gateway_channel_status` / `sceneapp_list_catalog` unknown command 与 `i18n` warning，未再出现 `agent_runtime_update_session` 或 `full-access / full_access` 相关 warning
- `SessionExecutionRuntimeAccessMode` 自身的 agent crate 单测已补代码，但本地存在其他长期 `cargo run` 进程占用默认 Cargo cache；尝试绕开锁时会退化成重新下载整套 crates，因此本轮未继续等待 agent crate 独立测试跑完
## 2026-04-15
### 已完成
- 在 [runtime_file_checkpoint_service.rs](../../src-tauri/src/services/runtime_file_checkpoint_service.rs)、[dto.rs](../../src-tauri/src/commands/aster_agent_cmd/dto.rs) 与 [runtime_api.rs](../../src-tauri/src/commands/aster_agent_cmd/command_api/runtime_api.rs) 补上 runtime file checkpoint current 主链：继续以 `SessionDetail.items -> FileArtifact -> artifact_document_service sidecar` 为唯一事实源，新增 `thread_read.file_checkpoint_summary` 轻摘要，以及 `agent_runtime_list_file_checkpoints / agent_runtime_get_file_checkpoint / agent_runtime_diff_file_checkpoint` 三个 current 命令，不再引入第二套 transcript 文件真相
- 在 [runtime_evidence_pack_service.rs](../../src-tauri/src/services/runtime_evidence_pack_service.rs) 与 [runtime_replay_case_service.rs](../../src-tauri/src/services/runtime_replay_case_service.rs) 把 `fileCheckpoints / fileCheckpointCount` 正式接入 evidence / replay sidecar，analysis / review / replay 后续统一复用同一份 checkpoint 读模型，不再各自重新扫描 artifact 状态
- 在 [types.ts](../../src/lib/api/agentRuntime/types.ts)、[threadClient.ts](../../src/lib/api/agentRuntime/threadClient.ts)、[agentRuntimeCommandSchema.json](../../src/lib/governance/agentRuntimeCommandSchema.json)、[agentCommandCatalog.json](../../src/lib/governance/agentCommandCatalog.json)、[mockPriorityCommands.ts](../../src/lib/dev-bridge/mockPriorityCommands.ts) 与 [core.ts](../../src/lib/tauri-mock/core.ts) 同步命令边界五侧，生成清单 [commandManifest.generated.ts](../../src/lib/api/agentRuntime/commandManifest.generated.ts) 也已刷新，新的 file checkpoint 命令继续落在 `agent_runtime_*` current gateway，而不是 compat/legacy 旁路
- 在 [AgentThreadReliabilityPanel.tsx](../../src/components/agent/chat/components/AgentThreadReliabilityPanel.tsx) 新增“最近文件快照”摘要块，并在 [AgentThreadReliabilityPanel.test.tsx](../../src/components/agent/chat/components/AgentThreadReliabilityPanel.test.tsx) 补稳定断言；同时建立持久化 current 文档 [persistence-map.md](../aiprompts/persistence-map.md)，并回挂到 [docs/README.md](../README.md)、[docs/aiprompts/README.md](../aiprompts/README.md) 与 [AGENTS.md](../../AGENTS.md)
- 在 [runtime_evidence_pack_service.rs](../../src-tauri/src/services/runtime_evidence_pack_service.rs) 与 [runtime_replay_case_service.rs](../../src-tauri/src/services/runtime_replay_case_service.rs) 的现有测试里补上 `fileCheckpointCount / fileCheckpoints / checkpoint_id / path` 断言，确保 evidence / replay 已真实消费新的 checkpoint 读模型，而不是只在实现侧悄悄接线
- 已执行校验：
- `node scripts/generate-agent-runtime-clients.mjs` 通过
- `npx vitest run "src/components/agent/chat/components/AgentThreadReliabilityPanel.test.tsx" "src/lib/dev-bridge/mockPriorityCommands.test.ts"` 通过（`17 passed`）
- `npm run test:contracts` 通过
- `npm run typecheck` 通过
- `npx vitest run "src/components/provider-pool/api-key/ProviderConfigForm.ui.test.tsx" "src/components/settings-v2/general/memory/index.test.tsx"` 通过（`19 passed`）
- `env CARGO_TARGET_DIR="/Users/coso/Documents/dev/ai/aiclientproxy/lime/.codex-target" cargo check --manifest-path "src-tauri/Cargo.toml" --lib` 通过
- `env CARGO_TARGET_DIR="/Users/coso/Documents/dev/ai/aiclientproxy/lime/.codex-target" cargo test --manifest-path "src-tauri/Cargo.toml" runtime_file_checkpoint_service::tests:: --lib -- --nocapture` 通过（`3 passed`）
- `env CARGO_TARGET_DIR="/Users/coso/Documents/dev/ai/aiclientproxy/lime/.codex-target" cargo test --manifest-path "src-tauri/Cargo.toml" should_export_runtime_ --lib -- --nocapture` 通过（`6 passed`）
- `npm run verify:gui-smoke` 通过（复用现有 headless 环境，`workspace-ready / browser-runtime / site-adapters / agent-service-skill-entry / agent-runtime-tool-surface / agent-runtime-tool-surface-page` 全部通过）
- `npm run verify:local` 通过
- 当前更高层验证状态：
- 之前记录里的 `should_export_runtime_` / `SceneAppRunSummary` 阻塞已不再复现；当前仓库中的 `sceneapp` 初始化点已补齐新字段，本轮实际阻塞改为 [claude_custom.rs](../../src-tauri/crates/providers/src/providers/claude_custom.rs) 的 `Default` 实现缺口，现已修复并复测通过
- 之前记录里的 `verify:local` TypeScript 阻塞也已修复；[ProviderConfigForm.ui.test.tsx](../../src/components/provider-pool/api-key/ProviderConfigForm.ui.test.tsx) 与 [index.tsx](../../src/components/settings-v2/general/memory/index.tsx) 的类型问题不再复现，本轮已重新从统一入口跑通 `npm run verify:local`
- 在 [auto_memory_service.rs](../../src-tauri/src/services/auto_memory_service.rs) 将自动记忆入口收口为 `memdir` 主链：新增 `user / feedback / project / reference` 四类目录脚手架、最小 provider seam、topic 文件递归索引与 `memory_type / provider / updated_at` 元数据；`feedback / project` 写入现在强制要求 `Why:` 与 `How to apply:` 结构，`project` 同时拒绝 `今天 / tomorrow / next week` 这类相对时间词，避免记忆过期后继续误导执行
- 在 [memory_source_resolver_service.rs](../../src-tauri/src/services/memory_source_resolver_service.rs) 为来源链读模型补齐 `source_bucket / provider / memory_type / updated_at`，并让 `auto_memory_item` 真正进入 runtime 解析与 prompt 来源链；同时把 `memory_type` 约束到 memdir 来源，不再误打到普通项目规则或其它非 memdir 文件
- 在 [memoryRuntimeTypes.ts](../../src/lib/api/memoryRuntimeTypes.ts)、[index.tsx](../../src/components/settings-v2/general/memory/index.tsx) 与 [MemoryPage.tsx](../../src/components/memory/MemoryPage.tsx) 同步前端主链：设置页可以直接初始化 `memdir`、按类型写入真实 note，并在前端先做结构化/绝对日期拦截；Memory 页面与设置页当前都按 `memdir` 分类、provider、最近更新时间展示真实来源，不再沿用旧的外部工具记忆心智文案
- 将这轮 `memdir` 约束与元数据回写到 [memory-compaction.md](../aiprompts/memory-compaction.md)，明确 `MEMORY.md -> user|feedback|project|reference` 是 current 组织方式，topic 文件必须继续挂在同一条索引主链下
- 在 [browser-runtime-smoke.mjs](../../scripts/browser-runtime-smoke.mjs) 与 [agent-runtime-tool-surface-page-smoke.mjs](../../scripts/agent-runtime-tool-surface-page-smoke.mjs) 补上固定 smoke profile key 与 `close_chrome_profile_session` 前后清理，避免每次 GUI smoke 都遗留新的 headless Chrome profile 进程，连带拖慢后续 `browser_execute_action` 页面 smoke
- 已执行校验：
- `npm exec vitest run "src/lib/api/memoryRuntime.test.ts" "src/components/settings-v2/general/memory/index.test.tsx" "src/components/memory/MemoryPage.test.tsx"` 通过（`26 passed`）
- `npm run test:contracts` 通过
- `npm run verify:gui-smoke -- --cargo-target-dir "/tmp/lime-gui-smoke-target-memdir-codex"` 通过（`workspace-ready / browser-runtime / site-adapters / agent-service-skill-entry / agent-runtime-tool-surface / agent-runtime-tool-surface-page` 全部通过）
- 在 [tests.rs](../../src-tauri/src/commands/aster_agent_cmd/tests.rs) 新增基础 Prompt 主链源码守卫，固定 `runtime_turn` 的 current 组装顺序：入口段必须保持 `RuntimeAgents -> ExplicitLocalPathFocus -> FullRuntime/FastChat 分流`，`build_full_runtime_system_prompt(...)` 必须保持 `Memory -> ... -> AutoContinue` 的既定 augmentation 顺序，`ServiceSkillLaunchPreload` 只能在 FullRuntime 下作为尾部追加阶段
- 同步把 `service_skill_launch_preload` 相关重复测试 fixture 收口为共享 helper，减少同一预执行样例在多条测试里重复内联，避免后续调整站点技能预执行 contract 时只改一半测试
- 补最贴边界的定向校验：
- `env CARGO_TARGET_DIR="/Users/coso/Documents/dev/ai/aiclientproxy/lime/.codex-target" cargo test --manifest-path "src-tauri/Cargo.toml" runtime_turn_source_keeps --lib -- --nocapture` 通过（`3 passed`）
- `env CARGO_TARGET_DIR="/Users/coso/Documents/dev/ai/aiclientproxy/lime/.codex-target" cargo test --manifest-path "src-tauri/Cargo.toml" service_skill_launch_preload --lib -- --nocapture` 通过（`3 passed`）
### 继续推进（browser DevBridge sceneapp / channels current 收口）
- 在 [sceneapp.rs](../../src-tauri/src/dev_bridge/dispatcher/sceneapp.rs)、[channels.rs](../../src-tauri/src/dev_bridge/dispatcher/channels.rs) 与 [dispatcher.rs](../../src-tauri/src/dev_bridge/dispatcher.rs) 把 `sceneapp_list_catalog`、`gateway_channel_status`、`wechat_channel_list_accounts` 继续接回 browser DevBridge current 分发；[dispatcher.rs](../../src-tauri/src/dev_bridge/dispatcher.rs) 也新增 `sceneapp_list_catalog_is_bridged`、`gateway_channel_status_is_bridged`、`wechat_channel_list_accounts_is_bridged` 定向守卫，锁定这些命令已进入对应 bridge 分支，不再回退成 `[DevBridge] 未知命令`
- 在 [agentCommandCatalog.json](../../src/lib/governance/agentCommandCatalog.json)、[mockPriorityCommands.ts](../../src/lib/dev-bridge/mockPriorityCommands.ts)、[mockPriorityCommands.test.ts](../../src/lib/dev-bridge/mockPriorityCommands.test.ts) 与 [core.ts](../../src/lib/tauri-mock/core.ts) 同步命令边界四侧：
- `gateway_channel_status` 与 `wechat_channel_list_accounts` 现在都被视为 browser 模式下必须走 bridge 真相的 current runtime gateway 命令
- `wechat_channel_list_accounts` 同步补进默认 mock，避免非 browser 模式的开发回路缺少返回形态
- 在 [wechat_channel_cmd.rs](../../src-tauri/src/commands/wechat_channel_cmd.rs) 抽出纯 helper `list_wechat_configured_accounts(...)`，让 Tauri 命令与 browser DevBridge 共享同一段“列微信账号”逻辑；不再把 `tauri::State` 包装态直接透传进 bridge 分支，避免 bridge 场景里额外引入命令包装态阻塞
- 已执行校验：
- `npm test -- src/lib/dev-bridge/mockPriorityCommands.test.ts` 通过（`3 passed`）
- `npm run test:bridge` 通过（`22 passed`）
- `npm run test:contracts` 通过
- `env CARGO_TARGET_DIR="/tmp/lime-devbridge-current-tests" cargo test --manifest-path "src-tauri/Cargo.toml" sceneapp_list_catalog_is_bridged --lib -- --nocapture` 通过（`1 passed`）
- `env CARGO_TARGET_DIR="/tmp/lime-devbridge-current-tests" cargo test --manifest-path "src-tauri/Cargo.toml" gateway_channel_status_is_bridged --lib -- --nocapture` 通过（`1 passed`）
- `env CARGO_TARGET_DIR="/tmp/lime-devbridge-current-tests" cargo test --manifest-path "src-tauri/Cargo.toml" wechat_channel_list_accounts_is_bridged --lib -- --nocapture` 通过（`1 passed`）
- 已补现场证据：
- 活跃在 `127.0.0.1:3030` 的旧 bridge 一度是 Codex 自己遗留的 [lime](/Users/coso/Documents/dev/ai/aiclientproxy/lime/src-tauri/target/debug/lime) 实例；该旧进程对 `sceneapp_list_catalog`、`gateway_channel_status` 的 `curl /invoke` 已能返回 `200`，但 `wechat_channel_list_accounts` 仍返回 `[DevBridge] 未知命令`，说明真实 GUI 当时看到的是“上一刀已生效、这一刀尚未热更新”的混合现场
- 在清掉这条 Codex 遗留 bridge 后，`127.0.0.1:3030` 一度空闲，随后又被另一条 Codex 派生的 [lime](/Users/coso/Documents/dev/ai/aiclientproxy/lime/src-tauri/target/debug/lime) 实例接管；`/health` 与 `gateway_channel_status` 已恢复 `200`
- 当前活跃 bridge 上，`curl /invoke` 已能真实返回 `wechat_channel_list_accounts` 的账号目录，例如 `774304b339c6@im.bot` 这条已启用账号会返回 `baseUrl=https://ilinkai.weixin.qq.com`、`cdnBaseUrl=https://novac2c.cdn.weixin.qq.com/c2c`、`hasToken=true` 与 `scannerUserId`
- 真实 GUI 续测到的错误类型已经从 `[DevBridge] 未知命令` 前移为 bridge 级超时：在 `消息渠道 -> 高级排障 -> 微信` 页，控制台已出现 `wechat_channel_list_accounts` / `gateway_channel_status` 的调用与 `timeout after 1800ms`，不再是 `unknown command`
- 在 [http-client.ts](../../src/lib/dev-bridge/http-client.ts) 收紧 browser DevBridge HTTP client 的时序策略：
- `sceneapp_list_catalog`、`gateway_channel_status`、`wechat_channel_list_accounts` 等“必须以 bridge 为真相”的命令现在统一使用 `5000ms` 请求超时，不再沿用默认 `1800ms`
- `fetch_provider_models_auto`、`test_api_key_provider_connection`、`test_api_key_provider_chat` 三条 provider 探测命令继续使用 `30000ms` 长超时，避免模型目录探测在浏览器模式下过早被前端判死
- `ensureBridgeReachable()` 对“首个 health probe timeout”不再直接写入 cooldown；只有硬连接失败才进入 `bridge cooldown active`，避免首页第一次慢探测把后续数秒都拖进假性不可用
- 在 [http-client.test.ts](../../src/lib/dev-bridge/http-client.test.ts) 补齐回归护栏：
- 区分“硬连接失败会进入 cooldown”和“timeout 只会触发重试，不会立刻 cooldown”
- 锁定 bridge 真相命令的 `5000ms` 超时窗口与 provider 探测命令的 `30000ms` 超时窗口
- 锁定事件流监听只会在硬连接失败后的短退避窗口里阻止新 `EventSource` 建连
- 本轮追加校验：
- `npm test -- src/lib/dev-bridge/http-client.test.ts` 通过（`10 passed`）
- `npm test -- src/lib/dev-bridge/mockPriorityCommands.test.ts` 通过（`3 passed`）
- `npm run test:bridge` 通过（`22 passed`）
- `npm run test:contracts` 通过
- 本轮追加 live 证据：
- `curl -sS -m 5 "http://127.0.0.1:3030/health"` 返回 `{"service":"DevBridge","status":"ok","version":"1.0.0"}`
- `curl -sS -m 10 -X POST "http://127.0.0.1:3030/invoke" -d '{"cmd":"sceneapp_list_catalog"}'` 返回 scene app catalog
- `curl -sS -m 10 -X POST "http://127.0.0.1:3030/invoke" -d '{"cmd":"gateway_channel_status","args":{"request":{"channel":"wechat"}}}'` 返回 `{"channel":"wechat","status":{"accounts":[],"runningAccounts":0}}`
- `curl -sS -m 10 -X POST "http://127.0.0.1:3030/invoke" -d '{"cmd":"wechat_channel_list_accounts"}'` 返回真实微信账号目录，当前可见 `774304b339c6@im.bot`
### 当前观察
- `sceneapp_list_catalog`、`gateway_channel_status`、`wechat_channel_list_accounts` 三条 current bridge 命令现在都已经具备代码、契约、Rust 定向测试与 live `/invoke` 证据；消息渠道页的真实 blocker 已经从 `unknown command` 前移到 bridge 性能/时序层，而不再是命令缺口
- 由于现场存在多条长期 `tauri dev` / `lime` 进程，本轮继续保留“用隔离 `CARGO_TARGET_DIR` 串行验证 bridge 改动”的做法，避免再次和默认 Cargo target 抢锁；后续若继续做消息渠道页的 GUI 续测，应优先复用当前已经接管 `3030` 的新版 bridge，而不是再让 Codex 遗留实例占住端口
- 本轮尝试继续做 GUI 复测时，`Playwright MCP` 仍直接报 `Target page/context/browser has been closed`，`chrome_devtools` 也出现 page/transport 提前断开；因此当前已经拿到“bridge live 可用 + 前端定向状态机回归通过”的证据，但“消息渠道页控制台里 `1800ms timeout` 是否已显著减少”还需要在更稳定的 MCP 浏览器会话下补一次真实 GUI 复测
## 2026-04-14
### 已完成
@@ -180,17 +320,19 @@
- 在 [inventory.rs](../../src-tauri/src/agent_tools/inventory.rs)、[runtime_api.rs](../../src-tauri/src/commands/aster_agent_cmd/command_api/runtime_api.rs)、[types.ts](../../src/lib/api/agentRuntime/types.ts)、[core.ts](../../src/lib/tauri-mock/core.ts) 与 [HarnessStatusPanel.tsx](../../src/components/agent/chat/components/HarnessStatusPanel.tsx) 已补统一 `runtime_tools` 视图后，本轮继续把前端 usage 从“只在工具库存面板里看四张表”往“主界面直接消费实际 runtime tool surface”推进
- [useWorkspaceHarnessInventoryRuntime.ts](../../src/components/agent/chat/workspace/useWorkspaceHarnessInventoryRuntime.ts) 现在会在主界面启用时预取工具库存，不再等 Harness 面板展开后才第一次拉取
- 新增 [runtimeToolAvailability.ts](../../src/components/agent/chat/utils/runtimeToolAvailability.ts)，把 `runtime_tools` 优先、`registry_tools` 兜底的真实 current surface 收口为 `webSearch / subagent(team) / task` 三组 capability 派生
- [useWorkspaceInputbarSceneRuntime.tsx](../../src/components/agent/chat/workspace/useWorkspaceInputbarSceneRuntime.tsx)、[AgentRuntimeStrip.tsx](../../src/components/agent/chat/components/AgentRuntimeStrip.tsx)、[WorkspaceConversationScene.tsx](../../src/components/agent/chat/workspace/WorkspaceConversationScene.tsx)、[EmptyState.tsx](../../src/components/agent/chat/components/EmptyState.tsx) 与 [EmptyStateComposerPanel.tsx](../../src/components/agent/chat/components/EmptyStateComposerPanel.tsx) 已开始直接消费这份派生结果：Runtime strip 会显示实际 runtime tool surface 规模与 team/task gap，首页主输入区也会在用户开启 `联网搜索 / 任务拆分` 偏好但 runtime current tools 尚未接通时给出明确提示，不再把静态偏好误显示成“真实可用能力”
- [useWorkspaceInputbarSceneRuntime.tsx](../../src/components/agent/chat/workspace/useWorkspaceInputbarSceneRuntime.tsx)、[AgentRuntimeStrip.tsx](../../src/components/agent/chat/components/AgentRuntimeStrip.tsx)、[WorkspaceConversationScene.tsx](../../src/components/agent/chat/workspace/WorkspaceConversationScene.tsx)、[EmptyState.tsx](../../src/components/agent/chat/components/EmptyState.tsx) 与 [EmptyStateComposerPanel.tsx](../../src/components/agent/chat/components/EmptyStateComposerPanel.tsx) 已开始直接消费这份派生结果：Runtime strip 会显示实际 runtime tool surface 规模与 team/task gap，首页主输入区也会在用户开启 `联网搜索 / 任务拆分` 偏好但 runtime current tools 尚未接通时给出明确提示，不再把静态偏好误显示成“真实可用能力”；此前误导性的两条页级黄提示已从主路径移除，只在工作台诊断位保留真实缺口摘要
- 本轮继续补齐测试与 smoke：
- 新增 [runtimeToolAvailability.test.ts](../../src/components/agent/chat/utils/runtimeToolAvailability.test.ts)，覆盖 `runtime_tools` current surface 派生与开发态 override
- 新增 [AgentRuntimeStrip.test.tsx](../../src/components/agent/chat/components/AgentRuntimeStrip.test.tsx) 与 [EmptyState.test.tsx](../../src/components/agent/chat/components/EmptyState.test.tsx) 的 `runtime tool surface` 页级断言，验证 runtime strip 的 team/task gap 与首页空态告警都能真实透传
- 在 [HarnessStatusPanel.tsx](../../src/components/agent/chat/components/HarnessStatusPanel.tsx) 新增 `Runtime 能力摘要`，让工具库存面板也直接消费 `deriveRuntimeToolAvailability(...)`，显式展示 `WebSearch / 子任务核心 tools / Team current tools / Task current tools` 的已接通状态或缺口，不再只显示 raw runtime tool list
- 在 [HarnessStatusPanel.test.tsx](../../src/components/agent/chat/components/HarnessStatusPanel.test.tsx) 新增 `runtime tool surface` 断言，覆盖 team/task gap 暴露与 current surface 完整接通两种情况
- 新增 [agent-runtime-tool-surface-smoke.mjs](../../scripts/agent-runtime-tool-surface-smoke.mjs)，并接入 [verify-gui-smoke.mjs](../../scripts/verify-gui-smoke.mjs) 与 [package.json](../../package.json) 的 `smoke:agent-runtime-tool-surface` current smoke 入口，避免这条主线只停留在局部单测
- 新增 [agent-runtime-tool-surface-page-smoke.mjs](../../scripts/agent-runtime-tool-surface-page-smoke.mjs)，通过真实页面执行 `onboarding -> 最小发送 -> 工作台` 链路，断言 `Runtime 能力摘要` 中的 `WebSearch / 子任务核心 tools / Team current tools / Task current tools` 缺口文案，同时确认旧页级黄提示不再回到页面主路径；脚本固定使用 `stream_mode=events`，避开真实页面在 `cdp_direct + frames/both` 下会把 `Runtime.evaluate` 挤到超时的已知运行时特性
- 本轮已执行校验：
- `npm run smoke:agent-runtime-tool-surface` 通过
- `npm run verify:gui-smoke` 通过（已串联新的 `smoke:agent-runtime-tool-surface`）
- Playwright MCP 真实页面续测通过：首页在开发态 override 下可稳定出现 `runtime tool surface` 告警，且 `toggle-web-search` / `toggle-subagent-mode` 可直接驱动真实空态提示
- `npm run smoke:agent-runtime-tool-surface-page` 通过
- `npm run verify:gui-smoke` 已接入新的 `smoke:agent-runtime-tool-surface-page`
- 真实页面自动 smoke 已验证：开发态 override 下可稳定进入工作台 `Runtime 能力摘要`，并且旧页级黄提示不会重新出现
### 当前判断
docs/test/README.md
+1
View File
@@ -109,6 +109,7 @@ npm run smoke:workspace-ready
npm run smoke:browser-runtime
npm run smoke:site-adapters
npm run smoke:agent-runtime-tool-surface
npm run smoke:agent-runtime-tool-surface-page
```
### 运行 Harness eval 摘要
docs/test/e2e-tests.md
+5 -3
View File
@@ -13,7 +13,8 @@
- `npm run smoke:workspace-ready`：当前自包含 smoke，覆盖 DevBridge 就绪与默认 workspace 基础链路
- `npm run smoke:browser-runtime`：当前自包含 smoke，覆盖 browser runtime 的启动、状态读取、最小动作与审计关联键
- `npm run smoke:site-adapters`：当前自包含 smoke，覆盖站点适配器目录状态、列表、推荐与检索主链
- `npm run smoke:agent-runtime-tool-surface`：当前自包含 smoke，覆盖 runtime inventory 到主界面提示、Runtime strip 与 HarnessStatusPanel 的 team/task current surface 透传
- `npm run smoke:agent-runtime-tool-surface`：当前自包含 smoke，覆盖 runtime inventory 到应用层透传、Runtime strip 与 HarnessStatusPanel 的 team/task current surface 派生
- `npm run smoke:agent-runtime-tool-surface-page`：当前真实页面 smoke，覆盖 onboarding 跳过、最小发送、工作台 `Runtime 能力摘要`，并确认旧页级黄提示不再回到主路径
### supplement
@@ -82,7 +83,7 @@ npm run bridge:health -- --timeout-ms 120000
1. 首页可加载，主导航可见
2. 社媒内容工作流可进入
3. 页面交互后控制台不新增关键 error
4. runtime inventory、Runtime strip、空态提示与 HarnessStatusPanel 对 team/task current tools 的展示保持一致
4. runtime inventory、Runtime strip、工作台 `Runtime 能力摘要` 与应用层透传对 team/task current tools 的展示保持一致，且旧页级黄提示不回流
详细点击路径、控制台检查要求、交接格式，以 `docs/aiprompts/playwright-e2e.md` 为准。
@@ -96,7 +97,8 @@ npm run bridge:health -- --timeout-ms 120000
| Workspace 自包含 smoke | `npm run smoke:workspace-ready` | current | 验证 DevBridge、默认 workspace、路径回查链路 |
| Browser Runtime smoke | `npm run smoke:browser-runtime` | current | 验证 browser runtime 最短主链与审计关联键 |
| Site Adapter smoke | `npm run smoke:site-adapters` | current | 验证站点适配器目录、推荐与检索最短主链 |
| Runtime Tool Surface smoke | `npm run smoke:agent-runtime-tool-surface` | current | 验证 runtime inventory 到 EmptyState / Runtime strip / HarnessStatusPanel 的 current surface 透传 |
| Runtime Tool Surface smoke | `npm run smoke:agent-runtime-tool-surface` | current | 验证 runtime inventory 到应用层透传 / Runtime strip / HarnessStatusPanel 的 current surface 派生 |
| Runtime Tool Surface page smoke | `npm run smoke:agent-runtime-tool-surface-page` | current | 验证真实页面最小发送后工作台 `Runtime 能力摘要` 的缺口诊断，并确认旧页级黄提示已删除 |
| 校验跨层命令契约 | `npm run test:contracts` | current | 检查前端命令、Rust 注册、catalog、mock 集合漂移 |
| 浏览器续测细则 | `docs/aiprompts/playwright-e2e.md` | current | Playwright MCP 唯一详细事实源 |
| 专项 bridge 排障 | `npm run bridge:e2e` | supplement | 适合排障，不是统一门禁 |
docs/test/testing-strategy-2026.md
+1 -1
View File
@@ -40,7 +40,7 @@
- 旧权限表面治理护栏已经补齐：`src/lib/governance/legacyToolPermissionGuard.test.ts` + `npm run governance:legacy-report`
- 跨层命令契约检查基础版已经落地：`npm run test:contracts` 已进入 `scripts/local-ci.mjs`
- 命令契约延期例外已经收口：`agent_terminal_command_response`、`agent_term_scrollback_response` 已退出 `runtimeGatewayCommands`，改为 `dead-candidate` 治理监控
- 自包含 smoke 最小基线已落地：`npm run smoke:workspace-ready`、`npm run smoke:browser-runtime`、`npm run smoke:site-adapters` 都无需人工准备；另外，`npm run smoke:agent-runtime-tool-surface` 已补齐“runtime inventory -> 主界面提示/runtime strip”这条应用层主线 smoke，`npm run verify:gui-smoke` 现已默认串联这四条 current smoke
- 自包含 smoke 最小基线已落地：`npm run smoke:workspace-ready`、`npm run smoke:browser-runtime`、`npm run smoke:site-adapters` 都无需人工准备；另外，`npm run smoke:agent-runtime-tool-surface` 与 `npm run smoke:agent-runtime-tool-surface-page` 已补齐“runtime inventory -> 应用层透传 / Runtime strip / 工作台 Runtime 能力摘要”这条应用层主线 smoke，`npm run verify:gui-smoke` 现已默认串联这组 current smoke
- 测试文档事实源已经收口：`docs/test/README.md`、`docs/test/e2e-tests.md`、`docs/aiprompts/playwright-e2e.md` 已按“索引 / 总览 / 详细事实源”分层
## 3. 当前仍未解决的问题优先级