chore: release v0.97.0

2026-09-24 23:10:56 +08:00 · 2026-03-27 14:35:56 +08:00
parent e380c98649
commit 26e7c60fdd
234 changed files with 36543 additions and 3657 deletions
@@ -5,7 +5,7 @@
 `docs/` 是 Lime 文档中心，分为两类受众：

 - 普通创作者：优先阅读 `content/` 下的入门与用户指南
- 开发者与维护者：阅读 `aiprompts/`、`develop/`、`tests/` 等工程文档
+- 开发者与维护者：阅读 `aiprompts/`、`develop/`、`tech/`、`tests/` 等工程文档

 文档站基于 Nuxt Content 构建。

@@ -13,6 +13,7 @@

 - `content/`：对外文档站正文（产品介绍、用户指南、进阶能力）
 - `aiprompts/`：模块级工程文档（前后端组件、服务、命令、数据层）
+- `tech/`：跨模块技术蓝图与专题工程文档（当前已包含 Harness Engineering 指导文档）
 - `bussniss/`：商务合作与代理运营方案
 - `develop/`：开发流程与协作规范
 - `plugins/`：插件与扩展相关文档
@@ -24,6 +25,8 @@
 - `develop/execution-tracker-deprecation-plan.md`：统一执行追踪旧路径退场计划（P0 收口）
 - `develop/execution-tracker-p0-acceptance-report.md`：统一执行追踪 P0 验收报告
 - `develop/execution-tracker-p1-p2-roadmap.md`：统一执行追踪后续路线（P1/P2）
+- `tech/harness/README.md`：Lime Harness Engineering 总入口
+- `tech/harness/implementation-blueprint.md`：Lime Harness 分阶段实施蓝图
 - `develop/scheduler-task-governance-p1.md`：调度任务治理 P1（连续失败、自动停用、冷却恢复）
 - `roadmap/lime-skills-standardization-roadmap.md`：Skills 标准化与产品化路线图
 - `roadmap/lime-service-skill-cloud-config-prd.md`：服务型技能的端优先执行与云配置同步 PRD
@@ -19,6 +19,7 @@
 - `quality-workflow.md` - 本地校验、GUI smoke、契约检查、CI 门禁
 - `project-heatmap.md` - 仓库热力图与治理候选分析
 - `limecore-collaboration-entry.md` - 跨仓库联动入口
+- `../tech/harness/README.md` - Lime Harness Engineering 总入口与实施蓝图

 ### GUI 与前端

@@ -145,8 +145,9 @@ npm run verify:local

 如果命令边界改动影响会话运行时恢复语义，例如：

- `agent_runtime_update_session` 新增或调整 `provider_name / model_name / execution_strategy`
- 话题切换时的 provider/model 恢复从本地 fallback 向 `execution_runtime` 收敛
+- `agent_runtime_update_session` 新增或调整 `provider_name / model_name / execution_strategy / recent_preferences / recent_team_selection`
+- `getSession/listSessions` 的 `execution_runtime` 新增或调整 `recent_theme / recent_session_mode / recent_gate_key / recent_run_title / recent_content_id`
+- 话题切换时的 provider/model、工具偏好、Team 选择，或 `theme / session_mode / gate_key / run_title / content_id` 恢复从本地 fallback 向 `execution_runtime` 收敛

 除了契约检查，还应补对应 Hook / UI 稳定回归，确认切换话题后模型选择器恢复的是会话 runtime，而不是陈旧本地缓存。

@@ -188,7 +189,15 @@ npm run verify:local
 以下是仓库当前已经明确收敛的几个方向：

 - **Agent / Codex 主命令**：继续收敛到 `agent_runtime_*`
- **会话状态回写主链**：继续收敛到 `agent_runtime_update_session`，用于名称、执行策略以及 session provider/model 的轻量持久化回写
+- **会话状态回写主链**：继续收敛到 `agent_runtime_update_session`，用于名称、执行策略、session provider/model、`recent_preferences` 以及 `recent_team_selection` 的轻量持久化回写
+- **运行时交接导出主链**：继续收敛到 `agent_runtime_export_handoff_bundle`；前端统一通过 `src/lib/api/agentRuntime.ts` 网关进入，当前 GUI 入口位于 `HarnessStatusPanel`
+- **运行时证据导出主链**：继续收敛到 `agent_runtime_export_evidence_pack`，用于把 runtime / timeline / artifacts 打包成最小问题证据
+- **运行时 replay 样本主链**：继续收敛到 `agent_runtime_export_replay_case`，复用 handoff bundle + evidence pack 生成 `input / expected / grader / evidence-links`
+- **运行时外部分析交接主链**：继续收敛到 `agent_runtime_export_analysis_handoff`，复用 handoff bundle + evidence pack + replay case 生成 `analysis-brief.md / analysis-context.json / copy_prompt`，供外部 Claude Code / Codex 直接诊断与最小修复；当前 GUI 入口位于 `HarnessStatusPanel`
+- **运行时人工审核记录主链**：继续收敛到 `agent_runtime_export_review_decision_template`，复用 `analysis handoff` 生成 `review-decision.md / review-decision.json`，把开发者的接受 / 延后 / 拒绝与回归要求回挂到工作区；当前 GUI 入口位于 `HarnessStatusPanel`
+- **会话主题上下文主链**：`getSession` 返回的 `execution_runtime.recent_theme / recent_session_mode` 负责承接最近一次运行态主题上下文；当前端已命中同一 steady-state theme/workbench mode 时，不应继续每回合重复携带 `harness.theme / harness.session_mode`
+- **会话运行阶段上下文主链**：`getSession` 返回的 `execution_runtime.recent_gate_key / recent_run_title` 负责承接最近一次 Theme Workbench 运行阶段上下文；当前端已命中同一 steady-state gate/run 时，不应继续每回合重复携带 `harness.gate_key / harness.run_title`
+- **会话内容上下文主链**：`getSession` 返回的 `execution_runtime.recent_content_id` 负责承接最近一次运行态 `content_id`；当前端已命中同一 steady-state 内容时，不应继续每回合重复携带 `harness.content_id`
 - **运行态摘要主链**：Aster `runtime_status` item -> timeline `turn_summary`
 - **旧 `chat_*` 命令**：已停止注册，不应重新回到 `commands::mod` 或 `generate_handler!`
 - **旧 `general_chat_*` 边界**：前端 compat 网关与 Rust 命令都已移除，不应重新接入
@@ -198,6 +207,14 @@ npm run verify:local

 **不要再造第三套入口，优先继续把能力收敛到已存在的主链。**

