docs: standardize Gitea handoffs for development and acceptance

docs/WorkBuddy对话与输入交互统一对齐方案-2026-10-21.md

@@ -1,5 +1,9 @@
 # WorkBuddy 对话与输入交互统一对齐方案
 
+> 双机协作入口：[开发与验收协作流程](协作/开发与验收协作流程.md)。仅使用 `gitea/master` 交接；另一台电脑开发，当前对话验收、评审与规划。以下复测版本是历史基线，正式复测以开发端交付记录中的完整 SHA 为准。
+
+> 2026-10-21 Windows 复测：开发成果已在 `gitea/master` 的 `37ddb2c`，而当前本地 `master` 的 `771ca54` 只保存了方案。已对新版本做隔离构建、回归、原生窗口与专项反例测试。**基础功能已落地，但尚未完整验收**；继续开发请先读[复测结果与后续指引](对话输入对齐复测与后续开发-2026-10-21.md)。下文仍为验收目标，不能将条目存在视为实现完成。
+
 ## 一、目标与证据基线
 
 统一覆盖十项：**会话加载、模型选择、权限保存与首发生效、模式输入栏、过程分组、运行状态、问答展示、完成收起／展开、工具授权、归档／删除确认**。
@@ -122,3 +126,13 @@
 - 主要入口：`.tmp/rea-runtime-scripts.json`（历史运行时脚本）、`.tmp/rea-css-recovered/manifest.json`（恢复 CSS 的来源清单）、`.tmp/rea-css-evidence/`（本方案引用的选定证据）、`.tmp/rea-context-source-candidates-20261017/src-0FGg1seX.js`、`.tmp/task-menu-runtime-source.js`、`.tmp/rea-visual-tool-expanded/` 及完成态、归档确认对照截图。
 - JS Evidence `ev_717fa5e846e64d67ac19c8925d121bff632c0d3aefb3603b10858559cabb2dcb` 对应 WorkBuddy 5.8.2；CSS Evidence `ev_176b4a0369c4836f9498bd4a9c7c9dff10022defcbddaad6dd0080442de78ee9` 对应 5.8.3。不得将历史 JS 统一标注为 5.8.3，或把前端映射当成后台授权生命周期已验证。
 - 不复制 `.tmp/rea-current-evidence.json` 整包（约 511 MiB）、无关资料库模块导出、REA 工具运行时及依赖、测试编译产物。本交接是选定材料集，不是完整 REA 会话备份；没有覆盖的记录及后台行为仍须经 REA 补取，不能推断为已验证。
+
+## 七、最新复测状态与继续开发入口（2026-10-21）
+
+- 审查版本：`37ddb2c`（包含 `308b98d` 实现和后续修复），不是旧工作区 `771ca54`。完整结果、代码位置、关闭条件及测试边界见[Windows复测报告](对话输入对齐复测与后续开发-2026-10-21.md)。本轮只更新文档，未修改产品源码、提交或合并分支。
+- **优先修复**：A01原生 `AskUserQuestion` 大小写未命中专用renderer；A02工具完成、正文输出和SDK重试状态未闭环；A03外层完成块切换会重置内层展开状态。这三项已由当前代码最小反例复现，不能以现有绿色回归关闭。
+- **样式继续对齐**：A04已答问答标题仍包在灰卡内；A05模式Chip仍用灰块／外置关闭按钮；A06 Popconfirm按钮变体未加载、圆角和排版不同；A07骨架尺寸为本地版本；A08规则详情仍是内联块，授权选中和占位布局待补。已有Windows计算样式和截图，具体值见报告。
+- **授权验收独立保留**：A09已有主机侧会话规则与重放，但测试仍为mock，没有验证真实SDK的重复匹配、不匹配、跨回合／内核重建。不得直接声称“始终允许已修好”，也不能反向声称“完全没有恢复实现”。
+- **已经修复的旧问题不重复开发**：会话factory传递权限、新增／删除模型同步、全局latest过程栏、单工具强制摘要、问答文字12px／600和完成时间冒用创建时间，均已有新实现；继续验证其完整链路和视觉边界。
+- 验证结果：构建／类型检查、离线alignment及66项DOM、聊天／持久化／会话等回归通过；真实Windows任务菜单47项通过。`check:tokens`仍为原基线相同6项失败；fold-summary在CRLF检出环境摘要失败，LF归一后匹配，分别作为既存门禁和构建可复现性问题处理。
+- 本地证据位于 `.tmp/workbuddy-alignment-audit-20261021/`，不随Git自动交接。大历史浏览器渲染、真实SDK授权、深色／窄窗及原版同状态像素仍须继续验收。

