docs：AGENTS.md 补协作约定（走分支、推前先 rebase、推完要同步）

起因：别人直接推 main（cc54603），本地未同步就分叉；同时 tag 与发布包错位。
把这些变成明文规则，避免下一个人或下一个 AI 重犯。

- 8.1 推送前先 rebase（强制）：git status -sb → git pull --rebase → push 固定顺序，
  禁止 push 被拒后用 reset --hard，附冲突处理与真实案例
- 8.2 多人/多 AI 协作走分支：跨文件、双人同改 gmweb/ 必须走分支 + 合并请求；
  单人确定改动与纯文档可直推，但仍受 8.1 约束
- 8.3 推完不等于生效：同步 Z:/90server 与桌面补丁包 → diff -rq → 重打包 → 通知重启
- 发版清单新增：打 tag 前用 git log -1 与 ls-remote 的 ^{} 双向确认指向实际发布的提交
- 当前状态记录 tag 基线：v2026.11.05 → 3b240ec（annotated），后续提交不在该 tag 内
- 不要做的事补三条：未 pull 就 push、reset --hard 覆盖、tag 错位发 Release

AGENTS.md

@@ -201,12 +201,18 @@ msedge --headless=new --disable-gpu --hide-scrollbars --window-size=800,720 \
 - [ ] 版本号三处一致（`CURRENT_VERSION` / 客户端显示 / 更新日志）
 - [ ] **干净目录**（非中文、无空格）实跑一遍再对外发
 - [ ] Release 说明用模板；附件传 `docs/release/网盘下载.url`（别直传十几 G 的包）
+- [ ] **打 tag 前先确认它指向「实际发布的那个提交」**：`git log --oneline -1 v2026.11.xx`，
+      再用 `git ls-remote --tags origin` 看远端解析到的 `^{}` 是不是同一个 sha。
+      tag 与代码错位时，Release 的「源码包」是一份旧代码，排查起来极难想到
 
 ---
 
 ## 7. 当前状态（2026-11-05）
 
 - 版本 `v2026.11.05`；`main` 与 `origin/main` 同步
+- **tag 基线**：`v2026.11.05` 指向 `3b240ec`（annotated），就是本次补丁包对应的代码；
+  之后的提交（如 `cc54603` 一键换装）**不在**这个 tag 里，发下一版要另打 `v2026.11.06`
+- Release `2026.11.05更新`（id=3）绑此 tag，附件 `90CN灵宝小竹整合20261105更新补丁.rar`
 - 启动器：六页（开始/GM工具/一键换装/游戏设置/游戏更新[当前|历史]/关于我们），关于页三列二维码
 - gmweb：四页，关于页三列（赞助我们 353 | 官方QQ群 178 | 团队公众号 179，面板宽 712）
 - 已修复：启动器打包后自我套娃开窗（P-001），带单实例互斥 + 运行日志 + WebView2 固定数据目录
@@ -220,7 +226,46 @@ msedge --headless=new --disable-gpu --hide-scrollbars --window-size=800,720 \
 2. 一次提交一件事；改了接口就同步改对应文档（服务端接口 → `docs/服务端开发文档.md`）
 3. 只提交源码与文档；产物走 `.gitignore`
 4. 新踩的坑，追加到 `docs/踩坑记录.md`（编号延续 P-0xx，格式照抄现有条目）
-5. 推送前 `git status -sb` 确认工作区干净、与 `origin/main` 无分叉
+
+### 8.1 推送前先 rebase（强制，不是建议）
+
+`main` 是**多人共享**的分支，别人（包括另一个 AI）随时可能已经推过。本地 commit 后直接 `push`
+会被拒（non-fast-forward）；这时最容易发生的坏操作是「先 reset 再重来」，改动就丢了。
+
+固定顺序，别跳步：
+
+```bash
+git status -sb          # ① 工作区必须干净；看 ahead/behind
+git pull --rebase       # ② 把本地提交挪到远端最新之上，有冲突当场解决
+git push origin main    # ③ 推
+```
+
+- 同步别人的改动时用 `git merge --ff-only origin/main` 或 `git pull --rebase`，**不要** `git reset --hard`
+- rebase 遇到冲突：改完 `git add <文件>` → `git rebase --continue`；搞不定就 `git rebase --abort` 回到原样再来
+- 推送后用 `git log --oneline -3` 确认自己的提交在最新，而不是被顶回旧位置
+
+> 真实案例：`cc54603`（别人的一键换装）就是直接推的 `main`，本地因未同步而分叉；
+> 好在工作区干净才能 `--ff-only` 快进过去，否则就得手工合。
+
+### 8.2 多人 / 多 AI 协作走分支，别直推 `main`
+
+| 场景 | 做法 |
+|---|---|
+| 改动跨多个文件、要评审、或不确定是否上线 | 建分支 `feat/xxx` / `fix/xxx` → 推送 → 发合并请求（Pull Request），由维护者合并 |
+| 同时有两人在改同一个目录（尤其 `gmweb/`） | **必须走分支**，否则后推的人一定覆盖前者 |
+| 单人、改动确定、改完立刻部署验证 | 可以直推 `main`，但仍要遵守 8.1 |
+| 只改文档 | 可以直推 `main`，仍要遵守 8.1 |
+
+分支命名：`feat/换装方案`、`fix/启动器端口` 这类「类型/主题」，合并后删掉分支。
+
+### 8.3 推完不等于生效
+
+仓库改了，`Z:\90server` 和桌面补丁包**还是旧的**（见 R3）。凡是改了 `gmweb/`、启动器或客户端的提交，
+推完要：同步部署副本 → `diff -rq` 核对 → 该重打包的重打包 → 通知实际在玩的人重启启动器。
+
+> 真实案例：`cc54603` 推了 gmweb 一键换装，但部署目录没同步，游戏里看不到新功能；
+> 同时 18112 被一个残留 `serve.py` 占着，启动器看到端口已占用就跳过启动，
+> 于是「改了、推了、也重启了，还是旧页面」（见 P-007、P-008）。
 
 ---
 
@@ -234,3 +279,6 @@ msedge --headless=new --disable-gpu --hide-scrollbars --window-size=800,720 \
 - ❌ 不要提交 exe/dll/`dnf_items.json`/PVF 资源
 - ❌ 不要把本机测试用的掉落改动带进对外发布的服务端
 - ❌ 不要公开分发或倒卖本仓库代码与资源（`pvf/` 除外，但受 GPL-3.0 约束）
+- ❌ 不要在没 `git pull --rebase` 的情况下直接 `push` —— 见 8.1
+- ❌ 不要在 push 被拒后用 `git reset --hard` 或强推 `--force` 覆盖别人的提交 —— 先 `pull --rebase`
+- ❌ 不要在 tag 指向错误提交的情况下发 Release —— 见第 6 章最后一项