+补充约定：
+
+- **站点能力主链**：继续收敛到 `site_list_adapters / site_recommend_adapters / site_search_adapters / site_get_adapter_info / site_run_adapter`
+- **站点 Agent 工具主链**：继续收敛到 `lime_site_list / lime_site_recommend / lime_site_search / lime_site_info / lime_site_run`
+- **站点结果沉淀主线**：`site_run_adapter` / `lime_site_run` 优先透传 `content_id` 写回当前主稿；只有缺少 `content_id` 时，才回退到 `project_id` 新建结果文档
+- **站点运行失败语义**：`SiteAdapterRunResult` 至少统一输出 `auth_required / no_matching_context / adapter_runtime_error`，并在前端与 Agent 结果里保留 `report_hint`
+- **浏览器资料 / 环境预设主链**：`list/save/archive/restore_browser_profile_cmd` 与 `list/save/archive/restore_browser_environment_preset_cmd` 已进入真实 DevBridge 主路径；浏览器模式下不应再默认放进 `mockPriorityCommands`，仅在 DevBridge 不可用时才允许回落 `defaultMocks`
+
 ## 相关检查脚本

 ```bash
@@ -17,6 +17,18 @@

 其余实现必须被明确归类。

+## 路线图任务防跑偏
+
+如果用户明确绑定了某份路线图，尤其是要求“按顺序继续”“对齐目标”“先完成主线”，治理动作必须服从路线图主线，而不是反过来主导路线图。
+
+执行时额外遵守：
+
+1. 先重述当前路线图的 **主目标 / 当前阶段 / 下一刀**
+2. 只有当 dead / compat / deprecated surface **直接阻碍主线收口** 时，才优先做治理减法
+3. 不要把“还能删一点旧代码”误当成“继续推进目标”
+4. 连续两轮主要都在删零引用或补文档时，必须重新打开路线图，改选尚未完成的主链项
+5. 汇报治理结果时，必须补一句“这一步如何服务路线图主线”；如果说不出来，就说明这一步不该先做
+
 ## 分类语言

 治理默认使用这四类：
@@ -129,6 +129,18 @@ npm run test:contracts
 6. 点击 `确认生成`
 7. 验证页面出现 `Theme Workbench` 或相关工作台内容
 8. 再次检查控制台 error
+9. 如能查看运行时摘要，继续确认当前 gate 与任务标题恢复自该话题最近一次 `execution_runtime.recent_gate_key / recent_run_title`
+
+### 浏览器工作台站点采集验证
+
+1. 进入带有 browser assist 的工作区或浏览器运行时面板
+2. 打开 `站点采集工作台` 或对应调试面板
+3. 先确认推荐区已出现，并至少看到一个推荐适配器卡片
+4. 点击一个推荐项，确认适配器、资料提示和标签页提示同步变化
+5. 触发一次执行失败场景时，确认结果区展示业务级错误码与 `report_hint`
+6. 如当前页面带有 `contentId` 上下文，再确认执行成功后默认是“写回当前主稿”，而不是新建资源文档
+7. 如工作台模式开启自动保存，再确认执行成功后保存态文案与打开入口正常
+8. 打开控制台并确认浏览器资料 / 环境预设读取没有落回 web mock，尤其不应出现 `[Mock] invoke: list_browser_profiles_cmd` 或 `[Mock] invoke: list_browser_environment_presets_cmd`

 ### 话题模型恢复验证

@@ -138,6 +150,71 @@ npm run test:contracts
 4. 验证模型选择器恢复的是该话题最近一次 session runtime，而不是陈旧的 localStorage 默认值
 5. 如页面暴露运行时摘要条，再确认 provider/model 文案与选择器一致

+### 话题工具偏好恢复验证
+
+1. 进入同一工作区中的两个话题
+2. 分别切换 `联网 / 深度思考 / 任务模式 / 子代理` 开关组合
+3. 在两个话题之间来回切换，必要时新建一个空白话题再切回
+4. 验证工具开关恢复的是该话题最近一次 session runtime，而不是主题级 localStorage 默认值
+5. 如首次切回旧话题时只能命中 fallback，再继续切换一次，确认第二次开始已优先走 runtime 恢复
+
+### 话题 Team 恢复验证
+
+1. 进入同一工作区中的两个话题
+2. 在话题 A 里选择一个 builtin Team，在话题 B 里选择另一个 builtin 或 custom Team
+3. 在两个话题之间来回切换，必要时新建一个空白话题再切回
+4. 验证 Team 选择器、摘要区和 Team Workbench 展示恢复的是该话题最近一次 `recent_team_selection`，而不是主题级 localStorage 的旧值
+5. 对 custom Team 额外确认：切回后 label / description / roles 没丢；如果本轮是从 fallback 回填，继续切换一次确认第二次开始已优先走 runtime 恢复
+
+### 运行时交接制品验证
+
+1. 进入带有 `HarnessStatusPanel` 的对话工作区，并确保当前话题已经拿到 `sessionId`
+2. 展开 `交接制品` 区块，点击 `导出交接制品`
+3. 验证区块内出现：
+   - 导出时间
+   - 线程状态 / 最新 Turn 状态
+   - Todo 统计
+   - `plan / progress / handoff / review` 文件列表
+4. 继续点击单个制品的 `预览`，确认预览弹窗能打开，并能看到对应绝对路径
+5. 如页面桥接到了真实后端，再点击 `打开目录` 或单文件 `打开`，确认不会落回 mock，且工作区内确实生成 `.lime/harness/sessions/<session_id>/...`
+6. 如果这轮继续开发问题证据包，再把同一条续测链扩展为“先导出 handoff，再导出 evidence pack”，确认两者目录与状态卡不会串线
+7. 如果这轮继续开发 replay 样本导出，再点击 `导出 Replay 样本`，确认：
+   - `input / expected / grader / evidence-links` 文件列表出现
+   - replay 区块能显示 handoff / evidence 的关联根路径
+   - 打开目录后工作区内确实生成 `.lime/harness/sessions/<session_id>/replay`
+8. 如果这轮继续开发外部分析交接，再点击 `导出分析交接` 与 `一键复制给 AI`，确认：
+   - `analysis-brief.md / analysis-context.json` 文件列表出现
+   - 复制内容直接来自后端 `copy_prompt`，不需要前端再手写 prompt
+   - analysis 区块能显示 handoff / evidence / replay 的关联目录
+9. 如果这轮继续开发人工审核记录，再点击 `导出人工审核记录`，确认：
+   - `review-decision.md / review-decision.json` 文件列表出现
+   - 区块能显示默认状态、审核清单与关联 analysis 文件
+   - 打开目录后工作区内确实生成 `.lime/harness/sessions/<session_id>/review`
+
+### 话题内容上下文恢复验证
+
+1. 进入带 `contentId` 的工作台话题并完成至少一次发送
+2. 留在同一话题下再次发送，保持目标主稿不变
+3. 验证本轮仍写回当前主稿，没有误新建资源文档或切到其他内容
+4. 如能查看调试面板或运行时摘要，继续确认恢复依据是当前话题最近一次 `execution_runtime.recent_content_id`，而不是页面一次性参数或陈旧缓存
+5. 再切到另一个 `contentId` 后立即发送一次，确认同步窗口内仍能命中新主稿，而不是被旧 runtime 误覆盖
+
+### 话题主题上下文恢复验证
+
+1. 进入普通对话话题完成一次发送，再切到 `Theme Workbench` 话题完成一次发送
+2. 在两个话题之间来回切换，必要时新建一个空白话题再切回
+3. 验证 UI 恢复的是该话题最近一次主题上下文，而不是页面一次性参数或主题级缓存
+4. 如能查看调试面板或运行时摘要，继续确认依据是当前话题最近一次 `execution_runtime.recent_theme / recent_session_mode`
+5. 再从普通对话切到新的 `theme_workbench` 后立即发送一次，确认同步窗口内仍命中新 theme / session mode，而不是被旧 runtime 误覆盖
+
+### Theme Workbench 运行阶段恢复验证
+
+1. 进入同一个 Theme Workbench 话题，至少完成一次 `write_mode` 或 `publish_confirm` 阶段发送
+2. 留在同一话题下再次发送，保持当前 gate 和任务标题不变
+3. 验证本轮仍衔接当前 gate / 任务标题，而不是掉回旧阶段或空标题
+4. 如能查看调试面板或运行时摘要，继续确认恢复依据是当前话题最近一次 `execution_runtime.recent_gate_key / recent_run_title`
+5. 再切到新的 gate 或新的运行标题后立即发送一次，确认同步窗口内仍命中新 gate / run title，而不是被旧 runtime 误覆盖
+
 ### 服务型技能自动化交付链

 1. 从首页进入服务型技能卡片
@@ -228,6 +305,7 @@ npm run test:contracts

 - 如果该命令属于浏览器模式可接受的降级能力，加入 mock 优先列表
 - 如果该命令属于当前主路径必须能力，补真实 bridge
+- 对浏览器资料 / 环境预设这类已桥接命令，优先排查真实 DevBridge 或默认种子，不要再把它们加回 mock 优先集合

 ## 何时补 mock，何时补真实 bridge

@@ -32,6 +32,19 @@
 4. **用户可见回归已补齐** - 用户可见 UI 改动有稳定断言或既有 snapshot 回归
 5. **文档与锁文件不掉队** - 相关文档、schema、锁文件与实际实现保持一致

+## 路线图任务防跑偏
+
+如果任务明确绑定路线图主线，质量校验除了回答“是否通过”，还必须回答“这次改动是否真的推进了路线图目标”。
+
+执行时额外遵守：
+
+1. 校验前先确认本轮改动对应路线图哪一项
+2. 如果本轮改动只是清理 dead surface、补 README 或局部整理，但没有直接推进主链，不能把“校验通过”当作完成目标
+3. 汇报时必须同时给出：
+   - 本轮改动对应的路线图节点
+   - 本轮校验覆盖了哪条主线风险
+   - 当前距离该路线图阶段完成还差什么
+
 ## 执行硬规则

 ### 1. 不要继续扩展 compat / deprecated 路径
@@ -120,6 +133,8 @@ npm run verify:gui-smoke
 - 启动或复用 `headless Tauri`
 - 等待 `DevBridge` 健康检查通过
 - 验证默认 workspace 的准备态可用
+- 验证 `browser runtime` 的启动、状态读取与审计主链可用
+- 验证 `site adapter catalog` 的状态、列表与推荐主链可读

 它解决的是 GUI 产品特有风险：

@@ -142,13 +157,17 @@ npm run bridge:health -- --timeout-ms 120000
 作用：

 - 检查前端命令调用与 Rust 注册表是否一致
+- 检查 harness metadata / execution runtime / 后端 request metadata 的关键字段是否漂移
 - 检查浏览器桥接 / mock 优先路径是否同步
 - 检查 `DevBridge` 是否可用

 高频场景：

 - 修改 `safeInvoke` / `invoke`
- 修改 `agent_runtime_update_session` 或会话 provider/model 恢复语义
+- 修改 `agent_runtime_update_session` 或会话 provider/model / recent_preferences / recent_team_selection 恢复语义
+- 修改 `execution_runtime.recent_theme / recent_session_mode / recent_gate_key / recent_run_title / recent_content_id` 恢复语义，或前端 `harness.theme / harness.session_mode / harness.gate_key / harness.run_title / harness.content_id` steady-state 去重逻辑
+- 修改 `site_*` 站点适配器命令族，例如 `site_recommend_adapters`、`site_run_adapter`
+- 修改浏览器资料 / 环境预设命令族，或调整它们在 `mockPriorityCommands` 里的优先级
 - 修改 `src/lib/dev-bridge/`
 - 修改 `src/lib/tauri-mock/`
 - 修改 `src-tauri/src/app/runner.rs`
@@ -172,19 +191,35 @@ npm run bridge:health -- --timeout-ms 120000

 ## 改动类型与最低门槛

-| 改动类型                            | 至少运行                                           | 额外要求                                    |
-| ----------------------------------- | -------------------------------------------------- | ------------------------------------------- |
-| 普通前端改动                        | `npm run verify:local`                             | 如有用户可见变化，补稳定回归                |
-| Tauri 命令 / Bridge / mock 改动     | `npm run verify:local`、`npm run test:contracts`   | 必要时补 `npm run governance:legacy-report` |
-| GUI 壳 / Workspace / 页面主路径改动 | `npm run verify:local`、`npm run verify:gui-smoke` | 必须补对应 UI 回归                          |
-| 配置结构改动                        | `npm run verify:local`                             | 同步 schema、消费者、文档                   |
-| 版本相关改动                        | `npm run verify:app-version`                       | 与发布配置一起核对                          |
-| Rust 模块改动                       | 受影响 crate / 模块定向测试                        | 再决定是否跑全量 `cargo test`               |
-| 真实页面交互验证                    | 先跑 `npm run verify:gui-smoke`                    | 再进入 `playwright-e2e.md`                  |
+| 改动类型                            | 至少运行                                               | 额外要求                                    |
+| ----------------------------------- | ------------------------------------------------------ | ------------------------------------------- |
+| 普通前端改动                        | `npm run verify:local`                                 | 如有用户可见变化，补稳定回归                |
+| Tauri 命令 / Bridge / mock 改动     | `npm run verify:local`、`npm run test:contracts`       | 必要时补 `npm run governance:legacy-report` |
+| GUI 壳 / Workspace / 页面主路径改动 | `npm run verify:local`、`npm run verify:gui-smoke`     | 必须补对应 UI 回归                          |
+| 运行时 handoff / 证据包导出改动     | `npm run test:contracts`、相关 `vitest`、Rust 定向测试 | 如入口落在工作台 UI，再补最小 GUI 续测      |
+| 配置结构改动                        | `npm run verify:local`                                 | 同步 schema、消费者、文档                   |
+| 版本相关改动                        | `npm run verify:app-version`                           | 与发布配置一起核对                          |
+| Rust 模块改动                       | 受影响 crate / 模块定向测试                            | 再决定是否跑全量 `cargo test`               |
+| 真实页面交互验证                    | 先跑 `npm run verify:gui-smoke`                        | 再进入 `playwright-e2e.md`                  |

 补充说明：

 - 如果这次改动把 `ServiceSkill -> automation_job -> agent_turn` 接到 Artifact 主线，除了常规 `verify:local` / `test:contracts` 之外，还应至少补一条稳定回归，证明 `content_id + request_metadata.artifact` 没在表单编辑或执行链路里丢失。
+- 如果这次改动把 `content_id` steady-state 从“每回合显式提交”后移到 `session/runtime`，除了契约检查之外，还应补 Hook/UI 回归，证明：
+  - session 已有 `execution_runtime.recent_content_id` 时，前端不会重复提交相同 `harness.content_id`
+  - 切换到新 content 但 runtime 尚未同步时，前端仍会保留显式 `content_id`
+- 如果这次改动把 `theme / session_mode` steady-state 从“每回合显式提交”后移到 `session/runtime`，除了契约检查之外，还应补 Hook/UI 回归，证明：
+  - session 已有 `execution_runtime.recent_theme / recent_session_mode` 时，前端不会重复提交相同 `harness.theme / harness.session_mode`
+  - 切换到新 theme 或 `theme_workbench` 但 runtime 尚未同步时，前端仍会保留显式 `theme / session_mode`
+- 如果这次改动把 `gate_key / run_title` steady-state 从“每回合显式提交”后移到 `session/runtime`，除了契约检查之外，还应补 Hook/UI 回归，证明：
+  - session 已有 `execution_runtime.recent_gate_key / recent_run_title` 时，前端不会重复提交相同 `harness.gate_key / harness.run_title`
+  - 切换到新的 Theme Workbench gate 或运行标题、但 runtime 尚未同步时，前端仍会保留显式 `gate_key / run_title`
+- 如果这次改动影响浏览器工作台里的站点采集链路，例如推荐区、资料自动选择、`report_hint` 展示、`lime_site_recommend`，或“优先写回当前 `content_id` 而不是新建资源文档”的主线收敛，除了契约检查，还应补对应 `*.test.tsx` 回归并执行 `verify:gui-smoke`。
+- 如果这次改动影响浏览器资料 / 环境预设的真实来源，还应补一次浏览器模式实测，确认控制台不再出现 `[Mock] invoke: list_browser_profiles_cmd` 或 `[Mock] invoke: list_browser_environment_presets_cmd`。
+- 如果这次改动影响 `agent_runtime_export_handoff_bundle`、`agent_runtime_export_evidence_pack`、`agent_runtime_export_analysis_handoff`、`agent_runtime_export_review_decision_template` 或 `agent_runtime_export_replay_case` 这条 Harness 导出主链，除了契约检查，还应至少补：
+  - `src/lib/api/agent.test.ts` 一类的网关回归，确认仍走统一 `agent_runtime_*` 主命令
+  - `HarnessStatusPanel.test.tsx` 一类的 UI 回归，确认导出入口、状态与制品展示正常
+  - 受影响 Rust 服务 / 命令的定向测试，确认 `.lime/harness/sessions/<session_id>/...` 一类制品仍能生成

 ## CI 事实源

@@ -223,6 +258,9 @@ npm run verify:local:full

 # GUI 最小冒烟
 npm run verify:gui-smoke
+npm run smoke:workspace-ready
+npm run smoke:browser-runtime
+npm run smoke:site-adapters

 # 前端 / 桥接 / 契约
 npm test
@@ -15,6 +15,10 @@

 我们现在更需要的，不是继续堆更多脚本，而是把已有能力收敛成一条清晰、分层、可执行的开发与交付路径。

+如果要把这些工程方法进一步落实到 Lime 的 Agent / Harness 改造，请继续阅读：
+
+- `docs/tech/harness/README.md`
+
 Codex 值得借鉴的，不是 Bazel、不是纯 Rust、也不是它的体量；
 真正值得借鉴的是：

@@ -48,6 +48,7 @@ docs/test/
 ├── integration-tests.md        # 集成测试指南
 ├── e2e-tests.md               # 浏览器续测与 E2E 总览
 ├── agent-evaluation.md        # Agent 评估指南（核心文档）
+├── harness-evals.md           # Harness eval 任务集与 runner 入口
 └── test-cases/                # 测试用例模板
    ├── converter-tests.md     # 协议转换器测试用例
    ├── provider-tests.md      # Provider 测试用例
@@ -56,17 +57,18 @@ docs/test/

 ## 文档索引

-| 文档                                                             | 说明                       | 适用场景                              |
-| ---------------------------------------------------------------- | -------------------------- | ------------------------------------- |
-| [testing-strategy-2026.md](testing-strategy-2026.md)             | 当前 Lime 测试体系建设建议 | 建立分层门禁、规划演进                |
-| [unit-tests.md](unit-tests.md)                                   | 单元测试指南               | 独立模块测试                          |
-| [integration-tests.md](integration-tests.md)                     | 集成测试指南               | 模块间协作测试                        |
-| [e2e-tests.md](e2e-tests.md)                                     | 当前浏览器续测与 E2E 入口  | Playwright MCP / DevBridge 主路径验证 |
-| [../aiprompts/playwright-e2e.md](../aiprompts/playwright-e2e.md) | 浏览器续测详细事实源       | 继续测试、复现、控制台与 Bridge 排障  |
-| [agent-evaluation.md](agent-evaluation.md)                       | Agent 评估指南             | AI Agent 行为评估                     |
-| [test-cases/converter-tests.md](test-cases/converter-tests.md)   | 转换器测试用例             | OpenAI ↔ Claude 转换                  |
-| [test-cases/provider-tests.md](test-cases/provider-tests.md)     | Provider 测试用例          | OAuth 和 API 调用                     |
-| [test-cases/agent-tests.md](test-cases/agent-tests.md)           | Agent 测试用例             | Aster Agent 集成                      |
+| 文档                                                             | 说明                         | 适用场景                              |
+| ---------------------------------------------------------------- | ---------------------------- | ------------------------------------- |
+| [testing-strategy-2026.md](testing-strategy-2026.md)             | 当前 Lime 测试体系建设建议   | 建立分层门禁、规划演进                |
+| [unit-tests.md](unit-tests.md)                                   | 单元测试指南                 | 独立模块测试                          |
+| [integration-tests.md](integration-tests.md)                     | 集成测试指南                 | 模块间协作测试                        |
+| [e2e-tests.md](e2e-tests.md)                                     | 当前浏览器续测与 E2E 入口    | Playwright MCP / DevBridge 主路径验证 |
+| [../aiprompts/playwright-e2e.md](../aiprompts/playwright-e2e.md) | 浏览器续测详细事实源         | 继续测试、复现、控制台与 Bridge 排障  |
+| [agent-evaluation.md](agent-evaluation.md)                       | Agent 评估指南               | AI Agent 行为评估                     |
+| [harness-evals.md](harness-evals.md)                             | Harness eval 任务集与 runner | Replay 样本、grader、nightly 摘要     |
+| [test-cases/converter-tests.md](test-cases/converter-tests.md)   | 转换器测试用例               | OpenAI ↔ Claude 转换                  |
+| [test-cases/provider-tests.md](test-cases/provider-tests.md)     | Provider 测试用例            | OAuth 和 API 调用                     |
+| [test-cases/agent-tests.md](test-cases/agent-tests.md)           | Agent 测试用例               | Aster Agent 集成                      |

 ## 快速开始

@@ -106,6 +108,24 @@ npm run bridge:health -- --timeout-ms 120000
 npm run smoke:workspace-ready
 ```