docs/协作/开发与验收协作流程.md

@@ -1,10 +1,14 @@
 # 开发与验收协作流程
 
+更新：2026-10-21（Asia/Shanghai）。本流程以 **Gitea 为唯一交接源**；以下角色按职责定义，不使用随电脑变化的“本机／另一台”指代。
+
 ## 1. 两台电脑，一条主线
 
-- **开发机（本机）**：负责业务源码、测试脚本、依赖与构建配置；实现需求、自测、构建并提交交付记录。
-- **验收与规划机（另一台）**：独立拉取指定提交、安装依赖和构建，验收、记录问题并规划下一批；不直接修改业务源码“顺手修复”。
+- **开发端（用户另一台电脑上的开发对话）**：负责业务源码、测试脚本、依赖与构建配置；实现需求、自测、构建并提交交付记录。开发端可以按根目录约定委派子 agent，由开发主对话集成和自测。
+- **验收与规划端（当前对话）**：独立拉取指定提交、安装依赖和构建，验收、记录问题并规划下一批；默认只修改需求、验收与交接文档，不修改业务源码、测试脚本、依赖或构建配置。子 agent 在这里用于调查、测试及评审；发现问题回传开发端。用户明确授权本地修复时才改变此边界，并记录责任转移。
+- 唯一交接仓库：远程名 `gitea`，地址 `https://gitea.iiiii.run/admin/ycode.git`，交接主线 `gitea/master`。`origin` 目前指向 GitHub，不用于本流程的拉取、推送或交付 SHA 判断，也不自动双向同步；保持其现有配置。
 - 使用当前仓库的 `master` 协作，不另设长期开发／验收分支。Git/Gitea 保存需求、代码、证据索引和结论，**不会自动执行开发或验收**；每次交接须明确通知对方批次、记录位置和 SHA。
+- `master` 是交接主线，可能包含“待验收”代码；分支名或推送成功都不代表已验收。可用版本以对应验收记录中的完整 SHA 与逐项结论为准。
 - 开始前阅读根目录 `AGENTS.md`、`docs/接手状态-2026-10-15.md` 及本批相关记录。原版 WorkBuddy 取证只通过 REA，不能因验收困难绕过。
 
 ## 2. 批次与状态
@@ -24,18 +28,23 @@
 - 开发方主写业务源码和交付记录；验收方主写需求、验收结果和下一批规划。同一记录的同一段一次只由一方编辑，转交前先提交、推送并通知。
 - 双方可以并行工作，但**一次只由一方推送**：约定推送窗口，推送完交还；另一方先同步再继续提交。无需引入自动锁或新系统。
 - 按需在 `docs/协作/` 保存批次记录，使用下面的内联模板即可；本流程不要求预先建立一套空文件。
+- 推荐文件名：`B01-需求.md`（验收端主写）、`B01-交付-01.md`（开发端主写）、`B01-验收-01.md`（验收端主写）。修复轮次递增为 `02`，保留历史交付与失败结论。开发端接单状态放交付记录，不与验收端同时改需求文件。
+- 推送窗口按交接回合转交：验收端发布需求后交给开发端；开发端发布交付后交回验收端。持有窗口的一方可提交本批记录；另一方可在固定 SHA 的隔离工作树工作、规划下一批，但不抢推。需要提前交接时通过用户传话明确约定；Git 不提供这把协作锁。
 - 提交只包含本批相关文件；先检查差异，避免 `git add .` 混入日志、构建产物或其他工作。
 
 开始工作或接到推送通知后，在主工作目录执行：
 
 ```sh
 git status --short --branch
-git fetch origin
-git log --oneline --left-right HEAD...origin/master
+git remote get-url gitea
+git fetch gitea
+git log --oneline --left-right HEAD...gitea/master
 # 确认当前在 master、工作区干净且没有分叉后：
-git pull --ff-only origin master
+git pull --ff-only gitea master
 ```
 
+若开发端是新 clone，且该 Gitea 地址被命名为 `origin`，先执行 `git remote -v`；确认目标确实是上述 Gitea 地址后，用 `git remote rename origin gitea` 统一名称。已有 GitHub `origin` 的检出只需按需 `git remote add gitea https://gitea.iiiii.run/admin/ycode.git`，不要覆盖 GitHub 地址。可以将本地 `master` 的上游设为 `gitea/master`，但本流程中的命令仍显式带 `gitea`，避免裸 `git push` 误推。
+
 有未提交修改时先检查并保留：适合提交的做独立提交，否则明确暂存并记录恢复方式；不要直接覆盖或清理。`pull --ff-only` 失败即停下检查，不用强制同步消除差异。
 
 提交／推送前再次检查并与对方确认窗口：
