2.7 KiB
2.7 KiB
title, status, created, updated
| title | status | created | updated |
|---|---|---|---|
| 对话意图、可恢复任务状态与文档占用可见性整改 | in_progress | 2026-09-13 | 2026-09-13 |
对话意图、可恢复任务状态与文档占用可见性整改
背景
见 专项审计。本问题不是单一意图模型错误，而是客户端写操作捷径、任务状态投影、租约展示和诊断数据隔离四处合同不一致。
目标
- 只读表达永不直接触发文档写任务；写操作必须具有明确动作语义。
- 失败、运行中、质量失败和恢复动作刷新后等价恢复。
- 文档被人工或智能体编辑时，在会话、文档列表和编辑器持续显示同一个服务端状态，并在发送前阻止重复写任务。
- 自动化/诊断请求只能使用隔离 fixture，不得写入真实用户会话。
分波次计划
| 波次 | 内容 | 验收 |
|---|---|---|
| Wave 0 | 禁止真实会话诊断探针；补污染审计与只读负例 | “总结/查看/状态/谁在编辑”均不命中写任务 |
| Wave 1 | 将客户端模板匹配收紧为“动作 + 目标”；“总结”由服务端按项目/阶段权限读取正文并在隔离对话目录生成只读摘要 | 明确“编写/生成/更新”触发；总结返回正文摘要且不创建 run/租约 |
| Wave 2 | 持久化/重建 error_info、task request、进度与恢复动作 |
刷新前后失败卡片语义和按钮一致 |
| Wave 3 | 增加运行态/租约查询与统一 busy UI，消费 governance 事件 | 运行中刷新仍显示文档、持有人、阶段、开始时间和禁止编辑提示 |
| Wave 4 | 将 busy 分型为策略状态，执行真实 PI + 刷新 + 双标签页 E2E | 重复请求不会创建第二 run；状态可恢复；完成后自动解锁 |
验收标准
- “总结一下用户初始需求表”返回已有文档摘要，不创建
task_runs。 - “开始编写用户初始需求表”只创建一个 run；运行中再次写请求不创建失败 run。
- 任务失败后刷新，错误码、诊断摘要及允许动作与刷新前一致。
- 运行中刷新，聊天占位、阶段进度、文档 busy 标识和输入保护均恢复。
- 租约释放/任务终态后 UI 自动解除 busy，无需用户手动刷新。
- 测试使用专用项目/会话并在 teardown 清理；禁止
debug/test探针进入非 fixture 会话。
相关链接
- Audit: ../audit/2026-09-13-conversation-intent-runtime-state.md
- Short-term: ../ops/short-term/2026-09-13-conversation-intent-runtime-state.md
- gap-matrix 行:
CHAT-INTENT-STATE