更新各种md文档

项目完整链路说明.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`。