@@ -46,12 +55,16 @@ git diff
 # git add <明确的文件路径>
 git diff --cached
 # git commit -m "docs(B01): 记录验收结果"  # 按实际类型和批次填写
-git fetch origin
-git log --oneline --left-right HEAD...origin/master
-git push origin master
+git fetch gitea
+git log --oneline --left-right HEAD...gitea/master
+git push gitea HEAD:master
+git rev-parse HEAD
+git ls-remote gitea refs/heads/master
 ```
 
-若推送被拒绝，先 `git fetch origin`、审阅双方新增提交；工作区干净后按实际情况快进，分叉则协商并显式 `git merge origin/master`。冲突由文件负责人逐项核对、解决、检查后提交，再推送。涉及代码的合并必须重跑相关测试；若交付代码变了，登记新的交付 SHA。禁止 `push --force`，禁止用 `reset --hard` 或删除文件丢掉另一方／本地修改。
+只有本次推送成功且远端 SHA 与本次 HEAD 一致，才报告“已交接”。代码 SHA 和交接记录所在的提交 SHA 可以不同，必须分别标明。
+
+若推送被拒绝，先 `git fetch gitea`、审阅双方新增提交；工作区干净后按实际情况快进，分叉则协商并显式 `git merge gitea/master`。冲突由文件负责人逐项核对、解决、检查后提交，再推送。涉及代码的合并必须重跑相关测试；若交付代码变了，登记新的交付 SHA。禁止 `push --force`，禁止用 `reset --hard` 或删除文件丢掉另一方／本地修改。
 
 ## 4. 固定 SHA 的独立验收
 
@@ -60,7 +73,7 @@ git push origin master
 可选：主工作目录保留 `master` 写验收记录，另建 detached worktree 固定代码，不新增远端分支：
 
 ```sh
-git fetch origin
+git fetch gitea
 # 将 <完整交付SHA> 替换为交付记录中的真实值；目标目录须不存在。
 git worktree add --detach ../ycode-accept-B01 <完整交付SHA>
 cd ../ycode-accept-B01
@@ -73,6 +86,8 @@ npm run build
 # 再执行本批交付记录列出的针对性测试；先阅读脚本，确认数据隔离。
 ```
 
+只有明确指定 SHA、确认工作目录干净且实际运行该目录的构建，才开始验收。启动 dev 时记录检出绝对路径、完整 SHA、启动命令、实际端口与窗口，确认 renderer 属于本次检出；不能因为看到一个 YCode 窗口，就认定加载的是新版本。旧 dev 占用端口时只处理已确认属于本次测试的进程，不批量结束所有 Electron／Node。
+
 当前锁文件存在已知 peer 依赖冲突，暂用 `--legacy-peer-deps` 与现有构建说明一致；后续修复依赖约束后同步更新此步骤。
 
 构建失败先记录安装／构建阶段、命令、错误及环境差异，不把环境失败冒充功能失败，也不擅自升级依赖或修改锁文件。验收结束回主工作目录同步，再提交文档；不要在 detached worktree 提交验收记录。
@@ -139,3 +154,35 @@ npm run build
 ```
 
 完成标准是“约定范围在指定 SHA 上有可复核的通过证据”，不是“代码已推送”。本文件只定义流程，不代表任何功能已经完成验收。
