docs: standardize Gitea handoffs for development and acceptance

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）。这只是待规划清单，尚未接单、派发或关闭；每批应把上述需求模板补成可验收标准后再交给开发端。