增加开发者和协作者ai操作标准流程

2026-04-14 21:06:19 +08:00
parent a2ef57da7e
commit 2a5d71f8a1
4 changed files with 673 additions and 402 deletions
@@ -1,402 +0,0 @@
-# AI 版本发布标准流程
-
-## 用途
-
-本文用于给 AI 一个固定、完整、可重复执行的版本发布流程。
-
-当用户在本仓库中引用本文，并明确说出类似下面的话时：
-
- `更新版本到 6.5.0`
- `按本文发布 6.5.0`
- `引用这个文件，把版本更新到 6.5.0 并发版`
-
-AI 必须按本文执行，不能猜流程，不能跳步骤，不能只做一半。
-
-## 目标
-
-AI 在收到“更新版本到 x.x.x”后，必须完成下面两段流程。
-
-1. 发布前流程。
-修改 `manifest.json` 中的版本号。
-提交本次准备发布的代码。
-基于“上一个 GitHub Release 到当前 HEAD”的真实差异分析更新内容。
-把发布文案先返回给用户看，且必须放在代码块里。
-
-2. 用户确认后的发布流程。
-把用户确认过的文案作为 GitHub Release 正文发布。
-发布完成后，再次从 GitHub 线上读取正文。
-审查正文是否乱码、是否异常、是否与用户确认稿一致。
-如果有问题，必须立刻修正后再汇报完成。
-
-## 仓库硬性规则
-
-1. 任何结论都不能猜，必须基于真实命令输出、真实 diff、真实 GitHub 返回结果。
-2. GitHub Releases 是版本发布真相源。分析“距离上一个版本更新了什么”时，默认以上一个正式 Release 为起点。
-3. 不要先去检查 `gh` 是否存在、是否登录、是否在 PATH、是否可用，也不要先跑 `gh auth status`。直接使用固定路径命令执行。
-4. `gh` 固定路径使用：
-
-```powershell
-$GH = 'C:\Program Files\GitHub CLI\gh.exe'
-if (-not (Test-Path $GH)) {
-  throw 'gh.exe fixed path not found: C:\Program Files\GitHub CLI\gh.exe'
-}
-```
-
-5. 默认 GitHub 仓库固定为：
-
-```powershell
-$Repo = 'QLHazyCoder/codex-oauth-automation-extension'
-```
-
-6. 默认不编译、不跑测试。完成后提醒用户自行测试。
-7. 如果当前工作区里存在无法确认是否属于本次发布的改动，必须先停下来问用户，不能猜哪些该一起发、哪些不该一起发。
-8. 发布完成后，必须做一次“线上正文复检”，确认不是乱码，不是空正文，不是错误版本，不是错误标签。
-
-## 输入要求
-
-AI 至少要从用户输入中拿到下面这些信息：
-
- 目标版本号，例如 `6.5.0`
- 是否已经确认可以发布
- 如果用户有特别强调的更新点，也要纳入发布文案
-
-如果用户没有给版本号，就不能猜。
-
-如果用户说的是口语化版本号，例如 `8`、`8.0`、`v8`、`v8.0`，AI 也不能直接猜最终版本号，必须先向用户确认标准版本号，例如 `8.0.0`。只有在用户明确确认后，后续所有命令、提交、tag、Release 标题、Release 正文都必须统一使用严格的三段版本号 `x.y.z`，不能继续混用口语化写法。
-
-## 固定变量模板
-
-每次执行本文时，先统一使用下面这组变量：
-
-```powershell
-$GH = 'C:\Program Files\GitHub CLI\gh.exe'
-if (-not (Test-Path $GH)) {
-  throw 'gh.exe fixed path not found: C:\Program Files\GitHub CLI\gh.exe'
-}
-
-$Repo = 'QLHazyCoder/codex-oauth-automation-extension'
-$TargetVersion = '<用户确认后的标准版本号，必须使用 x.y.z，例如：6.5.0>'
-$TargetTag = "v$TargetVersion"
-$ManifestPath = 'manifest.json'
-```
-
-## 阶段 1：发布前检查
-
-### 1. 真实查看当前工作区
-
-先执行：
-
-```powershell
-git status --short --branch
-git remote -v
-```
-
-要求：
-
-1. 必须看清当前分支和当前未提交改动。
-2. 如果工作区中有改动，必须结合 diff 判断这些改动是不是本次要发布的真实内容。
-3. 如果有无法确认归属的改动，必须先问用户，不准猜。
-
-### 2. 读取当前版本号
-
-执行：
-
-```powershell
-$Manifest = Get-Content -Path $ManifestPath -Raw | ConvertFrom-Json
-$CurrentVersion = [string]$Manifest.version
-$CurrentVersion
-```
-
-要求：
-
-1. 当前版本必须从 `manifest.json` 真实读取。
-2. 目标版本必须大于当前版本，不能相等，不能更小。
-3. 版本比较必须按版本号比较，不能按字符串比较。
-
-示例校验：
-
-```powershell
-if ([version]$TargetVersion -le [version]$CurrentVersion) {
-  throw "Target version $TargetVersion must be greater than current version $CurrentVersion"
-}
-```
-
-### 3. 检查目标版本是否已经存在
-
-先查 GitHub Releases：
-
-```powershell
-$ExistingReleaseTag = ([string](& $GH api "repos/$Repo/releases?per_page=100" --jq ".[] | select(.tag_name == `"$TargetTag`") | .tag_name")).Trim()
-```
-
-再查本地 tag：
-
-```powershell
-$ExistingLocalTag = ([string](git tag --list $TargetTag)).Trim()
-```
-
-再查最新一个正式 Release：
-
-```powershell
-$LatestReleaseTag = ([string](& $GH api "repos/$Repo/releases?per_page=100" --jq "[.[] | select(.draft == false and .prerelease == false)][0].tag_name")).Trim()
-$LatestReleaseVersion = if ($LatestReleaseTag) { $LatestReleaseTag.TrimStart('v') } else { '' }
-```
-
-规则：
-
-1. 只要 GitHub Release 已存在这个 tag，就必须停止，不能重复发版。
-2. 如果本地 tag 已存在，但 GitHub Release 不存在，也必须停止并告知用户先确认历史状态，不能直接覆盖。
-3. 如果已经存在最新正式 Release，目标版本还必须大于这个正式 Release 的版本号，不能倒发版。
-
-示例校验：
-
-```powershell
-if ($LatestReleaseVersion -and ([version]$TargetVersion -le [version]$LatestReleaseVersion)) {
-  throw "Target version $TargetVersion must be greater than latest released version $LatestReleaseVersion"
-}
-```
-
-## 阶段 2：更新版本号并提交
-
-### 1. 修改 `manifest.json`
-
-AI 必须只把 `manifest.json` 中的 `version` 更新为目标版本。
-
-### 2. 检查变更内容
-
-执行：
-
-```powershell
-git diff --stat
-git diff -- manifest.json
-```
-
-如果工作区里还有其他变更，也要继续真实查看它们的 diff，确认是否属于本次发布内容。
-
-### 3. 提交本次发布
-
-规则：
-
-1. 如果当前工作区改动就是本次要发布的功能改动，就应与版本号一起提交。
-2. 如果存在来源不明或明显无关的改动，必须先停下来问用户，不能偷偷一起提交，也不能擅自丢掉。
-3. 提交信息统一使用：
-
-```text
-chore(release): bump version to vX.Y.Z
-```
-
-示例：
-
-```powershell
-git add -A
-git commit -m "chore(release): bump version to $TargetTag"
-```
-
-提交后，必须记录真实提交哈希：
-
-```powershell
-git rev-parse HEAD
-```
-
-## 阶段 3：分析“距离上一个版本更新了什么”
-
-### 1. 获取上一个正式 Release
-
-执行：
-
-```powershell
-$PreviousReleaseTag = ([string](& $GH api "repos/$Repo/releases?per_page=100" --jq "[.[] | select(.draft == false and .prerelease == false)][0].tag_name")).Trim()
-$PreviousReleaseTag
-```
-
-规则：
-
-1. 默认取最新一个正式 Release 作为“上一个版本”。
-2. 如果仓库还没有任何正式 Release，再退回到本地最新 tag：
-
-```powershell
-if (-not $PreviousReleaseTag) {
-  $PreviousReleaseTag = ([string](git tag --sort=-creatordate | Select-Object -First 1)).Trim()
-}
-```
-
-3. 如果仍然拿不到上一个版本，就按“首个版本发布”处理，并明确告诉用户这是首发版文案。
-
-### 2. 拉真实变更范围
-
-如果存在上一个版本，执行：
-
-```powershell
-git log --oneline "$PreviousReleaseTag"..HEAD
-git diff --stat "$PreviousReleaseTag"..HEAD
-git diff --name-only "$PreviousReleaseTag"..HEAD
-```
-
-然后根据变更文件继续往下读真实 diff，不能只看 commit 标题。
-
-必要时继续执行：
-
-```powershell
-git diff "$PreviousReleaseTag"..HEAD -- <具体文件路径>
-```
-
-### 3. 文案分析要求
-
-AI 必须基于真实 diff 和真实代码上下文，分析并提炼：
-
- 新增了什么功能
- 修复了什么问题
- 优化了什么逻辑
- 删除了什么无用或陈旧逻辑
- 哪些点最值得放进发布说明
-
-禁止行为：
-
- 只看 commit message 就编文案
- 把没有真实证据的内容写进发布说明
- 把技术细节胡乱拔高成“重大更新”
-
-## 阶段 4：先给用户看发布文案，不要直接发布
-
-在真正发布前，AI 必须把文案返回给用户确认。
-
-返回给用户时，必须同时说明：
-
-1. `manifest.json` 已改到哪个版本
-2. 是否已经提交
-3. 本次提交哈希是什么
-4. 上一个版本标签是什么
-5. 发布文案草稿是什么
-
-发布文案草稿必须放在代码块中，格式建议如下：
-
-```markdown
-## vX.Y.Z
-
-### 更新内容
- ...
- ...
-
-### 修复与优化
- ...
- ...
-```
-
-注意：
-
-1. 这里必须先停下来等用户确认。
-2. 用户没确认前，不准创建 GitHub Release。
-3. 如果用户要求改文案，只改文案，不要乱改已经完成的代码与提交，除非用户明确要求。
-
-## 阶段 5：用户确认后再发布 GitHub Release
-
-### 1. 先推送当前提交
-
-发布前先把当前分支 HEAD 推到远端：
-
-```powershell
-git push origin HEAD
-```
-
-### 2. 把用户确认过的文案写入 UTF-8 文件
-
-不要直接把长正文硬塞进命令参数里，先写入临时文件。
-
-示例：
-
-```powershell
-$ReleaseNotesFile = Join-Path $env:TEMP "codex-release-$TargetVersion.md"
-$Utf8NoBom = New-Object System.Text.UTF8Encoding($false)
-[System.IO.File]::WriteAllText($ReleaseNotesFile, $ReleaseNotes, $Utf8NoBom)
-```
-
-### 3. 创建 Release
-
-执行：
-
-```powershell
-& $GH release create $TargetTag `
-  --repo $Repo `
-  --target HEAD `
-  --title $TargetTag `
-  --notes-file $ReleaseNotesFile
-```
-
-要求：
-
-1. 标题默认使用 `vX.Y.Z`。
-2. 正文必须使用用户确认过的最终文案。
-3. 不要在用户没确认前抢先发版。
-
-## 阶段 6：发布后线上正文复检
-
-Release 创建完成后，必须立刻重新读取线上内容。
-
-执行：
-
-```powershell
-& $GH api "repos/$Repo/releases/tags/$TargetTag"
-& $GH api "repos/$Repo/releases/tags/$TargetTag" --jq '.html_url'
-& $GH api "repos/$Repo/releases/tags/$TargetTag" --jq '.tag_name'
-& $GH api "repos/$Repo/releases/tags/$TargetTag" --jq '.name'
-& $GH api "repos/$Repo/releases/tags/$TargetTag" --jq '.body'
-```
-
-复检重点：
-
-1. 线上 tag 是否真的是目标 tag
-2. 线上标题是否真的是目标版本
-3. 线上正文是否完整
-4. 正文是否与用户确认稿一致
-5. 是否存在乱码、异常字符、错误换行、空正文
-
-尤其注意下面这些异常：
-
- 出现明显乱码字符
- 中文被破坏
- 正文为空
- 版本号不对
- 正文内容被截断
-
-### 如果复检发现异常
-
-必须立刻修复，不准带病汇报完成。
-
-修复示例：
-
-```powershell
-& $GH release edit $TargetTag `
-  --repo $Repo `
-  --title $TargetTag `
-  --notes-file $ReleaseNotesFile
-```
-
-修复后，再重复执行一次“发布后线上正文复检”，直到线上内容正常为止。
-
-## 用户侧最终反馈要求
-
-AI 完成后，对用户的最终反馈至少要说明：
-
-1. 已把 `manifest.json` 更新到哪个版本
-2. 是否已经提交，提交哈希是什么
-3. 上一个版本是什么
-4. 发布文案是否经过用户确认
-5. 是否已经创建 GitHub Release
-6. 是否已经完成线上正文复检
-7. 如果没跑测试，要明确提醒用户自行测试
-
-## 一句话执行要求
-
-当用户引用本文并说“更新版本到 x.x.x”时，AI 必须按下面顺序执行：
-
-1. 真实检查工作区与当前版本
-2. 真实校验目标版本是否合法且未发布
-3. 修改 `manifest.json` 版本号
-4. 提交本次待发布改动
-5. 基于上一个正式 Release 到当前 HEAD 的真实差异分析更新内容
-6. 把发布文案放进代码块返回给用户确认
-7. 得到确认后再推送并创建 GitHub Release
-8. 发布完成后再次读取线上正文并检查是否乱码
-9. 如有异常，先修复再汇报
-
-不能跳步骤，不能猜，不能偷懒。
@@ -0,0 +1,431 @@
+# Hotmail 鍙屾ā寮忛€傞厤寮€鍙戞柟妗?
+## 1. 鑳屾櫙涓庨棶棰樺垎鏋?
+褰撳墠浠撳簱鐨?Hotmail 鎺ョ爜璺緞宸茬粡鍥為€€鍒扳€滅涓夋柟閰嶇疆鈥濈増鏈紝鏍稿績鐗圭偣鏄細
+
+- 璐﹀彿姹犵户缁娇鐢?`閭 / 瀹㈡埛绔?ID / 鍒锋柊浠ょ墝` 浣滀负鎵归噺瀵煎叆鏍煎紡
+- 鎵╁睍褰撳墠娲昏穬閫昏緫鐩存帴璇锋眰绗笁鏂?HTTP 鎺ュ彛璇诲彇閭欢
+- 渚ц竟鏍忛澶栨毚闇蹭簡 `API 鍦板潃 / 鍝嶅簲绫诲瀷 / 鏀朵欢绠卞弬鏁?/ 鍨冨溇绠卞弬鏁癭 杩欑粍鍗忚缁嗚妭閰嶇疆
+
+杩欑増铏界劧鑳藉伐浣滐紝浣嗗凡缁忔毚闇插嚭涓や釜缁撴瀯鎬ч棶棰橈細
+
+1. **杩滅▼鍗忚鍜屾湰鍦板崗璁苟涓嶄竴鑷?*
+   - `#10` 鏄繙绋嬬涓夋柟鏈嶅姟妯″紡锛屾牳蹇冩槸涓€涓浐瀹氭枃妗ｆ帴鍙?`https://apple.882263.xyz/api.html`
+   - `#42` 鏄湰鍦?helper 妯″紡锛屾牳蹇冩槸鏈湴 Python 鑴氭湰鏆撮湶 `/messages`銆乣/code` 绛夋帴鍙?   - 涓よ€呭彧鏄骇鍝佸叆鍙ｇ浉浼硷紝涓嶆槸鍚屼竴鍗忚锛屼笉鑳界‖缁熶竴鎴愪竴濂椻€滈€氱敤 API 鍙傛暟閰嶇疆鍣ㄢ€?
+2. **褰撳墠 UI 鏆撮湶浜嗚繃澶氬崗璁粏鑺?*
+   - `鍝嶅簲绫诲瀷`
+   - `鏀朵欢绠卞弬鏁癭
+   - `鍨冨溇绠卞弬鏁癭
+   - 杩欎簺瀛楁瀵硅繙绋嬫彁渚涘晢鍗忚鏉ヨ鏄浐瀹氱殑锛屽鏈湴 helper 鍗忚鏉ヨ鍙堟牴鏈笉閫傜敤
+   - 鎶婅繖浜涚粏鑺傛毚闇茬粰鏈€缁堢敤鎴凤紝浼氭妸鐣岄潰鍙樻垚鈥滄帴鍙ｈ皟璇曞櫒鈥濓紝澧炲姞閿欒閰嶇疆椋庨櫓
+
+3. **鐢ㄦ埛鐪熷疄闇€姹備笉鏄氦浜掓巿鏉冿紝鑰屾槸鎵归噺璐﹀彿姹?*
+   - 闇€瑕佺户缁敮鎸?`璐﹀彿----瀵嗙爜----瀹㈡埛绔疘D----鍒锋柊浠ょ墝`
+   - 闇€瑕佹敮鎸佸嚑鍗佷釜璐﹀彿鐨勬壒閲忓鍏ヤ笌鑷姩杞
+   - 鍥犳褰撳墠闃舵涓嶅簲鍒囧埌鈥滃井杞氦浜掓巿鏉冣€濅富璺嚎
+
+## 2. 宸查獙璇佸弬鑰冩潵婧?
+### 2.1 PR #10锛氳繙绋嬬涓夋柟鏈嶅姟妯″紡
+
+宸茬‘璁ょ壒寰侊細
+
+- 鎵╁睍鐩存帴璇锋眰杩滅▼鎺ュ彛
+- 鎺ュ彛鏂囨。宸插叕寮€锛歚https://apple.882263.xyz/api.html`
+- 鏍稿績鎺ュ彛鏄?`/api/mail-new`
+- 鎵╁睍浼犲叆锛?  - `client_id`
+  - `refresh_token`
+  - `email`
+  - `mailbox`
+  - `response_type`
+
+璁捐鐗圭偣锛?
+- 鍗忚鐢辨彁渚涘晢鍥哄畾锛屼笉鍙兘涓哄綋鍓嶉」鐩崟鐙慨鏀?- 鎵╁睍搴旇鍋氣€滃崗璁€傞厤鈥濓紝鑰屼笉鏄鐢ㄦ埛鎵嬪～涓€鍫嗗簳灞傚弬鏁?
+### 2.2 PR #42锛氭湰鍦?helper 妯″紡
+
+宸茬‘璁ょ壒寰侊細
+
+- 鎵╁睍璇锋眰鏈湴 helper锛歚http://127.0.0.1:17373`
+- helper 鑴氭湰浣嶄簬锛?  - `scripts/hotmail_helper.py`
+  - `start-hotmail-helper.bat`
+- 鎵╁睍浣跨敤鐨勬牳蹇冩帴鍙ｆ槸锛?  - `/messages`
+  - `/code`
+
+璁捐鐗圭偣锛?
+- 鎵╁睍鍜岄偖绠卞崗璁В鑰?- 鏈湴鑴氭湰鎵挎媴 token 鍒锋柊銆佸彇淇°€侀獙璇佺爜绛涢€?- 鏇撮€傚悎鏈湴鐢ㄦ埛鑷帶鐜
+
+## 3. 鏈€缁堣璁″彇鑸?
+### 3.1 鐩爣鏂规
+
+Hotmail 鍖烘敼鎴?*鍙屾ā寮忛€傞厤**锛?
+- `杩滅▼鏈嶅姟`
+- `鏈湴鍔╂墜`
+
+涓ょ妯″紡缁х画鍏辩敤鍚屼竴濂楄处鍙锋睜涓庢壒閲忓鍏ユ牸寮忥細
+
+```text
+璐﹀彿----瀵嗙爜----瀹㈡埛绔疘D----鍒锋柊浠ょ墝
+```
+
+### 3.2 涓嶉噰鐢ㄧ殑鏂规
+
+#### 涓嶉噰鐢ㄢ€滃井杞氦浜掓巿鏉冣€濅富鏂规
+
+鍘熷洜锛?
+- 涓嶉€傚悎鍑犲崄涓处鍙风殑鎵归噺浣跨敤鍦烘櫙
+- 浼氱牬鍧忕幇鏈夋壒閲忓鍏ラ摼璺?- 涓庡綋鍓嶇敤鎴烽渶姹傚啿绐?
+#### 涓嶉噰鐢ㄢ€滈€氱敤 API 鍙傛暟閰嶇疆鍣ㄢ€?
+鍘熷洜锛?
+- 杩滅▼鍗忚鍜屾湰鍦板崗璁湰灏变笉鍚?- 缁х画淇濈暀 `鍝嶅簲绫诲瀷 / 鏀朵欢绠卞弬鏁?/ 鍨冨溇绠卞弬鏁癭 浼氬鍔犻厤缃鏉傚害
+- 杩欎簺瀛楁涓嶅簲鎴愪负鏈€缁堢敤鎴风殑甯歌閰嶇疆鍏ュ彛
+
+## 4. 鐩爣浜や簰璁捐
+
+### 4.1 Hotmail 鍖虹晫闈㈢粨鏋?
+鍦ㄧ幇鏈?`Hotmail 璐﹀彿姹燻 鍖哄潡涓柊澧烇細
+
+1. `Hotmail 妯″紡` 鎸夐挳缁?   - `杩滅▼鏈嶅姟`
+   - `鏈湴鍔╂墜`
+
+2. `鏈嶅姟鍦板潃` 杈撳叆妗?   - 褰撴ā寮忎负 `杩滅▼鏈嶅姟` 鏃舵樉绀鸿繙绋嬫湇鍔″湴鍧€
+   - 褰撴ā寮忎负 `鏈湴鍔╂墜` 鏃舵樉绀烘湰鍦板姪鎵嬪湴鍧€
+
+3. 淇濈暀璐﹀彿姹犺〃鍗?   - 閭
+   - 瀹㈡埛绔?ID
+   - 閭瀵嗙爜澶囨敞
+   - 鍒锋柊浠ょ墝
+   - 娣诲姞璐﹀彿
+
+4. 淇濈暀鎵归噺瀵煎叆
+   - 浠嶇劧鏀寔 `璐﹀彿----瀵嗙爜----瀹㈡埛绔疘D----鍒锋柊浠ょ墝`
+
+5. 淇濈暀璐﹀彿鎿嶄綔
+   - 浣跨敤姝よ处鍙?   - 鏍囪宸茬敤 / 鏈敤
+   - 鏍￠獙
+   - 澶嶅埗鏈€鏂伴獙璇佺爜
+   - 鍒犻櫎
+
+### 4.2 瑕佸垹闄ょ殑鏃?UI
+
+鍒犻櫎褰撳墠绗笁鏂归厤缃噷杩欏嚑涓粏椤癸細
+
+- `Hotmail API 鍦板潃`
+- `鍝嶅簲绫诲瀷`
+- `鏀朵欢绠卞弬鏁癭
+- `鍨冨溇绠卞弬鏁癭
+
+鍘熷洜锛?
+- 杩欎簺灞炰簬鍗忚缁嗚妭锛屼笉閫傚悎鏅€氫娇鐢ㄨ€?- 鍙屾ā寮忔柟妗堥噷鍙渶瑕侀厤缃€滄湇鍔″湴鍧€鈥?
+## 5. 鍚庡彴璁捐
+
+### 5.1 鎸佷箙鍖栭厤缃」
+
+鏂板骞朵娇鐢ㄤ互涓嬫寔涔呭寲瀛楁锛?
+- `hotmailServiceMode`
+  - 鍊硷細`remote` / `local`
+- `hotmailRemoteBaseUrl`
+  - 榛樿锛氳繙绋嬫湇鍔℃枃妗ｆ墍鍦ㄥ煙鍚?- `hotmailLocalBaseUrl`
+  - 榛樿锛歚http://127.0.0.1:17373`
+
+鍒犻櫎褰撳墠浠呮湇鍔′簬绗笁鏂归€氱敤閰嶇疆鍣ㄧ殑瀛楁锛?
+- `hotmailApiUrl`
+- `hotmailApiResponseType`
+- `hotmailApiInboxMailbox`
+- `hotmailApiJunkMailbox`
+
+### 5.2 璇锋眰閫傞厤灞?
+鏂板缁熶竴鐨勬ā寮忓垎鍙戝眰锛屼絾**涓嶇粺涓€搴曞眰鍗忚**銆?
+#### 杩滅▼妯″紡
+
+鐩存帴鍏煎 PR #10 鏂囨。鍗忚锛?
+- 璋冪敤杩滅▼ `baseUrl + /api/mail-new`
+- 鎵╁睍绔繚鎸佺幇鏈夆€滄媺娑堟伅鍚庢湰鍦扮瓫楠岃瘉鐮佲€濈殑妯″紡
+
+#### 鏈湴妯″紡
+
+鐩存帴鍏煎 PR #42 helper 鍗忚锛?
+- `/messages`
+- `/code`
+
+鎵╁睍绔€昏緫锛?
+- `鏍￠獙` / `娴嬭瘯鏀朵俊` 璧?`/messages`
+- 楠岃瘉鐮佽疆璇紭鍏堣蛋 `/code`
+
+### 5.3 闇€瑕佹柊澧炴垨璋冩暣鐨勫悗鍙板嚱鏁?
+1. 閰嶇疆褰掍竴鍖?   - `normalizeHotmailServiceMode`
+   - `normalizeHotmailRemoteBaseUrl`
+   - `normalizeHotmailLocalBaseUrl`
+   - `getHotmailServiceSettings`
+
+2. 杩滅▼妯″紡閫傞厤
+   - `requestHotmailRemoteMailbox`
+   - `fetchHotmailRemoteMessages`
+
+3. 鏈湴妯″紡閫傞厤
+   - `requestHotmailLocalMessages`
+   - `requestHotmailLocalCode`
+   - `fetchHotmailLocalMessages`
+
+4. 缁熶竴鍒嗗彂鍏ュ彛
+   - `fetchHotmailMailboxMessages`
+   - `pollHotmailVerificationCode`
+   - 鏍规嵁妯″紡鍒嗘祦
+
+## 6. 鏈湴 helper 鏂囦欢绛栫暐
+
+鐩存帴寮曞叆骞堕€傞厤 PR #42 宸查獙璇佺殑鏈湴鑴氭湰鏂规锛?
+- `scripts/hotmail_helper.py`
+- `start-hotmail-helper.bat`
+
+寮曞叆鍘熷垯锛?
+- 浼樺厛淇濇寔鍗忚鍏煎锛屼笉鍋氭棤蹇呰閲嶆瀯
+- 鍙帴鍏ュ綋鍓嶆墿灞曢渶瑕佺敤鍒扮殑鎺ュ彛涓庡惎鍔ㄦ柟寮?- 涓嶅湪鏈疆鎵╁睍寮€鍙戜腑缁х画寮曞叆涓?Hotmail 妯″紡鍒囨崲鏃犲叧鐨勫ぇ瑙勬ā鐘舵€侀€昏緫
+
+## 7. 涓庣幇鏈夐€昏緫鐨勫吋瀹硅姹?
+### 7.1 蹇呴』淇濇寔涓嶅彉鐨勮涓?
+- `Mail = Hotmail` 鏃朵粛鐒剁敱璐﹀彿姹犲垎閰嶉偖绠?- `璐﹀彿----瀵嗙爜----瀹㈡埛绔疘D----鍒锋柊浠ょ墝` 鎵归噺瀵煎叆鏍煎紡蹇呴』缁х画鍙敤
+- `鏍￠獙` / `澶嶅埗鏈€鏂伴獙璇佺爜` / `Auto` 鐨勭敤鎴峰叆鍙ｄ笉鍙?- Hotmail 璐﹀彿鐨?`used / status / lastError / lastAuthAt / lastUsedAt` 閫昏緫淇濇寔鐜版湁璇箟
+
+### 7.2 蹇呴』閬垮厤鐨勯棶棰?
+- 涓嶈兘鎶婅繙绋嬪拰鏈湴寮鸿鎶芥垚涓€濂楀亣缁熶竴鍗忚
+- 涓嶈兘鎶婄涓夋柟鏈嶅姟瑕佹眰鏀规垚 `/messages` `/code`
+- 涓嶈兘鍒犻櫎鎵归噺瀵煎叆 refresh token 鐨勮兘鍔?- 涓嶈兘鍙敼 UI锛屼笉鎺ュ悗鍙板垎鍙?- 涓嶈兘鍙帴鍚庡彴锛屼笉鍚屾 README 涓庤鏄?
+## 8. 鏂规鑷涓庡畬鏁存€у垎鏋?
+### 8.1 鏂规鏄惁绗﹀悎闇€姹?
+绗﹀悎銆?
+鍘熷洜锛?
+- 淇濈暀鎵归噺瀵煎叆
+- 涓嶅己杩敤鎴疯蛋寰蒋浜や簰鎺堟潈
+- 鍚屾椂鏀寔宸查獙璇佺殑杩滅▼涓庢湰鍦颁袱绉嶈矾寰?
+### 8.2 鏂规鏄惁瀹屾暣
+
+瀹屾暣銆?
+宸茬粡瑕嗙洊锛?
+- 閰嶇疆妯″瀷
+- 鐣岄潰鍙樻洿
+- 鍚庡彴鍒嗗彂
+- helper 寮曞叆
+- 鏂囨。鏇存柊
+- 鑷椤?
+### 8.3 鏂规鏄惁瀛樺湪鍐呴儴鍐茬獊
+
+褰撳墠鏃犳槑鏄惧啿绐併€?
+鍞竴闇€瑕佷弗鏍兼帶鍒剁殑鏄細
+
+- 杩滅▼妯″紡涓庢湰鍦版ā寮忚櫧鐒跺叆鍙ｇ粺涓€锛屼絾鍗忚涓嶈兘娣风敤
+- 瀹炵幇鏃跺繀椤绘槑纭垎灞傦紝涓嶈鍋氭垚鈥滄牴鎹厤缃嫾涓嶅悓 query 鍙傛暟鈥濈殑鏉傜硡閫昏緫
+
+### 8.4 鏂规娼滃湪缂洪櫡
+
+1. 鏈湴 helper 鍙兘渚濊禆 Python 鐜
+   - 闇€瑕佸湪 README 涓槑纭鏄庡浣曞惎鍔?
+2. 杩滅▼鏈嶅姟鏂囨。鑻ユ湭鏉ュ彉鏇?   - 褰撳墠浠嶄緷璧栨湇鍔″晢鎺ュ彛绋冲畾鎬?
+3. 褰撳墠浠撳簱鏄棫椤圭洰
+   - Hotmail 閫昏緫鍛ㄨ竟宸叉湁杈冨鐘舵€佸瓧娈?   - 瀹炵幇鏃跺繀椤昏皑鎱庢鏌?`verify/test/poll/auto-run` 鍥涙潯閾炬槸鍚︾粺涓€鎸夋ā寮忓垎鍙?
+## 9. 寮€鍙戞竻鍗?
+### 闃舵 1锛氶厤缃ā鍨嬩笌鏂规钀界洏
+
+- 鏂板缓鏈柟妗堟枃妗?- 鏂板 Hotmail 鍙屾ā寮忔寔涔呭寲瀛楁
+- 鍒犻櫎鏃х殑绗笁鏂瑰崗璁粏椤瑰瓧娈?
+鑷锛?
+- 閰嶇疆椤瑰懡鍚嶆槸鍚︾粺涓€
+- 榛樿鍊兼槸鍚﹀畬鏁?- import/export 鏄惁浠嶅彲宸ヤ綔
+
+### 闃舵 2锛欻otmail UI 鏀归€?
+- 鏂板 `杩滅▼鏈嶅姟 / 鏈湴鍔╂墜` 妯″紡鎸夐挳
+- 鏂板 `鏈嶅姟鍦板潃` 杈撳叆妗?- 鍒犻櫎鏃х殑 `鍝嶅簲绫诲瀷 / 鏀朵欢绠卞弬鏁?/ 鍨冨溇绠卞弬鏁癭 杈撳叆妗?- 淇濈暀璐﹀彿姹犺〃鍗曚笌鎵归噺瀵煎叆
+
+鑷锛?
+- 鍒囨崲妯″紡鍚庢樉绀烘槸鍚︽纭?- 鑷姩淇濆瓨鏄惁浠嶆甯?- 涓嶅悓妯″紡鐨勫湴鍧€鏄惁涓嶄細浜掔浉瑕嗙洊
+
+### 闃舵 3锛氬悗鍙板弻妯″紡閫傞厤
+
+- 瀹炵幇杩滅▼妯″紡璇锋眰閫傞厤
+- 瀹炵幇鏈湴妯″紡 helper 璇锋眰閫傞厤
+- 淇敼 `fetchHotmailMailboxMessages`
+- 淇敼 `pollHotmailVerificationCode`
+- 鏍￠獙 `verify / test / auto-run` 涓夋潯閾?
+鑷锛?
+- 杩滅▼妯″紡鏄惁浠嶅吋瀹?`#10`
+- 鏈湴妯″紡鏄惁鍏煎 `#42`
+- 閿欒淇℃伅鏄惁浠嶄細鍐欏洖 `lastError`
+
+### 闃舵 4锛氬紩鍏ユ湰鍦?helper
+
+- 寮曞叆 `scripts/hotmail_helper.py`
+- 寮曞叆 `start-hotmail-helper.bat`
+- 妫€鏌ユ湰鍦板崗璁笌鎵╁睍璋冪敤涓€鑷?
+鑷锛?
+- helper 璺緞鏄惁姝ｇ‘
+- 绔彛涓庢枃妗ｆ槸鍚︿竴鑷?- 鎵╁睍璇锋眰璺緞鏄惁鍖归厤 helper
+
+### 闃舵 5锛氭枃妗ｆ敹灏?
+- 鏇存柊 README 涓?Hotmail 浣跨敤璇存槑
+- 鏄庣‘杩滅▼妯″紡涓庢湰鍦版ā寮忕殑鍖哄埆
+- 鏄庣‘鏈湴 helper 鍚姩鏂瑰紡
+
+鑷锛?
+- README 鏄惁鍜岀湡瀹?UI 涓€鑷?- 鐢ㄦ埛鏄惁鑳界湅鏂囨。瀹屾垚閰嶇疆
+
+## 10. 瀹炴柦椤哄簭
+
+鏈疆寮€鍙戜弗鏍兼寜浠ヤ笅椤哄簭鎵ц锛?
+1. 鍏堝啓鏈柟妗堟枃妗?2. 鍐嶆敼閰嶇疆妯″瀷
+3. 鍐嶆敼 UI
+4. 鍐嶆敼鍚庡彴鍙屾ā寮忓垎鍙?5. 鍐嶅紩鍏ユ湰鍦?helper
+6. 鏈€鍚庣粺涓€鍋氶潤鎬佽嚜妫€骞舵彁閱掔敤鎴锋墜娴?
+## 11. 瀹為檯寮€鍙戣褰?
+### 11.1 宸插畬鎴愭敼鍔?
+鏈疆宸插疄闄呭畬鎴愪互涓嬪紑鍙戝唴瀹癸細
+
+1. Hotmail 閰嶇疆妯″瀷浠庘€滅涓夋柟閫氱敤缁嗛」閰嶇疆鈥濆垏鎹负鈥滃弻妯″紡 + 鍦板潃閰嶇疆鈥?   - 鍒犻櫎鍘熸湰闈㈠悜绗笁鏂圭粏椤圭殑鎬濊矾锛?     - `hotmailApiUrl`
+     - `hotmailApiResponseType`
+     - `hotmailApiInboxMailbox`
+     - `hotmailApiJunkMailbox`
+   - 鏀逛负锛?     - `hotmailServiceMode`
+     - `hotmailRemoteBaseUrl`
+     - `hotmailLocalBaseUrl`
+
+2. Sidepanel Hotmail 鍖哄凡鏀归€犳垚鍙屾ā寮?UI
+   - 鏂板 `杩滅▼鏈嶅姟 / 鏈湴鍔╂墜` 鎸夐挳缁?   - 鏂板杩滅▼鏈嶅姟鍦板潃杈撳叆妗?   - 鏂板鏈湴鍔╂墜鍦板潃杈撳叆妗?   - 淇濈暀鍘熸湁璐﹀彿姹犺〃鍗曞拰鎵归噺瀵煎叆鏍煎紡
+
+3. 鍚庡彴 Hotmail 璇锋眰閾惧凡鎸夋ā寮忓垎娴?   - 杩滅▼妯″紡锛?     - 鐩存帴鍏煎 `#10`
+     - 浣跨敤 `baseUrl + /api/mail-new`
+   - 鏈湴妯″紡锛?     - 鐩存帴鍏煎 `#42`
+     - 浣跨敤 `/messages`
+     - 浣跨敤 `/code`
+
+4. 鏈湴 helper 鏂囦欢宸茶惤鍦?   - `scripts/hotmail_helper.py`
+   - `start-hotmail-helper.bat`
+
+5. README 宸插悓姝ユ洿鏂颁负鍙屾ā寮忚鏄?
+### 11.2 瀹為檯淇敼鏂囦欢
+
+鏈疆瀹為檯鏀瑰姩鏂囦欢濡備笅锛?
+- `background.js`
+- `sidepanel/sidepanel.html`
+- `sidepanel/sidepanel.js`
+- `README.md`
+- `scripts/hotmail_helper.py`
+- `start-hotmail-helper.bat`
+
+鏈疆鏂板浣嗕笉涓€瀹氳繘鍏?Git 鐨勬枃妗ｏ細
+
+- `docs/md/Hotmail鍙屾ā寮忛€傞厤寮€鍙戞柟妗?md`
+
+### 11.3 瀹為檯瀹炵幇涓庡師鏂规鐨勫樊寮?
+褰撳墠瀹炵幇涓庡師鏂规鐩告瘮锛屽瓨鍦ㄨ繖浜涘疄闄呭樊寮傦細
+
+1. 鏈湴 helper 娌℃湁鏁翠唤鐓ф惉 `#42`
+   - 褰撳墠鏄寜 `#42` 鐨勫崗璁€濊矾钀戒簡涓€涓畝鍖栫増
+   - 鐩爣鏄厛婊¤冻鎵╁睍鐜伴樁娈电殑 `/messages` 涓?`/code`
+   - 娌℃湁缁х画寮曞叆 `#42` 閲屾洿閲嶇殑澶辫触鐘舵€併€佹寔涔呭凡鐢ㄩ偖绠便€佸苟鍙戜繚鎶ょ瓑鏁村鎵╁睍閫昏緫
+
+2. 杩滅▼妯″紡鐩墠浠嶆部鐢ㄦ墿灞曠鏈湴绛涢獙璇佺爜
+   - 鍏煎 `#10` 鐨勫崟鎺ュ彛 `/api/mail-new`
+   - 鏈澶栧鎺?`mail-all`銆乣process-inbox`銆乣process-junk`
+
+3. 娴嬭瘯鏂囦欢鏈疆娌℃湁缁х画琛ラ綈
+   - 褰撳墠涓昏瀹屾垚鐨勬槸鏂规钀藉湴鍜屼富閾炬敼閫?   - 灏氭湭琛ラ拡瀵瑰弻妯″紡鐨勬渶灏忓洖褰掓祴璇曟々
+
+### 11.4 褰撳墠宸茬煡鏈畬鎴愰」
+
+浠ヤ笅鍐呭褰撳墠浠嶆湭瀹屾垚鎴栨湭楠岃瘉锛?
+1. 鏈ˉ Hotmail 鍙屾ā寮忓搴旂殑娴嬭瘯妗?   - 杩滅▼妯″紡楠岃瘉閫昏緫
+   - 鏈湴妯″紡 `/messages` 涓?`/code` 鍒嗗彂閫昏緫
+   - 妯″紡鍒囨崲鍚庣殑 UI 鐘舵€佸洖濉?
+2. 鏈 helper 鍋氳繍琛岀骇瀹炴祴
+   - 褰撳墠鍙畬鎴愪唬鐮佹帴鍏?   - 灏氭湭纭鏈満 Python 鐜涓?`imaplib + XOAUTH2 + login.live.com/oauth20_token.srf` 鏄惁鑳界ǔ瀹氬伐浣?
+3. 鏈獙璇佽繙绋嬫湇鍔″湴鍧€鐨勪笉鍚岃緭鍏ュ舰寮?   - 渚嬪鐢ㄦ埛濉細
+     - 鏍瑰煙鍚?     - `/api.html`
+     - `/api/mail-new`
+   - 鐩墠浠ｇ爜鍋氫簡璺緞褰掍竴鍖栵紝浣嗛渶瑕佷汉宸ユ墜娴嬬‘璁?
+4. 鏈ˉ README 涓洿缁嗙殑鏈湴 helper 鍚姩鎺掗敊璇存槑
+   - 褰撳墠鍙啓浜嗗叆鍙ｈ鏄?   - 杩樻病鍐欌€滃惎鍔ㄥけ璐ユ€庝箞鐪嬨€佺鍙ｅ崰鐢ㄦ€庝箞鍔炪€丳ython 涓嶅瓨鍦ㄦ€庝箞鍔炩€?
+### 11.5 褰撳墠鎵嬫祴閲嶇偣
+
+鍚庣画浼樺厛鎵嬫祴浠ヤ笅鍐呭锛?
+1. 杩滅▼妯″紡
+   - `Mail = Hotmail`
+   - 妯″紡鍒囧埌 `杩滅▼鏈嶅姟`
+   - 鍦板潃濉?`https://apple.882263.xyz`
+   - 娴嬶細
+     - `鏍￠獙`
+     - `澶嶅埗鏈€鏂伴獙璇佺爜`
+     - `Auto`
+
+2. 鏈湴妯″紡
+   - 鍏堣繍琛?`start-hotmail-helper.bat`
+   - 妯″紡鍒囧埌 `鏈湴鍔╂墜`
+   - 鍦板潃淇濇寔 `http://127.0.0.1:17373`
+   - 娴嬶細
+     - `鏍￠獙`
+     - `澶嶅埗鏈€鏂伴獙璇佺爜`
+     - `Auto`
+
+3. 妯″紡鍒囨崲
+   - 浠?`杩滅▼鏈嶅姟` 鍒囧埌 `鏈湴鍔╂墜`
+   - 浠?`鏈湴鍔╂墜` 鍒囧埌 `杩滅▼鏈嶅姟`
+   - 鐪嬪湴鍧€鏄惁鍒嗗埆淇濈暀
+   - 鐪?Hotmail 璐﹀彿姹犳槸鍚︿笉鍙楀奖鍝?
+4. 鎵归噺瀵煎叆
+   - 瀵煎叆鏍煎紡锛?     - `璐﹀彿----瀵嗙爜----瀹㈡埛绔疘D----鍒锋柊浠ょ墝`
+   - 妫€鏌ユā寮忓垏鎹㈠悗瀵煎叆鑳藉姏鏄惁浠嶆甯?
+### 11.6 褰撳墠椋庨櫓缁撹
+
+褰撳墠鏈€澶ч闄╀笉鍦?UI锛岃€屽湪杩欎袱涓偣锛?
+1. 鏈湴 helper 鐨勭湡瀹炲彲杩愯鎬?   - 浠ｇ爜宸茬粡鎺ヤ笂
+   - 浣嗘湭缁忓疄闄呰繍琛岄獙璇?
+2. 杩滅▼涓庢湰鍦扮殑杩斿洖缁撴瀯鍏煎鎬?   - 杩滅▼妯″紡璧?`#10` 椋庢牸
+   - 鏈湴妯″紡璧?`#42` 椋庢牸
+   - 铏界劧鍚庡彴宸茬粡鍋氫簡閫傞厤锛屼絾浠嶉渶瑕佸疄闄呰繑鍥炴牱鏈獙璇?
+### 11.7 褰撳墠闃舵缁撹
+
+褰撳墠鐘舵€佸彲浠ョ悊瑙ｄ负锛?
+- 鏂规宸茶惤鐩?- 鍙屾ā寮忎富缁撴瀯宸插紑鍙戝畬鎴?- 杩滅▼ / 鏈湴涓ゆ潯鍗忚宸叉帴鍏?- 璐﹀彿姹犱笌鎵归噺瀵煎叆浠嶄繚鐣?- 浣嗗皻鏈粡杩囩湡瀹炶繍琛岄獙璇?
+鍥犳鏈疆寮€鍙戠粨鏋滃睘浜庯細
+
+- **浠ｇ爜缁撴瀯宸插埌浣?*
+- **杩愯绋冲畾鎬у緟浜哄伐楠岃瘉**
+
+## 12. 本地 helper 运行说明补充
+
+### 12.1 启动命令
+
+Windows：
+
+```powershell
+.\start-hotmail-helper.bat
+```
+
+macOS：
+
+```bash
+chmod +x ./start-hotmail-helper.command
+./start-hotmail-helper.command
+```
+
+如果不使用启动脚本，也可以直接运行：
+
+```bash
+python scripts/hotmail_helper.py
+```
+
+或：
+
+```bash
+python3 scripts/hotmail_helper.py
+```
+
+### 12.2 启动成功标志
+
+启动成功后，终端应输出：
+
+```text
+Hotmail helper listening on http://127.0.0.1:17373
+```
+
+### 12.3 最小排错说明
+
+- 若提示 `Python 3 not found`，说明当前机器没有可用的 Python 3.10+。
+- 若 helper 已启动但扩展仍连不上，先确认 Hotmail 模式切到了 `本地助手`。
+- 再确认侧边栏中的本地助手地址与终端输出一致，默认应为 `http://127.0.0.1:17373`。
+- 若地址一致仍失败，再检查终端中是否已经打印异常，或是否有端口占用。
@@ -0,0 +1,301 @@
+# 仓库协作者用 AI 分析 PR 与合并标准流程
+
+## 用途
+
+本文件用于给仓库协作者自己电脑上的 AI 一个固定、完整、可重复执行的 PR 处理流程。
+
+下次只要告诉 AI：
+
+- 本仓库根目录
+- 要处理的 PR 编号
+- 是否只分析，还是分析后需要继续合并
+
+再把本文件提供给 AI，AI 就必须按本文件执行，不能自行脑补流程。
+
+## 仓库硬性规则
+
+1. 任何结论都不能猜，必须基于真实命令输出、真实 diff、真实代码上下文。
+2. 优先使用当前环境可直接执行的 `gh`、`git` 命令；如果命令不存在、认证失败、权限不足，必须立刻明确告知用户并停止，不能假装已经操作成功。
+3. 本仓库自动处理的唯一目标分支是 `dev`。AI 不得把其他作者的 PR 直接作为自动流程合并到 `master`。
+4. 任何分支判断都必须以实时 `gh pr view` 返回的 `baseRefName` 为准，不能只信用户口述、PR 标题或截图描述。
+5. 如果 PR 当前目标分支是 `master`，AI 必须先自动把它改到 `dev`，然后重新拉取 PR 元数据与 diff，再继续分析。
+6. 如果 PR 当前目标分支既不是 `dev` 也不是 `master`，AI 不得擅自改到别的分支，必须停止并告诉用户当前自动流程只支持 `dev`。
+7. 如果把 `master` 转到 `dev` 时发现同一个来源仓库 + 来源分支已经存在另一个指向 `dev` 的打开 PR，AI 不得继续硬转，不得继续自动合并，必须先反馈重复 PR 问题。
+8. 用户当前工作区可能是脏的，不能直接在当前工作区切分支、切换分支、硬合并。需要使用临时 `worktree`。
+9. 如果合并后需要本地修复，优先删除无用旧逻辑，避免继续堆积陈旧代码。
+10. 默认不编译测试。处理完成后提醒用户自行测试。
+11. 任何 GitHub 评论、回复、感谢留言发出后，AI 都必须立即再读一遍线上实际内容，确认正文不是乱码、不是 `?`、不是编码异常；如果发现异常，必须立刻修正后再继续后续流程。
+12. 如果流程执行过程中，PR 的实时目标分支被别人改掉，或者不再是 `dev`，AI 必须停止当前合并流程，重新拉取信息后再决定下一步。
+
+## 输入要求
+
+AI 至少要拿到下面这些输入：
+
+- `PR 编号`
+- `仓库路径`
+- 本次目标：`只分析` / `分析后需要继续合并`
+- 如果需要继续合并：是否允许 AI 直接本地修复冲突和问题
+
+补充要求：
+
+- 如果 AI 不能从当前仓库自动识别 `OWNER/REPO`，则用户还需要补充提供。
+- 本流程默认允许 AI 在检测到 `master` 为目标分支时，直接远程改成 `dev`；如果用户明确禁止任何远程修改，则本流程不适用。
+
+## 总流程
+
+### 阶段 1：准备、目标分支校正与信息拉取
+
+AI 必须先执行下面这些动作，不能跳步：
+
+1. 检查当前仓库状态：
+   - `git status --short --branch`
+   - `git remote -v`
+2. 拉取 PR 元数据：
+
+```powershell
+gh pr view <PR_NUMBER> --repo <OWNER/REPO> --json number,title,body,author,baseRefName,headRefName,headRepository,headRepositoryOwner,changedFiles,additions,deletions,commits,files,isDraft,mergeStateStatus,mergeable,state,url
+```
+
+3. 先根据实时 `baseRefName` 处理目标分支：
+   - 如果 `baseRefName = dev`：继续下一步。
+   - 如果 `baseRefName = master`：先执行“自动转到 `dev`”流程，再继续下一步。
+   - 如果 `baseRefName` 既不是 `dev` 也不是 `master`：立即停止，并向用户反馈“当前自动流程只支持 `dev`”。
+
+4. 当 `baseRefName = master` 时，必须执行下面的自动转分支流程：
+
+```powershell
+gh api --method GET repos/<OWNER/REPO>/pulls -f state=open -f head='<HEAD_OWNER>:<HEAD_REF>' -f base='dev' -f per_page='100'
+```
+
+处理规则：
+
+1. 先从上一步 PR 元数据中读取真实的 `HEAD_OWNER` 与 `HEAD_REF`，不能猜。
+2. 如果查询结果中已经存在 `number != <PR_NUMBER>` 的打开 PR，则视为“重复的 dev PR”：
+   - 不再执行转分支
+   - 不再继续自动分析旧 diff
+   - 先反馈给当前用户，必要时再给 PR 留言说明
+3. 如果不存在重复的 dev PR，则执行：
+
+```powershell
+gh pr edit <PR_NUMBER> --base dev --repo <OWNER/REPO>
+```
+
+4. 改完目标分支后，必须重新执行一次 PR 元数据拉取，确认新的 `baseRefName = dev`。
+5. 在重新确认 `baseRefName = dev` 之前，不允许继续分析旧 diff，不允许继续合并。
+
+5. 只有在目标分支已经确认是 `dev` 后，才能拉取 PR diff：
+
+```powershell
+gh pr diff <PR_NUMBER> --repo <OWNER/REPO>
+```
+
+6. 拉取目标分支与 PR 头：
+
+```powershell
+git fetch origin dev
+git fetch origin pull/<PR_NUMBER>/head:refs/remotes/origin/pr-<PR_NUMBER>
+```
+
+7. 如果需要稳定查看行号、文件内容、避免污染当前工作区，创建临时 `worktree`：
+
+```powershell
+$TempWorktree = '<临时目录>'
+git worktree add --detach $TempWorktree origin/pr-<PR_NUMBER>
+```
+
+### 阶段 2：分析与审查
+
+AI 分析时，必须完整执行下面这些要求：
+
+1. 不能只看 PR 描述，必须结合真实 diff 和仓库现有代码上下文一起分析。
+2. 如果阶段 1 发生过 `master -> dev` 自动转向，分析时只能基于转向后的最新 diff，不得继续引用转向前的 diff 结论。
+3. 对于高风险文件，必须继续读取改动函数周边逻辑，确认消息流、状态流、配置项、回调流程、页面跳转流程是否一致。
+4. 必须分析并输出：
+   - 这个 PR 改了什么
+   - 这些改动是否合理
+   - 是否存在 bug / 风险 / 逻辑冲突
+   - PR 当前是否可直接合并，例如 `mergeable`、`mergeStateStatus`
+5. 如果发现问题，结论必须按严重级别排序，优先写真正会影响功能、合并或后续维护的问题。
+6. 如果没有发现明确问题，也要说明剩余风险，例如：
+   - 未运行测试
+   - 需要人工验证真实业务接口
+   - 当前仅完成静态分析
+7. 在准备进入后续合并步骤前，必须再拉取一次实时 PR 元数据，确认：
+   - PR 仍然是打开状态
+   - PR 不是 draft
+   - `baseRefName` 仍然是 `dev`
+
+## 分析后评论规则
+
+### 有问题时
+
+如果发现需要作者或维护者注意的问题，AI 必须自动发 PR 评论，并且评论格式必须固定如下：
+
+```text
+（自动回复）AI分析结果（不一定完全正确，请仓库协作者确认无问题后再继续）：
+
+<这里写正式评论内容>
+```
+
+要求：
+
+1. 第一行必须完全使用上面的标题，不能改字。
+2. 标题下方必须空一行，再写正文。
+3. 正文内容要直接写问题，不要再套娃解释“下面是分析结果”。
+4. 评论内容必须基于实际检查到的问题，不能编。
+5. 评论发出后，必须立刻回读该评论的线上正文，确认不是乱码；如果有乱码，必须先修正评论，再继续后续动作。
+
+### 没问题时
+
+如果没有发现明确问题：
+
+1. 先把分析结果反馈给当前用户。
+2. 不强制给 PR 留问题评论。
+3. 是否继续合并，取决于用户命令。
+
+## 带问题继续合并的规则
+
+如果 PR 有问题，但用户明确要求：
+
+- 不等待 PR 作者修复
+- 由当前 AI 直接本地处理冲突和问题
+- 处理完成后继续合并
+
+则必须进入下面的流程。
+
+### 阶段 3：临时工作区合并
+
+禁止在用户当前工作区直接乱合并。
+
+必须先创建临时 `worktree`，再在临时目录内处理：
+
+```powershell
+git fetch origin dev
+git fetch origin pull/<PR_NUMBER>/head:refs/remotes/origin/pr-<PR_NUMBER>
+git worktree add <TEMP_WORKTREE> -b pr-<PR_NUMBER>-merge origin/dev
+```
+
+进入临时目录后再执行：
+
+```powershell
+git merge --no-ff --no-commit origin/pr-<PR_NUMBER>
+```
+
+处理规则：
+
+1. 如果阶段 1 发生过 `master -> dev` 自动转向，本阶段必须以 `dev` 为唯一合并基准，不允许再回到 `master` 做本地吸收。
+2. 如果出现冲突，先解决冲突，再继续检查相关联逻辑。
+3. 不能只消掉冲突标记就结束，必须继续看是否有设计冲突、状态字段不一致、调用链断裂、配置项名不一致、回调逻辑互相打架的问题。
+4. 如果 PR 本身逻辑有 bug，而用户又明确要求继续合并，AI 需要直接在本地修正。
+5. 修正时要清理无用旧代码，避免留下史山。
+6. 如果改了 SQL，按仓库规则同步本地 MySQL `xzs`。
+
+### 阶段 4：本地修复后的自检清单
+
+完成临时合并与本地修复后，必须自检下面这些项目：
+
+1. `git status` 中不能再有未处理冲突。
+2. 相关文件中不能残留冲突标记。
+3. 新旧逻辑之间不能出现字段名、消息名、步骤编号、状态名不一致。
+4. 需要检查与本次功能直接相关的上下游代码，不能只改当前冲突文件。
+5. 要重新查看最终 diff，确认本地修复没有引入明显回归。
+6. 要重新拉取一次实时 PR 元数据，确认该 PR 的 `baseRefName` 仍然是 `dev`；如果不是，停止后续合并并先反馈用户。
+7. 默认不编译测试，最后提醒用户自行测试。
+
+## 合并提交信息规则
+
+如果最后决定真正合并，提交信息不能直接写：
+
+- `merge branch xxx`
+- `merge pr #19`
+- `合并某某分支`
+
+必须重新分析“最终合并结果到底做了什么”，然后重写提交信息。
+
+### 提交信息要求
+
+1. 标题必须描述最终落地功能，不是描述 Git 动作。
+2. 标题要体现核心改动结果，而不是“从哪里合并过来”。
+3. 正文要写清楚：
+   - 这次吸收了 PR 的什么内容
+   - 本地额外修复了什么冲突或 bug
+   - 对哪些关键流程做了调整
+
+### 推荐格式
+
+```text
+<type>: <最终功能或修复结果>
+
+- 合并 PR #<PR_NUMBER> 的核心改动：<一句话概括>
+- 本地补充修复：<一句话概括>
+- 影响范围：<步骤/模块/页面/接口>
+```
+
+### 示例
+
+```text
+feat: support SUB2API mode for OAuth generation and callback handling
+
+- 合并 PR #19 的核心改动：新增 SUB2API 模式并接入 OAuth 生成与回调提交流程
+- 本地补充修复：修正回调地址约束与超时重试带来的重复执行风险
+- 影响范围：background orchestration、sidepanel config、sub2api content script
+```
+
+## 最终合并与收尾
+
+如果本地已经解决该 PR 的内容，并且最终代码已经进入 `dev` 分支，则继续执行下面动作。
+
+### 1. 感谢作者
+
+此时需要自动给 PR 留一条感谢评论。
+
+注意：
+
+1. 感谢评论不要带问题评论的固定标题。
+2. 直接正常感谢即可。
+3. 感谢内容要基于真实贡献，语气简洁。
+4. 如果阶段 1 发生过 `master -> dev` 自动转向，感谢评论不能把最终落地分支写错，必须明确本次内容已吸收到 `dev`。
+5. 感谢评论发出后，也必须立刻回读线上正文，确认不是乱码；如果有乱码，必须先修正评论，再进行关闭 PR 等后续动作。
+
+示例：
+
+```text
+感谢贡献这次改动，核心思路和主体实现已经吸收进 dev 分支了。我这边补了一下合并过程里的冲突和相关修正，后续如果你还有类似改进也欢迎继续提交。
+```
+
+### 2. 自动关闭 PR
+
+如果 PR 还没有因为合并而自动关闭，则感谢评论发完后，自动关闭该 PR：
+
+```powershell
+gh pr close <PR_NUMBER> --repo <OWNER/REPO>
+```
+
+如果需要，先评论再关闭，不要把感谢遗漏掉。
+
+### 3. 评论编码复检
+
+无论是问题评论、感谢评论，还是其他直接发到 GitHub 的回复，只要消息已经发出，AI 必须执行一次“发送后复检”：
+
+1. 重新读取该评论/回复在线上的实际正文。
+2. 检查是否存在乱码、异常问号、编码错乱、BOM 污染等问题。
+3. 如果有问题，必须立即编辑修正，直到线上正文正常为止。
+4. 编码复检完成前，不允许声称“评论已发送完成”。
+
+## 用户侧最终反馈要求
+
+AI 在对当前用户做最终反馈时，至少要说明：
+
+1. 做了哪些真实动作
+2. PR 原始目标分支是否是 `master`
+3. 是否已经执行 `master -> dev` 自动转向
+4. 是否发现重复的 `dev` PR
+5. 是否发现问题
+6. 是否已经发了 PR 评论
+7. 是否已经本地合并并修复
+8. 是否已经关闭 PR
+9. 如果改了代码但没跑测试，要明确提醒用户测试
+
+## 给 AI 的一句话执行要求
+
+拿到本文件后，AI 必须按“先真实读取 PR 元数据，先校正目标分支，再拉取最新 diff 做分析，再按用户要求决定是否进入临时合并修复，最后重写提交信息并在完成后感谢作者、关闭 PR”的顺序执行，不能跳步，不能猜，不能偷懒。