+
+## 6. Git 交接消息与当前入口
+
+提交 Git 记录后，由用户将以下短消息带到对应对话即可；双方不依赖彼此的聊天历史、电脑路径或 `.tmp` 目录。
+
+```text
+需求已发布：gitea/master，记录提交 <完整SHA>。
+请阅读 docs/协作/B01-需求.md，接单后在开发端实现、自测并回传交付记录。
+本批推送窗口转交开发端。
+```
+
+```text
+开发已交付：受测代码 <完整SHA>，交付记录提交 <完整SHA>。
+请阅读 docs/协作/B01-交付-01.md，在固定代码 SHA 的隔离检出验收。
+本批推送窗口转交验收与规划端。
+```
+
+```text
+验收已回传：受测代码 <完整SHA>，验收记录提交 <完整SHA>。
+请阅读 docs/协作/B01-验收-01.md；结论 <通过／待修复／阻塞>。
+需要修复时只处理本轮失败项；新增需求另开批次。
+本批推送窗口 <转交开发端／本批关闭>。
+```
+
+用户说“检查一下／继续验收”时，验收端先 fetch 并读取最新交付记录，不自行选择一个看起来最新的 SHA。没有交付记录时可以调查，但将结果标记为探索性复测，不能宣称正式批次通过。此流程没有设置后台轮询或定时自动执行。
+
+当前对话交互对齐的需求与问题入口：
+
+- [完整对齐方案](../WorkBuddy对话与输入交互统一对齐方案-2026-10-21.md)：十项功能与原版证据基线。
+- [Windows复测与后续开发](../对话输入对齐复测与后续开发-2026-10-21.md)：针对 `37ddb2c` 的 A01～A09，包含已证缺陷、样式偏差与真实 SDK 验收缺口；该结果不自动适用于后续代码。
+
+建议按依赖安排后续批次：问答分发／折叠／回答卡（A01、A03、A04），运行进度（A02），界面与加载（A05～A08），真实会话授权矩阵（A09）。这只是待规划清单，尚未接单、派发或关闭；每批应把上述需求模板补成可验收标准后再交给开发端。

docs/对话输入对齐复测与后续开发-2026-10-21.md

