Merge branch 'QLHazyCoder:master' into codex-luckmail

docs/AI版本发布标准流程.md

@@ -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. 如有异常，先修复再汇报
-
-不能跳步骤，不能猜，不能偷懒。

docs/仓库协作者AI分析PR与合并标准流程.md

@@ -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”的顺序执行，不能跳步，不能猜，不能偷懒。

开发者AI开发与PR流程.md

@@ -0,0 +1,372 @@
+# 开发者 AI 开发与 PR 流程
+
+请开发者们先让自己的 AI 阅读此文件。
+
+AI 在本仓库里进行开发、整理改动、发起 PR、更新 PR、补充说明时，都必须按本文执行，不能跳步，不能猜，不能自创流程。
+
+本文面向“开发者自己电脑上的 AI”，不是给仓库维护者批量处理别人 PR 用的，也不是版本发布流程。
+
+## 使用前准备
+
+在让 AI 操作 GitHub 之前，开发者本机必须先安装 GitHub CLI，并完成登录。
+
+最低要求：
+
+1. 本机已安装 `git`
+2. 本机已安装 GitHub CLI，也就是 `gh`
+3. 已完成 GitHub 登录
+4. 当前账号对目标仓库至少有读取权限；如果要推分支、改 PR、合并 PR，还需要对应写权限
+
+登录示例：
+
+```powershell
+gh auth login
+```
+
+如果 AI 检查到 `gh` 不可用，或者 `gh auth status` 显示未登录、登录到错误账号、权限不足，则必须先停止并明确告诉开发者，不准假装已经完成 GitHub 操作。
+
+## 本文适用场景
+
+适用于下面这些任务：
+
+- 开发新功能
+- 修复 bug
+- 清理陈旧逻辑
+- 整理本地提交
+- 发起新的 PR
+- 更新已有 PR
+- 在自己的 PR 下补充说明
+- 在权限允许时，把自己的 PR 合并到 `dev`
+
+不适用于：
+
+- 版本发布
+- 直接把代码合并到 `master`
+- 在没看代码上下文的前提下，靠猜测生成 PR 结论
+
+## 仓库硬性规则
+
+1. 任何结论都不能猜，必须基于真实命令输出、真实 diff、真实代码上下文。
+2. 开发基线分支只能是 `dev`。AI 不得以 `master` 作为日常开发起点，也不得把 PR 目标分支设为 `master`。
+3. 发起 PR 前，必须先同步最新远端提交，确保当前分支已经对齐最新 `origin/dev`。
+4. 如果发现当前 PR 的目标分支是 `master`，AI 必须立刻改为 `dev`，然后重新检查 PR 信息。
+5. 如果当前工作区有无法确认归属的脏改动，AI 必须先停下来告诉开发者，不能偷偷带进本次 PR，也不能擅自删除。
+6. 开发新功能时，不要为了兼容旧逻辑而保留明显无用的陈旧代码；如果确认无其他代码依赖，应一并清理。
+7. 如果旧逻辑本身设计差、实现混乱或者存在 bug，AI 需要继续检查相关调用点；在不影响其他功能的前提下，可以顺手一起修正。
+8. 如果改动了 SQL 文件，必须按仓库规则同步本地 MySQL：账号 `root`，密码 `123456`，数据库 `xzs`。
+9. 默认不编译、不跑测试。开发完成后提醒开发者自行测试。
+10. 如果是前端改动且没有新增依赖，只提醒开发者自己测试即可；如果新增了依赖并完成安装，可以自行验证能否启动，验证后要关闭启动占用的端口，并提醒开发者重新启动。
+11. PR 标题、PR 正文、PR 评论都用自然中文直接表达，不要写“自动回复”“AI 分析结果如下”这种固定机器人腔。
+12. 没有开发者明确授权时，AI 不得擅自合并 PR、关闭 PR、删除远端分支。
+
+## 开发者需要提供给 AI 的信息
+
+至少提供下面这些内容：
+
+- 仓库本地路径
+- 本次要做的功能或问题描述
+- 是新任务，还是继续一个已有分支/已有 PR
+- 如果已经有 PR，要提供 PR 编号
+- 是否允许 AI 在自己的功能分支上执行 `rebase`
+- 是否允许 AI 在最后直接发起 PR
+- 如果 PR 已经审完，是否允许 AI 直接合并到 `dev`
+
+如果这些关键信息缺失，AI 不能靠猜来补。
+
+## 标准执行顺序
+
+### 阶段 1：环境确认与仓库现状检查
+
+AI 开始干活前，先执行下面这些动作：
+
+```powershell
+gh --version
+gh auth status
+git status --short --branch
+git remote -v
+git branch --show-current
+git fetch origin
+```
+
+要求：
+
+1. 必须先确认 `gh` 可用且已登录。
+2. 必须确认当前仓库远端是正确仓库。
+3. 必须确认当前工作区是否有未提交改动。
+4. 不能在没看当前分支状态的情况下直接开始写代码或直接发 PR。
+
+### 阶段 2：先对齐最新 `dev`
+
+#### 场景 A：这是一个新任务
+
+如果是新任务，还没开始写代码，则必须先同步最新 `dev`：
+
+```powershell
+git switch dev
+git pull --ff-only origin dev
+git switch -c <feature-branch>
+```
+
+规则：
+
+1. 新任务必须从最新 `dev` 拉出功能分支。
+2. 不允许直接在 `dev` 上开发。
+3. 不允许从 `master` 拉开发分支。
+
+#### 场景 B：这是一个已有分支上的继续开发
+
+如果开发已经在某个功能分支上进行，则不能为了同步 `dev` 直接丢本地改动。
+
+这时至少要先执行：
+
+```powershell
+git fetch origin
+git rev-list --left-right --count origin/dev...HEAD
+git log --oneline HEAD..origin/dev
+```
+
+要求：
+
+1. 必须真实判断当前分支是否已经落后于 `origin/dev`。
+2. 如果当前分支落后，先继续开发可以，但在发起 PR 前必须补齐最新 `dev`。
+3. 如果当前分支已经出现复杂冲突风险，AI 需要提前告诉开发者，不要拖到最后一刻再爆。
+
+### 阶段 3：开发与本地整理
+
+AI 开发时，必须遵守下面这些要求：
+
+1. 先读相关代码上下文，再改代码。
+2. 不能只改表面调用点，必须检查相关联的状态流、配置项、消息流、页面流程、回调流程。
+3. 如果发现本次功能附近本来就有坏逻辑，而且修复不会影响其他已使用代码，可以顺手一并修正。
+4. 如果为了完成新功能必须删除旧逻辑，就删除，不要为了“看起来兼容”堆陈旧代码。
+5. 改完后必须自己检查：
+   - `git diff --stat`
+   - `git diff`
+   - 相关文件中是否残留冲突标记
+   - 是否混入无关改动
+6. 如果改了 SQL，别忘了同步本地 MySQL `xzs`。
+
+### 阶段 4：发起 PR 前必须再次同步最新 `dev`
+
+这是硬规则。
+
+无论这个分支什么时候开始开发，只要准备发起 PR，就必须再次拉取远端最新提交，并确认当前分支已经吸收了最新 `origin/dev`。
+
+先执行：
+
+```powershell
+git fetch origin
+git log --oneline HEAD..origin/dev
+```
+
+#### 如果 `origin/dev` 没有新提交
+
+可以继续进入下一阶段。
+
+#### 如果 `origin/dev` 有新提交
+
+优先处理方式：
+
+```powershell
+git rebase origin/dev
+```
+
+如果开发者明确禁止改写当前分支历史，或者这个分支已经有多人共同使用，再改用：
+
+```powershell
+git merge origin/dev
+```
+
+处理规则：
+
+1. 如果执行了 `rebase`，必须重新检查 diff，确认没有把逻辑改坏。
+2. 如果执行了 `rebase` 且当前分支之前已经推到远端，后续推送时只能使用：
+
+```powershell
+git push --force-with-lease origin <feature-branch>
+```
+
+3. 不允许使用 `git push --force`。
+4. 不能只把冲突标记删掉就算完，必须继续检查冲突两边的真实逻辑是否仍然一致。
+
+### 阶段 5：提交与推送
+
+在发起 PR 前，AI 必须先把本次改动整理干净。
+
+至少要执行下面这些检查：
+
+```powershell
+git status --short
+git diff --stat origin/dev...HEAD
+git diff origin/dev...HEAD
+```
+
+要求：
+
+1. PR 中只能包含与本次任务相关的改动。
+2. 不要把临时调试代码、无关格式化、无关文件重命名、构建产物一起带进 PR。
+3. 提交信息必须描述真实功能结果，不要写：
+   - `update`
+   - `fix bug`
+   - `merge branch`
+   - `修改一下`
+4. 推送前要确认当前分支不是 `dev`，也不是 `master`。
+
+推送示例：
+
+```powershell
+git push -u origin <feature-branch>
+```
+
+### 阶段 6：创建或更新 PR
+
+PR 只能指向 `dev`。
+
+创建 PR 时使用：
+
+```powershell
+gh pr create --base dev --head <feature-branch> --title "<PR标题>" --body-file <PR正文文件>
+```
+
+如果 PR 已经存在，则执行：
+
+```powershell
+gh pr view <PR_NUMBER> --json number,title,baseRefName,headRefName,state,isDraft,url
+```
+
+如果发现已有 PR 的目标分支不是 `dev`，必须改正：
+
+```powershell
+gh pr edit <PR_NUMBER> --base dev
+```
+
+改完后，再重新读取一次 PR 信息，确认：
+
+- `baseRefName = dev`
+- PR 仍是 open
+- head 分支正确
+
+#### PR 标题要求
+
+1. 直接描述功能结果或修复结果。
+2. 不要把标题写成 Git 动作描述。
+3. 不要写空洞标题。
+
+#### PR 正文要求
+
+PR 正文直接写真实信息，建议结构如下：
+
+```markdown
+## 本次改动
+- ...
+
+## 风险与影响
+- ...
+
+## 测试情况
+- 未运行测试，请开发者自行验证
+```
+
+说明：
+
+1. 正文必须基于真实改动来写。
+2. 不要写固定“自动回复”抬头。
+3. 不要写和代码不相符的夸大表述。
+
+### 阶段 7：PR 后续补充说明
+
+如果 AI 需要在 PR 里补充评论、解释冲突、说明待确认点，要求如下：
+
+1. 直接写清楚问题、原因、影响、建议。
+2. 语气自然、简洁、可读。
+3. 不要使用固定机器人模板。
+4. 不要为了“像 AI”而加免责声明废话。
+5. 评论内容必须和真实代码、真实 diff、真实冲突一致。
+
+### 阶段 8：只有在明确授权时，才允许合并 PR
+
+如果开发者明确要求 AI 继续合并自己的 PR，则必须先再次确认：
+
+```powershell
+gh pr view <PR_NUMBER> --json number,title,baseRefName,headRefName,state,isDraft,mergeable,mergeStateStatus,url
+git fetch origin
+git log --oneline HEAD..origin/dev
+```
+
+合并前必须满足：
+
+1. PR 目标分支是 `dev`
+2. PR 不是 draft
+3. PR 仍然是 open
+4. 当前分支已经吸收了最新 `origin/dev`
+5. 没有尚未处理的明确问题
+6. 开发者已经明确授权合并
+
+如果满足以上条件，才可以执行 GitHub 合并，例如：
+
+```powershell
+gh pr merge <PR_NUMBER> --merge --delete-branch
+```
+
+限制：
+
+1. AI 只能把自己的 PR 合并到 `dev`。
+2. AI 不得把任何开发分支直接合并到 `master`。
+3. 如果发现 PR 目标分支是 `master`，先改成 `dev`，再重新核对是否允许继续。
+
+## 开发清单
+
+开发时按下面清单自检，避免漏项：
+
+### 第 1 阶段：开始前
+
+- `gh` 已安装且已登录
+- 当前仓库正确
+- 当前工作区状态已确认
+- 已明确本次任务是否是新任务还是续做
+
+### 第 2 阶段：开发前基线
+
+- 新任务已从最新 `dev` 拉分支
+- 续做任务已确认自己相对 `origin/dev` 的落后情况
+- 没有误在 `master` 或 `dev` 上直接开发
+
+### 第 3 阶段：开发中
+
+- 代码上下文已阅读
+- 相关联逻辑已检查
+- 无用旧代码已清理
+- SQL 改动已同步本地数据库
+
+### 第 4 阶段：发 PR 前
+
+- 已再次获取最新 `origin/dev`
+- 已完成 `rebase` 或 `merge`
+- diff 只包含本次任务改动
+- 提交信息清晰
+- 当前分支不是 `dev` / `master`
+
+### 第 5 阶段：PR 与收尾
+
+- PR 目标分支确认是 `dev`
+- PR 标题和正文与真实改动一致
+- 如有评论，内容为自然中文，不用固定机器人模板
+- 如果未跑测试，已明确提醒开发者测试
+
+## 最终反馈给开发者时必须说明
+
+AI 完成后，至少要向开发者明确反馈下面这些信息：
+
+1. 实际执行了哪些命令和动作
+2. 当前分支是否已经同步最新 `origin/dev`
+3. 是否创建了新 PR，或者更新了已有 PR
+4. PR 编号和链接是什么
+5. PR 目标分支是否确认是 `dev`
+6. 是否执行了 `rebase` 或 `merge`
+7. 是否改了 SQL 并同步了本地数据库
+8. 是否运行过测试；如果没跑，要明确提醒开发者自行测试
+9. 是否已经合并；如果已合并，要明确说明是合并到 `dev`
+
+## 一句话执行要求
+
+AI 在本仓库里做开发与提 PR 时，必须按“先确认环境与当前工作区，再对齐最新 `dev`，再开发与整理改动，再次同步最新 `dev`，最后只向 `dev` 发起或更新 PR；只有在开发者明确授权时，才允许把自己的 PR 合并到 `dev`”的顺序执行，不能跳步，不能猜，不能偷懒。