140 lines
13 KiB
Markdown
140 lines
13 KiB
Markdown
# B01：对话与输入交互复测问题修复
|
||
|
||
发布日期：2026-10-21（Asia/Shanghai）。
|
||
|
||
状态：**待开发，尚未接单或交付**。需求由当前验收与规划端发布，开发端在另一台电脑执行。依据用户已经确认的十项对齐方案与修复要求定义本批范围；开发端阅读后在交付记录登记接单，不需要再次让用户确认已有需求。
|
||
|
||
## 1. 交接与基线
|
||
|
||
- 唯一仓库：`gitea`，`https://gitea.iiiii.run/admin/ycode.git`；主线 `master`。
|
||
- 开发起点：`21ca0e0fc379e7a71639b5160c1b7cd168b9d6fa`，已经包含原实现、复测报告和协作流程。开发开始时先 fetch；若远端又有代码变化，审阅差异并在接单记录更新基线，不能直接把旧报告套到新代码上。
|
||
- 原始受测产品提交：`37ddb2ce24c23d1fab7d0609a62901cc666d4975`。其后的 `5b3dd42`、`21ca0e0` 仅为协作文档提交，不包含本批修复。
|
||
- 本批接单与交付文件：`docs/协作/B01-交付-01.md`，由开发端创建；验收文件：`docs/协作/B01-验收-01.md`，由验收端在真实验收后创建。不得预填通过记录。
|
||
- 本文件推送成功后，**本批推送窗口转交开发端**。验收端默认只读 fetch／检查；新增规划先本地整理，交还窗口后再推送。开发端提交交付记录并通知用户后，窗口交回验收端。
|
||
|
||
必须先读：
|
||
|
||
1. [开发与验收协作流程](开发与验收协作流程.md)。
|
||
2. [完整对齐方案](../WorkBuddy对话与输入交互统一对齐方案-2026-10-21.md)。
|
||
3. [Windows复测与后续开发](../对话输入对齐复测与后续开发-2026-10-21.md)，尤其 A01～A09 的复现与证据边界。
|
||
4. 根目录 `AGENTS.md` 与 `docs/接手状态-2026-10-15.md`。
|
||
|
||
## 2. 本批范围与实施顺序
|
||
|
||
目标是在现有实现上修复已复现缺陷、补齐已确认的视觉差异，并为会话授权建立真实 SDK 验证。保持十项原方案目标；不重新实现已经通过的模型选择、会话 factory 与权限传递。
|
||
|
||
开发主对话负责拆分、集成、审查、最终验证。可以使用子 agent，但必须分配明确文件边界；共享类型、`ChatPane.tsx`、共享 CSS 与跨模块接口由主对话协调，避免并发覆盖。每个子任务报告修改文件、关键决定、验证结果及剩余风险。
|
||
|
||
建议按以下任务执行；编号固定，原 A 编号同时保留。后续修复轮次不重新编号，也不删除旧失败记录。
|
||
|
||
### YC-001 / P1：问答分发、折叠状态与回答卡
|
||
|
||
对应 **A01、A03、A04**。问答链路优先；折叠和样式问题的原始严重度仍为 P2。
|
||
|
||
主要边界：`ToolCallRenderer.tsx`、问答投影与问答组件、`CompletedFold.tsx`、相关工具／思考展开组件及问答 CSS；共享展开状态如需调整，由开发主对话统一设计。不得以全局一个展开布尔值替代消息／part 局部状态。
|
||
|
||
验收标准：
|
||
|
||
- **AC1.1**：真实工具名 `AskUserQuestion`、现有小写别名与历史导入都进入专用问答展示；普通工具不误分发；历史源对象不被改写。
|
||
- **AC1.2**：从原生名称提问、回答、完成到展开过程，问题与回答只展示一次，不泄漏原始 SDK 答案；关联去重和无定位旧历史有回归。
|
||
- **AC1.3**：分别打开内层问答、工具、思考和局部摘要后，外层完成块收起再展开，内层选择保持；后续 part／事件追加后仍稳定。测试真实嵌套组件，而非只测两个独立 disclosure。
|
||
- **AC1.4**：标题在灰卡外，仅问题与答案在内容灰卡内；正文保持 14px、400、1.75 行高，内容壳按已有证据采用 16px 圆角、`12px 16px` 内边距。清除旧 `?`、`+/-`、分隔线等与原版不符结构。
|
||
- **AC1.5**：完成折叠顺序、正文位置、局部默认展开语义不回归；隐藏内容不抢焦点或重复出现在辅助技术中。
|
||
|
||
至少验证：`test:conversation`、`test:alignment`、问答与嵌套折叠 DOM 回归，以及真实 Electron 下原生工具名完整轨迹截图。SSR／jsdom 不承担真实布局通过结论。
|
||
|
||
### YC-002 / P2：运行进度状态闭环
|
||
|
||
对应 **A02**。主要边界：Claude 内核事件处理、共享进度类型／reducer、`StreamingFooter` 及相关事件回归。
|
||
|
||
验收标准：
|
||
|
||
- **AC2.1**：最后一个工具返回后退役该工具状态；仍有并行工具时不能误退役其他工具，也不能继续显示已经完成的工具。
|
||
- **AC2.2**：正文开始输出后不再显示“思考中”；工具完成后的模型等待、正文、收尾均由实际事件驱动，不使用计时伪造阶段。
|
||
- **AC2.3**：消费已安装 SDK 的真实 `system/api_retry` 结构，保留可用的重试次数、延迟与原因；收到恢复事件后退出重试。不把限流、未知错误统称为网络故障。
|
||
- **AC2.4**：等待用户／权限的优先级、终态清理、取消与乱序防护保持；晚到 progress 不能把已结束回合恢复为运行。
|
||
- **AC2.5**：回归覆盖“工具结果 → 模型等待 → 正文 → 重试 → 恢复 → 终态”，穿插并行工具、审批、取消与乱序。原版文案依据现有 REA 证据；未知词典或 reasoning-only 边界单独记录，不自行宣称完整恢复。
|
||
|
||
至少验证：直接事件驱动的内核＋共享 reducer 测试、`test:chat`、`test:alignment`、`test:conversation`、`test:assistant-footer`；真实窗口记录各阶段及等待态。
|
||
|
||
### YC-003 / P2：模式、确认浮层、加载与授权卡视觉
|
||
|
||
对应 **A05、A06、A07、A08**。主要边界：ModeChip、TaskPopconfirm、SessionLoading、PermissionConfirm、相关局部 CSS；输入区占位与共享 Popover 变更由开发主对话集成。
|
||
|
||
验收标准：
|
||
|
||
- **AC3.1 / A05**：模式默认透明背景、pill 圆角和次级文字；hover／focus 在原图标槽位切换为关闭图标，无额外右上角 X。保持 craft 隐藏、plan／ask 有效、权限禁用及模式清除后草稿和权限偏好保留。
|
||
- **AC3.2 / A06**：240px 右侧锚定浮层、箭头与焦点行为保持；主／次／危险按钮样式在 portal 中实际生效。按既定证据恢复 66px 最小宽度、19px 水平 padding、16px 浮层圆角及 600 标题字重，使用用户选择的原版归档说明。
|
||
- **AC3.3 / A06**：更新原来接受错误样式的测试目标，验证计算样式中的背景、边框、圆角、字号及最小宽度；不能只断言 class 存在。忙状态、失败、取消、归档和删除落库行为不回归。
|
||
- **AC3.4 / A07**：骨架名称占位 80×12px，正文宽度 90%／70%／45%；恢复有证据的布局及动效。验证无缓存、缓存、延迟 IPC、快速切换、失败重试、不闪首页与标题／输入区保留。没有原始尺寸证据的项明确保留为未验证，不猜值后称 1:1。
|
||
- **AC3.5 / A07**：测真实消息挂载、滚动与长任务，至少记录固定消息数量、内容规模、硬件／窗口条件、首批可见耗时和最长主线程任务。不能用 Node 解析耗时替代浏览器性能；发现阻塞后按实测热点修复，保持消息完整可达、搜索、滚动锚点及局部展开语义。
|
||
- **AC3.6 / A08**：拦截规则详情为右上锚定浮层，入口 14px／22px；显示真实可用规则／原因，无数据不编造。恢复稳定默认选中背景和箭头，同时保持默认拒绝等安全选择语义，不因展示选中自动授权。
|
||
- **AC3.7 / A08**：按参考同状态核对授权卡与输入区替换／占位关系，不保留无依据的重复完整输入框；数字键、焦点、忙状态、错误和重试行为保持。
|
||
- **AC3.8**：对修复表面验证浅色、深色和窄窗；分别记录计算样式、截图与功能结果。原版对照没有同版本、同状态证据时，视觉结论为“修复后待原版对照”，不得记为逐像素通过。
|
||
|
||
至少验证：`node scripts/verify-task-menu.cjs`、相关模式／问答／授权 DOM 回归、真实 Electron 的加载／模式／授权／确认浮层截图与计算样式，以及真实历史性能记录。
|
||
|
||
### YC-004 / P1 验收缺口：真实 SDK 会话授权
|
||
|
||
对应 **A09**。这是验收缺口，尚不能据此声称当前 SDK 路径必然故障。已有 session＋workspace 隔离、规则映射与重放不得无理由重做。
|
||
|
||
主要边界：内核 permission callback、`session-grants.ts`、broker 与真实 SDK 集成脚本。真实服务使用本地可控 loopback 模型，临时 userData 和专用 workspace；不请求用户供应商、不写真实工作区。
|
||
|
||
验收标准：
|
||
|
||
- **AC4.1**：真实本地 SDK／CLI 中，“允许一次”后相同操作再次触发审批；“本次会话内始终允许”后，明确相同授权范围内的第二次工具执行不再审批，且工具实际完成。
|
||
- **AC4.2**：不匹配操作、另一会话、另一工作区继续按策略审批，不能用全工具白名单或模糊字符串扩大授权范围。
|
||
- **AC4.3**：跨回合、切走返回和内核重建后验证 grant 重放；计划／仅问答限制、显式询问和拒绝不被绕过。
|
||
- **AC4.4**：验证更新失败、取消、重复提交和并发响应，记录请求、响应、真实 permission callback 及第二次工具结果。mock 接口成功或 `updatedPermissions` 对象正确不足以通过。
|
||
- **AC4.5**：客户端重启后的 grant 生命周期若缺少原版证据，明确未验证；不得擅自做成用户级／项目级永久授权。持久权限偏好与 session grant 不混为一谈。
|
||
|
||
至少验证：新增或扩展真实 SDK／CLI loopback 矩阵、`test:alignment` 中已有 policy／grant mock 回归，以及授权卡到宿主响应的集成路径。报告分开列出真实场景、mock 场景和未覆盖场景。
|
||
|
||
## 3. 共通交付要求
|
||
|
||
1. 不新增虚构模型、费用、进度或规则。已有用户模型、权限偏好与历史快照不因本批修复被重写。
|
||
2. 原版取证仅通过 REA。引用原版证据时写版本、Evidence ID、观察范围与限制；没有证据的项可以交付为明确阻塞，但本批不得因此全量关闭。
|
||
3. 以独立 userData／workspace 测试。避免默认启动迁移清理真实数据，不复用用户配置，不提交令牌、密码或敏感日志。
|
||
4. 本批不包含发布、安装器执行、自动部署或替换用户安装版。既存六项 token 门禁问题不是放宽 baseline 的理由；记录相对本批基线的变化，至少保证不新增漂移。若修复触及原有违规代码，应按 token 规范处理对应范围。
|
||
5. Windows CRLF 导致 recovered fold-summary 哈希不匹配时，保留摘要断言与原提取内容，使用确定性的检出行尾方案并重测。不得直接改 manifest 哈希掩盖差异；不绕 REA 重新读取原版。
|
||
6. 相关回归与完整 `npm run build` 必须执行。某条命令原先就失败，提供对同基线的复现与失败集合；不能将“原来就失败”写成通过。
|
||
7. 日志／截图需以双方能取得的方式交付：小型脱敏证据可提交在 `docs/协作/证据/B01/`，大型文件提供共享附件及校验值。仅给开发机绝对路径或 `.tmp` 路径不算完成交接；复现脚本保存在 Git，截图对应受测 SHA／场景。
|
||
8. 实测发现范围外缺陷，在交付记录列为下一批建议；不暗中扩大需求。若阻断本批验收，说明依赖并由主对话协调。
|
||
|
||
## 4. 开发端如何接单、交付
|
||
|
||
在已有工作区确认无未处理修改后，显式同步 `gitea/master`，阅读上述入口；若工作区有别的未提交开发，先隔离保存，不能覆盖。
|
||
|
||
创建 `docs/协作/B01-交付-01.md`，先登记接单基线和拆分。完成后提交代码，取得完整代码 SHA，再提交交付记录。交付记录自身可位于后续文档提交。
|
||
|
||
交付记录至少包含：
|
||
|
||
```text
|
||
批次：B01
|
||
状态：开发中／待验收／阻塞
|
||
接单时间、开发负责人、基线完整 SHA：
|
||
需求记录：docs/协作/B01-需求.md
|
||
受测代码完整 SHA（代码提交后填写）：
|
||
|
||
YC-001 / AC1.1～AC1.5：实现情况、验证结果、证据、剩余问题
|
||
YC-002 / AC2.1～AC2.5：实现情况、验证结果、证据、剩余问题
|
||
YC-003 / AC3.1～AC3.8：实现情况、验证结果、证据、剩余问题
|
||
YC-004 / AC4.1～AC4.5：实现情况、真实SDK矩阵、mock边界、剩余问题
|
||
|
||
修改文件与关键决定：
|
||
环境、依赖安装、构建与逐项测试命令／退出码：
|
||
真实窗口启动目录、命令、端口与版本确认：
|
||
复现脚本及双方可取得的脱敏证据位置：
|
||
既存失败与本批新增失败的区别：
|
||
未验证项、阻塞原因、责任方和解除条件：
|
||
回传后推送窗口：交回验收与规划端
|
||
```
|
||
|
||
开发主对话检查 diff、自测和原需求一致后推送 `gitea/master`。向用户回传“B01 已交付，受测代码完整 SHA、交付记录路径、交接提交完整 SHA”，由用户带回当前验收对话；不要以子 agent 完成消息替代正式交付。
|
||
|
||
## 5. 验收端如何关闭本批
|
||
|
||
收到交付后，fetch 并读取交付记录，在完整代码 SHA 的隔离检出独立构建及逐项验证。使用 `docs/协作/B01-验收-01.md` 记录每条 AC 的“通过／失败／未验证”及证据；不只记四个任务总状态。
|
||
|
||
失败回传最短复现、预期／实际与受测 SHA，下一轮交付／验收文件递增编号。真实 SDK、原版证据或运行环境缺失则标记阻塞，不作为通过。全部约定 AC 有可复核证据后才关闭 B01；范围调整必须明确记录被移出项与新批次编号，不能靠删除失败断言关闭。
|