@@ -0,0 +1,157 @@
+# 对话与输入对齐：Windows 复测与后续开发
+
+> 后续由开发端修复、当前对话复测并规划，Git 交接统一使用 `gitea/master`。具体职责、记录模板与推送规则见[开发与验收协作流程](协作/开发与验收协作流程.md)。本文保留针对 `37ddb2c` 的原始审查结论，不代表后续版本状态；A01～A09尚未因先前中止的本地修复而关闭。
+
+日期：2026-10-21（Asia/Shanghai）。本轮任务是测试和更新开发指引，没有修改产品源码、安装版或用户数据，没有发起真实供应商模型请求，也没有提交、推送或合并分支。
+
+## 1. 先确认测试的是哪个版本
+
+**实际审查的是 `gitea/master` / `gitea/main` 指向的 `37ddb2c`，不是当前本地 `master` 的 `771ca54`。**
+
+- `771ca54`：保存十项方案；本地工作目录 `C:/Users/Administrator/code/YCode` 和 `origin/master` 的本地跟踪记录均停留在此。
+- `308b98d`：十项对齐实现；`c7231be`：实现与验收说明；`37ddb2c`：竞态与状态修复。
+- 三个新提交已经在本地 Git 对象库中。本轮在独立检出 `C:/Users/Administrator/.codex/worktrees/workbuddy-alignment-audit/YCode` 测试 `37ddb2c`，未切换原工作目录、未覆盖三个原有未跟踪文件。
+- 下文源码行号全部针对 `37ddb2c`。不能直接在旧 `master` 查同一行，再把已修复的旧问题重新列为缺陷。
+- 后续启动 dev 前先执行 `git rev-parse --short HEAD`；若仍是 `771ca54`，看到的不是本轮开发成果。此次没有自动合并或切换用户工作区。
+
+目标仍以[完整方案](WorkBuddy对话与输入交互统一对齐方案-2026-10-21.md)为准。开发方原报告位于审查版本的 `docs/对话输入统一对齐实现与验收-2026-10-21.md`；该报告已经说明授权 mock、像素及原版证据的边界，本轮不把其“部分实现”误读成“全量已验收”。
+
+## 2. 结论与十项状态
+
+**当前是“核心结构和离线行为已落地，仍有可复现功能缺陷及明显样式差异”。绿色回归不能作为十项验收完成的依据。**
+
+| 方案项 | 本轮确认已实现或通过 | 仍不一致／未验收 |
+| --- | --- | --- |
+| 会话加载 | 已消费 loading；不再误进首页；两组骨架；延迟 IPC 下标题和输入区保留；缓存／乱序／失败状态测试通过 | 骨架几何和原版不同；大历史只测了 Node 解析和 store，没有真实渲染帧耗时 |
+| 模型选择 | 新增自动选择、编辑不抢选、空模型入口、legacy 鉴别、删除 reconcile 和 pending 保存竞态回归通过 | 未做真实供应商首发；不能从离线 registry 测试推导全部 UI／请求协议验收 |
+| 权限保存与首发 | factory 已传递并校验权限；权威保存值和设置序列化已有实现，离线首发／模式测试通过 | 客户端重启后的实际界面→真实内核首发仍待端到端验证 |
+| 模式输入栏 | plan／ask 可见、craft 隐藏、清除动作、权限禁用及偏好保留已接 | Chip 的背景、圆角、图标与关闭按钮位置不符原版，见 A05 |
+| 过程分组 | 全局 latest 过滤、单工具成组和 containsToolCall 强制折叠均已移除；局部顺序回归通过 | 外层收起重开会重置内层状态，见 A03 |
+| 底部状态 | 已有真实本地 progress、等待问答／权限及终态清理，不再是全程固定文案 | 工具完成不退役、正文仍为思考、SDK 重试被忽略，见 A02；原版全阶段文案仍未完整恢复 |
+| 问答展示 | 文本实际已为 14px／400／1.75；结构化答案投影及历史去重已有实现 | 原生大小写工具名漏分发，见 A01；灰卡层级与参考图不同，见 A04 |
+| 完成态 | 默认完成折叠、正文锚点、实际终态时间已接 | 内层状态保持未达标；完整操作栏及同状态视觉仍未验收 |
+| 授权卡及会话允许 | 卡片已换 Intercept 结构；主机侧有 session＋workspace 隔离规则和重放；失败／取消等 mock 通过 | 详情不是浮层，默认选中表现仍有差异，见 A08；真实 SDK 匹配和重建效果未验收，见 A09 |
+| 归档／删除 | 真实 Windows Electron 47 项行为通过：240px 右侧浮层、箭头、归档／删除实际落库等 | 按钮样式未生效、局部排版与文案有差异，见 A06；现有测试接受了这些差异 |
+
+## 3. 下一轮必须处理的偏差
+
+### A01 — P1：原生 AskUserQuestion 没有进入专用问答卡
+
+- 位置：`src/renderer/src/workbuddy/conversation/ToolCallRenderer.tsx:135` 的 question 别名只有小写，`:138` 的 `getCapturedToolKind` 按大小写精确匹配。`MessageBubble` 分类时 lowercase，但渲染仍传原名。
+- 最小反例使用未导入的真实 SDK 名称 `AskUserQuestion`，带结构化答案和 `RAW SDK ANSWER`。实测结果：`kind=undefined`、专用问答卡不存在、原始 SDK 输出出现；换成 `askuserquestion` 才正确。整条 MessageBubble 也复现，不能只验投影数组。
+- 开发要求：在统一工具身份／别名层支持真实 SDK 名称；保持普通工具名称和原始历史不被误改。不要为了通过测试而只把 fixture 名称改成小写。
+- 验收：原生名称→回答完成→展开外层完成过程，应看到问题与回答卡，且没有原始工具输出；同时覆盖历史导入、小写别名、关联去重和无位置历史。
+- 证据：`render-repro.log`、`repro.tsx`。
+
+### A02 — P2：进度状态还没有闭环
+
+三条独立的离线事件反例均复现，直接调用当前内核消息处理和共享 reducer，禁止启动 SDK query／CLI：
+
+1. 最后一个工具返回成功后，只发 `tool_result`，工具已为 `ok`，footer 仍为“正在运行 Read”。位置：`claude-kernel.ts:823`、`src/shared/message-parts.ts:63`。应按仍运行的工具集合退役状态，不能无条件覆盖另一个并行工具。
+2. 注入已安装 SDK 的真实 `system/api_retry` 事件形状后，`events=[]`，旧工具状态不变。SDK 类型已有 `attempt/max_retries/retry_delay_ms/error_status/no_response`；这不是“没有数据源所以不实现”的情况。位置：`claude-kernel.ts:667` 的 system 分支和 `src/shared/types.ts:225`。
+3. `message_start` 后收到正文 `text_delta`，正文已经是 `answer`，状态仍为 thinking，footer 仍为“思考中”。位置：`claude-kernel.ts:719`、`:738` 及共享进度类型。
+
+开发要求：补齐工具完成、模型输出、真实重试及恢复的状态转换；重试原因不明确或是限流时，不能统一描述成网络故障。等待用户／权限、取消及终态优先级要继续成立。原版词典和 reasoning-only 边界按既定 REA 证据恢复，不能将本地手写简化文案标成完整原版对齐。
+
+验收至少覆盖工具结果→模型等待→正文→重试→恢复→终态，并穿插并行工具、审批、取消及乱序事件。证据：`backend-progress.log`、`audit-backend-progress-builder.mjs`。
+
+### A03 — P2：外层完成块切换会重置内层展开状态
+
+- 位置：`CompletedFold.tsx:185` 的展开态和 `:211` 起的收起态使用不同组件子树，切换造成内层重新挂载。
+- 用真实 CompletedFold＋AskUserQuestion 的 DOM 反例：内层展开为 `true`→外层收起再展开→内层变 `false`。
+- 开发要求：按消息／part 的稳定身份保留工具、思考和局部摘要的状态；外层开关不能销毁用户的内层选择，也不能借修复恢复成全局一个展开布尔值。
+- 验收真实嵌套组件，不只验两个独立 LiveEventDisclosure；分别覆盖问答、工具、思考和局部摘要，以及后续事件到达后的稳定性。
+- 证据：`fold-state.log`、`fold-state.tsx`。
+
+### A04 — P2：已回答问答的灰卡包住了标题
+
+- 位置：`conversation.css:343` 把灰底、圆角、padding 施加在整个 `.ask-user-question--completed`；`AskUserQuestion.tsx:97` 的 section 同时包含标题和问答内容。
+- Windows 实测：整个卡片灰底，含 `?`、“向用户提问”、`+/-` 及分隔线；外层 padding 为 `8px 12px`，问题区没有独立灰底。这与参考图“标题在灰卡外、仅问题／答案在卡内”不同。
+- **文本字号已经修好**：实际问题与答案均为 `14px/400/24.5px`，不能继续报“仍12px/600”。
+- 开发要求：恢复 ToolExpandable 风格的标题与独立问答内容壳；仅内容区使用16px圆角、`12px 16px`内边距、原版主题色和滚动限制，移除无依据的旧 `?`／`+/-` 结构与边框。
+- 证据：`window-report.json` 的 question、`answered-expanded.png`。为隔离此布局问题，窗口 fixture 使用已能命中 renderer 的小写别名；原生名称问题单独由 A01 覆盖。
+
+### A05 — P2：ModeChip 有功能，但外观和交互仍是本地版本
+
+- 位置：`workbuddy/composer/ModeChip.tsx:5`、`mode-chip.css:1`。
+- 实测已满足32px高、13px／500／20px文字、8px水平内边距和16px图标。不同处是常驻灰底、8px圆角、主文字颜色，以及在右上角额外出现的“×”。聚焦后原模式图标仍在，未切换成同位置关闭图标。
+- 既定原版要求是透明默认背景、pill 圆角、次级文字，hover／focus 后在图标槽位切换为 X；当前 SVG 源码也明确注释为 local geometry。
+- 开发要求：按已经记录的原版组件／SVG证据恢复，不只检查类名存在；保持 craft 隐藏、plan／ask 权限禁用、清除模式及草稿不丢。
+- 证据：`window-report.json` 的 mode/focusedMode、`plan-focus.png`。
+
+### A06 — P2：Popconfirm 的按钮没有获得对应样式
+
+- 位置：`TaskPopconfirm.tsx:55` 使用 `wb-button--secondary/primary`，但 portal 宿主没有使这些按钮变体的样式生效；`task-popconfirm.css:30` 只补了尺寸。已有 `.wb-button` 变体样式多在其他限定作用域，不能凭 class 名认定已经加载。
+- 稳定等待动画结束后实测：主按钮背景透明、文字黑色、圆角0；取消最小宽度仅52px，padding仅`0 8px`。原版要求的主／次／危险按钮视觉以及66px最小宽度、19px水平padding未恢复。
+- 同时实际浮层圆角12px、标题字重500；旧对齐计划的目标为16px圆角及600标题。额外 compatibility 说明使内容和高度也与此前确认的原文不同，不能计为全文1:1。
+- 开发要求：复用能在 portal 中正确加载的已验证按钮原语／样式作用域，修复变体和主题；保留240px、右侧锚定、点击吞掉、焦点、失败及忙状态行为。用户曾明确选择原版归档说明，额外解释应作为产品差异处理，不能暗中写进对齐通过项。
+- 测试盲区：现有 `verify-task-menu.cjs` 47项全绿，却只检查宽度／padding／圆角12px及行为，未检查主按钮背景、次按钮边框、最小宽度和标题字重。必须更正目标断言，不要让实际输出反向定义期望。
+- 证据：`task-menu-report.json`、`window-report.json` 的 popconfirm、`archive-settled.png`。原脚本的第一张抓图处于淡入中，故本轮另等透明度1并稳定后截图，未将抓图时机误报成透明度缺陷。
+
+### A07 — P2：加载行为已有，但骨架几何没有原样恢复
+
+- 位置：`SessionLoading.tsx:12`、`session-loading.css:7`。
+- Windows 延迟1200ms本地 IPC 实测：骨架可见、不显示首页、标题与输入区均在，属于已通过行为。
+- 实际名称占位64×14px，原版记录为80×12px；正文长度100%／100%／65%，原版为90%／70%／45%；当前用户占位和组间距也采用本地token重绘。不能仅凭“两组、1.5秒、300ms”认定样式一致。
+- 开发要求：按原DOM／CSS恢复尺寸、内外间距和淡出曲线，并测缓存到达及快速切换不闪屏。不要凭Node的10,000条消息解析／状态注入耗时宣称浏览器不卡；另测真实消息挂载、滚动和长任务。
+- 证据：`window-report.json` 的 skeleton/switching、`loading.png`。
+
+### A08 — P2：授权详情与默认选中展示仍有偏差
+
+- 位置：`PermissionConfirm.tsx:177` 将“查看拦截规则”展开成卡内普通 div，不是既定右上锚定规则详情浮层；`permission-intercept.css:7` 的入口实际12px，原版记录为14px／22px。
+- 实测卡片已是24px圆角、标题16px／500／25px、选项40px高／12px圆角，不能再报“仍是高额度卡或居中模态”。
+- 当前只以 hover／focus-visible 控制行背景和箭头，没有原版 defaultChoice 的稳定选中状态；鼠标路径进入 fixture 时第一行没有参考图的灰底／箭头。
+- 当前规则卡下仍保留完整独立输入框；参考图只有输入区授权卡。需补同状态布局验收，确认拦截卡替换／占位规则，不以纯SSR认定完成。
+- 开发要求：保留真实原因／规则详情，不编造命中规则；按原版恢复 headerAction 浮层与选中表现，同时保留安全请求的默认拒绝边界及数字键／焦点／失败行为。
+- 证据：`window-report.json` 的 permission/permissionRule、`approval-rule.png`。该窗口注入的是隔离审批快照，仅证明 renderer 布局，不证明规则匹配、工具执行或用户授权生效。
+
+### A09 — P1验收缺口，尚非已证故障：会话始终允许没有真实 SDK 匹配证据
+
+- 新版本已有 `session-grants.ts` 的进程内 session＋workspace 隔离和 `applyFlagSettings` 重放，不能继续使用“完全没接／切换一定丢失”的旧结论。
+- 但 `claude-grant-replay-regression.ts` 和 policy fixture 替换了 query／apply 接口；`claude-kernel-integration.ts:235` 的 approval 回调还直接抛出 `approval was not expected`。因此绿色测试没有覆盖用户反馈的真实 SDK 路径。
+- 下一轮必须用独立工作区、真实本地SDK／CLI和可控loopback模型服务验证：一次允许后再问；会话允许后相同范围不问；不匹配范围及另一会话仍问；跨回合、切走返回、内核重建；显式询问／拒绝及plan／ask限制；更新失败、取消、重复／并发提交。
+- 验收证据应包括请求、响应和第二次工具是否触发审批，不能只检查 `updatedPermissions` 对象或按钮成功。不得用全工具白名单／字符串模糊匹配扩大范围来让测试变绿。
+- 客户端重启后的会话grant生命周期仍需原版证据；本轮不要求改成用户级／项目级永久授权。模式偏好持久化与会话grant生命周期是两件事。
+
+## 4. 本轮测试结果及其证明范围
+
+| 命令／验证 | 结果 | 能证明什么 |
+| --- | --- | --- |
+| `npm run build`（含typecheck） | 通过 | Windows依赖下可编译、构建；不证明交互或授权 |
+| `npm run test:alignment` | 通过 | 离线模型、会话状态、投影及宿主／SDK接口mock |
+| 设置 `YCODE_TEST_DOM_MODULE` 后 `npm run test:alignment` | 通过，28任务确认＋24问答＋14授权DOM检查 | jsdom行为，无真实布局／SDK匹配 |
+| `npm run test:chat`、`test:sessions`、`test:persistence`、`test:model-metadata` | 均通过 | 当前对应状态／存储回归 |
+| `npm run test:conversation`、`test:assistant-footer`、`test:tool-approvals` | 均通过 | 现有SSR／纯状态断言，不能否定A01～A09 |
+| `node scripts/verify-task-menu.cjs` | Windows Electron 47项通过，0个renderer错误 | 本地真实主进程／preload／文件系统上的菜单、归档、删除；不等于样式一致 |
+| 自定义窗口probe | 通过执行，0个renderer错误，记录了偏差 | 1336×902、隔离数据、延迟IPC及审批快照下的计算样式／截图 |
+| 问答分发／内层状态／progress最小反例 | 均复现偏差 | A01、A02、A03具有当前代码可重复证据；probe退出0表示执行成功，不表示产品行为正确 |
+| `npm run check:tokens` | 失败：相同6项既存问题 | 在原始771ca54和审查37ddb2c分别运行，失败集合相同；未刷新baseline、未放宽门禁 |
+| `npm run test:fold-summary` | 隔离检出失败：CRLF摘要不匹配 | `core.autocrlf=true`使生成模块出现717个CRLF。归一LF后的SHA与manifest、原工作区相同；是可复现性问题，非折叠算法回归 |
+
+token既存问题：recommended-flow、skill-detail-shell、skills-host、capability-picker、composer、prompt-queue六份CSS。后续应按来源／token规范处理，不能整体update-baseline把问题隐藏。
+
+fold-summary建议为生成证据模块声明LF并补干净Windows checkout验收；保留摘要校验，不以删除hash断言“修复”。本轮未修改生成物、manifest或行尾。
+
+## 5. 建议的继续开发顺序与关闭条件
+
+1. **先消除A01并补真实名称渲染回归，再闭合A02事件状态机。** 不再重复实现已修复的factory、模型选择及全局分组问题。
+2. **修A03稳定挂载和A04问答内容壳。** 一条真实SDK名字轨迹贯穿提问、回答、完成、展开、外层收起重开，避免各组件测试通过而整条链路失败。
+3. **修A06按钮样式、A05模式Chip、A07骨架和A08授权详情／布局。** 先验证CSS作用域和主题实际命中，再做几何及截图对照，不能仅增加同名class。
+4. **单列A09真实SDK验收。** 通过匹配／不匹配与重建矩阵后，才可以宣称“本次会话始终允许已修复”；仍有原版生命周期未知时保留明确边界。
+5. **补发布验收环境。** 干净Windows checkout、真实大历史渲染、深色／窄窗、共享Popover回归及token门禁分别留证。当前没有同版本原版成对运行截图，不作逐像素通过结论。
+
+测试和修复应在`37ddb2c`或包含它的后续版本进行。保留本报告编号，将每项标记为“待修复／修复后待验／已验证关闭”，关闭时填写提交、命令、场景及证据，不用一条“全部测试通过”覆盖所有状态。
+
+## 6. 本地证据与复现入口
+
+本轮证据已复制到原工作目录的 `.tmp/workbuddy-alignment-audit-20261021/`，独立检出保留未归档。`.tmp` 不随Git提交，交接时需单独复制，不能只交接本文。
+
+- `build.log`、`alignment.log`、`alignment-dom.log`、`tokens.log`、`tokens-baseline-771ca54.log`、`task-menu.log`：主对话实际命令输出。
+- `render-repro.log`、`fold-state.log`、`backend-progress.log`：最小反例输出；对应源码为 `repro.tsx`、`fold-state.tsx`、`audit-backend-progress-builder.mjs`。
+- `window-report.json`：原生Windows窗口计算样式；`task-menu-report.json`：47项菜单行为结果。
+- [加载截图](../.tmp/workbuddy-alignment-audit-20261021/loading.png)、[模式标签聚焦](../.tmp/workbuddy-alignment-audit-20261021/plan-focus.png)、[已回答记录展开](../.tmp/workbuddy-alignment-audit-20261021/answered-expanded.png)、[稳定后的归档浮层](../.tmp/workbuddy-alignment-audit-20261021/archive-settled.png)、[授权详情展开](../.tmp/workbuddy-alignment-audit-20261021/approval-rule.png)。
+- `window-probe.cjs`：通过临时userData和workspace启动真实应用；延迟本地IPC，注入明确的审批fixture；未调用真实模型或审批确认按钮。
+
+在隔离检出中可重跑 `node .tmp/alignment-audit-20261021/window-probe.cjs`。其余反例位于该检出的 `.tmp/audit-render/` 与 `.tmp/audit-backend-progress-builder.mjs`。DOM环境使用 `.tmp/alignment-audit-dom/node_modules/jsdom`；该路径设置为 `YCODE_TEST_DOM_MODULE` 后可重跑可选DOM回归。
+
+本轮没有新增WorkBuddy原版证据；差异判断引用完整方案及用户截图，不读取原版安装包、脚本导出或调试端口。本轮窗口和反例只操作YCode隔离测试环境。真实SDK匹配、当前原版运行对照、像素及安装发布均明确未验收。