+### 运行 Harness eval 摘要
+
+```bash
+npm run harness:eval
+```
+
+### 提升工作区 Replay 为仓库样本
+
+```bash
+npm run harness:eval:promote -- --session-id "session-123" --slug "pending-request-runtime"
+```
+
+### 运行 Harness eval 趋势报告
+
+```bash
+npm run harness:eval:trend
+```
+
 ### 当前浏览器续测入口

 当前仓库的浏览器模式 E2E / 续测文档分两层：
@@ -0,0 +1,89 @@
+{
+  "manifestVersion": "v1",
+  "title": "Lime Harness Eval Manifest",
+  "defaults": {
+    "requiredArtifacts": [
+      "input.json",
+      "expected.json",
+      "grader.md",
+      "evidence-links.json"
+    ],
+    "requiredInputFields": [
+      "session.sessionId",
+      "session.threadId",
+      "task.goalSummary",
+      "classification.suiteTags",
+      "classification.failureModes",
+      "linkedArtifacts.handoffBundle.relativeRoot",
+      "linkedArtifacts.evidencePack.relativeRoot"
+    ],
+    "requiredExpectedFields": [
+      "successCriteria",
+      "blockingChecks",
+      "artifactChecks",
+      "graderSuggestion.preferredMode"
+    ],
+    "requiredEvidenceFields": [
+      "handoffBundle.relativeRoot",
+      "evidencePack.relativeRoot"
+    ]
+  },
+  "suites": [
+    {
+      "id": "repo-fixtures",
+      "title": "仓库固定 Replay 样本",
+      "priority": "P0",
+      "roadmap": "P3-2 Eval runner",
+      "description": "固定一条可在 CI 和 nightly 中稳定运行的 replay fixture，先验证 grader 合同与样本结构，而不是等真实工作区样本才能开始。",
+      "upstream": {
+        "codex": "沿用 Codex evidence-first 的 replay / grader 形状。",
+        "aster": "沿用 Aster runtime / thread / turn 的会话事实边界。",
+        "lime": "把样本、脚本和摘要统一落在 Lime 仓库 current 主线。"
+      },
+      "cases": [
+        {
+          "id": "fixture-minimal-pending-request",
+          "title": "最小 pending request Replay 样本",
+          "source": "repo_fixture",
+          "caseDir": "docs/test/harness-fixtures/replay/minimal-pending-request",
+          "tags": ["conversation-runtime", "replay", "handoff", "evidence"]
+        }
+      ]
+    },
+    {
+      "id": "repo-promoted-replays",
+      "title": "仓库沉淀 Replay 样本",
+      "priority": "P1",
+      "roadmap": "P3-6 Replay 样本沉淀",
+      "description": "把工作区导出的高价值 replay case 提升为仓库 current 样本，用于固定回归入口与 nightly 趋势对比。",
+      "upstream": {
+        "codex": "沿用 Codex 把真实失败沉淀为 replay 资产的做法。",
+        "aster": "继续复用 Aster runtime 导出的 thread / turn / evidence 边界。",
+        "lime": "由 Lime 持有 promotion 命令、repo fixture 目录与 current manifest。"
+      },
+      "cases": []
+    },
+    {
+      "id": "workspace-replay-discovery",
+      "title": "工作区 Replay 自动发现",
+      "priority": "P1",
+      "roadmap": "P3-2 Eval runner",
+      "description": "扫描当前工作区 `.lime/harness/sessions/*/replay`，把真实会话导出的 replay case 接进固定摘要格式。",
+      "upstream": {
+        "codex": "参考 Codex 把真实失败沉淀为 replay / eval 样本的习惯。",
+        "aster": "复用 Aster session runtime 导出的 thread / turn 上下文。",
+        "lime": "让 Lime 的 handoff bundle 与 evidence pack 成为 eval 的事实源。"
+      },
+      "cases": [
+        {
+          "id": "workspace-session-replays",
+          "title": "工作区会话 Replay 样本",
+          "source": "workspace_replay_discovery",
+          "root": ".lime/harness/sessions",
+          "allowZeroMatches": true,
+          "tags": ["workspace", "replay", "runtime-export"]
+        }
+      ]
+    }
+  ]
+}
@@ -0,0 +1,230 @@
+# Lime Harness Evals
+
+> 面向 Lime `P3-6 Replay 样本沉淀` 的 current 事实源  
+> 目标：把 replay 样本、grader 合同、仓库固定任务集与 nightly 摘要，收口到一条可执行主链。
+
+## 先给结论
+
+Lime 当前不直接把“真实模型重放平台”一次做完，而是先固定四件事：
+
+1. **固定任务集入口**  
+   由 [harness-evals.manifest.json](harness-evals.manifest.json) 持有机可读任务清单。
+
+2. **固定样本形状**  
+   所有 replay case 统一要求最小四件套：
+   - `input.json`
+   - `expected.json`
+   - `grader.md`
+   - `evidence-links.json`
+     其中 `input.json` 继续承载 `classification.suiteTags` 与 `classification.failureModes`。
+
+3. **固定摘要出口**  
+   由 `scripts/harness-eval-runner.mjs` 统一产出 JSON / Markdown 摘要，后续 nightly 与趋势报表都从这里接。
+
+4. **固定趋势入口**  
+   由 `scripts/harness-eval-trend-report.mjs` 把一个或多个 summary JSON 聚合成 trend 报告。
+
+这一步对应 Harness 路线图里的 `P3-2 Eval runner`，不是终点，但它把“评估理念”升级成了仓库内可执行入口。
+
+## 为什么这一步要先做
+
+如果没有固定 manifest 和 runner，Lime 当前的 replay 样本会停留在“可以导出”，却还不能稳定回答：
+
+- 当前有哪些回放样本可以复用
+- 哪些样本结构不完整
+- grader 需要哪些输入字段
+- nightly 应该上传什么摘要
+
+先把这层收口，后面的真实模型评估、trend 报表、熵管理和清理才有统一入口。
+
+## 三层来源挂载
+
+| 层次         | 作用                                                                  | 当前落点                                                        |
+| ------------ | --------------------------------------------------------------------- | --------------------------------------------------------------- |
+| `codex-rs`   | 提供 replay / grader / evidence-first 的形状参照                      | manifest 中的 replay case 四件套与评分原则                      |
+| `aster-rust` | 提供 thread / turn / runtime / telemetry 的事实边界                   | `input.json` 中的 session / thread / turn / runtimeContext 结构 |
+| `lime`       | 持有产品层 handoff bundle、evidence pack、workspace `.lime/` 样本目录 | runner、fixture、nightly 摘要与工作区发现逻辑                   |
+
+一句话：
+
+**Codex 决定评估形状，Aster 决定运行时事实边界，Lime 负责把 replay case、grader 和 nightly 摘要落到 current 主链。**
+
+## 当前任务集
+
+当前 manifest 默认分三条 suite：
+
+1. **仓库固定 Replay 样本**
+   - 用于 CI / nightly 的稳定入口
+   - 当前固定一条 fixture：
+     - `fixture-minimal-pending-request`
+   - 目的不是替代真实会话，而是先验证 grader 合同、字段预算和摘要出口不会漂移
+
+2. **仓库沉淀 Replay 样本**
+   - 用于把高价值真实失败从工作区提升为仓库 current 资产
+   - 默认进入 `repo-promoted-replays` suite
+   - 由 `scripts/harness-replay-promote.mjs` 负责：
+     - 复制最小四件套
+     - 把绝对工作区路径脱敏为稳定占位路径
+     - 回写 manifest case
+   - 目的不是把所有会话都进仓，而是把“值得长期回归”的失败收进固定任务集
+
+3. **工作区 Replay 自动发现**
+   - 扫描 `.lime/harness/sessions/*/replay`
+   - 自动把真实导出的 replay case 纳入统一摘要
+   - 默认允许零样本，避免没有本地会话时误报失败
+
+这是一种“固定入口、允许样本增长”的设计：
+
+- 入口是固定的
+- 样本既可以来自仓库 fixture，也可以来自已沉淀的 current case，还可以来自真实工作区导出
+- 不需要为每个新 session 再发明一套单独脚本
+
+## Runner 做什么
+
+`scripts/harness-eval-runner.mjs` 当前负责四件事：
+
+1. 读取 manifest
+2. 解析固定 fixture 与工作区自动发现 case
+3. 校验 replay case 最小四件套与关键 JSON 字段
+4. 输出统一 JSON / Markdown 摘要，并聚合 `suite tag / failure mode` 分布
+
+当前它**不直接执行真实模型重放**，而是先把“样本是否可评估、摘要是否可归档”工程化。
+
+这符合 Lime 当前阶段的约束：
+
+- 先复用现有 `handoff bundle + evidence pack + replay export`
+- 不引入第二套总控平台
+- 先把仓库 fixture、repo current 样本和工作区 replay case 变成稳定资产
+
+## 如何把真实 Replay 提升为 current 样本
+
+当某个工作区 replay case 已经足够稳定、足够重要，应该把它从“工作区临时样本”提升到“仓库固定样本”。当前主入口：
+
+```bash
+npm run harness:eval:promote -- \
+  --session-id "session-123" \
+  --slug "pending-request-runtime" \
+  --title "Pending request 会话不会被误判为完成"
+```
+
+也可以直接指定 replay 目录：
+
+```bash
+node scripts/harness-replay-promote.mjs \
+  --replay-dir ".lime/harness/sessions/session-123/replay" \
+  --slug "pending-request-runtime"
+```
+
+这个命令会做四件事：
+
+1. 读取 replay 最小四件套。
+2. 把工作区绝对路径脱敏成稳定占位路径，避免把本机路径直接写进仓库。
+3. 把样本复制到 `docs/test/harness-fixtures/replay/<slug>/`。
+4. 把 case 回写到 `repo-promoted-replays` suite，成为 nightly 与 trend 的 current 样本。
+
+默认原则：
+
+- 不是每个 replay 都要 promotion，只提升高价值、可重复、能代表失败模式的样本。
+- promotion 之后，样本不再只是“本机能看到”，而是仓库 current 主线的一部分。
+- 仓库沉淀样本仍然复用原来的 handoff / evidence 形状，不另造 schema。
+
+## Trend Report 做什么
+
+`scripts/harness-eval-trend-report.mjs` 当前负责三件事：
+
+1. 读取一个或多个 `harness eval summary` JSON
+2. 生成 baseline / latest 对比、suite 级 delta，以及 `suite tag / failure mode` 聚合变化
+3. 输出 JSON / Markdown 趋势报告
+
+如果没有显式提供输入，它会先调用 `harness-eval-runner` 生成当前 summary，再把它当作第一条 trend seed。
+
+这一步的目的不是假装已经有完整历史，而是先把：
+
+- trend 报告字段
+- nightly 报告出口
+- baseline / latest / suite delta 的最小合同
+
+固定下来。
+
+当前 nightly 还会恢复并追加 `artifacts/history/*.json` 历史窗口，用于让 trend 不只停留在单次 seed。
+
+## 常用命令
+
+```bash
+# 人类可读摘要
+npm run harness:eval
+
+# JSON 输出，适合脚本和 CI 消费
+npm run harness:eval:json
+
+# 把工作区 replay 提升为仓库 current 样本
+npm run harness:eval:promote -- --session-id "session-123" --slug "pending-request-runtime"
+
+# 生成当前趋势报告；若没有历史输入，会先生成当前 summary 作为 trend seed
+npm run harness:eval:trend
+
+# 指定工作区根目录扫描真实 replay 样本
+node scripts/harness-eval-runner.mjs --workspace-root "/path/to/workspace"
+
+# 生成 nightly 可上传的双格式摘要
+node scripts/harness-eval-runner.mjs \
+  --output-json "./tmp/harness-eval-summary.json" \
+  --output-markdown "./tmp/harness-eval-summary.md"
+
+# 从历史 summary 目录生成趋势报告
+node scripts/harness-eval-trend-report.mjs \
+  --history-dir "./artifacts/history" \
+  --output-json "./tmp/harness-eval-trend.json" \
+  --output-markdown "./tmp/harness-eval-trend.md"
+```
+
+## 输出摘要里应该看什么
+
+Runner 摘要至少回答下面这些问题：
+
+- 总共有多少 suite / case
+- 有多少 case 已经 ready
+- 哪些 case 缺文件
+- 哪些 case JSON 字段不完整
+- 哪些 case 属于什么 suite tag / failure mode
+- 哪些 case 默认需要人工复核
+- 工作区 replay 是否已经开始形成增量样本
+
+如果摘要回答不了这些问题，就说明 runner 还不算进入 current 主链。
+
+Trend 报告至少还要回答：
+
+- baseline 和 latest 之间，ready / invalid / pending request 有没有变化
+- 哪些 suite 在 latest 里变差了
+- 哪些 failure mode / suite tag 在 latest 里增长或退化了
+- 当前只有 trend seed，还是已经开始形成真正的历史窗口
+
+## 与其他事实源的关系
+
+| 文档 / 文件                                                                                | 角色                                            |
+| ------------------------------------------------------------------------------------------ | ----------------------------------------------- |
+| [agent-evaluation.md](agent-evaluation.md)                                                 | 解释评估原则、pass@k / pass^k、grader 类型      |
+| [testing-strategy-2026.md](testing-strategy-2026.md)                                       | 解释为什么 eval 工程化排在 smoke 之后           |
+| [../tech/harness/implementation-blueprint.md](../tech/harness/implementation-blueprint.md) | 解释 `P3-2 Eval runner` 在 Harness 主线中的位置 |
+| [../tech/harness/tooling-roadmap.md](../tech/harness/tooling-roadmap.md)                   | 解释 runner、nightly、trend 的后续工具面        |
+| `scripts/harness-eval-runner.mjs`                                                          | 当前唯一的 runner 入口                          |
+| `scripts/harness-eval-trend-report.mjs`                                                    | 当前 trend 聚合与 nightly 趋势出口              |
+| [harness-evals.manifest.json](harness-evals.manifest.json)                                 | 当前任务集与 suite 机可读事实源                 |
+
+## 下一刀
+
+`P3-6` 做完之后，下一刀优先级建议固定为：
+
+1. 把分类聚合直接挂到熵治理清单，形成 replay 驱动 cleanup 主线
+2. 继续补 observability 证据字段，让 grader 能消费更多 request / timeline / artifact 关联
+3. 逐步提高 repo current 样本质量，而不是只增加数量
+4. 再考虑是否引入真实模型执行或 transcript grading
+
+## 非目标
+
+当前阶段默认不做：
+
+- 不把 runner 变成第二套 CI 总控
+- 不要求所有 replay case 都进仓库版本控制
+- 不在这一刀里直接引入真实模型调用成本
+- 不绕开 `handoff bundle / evidence pack / replay export` 另造样本格式
@@ -0,0 +1,43 @@
+{
+  "replayCaseVersion": "v1",
+  "exportedAt": "2026-03-27T11:30:00Z",
+  "handoffBundle": {
+    "relativeRoot": ".lime/harness/sessions/fixture-session-minimal-pending-request/handoff",
+    "absoluteRoot": "/workspace/lime/.lime/harness/sessions/fixture-session-minimal-pending-request/handoff",
+    "artifacts": [
+      {
+        "kind": "plan",
+        "title": "执行计划",
+        "relativePath": ".lime/harness/sessions/fixture-session-minimal-pending-request/handoff/plan.md"
+      },
+      {
+        "kind": "handoff",
+        "title": "交接摘要",
+        "relativePath": ".lime/harness/sessions/fixture-session-minimal-pending-request/handoff/handoff.md"
+      }
+    ]
+  },
+  "evidencePack": {
+    "relativeRoot": ".lime/harness/sessions/fixture-session-minimal-pending-request/evidence",
+    "absoluteRoot": "/workspace/lime/.lime/harness/sessions/fixture-session-minimal-pending-request/evidence",
+    "knownGaps": [
+      "当前 fixture 不包含真实浏览器快照，只验证 replay 样本结构与 grader 约定。"
+    ],
+    "artifacts": [
+      {
+        "kind": "summary",
+        "title": "证据摘要",
+        "relativePath": ".lime/harness/sessions/fixture-session-minimal-pending-request/evidence/summary.md"
+      },
+      {
+        "kind": "runtime",
+        "title": "运行时快照",
+        "relativePath": ".lime/harness/sessions/fixture-session-minimal-pending-request/evidence/runtime.json"
+      }
+    ]
+  },
+  "recentArtifacts": [
+    "docs/tech/harness/implementation-blueprint.md",
+    ".lime/harness/sessions/fixture-session-minimal-pending-request/handoff/handoff.md"
+  ]
+}
@@ -0,0 +1,28 @@
+{
+  "replayCaseVersion": "v1",
+  "exportedAt": "2026-03-27T11:30:00Z",
+  "sessionId": "fixture-session-minimal-pending-request",
+  "threadId": "fixture-thread-minimal-pending-request",
+  "goalSummary": "确认评估链不会把仍存在 approval request 的会话误判为已完成。",
+  "successCriteria": [
+    "评分结果必须明确说明 pending request 是否已解决、保留还是不影响结论。",
+    "若沿用 handoff bundle 与 evidence pack，结论必须引用至少一条证据来源。",
+    "不得因为工具调用路径不同而直接判失败。"
+  ],
+  "blockingChecks": [
+    "确认 approval-fixture-001 是否仍处于待处理状态。",
+    "确认 `waiting_request` 不会被误判为 `completed`。"
+  ],
+  "artifactChecks": [
+    "确认 `.lime/harness/sessions/fixture-session-minimal-pending-request/handoff/handoff.md` 仍与目标一致。",
+    "确认 evidence pack 中记录的 known gaps 没有被当作 PASS 证据。"
+  ],
+  "nonGoals": [
+    "不要要求与原始会话完全相同的工具调用顺序。",
+    "不要把措辞差异当作失败，除非它改变了交付结果或风险判断。"
+  ],
+  "graderSuggestion": {
+    "preferredMode": "result_artifact_and_request_resolution",
+    "requiresHumanReview": false
+  }
+}
@@ -0,0 +1,37 @@
+# Replay Case 评分说明
+
+- 会话：`fixture-session-minimal-pending-request`
+- 线程：`fixture-thread-minimal-pending-request`
+- 导出时间：2026-03-27T11:30:00Z
+- 目标摘要：确认评估链不会把仍存在 approval request 的会话误判为已完成。
+
+## 建议读取顺序
+
+1. 先读 `input.json`，理解当前任务与运行时上下文。
+2. 再读 `expected.json`，确认只评估结果与风险。
+3. 再读 `evidence-links.json`，跳转到已有证据源。
+4. 如需补证据，优先回看 handoff bundle 与 evidence pack。
+
+## 评分原则
+
+- 只评结果，不评路径。
+- 先证据后结论；没有证据支撑的 PASS 不成立。
+- 如仍存在 pending request，必须解释它是已处理、仍保留，还是不影响判定。
+
+## 最小通过条件
+
+- 结果必须解释 pending request 的处理状态。
+- 结果必须引用 handoff 或 evidence 中的至少一条证据。
+- 不得把 `waiting_request` 误判成 `completed`。
+
+## 建议输出模板
+
+```text
+verdict: pass | fail | needs_review
+reason:
+- ...
+evidence:
+- ...
+risks:
+- ...
+```
@@ -0,0 +1,102 @@
+{
+  "replayCaseVersion": "v1",
+  "source": "lime.fixture.replay_case",
+  "exportedAt": "2026-03-27T11:30:00Z",
+  "session": {
+    "sessionId": "fixture-session-minimal-pending-request",
+    "threadId": "fixture-thread-minimal-pending-request",
+    "workspaceId": "fixture-workspace",
+    "workspaceRoot": "/workspace/lime",
+    "model": "fixture-model",
+    "executionStrategy": "agent_runtime"
+  },
+  "task": {
+    "goalSummary": "确认评估链不会把仍存在 approval request 的会话误判为已完成。",
+    "latestPlan": "先导出 handoff bundle，再导出 evidence pack，最后生成 replay case。",
+    "latestTurnSummary": "当前会话已生成 replay case，但还有一个待处理审批请求。",
+    "latestTurnPrompt": "请把这次 pending request 会话导出为可回放样本。",
+    "latestTurnId": "turn-fixture-001",
+    "latestTurnStatus": "action_required",
+    "threadStatus": "waiting_request",
+    "primaryBlockingSummary": "存在待审批写文件请求，需要在评分时显式说明是否已处理。"
+  },
+  "classification": {
+    "sourceKind": "repo_fixture",
+    "suiteTags": [
+      "conversation-runtime",
+      "replay",
+      "pending-request",
+      "handoff",
+      "evidence"
+    ],
+    "failureModes": ["pending_request", "unfinished_todo"],
+    "primaryBlockingKind": "pending_request"
+  },
+  "runtimeContext": {
+    "pendingRequests": [
+      {
+        "requestId": "approval-fixture-001",
+        "requestType": "approval_request",
+        "title": "允许写入 replay 样本目录",
+        "actionType": "write_file",
+        "prompt": "需要确认是否允许写入 `.lime/harness/sessions/.../replay`。"
+      }
+    ],
+    "queuedTurns": [],
+    "todoItems": [
+      {
+        "content": "导出 replay case",
+        "status": "completed"
+      },
+      {
+        "content": "评估 pending request 风险",
+        "status": "in_progress"
+      }
+    ],
+    "activeSubagents": [],
+    "recentArtifacts": [
+      "docs/tech/harness/implementation-blueprint.md",
+      ".lime/harness/sessions/fixture-session-minimal-pending-request/handoff/handoff.md"
+    ],
+    "recentTimeline": [
+      {
+        "itemId": "timeline-fixture-001",
+        "turnId": "turn-fixture-001",
+        "payloadKind": "plan",
+        "status": "completed",
+        "summary": "产出 replay 导出计划",
+        "updatedAt": "2026-03-27T11:20:00Z"
+      },
+      {
+        "itemId": "timeline-fixture-002",
+        "turnId": "turn-fixture-001",
+        "payloadKind": "approval_request",
+        "status": "pending",
+        "summary": "等待写文件审批",
+        "updatedAt": "2026-03-27T11:24:00Z"
+      }
+    ],
+    "lastOutcome": {
+      "thread_id": "fixture-thread-minimal-pending-request",
+      "turn_id": "turn-fixture-001",
+      "outcome_type": "partial_success",
+      "summary": "handoff 与 evidence 已导出，replay 样本待审批确认",
+      "primary_cause": "pending_request",
+      "retryable": true
+    },
+    "incidents": []
+  },
+  "linkedArtifacts": {
+    "handoffBundle": {
+      "relativeRoot": ".lime/harness/sessions/fixture-session-minimal-pending-request/handoff",
+      "artifactCount": 4
+    },
+    "evidencePack": {
+      "relativeRoot": ".lime/harness/sessions/fixture-session-minimal-pending-request/evidence",
+      "artifactCount": 4,
+      "knownGaps": [
+        "当前 fixture 不包含真实浏览器快照，只验证 replay 样本结构与 grader 约定。"
+      ]
+    }
+  }
+}
@@ -45,10 +45,10 @@

 ## 3. 当前仍未解决的问题优先级

