From 56a5d4f1d70a40efcd99dde217d645d61e0f12a8 Mon Sep 17 00:00:00 2001 From: QLHazyCoder <2825305047@qq.com> Date: Tue, 19 May 2026 19:54:12 +0800 Subject: [PATCH] =?UTF-8?q?=E6=9B=B4=E6=96=B0=E5=90=84=E7=A7=8Dmd=E6=96=87?= =?UTF-8?q?=E6=A1=A3?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- README.md | 878 ++----------------- docs/使用教程/使用教程.md | 4 +- sidepanel/sidepanel.js | 2 +- tests/sidepanel-flow-source-registry.test.js | 5 + 开发者AI开发与PR提交流程.md | 4 +- 项目完整链路说明.md | 319 ++++--- 项目开发规范（AI协作）.md | 28 +- 项目文件结构说明.md | 118 ++- 8 files changed, 411 insertions(+), 947 deletions(-) diff --git a/README.md b/README.md index 7b948d3..93e881e 100644 --- a/README.md +++ b/README.md @@ -1,12 +1,12 @@ # FlowPilot -一个用于批量跑通 ChatGPT OAuth 注册/登录流程的 Chrome 扩展。 +`FlowPilot` 是一个 Chrome 侧边栏扩展，用来批量处理 ChatGPT / OpenAI 账号注册、授权、Plus 支付和平台接入流程。 -当前版本基于侧边栏控制，支持单步执行、整套自动执行、停止当前流程、保存常用配置，以及通过 DuckDuckGo / QQ / 163 / 163 VIP / 126 / Inbucket / Hotmail / Cloud Mail / YYDS Mail 协助获取验证码。 +它的定位不是“单个按钮脚本”，而是把注册、验证码、OAuth、Plus 支付、账号导入、自动重试和记录管理放进同一套可持续使用的工具里。 ## 插件效果 -一百五十个号，一个401： +一百五十个号，一个 401：
@@ -28,843 +28,77 @@ -## 当前能力 +## 主要功能 -- 从 CPA 面板自动获取 OpenAI OAuth 授权链接 -- 自动打开 OpenAI 注册页并点击 `Sign up / Register` -- 自动填写邮箱与密码 -- 支持自定义密码；留空时自动生成强密码 -- 自动显示当前使用中的密码，便于后续保存 -- 自动获取注册验证码与登录验证码 -- 支持 `Hotmail`：继续使用 `邮箱 + 客户端 ID + 刷新令牌（refresh token）`，并可在远程服务与本地助手两种模式间切换 -- 支持 `2925`：新增多账号池、自动登录登出、Step 4 / Step 8 命中“子邮箱已达上限邮箱”后的 24 小时禁用与自动切号 -- 支持 `Cloud Mail`：可通过 skymail.ink API 生成自定义域邮箱，也可作为转发收件通道轮询验证码 -- 支持 `YYDS Mail`：通过 API Key 自动创建临时邮箱，并用返回的临时 Bearer token 读取验证码邮件 -- 支持 `QQ Mail`、`163 Mail`、`163 VIP Mail`、`126 Mail`、`Inbucket mailbox` -- 支持从 DuckDuckGo Email Protection 自动生成新的 `@duck.com` 地址 -- 支持基于 Cloudflare 自定义域名自动生成随机邮箱前缀 -- Step 5 同时兼容两种页面： - - 页面要求填写 `birthday` - - 页面要求填写 `age` -- 支持 `Auto` 多轮运行 -- 支持中途 `Stop` -- 支持通过日志区的 `记录` 按钮查看账号记录面板，同一轮的邮箱和手机号会合并显示，按最终状态、时间、失败标签和重试次数筛选 -- 支持将账号记录完整快照同步到本地 helper，便于开发者直接查看 `data/account-run-history.json` -- Step 8 会自动寻找 OAuth 同意页的“继续”按钮，并通过 Chrome debugger 输入事件发起点击，然后监听本地回调地址 +- 支持普通注册授权链路，既可以单步执行，也可以整套 `Auto` 执行。 +- 支持 Plus 模式，覆盖 `PayPal`、`GoPay`、`GPC` 三种支付链路。 +- 支持 `账号接入策略`，可以在 Plus 模式下按来源选择继续走 `OAuth`，或直接导入当前 ChatGPT 已登录会话。 +- 支持 `CPA`、`SUB2API`、`Codex2API` 三种 OpenAI 来源，以及独立的 `Kiro` flow。 +- 支持邮箱注册、验证码收取、登录验证码处理、OAuth 同意页确认和平台侧账号创建。 +- 支持 `Hotmail`、`2925`、`QQ Mail`、`163 Mail`、`163 VIP Mail`、`126 Mail`、`Inbucket`、`Cloud Mail`、`YYDS Mail`、`iCloud` 等收码方式。 +- 支持 `DuckDuckGo`、`Cloudflare`、`自定义邮箱池`、`自定义邮箱服务号池`、`Gmail / 2925 别名邮箱` 等注册邮箱生成方式。 +- 支持接码平台、手机号验证、自动重试、执行范围限制、IP 代理、贡献模式和账号记录面板。 +- 支持 `Stop`、暂停后继续、失败后重试，以及本地 helper 快照同步。 +## 支持的来源 -## 环境要求 +- `CPA` + 用于普通 OAuth 接入，也支持在 Plus 模式下直接导入当前 ChatGPT 会话到 CPA。 -- Chrome 浏览器 -- 打开扩展开发者模式 -- 你自己的 CPA 管理面板，且页面结构与当前脚本适配 -- 至少准备一种验证码接收方式： - - DuckDuckGo `@duck.com` + QQ / 163 / Inbucket 转发 - - Cloudflare 自定义域邮箱前缀 + QQ / 163 / Inbucket 转发 - - 手动填写一个可收信邮箱 -- 如果使用 `QQ` / `163` / `163 VIP` / `126` / `Inbucket`，对应页面需要提前能正常打开 +- `SUB2API` + 用于普通 OAuth 接入，也支持在 Plus 模式下直接导入当前 ChatGPT 会话到 SUB2API。 -## 安装 +- `Codex2API` + 当前保持 OAuth 接入，不支持 Plus 会话直导。 -1. 打开 `chrome://extensions/` -2. 开启“开发者模式” -3. 点击“加载已解压的扩展程序” -4. 选择本项目目录 -5. 打开扩展侧边栏 +- `Kiro` + 独立的 Builder ID 注册、桌面授权和 `kiro.rs` 上传链路，不复用 OpenAI 的 Plus 和平台接入逻辑。 -## 2026-04-17 更新补充：Gmail / 2925 别名邮箱 +## Plus 模式 -本次版本对 `Gmail` 与 `2925 provide` 的注册邮箱逻辑做了统一整理： +- Plus 模式下，侧边栏会先显示 `账号接入策略`，再显示 `Plus 支付`。 +- `账号接入策略` 会跟随当前来源动态变化： + - `CPA`：支持 `OAuth`、`导入当前 ChatGPT 会话到 CPA` + - `SUB2API`：支持 `OAuth`、`导入当前 ChatGPT 会话到 SUB2API` + - `Codex2API`：当前仅支持 `OAuth` +- Plus 模式下的步骤不是固定一套，系统会按支付方式和账号接入策略动态切换尾链。 +- Plus 模式当前只支持邮箱注册，不支持手机号注册。 -- `Gmail` 与 `2925 provide` 现在都走同一套“别名邮箱”逻辑。 -- 两者都不再使用“只填前缀再特殊拼接”的界面交互。 -- 两者都要求先填写“基邮箱”： - - `Gmail`：例如 `name@gmail.com` - - `2925`（仅 provide 模式）：例如 `name@2925.com` -- 侧边栏里的“注册邮箱”输入框对这两种模式都已开放，可直接手动填写完整邮箱。 -- 侧边栏里的 `获取 / 生成` 按钮对这两种模式也可用，行为与 Duck / Cloudflare 一样，都是“可自动生成，也可手动覆盖”。 -- 当 `Mail = 2925` 且模式切到 `接收邮箱` 时，不再走别名基邮箱链路，而是回退到普通“邮箱生成 / 手动填写注册邮箱”路线，2925 只负责后续收信。 +## 自动化能力 -具体行为： +- 支持手动单步执行、自动整套执行、手动跳过、失败重试和中途停止。 +- 支持在同一轮里保留账号身份，自动把邮箱、手机号、注册邮箱状态和平台回调状态串起来。 +- 支持“记录”面板查看成功、失败、停止、重试次数，以及同一轮的邮箱/手机号组合身份。 +- 支持把账号记录同步到本地 helper，方便直接查看 `data/account-run-history.json`。 -- `Gmail` 会基于完整基邮箱生成 `name+tag@gmail.com` -- `2925` 仅在 provide 模式下会基于完整基邮箱生成 `name123456@2925.com` -- 如果当前“注册邮箱”里已经是与当前基邮箱兼容的完整邮箱，流程会优先复用，不会强行重新生成 +## 邮箱与验证码能力 -注意： - -- `2925` 旧的“只填前缀”使用方式已经不再推荐，应该改为填写完整基邮箱 -- 如果你手动填写了与当前 `Gmail / 2925 provide` 基邮箱不匹配的完整邮箱，侧边栏会在保存或执行 Step 3 时拦截 - -## 2026-04-23 更新补充：自定义邮箱池 - -本次版本新增 `自定义邮箱池` 生成方式，用于把一批已经准备好的邮箱按顺序分配给自动流程： - -- 在 `邮箱生成` 中选择 `自定义邮箱池` -- 在新出现的 `邮箱池` 文本框里按“每行一个邮箱”填写 -- `Auto` 运行次数会自动跟随邮箱池数量，无需再手动对齐轮数 -- 同一目标轮次的失败重试会继续复用当前轮邮箱，不会提前跳到下一个 -- 实际收码仍然走当前 `Mail` 对应的邮箱服务，因此应保证邮箱池里的地址与当前收码链路匹配 - -## 2026-04-23 更新补充：自定义邮箱服务号池 - -当 `Mail = 自定义邮箱` 时，现在也可以直接维护一组“自定义号池”： - -- 在 `邮箱服务` 选择 `自定义邮箱` -- 在新出现的 `自定义号池` 文本框里按“每行一个邮箱”填写 -- `Auto` 运行次数会自动跟随号池数量 -- 只要当前邮箱还没成功认证、也没出现手机号验证，就会持续复用这个邮箱重试 -- 只有成功认证，或明确出现 `add-phone / 手机号验证` 时，才会切换到号池中的下一个邮箱 -- 这条链路只负责分配注册邮箱；第 `4 / 8` 步仍然保持手动输入验证码，不会改成自动轮询邮箱 +- 支持网页邮箱轮询、API 邮箱轮询和本地 helper 读取三类模式。 +- 支持注册验证码、登录验证码、绑定邮箱验证码，以及 Plus / GPC 场景下的 OTP 处理。 +- `2925` 支持多账号池、自动登录、自动切号、24 小时冷却。 +- `Hotmail` 支持远程服务模式和本地 helper 模式。 +- `自定义邮箱池` 和 `自定义邮箱服务号池` 都可以和自动运行轮数联动。 ## 快速开始 -如果你只是想先跑通一套最稳的组合，建议直接按下面三种方案之一配置。 +1. 在 `chrome://extensions/` 打开开发者模式。 +2. 点击“加载已解压的扩展程序”，选择本项目目录。 +3. 打开扩展侧边栏，先选择当前要跑的 `flow` 和 `来源`。 +4. 按你的使用方式配置邮箱、验证码来源、Plus 支付或平台参数。 +5. 先手动跑通前几步，再使用 `Auto` 跑完整链路。 -### 方案 A：`CPA + QQ / 163 / 163 VIP / 126` +## 操作间延迟 -1. `CPA` 填你的管理面板 OAuth 页面地址 -2. `Mail` 选择 `QQ Mail`、`163 Mail`、`163 VIP Mail` 或 `126 Mail` -3. `邮箱生成` 选择 `DuckDuckGo`、`Cloudflare` 或 `自定义邮箱池` -4. 若你选择 `Cloudflare`，先按下文把 Cloudflare Email Routing 配好 -5. 若你选择 `自定义邮箱池`，就在 `邮箱池` 中按行填入邮箱；否则点击 `获取` 生成邮箱，或手动粘贴一个你能收信的邮箱 -6. 先单步验证 `Step 1 ~ Step 4` -7. 验证没问题后再点右上角 `Auto` +- `操作间延迟` 默认开启，默认值是 `2 秒`。 +- 它主要作用于页面里的点击、输入和短等待节奏，让操作更稳一些。 +- 它不影响邮箱验证码轮询、短信验证码轮询、OTP 轮询，也不改变 `confirm-oauth` 和 `platform-verify` 这类后台步骤的执行节奏。 -### 方案 B：`SUB2API + QQ / 163 / 163 VIP / 126` +## 文档入口 -1. `来源` 选择 `SUB2API` -2. 填好 `SUB2API` 地址、登录邮箱、登录密码、分组名 -3. `Mail` 与 `邮箱生成` 的配置方式同方案 A -4. Step 1 会直接在 SUB2API 后台生成 OAuth 链接 -5. Step 10 会把 localhost 回调提交回 SUB2API，并直接创建 OpenAI 账号 +- [项目文件结构说明.md](./项目文件结构说明.md) +- [项目完整链路说明.md](./项目完整链路说明.md) +- [项目开发规范（AI协作）.md](./项目开发规范（AI协作）.md) -### 方案 C：`Codex2API + QQ / 163 / 163 VIP / 126` +如果你只想知道“这个扩展能做什么、该怎么开用”，看本 README 就够了。 -1. `来源` 选择 `Codex2API` -2. 填好 `Codex2API` 后台地址、管理密钥 -3. `Mail` 与 `邮箱生成` 的配置方式同方案 A -4. Step 7 会直接通过 Codex2API 协议 `/api/admin/oauth/generate-auth-url` 生成 OAuth 链接 -5. Step 10 会把 localhost 回调中的 `code / state` 通过 `/api/admin/oauth/exchange-code` 直接提交给 Codex2API - -### 方案 D：`Hotmail 账号池` - -1. `Mail` 选择 `Hotmail` -2. 在 `Hotmail 账号池` 中添加 `邮箱 / Client ID / Refresh Token` -3. 先点 `校验`，再点 `测试收信` -4. 通过后再执行步骤或 `Auto` -5. 当前项目中，`Mail = Hotmail` 时会直接使用账号池里的邮箱作为注册邮箱，不再走 `Duck / Cloudflare` 自动生成 - -### 方案 E：`2925 账号池` - -1. `Mail` 选择 `2925` -2. 在 `2925 账号池` 中添加 `邮箱 / 密码` -3. 先根据你的用途选择 `2925 模式` - - `提供邮箱`：注册邮箱本身就是 2925 别名，会显示“别名基邮箱”输入 - - `接收邮箱`：注册邮箱回退到普通“邮箱生成 / 手动填写”路线，2925 只负责收信 -4. `2925 号池` 现在是独立配置行；开启 `号池` 后可从下拉框中选择当前 2925 账号。若当前处于 `提供邮箱` 模式，这个账号也会同步作为别名基邮箱 -5. 可先点 `使用此账号` 让当前 2925 账号切到这条记录，再点 `登录` 手动验证网页邮箱登录态 -6. 只有在 `号池` 开关开启时，自动流程执行到 Step 4 / Step 8 前才会自动检查 2925 登录态；如果未登录，会先清理登录 cookie、等待 `3 秒`，再打开登录页，并在页面打开后再等待 `3 秒`，然后使用当前账号自动登录；填写完账号密码后会额外等待 `1 秒` 再点击登录，点击后若 `40 秒`内仍未进入收件箱，则会判定当前登录失败 -7. 当 Step 4 / Step 8 轮询邮箱时遇到“子邮箱已达上限邮箱”，扩展会记录当前时间；如果还有下一个可用账号，就禁用当前账号 24 小时并自动切换登录；如果没有下一个可用账号，或当前未启用号池模式，则会直接复用现有“手动暂停 / 停止”逻辑终止自动流程 -8. 如果你同时开启了 `Auto` 的自动重试，当前尝试结束后会按现有逻辑自动进入下一次尝试，不需要再手动介入 -9. 只有 `Mail = 2925` 且模式为 `提供邮箱` 时，才会继续走 Gmail / 2925 共用的别名邮箱链路；例如 `name@2925.com -> name123456@2925.com` - -## 侧边栏配置说明 - -### `CPA` - -你的管理面板 OAuth 页面地址，例如： - -```txt -http(s):///management.html#/oauth -``` - -Step 1 和 Step 10 都依赖这个地址。 - -### `SUB2API` - -当 `来源 = SUB2API` 时，需要配置： - -- `SUB2API`：后台账号管理页地址 -- `账号 / 密码`：SUB2API 管理员登录信息 -- `分组`：目标 OpenAI 分组，留空时默认 `codex` -- `默认代理`：可选，填写代理名称或代理 ID；留空时不使用代理 - -插件会在 Step 1 和 Step 10 自动从 `/api/v1/admin/proxies/all` 解析这个代理，并在 OAuth 链接生成、授权码交换和账号创建请求中附带 `proxy_id`。如果名称匹配到多个代理，请改填代理 ID；留空则不会发送 `proxy_id`。 - -### `Codex2API` - -当 `来源 = Codex2API` 时，需要配置： - -- `Codex2API`：后台账号管理页地址，默认 `http://localhost:8080/admin/accounts` -- `管理密钥`：Codex2API 的 `Admin Secret` - -插件会在： - -- Step 7 调用 `POST /api/admin/oauth/generate-auth-url` 生成授权链接 -- Step 10 调用 `POST /api/admin/oauth/exchange-code` 完成 localhost callback 的授权码交换并创建账号 - -这条来源是协议直连，不依赖 Codex2API 后台页面的“添加账号 / OAuth 授权 / 生成授权链接”按钮 DOM。 - -### `Mail` - -支持九种验证码来源： - -- `Hotmail` -- `2925` -- `Cloud Mail` -- `YYDS Mail` -- `163 Mail` -- `163 VIP Mail` -- `126 Mail` -- `QQ Mail` -- `Inbucket` - -说明： - -- `Hotmail` 通过侧边栏里的 Hotmail 账号池选择账号，可切换为远程服务模式或本地助手模式 -- `2925` 通过侧边栏里的 2925 账号池选择账号，并在 Step 4 / Step 8 前自动校验网页邮箱登录态 -- `Cloud Mail` 通过侧边栏配置 API 地址、管理员账号、接收邮箱或生成域名，可直接生成邮箱或轮询转发收件箱 -- `YYDS Mail` 通过侧边栏配置 API Key 与 Base URL；点击“获取”或自动运行时会创建新的临时邮箱，Step 4 / Step 8 使用返回的临时 token 轮询验证码 -- `QQ`、`163`、`163 VIP`、`126` 用于直接轮询网页邮箱 -- `Inbucket` 通过你在侧边栏里配置的 host 访问 `mailbox` 页面：`https:///m//` - -### `YYDS Mail` - -仅当 `Mail = YYDS Mail` 时使用。 - -可配置项： - -- `API Key`：用于创建临时邮箱，请求头为 `X-API-Key` -- `Base URL`：默认 `https://maliapi.215.im/v1`，可按自建或兼容服务地址修改 - -行为说明： - -1. 点击注册邮箱区域的 `获取`，或 Auto 每轮准备邮箱时，扩展会调用 `POST /accounts` 创建临时邮箱。 -2. 创建请求只发送 `localPart`；最终注册邮箱以后端返回的 `address` 为准。 -3. 后台保存本轮返回的临时 `token`，Step 4 / Step 8 通过 `Bearer token` 读取 `/messages` 与 `/messages/{id}`。 -4. 平台验证完成或重置当前流程后，会清空本轮 YYDS Mail 邮箱运行态；API Key 与 Base URL 配置会保留，下一轮重新创建邮箱。 - -### `Hotmail 账号池` - -仅当 `Mail = Hotmail` 时使用。 - -可配置项： - -- `接码模式` -- `远程服务地址` -- `本地助手地址` - -每条账号支持保存： - -- `email` -- `clientId` -- `refreshToken` -- 可选邮箱密码备注 - -使用方式： - -- 先选择 Hotmail 接码模式 -- 远程模式下填写你自己的远程服务地址 -- 本地模式下填写本地助手地址（默认 `http://127.0.0.1:17373`） -- Windows 运行仓库根目录的 `start-hotmail-helper.bat` -- macOS 运行仓库根目录的 `start-hotmail-helper.command` -- 本地 helper 当前仅依赖 Python 标准库，无需额外安装第三方 Python 包 -- 再新增账号 -- 点击 `校验` -- 校验通过后，可点击 `测试收信` -- Auto 模式每轮会自动选用一个可用账号 - -### `2925 账号池` - -仅当 `Mail = 2925` 时使用。 - -每条账号支持保存： - -- `email` -- `password` - -使用方式： - -- 添加一个或多个 `2925.com` 账号 -- 点击 `使用此账号` 可以切换当前别名基邮箱来源 -- 点击 `登录` 可以让扩展直接打开 / 复用 2925 邮箱标签页，并使用当前账号自动登录 -- 如果账号因为“子邮箱已达上限邮箱”被临时禁用，列表里会展示上限记录时间和恢复时间 -- 命中冷却的账号可手动 `清冷却`，也可以等待 24 小时后自动恢复可用 -- Auto 模式在生成 2925 别名邮箱前，会自动分配当前可用账号；若 Step 4 / Step 8 命中上限，会自动切到下一个账号 - -#### 本地 helper 启动命令 - -Windows： - -```powershell -.\start-hotmail-helper.bat -``` - -macOS： - -```bash -chmod +x ./start-hotmail-helper.command -./start-hotmail-helper.command -``` - -如果你不想走启动脚本，也可以直接运行 Python 程序本体： - -```bash -python scripts/hotmail_helper.py -``` - -如果你的环境里命令是 `python3`： - -```bash -python3 scripts/hotmail_helper.py -``` - -#### 启动成功标志 - -本地 helper 启动成功后，终端会输出： - -```text -Hotmail helper listening on http://127.0.0.1:17373 -``` - -同时还会输出本地账号记录快照文件路径。看到这些输出后，再回到扩展里点 `校验`、`复制最新验证码`；账号记录快照会按默认本地 helper 地址自动同步，无需再手动开启本地同步。 - -#### 最小排错说明 - -- 如果提示 `Python 3 not found`，先安装 Python 3.10+ -- 如果 helper 已启动但扩展仍报连接失败，先确认模式切到了 `本地助手` -- 确认本地助手地址与终端输出一致，默认应为 `http://127.0.0.1:17373` -- 如果地址一致仍失败，再检查是否有端口占用或终端里是否已经抛出异常 - -### `Mailbox` - -仅当 `Mail = Inbucket` 时显示。 - -填写 Inbucket mailbox 名称，例如： - -```txt -tmp-mailbox -``` - -脚本会自动打开： - -```txt -https:///m// -``` - -并且只检索未读邮件： - -- 只匹配 `.message-list-entry.unseen` -- 第 2 次轮询开始会自动点击 mailbox 页面上的刷新按钮 -- 识别到验证码后会尝试删除当前邮件，减少重复命中 - -### `Inbucket` - -仅当 `Mail = Inbucket` 时显示。 - -这里填写 Inbucket host，支持两种格式： - -- `your-inbucket-host` -- `https://your-inbucket-host` - -脚本会自动规范化成 origin 后再拼接 mailbox URL。 - -### `Email` - -Step 3 使用的注册邮箱。 - -来源有两种： - -- 手动粘贴 -- 按当前生成方式自动生成或分配邮箱（DuckDuckGo / Cloudflare / 自定义邮箱池） - -注意： - -- 若 `邮箱生成 = Cloudflare`，插件里只需要维护 `CF 域名` -- 若 `邮箱生成 = 自定义邮箱池`，需要在 `邮箱池` 文本框中按行维护邮箱列表 -- 若 `Mail = 自定义邮箱` 且你希望多轮自动跑不同邮箱，可直接在 `自定义号池` 文本框中按行维护邮箱列表 -- `CF 域名` 支持保存多个，并通过下拉框切换当前要生成的域名 -- Cloudflare 侧的转发规则、Catch-all、路由目标邮箱等，都需要你自己提前在 Cloudflare 后台配置好 -- 当 `Mail = Hotmail` 时，这个输入框由账号池自动同步当前账号邮箱 -- 当 `Mail = Hotmail` 时，Step 3 会直接使用 Hotmail 账号池里的邮箱；`Duck / Cloudflare` 不参与自动邮箱生成 -- 当 `Mail = 自定义邮箱` 且启用了 `自定义号池` 时，Auto 会先为当前轮分配一个邮箱；后续普通失败不会换号，只有成功或出现手机号验证才会切到下一个邮箱 -- 若你准备走 `Cloudflare`，更推荐把 `Mail` 设为 `QQ / 163 / 163 VIP / 126`；`Inbucket` 仅在它能真实接收外部邮件并完成 Cloudflare 验证时再使用 -- `Auto` 会按当前“邮箱生成”配置自动获取或分配邮箱；若当前是 `自定义邮箱池`，则会按邮箱池顺序取用 -- 如果你使用 Inbucket，它只是验证码收件箱，不会自动生成 Inbucket 地址 - -### `邮箱生成 = Cloudflare` 时的配置 - -- `CF 域名`：例如 `example.xyz` -- 右侧 `添加 / 保存`：用于保存多个可切换的域名 -- 下拉框：用于切换当前这次要生成邮箱所使用的域名 - -#### 当前实现是什么逻辑 - -Cloudflare 模式下，插件不会再调用 Cloudflare API 创建路由。 - -它现在只做一件事： - -1. 根据你当前选中的 `CF 域名` -2. 本地生成一个 10 位随机前缀 -3. 前缀由 `6 个小写字母 + 4 个数字` 组成，顺序随机打乱 -4. 直接得到一个类似 `a3b9cd1e2f@example.xyz` 的注册邮箱 -5. 把这个邮箱写入当前流程继续往下跑 - -也就是说，插件默认认为： - -- 你已经在 Cloudflare 后台把这个域名的收件转发规则配置好了 -- 这个随机前缀邮箱发来的邮件，最终能被你现有的 `163 / QQ / Inbucket` 收件链路接住 - -#### 你需要自己提前做什么 - -在 Cloudflare 后台，至少保证下面一条成立： - -- 你已经配好了 Catch-all / 通配规则，能接住任意前缀邮箱 -- 或者你本来就有一套能覆盖这些随机前缀邮箱的转发规则 - -否则插件虽然能生成 `@你的域名` 邮箱，但验证码邮件最后没人接收，后面的 Step 4 / Step 7 还是会失败。 - -#### 推荐搭配 - -- `Mail = QQ Mail`：Cloudflare 的 `Destination address / Destination addresses` 填你的 QQ 邮箱全地址 -- `Mail = 163 Mail`：Cloudflare 的 `Destination address / Destination addresses` 填你的 163 邮箱全地址 -- `Mail = 163 VIP Mail`：Cloudflare 的 `Destination address / Destination addresses` 填你的 163 VIP 邮箱全地址 -- `Mail = 126 Mail`：Cloudflare 的 `Destination address / Destination addresses` 填你的 126 邮箱全地址 -- `Mail = Inbucket`：仅当你的 Inbucket 实例本身就是一个真实可收外部邮件、且能收到 Cloudflare 验证邮件的地址时再使用 -- `Mail = Hotmail`：当前项目的自动流程不推荐和 Cloudflare 同时使用；因为 `Mail = Hotmail` 时，注册邮箱会直接使用 Hotmail 账号池邮箱 - -#### Cloudflare 后台怎么配（按钮中英对照） - -下面按钮名称以 Cloudflare 官方英文界面为准，括号内中文仅用于对照理解，不保证是 Cloudflare 的官方中文翻译。 - -1. 登录 Cloudflare 后台，选中你要用的域名 -2. 进入 `Email > Email Routing` -3. 如果这是你第一次给这个域名启用 Email Routing： - - 先检查 Cloudflare 准备添加的记录 - - 点击 `Add records and enable（添加记录并启用）` -4. 进入 `Routing rules（路由规则）` 或 `Routes（路由）` -5. 先创建一个固定地址，用来把目标收件箱加进 Cloudflare： - - 点击 `Create address（创建地址）` - - 在 `Custom address（自定义地址）` 里填一个固定前缀，例如 `cf-init` - - 在 `Action（动作）` 中选择 `Send to an email（转发到邮箱）` - - 在 `Destination / Destination addresses（目标邮箱）` 中填你真正收验证码的邮箱 - - 点击 `Save（保存）` -6. 打开 Cloudflare 发到目标邮箱的验证邮件，依次点击： - - `Verify email address（验证邮箱地址）` - - `Go to Email Routing（前往 Email Routing）` -7. 回到 Cloudflare 后台后，确认这个目标邮箱的状态已经变成 `Verified（已验证）` -8. 如果 Cloudflare 还在首次启用向导里要求继续： - - 点击 `Continue（继续）` - - 点击 `Add records and finish（添加记录并完成）` -9. 对于本项目这种“每次都生成随机前缀”的用法，建议再打开： - - `Catch-all address（Catch-all 地址）` - - 让它显示为 `Active（启用）` - - 在 `Action（动作）` 中选择 `Send to an email（转发到邮箱）` - - 如果界面要求选择 `Destination（目标邮箱）`，就选你刚刚已经验证通过的那个邮箱 - - 点击 `Save（保存）` -10. 最后再回到插件： - - `邮箱生成` 选择 `Cloudflare` - - 在 `CF 域名` 里点 `添加` - - 输入域名后点 `保存` - - 点击 `获取` - -#### Cloudflare 配好后怎么自测 - -1. 先在插件里点击 `获取`，拿到一个随机前缀邮箱 -2. 用另一个邮箱给这个地址发一封测试邮件 -3. 不要用目标邮箱给自己发测试邮件，否则某些邮箱服务会把它当成重复邮件直接吞掉 -4. 如果你的 `Mail` 选的是 `QQ / 163 / 163 VIP / 126 / Inbucket`，就去对应收件链路里确认这封测试邮件能否到达 - -#### 官方参考 - -- Cloudflare Email Routing 启用流程： -- Cloudflare Routing rules / Routes / Catch-all / Destination addresses： - -#### 最简单的使用方式 - -1. 在 Cloudflare 后台先把你的域名收件转发规则配好 -2. 在插件里选择 `邮箱生成 = Cloudflare` -3. 在 `CF 域名` 里点 `添加` -4. 输入域名后点 `保存` -5. 以后直接从下拉框切换当前使用的域名 -6. 点击 `获取`，插件就会基于这个域名生成一个随机邮箱 - -### `Password` - -- 留空：自动生成强密码 -- 手动输入：使用你自定义的密码 -- 可通过输入框右侧的眼睛图标切换显示 -- 配置会自动保存，也可以点击右侧 `保存` 按钮手动保存一次 -- 右上角 `配置` 按钮支持导出当前配置到 JSON 文件，也支持从 JSON 文件覆盖导入配置 - -扩展会把本轮实际使用的密码同步回侧边栏，便于查看和复制。 - -### `Auto` - -整套流程自动跑。 - -支持多轮运行，运行次数由右上角数字框决定。 - -`延迟` 里的“启动前倒计时”只控制整轮 Auto 开始前要不要先倒计时多少分钟。 - -`步间随机` 控制 Auto 流程里**每一步真正执行前**的额外等待秒数。这个设置只影响 Auto，不影响你手动单步点击执行；填 `0` 或留空表示不延迟。 - -如果当前面板里已经存在未完成进度，点击 `Auto` 时会弹出选择： - -- `重新开始`：重置当前流程进度，从 Step 1 开始新一轮 -- `继续当前`：把 `已完成 / 已跳过` 视为已处理，从第一个未处理步骤继续往后执行 - -### 操作间延迟 - -`操作间延迟` 默认开启且固定开启。自动流程和手动单步在每个页面输入、选择、点击、提交、继续或授权操作完成后固定等待 2 秒；第一项页面操作不会提前等待。分格 OTP/验证码会先整组填完，然后只等待一次。 - -该开关不同于步间间隔，不影响邮箱轮询、短信/WhatsApp 轮询、后台 API、网络重试、后台定时器或存储持久化，也不影响 `confirm-oauth` 和 `platform-verify` 的交互节奏。 - -## 工作流 - -### 单步模式 - -侧边栏共有 10 个步骤按钮，可逐步执行： - -1. `Open ChatGPT` -2. `Signup + Email` -3. `Fill Password` -4. `Get Signup Code` -5. `Fill Name / Birthday` -6. `Wait Registration Success` -7. `Login via OAuth` -8. `Get Login Code` -9. `Manual OAuth Confirm` -10. `CPA Verify` - -### Auto 模式 - -点击右上角 `Auto` 后，后台会按顺序跑完整流程。 - -当前 Auto 逻辑是： - -1. Step 1 打开 `https://chatgpt.com/` -2. 根据 `Mail` 选择邮箱来源 -3. 如果 `Mail = Hotmail`，会从账号池自动分配一个可用账号 -4. 如果 `Mail = 自定义邮箱` 且配置了 `自定义号池`，会按号池顺序分配当前轮邮箱；否则如果不是 Hotmail，则按当前“邮箱生成”配置尝试自动获取或分配邮箱（Duck / Cloudflare / Cloud Mail / iCloud / 自定义邮箱池等） -5. Step 2 点击注册、填写邮箱，并按真实落地页进入密码页或直接进入邮箱验证码页 -6. 如果自动获取失败，暂停并等待你在侧边栏填写邮箱后点击 `Continue` -7. 继续执行 Step 3 ~ Step 10 - -也就是说： - -- 如果邮箱可自动获取，整套流程更接近全自动 -- 如果自动获取失败，后台会先自动重试 5 次；仍失败时，Auto 才会在邮箱阶段暂停 -- Auto 的暂停状态会保存在会话状态中，重新打开侧边栏后仍可继续 -- 如果你在 Auto 暂停时改为手动点步骤或跳过步骤，面板会先确认并停止 Auto，再切回手动控制 -- 选择 `继续当前` 时，后台不会先做大而全的前置校验，而是从当前步骤状态直接继续；缺什么条件，就在运行到那一步时再报错或暂停 -- 除了现有的页面切换等待外，Auto 还会在每一步执行前按 `步间随机` 的秒数额外等待；填 `0` 或留空表示不延迟 - -## 详细步骤说明 - -### Step 1: Open ChatGPT - -通过动态注入的 `content/signup-page.js`： - -- 打开 `https://chatgpt.com/` -- 确认官网首页或注册入口弹窗已经可操作 - -这一步不再获取 `OAuth` 链接；`OAuth` 链接会在 Step 7 内部按需刷新。 - -### Step 2: Signup + Email - -通过 `content/signup-page.js`： - -- 在官网首页查找 `免费注册 / Sign up / Register / 创建账户` -- 自动点击进入注册流程 -- 自动填写邮箱 -- 点击 `继续` -- 等待真实落地页；进入 `https://auth.openai.com/create-account/password` 时继续 Step 3，进入 `https://auth.openai.com/email-verification` 时自动跳过 Step 3 直接进入 Step 4 - -### Step 3: Fill Password - -- 使用第 2 步已经确定好的邮箱 -- 使用自定义密码或自动生成密码 -- 在密码页填写密码并提交注册表单 -- 后台会在真正把 Step 3 记为完成前，再确认页面是否已经推进；如果此时出现认证页 `重试` 页面，或 `/email-verification` 上的 `405 / Route Error` 重试页，会先通过共享恢复逻辑最多自动点击 5 次 `重试` 尝试恢复，再继续后续链路 -- Step 3 收尾阶段如果页面切换导致旧内容脚本失联，后台单次消息等待不会再卡住超过当前收尾预算；若最终仍未恢复，则会输出中文的步骤级错误，而不是直接暴露底层英文通信超时 - -实际使用的密码会写入会话状态，并同步到侧边栏显示。 - -### Step 4: Get Signup Code - -根据 `Mail` 配置，轮询邮箱并提取 6 位验证码。 - -进入邮箱轮询前，脚本会先确认认证页是否已经进入验证码页面；如果注册认证流程出现 `糟糕，出错了 / 操作超时（Operation timed out）`，或 `/email-verification` 上的 `405 / Route Error` 且带有 `重试` 按钮，会先通过共享恢复逻辑最多自动点击 5 次 `重试`，必要时回到密码页重新提交，再继续等待验证码页面。 - -在 `Auto` 模式下，如果 Step 4 当前轮失败，后台不会立刻丢弃这轮邮箱；而是沿用当前邮箱回到 Step 1 重新开始当前轮，避免刚拿到的邮箱被直接换掉。 -但如果 Step 4 的认证重试页正文里出现 `user_already_exists`，则会直接判定“当前用户已存在”，不会点击 `重试`，而是立即结束当前轮；开启自动重试时会直接继续下一轮。 - -支持： - -- `Hotmail`（远程服务 / 本地助手） -- `content/qq-mail.js` -- `content/mail-163.js`（163 / 163 VIP / 126） -- `content/inbucket-mail.js` - -邮件匹配规则以以下关键词为主： - -- 发件人：`openai`、`noreply`、`verify`、`auth`、`duckduckgo`、`forward` -- 标题：`verify`、`verification`、`code`、`验证`、`confirm` - -### Step 5: Fill Name / Birthday - -随机生成人名与生日。 - -当前脚本支持两种页面结构： - -- 页面要求 `birthday` -- 页面要求 `age` - -如果页面是生日模式，会填写年月日；如果页面上存在 `input[name='age']`，则直接填写年龄。 -如果资料页出现顶部“我同意以下所有各项”总勾选框，脚本会优先自动勾选，再点击 `完成帐户创建`。 -点击 `完成帐户创建` 后，Step 5 会立刻记为完成，不再等待页面跳转结果；自动运行在进入 Step 6 前只会等待当前页面加载完成，不再接管 ChatGPT 跳转或 onboarding 跳过逻辑。 - -### Step 6: Wait Registration Success - -这一步只负责等待注册完成后的页面状态稳定： - -- 固定等待 20 秒 -- 默认不清理 `chatgpt.com / openai.com` 相关 cookies；侧栏开启第六步 `清 Cookies` 后才会在等待结束后执行清理 -- 等待完成后直接进入后续 OAuth 登录链路 - - -### Step 7: Login via OAuth - -这一步会重新获取一遍最新的 CPA OAuth 链接，再使用刚注册的账号登录。 - -当前 Step 7 的完成标准不是“邮箱/密码已提交”，而是： - -- 已刷新到最新 OAuth 链接 -- 认证页已经真正进入登录验证码页面 -- 在真正把 Step 7 记为完成前，还会再做一轮收尾确认；如果页面只是短暂进入登录验证码页、随后又掉进登录重试页，则不会直接进入 Step 8，而是先按共享恢复逻辑处理并重跑 Step 7 -- 如遇登录超时报错，会先尝试通过共享恢复逻辑最多自动点击 5 次认证页上的 `重试` 恢复当前页面；若仍未恢复，再按既有逻辑重跑整个 Step 7 -- 如遇登录页长时间停滞，会由后台刷新 OAuth 后重跑整个 Step 7 -- 如果重试页内容中出现 `max_check_attempts`，会立刻完全停止流程，并在侧边栏复用现有确认弹窗提示这是 Cloudflare 风控拦截，确认按钮显示为“我知道了” -- Step 8 不负责替代 Step 7 的收尾确认；它默认消费的是“已经由 Step 7 确认稳定进入”的登录验证码页，只在后台入口做防御性状态兜底 - -支持： - -- 邮箱 + 密码登录 -- 必要时切换到一次性验证码登录 -- 直到登录验证码页就绪才算步骤完成 - -### Step 8: Get Login Code - -Step 8 默认要求当前认证页已经处于登录验证码页。 - -它只负责： - -- 打开邮箱并轮询登录验证码 -- 填写并提交登录验证码 -- 验证码链路失败后按有限次数回退到 Step 7 -- 如果进入登录超时报错/重试页，包括 `/email-verification` 上的 `405 / Route Error` 登录重试页，会直接报错并回到 Step 7，不会在 Step 8 内部点击 `重试` -- 如果重试页内容中出现 `max_check_attempts`，会直接完全停止整个流程，并复用现有确认弹窗提醒先等待 15 到 30 分钟或更换浏览器，确认按钮显示为“我知道了” -- 当 `Mail = 自定义邮箱` 时，Step 8 的手动确认弹窗会额外提供一个“出现手机号验证”按钮；点击后会直接按真实 `add-phone` fatal 错误处理，日志和自动切号行为与页面实际进入手机号验证时保持一致 - -与 Step 4 类似，但会使用稍微不同的关键词组合去找登录验证码邮件。 - -### Step 9: Manual OAuth Confirm - -严格回调捕获规则： - -- 步骤 9 现在只接受 `http(s)://localhost:/auth/callback?code=...&state=...` 或 `http(s)://127.0.0.1:/auth/callback?code=...&state=...` -- 监听范围只限于当前 OAuth 认证标签页的主 frame 跳转 -- 普通 `localhost` 页面，包括本地部署的 CPA 面板，不会再被误判为回调地址 - -虽然按钮名称还是 `Manual OAuth Confirm`，但当前代码已经做了自动尝试： - -- 在授权页定位“继续”按钮 -- 等待按钮可点击 -- 获取按钮坐标 -- 通过 Chrome `debugger` 的输入事件点击该按钮 -- 点击后会持续检查页面是否真正离开当前状态；如果点击后出现认证页 `重试` 页面，则直接报错，不会在 Step 9 内部点击 `重试` -- 同时监听 `chrome.webNavigation.onBeforeNavigate` -- 一旦捕获本地回调地址，就把结果保存到 `Callback` - -注意： - -- 这一步仍然是最容易因页面变化而失效的一步 -- 如果 120 秒内没有捕获到 localhost 回调，会报错超时 -- README 中的按钮名称沿用了旧文案，但代码行为是“自动尝试点击” - -### Step 10: CPA Verify - -校验规则： - -- 步骤 10 会拒绝任何不是真实 `/auth/callback`，或缺少 `code` / `state` 的本地回调地址 -- 成功后的清理只会针对 `/auth` 这一类真实回调标签页，不会再泛化清理任意 localhost 路径 -- 侧边栏可切换“回调方式”，默认是 `服务器部署` -- 选择 `服务器部署` 时，即使 CPA 部署在本地，也会执行步骤 10 -- 选择 `本地部署` 时，仅当本地 CPA 且步骤 9 已拿到回调地址时，才会直接跳过步骤 10 - -回到 CPA 面板： - -- 自动填写 localhost 回调地址 -- 自动点击“提交回调 URL” -- 必须等到 CPA 面板出现精确的 `认证成功！` 状态徽标后，才判定成功 -- 成功后会自动关闭匹配 `http://localhost:1455/auth` 这一类前缀的 localhost 残留页面 - -## Duck 邮箱自动获取 - -通过 `content/duck-mail.js`： - -- 打开 DuckDuckGo Email Protection Autofill 设置页 -- 查找当前私有地址 -- 如需要，点击 `Generate Private Duck Address` -- 读取新的 `@duck.com` 地址 - -这个功能会被： - -- 侧边栏 `Email` 旁边的 `Auto` 按钮使用 -- `Auto Run` 流程优先尝试使用 - -## 停止机制 - -扩展内置了停止当前流程的能力： - -- 侧边栏点击 `Stop` -- Background 会广播 `STOP_FLOW` -- 各 content script 会在等待、轮询、sleep、元素查找中尽量中断 - -适合以下场景： - -- 卡在某一步 -- 邮件迟迟不来 -- 页面结构变化导致等待超时 -- Auto 暂停后，明确放弃 Auto、改为手动接管 - -## 状态与数据 - -运行时状态主要使用 `chrome.storage.session` 保存： - -- 当前步骤 -- 每一步状态 -- OAuth 链接 -- 当前邮箱 -- 当前密码 -- localhost 回调地址 -- 账号记录 -- tab 注册信息 -- 各来源最近一次打开的地址（用于打开新地址前清理旧标签） -- Auto 当前阶段、当前轮次、暂停信息 - -配置项另外使用 `chrome.storage.local` 持久化保存： - -- CPA 地址 -- CPA 管理密钥 -- 自定义密码 -- 邮箱服务 -- Inbucket 主机 -- Inbucket 邮箱名 -- Hotmail 账号池与对应令牌 -- 兜底开关 - -特点： - -- 运行时步骤状态是浏览器会话级存储 -- 配置项会持久化保存，关闭浏览器后重新打开仍会恢复 -- 扩展运行期间可在多个步骤之间共享 -- 代码里已启用 `storage.session` 对 content script 的访问 -- 同一来源打开新地址前，会先按来源/站点范围关闭旧标签，避免旧页面残留 - -## 项目结构 - -```txt -background.js 后台主控，编排 1~9 步、Tab 复用、状态管理 -manifest.json 扩展清单 -data/names.js 随机姓名、生日数据 -content/utils.js 通用工具：等待元素、点击、日志、停止控制 -content/vps-panel.js CPA 面板步骤：内部 OAuth 刷新 / Step 10 -content/signup-page.js ChatGPT 官网 + OpenAI 注册/登录页步骤：Step 1 / 2 / 3 / 5 / 7 / 9 -hotmail-utils.js Hotmail 收信相关通用辅助 -mail-provider-utils.js 网页邮箱 provider 配置辅助 -content/duck-mail.js Duck 邮箱自动获取 -content/qq-mail.js QQ 邮箱验证码轮询 -content/mail-163.js 163 / 163 VIP / 126 邮箱验证码轮询 -content/inbucket-mail.js Inbucket mailbox 验证码轮询 -sidepanel/ 侧边栏 UI -``` - -## 常见使用建议 - -### 1. 先单步验证，再开 Auto - -推荐先手动跑通一次： - -1. Step 1 -2. Step 2 -3. Step 3 -4. Step 4 - -确认邮箱和验证码链路稳定后，再使用 `Auto`。 - -### 2. Inbucket 建议使用专用 mailbox - -当前 Inbucket 逻辑只看未读邮件，但还是建议： - -- 给脚本准备一个相对独立的 mailbox -- 避免收件箱里混入过多无关邮件 - -### 3. 自动获取失败时直接手填 - -如果 Duck 页面打不开、Cloudflare 域名未配置、未登录或按钮变化： - -- 直接在 `Email` 输入框中粘贴邮箱 -- 手动点 `Step 3` 时，如果邮箱为空，脚本会先自动尝试获取 Duck 邮箱；失败后再改为手填 -- Auto 暂停时，仍可手动粘贴邮箱后点击 `Continue` - -### 4. 跳过步骤 - -- 每个步骤右侧都会在满足顺序条件时出现一个小按钮，用来直接跳过该步骤 -- 点击后会先弹窗确认；它不会真正执行脚本，只会把该步骤状态改为“已跳过”，从而放行后续步骤 -- 跳过按钮的规则很简单：只要上一步已完成、当前步骤没在运行，就可以使用；Step 1 没有前置步骤，也可直接跳过 -- 如果 Auto 处于暂停状态，点击该按钮会先确认是否接管 Auto - -### 5. Step 8 失败时重点检查 - -补充检查项： - -- 确认回调路径仍然是 `/auth/callback` -- 确认回调 query 里仍然同时包含 `code` 和 `state` -- 如果 CPA 部署在 `localhost`，确认当前看到的页面是真实 OAuth 回调，而不是 CPA 面板自身页面 - -- OAuth 同意页 DOM 是否变化 -- “继续”按钮是否变成了别的文案 -- localhost 回调是否真的触发 -- 浏览器是否允许 debugger 附加 - -## 已知限制 - -- Step 8 对页面结构较敏感 -- Duck 自动获取依赖 Duck 页面真实 DOM -- CPA 面板 DOM 也需要和当前脚本选择器匹配 -- `Auto` 按钮名称和 Step 8 的旧文案还未完全统一，但代码行为以实际实现为准 - -## 调试建议 - -- 打开扩展侧边栏看日志 -- 查看 Service Worker 控制台 -- 查看目标页面的 content script 控制台日志 -- 当某一步频繁失败时，优先检查当前页面选择器是否仍然匹配 - -## 安全说明 - -- 所有状态仅保存在浏览器会话中 -- 没有硬编码你的 CPA 地址、密码或账户 -- 自定义密码只存在当前会话存储中 -- 邮箱和密码会被记录到本轮 `accounts` 中，便于追踪本次运行结果 - -## 来源与致谢 - -本项目早期代码与 [whwh1233/StepFlow-Duck](https://github.com/whwh1233/StepFlow-Duck) 同源，共同历史截至 `387e177e005e9863f3de193ad8b954e9efb5fd1d`。当前维护者最初接触到的是社群内分享的 zip 软件包，当时压缩包内没有 `LICENSE` 文件，也没有任何 GitHub 远程仓库地址或开源协议声明。 - -后续核对发现，原作者也将同源早期代码发布到了 GitHub，并在 `72218aab151a2ff74bf1763684a6370657c7bc57` 提交补充 MIT License。当前仓库已改为 MIT License，并补充原作者署名与来源说明。完整时间线见 [THIRD_PARTY_NOTICES.md](THIRD_PARTY_NOTICES.md)。 - -感谢原作者 whwh1233、Jimmy 以及后续所有贡献者的早期工作和持续改进。当前仓库中的相关服务入口、贡献入口、交流群入口和其他维护者整理的入口，不代表原项目作者背书。 +如果你要继续开发、补链路、加步骤或排查运行态，请再看上面的两份技术文档。 diff --git a/docs/使用教程/使用教程.md b/docs/使用教程/使用教程.md index 79fb6f5..831e7ae 100644 --- a/docs/使用教程/使用教程.md +++ b/docs/使用教程/使用教程.md @@ -36,7 +36,7 @@ 下面这些主题在旧总述里已经提到过，但目前还没有单独的部分文件： -- `HeroSMS` 手机接码扩展使用教程 +- `HeroSMS / 5sim / NexSMS` 手机接码扩展使用教程 - 节点检测与纯净度检查网站使用教程 如果后续收到这些主题的新增内容，优先新开部分，而不是硬塞到现有 9 个文件里。 @@ -77,4 +77,4 @@ `操作间延迟` 默认开启且固定开启。自动流程和手动单步在每个页面输入、选择、点击、提交、继续或授权操作完成后固定等待 2 秒；第一项页面操作不会提前等待。分格 OTP/验证码会先整组填完，然后只等待一次。 -该开关不同于步间间隔，不影响邮箱轮询、短信/WhatsApp 轮询、后台 API、网络重试、后台定时器或存储持久化，也不影响 `confirm-oauth` 和 `platform-verify` 的交互节奏。 +该开关不同于步间间隔，不影响邮箱轮询、短信/WhatsApp 轮询、后台 API、网络重试、后台定时器或存储持久化，也不影响 `confirm-oauth` 和 `platform-verify` 的交互节奏。当前就算读到旧配置里的 `operationDelayEnabled`，扩展也会按“固定开启”处理，不需要再额外找地方手动关闭或恢复。 diff --git a/sidepanel/sidepanel.js b/sidepanel/sidepanel.js index 624d604..0c5aa59 100644 --- a/sidepanel/sidepanel.js +++ b/sidepanel/sidepanel.js @@ -14245,7 +14245,7 @@ btnGpcHelperConvertApiKey?.addEventListener('click', () => { }); btnOpenKiroRsGithub?.addEventListener('click', () => { - openExternalUrl('https://github.com/hank9999/kiro.rs'); + openExternalUrl('https://github.com/QLHazyCoder/kiro.rs'); }); btnGpcHelperBalance?.addEventListener('click', async () => { diff --git a/tests/sidepanel-flow-source-registry.test.js b/tests/sidepanel-flow-source-registry.test.js index eda61c8..58ab6ad 100644 --- a/tests/sidepanel-flow-source-registry.test.js +++ b/tests/sidepanel-flow-source-registry.test.js @@ -51,6 +51,11 @@ test('sidepanel html exposes flow selector and kiro source fields', () => { }); }); +test('sidepanel Kiro GitHub button opens the configured fork', () => { + assert.match(sidepanelSource, /openExternalUrl\('https:\/\/github\.com\/QLHazyCoder\/kiro\.rs'\)/); + assert.doesNotMatch(sidepanelSource, /github\.com\/hank9999\/kiro\.rs/); +}); + test('sidepanel step definitions rerender when active flow changes even if plus/signup settings stay the same', () => { const bundle = [ extractFunction(sidepanelSource, 'normalizeSignupMethod'), diff --git a/开发者AI开发与PR提交流程.md b/开发者AI开发与PR提交流程.md index 49b8bff..4853ef3 100644 --- a/开发者AI开发与PR提交流程.md +++ b/开发者AI开发与PR提交流程.md @@ -54,8 +54,8 @@ gh auth login 6. 开发新功能时，不要为了兼容旧逻辑而保留明显无用的陈旧代码；如果确认无其他代码依赖，应一并清理。 7. 如果旧逻辑本身设计差、实现混乱或者存在 bug，AI 需要继续检查相关调用点；在不影响其他功能的前提下，可以顺手一起修正。 8. 如果改动了 SQL 文件，必须按仓库规则同步本地 MySQL：账号 `root`，密码 `123456`，数据库 `xzs`。 -9. 默认不编译、不跑测试。开发完成后提醒开发者自行测试。 -10. 如果是前端改动且没有新增依赖，只提醒开发者自己测试即可；如果新增了依赖并完成安装，可以自行验证能否启动，验证后要关闭启动占用的端口，并提醒开发者重新启动。 +9. 默认不做无关编译，但代码改动后必须按 [项目开发规范（AI协作）.md](./项目开发规范（AI协作）.md) 执行必要的定向测试与全量回归；无法执行时必须明确说明原因。 +10. 如果是前端改动且需要本地启动验证，可以自行启动后完成最小验证；验证结束后要关闭占用端口，并在结果里明确说明“实际执行了什么、没有执行什么”。 11. PR 标题、PR 正文、PR 评论都用自然中文直接表达，不要写“自动回复”“AI 分析结果如下”这种固定机器人腔。 12. 没有开发者明确授权时，AI 不得擅自合并 PR、关闭 PR、删除远端分支。 13. 必须严格区分“同步 PR 分支”和“合并 PR 到 `dev`”： diff --git a/项目完整链路说明.md b/项目完整链路说明.md index 4b3ce3a..82b8851 100644 --- a/项目完整链路说明.md +++ b/项目完整链路说明.md @@ -4,9 +4,9 @@ 使用建议： -1. 先阅读 [项目文件结构说明.md](c:/Users/projectf/Downloads/codex注册扩展/项目文件结构说明.md) +1. 先阅读 [项目文件结构说明.md](./项目文件结构说明.md) 2. 再阅读本文 -3. 最后阅读 [项目开发规范（AI协作）.md](c:/Users/projectf/Downloads/codex注册扩展/项目开发规范（AI协作）.md) +3. 最后阅读 [项目开发规范（AI协作）.md](./项目开发规范（AI协作）.md) ## 1. 项目目标 @@ -34,7 +34,7 @@ ### 2.1 Sidepanel -[sidepanel/sidepanel.html](c:/Users/projectf/Downloads/codex注册扩展/sidepanel/sidepanel.html) + [sidepanel/sidepanel.js](c:/Users/projectf/Downloads/codex注册扩展/sidepanel/sidepanel.js) + [sidepanel/account-pool-ui.js](c:/Users/projectf/Downloads/codex注册扩展/sidepanel/account-pool-ui.js) + [sidepanel/update-service.js](c:/Users/projectf/Downloads/codex注册扩展/sidepanel/update-service.js) + [sidepanel/contribution-content-update-service.js](c:/Users/projectf/Downloads/codex注册扩展/sidepanel/contribution-content-update-service.js) +[sidepanel/sidepanel.html](./sidepanel/sidepanel.html) + [sidepanel/sidepanel.js](./sidepanel/sidepanel.js) + [sidepanel/account-pool-ui.js](./sidepanel/account-pool-ui.js) + [sidepanel/update-service.js](./sidepanel/update-service.js) + [sidepanel/contribution-content-update-service.js](./sidepanel/contribution-content-update-service.js) 职责： @@ -48,18 +48,23 @@ - 管理顶部“贡献”按钮与贡献模式主面板；贡献模式本身是 sidepanel 的运行态 UI 模式，不是新的 `panelMode` 来源 - 在贡献模式下复用同一套主自动流程启动，并在面板内展示贡献链路的 `OAUTH / 回调 / 总状态` 三块实时状态 - 在顶部“贡献/使用”按钮下方展示一个非强制的内容更新轻提示；提示来源于 `flowpilot.qlhazycoder.top` 的公开公告 / 教程摘要，用户关闭后仅对当前 `promptVersion` 静默，下次内容版本变化后会重新出现 +- sidepanel 首次初始化后会按本地一次性关闭标记决定是否弹出“新手引导”提示；确认后直接打开贡献入口，关闭后仅对该引导静默 - 在 sidepanel 初始化和点击“自动”按钮前刷新一次贡献站公开内容摘要；点击“自动”时会先冻结当时输入或号池锁定的目标轮数，后续刷新、保存和后台状态回灌不能把启动目标改回旧的 1 轮；如果刷新失败，不阻塞主自动流程 +- 当 `Auto` 目标轮数达到风险阈值且当前没有配置“节点轮询”能力时，会先弹出风险提醒，避免连续使用单节点跑大量轮次导致更容易命中手机号验证 - 在日志区通过“记录”按钮打开独立的账号记录覆盖层，并展示成功/失败/停止/重试统计与分页列表；同一轮同时出现邮箱和手机号时只显示一条组合记录，按本轮 `accountIdentifierType` 展示主身份，另一种身份作为副行显示 - 查询 GitHub Releases 并展示更新卡片；当前更新服务会区分 `Ultra`、历史 `Pro` 与 legacy `v` 三个版本族，排序时固定以 `Ultra` 为最高正式系列，同时会在读取缓存后重新排序，避免历史 `Pro` 或 `v` 版本误显示为比 `Ultra` 更新 - 展示一个单独的“接码”开关、注册方式 `signupMethod` 与“接码平台”下拉；接码平台当前支持 HeroSMS / 5sim / NexSMS。普通模式下开启接码后可把注册方式切到手机号注册，并在 OAuth 登录链路命中手机号登录验证码页时继续复用同一手机号续跑短信验证 - 侧栏在接码卡内提供一个独立运行态“注册手机号”输入框，位于接码订单运行状态下方；第 2 步自动拿到号码后立即回填，用户手动接管手机号注册时也可以直接改写这一个运行态槽位。这个输入框表达账号身份，不等同于接码订单；后续自动拉短信仍依赖 `signupPhoneActivation / signupPhoneCompletedActivation` -- 展示 `Plus 模式` 开关与 Plus 支付方式配置；支付方式支持 PayPal / GoPay / GPC，PayPal 展示账号池下拉与添加按钮，GoPay 展示手机号和 PIN，GPC 展示只读 API 地址、API Key、专用手机号、OTP 渠道、本地 OTP helper 开关与 URL、PIN；GPC 的 `购买卡密` 按钮打开卡密购买页，`转换 API Key` 按钮打开 `https://gpc.qlhazycoder.top/`；步骤列表切换为 Plus 模式步骤定义，普通模式的注册成功等待步骤不再显示或执行，登录验证码步骤会移动到 Plus 可见第 11 步 +- 展示 `Plus 模式` 开关、`账号接入策略` 与 `Plus 支付` 配置；`账号接入策略` 固定放在 `Plus 支付` 上方，并根据当前来源动态提供 `OAuth / 导入当前 ChatGPT 会话到 CPA / 导入当前 ChatGPT 会话到 SUB2API` 等可用选项，不支持的来源会直接禁用为仅 OAuth；支付方式支持 PayPal / GoPay / GPC，PayPal 展示账号池下拉与添加按钮，GoPay 展示手机号和 PIN，GPC 展示只读 API 地址、API Key、专用手机号、OTP 渠道、本地 OTP helper 开关与 URL、PIN；GPC 的 `购买卡密` 按钮打开卡密购买页，`转换 API Key` 按钮打开 `https://gpc.qlhazycoder.top/`；步骤列表会按支付方式和账号接入策略动态切换，普通模式的注册成功等待步骤不再显示或执行；Plus 模式下手机号注册不可用，只允许邮箱注册 - 展示 `执行范围` 配置；当前 UI 只在 codex/openai flow 显示，保存为通用的 `stepExecutionRangeByFlow`，用于指定允许执行的起止步骤。开启后，范围外节点在侧栏中显示为禁用态，手动按钮、手动跳过入口与进度计数只按允许节点计算。 - 为 Hotmail / 2925 账号池复用同一套“添加账号 / 取消添加 / 批量导入 / 收起列表”表单交互；共享的显隐控制放在 `sidepanel/account-pool-ui.js`，各自 manager 只保留 provider 相关字段校验与业务操作 +- `Cloudflare Temp Email` 在侧栏中有独立区域，支持“按注册邮箱查信 / 按接收邮箱查信”切换、可编辑域名列表、随机子域名开关，以及教程/部署入口；域名选择由 `sidepanel/editable-list-picker.js` 统一承接 +- `SUB2API` 目标在分组配置下方额外暴露 `账号优先级`；该值会随设置一起持久化，并在后台直连创建账号时原样透传给 SUB2API 管理接口 +- 点击“自动”或其他自动化入口时，sidepanel 会附带当前浏览器窗口 ID；后台后续查找、复用和接管标签页时优先锁定在这一个 automation window 内，避免串到其他窗口 ### 2.2 Background Service Worker -[background.js](c:/Users/projectf/Downloads/codex注册扩展/background.js) +[background.js](./background.js) 职责： @@ -71,7 +76,7 @@ ### 2.3 Content Scripts -[content](c:/Users/projectf/Downloads/codex注册扩展/content) +[content](./content) 职责： @@ -93,7 +98,7 @@ ### 3.1 扩展入口 -[manifest.json](c:/Users/projectf/Downloads/codex注册扩展/manifest.json) 声明： +[manifest.json](./manifest.json) 声明： - `background.service_worker = background.js` - `side_panel.default_path = sidepanel/sidepanel.html` @@ -101,7 +106,7 @@ ### 3.2 背景层装配 -[background.js](c:/Users/projectf/Downloads/codex注册扩展/background.js) 通过 `importScripts(...)` 依次加载： +[background.js](./background.js) 通过 `importScripts(...)` 依次加载： - 共享数据与纯工具 - provider 纯逻辑 @@ -119,21 +124,40 @@ ### 3.3 Flow / Source 注册 -[shared/flow-registry.js](c:/Users/projectf/Downloads/codex注册扩展/shared/flow-registry.js) 定义 flow、来源、可见设置分组、runtime source 与 driver。 -[shared/source-registry.js](c:/Users/projectf/Downloads/codex注册扩展/shared/source-registry.js) 负责把 flow runtime source 与共享 mail source 合并成统一来源视图。 -[shared/flow-capabilities.js](c:/Users/projectf/Downloads/codex注册扩展/shared/flow-capabilities.js) 负责把当前 flow/source 解析成 sidepanel 的能力矩阵。 -[shared/settings-schema.js](c:/Users/projectf/Downloads/codex注册扩展/shared/settings-schema.js) 负责把旧平铺字段与新的 `flows.*` 配置结构互转。 +[shared/flow-registry.js](./shared/flow-registry.js) 定义 flow、来源、可见设置分组、runtime source 与 driver。 +[shared/source-registry.js](./shared/source-registry.js) 负责把 flow runtime source 与共享 mail source 合并成统一来源视图。 +[shared/flow-capabilities.js](./shared/flow-capabilities.js) 负责把当前 flow/source 解析成 sidepanel 的能力矩阵。 +[shared/settings-schema.js](./shared/settings-schema.js) 负责把旧平铺字段与新的 `flows.*` 配置结构互转。 这意味着： - flow 是第一层边界，source 是第二层边界 - “显示什么配置”“允许什么步骤”“哪些运行态字段属于哪个 flow” 都不再由 sidepanel 或 background 临时硬编码 - 共享服务目前主要是 `email` 与 `proxy` +- OpenAI 的 target capability 还统一决定 Plus 模式下 `账号接入策略` 的可选项：`cpa` 支持 `oauth / cpa_codex_session`，`sub2api` 支持 `oauth / sub2api_codex_session`，`codex2api` 当前仅支持 `oauth` + +### 3.3.1 Workflow 与运行态基础设施 + +[background/workflow-engine.js](./background/workflow-engine.js) 负责把当前 flow 的 workflow 节点定义变成统一的执行视图，包括： + +- 节点默认状态 `pending` +- 当前 workflow 的节点顺序与 `nodeId` +- `next` 后继节点解析 +- `getFirstUnfinishedNodeId / getRunningNodeIds / hasSavedProgress` 这类自动运行与恢复入口共享判断 + +[background/runtime-state.js](./background/runtime-state.js) 则负责把 session 运行态整理成统一的结构化视图与 patch 入口： + +- `runtimeState`：当前运行中的 node、nodeStatuses、activeRunId 等核心执行态 +- `sharedState`：automation window、tab registry、最近来源 URL 这类跨 flow 共享运行态 +- `serviceState`：代理、邮箱等共享服务运行态 +- `flowState`：OpenAI / Kiro 各自的 flow 私有运行态 + +这两个模块的作用，是把“当前该跑哪些节点”“当前 state 应该怎么看”“前后台恢复时如何合并 patch”从 `background.js` 主入口里抽离出来，避免再次退回到旧的平铺 step 状态机。 ### 3.4 步骤注册 -[data/step-definitions.js](c:/Users/projectf/Downloads/codex注册扩展/data/step-definitions.js) 提供共享步骤元数据，并按当前 `activeFlowId` 输出 flow-specific workflow。`openai` flow 会继续按 `plusPaymentMethod / signupMethod` 动态解析步骤标题与节点集合，`kiro` flow 则输出固定的 9 节点注册/桌面授权/上传 workflow。 -[background/steps/registry.js](c:/Users/projectf/Downloads/codex注册扩展/background/steps/registry.js) 负责把“workflow node 元数据”映射到“步骤执行器”，同时保留 `flowId / nodeId / displayOrder / executeKey` 等稳定节点元数据。 +[data/step-definitions.js](./data/step-definitions.js) 提供共享步骤元数据，并按当前 `activeFlowId` 输出 flow-specific workflow。`openai` flow 会继续按 `plusPaymentMethod / signupMethod / plusAccountAccessStrategy` 动态解析步骤标题与节点集合：当 Plus 模式为邮箱注册且来源支持时，原本的 OAuth 尾链可以被替换成 `sub2api-session-import` 或 `cpa-session-import`；`kiro` flow 则输出固定的 9 节点注册/桌面授权/上传 workflow。 +[background/steps/registry.js](./background/steps/registry.js) 负责把“workflow node 元数据”映射到“步骤执行器”，同时保留 `flowId / nodeId / displayOrder / executeKey` 等稳定节点元数据。 这意味着： @@ -142,15 +166,32 @@ - 新增步骤时不需要重命名后续文件 - 非 OpenAI flow 不需要复用旧的数字 step registry；直接按 node workflow 注册即可 +### 3.4.1 验证码规则注册 + +[background/mail-rule-registry.js](./background/mail-rule-registry.js) 负责按当前 `activeFlowId` 选择验证码规则构造器。[flows/openai/mail-rules.js](./flows/openai/mail-rules.js) 则提供 OpenAI flow 当前使用的注册验证码 / 登录验证码规则。 + +这层统一产出： + +- `senderFilters / subjectFilters / codePatterns` +- `targetEmail / targetEmailHints` +- `mail2925MatchTargetEmail` +- `maxAttempts / includeBody / filterAfterTimestamp` 这类轮询 payload + +它的职责边界是： + +- `background/verification-flow.js` 只消费统一规则 payload，不再在每个 provider 或内容脚本里各自硬写一套 OpenAI 验证码过滤条件。 +- “邮件从哪里读”由 provider 决定，“哪封邮件算命中验证码”优先由规则注册层决定。 +- 新 flow 如需接入邮箱验证码，应优先新增自己的 mail rules builder，而不是继续改写 OpenAI 规则。 + ### 3.5 日志步骤号链路 日志步骤号不再从日志正文里提取，也不再兼容旧的 `步骤 X` / `Step X` 文本解析。 - 后台统一通过 `addLog(message, level, { step, stepKey })` 写入结构化日志条目。 - 内容脚本通过 `log(message, level, { step, stepKey })` 上报结构化日志，`reportComplete` / `reportError` 的步骤号只走消息字段和日志元数据。 -- [sidepanel/sidepanel.js](c:/Users/projectf/Downloads/codex注册扩展/sidepanel/sidepanel.js) 只读取 `entry.step` 渲染步骤标签；日志正文只作为正文展示，不参与步骤号判断。 -- Plus 模式后半段复用普通执行器时，必须先解析当前可见步骤：`oauth-login=10`、`fetch-login-code=11`、`confirm-oauth=12`、`platform-verify=13`，再把该步骤号传入日志、完成信号和内容脚本 payload。 -- 平台验证链路中，CPA / SUB2API / Codex2API 都按当前 `platform-verify` 可见步骤上报；SUB2API 和 Codex2API 的协议式分支由后台直接完成 callback 交换与账号创建，不再依赖后台页面内容脚本修正步骤号。 +- [sidepanel/sidepanel.js](./sidepanel/sidepanel.js) 只读取 `entry.step` 渲染步骤标签；日志正文只作为正文展示，不参与步骤号判断。 +- Plus 模式后半段不再固定只有一条 OAuth 复用尾链；当 `plusAccountAccessStrategy` 选择会话导入时，尾节点会直接变成 `sub2api-session-import` 或 `cpa-session-import`，并按当前可见步骤写日志、完成信号和错误信号。只有走 `oauth` 时，才会进入 `oauth-login -> fetch-login-code -> confirm-oauth -> platform-verify` 这组复用节点。 +- 平台验证链路只在 OAuth 尾链下出现；CPA / SUB2API / Codex2API 都按当前 `platform-verify` 可见步骤上报。若尾链改为会话导入，则不再经过 `platform-verify`，而是由各自的 session-import 节点直接完成平台接入。 ## 4. 状态与存储链路 @@ -159,6 +200,8 @@ 保存运行态： - 当前 flow 选择：`activeFlowId / flowId` +- `runtimeState` 结构化运行快照，以及它投影出来的顶层兼容字段 +- `automationWindowId`：来自 sidepanel 启动 payload 或 sender tab，用于把后续找 tab、复用 tab、接管来源页尽量锁定在同一个浏览器窗口内 - 当前步骤状态 - 当前 sidepanel UI 模式 `contributionMode` - 贡献 OAuth 会话字段： @@ -201,6 +244,8 @@ 补充： +- `background/runtime-state.js` 会把会话运行态统一整理成 `runtimeState / sharedState / serviceState / flowState` 四层结构；当前顶层那些 `currentNodeId / nodeStatuses / automationWindowId / ipProxyApplied* / flowId / runId` 等兼容字段，都是这份结构化运行态的投影视图，不应再当成另一套平行状态机维护。 +- `automationWindowId` 会同时存在于顶层兼容字段与 `runtimeState.sharedState` 视图中；真正目的是约束自动化只在当前 sidepanel 所在窗口里继续接管标签页，而不是把不同窗口里的同类页面串到一起。 - `content/mail-2925.js` 会把“当前验证码步骤启动会话”对应的已试验证码写入 `chrome.storage.session`，键为 `seen2925CodeState`；同一个 Step 4 / Step 8 会话里试过的验证码不会再次提交，新会话开始时会重置。 ### 4.2 `chrome.storage.local` @@ -210,9 +255,11 @@ - 当前 flow 与目标配置：`activeFlowId`、OpenAI 的 `panelMode`（归一到 integration target）、Kiro 的 `flows.kiro.targetId` - flow-aware 配置树：`flows.openai.*`、`flows.kiro.*` - CPA / SUB2API 配置 +- SUB2API 持久配置中的 `sub2apiGroupName / sub2apiGroupNames / sub2apiAccountPriority / sub2apiDefaultProxyName` - Codex2API 配置 - IP 代理持久配置：`ipProxyEnabled`、服务商、模式、API 地址、服务商配置快照、账号列表、固定 Host / Port / Protocol / Username / Password、地区参数、session 与自动切换阈值 - Plus 模式开关 `plusModeEnabled` +- Plus 账号接入策略 `plusAccountAccessStrategy` - Plus 支付方式 `plusPaymentMethod`，GoPay 配置 `gopayPhone / gopayPin`，GPC helper 配置 `gopayHelperApiUrl / gopayHelperApiKey / gopayHelperPhoneMode / gopayHelperPhoneNumber / gopayHelperOtpChannel / gopayHelperLocalSmsHelperEnabled / gopayHelperLocalSmsHelperUrl / gopayHelperPin`；其中 GPC API 地址固定归一为 `https://gpc.qlhazycoder.top` - PayPal 账号池配置 `paypalAccounts / currentPayPalAccountId`，以及供后台步骤兼容读取的 `paypalEmail / paypalPassword` - 邮箱 provider 配置 @@ -223,12 +270,14 @@ - 2925 是否启用号池模式 `mail2925UseAccountPool` - 2925 当前选中的号池账号 ID `currentMail2925AccountId` - Cloudflare / Temp Email 设置 +- Cloudflare Temp Email 细分配置：`cloudflareTempEmailLookupMode / cloudflareTempEmailUseRandomSubdomain / cloudflareTempEmailDomain / cloudflareTempEmailDomains` - 注册方式 `signupMethod` - 接码开关、接码平台 `phoneSmsProvider`，以及 HeroSMS / 5sim 各自的 API Key、国家/地区、价格上限和平台扩展设置 - iCloud 相关偏好 - LuckMail API 配置 - Kiro 目标配置：`flows.kiro.targetId` 与 `flows.kiro.targets["kiro-rs"] = { baseUrl, apiKey }` - 自动运行默认配置 +- 操作间延迟兼容字段 `operationDelayEnabled`：当前会被严格归一为启用；sidepanel 不再暴露真正关闭入口，但内容脚本仍通过 `chrome.storage.local` 监听该字段完成兼容同步 - OAuth 授权后链总超时开关 `oauthFlowTimeoutEnabled`：默认开启；关闭后会立即清空已存在的 OAuth 总预算 deadline，仅保留各步骤本地等待超时 - flow 级执行范围配置 `stepExecutionRangeByFlow`：按 flowId 保存，例如 `openai: { enabled: true, fromStep: 3, toStep: 6 }`；侧栏中的 `codex` 会归一到内部默认 flowId `openai`。这是通用配置结构，但当前只给 codex/openai flow 暴露 UI。 - 账号运行历史 `accountRunHistory`（以统一账号标识为主键；邮箱账号保留邮箱主键，手机号注册保留手机号主键；同一轮中后续绑定的邮箱或手机号会写入同一条记录的副身份字段，保存最近一次状态：成功/失败/停止） @@ -239,7 +288,7 @@ - `contributionMode` 不属于持久配置，也不参与导入/导出；它只存在于运行态 - `panelMode` 现在只代表 `openai` flow 下的 `cpa | sub2api | codex2api` 三个 legacy 来源；`kiro` flow 使用独立的 `flows.kiro.targetId` -账号运行历史会默认通过 [scripts/hotmail_helper.py](c:/Users/projectf/Downloads/codex注册扩展/scripts/hotmail_helper.py) 的本地 helper 地址尝试同步写入 `data/account-run-history.json` 快照文件；如果 helper 没有运行，则静默跳过，不再要求用户先手动打开一个“本地同步”开关。 +账号运行历史会默认通过 [scripts/hotmail_helper.py](./scripts/hotmail_helper.py) 的本地 helper 地址尝试同步写入 `data/account-run-history.json` 快照文件；如果 helper 没有运行，则静默跳过，不再要求用户先手动打开一个“本地同步”开关。 这条配置链路独立于 `mailProvider` 和 Hotmail 的接码模式。 ### 4.3 状态广播 @@ -307,7 +356,7 @@ IP 代理模块在同步、切换、Change、出口探测和自动运行成功 ### 5.1 READY 机制 -[content/utils.js](c:/Users/projectf/Downloads/codex注册扩展/content/utils.js) 在脚本加载后会发送 `CONTENT_SCRIPT_READY`。 +[content/utils.js](./content/utils.js) 在脚本加载后会发送 `CONTENT_SCRIPT_READY`。 后台收到后会： @@ -317,7 +366,7 @@ IP 代理模块在同步、切换、Change、出口探测和自动运行成功 ### 5.2 队列与重试 -[background/tab-runtime.js](c:/Users/projectf/Downloads/codex注册扩展/background/tab-runtime.js) 负责： +[background/tab-runtime.js](./background/tab-runtime.js) 负责： - `queueCommand` - `flushCommand` @@ -331,14 +380,25 @@ IP 代理模块在同步、切换、Change、出口探测和自动运行成功 - 邮箱页或注册页能在注入恢复后继续执行 - 用户点击 Stop 后，标签完成等待、注入后的短暂延迟和内容脚本重试等待会尽快中断，不会因为底层轮询还在 sleep 而继续往下恢复 +### 5.3 操作间延迟注入层 + +[content/operation-delay.js](./content/operation-delay.js) 是内容脚本侧的统一交互节奏层。 + +当前接入方式： + +- 它会在 `content/utils.js` 之后注入到需要真实页面交互的 bundle，例如 `signup-page`、`plus-checkout`、`paypal-flow`、`gopay-flow`，以及 `mail-2925` 这类仍有页面级点击/清理动作的链路。 +- 它主要包装输入、选择、点击、提交与短等待这类页面内操作；当前默认节奏为 2 秒。 +- `confirm-oauth`、`platform-verify` 这类后台节点不走这一层；邮箱 API 轮询、短信 API 轮询、WhatsApp 读码和其他纯后台请求也不应被硬塞进 2 秒延迟。 +- `operationDelayEnabled` 这个持久字段现在仍会被内容脚本监听，但对外语义已经等价于“始终启用”，保留它主要是为了兼容旧配置与统一注入同步。 + ## 6. 手动步骤完整链路 ### Step 1 文件： -- [background/steps/open-chatgpt.js](c:/Users/projectf/Downloads/codex注册扩展/background/steps/open-chatgpt.js) -- [content/signup-page.js](c:/Users/projectf/Downloads/codex注册扩展/content/signup-page.js) +- [background/steps/open-chatgpt.js](./background/steps/open-chatgpt.js) +- [content/signup-page.js](./content/signup-page.js) 流程： @@ -355,7 +415,7 @@ IP 代理模块在同步、切换、Change、出口探测和自动运行成功 文件： -- [background/steps/submit-signup-email.js](c:/Users/projectf/Downloads/codex注册扩展/background/steps/submit-signup-email.js) +- [background/steps/submit-signup-email.js](./background/steps/submit-signup-email.js) 流程： @@ -375,7 +435,7 @@ IP 代理模块在同步、切换、Change、出口探测和自动运行成功 文件： -- [background/steps/fill-password.js](c:/Users/projectf/Downloads/codex注册扩展/background/steps/fill-password.js) +- [background/steps/fill-password.js](./background/steps/fill-password.js) 流程： @@ -400,9 +460,9 @@ IP 代理模块在同步、切换、Change、出口探测和自动运行成功 文件： -- [background/steps/fetch-signup-code.js](c:/Users/projectf/Downloads/codex注册扩展/background/steps/fetch-signup-code.js) -- [background/steps/fetch-login-code.js](c:/Users/projectf/Downloads/codex注册扩展/background/steps/fetch-login-code.js) -- [background/verification-flow.js](c:/Users/projectf/Downloads/codex注册扩展/background/verification-flow.js) +- [background/steps/fetch-signup-code.js](./background/steps/fetch-signup-code.js) +- [background/steps/fetch-login-code.js](./background/steps/fetch-login-code.js) +- [background/verification-flow.js](./background/verification-flow.js) 这两步共享验证码主流程： @@ -439,7 +499,7 @@ IP 代理模块在同步、切换、Change、出口探测和自动运行成功 文件： -- [background/steps/fill-profile.js](c:/Users/projectf/Downloads/codex注册扩展/background/steps/fill-profile.js) +- [background/steps/fill-profile.js](./background/steps/fill-profile.js) 流程： @@ -453,7 +513,7 @@ IP 代理模块在同步、切换、Change、出口探测和自动运行成功 文件： -- [background/steps/wait-registration-success.js](c:/Users/projectf/Downloads/codex注册扩展/background/steps/wait-registration-success.js) +- [background/steps/wait-registration-success.js](./background/steps/wait-registration-success.js) 流程： @@ -466,7 +526,7 @@ IP 代理模块在同步、切换、Change、出口探测和自动运行成功 文件： -- [background/steps/oauth-login.js](c:/Users/projectf/Downloads/codex注册扩展/background/steps/oauth-login.js) +- [background/steps/oauth-login.js](./background/steps/oauth-login.js) 流程： @@ -494,7 +554,7 @@ IP 代理模块在同步、切换、Change、出口探测和自动运行成功 文件： -- [background/steps/fetch-login-code.js](c:/Users/projectf/Downloads/codex注册扩展/background/steps/fetch-login-code.js) +- [background/steps/fetch-login-code.js](./background/steps/fetch-login-code.js) 流程： @@ -529,7 +589,7 @@ IP 代理模块在同步、切换、Change、出口探测和自动运行成功 文件： -- [background/steps/confirm-oauth.js](c:/Users/projectf/Downloads/codex注册扩展/background/steps/confirm-oauth.js) +- [background/steps/confirm-oauth.js](./background/steps/confirm-oauth.js) 流程： @@ -555,7 +615,12 @@ IP 代理模块在同步、切换、Change、出口探测和自动运行成功 文件： -- [background/steps/platform-verify.js](c:/Users/projectf/Downloads/codex注册扩展/background/steps/platform-verify.js) +- [background/steps/platform-verify.js](./background/steps/platform-verify.js) + +说明： + +- 本节描述的是普通 OAuth 尾链里的 `platform-verify` 节点。 +- 如果 Plus 模式下把 `账号接入策略` 切到 `cpa_codex_session` 或 `sub2api_codex_session`，尾节点不会进入这里，而是分别走 `cpa-session-import` 或 `sub2api-session-import`。 流程： @@ -580,7 +645,7 @@ SUB2API 补充： - 步骤 7 直接调用 `POST /api/v1/auth/login` 登录管理接口，再调用 `/api/v1/admin/groups/all` 校验目标 openai 分组；如果配置了默认代理，会读取 `/api/v1/admin/proxies/all?with_count=true` 并按名称或 ID 选择代理。 - 步骤 7 调用 `POST /api/v1/admin/openai/generate-auth-url` 获取 `auth_url / session_id / state`，并把目标分组 ID、代理 ID、草稿账号名写入运行态。 -- 步骤 10 / Plus 第 13 步直接用 localhost callback 中的 `code / state` 调用 `POST /api/v1/admin/openai/exchange-code`，再用返回的 OpenAI token 信息调用 `POST /api/v1/admin/accounts` 创建 SUB2API 账号。 +- 步骤 10，以及 Plus 仍走 OAuth 尾链时的 `platform-verify` 节点，会直接用 localhost callback 中的 `code / state` 调用 `POST /api/v1/admin/openai/exchange-code`，再用返回的 OpenAI token 信息调用 `POST /api/v1/admin/accounts` 创建 SUB2API 账号。 - SUB2API 主链路不再打开后台页面，也不再依赖 `content/sub2api-panel.js` 的 DOM 自动化；该内容脚本仅保留为旧后台页面路径的兼容能力。 贡献模式补充： @@ -591,32 +656,59 @@ SUB2API 补充： ## 6.1 Plus 模式链路 -Plus 模式通过 `plusModeEnabled` 开启，目标是在普通注册资料完成后，不执行普通模式 Step 6 注册成功等待，而是先完成 Plus 支付链路，再复用现有 OAuth 后半段。 +Plus 模式通过 `plusModeEnabled` 开启，核心目标是在普通注册资料完成后，先完成 Plus 支付，再根据 `账号接入策略` 决定后半段是继续走 OAuth，还是直接把当前 ChatGPT 已登录会话导入目标平台。 -Plus 模式可见步骤： +先说明边界： -1. 第 1~5 步：沿用普通注册入口、邮箱、密码、注册验证码、资料填写链路。 -2. 第 6 步 `创建 Plus Checkout`：PayPal / GoPay 打开已登录 ChatGPT 页面，通过 `/api/auth/session` 读取 accessToken，再请求 `https://chatgpt.com/backend-api/payments/checkout` 创建 `chatgptplusplan` 的 checkout session。PayPal 使用 `DE / EUR` 与 `https://chatgpt.com/checkout/openai_ie/{checkout_session_id}`；GoPay 使用 `ID / IDR` 与 `https://chatgpt.com/checkout/openai_llc/{checkout_session_id}`；GPC helper 模式改为把 accessToken 和 `gopayHelperPhoneMode` 提交到 `gopayHelperApiUrl` 的 `/api/gp/tasks`，并通过 `gopayHelperApiKey` 发送 `X-API-Key` 认证；自动模式只传 `phone_mode=auto`，手动模式额外传手机号、国家区号和 `otp_channel`，创建后保存 `task_id`；当前默认 GPC API 地址为 `https://gpc.qlhazycoder.top`。 -3. 第 7 步 `填写账单并提交订阅`：PayPal / GoPay 仍走 checkout 页面与 Stripe iframe 自动化；GPC helper 模式不再操作 checkout iframe，而是轮询 `/api/gp/tasks/{task_id}`。自动模式只等待远端 `completed` 后继续后续步骤；手动模式根据远端 `api_waiting_for` 依次向 `/otp` 和 `/pin` 提交验证码与 PIN。若侧栏启用本地 OTP helper，后台会轮询 `gopayHelperLocalSmsHelperUrl` 的 `/latest-otp?phone=...&consume=1` 接口，按当前 GPC 手机号读取并消费当前 OTP 通道的验证码；未开启本地 helper 时才弹出手动 OTP 输入框。仓库内置的 `scripts/gpc_sms_helper_macos.py` 是 macOS Messages/本地通知兼容读取实现，其他通道需要提供兼容的本地 `/latest-otp` 或 `/otp` 接口。 -4. 仅 PayPal / GoPay 会继续显示第 8 步：该步按当前支付方式显示为 `PayPal 登录与授权` 或 `GoPay 手机验证与授权`，底层 step key 仍为 `paypal-approve`。 -5. 第 9 步 `订阅回跳确认` 仅在 PayPal / GoPay 模式下等待授权后回跳到 ChatGPT / OpenAI 页面，页面加载完成后固定等待 1 秒。GPC helper 模式在第 7 步任务完成后会直接进入 Plus 可见第 10 步 OAuth 登录。 -6. 第 10 步：复用原 Step 7 OAuth 登录执行器，但状态和日志按 Plus 可见第 10 步记录。 -7. 第 11 步：复用原 Step 8 登录验证码执行器，但状态和日志按 Plus 可见第 11 步记录。 -8. 第 12 步：复用原 Step 9 OAuth 同意页点击和 localhost callback 捕获执行器，但状态和日志按 Plus 可见第 12 步记录。 -9. 第 13 步：复用原 Step 10 CPA / SUB2API / Codex2API 平台回调验证执行器，但状态和日志按 Plus 可见第 13 步记录。 +- Plus 模式不是固定一套步骤数量，前缀会随着 `PayPal / GoPay / GPC` 变化，尾链又会随着 `账号接入策略` 变化。 +- Plus 模式只允许邮箱注册；一旦开启 Plus，手机号注册入口会被 capability 层直接禁用。 +- `账号接入策略` 只在 `openai` flow、Plus 已开启、且当前是邮箱注册时才生效。 -以上复用步骤的日志标签、完成信号和错误信号都以结构化 `step` 为准，不再允许靠日志正文中的固定步骤号修正显示。 +前缀链路按支付方式分三类： -隐藏与跳过规则： +1. `PayPal` + - 创建 Plus Checkout + - 填写账单并提交订单 + - PayPal 登录与授权 + - 订阅回跳确认 +2. `GoPay` + - 打开 GoPay 订阅页 + - 等待当前页面完成 GoPay 订阅确认 +3. `GPC` + - 创建 GPC 订单 + - 轮询远端任务，按需提交 OTP / PIN，直到任务完成 -- 普通模式 Step 6 `等待注册成功`：Plus 模式下隐藏且不执行，因为 Plus Checkout 创建会直接承接当前 ChatGPT 登录态。 -- 原 Step 8 `获取登录验证码`：Plus 模式下移动到可见第 11 步，继续负责登录验证码页的收码与提交。 -- 原 Step 9 不能跳过；它负责点击 OAuth 同意页并捕获 `localhostUrl`。 -- 原 Step 10 不能跳过；它依赖 `localhostUrl` 完成平台侧账号创建或回调验证。 +支付前缀完成后，尾链有两种模式： + +1. `OAuth` + - 继续进入 `oauth-login -> fetch-login-code -> confirm-oauth -> platform-verify` + - `platform-verify` 会按当前来源分别落到 CPA、SUB2API 或 Codex2API 的平台接入逻辑 +2. `当前 ChatGPT 会话直导` + - `sub2api_codex_session`：尾链直接切成 `sub2api-session-import` + - `cpa_codex_session`：尾链直接切成 `cpa-session-import` + - 这两条尾链都不再进入 `oauth-login / fetch-login-code / confirm-oauth / platform-verify` + +来源能力限制如下： + +- `CPA` 支持 `oauth`、`cpa_codex_session` +- `SUB2API` 支持 `oauth`、`sub2api_codex_session` +- `Codex2API` 当前只支持 `oauth` + +直导尾链的真实行为： + +- `sub2api-session-import` 会优先复用 Plus 过程中已经登记的 ChatGPT 标签页；如果没有，再回退到当前活动的 `chatgpt.com / chat.openai.com / openai.com` 已登录标签页。 +- `cpa-session-import` 使用同样的标签页选择策略，读取当前会话、accessToken 和可解析的账号信息后，直接调用 CPA 管理接口导入。 +- 两个导入尾节点都由后台直接完成，不依赖平台后台页面 DOM 自动化。 + +隐藏与替换规则： + +- 普通模式的 `等待注册成功` 在 Plus 模式下隐藏且不执行。 +- 当尾链切到 session import 时，被替换掉的是原本的整段 OAuth 后链，而不是只替换某一个固定编号步骤。 +- 只有 `账号接入策略 = oauth` 时，才会出现 `platform-verify`。 等待模型： -- Plus Checkout 和 PayPal 专用步骤使用“无限等待但可停止”的后台等待 helper。 +- Plus Checkout、PayPal、GoPay 手动确认与 GPC 任务轮询，都使用“可停止的后台等待”模型；等待过程中仍保持 Stop 可打断。 ## 6.2 Kiro Flow 链路 @@ -675,7 +767,9 @@ Kiro flow 的目标不是复用 OpenAI 注册链，而是独立完成“Kiro 官 ## 7. 邮箱与 provider 链路 -### 7.1 2026-04-17 补充：Gmail / 2925 统一别名邮箱链路 +### 7.1 共享邮箱生成补充 + +#### 7.1.1 Gmail / 2925 统一别名邮箱链路 本轮将 Gmail 与 `2925 + provide` 的注册邮箱逻辑统一收敛为“共享别名邮箱链路”： @@ -705,7 +799,7 @@ Kiro flow 的目标不是复用 OpenAI 注册链，而是独立完成“Kiro 官 - `gmailBaseEmail` - `mail2925BaseEmail` -### 7.1.1 2026-04-23 补充：自定义邮箱池链路 +#### 7.1.2 自定义邮箱池链路 本轮新增 `custom-pool` 生成方式，用于把一批已准备好的邮箱按顺序并入现有自动流，而不是继续为每种邮箱页面单独适配一套“新地址生成器”。 @@ -719,7 +813,7 @@ Kiro flow 的目标不是复用 OpenAI 注册链，而是独立完成“Kiro 官 6. 如果当前目标轮次超出了邮箱池数量，后台会直接报错提示数量不一致 7. 自定义邮箱池只负责“本轮注册邮箱分配”，实际收码仍由当前 `mailProvider` 对应的既有链路负责 -### 7.1.2 2026-04-23 补充：自定义邮箱服务号池链路 +#### 7.1.3 自定义邮箱服务号池链路 本轮给 `mailProvider = custom` 这条链路补上了“号池式注册邮箱分配”，目标是让“手动验证码模式”也能稳定跑多轮不同邮箱，而不是每轮都手动改一次注册邮箱。 @@ -746,17 +840,32 @@ Kiro flow 的目标不是复用 OpenAI 注册链，而是独立完成“Kiro 官 - `background/registration-email-state.js` 统一维护当前注册邮箱、上一份比较基线邮箱、来源与更新时间，并提供 Duck 生成前解析比较基线、Step 8 清空当前邮箱但保留历史基线，以及 Step 8 `add-email` 写入邮箱时保留手机号身份的共享工具。 +- `background/mail-rule-registry.js` + `flows/openai/mail-rules.js` + 统一构造 Step 4 / Step 8 的验证码规则 payload，区分注册验证码与登录/绑定验证码，并把 `senderFilters / subjectFilters / codePatterns / targetEmailHints / mail2925MatchTargetEmail` 收敛到同一层。 + - `background/generated-email-helpers.js` 在原有 Duck / Cloudflare / iCloud / Cloudflare Temp Email 生成链路之外，新增 Gmail / 2925 的共享生成接入；Duck 生成前会按“侧栏当前可见邮箱 -> `registrationEmailState.current` -> `registrationEmailState.previous`”的顺序解析比较基线。 - `background/signup-flow-helpers.js` 负责在真正提交注册邮箱前做“复用已有完整邮箱 / 重新生成”的最终决策，并避免把生成阶段已经落库的邮箱再次重复写入运行态。 -### 7.1 生成邮箱 +- `phone-sms/providers/registry.js` + 统一维护 HeroSMS / 5sim / NexSMS 的 provider id、显示名、默认顺序与工厂装配入口；sidepanel 与后台优先经这层归一化 provider 值，而不是各自手搓字符串判断。 + +- `phone-sms/providers/hero-sms.js` / `phone-sms/providers/five-sim.js` + 承接已模块化的接码平台协议适配；NexSMS 当前仍保留在 `background/phone-verification-flow.js` 的兼容路径中，但 provider id、UI 顺序和能力入口已经统一走注册表。 + +- `sidepanel/custom-email-pool-manager.js` + 负责自定义邮箱池 / 自定义邮箱服务号池的表单接线、批量解析、自动轮数联动与显隐管理，不再把这部分 UI 细节继续堆在 `sidepanel.js` 主文件里。 + +- `sidepanel/editable-list-picker.js` + 负责可编辑列表 UI 组件；当前用于 SUB2API 分组、PayPal 账号池、Cloudflare 域名列表与 Cloudflare Temp Email 域名选择，不再在 `sidepanel.js` 内各自手搓一套列表交互。 + +### 7.3 生成邮箱 文件： -- [background/generated-email-helpers.js](c:/Users/projectf/Downloads/codex注册扩展/background/generated-email-helpers.js) +- [background/generated-email-helpers.js](./background/generated-email-helpers.js) 支持： @@ -773,15 +882,15 @@ Kiro flow 的目标不是复用 OpenAI 注册链，而是独立完成“Kiro 官 - 所有生成器在返回邮箱后都会统一调用共享注册邮箱状态持久化入口回写运行态：普通邮箱流等价于 `setEmailState(..., { source })`，而 Step 8 `add-email` 的手机号身份流会在更新 `email / registrationEmailState` 的同时保留 `signupPhone* / accountIdentifier*`，避免 sidepanel 短暂看到手机号被清空。 - Duck 生成链路不会再直接拿“生成前瞬间读到的输入框值”当唯一基线，而是优先使用 sidepanel 当前可见邮箱，再回退到共享的注册邮箱运行态基线，避免生成前后地址对比失效。 -### 7.1.1 Cloud Mail +#### 7.3.1 Cloud Mail 组成： -- [cloudmail-utils.js](c:/Users/projectf/Downloads/codex注册扩展/cloudmail-utils.js) -- [background/cloudmail-provider.js](c:/Users/projectf/Downloads/codex注册扩展/background/cloudmail-provider.js) -- [background/verification-flow.js](c:/Users/projectf/Downloads/codex注册扩展/background/verification-flow.js) -- [sidepanel/sidepanel.html](c:/Users/projectf/Downloads/codex注册扩展/sidepanel/sidepanel.html) -- [sidepanel/sidepanel.js](c:/Users/projectf/Downloads/codex注册扩展/sidepanel/sidepanel.js) +- [cloudmail-utils.js](./cloudmail-utils.js) +- [background/cloudmail-provider.js](./background/cloudmail-provider.js) +- [background/verification-flow.js](./background/verification-flow.js) +- [sidepanel/sidepanel.html](./sidepanel/sidepanel.html) +- [sidepanel/sidepanel.js](./sidepanel/sidepanel.js) 链路： @@ -791,15 +900,15 @@ Kiro flow 的目标不是复用 OpenAI 注册链，而是独立完成“Kiro 官 4. 邮件读取统一走 `/api/public/emailList`，返回数据先经 `cloudmail-utils.js` 归一化，再复用现有验证码匹配与时间窗过滤逻辑。 5. 如果 Token 失效，后台会尝试重新登录刷新 Token 后重试当前 API 请求。 -### 7.1.2 YYDS Mail +#### 7.3.2 YYDS Mail 组成： -- [yyds-mail-utils.js](c:/Users/projectf/Downloads/codex注册扩展/yyds-mail-utils.js) -- [background/yyds-mail-provider.js](c:/Users/projectf/Downloads/codex注册扩展/background/yyds-mail-provider.js) -- [background/verification-flow.js](c:/Users/projectf/Downloads/codex注册扩展/background/verification-flow.js) -- [sidepanel/sidepanel.html](c:/Users/projectf/Downloads/codex注册扩展/sidepanel/sidepanel.html) -- [sidepanel/sidepanel.js](c:/Users/projectf/Downloads/codex注册扩展/sidepanel/sidepanel.js) +- [yyds-mail-utils.js](./yyds-mail-utils.js) +- [background/yyds-mail-provider.js](./background/yyds-mail-provider.js) +- [background/verification-flow.js](./background/verification-flow.js) +- [sidepanel/sidepanel.html](./sidepanel/sidepanel.html) +- [sidepanel/sidepanel.js](./sidepanel/sidepanel.js) 链路： @@ -811,15 +920,15 @@ Kiro flow 的目标不是复用 OpenAI 注册链，而是独立完成“Kiro 官 6. 平台验证完成后的成功收尾会清空 `currentYydsMailInbox` 与当前邮箱运行态，下一轮重新创建新的 YYDS Mail 邮箱。 7. `reset` 保留 YYDS Mail 的 API Key / Base URL 配置，但清空当前邮箱运行态，避免旧临时 token 被下一轮误用。 -### 7.2 Hotmail +### 7.4 Hotmail 组成： -- [hotmail-utils.js](c:/Users/projectf/Downloads/codex注册扩展/hotmail-utils.js) -- [microsoft-email.js](c:/Users/projectf/Downloads/codex注册扩展/microsoft-email.js) -- [scripts/hotmail_helper.py](c:/Users/projectf/Downloads/codex注册扩展/scripts/hotmail_helper.py) -- [sidepanel/hotmail-manager.js](c:/Users/projectf/Downloads/codex注册扩展/sidepanel/hotmail-manager.js) -- [sidepanel/account-pool-ui.js](c:/Users/projectf/Downloads/codex注册扩展/sidepanel/account-pool-ui.js) +- [hotmail-utils.js](./hotmail-utils.js) +- [microsoft-email.js](./microsoft-email.js) +- [scripts/hotmail_helper.py](./scripts/hotmail_helper.py) +- [sidepanel/hotmail-manager.js](./sidepanel/hotmail-manager.js) +- [sidepanel/account-pool-ui.js](./sidepanel/account-pool-ui.js) 模式： @@ -832,19 +941,19 @@ Kiro flow 的目标不是复用 OpenAI 注册链，而是独立完成“Kiro 官 - 账号运行历史快照会按默认本地 helper 地址自动尝试同步，不再要求用户手动打开独立开关，也不再绑定 Hotmail 的本地助手模式。 - sidepanel 中 Hotmail 账号池的新增表单默认收起，头部通过共享按钮切换“添加账号 / 取消添加”；表单显隐、按钮文案切换、清空与聚焦都复用 `sidepanel/account-pool-ui.js`，不在 Hotmail manager 内重复实现一套。 -### 7.3 LuckMail +### 7.5 LuckMail 组成： -- [luckmail-utils.js](c:/Users/projectf/Downloads/codex注册扩展/luckmail-utils.js) -- LuckMail 相关后台领域逻辑仍在 [background.js](c:/Users/projectf/Downloads/codex注册扩展/background.js) +- [luckmail-utils.js](./luckmail-utils.js) +- LuckMail 相关后台领域逻辑仍在 [background.js](./background.js) -### 7.4 163 / 163 VIP / 126 网页邮箱 +### 7.6 163 / 163 VIP / 126 网页邮箱 组成： -- [mail-provider-utils.js](c:/Users/projectf/Downloads/codex注册扩展/mail-provider-utils.js) -- [content/mail-163.js](c:/Users/projectf/Downloads/codex注册扩展/content/mail-163.js) +- [mail-provider-utils.js](./mail-provider-utils.js) +- [content/mail-163.js](./content/mail-163.js) 行为约定： @@ -856,14 +965,14 @@ Kiro flow 的目标不是复用 OpenAI 注册链，而是独立完成“Kiro 官 - `https://webmail.vip.163.com/*` - `https://mail.126.com/*` -### 7.5 2925 账号池 +### 7.7 2925 账号池 组成： -- [mail2925-utils.js](c:/Users/projectf/Downloads/codex注册扩展/mail2925-utils.js) -- [background/mail-2925-session.js](c:/Users/projectf/Downloads/codex注册扩展/background/mail-2925-session.js) -- [sidepanel/mail-2925-manager.js](c:/Users/projectf/Downloads/codex注册扩展/sidepanel/mail-2925-manager.js) -- [sidepanel/account-pool-ui.js](c:/Users/projectf/Downloads/codex注册扩展/sidepanel/account-pool-ui.js) +- [mail2925-utils.js](./mail2925-utils.js) +- [background/mail-2925-session.js](./background/mail-2925-session.js) +- [sidepanel/mail-2925-manager.js](./sidepanel/mail-2925-manager.js) +- [sidepanel/account-pool-ui.js](./sidepanel/account-pool-ui.js) 职责： @@ -888,7 +997,7 @@ Kiro flow 的目标不是复用 OpenAI 注册链，而是独立完成“Kiro 官 8. sidepanel 中 2925 账号池的新增表单也走与 Hotmail 相同的共享交互：默认收起，头部按钮切换“添加账号 / 取消添加”，操作行右侧提供“批量导入”，保存成功后自动收起并清空。 9. 当 2925 号池模式开启时，当前选中的号池邮箱会同步回写到同一个 `mail2925BaseEmail` 字段；因此用户切换号池账号后，即使再次关闭号池模式，也会直接沿用刚才选中的邮箱作为手动基邮箱，无需重新输入。 -### 7.5.1 2925 双模式维护约定 +#### 7.7.1 2925 双模式维护约定 这是后续维护 `2925` 时最容易被重新打散的一段链路，建议按下面的职责边界理解： @@ -940,12 +1049,12 @@ Kiro flow 的目标不是复用 OpenAI 注册链，而是独立完成“Kiro 官 4. `background/verification-flow.js` 与 `content/mail-2925.js` 的“弱目标邮箱匹配”是否保持同步 5. `项目文件结构说明.md` 与当前文件是否已同步更新 -### 7.6 iCloud +### 7.8 iCloud 组成： -- [icloud-utils.js](c:/Users/projectf/Downloads/codex注册扩展/icloud-utils.js) -- [content/icloud-mail.js](c:/Users/projectf/Downloads/codex注册扩展/content/icloud-mail.js) +- [icloud-utils.js](./icloud-utils.js) +- [content/icloud-mail.js](./content/icloud-mail.js) 配置： @@ -972,15 +1081,15 @@ Hide My Email 获取与管理链路： - iCloud 登录态提示必须区分“真实未登录”和“已登录但请求上下文波动”；不能把所有 401 / 403 / 421 都直接提示为未登录。 - iCloud 别名缓存只用于短暂失败回退，不应改变最终的已用 / 保留状态来源；状态仍以 `manualAliasUsage`、`preservedAliases` 与最新线上列表合并后的结果为准。 -### 7.7 IP Proxy +### 7.9 IP Proxy 组成： -- [background/ip-proxy-core.js](c:/Users/projectf/Downloads/codex注册扩展/background/ip-proxy-core.js) -- [background/ip-proxy-provider-711proxy.js](c:/Users/projectf/Downloads/codex注册扩展/background/ip-proxy-provider-711proxy.js) -- [sidepanel/ip-proxy-panel.js](c:/Users/projectf/Downloads/codex注册扩展/sidepanel/ip-proxy-panel.js) -- [sidepanel/ip-proxy-provider-711proxy.js](c:/Users/projectf/Downloads/codex注册扩展/sidepanel/ip-proxy-provider-711proxy.js) -- [docs/ip-proxy-module.md](c:/Users/projectf/Downloads/codex注册扩展/docs/ip-proxy-module.md) +- [background/ip-proxy-core.js](./background/ip-proxy-core.js) +- [background/ip-proxy-provider-711proxy.js](./background/ip-proxy-provider-711proxy.js) +- [sidepanel/ip-proxy-panel.js](./sidepanel/ip-proxy-panel.js) +- [sidepanel/ip-proxy-provider-711proxy.js](./sidepanel/ip-proxy-provider-711proxy.js) +- [docs/ip-proxy-module.md](./docs/ip-proxy-module.md) 职责边界： @@ -1006,12 +1115,12 @@ Hide My Email 获取与管理链路： - 代理解析、PAC、鉴权和出口检测必须留在后台模块，不应继续堆进 `background.js`。 - UI 层不能凭输入值直接判断“代理已接管”，只能展示后台返回的 `ipProxyApplied*` 状态。 - 新增代理服务商时，应优先新增 provider 规则模块，并让共享解析/运行态继续走 `background/ip-proxy-core.js`。 -- 修改代理字段、权限或链路时，需要同步更新 [docs/ip-proxy-module.md](c:/Users/projectf/Downloads/codex注册扩展/docs/ip-proxy-module.md)、当前完整链路说明和结构说明。 +- 修改代理字段、权限或链路时，需要同步更新 [docs/ip-proxy-module.md](./docs/ip-proxy-module.md)、当前完整链路说明和结构说明。 ## 8. 自动运行完整链路 文件： -- [background/auto-run-controller.js](c:/Users/projectf/Downloads/codex注册扩展/background/auto-run-controller.js) +- [background/auto-run-controller.js](./background/auto-run-controller.js) 流程： @@ -1048,10 +1157,10 @@ Hide My Email 获取与管理链路： 必须同时检查： -1. [data/step-definitions.js](c:/Users/projectf/Downloads/codex注册扩展/data/step-definitions.js) -2. [background/steps](c:/Users/projectf/Downloads/codex注册扩展/background/steps) -3. [background/steps/registry.js](c:/Users/projectf/Downloads/codex注册扩展/background/steps/registry.js) -4. 如果步骤属于新 flow，还必须同步检查 [shared/flow-registry.js](c:/Users/projectf/Downloads/codex注册扩展/shared/flow-registry.js) 与 [shared/settings-schema.js](c:/Users/projectf/Downloads/codex注册扩展/shared/settings-schema.js) +1. [data/step-definitions.js](./data/step-definitions.js) +2. [background/steps](./background/steps) +3. [background/steps/registry.js](./background/steps/registry.js) +4. 如果步骤属于新 flow，还必须同步检查 [shared/flow-registry.js](./shared/flow-registry.js) 与 [shared/settings-schema.js](./shared/settings-schema.js) 4. 自动运行链路是否需要纳入 5. Step 状态传播和侧边栏展示是否需要适配 6. 测试是否要补 @@ -1088,11 +1197,11 @@ Hide My Email 获取与管理链路： 修改下列内容时，必须同步更新文档： - 文件结构变更 - 更新 [项目文件结构说明.md](c:/Users/projectf/Downloads/codex注册扩展/项目文件结构说明.md) + 更新 [项目文件结构说明.md](./项目文件结构说明.md) - 运行链路变更 - 更新 [项目完整链路说明.md](c:/Users/projectf/Downloads/codex注册扩展/项目完整链路说明.md) + 更新 [项目完整链路说明.md](./项目完整链路说明.md) - 规范、边界、步骤接入方式变更 - 更新 [项目开发规范（AI协作）.md](c:/Users/projectf/Downloads/codex注册扩展/项目开发规范（AI协作）.md) + 更新 [项目开发规范（AI协作）.md](./项目开发规范（AI协作）.md) ## 2026-04 链路补充：认证页共享恢复 - 新增共享恢复层：`content/auth-page-recovery.js`。 diff --git a/项目开发规范（AI协作）.md b/项目开发规范（AI协作）.md index eed75ed..e8da894 100644 --- a/项目开发规范（AI协作）.md +++ b/项目开发规范（AI协作）.md @@ -293,6 +293,24 @@ - iCloud 别名缓存只能作为短暂失败回退，不允许替代线上列表成为最终状态来源；已用和保留状态仍然以 `manualAliasUsage`、`preservedAliases` 与最新线上列表合并后的结果为准。 - 如果新增 iCloud 相关回退路径，必须补覆盖登录提示、缓存回退、自动运行停止重试和 reserve 异常恢复的测试，并同步更新 [项目完整链路说明.md](./项目完整链路说明.md)。 +### 3.4.2 Plus 账号接入策略 / 会话导入规范 + +- `plusAccountAccessStrategy` 属于 `flows.openai.plus` 下的持久配置，不是新的运行态模式，也不是新的 source。 +- 当前能力边界由 target capability 决定：`CPA` 允许 `oauth / cpa_codex_session`，`SUB2API` 允许 `oauth / sub2api_codex_session`，`Codex2API` 当前仅允许 `oauth`。 +- UI 上不支持的选项必须直接禁用并回落为 `oauth`；不允许出现“看起来能选，执行时再报不支持”的假开关。 +- Plus 模式下会话导入只在 `openai` flow、Plus 已开启、且当前是邮箱注册时可用；Plus 模式不允许手机号注册。 +- 任何设计、文档和代码都不能把 Plus 写成固定步骤号链；只能描述“替换哪一段 workflow 节点”。 +- 当尾链切到 `cpa-session-import` 或 `sub2api-session-import` 时，被替换的是整段 `oauth-login -> fetch-login-code -> confirm-oauth -> platform-verify`，不是只替换其中某一个固定编号步骤。 +- session import 节点必须直接完成目标平台接入，不得再经过 `platform-verify`，也不得混入普通 OAuth callback 状态机。 +- 相关改动必须同步检查： + - `data/step-definitions.js` + - `shared/flow-capabilities.js` + - `shared/settings-schema.js` + - `background/message-router.js` + - 对应 session import executor 与 `background/steps/platform-verify.js` + - `sidepanel/sidepanel.html` 与 `sidepanel/sidepanel.js` + - 手动跳过、自动运行、最终完成节点判断、日志 step 映射与测试 + ### 3.5 OAuth / 接码 / 注册身份链路规范 OAuth 登录后链路是本项目最容易出现“功能重复、页面冲突、步骤偷跑”的区域。任何改动都必须先区分注册模式、登录身份和当前认证页状态。 @@ -365,17 +383,13 @@ OAuth 登录后链路是本项目最容易出现“功能重复、页面冲突 完成一次结构性改动后，至少执行： ```bash -bun test +npm test ``` 补充说明： -- 实际执行命令以仓库当前 `package.json` 为准 -- 本仓库当前全量回归命令为： - -```bash -npm test -``` +- 实际执行命令以仓库当前 `package.json` 为准；如果后续脚本名变化，这里也必须同步更新。 +- 只在用户明确限制、或当前环境确实无法运行时，才允许不跑全量回归；此时必须在结果里说明原因与未覆盖风险。 ### 4.4 分阶段测试要求 diff --git a/项目文件结构说明.md b/项目文件结构说明.md index a368f2f..a5d46a9 100644 --- a/项目文件结构说明.md +++ b/项目文件结构说明.md @@ -20,7 +20,7 @@ - `.gitignore`：定义仓库忽略规则，当前忽略 `docs/md/`、`.github/`、`_metadata/`、`.vscode/` 等目录。 - `LICENSE`：项目许可证文件。 -- `README.md`：面向使用者的项目介绍、安装说明、能力清单与操作指引。 +- `README.md`：面向使用者的精简说明文档，主要介绍项目用途、功能范围、快速开始与文档入口；不再承载过多技术实现细节。 - `background.js`：扩展后台 Service Worker 入口壳，负责模块装配、初始化、全局常量、少量保留的领域函数与运行入口；当前已按 `activeFlowId` 装配 flow-aware 的步骤定义、执行注册表、自动运行与状态同步，`openai` flow 继续承接 `oauthFlowTimeoutEnabled` 与 `stepExecutionRangeByFlow`，`kiro` flow 则走独立的“注册页 1-6 步 -> 桌面授权 7-8 步 -> `kiro.rs` 上传 9 步”链路。 - `cloudmail-utils.js`：Cloud Mail / SkyMail 相关的纯工具函数，负责 API 地址、域名、鉴权头、邮件列表响应与邮件正文归一化。 - `cloudflare-temp-email-utils.js`：Cloudflare Temp Email 相关的纯工具函数，负责 URL、域名、邮件内容与 MIME 数据归一化。 @@ -39,6 +39,7 @@ - `rules.json`：静态 DNR 规则，主要处理 iCloud 相关请求头。 - `start-hotmail-helper.bat`：Windows 下启动本地 helper 的脚本；当前既服务于 Hotmail 本地收信，也服务于账号记录快照同步。 - `start-hotmail-helper.command`：macOS 下启动本地 helper 的脚本；当前既服务于 Hotmail 本地收信，也服务于账号记录快照同步。 +- `THIRD_PARTY_NOTICES.md`：项目来源、共同历史、原仓库地址与许可说明，用于补充当前仓库与历史上游代码的来源关系。 - `开发者AI开发与PR提交流程.md`：仓库现有的 AI 开发与 PR 提交流程说明。 - `项目文件结构说明.md`：当前文件，维护整个仓库非忽略文件的结构与职责索引。 - `项目完整链路说明.md`：面向 AI/开发者的完整功能链路说明，用于快速理解系统整体运行过程。 @@ -49,6 +50,7 @@ - `background/account-run-history.js`：账号记录模块，负责以统一账号标识维护最新记录；邮箱注册以邮箱为主身份，手机号注册以手机号为主身份，同一轮后续绑定的手机号或邮箱会并入同一条记录并覆盖旧占位状态；模块统一归一化成功/失败/停止三态并落地到 `chrome.storage.local`，兼容 phone-only 与 email+phone 组合记录、空密码，并按默认本地 helper 地址自动尝试把完整快照同步到本地 helper；若 helper 未启动，则静默跳过。 - `background/auto-run-controller.js`：自动运行主控制器，封装多轮执行、重试、轮次摘要、线程间隔与倒计时恢复逻辑；当前自动流程会绑定 `autoRunSessionId`，手动停止后旧的倒计时计划、旧重试链路和旧恢复入口不会再复活已失效的自动运行；fresh-attempt reset 时会额外保留 Plus 模式与 PayPal 配置、`gmailBaseEmail`、`mail2925BaseEmail`、当前 2925 账号选择与 `stepExecutionRangeByFlow`，避免自动流程重置后丢失关键持久配置。 - `background/contribution-oauth.js`：贡献模式的公开 OAuth 流程模块，负责调用 `flowpilot.qlhazycoder.top` 的公开贡献接口、保存贡献会话运行态、在主 10 步流程里为步骤 7 提供贡献登录地址、在步骤 9/10 衔接 callback 捕获与兼容提交 `/oauth/api/submit-callback`，并把真实服务端状态映射回 sidepanel 运行态。 +- `background/cpa-api.js`：CPA 管理接口直连模块，负责请求 CPA OAuth 地址、提交 localhost callback，以及把当前 ChatGPT 已登录会话转换为 CPA `auth-files` 导入格式并直接写入管理接口。 - `background/cloudmail-provider.js`：Cloud Mail / SkyMail 后台 provider 模块，负责 Token 获取、邮箱创建、邮件列表读取、验证码轮询和生成/转发收件目标邮箱选择；新生成的 Cloud Mail 地址会统一走共享注册邮箱状态持久化，既回写带来源标记的注册邮箱运行态，也能在 Step 8 `add-email` 的手机号身份链路中保留 `signupPhone* / accountIdentifier*`。 - `background/yyds-mail-provider.js`：YYDS Mail 后台 provider 模块，负责通过 `X-API-Key` 创建临时邮箱、保存返回的地址与临时 Bearer token、按 `/messages` 与 `/messages/{id}` 读取验证码邮件，并在成功收尾或 reset 时清空当前运行态邮箱。 - `background/generated-email-helpers.js`：生成邮箱辅助层，除了 Duck / Cloudflare / iCloud / Cloudflare Temp Email，也统一承接 Gmail / 2925 的别名邮箱生成入口与自定义邮箱池读取；当 provider 为 2925 且 `mail2925Mode = provide` 时，会先确保当前账号池里已有可用账号，再基于该账号生成别名邮箱；若 `mail2925Mode = receive`，则会回退到普通邮箱生成链路；当生成方式为 iCloud 且 `icloudFetchMode = always_new` 时，会强制跳过未用别名复用并新建别名；当生成方式为 `custom-pool` 时，会按当前目标轮次读取邮箱池中的对应邮箱；Duck 生成前会优先结合 `registrationEmailState` 与侧栏当前可见邮箱解析对比基线，避免重复拿到旧地址；所有生成结果都会统一走共享注册邮箱状态持久化，普通邮箱流仍切回邮箱身份，Step 8 `add-email` 的手机号身份流则保留当前手机号身份。 @@ -61,8 +63,10 @@ - `background/ip-proxy-provider-711proxy.js`：711Proxy provider 规则模块，负责从账号串中识别和写回 `region / session / sessTime` 等参数，并在固定账号模式下把侧栏配置转换为最终生效的代理账号。 - `background/logging-status.js`：后台日志、步骤状态、错误信息和若干状态判断的公共工具层；日志条目统一写入结构化 `step / stepKey`，sidepanel 只读取该元数据渲染步骤标签，不再从日志正文解析步骤号；当前额外承接 `add-phone / 手机号页` 这类认证 fatal 错误的共享判定，并会把 Step 2 的“手机号输入模式未切成功”与真正的 auth `add-phone` 页面区分开，避免自动运行误停机。 - `background/mail-2925-session.js`：2925 会话模块，负责 2925 账号池持久化、当前账号切换、cookie 清理登出、自动登录、命中“子邮箱已达上限邮箱”后的 24 小时禁用与自动切号。 +- `background/mail-rule-registry.js`：flow-aware 邮件规则注册表，负责按 `activeFlowId` 选择验证码规则构造器，并统一输出注册/登录验证码轮询 payload。 - `background/message-router.js`：后台消息路由层，负责处理 `chrome.runtime.onMessage` 进入的所有业务消息；`LOG / STEP_COMPLETE / STEP_ERROR` 会把消息里的真实 `step` 继续传给结构化日志，跳过登录验证码这类派生日志也按当前步骤 key 写入；当前额外接入 PayPal 账号池的新增与切换、2925 账号池的新增、导入、切换、登录、禁用与删除消息，以及 IP 代理的同步、切换、Change 与出口检测消息；手动改邮箱、手动取邮箱等入口也统一经这里落到 `setEmailState`，同步维护注册邮箱运行态；当侧栏关闭 `oauthFlowTimeoutEnabled` 时，会立即清空已存在的 OAuth 总预算 deadline；手动 `EXECUTE_NODE` 会先按 `stepExecutionRangeByFlow` 校验当前节点是否允许执行。 - `background/registration-email-state.js`：注册邮箱运行态共享模块，负责维护 `registrationEmailState = { current, previous, source, updatedAt }`，并提供“当前邮箱清空时保留上一比较基线”“Duck 生成前解析比较基线”“Step 8 `add-email` 写入邮箱时按需保留手机号身份”的统一工具。 +- `background/runtime-state.js`：运行态视图与 patch 构造模块，负责把会话字段归一到 `runtimeState / sharedState / serviceState / flowState` 结构，并维护 flow-aware 的 session patch、节点状态默认值与兼容视图输出。 - `background/navigation-utils.js`：导航与 URL 判断工具层，负责 callback、入口页、CPA / SUB2API / Codex2API 地址归一化、来源标签页家族判断与步骤跳转相关判断。 - `background/paypal-account-store.js`：PayPal 账号池持久化模块，负责保存账号列表、切换当前账号，并把当前选中账号同步回兼容字段 `paypalEmail / paypalPassword`。 - `background/phone-verification-flow.js`：OpenAI 专属手机号验证码流程模块，负责复用 HeroSMS / 5sim / NexSMS 的取号、复用、轮询、重发、换号与收尾能力；既承接 OpenAI OAuth 后置 `add-phone / phone-verification` 页面，也承接 OpenAI 手机号注册 Step 4 和 Step 8 中真实出现的 `phone-verification` 页面，并保持 `signupPhone*` 运行态与 `currentPhoneActivation` 隔离；后续多注册 flow 架构中，该模块应收拢到 `flows/openai` 边界内，不作为 core 通用接码服务提前抽象；后置 add-phone 成功后会把已绑定手机号写入运行态 `phoneNumber`，供账号记录并入同一轮；提交后置手机号验证码时会一并透传可复用的资料页 payload，便于认证页偶发跳回资料页时继续补齐；该流程由调用方传入当前可见步骤号，手机号日志不会再固定显示普通模式 Step 9。 @@ -70,7 +74,8 @@ - `background/sub2api-api.js`：SUB2API 管理接口直连模块，负责后台登录 SUB2API、解析 openai 分组、按配置选择代理、生成 OpenAI OAuth 地址、交换 localhost callback 授权码并创建 SUB2API 账号；主链路不再依赖 SUB2API 后台页面 DOM 自动化。 - `background/signup-flow-helpers.js`：注册页辅助层，负责打开注册入口、Step 2 打开入口页后的加载完成与额外 3 秒稳定等待、等待密码页以及解析当前流程所用邮箱；在 Gmail 与 `2925 + provide` 模式下会优先复用已经存在且仍兼容的完整注册邮箱，只有不兼容或为空时才重新生成；当 provider 为 2925 且启用了 provide 模式下的号池时，会先确保账号池中已选中可用账号；若邮箱生成器在生成阶段已经写回运行态，这里不会再重复覆盖 `registrationEmailState`，但仍会在 Step 8 `add-email` 的手机号身份场景下通过共享持久化按需保留手机号身份。 - `background/tab-runtime.js`：标签页与内容脚本运行时基础设施，封装标签注册、冲突清理、消息超时、注入重试与队列；内容脚本恢复等待日志支持 `logStep / logStepKey`，用于保持 Plus 复用步骤的日志标签正确；当前等待标签完成、等待标签完成并短暂稳定、注入后的短暂延迟和内容脚本重试等待都已做 Stop 感知，避免用户停止后后台还继续等待并恢复执行。 -- `background/verification-flow.js`：注册/登录验证码共享流程层，封装重发、轮询、提交、失败回退、自定义邮箱跳过、共享验证码自动重发次数配置、Cloud Mail / YYDS Mail API 轮询以及 2925 长轮询参数；日志步骤号使用 `completionStep`，因此 Plus 登录验证码会显示可见第 11 步而不是内部复用的 Step 8；当前验证码提交重试上限为 15 次，2925 每次重发验证码之间都会固定跑完一轮 15 次邮箱刷新轮询；若 `mail2925Mode = receive`，会额外把目标注册邮箱传给 2925 内容脚本做弱匹配；若登录验证码提交后页面转入 `add-phone / 手机号页`，则会把“后续需要手机号验证”的结果继续传给 OAuth 确认步骤，而不是误判为普通失败；若登录验证码提交后通信中断但认证页已进入 OAuth 同意页或手机号验证页，会按真实页面状态继续后续流程；若 2925 轮询命中“子邮箱已达上限邮箱”，会转入 2925 会话模块执行“记录时间、禁用 24 小时、切下一个账号并重新登录”，然后直接结束当前尝试。 +- `background/verification-flow.js`：注册/登录验证码共享流程层，封装重发、轮询、提交、失败回退、自定义邮箱跳过、共享验证码自动重发次数配置、Cloud Mail / YYDS Mail API 轮询以及 2925 长轮询参数；日志步骤号使用 `completionStep`，因此在 Plus 仍走 OAuth 尾链的场景下，登录验证码会显示当前可见步骤而不是内部复用的 Step 8；当前验证码提交重试上限为 15 次，2925 每次重发验证码之间都会固定跑完一轮 15 次邮箱刷新轮询；若 `mail2925Mode = receive`，会额外把目标注册邮箱传给 2925 内容脚本做弱匹配；若登录验证码提交后页面转入 `add-phone / 手机号页`，则会把“后续需要手机号验证”的结果继续传给 OAuth 确认步骤，而不是误判为普通失败；若登录验证码提交后通信中断但认证页已进入 OAuth 同意页或手机号验证页，会按真实页面状态继续后续流程；若 2925 轮询命中“子邮箱已达上限邮箱”，会转入 2925 会话模块执行“记录时间、禁用 24 小时、切下一个账号并重新登录”，然后直接结束当前尝试。 +- `background/workflow-engine.js`：workflow 节点状态引擎，负责按当前 flow 解析节点列表、默认状态、后继节点、首个未完成节点和运行中节点，并为自动运行、恢复与手动执行提供统一 node 视图。 ## `background/steps/` @@ -80,13 +85,17 @@ - `background/steps/fetch-login-code.js`：步骤 8 实现，负责按真实认证页状态分发登录后续流程：邮箱验证码页走邮箱轮询、验证码回填与回退控制；真实 `phone-verification` 页才复用 OpenAI 专属手机号验证码流程；手机号注册登录后若进入 `add-email`，会先按共享邮箱状态持久化规则生成/解析邮箱并提交绑定，在不丢失当前手机号身份的前提下再进入邮箱验证码轮询；邮箱分支对非 2925 provider 会固定当前验证码页显示邮箱作为本次 Step 8 的目标邮箱，当 provider 为 2925 时，会在轮询前先确保当前 2925 账号已自动登录；命中 `email_in_use` 时会仅清空当前邮箱并保留上一轮比较基线，再在当前 Step 8 内重开 `add-email` 获取新邮箱，`max_check_attempts` 也只重启当前步骤恢复链。 - `background/steps/fetch-signup-code.js`：步骤 4 实现，负责注册验证码阶段的页面准备与验证码流程入口；邮箱注册继续走邮箱验证码，手机号注册改走短信验证码；当 provider 为 2925 时，会在邮箱轮询前先确保当前 2925 账号已自动登录。 - `background/steps/fill-plus-checkout.js`：Plus 模式第 7 步实现，负责驱动 PayPal / GoPay checkout 页面选择付款方式、填写账单地址、提交订阅并等待跳转；GPC 模式则轮询队列任务，按远端 `api_waiting_for` 提交 OTP / PIN，并在任务失败、过期或取消时清理运行态。 +- `background/steps/gopay-manual-confirm.js`：GoPay 手动确认节点，负责在需要人工完成订阅时发布待确认运行态，并按当前 Plus 尾链动态生成“继续 OAuth / 继续导入 SUB2API / 继续导入 CPA”的提示文案。 +- `background/steps/gopay-approve.js`：GoPay 自动审批节点，负责接管 GoPay / GPC 相关标签页、识别 OTP / PIN / Pay now / Hubungkan 等页面状态，并在支付页失效时回退到重新创建 checkout。 - `background/steps/fill-password.js`：步骤 3 实现，负责密码生成、保存、回填与提交；当前已改为身份中立，手机号注册遇到无密码页时会按页面状态自动跳过。 - `background/steps/fill-profile.js`：步骤 5 实现，负责姓名、生日填写并把资料提交给注册页内容脚本。 - `background/steps/oauth-login.js`：步骤 7 实现，负责刷新 OAuth 链接、登录和确保进入验证码页；当前会根据 `accountIdentifierType / accountIdentifier` 选择邮箱或手机号登录，手机号账号会先探测并切换手机号登录入口；普通可恢复登录态失败会按上限重试，但一旦识别到认证流程进入 `add-phone / 手机号页`，会立即退出步骤 7 内部重试。 - `background/steps/open-chatgpt.js`：步骤 1 实现，负责打开 ChatGPT 官网并确认入口就绪。 - `background/steps/paypal-approve.js`：Plus 模式第 8 步实现，负责驱动 PayPal 登录、关闭可见通行密钥提示、点击“同意并继续”，并等待授权流程离开 PayPal 页面。 -- `background/steps/platform-verify.js`：平台回调验证实现，普通模式为步骤 10，Plus 模式为可见步骤 13；负责 CPA 页面回调验证、SUB2API 管理接口 callback code/state 交换与账号创建，以及 Codex2API 的协议式 callback code/state 交换，所有平台验证日志和完成信号都按当前可见步骤上报。 +- `background/steps/cpa-session-import.js`：Plus 模式下的 CPA 会话导入尾节点，负责定位当前已登录的 ChatGPT / OpenAI 标签页、读取会话与 accessToken，并调用 `background/cpa-api.js` 直接导入 CPA。 +- `background/steps/platform-verify.js`：平台回调验证实现，普通模式为步骤 10；Plus 场景下只有仍走 OAuth 尾链时才会出现该节点，并按当前可见 `platform-verify` 步骤上报（常见为第 13 步）；负责 CPA 页面回调验证、SUB2API 管理接口 callback code/state 交换与账号创建，以及 Codex2API 的协议式 callback code/state 交换。 - `background/steps/plus-return-confirm.js`：Plus 模式第 9 步实现，负责等待 PayPal 授权后回跳到 ChatGPT / OpenAI 页面，页面加载完成后固定等待 1 秒再完成。 +- `background/steps/sub2api-session-import.js`：Plus 模式下的 SUB2API 会话导入尾节点，负责读取当前 ChatGPT 会话，并调用 `background/sub2api-api.js` 的 `codex-session` 导入接口直接创建或更新 SUB2API 账号。 - `background/steps/registry.js`：节点注册表工厂，负责保留 `flowId / nodeId / displayOrder / executeKey` 等稳定节点元数据，并把 flow-specific workflow node 映射到后台执行器。 - `background/steps/submit-signup-email.js`：步骤 2 实现，负责按 `signupMethod` 在邮箱注册与手机号注册之间分发；切回已有注册页标签时会先等待加载完成并额外稳定 3 秒，再检查注册入口状态；邮箱分支会先点击官网“免费注册”再提交邮箱并清理旧手机号注册运行态，手机号分支会先点击官网“免费注册”并切到手机号注册入口，确认手机号输入页就绪后优先复用已有 signup activation，其次使用手动运行态手机号，最后才申请接码平台号码并提交，最后根据落地页判断是否跳过后续密码步骤。 @@ -96,12 +105,14 @@ - `content/auth-page-recovery.js`：认证页共享恢复模块，统一封装 `Try again / 重试` 页识别、点击重试和等待退出重试页；当前由注册验证码等待、OAuth 登录恢复、OAuth 同意页重试恢复链路复用。 - `content/duck-mail.js`：DuckDuckGo Email Protection 页面脚本，负责生成或读取 `@duck.com` 地址；生成新地址时会优先读取显式传入的基线邮箱，并要求新地址稳定出现两次后才接受，避免页面旧值尚未渲染完成时误判“地址已变化”。 - `content/gmail-mail.js`：Gmail 邮箱轮询脚本，负责在 Gmail 页面中匹配验证码邮件。 +- `content/gopay-flow.js`：GoPay 页面内容脚本，负责读取当前支付页状态、提交手机号/OTP/PIN、点击 Continue / Pay now，并把页面内的按钮交互统一包进操作间延迟门控。 - `content/icloud-mail.js`：iCloud 邮箱页面脚本，负责在 iCloud Mail 页面中读取邮件详情和验证码。 - `content/inbucket-mail.js`：Inbucket 邮箱轮询脚本，负责在 Inbucket 页面中读取、删除验证码邮件。 - `content/kiro/register-page.js`：Kiro 注册页内容脚本，负责识别 Kiro 官方登录页、AWS Builder ID 注册页、Kiro Web 登录完成页，并执行选择 Builder ID、填写邮箱、姓名、验证码、密码与“确认并继续 / 允许访问”等页面交互。 - `content/kiro/desktop-authorize-page.js`：Kiro 桌面授权页内容脚本，负责识别桌面授权过程中的 relogin、OTP、consent 与跳转完成状态，并向后台汇报授权页进度。 - `content/mail-163.js`：163 / 163 VIP / 126 邮箱轮询脚本，负责网页邮箱验证码读取和邮件清理。 - `content/mail-2925.js`：2925 邮箱页面脚本，负责 2925 邮箱自动登录态确认、收件轮询、按步骤会话隔离“已试验证码”、在每次重发验证码之间执行一轮最多 15 次的邮箱刷新轮询、命中邮件后立即删当前邮件，以及在成功后配合后台执行整箱清理；若页面出现“子邮箱已达上限邮箱”提示，会立即上报后台进入切号链路；当后台显式开启 `mail2925MatchTargetEmail` 时，会对邮件里显式出现的目标邮箱做弱匹配，避免 `receive` 模式误捞别人的验证码。 +- `content/operation-delay.js`：内容脚本操作间延迟层，负责在覆盖到的注册/支付脚本里把点击、输入和短等待收敛成统一的 2 秒节奏；当前显式排除 `confirm-oauth / platform-verify` 等后台步骤。 - `content/paypal-flow.js`：PayPal 页面脚本，负责识别登录表单、填写 PayPal 账号密码、在账号页固定执行 `focus -> clear -> fill -> blur` 重新触发邮箱输入事件、处理页面内可见通行密钥提示，并点击 PayPal 授权页的“同意并继续”按钮。 - `content/phone-country-utils.js`：手机号国家/区号共享工具层，负责手机号纯数字归一化、国家文案/别名归一化、`+(44)` / `(+44)` / `+44` 区号提取、按号码最长区号匹配国家选项，并由注册页与后续手机号验证页共同复用。 - `content/phone-auth.js`：认证页手机号验证脚本，负责识别 `add-phone / phone-verification` 页面、选择国家、填写手机号、提交短信验证码、触发重发短信，以及把“回到 add-phone / 进入 OAuth 同意页”的结果反馈给后台。 @@ -110,10 +121,12 @@ - `content/signup-page.js`：注册、登录、授权主内容脚本，负责 OpenAI / ChatGPT 页面上的步骤执行；其中 Step 2 / 3 的延迟点击与延迟提交在真正触发前会先检查 Stop 状态，避免停止后页面继续自动点击；当前 Step 2 同时支持邮箱注册与手机号注册入口切换、官网注册入口点击前固定等待 3 秒、入口点击失败后最多 5 次重试、手机号国家下拉框同步校验、手机号填写与提交；Step 3 收尾会识别手机号注册密码页的 `Incorrect phone number or password` 并上报当前轮重开信号；Step 7 / 8 登录链路会额外识别手机号输入页、手机号登录入口、`phone-verification` 与真实 `add-email` 页面，避免把手机验证码页或添加邮箱页误判成普通邮箱登录入口；Step 9 后置手机号验证完成后若偶发进入资料页，会复用 Step 5 的姓名生日填写逻辑再继续等待 OAuth 同意页。 - `content/sub2api-panel.js`：SUB2API 后台内容脚本，保留后台页面内生成 OAuth 地址和提交 localhost 回调的兼容能力；当前主流程已迁移到 `background/sub2api-api.js` 的管理接口直连路径。 - `content/utils.js`：内容脚本公共工具层，负责结构化日志、READY / COMPLETE / ERROR 上报、元素等待、输入与点击；内容脚本日志通过 `{ step, stepKey }` 上报，正文不再承担步骤号解析职责。 -- `content/vps-panel.js`：CPA 面板内容脚本，负责获取 OAuth 地址、提交回调 URL，并基于精确成功徽标与错误态做平台验证判定；当前支持普通步骤 10 与 Plus 可见步骤 13。 +- `content/vps-panel.js`：CPA 面板内容脚本，负责获取 OAuth 地址、提交回调 URL，并基于精确成功徽标与错误态做平台验证判定；当前支持普通步骤 10，以及 Plus 仍走 OAuth 尾链时的 `platform-verify` 节点。 +- `content/whatsapp-flow.js`：WhatsApp Web 读取脚本，负责在 GoPay 场景下从聊天消息中提取 OTP；它只参与轮询读取，不接入操作间延迟门控。 ## `data/` +- `data/account-run-history.txt`：账号运行历史的文本快照样例文件，保留本地 helper 旧追加格式的成功/失败/停止记录，便于人工查看与兼容排查。 - `data/names.js`：随机姓名、生日等测试数据源。 - `data/address-sources.js`：Plus 模式本地地址 seed 表，负责按国家选择用于触发 checkout 内置 Google 地址推荐的查询词和结构化地址 fallback；第一版不实时抓取外部地址网站。 - `data/step-definitions.js`：共享步骤元数据，前后台共同使用，用于动态渲染、workflow 生成和步骤注册；当前 `openai` flow 会按 `plusPaymentMethod / signupMethod` 动态生成普通/Plus workflow，`kiro` flow 则提供独立的 9 节点注册/桌面授权/上传 workflow。 @@ -132,9 +145,14 @@ - `docs/多注册流程来源与驱动注册设计.md`：多注册 flow 下 source registry、driver registry、内容脚本注入与 localhost callback 清理的设计说明。 - `docs/多注册流程邮件分层设计.md`：多注册 flow 下邮件 provider driver 与 flow mail rules 的分层设计说明。 - `docs/多注册流程侧边栏能力矩阵.md`：多注册 flow 下 sidepanel 的 flow capability、panel capability 与 runtime lock 设计说明。 +- `docs/images/log.png`：侧边栏日志区域与步骤状态展示截图，用于教程或说明文档中的运行效果示意。 - `docs/images/交流群.jpg`：README 中展示的官网 / QQ 交流群入口图片。 - `docs/images/微信.png`：README 与文档中使用的微信相关展示图片。 +## `flows/` + +- `flows/openai/mail-rules.js`：OpenAI flow 的验证码邮件规则定义，负责按注册/登录节点输出 code pattern、关键词、目标邮箱提示、2925 receive 弱匹配与轮询参数。 + ## `icons/` - `icons/icon128.png`：扩展 128 像素图标。 @@ -144,6 +162,13 @@ ## `md/` - `md/kiro-flow-独立重构开发方案.md`：Kiro 独立 flow 升级方案与阶段清单，记录根因分析、架构决策、分阶段开发计划、自检标准与最终收口要求。 +- `md/plus模式-sub2api-session接入策略开发方案.md`：Plus 模式 `账号接入策略` 中 SUB2API 会话导入链路的开发方案，记录能力边界、替换节点、自检项与实现阶段划分。 + +## `phone-sms/providers/` + +- `phone-sms/providers/registry.js`：接码 provider 注册表，负责统一 `HeroSMS / 5sim / NexSMS` 的 ID、显示名、默认顺序、模块装载与实例化入口。 +- `phone-sms/providers/hero-sms.js`：HeroSMS 平台适配层，负责国家候选、价格限制、取号、查码、完成、取消与黑名单等 API 协议封装。 +- `phone-sms/providers/five-sim.js`：5sim 平台适配层，负责国家 slug、产品价格、取号、复用、查码、完成、取消、ban 与限流/无号错误归类。 ## `scripts/` @@ -152,8 +177,9 @@ ## `shared/` -- `shared/flow-capabilities.js`：flow 能力矩阵归一化模块，负责根据 `activeFlowId` 与来源解析 sidepanel 的显隐能力、来源作用域、贡献模式边界与步骤范围 UI 作用域。 +- `shared/flow-capabilities.js`：flow 能力矩阵归一化模块，负责根据 `activeFlowId` 与来源解析 sidepanel 的显隐能力、来源作用域、贡献模式边界、步骤范围 UI 作用域，以及 Plus 模式下 `账号接入策略` 的可选项、可编辑性与最终生效值。 - `shared/flow-registry.js`：flow/source/settings group 总注册表，定义 `openai / kiro` 两套 flow、各自 target/runtime source、可见分组、driver 定义，以及默认 target 和默认 `kiro.rs` 配置。 +- `shared/kiro-timeouts.js`：Kiro 共享超时常量与归一化工具，负责注册页/桌面授权链路复用的页面加载超时配置。 - `shared/settings-schema.js`：统一设置 schema 与归一化层，负责把持久配置收敛到 `settingsState.services.*` 与 `settingsState.flows.*` 结构，并维护 `activeFlowId`、OpenAI 的 integration target、Kiro 的 `flows.kiro.targetId / targets` 与 `stepExecutionRangeByFlow`。 - `shared/source-registry.js`：运行时来源注册表，负责合并 flow runtime source 与共享 mail source，统一 source family、driver、URL 归属和 cleanup owner 判定。 @@ -168,6 +194,8 @@ - `sidepanel/account-records-manager.js`：侧边栏账号记录面板管理器，负责“记录”按钮、覆盖层开关、分页列表、成功/失败/停止统计摘要和清理确认；展示时按 `accountIdentifierType` 决定主身份，手机号注册显示手机号并把绑定邮箱放副行，邮箱注册显示邮箱并把后续绑定手机号放副行。 - `sidepanel/contribution-content-update-service.js`：侧边栏贡献内容更新服务，负责拉取 `https://flowpilot.qlhazycoder.top/api/content-summary`、缓存公开公告/教程摘要，并输出可用于提示展示的 `promptVersion` 与最新更新时间。 - `sidepanel/contribution-mode.js`：侧边栏贡献模式管理器，负责顶部“贡献”按钮、确认弹窗、贡献模式显隐、复用主自动流程启动、侧栏内贡献状态轮询、上传页跳转，以及贡献模式下对来源选择、配置入口、记录入口和敏感配置行（包括 Codex2API 配置）的禁用与隐藏。 +- `sidepanel/custom-email-pool-manager.js`：侧边栏自定义邮箱池管理器，负责邮箱池的搜索、筛选、批量启停/已用标记/删除、导入刷新与当前邮箱标识展示。 +- `sidepanel/editable-list-picker.js`：可编辑列表选择器通用组件，负责 Cloudflare Temp Email 域名等配置的当前值显示、下拉选择与删除交互。 - `sidepanel/ip-proxy-panel.js`：侧边栏 IP 代理面板逻辑，负责代理配置显隐、服务/模式切换、账号串参数同步、状态卡渲染，以及同步、下一条、Change、检测出口、检查 IP 等按钮行为。 - `sidepanel/ip-proxy-provider-711proxy.js`：侧边栏 711Proxy 输入辅助逻辑，负责从 host、username、region 输入中推断和归一化国家/地区参数。 - `sidepanel/sidepanel.css`：侧边栏样式文件；当前额外提供 Hotmail / 2925 共用的号池表单容器、操作按钮行、统一的收起态列表高度样式，以及 IP 代理配置区、状态卡和操作按钮样式；步骤列表额外提供执行范围禁用态样式。 @@ -179,7 +207,7 @@ receive 模式把账号池开关一起隐藏；当前在 `邮箱生成` 区域新增 `自定义邮箱池` 选项和多行邮箱池输入框，并在 `邮箱服务 = 自定义邮箱` 时 额外显示 `自定义号池` 文本框；当邮箱服务为 iCloud 时，额外提供目标邮箱类型与转发邮箱 provider 配置，用于选择直接从 iCloud 收件箱收 码或从 QQ / 网易 / Gmail 转发目标邮箱收码；当邮箱服务或邮箱生成器为 Cloud Mail 时，额外显示 API 地址、管理员账号、接收邮箱和生成域名配置行；当邮箱服务为 YYDS Mail 时，额外显示 API Key 与 Base URL 配置行，并隐藏普通邮箱生成/转发邮箱相关配置；来源下拉框当前支持 `CPA / SUB2API / Codex2API`，其中 Codex2API 额外提供后台地址和管理密 - 钥配置行；设置卡片新增 `IP代理` 开关与代理配置折叠区，支持 711Proxy 账号密码模式、代理状态卡与出口检测按钮；接码卡内把注册方式、接码配置、接码订单运行态与“注册手机号”身份运行态分层展示，“注册手机号”位于订单运行状态下方，不嵌入当前分配/验证码网格；设置卡片新增 `Plus 模式` 开关与 PayPal 账号下拉框，右侧使用公共表单弹窗添加账号；GPC Plus 配置额外提供只读 API 地址、API Key、专用手机号、OTP 渠道、本地 OTP helper 开关、helper URL 与 PIN，并提供 `购买卡密` 与 `转换 API Key` 入口；Hotmail / 2925 两个账号池当前都使用统一的头部“添加账号/取消添加”按钮和共享表单容器；设置卡片还新增“授权总超时”开关，用于控制 Step 7 后链 5 分钟总预算；注册邮箱下方新增 `执行范围` 行，目前只在 codex/openai flow 显示，用于配置允许执行的起止步骤。 + 钥配置行；设置卡片新增 `IP代理` 开关与代理配置折叠区，支持 711Proxy 账号密码模式、代理状态卡与出口检测按钮；接码卡内把注册方式、接码配置、接码订单运行态与“注册手机号”身份运行态分层展示，“注册手机号”位于订单运行状态下方，不嵌入当前分配/验证码网格；设置卡片新增 `Plus 模式` 开关，并在 `Plus 支付` 之上新增 `账号接入策略` 下拉；该下拉会按当前来源动态显示 `OAuth / 导入当前 ChatGPT 会话到 CPA / 导入当前 ChatGPT 会话到 SUB2API`，不支持的来源会直接禁用并显示“当前来源仅支持 OAuth”；PayPal 账号下拉框继续使用公共表单弹窗添加账号；GPC Plus 配置额外提供只读 API 地址、API Key、专用手机号、OTP 渠道、本地 OTP helper 开关、helper URL 与 PIN，并提供 `购买卡密` 与 `转换 API Key` 入口；Hotmail / 2925 两个账号池当前都使用统一的头部“添加账号/取消添加”按钮和共享表单容器；设置卡片还新增“授权总超时”开关，用于控制 Step 7 后链 5 分钟总预算；注册邮箱下方新增 `执行范围` 行，目前只在 codex/openai flow 显示，用于配置允许执行的起止步骤。 - `sidepanel/paypal-manager.js`：侧边栏 PayPal 账号管理器，负责 Plus 模式下的账号下拉框渲染、添加账号弹窗、保存账号与切换当前账号。 - `sidepanel/sidepanel.js`：侧边栏主入口脚本，负责 UI 状态同步、动态步骤渲染、按钮交互、共享验证码自动重发次数配置与广播接收，并装 配 Hotmail / 2925 / iCloud / LuckMail / 贡献模式 / 账号记录面板 / 贡献内容更新服务；当前贡献模式的“开始贡献”会直接复用主自动流程启 @@ -188,8 +216,7 @@ 示并同时服务于 provide / receive 两种模式；当 provider 为 iCloud 时，会保存并回显目标邮箱类型与转发邮箱 provider，相关 provider 选 项和 label 复用 `mail-provider-utils.js`；Cloud Mail 配置保存、回显和显隐由这里接入，可分别服务于邮箱生成器和转发收件 provider；YYDS Mail 配置保存、回显和显隐由这里接入，只暴露 API Key / Base URL，并在点击“获取”或自动运行时委托后台创建临时邮箱；执行范围配置在这里保存为 `stepExecutionRangeByFlow`，UI 只派生 `disabled` 展示态，不把禁用态写回 `nodeStatuses`；手动点击“获取/生成邮箱”时，这里会把输入框当前可见邮箱一并传给后台，作为 Duck 新地址检测的优先对比基线；`自定义邮箱池` 模式会按邮箱池长度锁定自动轮数，并把当前输入的邮箱池配置参与自动启动前保 存；点击“自动”时会先冻结当时的目标轮数，避免启动前的异步刷新、保存或后台旧状态回灌把输入框重置为 1；`邮箱服务 = 自定义邮箱` 时，如果配置了 `customMailProviderPool`，也会按号池长度锁定自动轮数并在 Auto 中按轮次分配注册邮箱，同时 - 在普通失败时继续复用当前邮箱，只有成功或出现手机号验证时才切换下一个邮箱；Plus 模式开启后，步骤列表会切换为 13 步，并显示 PayPal 账 - 号下拉框与添加入口；当前选中的 PayPal 账号会同步回兼容字段 `paypalEmail / paypalPassword` 供后台步骤复用；Step 8 的自定义邮箱确认弹 + 在普通失败时继续复用当前邮箱，只有成功或出现手机号验证时才切换下一个邮箱；Plus 模式开启后，这里会根据 `activeFlowId / targetId / signupMethod / plusPaymentMethod / plusAccountAccessStrategy` 动态重建步骤列表与尾链：邮箱注册且来源支持时，可把原本的 OAuth 尾链替换为 `sub2api-session-import` 或 `cpa-session-import`；不支持时则自动回退到 OAuth；账号接入策略选择器也会在这里按 capability 动态禁用、回显说明文案并把配置持久化；当前选中的 PayPal 账号会同步回兼容字段 `paypalEmail / paypalPassword` 供后台步骤复用；Step 8 的自定义邮箱确认弹 窗当前额外提供“出现手机号验证”按钮，用于直接走与真实 add-phone 一致的 fatal 分支；HeroSMS 国家列表 会在 sidepanel 初始化时拉取并恢复到本地保存的国家/API 设置，接码开关关闭时会直接隐藏相关配置；账号记录快照同步改为默认自动模式，只 要本地 helper 可用就会自动落盘；新来源 Codex2API 在这里仅补充来源配置接线、表单显隐和 Step 10 按钮文案，不承接协议业务逻辑； @@ -203,7 +230,10 @@ - `tests/activation-utils.test.js`：测试内容脚本激活策略与平台回调可恢复错误判断。 - `tests/address-sources.test.js`：测试 Plus 模式本地地址 seed 表的国家归一化、fallback 国家选择与基础地址字段。 - `tests/auth-page-recovery.test.js`：测试认证页共享恢复层的重试页识别与恢复行为。 +- `tests/auth-japanese-localization.test.js`：测试登录、验证码、OAuth 同意页与资料页对日文按钮和文案的本地化识别。 - `tests/auto-run-fresh-attempt-reset.test.js`：测试自动运行在新一轮开始前会重置旧运行时上下文，并补充 `gmailBaseEmail` / `mail2925BaseEmail` 在 fresh reset 后仍被保留的回归验证。 +- `tests/auto-run-hotmail-preflight.test.js`：测试自动运行控制器在每轮 fresh attempt 前会先预检 Hotmail 邮箱可用性。 +- `tests/auto-run-step4-restart.test.js`：测试步骤 4 失败后的同邮箱重开、`user_already_exists` 终止分支、注册链跳过与手机号状态清理。 - `tests/auto-run-step4-mail2925-thread-terminate.test.js`：测试步骤 4 命中 2925“结束当前尝试”错误时，不会再沿用当前邮箱回到步骤 1 重开，而是直接把错误抛给自动重试控制器。 - `tests/auto-run-timer-session-guard.test.js`：测试自动运行的旧计时计划在 Stop 使 session 失效后，不能再把已停止的自动流程重新拉起。 - `tests/auto-run-add-phone-stop.test.js`：测试自动运行控制器在开启自动重试时，遇到 `add-phone / 手机号页` 会直接结束当前轮并继续下一轮，而不是把整条自动流程暂停。 @@ -213,6 +243,12 @@ - `tests/background-auto-run-module.test.js`：测试自动运行控制器模块已接入且导出工厂。 - `tests/background-account-run-history-module.test.js`：测试账号记录模块已接入、导出工厂，能够保留并归一化停止记录、归一化失败标签、计算自动重试次数、归并同一轮邮箱/手机号身份，并支持清理后同步完整快照。 - `tests/background-account-history-settings.test.js`：测试账号运行历史的独立配置项归一化，不再复用 Hotmail 模式作为启停条件。 +- `tests/background-auth-chain-guard.test.js`：测试认证顶层链路的去重、Stop 重抛、OAuth 总预算窗口和 `fetch-signup-code` 网络重试边界。 +- `tests/background-auth-tab-snapshot.test.js`：测试认证标签快照在脚本执行失败时会回退到标签页 URL 做页面状态判断。 +- `tests/background-cloudflare-temp-email-settings.test.js`：测试 Cloudflare Temp Email 随机子域名设置与 OAuth 总超时配置的持久化归一化。 +- `tests/background-cpa-api.test.js`：测试 CPA 管理接口模块的地址归一化、OAuth 地址获取、callback 提交，以及 ChatGPT 会话导入 payload 构建与返回结果。 +- `tests/background-cpa-session-import.test.js`：测试 CPA 会话导入尾节点的标签页选择、会话读取、日志上报、结果透传和后台接线约束。 +- `tests/background-cpa-state-plumbing.test.js`：测试步骤 1 与消息路由对 CPA OAuth 运行态字段的保存、回写和 reset 接线。 - `tests/background-kiro-state-module.test.js`：测试 Kiro 运行态模块已接入且导出工厂，并覆盖默认命名空间、状态归一化、节点完成回写和下游重置规则。 - `tests/background-kiro-register-runner-module.test.js`：测试 Kiro 注册页执行器已接入且导出工厂，并覆盖步骤 1~6 的状态推进、页面命令派发与注册态回写。 - `tests/background-kiro-desktop-authorize-runner-module.test.js`：测试 Kiro 桌面授权执行器已接入且导出工厂，并覆盖 callback 捕获、state 校验、token 兑换和授权态更新。 @@ -220,6 +256,9 @@ - `tests/background-contribution-mode.test.js`：测试贡献模式的后台运行态与公开 OAuth 接入，覆盖 `contributionMode` 只存在于运行态、`SET_CONTRIBUTION_MODE / POLL_CONTRIBUTION_STATUS` 消息接入、reset 保留贡献运行态，以及 callback 自动提交在“无需手动提交”场景下的兼容处理。 - `tests/background-custom-email-pool.test.js`：测试后台对自定义邮箱池生成方式，以及自定义邮箱服务号池的归一化、标签文案和按轮次取邮箱逻辑。 - `tests/background-generated-email-module.test.js`：测试生成邮箱辅助模块已接入且导出工厂，并覆盖 Duck 对比基线优先级、2925 receive 模式回退普通邮箱生成、自定义邮箱池按轮次取值、2925 provide 模式账号池预热，以及 Duck / iCloud 在保留手机号身份场景下的共享持久化传参。 +- `tests/background-generate-password-policy.test.js`：测试共享密码生成器满足当前统一密码策略。 +- `tests/background-effective-plus-account-access-strategy.test.js`：测试后台对 Plus `账号接入策略` 的最终生效值解析，确保来源不支持或注册方式不匹配时会自动回退到 OAuth 尾链。 +- `tests/background-hotmail-local-helper-rule-forwarding.test.js`：测试后台会把 flow-aware 邮件规则元数据转发给 Hotmail 本地 helper 与共享选码路径。 - `tests/background-icloud-preserve.test.js`：测试 iCloud Hide My Email 在 Step 8 `add-email` 的保留手机号身份复用路径里，会调用共享注册邮箱状态持久化，而不是回退到直接 `setEmailState`。 - `tests/background-icloud.test.js`：测试 iCloud 相关后台纯函数与别名收尾逻辑。 - `tests/background-icloud-login-help.test.js`：测试 iCloud 登录判定、页面上下文回退、别名缓存回退和保留异常恢复的关键源码约束。 @@ -227,54 +266,94 @@ - `tests/background-ip-proxy-core.test.js`：测试 IP 代理核心解析与接入约束，覆盖注释行过滤、代理条目归一化、711 固定账号参数叠加、PAC 生成、侧栏脚本加载顺序和自动切换阈值钳制。 - `tests/background-logging-status-module.test.js`：测试日志 / 状态模块已接入且导出工厂。 - `tests/background-luckmail.test.js`：测试 LuckMail 相关后台逻辑，如购买、复用、标记已用与重置。 +- `tests/background-mail2925-entry-behavior.test.js`：测试 2925 邮箱会话在复用、强制登录、邮箱不匹配和号池开关下的入口行为。 +- `tests/background-mail2925-relogin-wait.test.js`：测试 2925 强制重登入口 URL、长登录超时与前后固定等待窗口。 - `tests/background-mail2925-session-module.test.js`：测试 2925 会话模块已接入且导出工厂，并覆盖命中上限后“禁用 24 小时 + 切下一个号 + 自动登录”的核心链路。 - `tests/background-mail2925-signup-flow.test.js`：测试注册页辅助层在 2925 provider 下，会先确保账号池里已分配可用账号，再继续生成别名邮箱。 +- `tests/background-mail-rule-registry-module.test.js`：测试邮件规则注册表与 OpenAI mail rules 模块接入，并覆盖验证码轮询 payload 构造。 - `tests/background-message-router-module.test.js`：测试消息路由模块已接入且导出工厂。 +- `tests/background-message-router-plus-final-step.test.js`：测试消息路由会按 Plus 当前最终节点追加成功记录，不再写死步骤 10。 - `tests/background-message-router-step2-skip.test.js`：测试步骤 2 直接落到验证码页时的跳步与状态保护逻辑，并覆盖邮箱身份写入时清理旧手机号注册运行态。 - `tests/background-navigation-utils-module.test.js`：测试导航工具模块已接入且导出工厂。 +- `tests/background-operation-delay-exclusions.test.js`：测试 `confirm-oauth / platform-verify` 以及相关平台链路不接入操作间延迟门控。 +- `tests/background-operation-delay-settings.test.js`：测试 `operationDelayEnabled` 的默认值、持久化 payload 与严格归一化行为。 - `tests/background-panel-bridge-module.test.js`：测试面板桥接模块已接入且导出工厂。 - `tests/background-paypal-account-store-module.test.js`：测试 PayPal 账号池后台模块已接入、导出工厂，并覆盖当前账号选择会同步回兼容字段 `paypalEmail / paypalPassword`。 - `tests/background-platform-verify-codex2api.test.js`：测试 Codex2API 新来源在步骤 10 走协议式 callback 交换，不依赖后台页面注入。 +- `tests/background-platform-verify-cpa-api.test.js`：测试 `platform-verify` 优先走 CPA 管理接口提交回调，并透传 SUB2API 可见步骤与账号优先级。 +- `tests/background-registration-account-used.test.js`：测试标记当前注册账号已用时会以最新运行态为准，而不是沿用旧 checkout 快照。 +- `tests/background-sub2api-session-import.test.js`：测试 SUB2API 会话导入尾节点的管理接口登录、分组/代理选择、导入结果解析和后台接线约束。 - `tests/background-registration-email-state.test.js`：测试注册邮箱运行态共享模块对 `registrationEmailState` 的维护，覆盖清空当前邮箱时保留上一比较基线、Duck 生成前优先使用侧栏当前可见邮箱作为基线，以及流程邮箱写入时保留手机号身份的共享纯函数。 +- `tests/background-runtime-state-module.test.js`：测试 runtime-state 模块接入、state view/state patch 构造与 flow-aware 运行态投影。 +- `tests/background-security-block-alert.test.js`：测试安全拦截提示标题会区分 Cloudflare 风控与普通网络超时。 +- `tests/background-settings-import-mode-validation.test.js`：测试导入配置时会先归一化当前 capability 不支持的模式开关与接入策略。 - `tests/background-signup-flow-module.test.js`：测试注册页辅助模块已接入且导出工厂。 +- `tests/background-signup-method-settings.test.js`：测试注册方式按当前轮冻结、能力回退以及步骤标题解析。 - `tests/background-skip-step-linking.test.js`：测试手动跳过步骤 1 时，会级联跳过步骤 2~6，并仅跳过其中未完成、未运行且仍在当前执行范围内的步骤。 - `tests/background-settings-schema-persistence.test.js`：测试后台设置持久化已接入统一 settings schema，并覆盖 flow-aware 配置与旧字段兼容回写。 - `tests/background-step-execution-range.test.js`：测试 `stepExecutionRangeByFlow` 对 codex/openai flow 的归一化、节点执行范围过滤、后台执行禁用拦截，以及保存进度只统计允许执行节点。 - `tests/background-signup-step2-branching.test.js`：测试在 Gmail / 2925 模式下，已有兼容别名邮箱时应直接复用，不应再次重生成，并覆盖生成阶段已落库邮箱不会被流程层重复覆盖，以及 Step 8 `add-email` 复用已有邮箱时会委托共享注册邮箱状态持久化保留手机号身份。 +- `tests/background-step3-password-reuse.test.js`：测试步骤 3 对同邮箱密码复用、phone-only 身份与注册方式 fallback 的处理。 - `tests/background-step-modules.test.js`：测试步骤模块文件都已由后台入口加载。 - `tests/background-step-node-registry-module.test.js`：测试节点注册表模块已接入且导出工厂，并覆盖节点元数据保留与 display order 执行顺序。 +- `tests/background-step4-filter-window.test.js`：测试步骤 4 的 2925 固定回看窗口、Cloudflare Temp Email/iCloud/短信分支与重试页恢复。 +- `tests/background-step5-post-completion-validation.test.js`：测试步骤 5 完成后会先验证 about-you 重试页恢复，再允许成功收尾。 - `tests/background-step5-submit-short-circuit.test.js`：测试步骤 5 会把生成好的资料直接转发给内容脚本，并依赖完成信号收尾。 - `tests/background-step6-retry-limit.test.js`：测试步骤 6 的注册成功等待、可选 cookies 清理开关，以及步骤 7 的有限重试上限与 `add-phone` 命中后的立即跳出行为。 - `tests/background-step7-recovery.test.js`：测试步骤 8 获取登录验证码后直接提交（不再回放步骤 7），覆盖邮箱验证码页、真实手机验证码页、`add-email` 绑定邮箱后收码、`email_in_use / max_check_attempts` 当前步骤恢复、2925 固定回看窗口与关闭重发间隔。 +- `tests/background-step-completion.test.js`：测试后台完成节点时在最终节点与普通节点场景下的完成信号时机。 - `tests/background-step-registry.test.js`：测试后台步骤注册表、Kiro 执行器映射与共享 workflow 定义已接入。 +- `tests/background-stop-gap-record.test.js`：测试无运行节点时 Stop 记录会补挂到下一个未完成节点。 - `tests/background-tab-runtime-module.test.js`：测试标签运行时模块已接入且导出工厂，并覆盖等待标签完成、等待标签稳定完成，以及等待过程中的 Stop 中断行为。 - `tests/background-verification-flow-module.test.js`：测试验证码流程模块已接入且导出工厂。 - `tests/phone-auth-country-match.test.js`：测试认证页手机号国家选择在页面本地化时，仍能用 HeroSMS 的英文国家名匹配对应国家选项。 - `tests/phone-country-utils.test.js`：测试手机号国家/区号共享工具的区号提取、最长前缀解析、国家别名匹配，以及 manifest 与后台动态注入顺序。 +- `tests/phone-sms-provider-registry.test.js`：测试接码 provider 注册表对平台 ID、顺序、标签、模块装载与实例化入口的归一化。 - `tests/phone-verification-flow.test.js`：测试 OpenAI 专属手机号验证流程对 HeroSMS / 5sim / NexSMS 的取号、复用、重发、换号与 Step 7 重开错误分支。 - `tests/paypal-approve-detection.test.js`：测试 Plus 第 8 步后台执行器对 PayPal 标签页发现、分离式账号/密码页识别、联合登录页识别，以及登录后直接离开 PayPal 页的分支判断。 - `tests/paypal-flow-content.test.js`：测试 PayPal 内容脚本对可见邮箱/密码输入框的识别，并覆盖邮箱页即使已预填相同账号也会先清空再重填后继续下一步。 - `tests/gpc-sms-helper-script.test.js`：测试 GPC macOS 本地短信 helper 在非 macOS 环境下会提示平台与 iPhone 短信转发要求。 +- `tests/gopay-approve-source.test.js`：测试 GoPay 自动审批执行器对 OTP/PIN/Pay now/iframe/重建 checkout sentinel 的页面识别与回退。 +- `tests/gopay-flow-content.test.js`：测试 GoPay 内容脚本的人类点击、表单提交、operation delay 包装与 Continue/Pay now 控件识别。 +- `tests/gopay-manual-confirm.test.js`：测试 GoPay 手动确认节点会按当前 Plus 尾链生成 OAuth、SUB2API 或 CPA 的继续提示文案。 +- `tests/gopay-utils.test.js`：测试 GoPay/GPC 工具层的 OTP/PIN 输入归一化、helper URL、payload 和余额解析。 +- `tests/plus-checkout-address-input.test.js`：测试 Plus checkout 内容脚本的国家/商户路径、结构化地址识别、付款方式判定和 GoPay 控件查找。 +- `tests/plus-checkout-create-wait.test.js`：测试 Plus checkout 创建节点的等待策略、GoPay 参数透传与 GPC helper 队列权限/余额校验。 - `tests/plus-checkout-billing-tab-resolution.test.js`：测试 Plus 第 7 步可直接接管当前 checkout 标签页，并把 PayPal、账单地址、Google 地址推荐和订阅按钮操作路由到对应 Stripe iframe；当前也覆盖 GPC 队列任务轮询、本地 OTP 自动读取、手动 OTP 输入、PIN 提交与任务终止分支。 +- `tests/plus-return-confirm-wait.test.js`：测试 Plus return confirm 在检测到回跳页后会固定等待 20 秒再结束。 +- `tests/provider-operation-delay.test.js`：测试 Duck 地址生成与 2925 会话准备接入操作间延迟，而清理路径保持免延迟。 +- `tests/qq-mail-content.test.js`：测试 QQ 邮箱内容脚本会把 runtime mail rule 的验证码模式转发到新邮件匹配链路。 +- `tests/run-count-unlimited.test.js`：测试自动运行轮数不再被 50 封顶，且旧 active 状态不会把手动输入轮数重置回去。 - `tests/cloudflare-temp-email-provider.test.js`：测试 Cloudflare Temp Email provider 的轮询与目标邮箱选择逻辑。 - `tests/cloudflare-temp-email-utils.test.js`：测试 Cloudflare Temp Email 工具层的 URL、域名、邮件解析逻辑。 - `tests/cloudmail-provider.test.js`：测试 Cloud Mail provider 的验证码轮询和生成/转发收件目标邮箱选择逻辑，并覆盖生成邮箱时对共享注册邮箱状态持久化的接入。 - `tests/cloudmail-utils.test.js`：测试 Cloud Mail 工具层的 URL、域名、鉴权头、Token 与邮件响应归一化逻辑。 +- `tests/content-operation-delay.test.js`：测试内容脚本操作间延迟层的执行顺序、默认启用、排除步骤、悬挂恢复和 stop-aware sleep。 - `tests/yyds-mail-provider.test.js`：测试 YYDS Mail provider 创建邮箱、临时 token 收信、邮件详情读取、验证码轮询与运行态清理逻辑。 - `tests/yyds-mail-utils.test.js`：测试 YYDS Mail 工具层的 Base URL、请求头、邮箱响应、邮件列表/详情与验证码字段归一化逻辑。 - `tests/content-utils.test.js`：测试内容脚本公共工具层对 `mail.126.com` 等网页邮箱来源的识别逻辑。 - `tests/duck-mail-content.test.js`：测试 Duck 页面脚本会等待页面现有地址或显式基线出现后再比较新地址，并要求新地址稳定渲染后才判定生成成功。 +- `tests/five-sim-provider.test.js`：测试 5sim 平台的余额、国家/价格列表、买号、查码、finish/cancel/ban/reuse 与限流错误归类。 - `tests/hotmail-api-mode.test.js`：测试 Hotmail API 模式相关文案和集成方式。 +- `tests/hotmail-auto-run-preflight.test.js`：测试 Hotmail 自动运行预检中的账号分配、验证和失败后切换行为。 - `tests/hotmail-cors-headers.test.js`：测试 Microsoft token 请求相关 DNR 配置。 +- `tests/hotmail_helper_logging_test.py`：测试 Hotmail 本地 helper 在 OpenAI 邮件日志中优先输出完整正文，并可从截断 preview 回退到 full body 提码。 - `tests/hotmail-utils.test.js`：测试 Hotmail 工具层的账号筛选、验证码提取和消息匹配逻辑。 - `tests/icloud-mail-content.test.js`：测试 iCloud Mail 内容脚本读取邮件正文和选中状态逻辑。 - `tests/icloud-utils.test.js`：测试 iCloud 工具层的 host、别名列表、保留状态与筛选逻辑。 +- `tests/kiro-register-page-fatal-state.test.js`：测试 Kiro 注册页会把 AWS request error 判定为代理失败，并正确识别 Kiro Web 登录成功态。 - `tests/luckmail-utils.test.js`：测试 LuckMail 工具层的购买记录、邮件、游标和验证码匹配逻辑。 +- `tests/mail-163-content.test.js`：测试网易邮箱轮询脚本的选区回退、时间解析、正文读取与 runtime mail rule 识别。 +- `tests/mail-163-manifest.test.js`：测试 manifest 中网易邮箱内容脚本覆盖到 `126` 子域名。 +- `tests/mail-polling-operation-delay-exclusion.test.js`：测试邮件轮询、邮件清理与 WhatsApp 读码链路不接入操作间延迟。 - `tests/mail-provider-utils.test.js`：测试网页邮箱 provider 配置工具对 `126` 等 provider 的归一化与入口配置解析，以及 iCloud 转发收码 provider 选项、归一化和配置复用。 - `tests/mail-2925-content.test.js`：测试 2925 邮箱内容脚本的轮询快照、忽略邮箱对比、按步骤会话隔离已试验证码、单封邮件删除与整箱删除逻辑。 - `tests/mail2925-utils.test.js`：测试 2925 账号池工具层的账号归一化、冷却期判断、可用账号挑选与批量导入解析。 - `tests/managed-alias-utils.test.js`：覆盖 Gmail / 2925 共享别名工具的解析、生成、兼容性判断。 +- `tests/message-router-window-lock.test.js`：测试消息路由会从 sidepanel payload 或 sender tab 继承 automation window 锁定信息。 - `tests/microsoft-email.test.js`：测试 Microsoft 邮件拉取与验证码提取逻辑。 +- `tests/operation-delay-docs.test.js`：测试 README 与使用教程对操作间延迟的文档说明保持最新。 +- `tests/operation-delay-injection.test.js`：测试 manifest 与动态注入路径只在覆盖到的认证/支付脚本里加载操作间延迟模块。 - `tests/sidepanel-hotmail-manager.test.js`：测试侧边栏 Hotmail 管理器模块接线、共享号池表单显隐交互与空态渲染。 - `tests/sidepanel-contribution-button.test.js`：测试侧边栏顶部 `贡献` 按钮的 HTML 接线、更新提示气泡接线，以及相关脚本加载顺序。 - `tests/sidepanel-account-records-manager.test.js`：测试侧边栏账号记录覆盖层的 HTML 接入、helper 地址归一化与 manager 渲染逻辑。 @@ -284,34 +363,57 @@ - `tests/sidepanel-custom-email-pool.test.js`：测试侧边栏自定义邮箱池、自定义邮箱服务号池的 HTML 接线，以及邮箱池长度与自动轮数之间的联动规则。 - `tests/sidepanel-contribution-mode.test.js`：测试侧边栏贡献模式的 HTML 接线、runtime-only 设置保护，以及贡献模式 manager 复用主自动流启动、状态轮询和退出清理逻辑。 - `tests/sidepanel-contribution-mode-flow-scope.test.js`：测试贡献模式只在 `openai` flow 内生效，不会污染 Kiro flow 的来源与面板作用域。 +- `tests/sidepanel-contribution-update-hint.test.js`：测试顶部贡献更新轻提示在公告、教程和托管 auto-run 提醒并存时的文案合成。 - `tests/sidepanel-flow-source-registry.test.js`：测试 sidepanel 的 flow/source 选择器、Kiro 来源切换与显隐分组接线。 - `tests/sidepanel-auto-run-content-refresh.test.js`：测试点击“自动”时会先冻结当前轮数并刷新贡献内容更新摘要，且刷新失败或启动前状态回灌不会阻塞或改写自动流程启动目标。 +- `tests/sidepanel-auto-run-risk-warning.test.js`：测试自动运行在高轮数且未配置节点轮询时会弹出风险提醒。 +- `tests/sidepanel-cloudflare-temp-email-random-subdomain.test.js`：测试 Cloudflare Temp Email 独立区域、随机子域名开关、域名列表恢复与提示文案联动。 +- `tests/sidepanel-header-links.test.js`：测试侧边栏头部仓库首页与 Releases 入口的 HTML 接线与链接解析。 - `tests/sidepanel-icloud-manager.test.js`：测试侧边栏 iCloud 管理器模块接线与空态渲染。 - `tests/sidepanel-icloud-provider.test.js`：测试侧边栏 iCloud 登录地址解析、目标邮箱类型 / 转发邮箱 provider 保存、回显和显隐联动。 - `tests/sidepanel-luckmail-manager.test.js`：测试侧边栏 LuckMail 管理器模块接线与空态渲染。 +- `tests/sidepanel-mail2925-base-email.test.js`：测试 2925 当前号池邮箱会回写到手动基邮箱字段，并持久化当前账号选择。 +- `tests/sidepanel-mail2925-edit.test.js`：测试 2925 账号表单的折叠交互，以及现有账号编辑入口渲染。 - `tests/sidepanel-mail2925-manager.test.js`：测试侧边栏 2925 管理器模块接线、共享号池表单脚本加载顺序、显隐交互与空态渲染。 - `tests/sidepanel-mail2925-mode.test.js`：测试侧边栏保留 `2925 provide / receive` 模式行与独立的号池配置行，并验证 sidepanel 只在 provide 模式下把 2925 视为别名邮箱 provider。 +- `tests/sidepanel-new-user-guide.test.js`：测试首次新手引导提示的一次性关闭状态，以及确认后跳转贡献入口的行为。 +- `tests/sidepanel-operation-delay.test.js`：测试侧边栏不再暴露操作间延迟开关，并保持该状态统一归一为启用。 +- `tests/sidepanel-password-visibility.test.js`：测试侧边栏与共享表单弹窗中的密码字段都支持显示/隐藏切换。 +- `tests/sidepanel-phone-verification-settings.test.js`：测试接码平台多 provider UI、免费复用号码、运行态注册手机号、CPA 风险提醒与国家/价格联动。 - `tests/sidepanel-paypal-manager.test.js`：测试侧边栏公共表单弹窗脚本与 PayPal manager 的加载顺序，以及 PayPal 账号保存后会立即选中当前账号。 +- `tests/sidepanel-plus-payment-method.test.js`：测试 Plus 支付方式切换、GPC helper UI、共享步骤刷新与手动确认状态解析。 +- `tests/sidepanel-sub2api-priority-settings.test.js`：测试 SUB2API 账号优先级输入行的位置、持久化、锁定态与 capability 显隐接线。 +- `tests/sidepanel-window-lock.test.js`：测试侧边栏启动自动流程时会附带当前窗口 ID，普通消息不受影响。 - `tests/signup-entry-diagnostics.test.js`：测试注册入口与密码页诊断快照输出，包括密码页错误文案字段。 - `tests/signup-step2-email-switch.test.js`：测试 Step 2 在手机号输入模式下切回邮箱输入模式、本地化邮箱输入框识别、官网注册入口点击等待与最多 5 次重试，以及手机号注册时国家下拉框可视区号同步。 +- `tests/signup-verification-state-guard.test.js`：测试注册验证码页、重试页、资料页与已登录首页之间的状态优先级判定不会互相误伤。 - `tests/signup-page-tab-cleanup.test.js`：测试注册页来源标签的冲突清理逻辑。 - `tests/source-registry-module.test.js`：测试共享来源注册表模块已接入且导出工厂，并覆盖 flow runtime source 与共享 mail source 的合并。 +- `tests/plus-account-access-strategy.test.js`：测试侧边栏 `账号接入策略` 的 HTML 接线、capability 回显、动态禁用与步骤尾链刷新。 - `tests/step-definitions-module.test.js`：测试共享步骤定义模块、flow-specific workflow 输出与侧边栏脚本加载顺序。 - `tests/step3-direct-complete.test.js`：测试步骤 3 在提交前先完成上报，并保留延迟提交回调的可执行性验证。 +- `tests/step4-split-code-submit.test.js`：测试验证码分格输入、延迟提交、注册手机号到邮箱验证码页的 handoff，以及组合资料页预填行为。 +- `tests/step4-submit-retry-recovery.test.js`：测试步骤 4 提交验证码后的重试页恢复、直达首页跳过资料页与成功判定边界。 - `tests/step5-age-consent.test.js`：测试步骤 5 在年龄页会先勾选顶部“我同意以下所有各项”复选框，再点击提交。 - `tests/step5-direct-complete.test.js`：测试步骤 5 在资料页点击提交后立即完成当前步骤。 - `tests/step6-login-state.test.js`：测试 OAuth 登录状态识别逻辑，当前对应步骤 7 链路，并覆盖 `phone-verification` 页面不会被误判成邮箱验证码页、真实 `add-email` 页面不会被误判成普通邮箱输入页。 +- `tests/step6-oauth-consent-skip.test.js`：测试密码页或步骤 7 入口已落在 OAuth 同意页时会直接跳过登录验证码节点。 +- `tests/step6-passwordless-otp-login.test.js`：测试无密码页时会切换到一次性验证码登录，缺少入口时返回可恢复结果。 - `tests/step6-timeout-recovery.test.js`：测试 OAuth 登录超时报错页的可恢复结果构造，当前对应步骤 7 链路。 - `tests/step7-phone-login-entry.test.js`：测试 OAuth 手机号登录入口识别、真实 add-phone 与手机号登录页区分、慢切换等待窗口、手机号登录页可视国家下拉框会按本轮号码区号自动切换，以及输入框只剩区号时不会继续提交。 - `tests/step8-callback-handling.test.js`：测试 localhost 回调地址捕获逻辑，当前对应步骤 9。 - `tests/step8-debugger-stop.test.js`：测试调试器点击在 Stop 场景下的中止行为，当前对应步骤 9。 +- `tests/step8-restart-step7-error.test.js`：测试步骤 8 在登录超时重试页、Cloudflare 风控页和 add-email handoff 边界上的 restart-step7 行为。 - `tests/step8-retry-page-recovery.test.js`：测试 OAuth 同意页点击后的重试页恢复分支，以及手机号验证完成后会继续回到 OAuth 同意页等待，当前对应步骤 9。 - `tests/step8-state-timeout-retry.test.js`：测试认证页通信错误是否可判定为可重试，当前对应步骤 9。 - `tests/step8-stop-cleanup.test.js`：测试 OAuth 确认流程在 Stop 后能正确清理监听器与挂起状态，当前对应步骤 9。 +- `tests/step9-oauth-timeout-toggle.test.js`：测试步骤 9 在等待 localhost callback 时会动态遵守 OAuth 总超时开关与重定向缓冲窗口。 - `tests/step9-profile-after-phone-verification.test.js`：测试 Step 9 后置手机号验证提交后若落到注册资料页，会复用 Step 5 资料填写逻辑，并覆盖未出现资料页时继续保持原 OAuth 同意页路径。 - `tests/step9-cpa-mode.test.js`：测试本地 CPA 平台回调跳过策略判断，当前作用于步骤 10。 - `tests/step9-localhost-cleanup-scope.test.js`：测试 localhost callback 与路径前缀残留页的精确清理范围，当前对应步骤 10 收尾。 - `tests/step9-status-diagnostics.test.js`：测试平台回调成功判定、红色错误态过滤，以及成功徽标与失败提示并存时的优先级，当前对应步骤 10。 +- `tests/step9-timeout-recovery.test.js`：测试步骤 9 在 OAuth localhost 回调超时后会触发恢复 hook、重试预算检查并清理监听器。 +- `tests/sub2api-panel-proxy.test.js`：测试 SUB2API OAuth 与平台回调链路会继承默认代理、多分组配置和账号优先级。 - `tests/update-service.test.js`：测试侧边栏更新检查服务在 `Ultra` / 历史 `Pro` / legacy `v` 混合版本和旧缓存场景下都能按版本族正确排序，不会把历史版本误显示成最新可升级版本。 - `tests/verification-stop-propagation.test.js`：测试验证码流程在 Stop 场景下的错误传播与不中途降级。 - `tests/verification-flow-polling.test.js`：测试 2925 长轮询参数、验证码提交流程中的 `beforeSubmit` 钩子执行顺序，以及步骤 8 提交验证码后进入手机号页时会把“继续手机号验证”状态交给步骤 9 处理。