-| 优先级 | 事项                  | 为什么重要                                     | 当前证据                                                                                                                  | 完成定义                                                                                                   |
-| ------ | --------------------- | ---------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------- |
-| P0     | 自包含 smoke 仍然不足 | 单测很多，但主链路仍缺少无需人工准备的自动回归 | 目前仅有 `smoke:workspace-ready` 属于自包含 smoke；`smoke:social-workbench` 仍依赖已有 session，`bridge:e2e` 更像排障脚本 | 至少补齐 3 条无需人工准备的 smoke；当前已完成 1 条，仍需补 server / terminal / browser runtime 等 2 条以上 |
-| P1     | Agent eval 尚未工程化 | 价值高，但建立在前面基础门禁稳定之后           | 仓库已有理念和局部真实测试，但缺少任务集、grader、nightly 报表                                                            | 形成固定任务集、采样归档、grader、nightly 输出与趋势指标                                                   |
+| 优先级 | 事项                      | 为什么重要                                     | 当前证据                                                                                                                                                                                                  | 完成定义                                                                                                   |
+| ------ | ------------------------- | ---------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------- |
+| P0     | 自包含 smoke 仍然不足     | 单测很多，但主链路仍缺少无需人工准备的自动回归 | 目前仅有 `smoke:workspace-ready` 属于自包含 smoke；`smoke:social-workbench` 仍依赖已有 session，`bridge:e2e` 更像排障脚本                                                                                 | 至少补齐 3 条无需人工准备的 smoke；当前已完成 1 条，仍需补 server / terminal / browser runtime 等 2 条以上 |
+| P1     | Agent eval 仍未完全工程化 | 价值高，但建立在前面基础门禁稳定之后           | 已补 `docs/test/harness-evals.md`、`harness-evals.manifest.json`、`scripts/harness-eval-runner.mjs`、`scripts/harness-eval-trend-report.mjs` 与 nightly 摘要 / trend 骨架，但真实执行与更多高价值样本仍缺 | 形成稳定任务集、可增长 replay 样本、grader、nightly 输出与趋势指标                                         |

 ## 4. 建议执行顺序

@@ -70,12 +70,17 @@
 - 有稳定契约检查
 - 有可重复 smoke

-完成后再上：
+当前已先补：
+
+- 固定 manifest 与 replay fixture
+- runner 摘要出口
+- nightly artifact 与 trend 骨架
+
+后续再继续补：

- 固定任务集
 - transcript 存档
- grader
- nightly 报表
+- 更多真实高价值 replay 样本
+- 更长窗口的趋势报表

 ## 5. 当前建议