refactor flows into canonical runtime architecture

项目文件结构说明.md

@@ -1,4 +1,4 @@
-# 项目文件结构说明
+# 项目文件结构说明
 
 本文档列出当前仓库中所有“非忽略文件”，并说明每个文件的作用。
 
@@ -54,11 +54,11 @@
 - `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` 的手机号身份流则保留当前手机号身份。
-- `background/kiro/state.js`：Kiro 独立运行态模型与状态工具，负责 `kiroRuntime.session / register / webAuth / desktopAuth / upload` 的默认值、归一化、节点完成回写、下游重置和 fresh-attempt keep-state 构建。
-- `background/kiro/register-runner.js`：Kiro 注册页执行器，负责步骤 1~6 的编排、Kiro / AWS Builder ID cookies 清理、打开 `https://app.kiro.dev/signin`、选择 Builder ID 入口、注册标签页管理、邮箱/姓名/验证码/密码/授权确认，以及 Kiro Web 登录态推进。
-- `background/kiro/desktop-client.js`：Kiro 桌面授权协议层，负责桌面 OIDC client 注册、PKCE 参数生成、授权地址组装、callback 参数校验和授权码换 token。
-- `background/kiro/desktop-authorize-runner.js`：Kiro 桌面授权执行器，负责步骤 7~8 的标签页打开、授权页轮询、localhost callback 捕获，以及桌面授权完成后的凭据落库。
-- `background/kiro/publisher-kiro-rs.js`：Kiro 发布器，负责 `kiro.rs` 地址归一化、连通性探测、BuilderId profileArn 固定映射、machineId 计算、上传 payload 构建与最终凭据上传。
+- `flows/kiro/background/state.js`：Kiro 独立运行态模型与状态工具，负责 `kiroRuntime.session / register / webAuth / desktopAuth / upload` 的默认值、归一化、节点完成回写、下游重置和 fresh-attempt keep-state 构建。
+- `flows/kiro/background/register-runner.js`：Kiro 注册页执行器，负责步骤 1~6 的编排、Kiro / AWS Builder ID cookies 清理、打开 `https://app.kiro.dev/signin`、选择 Builder ID 入口、注册标签页管理、邮箱/姓名/验证码/密码/授权确认，以及 Kiro Web 登录态推进。
+- `flows/kiro/background/desktop-client.js`：Kiro 桌面授权协议层，负责桌面 OIDC client 注册、PKCE 参数生成、授权地址组装、callback 参数校验和授权码换 token。
+- `flows/kiro/background/desktop-authorize-runner.js`：Kiro 桌面授权执行器，负责步骤 7~8 的标签页打开、授权页轮询、localhost callback 捕获，以及桌面授权完成后的凭据落库。
+- `flows/kiro/background/publisher-kiro-rs.js`：Kiro 发布器，负责 `kiro.rs` 地址归一化、连通性探测、BuilderId profileArn 固定映射、machineId 计算、上传 payload 构建与最终凭据上传。
 - `background/ip-proxy-core.js`：IP 代理核心模块，负责代理条目解析、账号/接口代理池运行态、PAC 应用与清除、代理鉴权回填、出口探测、失败时的目标站点 fail-close 防漏规则，以及自动运行成功阈值后的代理切换支撑。
 - `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` 页面区分开，避免自动运行误停机。
@@ -66,63 +66,63 @@
 - `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、节点状态默认值与兼容视图输出。
+- `core/flow-kernel/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。
 - `background/panel-bridge.js`：来源桥接层；CPA 继续封装页面打开、脚本注入和通信，SUB2API / Codex2API 则通过后台协议生成 OAuth 地址。
 - `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 感知，避免用户停止后后台还继续等待并恢复执行。
+- `core/flow-kernel/tab-runtime.js`：标签页与内容脚本运行时基础设施，封装标签注册、冲突清理、消息超时、注入重试与队列；内容脚本恢复等待日志支持 `logStep / logStepKey`，用于保持 Plus 复用步骤的日志标签正确；当前等待标签完成、等待标签完成并短暂稳定、注入后的短暂延迟和内容脚本重试等待都已做 Stop 感知，避免用户停止后后台还继续等待并恢复执行。
 - `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 视图。
+- `core/flow-kernel/workflow-engine.js`：workflow 节点状态引擎，负责按当前 flow 解析节点列表、默认状态、后继节点、首个未完成节点和运行中节点，并为自动运行、恢复与手动执行提供统一 node 视图。
 
 ## `background/steps/`
 
-- `background/steps/wait-registration-success.js`：步骤 6 实现，负责注册资料提交后等待 20 秒，让注册成功状态和页面跳转稳定；默认不清理 cookies，只有侧栏第六步 `清 Cookies` 开关开启时才会在等待结束后清理 ChatGPT / OpenAI 相关 cookies。
-- `background/steps/confirm-oauth.js`：步骤 9 实现，负责 OAuth 同意页按钮定位、点击、localhost 回调监听与回调完成；等待 callback 期间会动态检查 OAuth 总预算开关，关闭后仅保留本地回调等待超时。
-- `background/steps/create-plus-checkout.js`：Plus 模式第 6 步实现，负责在已登录 ChatGPT 页面创建 PayPal / GoPay checkout session，或在 GPC 模式下读取 accessToken 并通过 `https://gpc.qlhazycoder.top/api/gp/tasks` 创建队列任务，记录 checkout / GPC task 运行态。
-- `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/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，其次使用手动运行态手机号，最后才申请接码平台号码并提交，最后根据落地页判断是否跳过后续密码步骤。
+- `flows/openai/background/steps/wait-registration-success.js`：步骤 6 实现，负责注册资料提交后等待 20 秒，让注册成功状态和页面跳转稳定；默认不清理 cookies，只有侧栏第六步 `清 Cookies` 开关开启时才会在等待结束后清理 ChatGPT / OpenAI 相关 cookies。
+- `flows/openai/background/steps/confirm-oauth.js`：步骤 9 实现，负责 OAuth 同意页按钮定位、点击、localhost 回调监听与回调完成；等待 callback 期间会动态检查 OAuth 总预算开关，关闭后仅保留本地回调等待超时。
+- `flows/openai/background/steps/create-plus-checkout.js`：Plus 模式第 6 步实现，负责在已登录 ChatGPT 页面创建 PayPal / GoPay checkout session，或在 GPC 模式下读取 accessToken 并通过 `https://gpc.qlhazycoder.top/api/gp/tasks` 创建队列任务，记录 checkout / GPC task 运行态。
+- `flows/openai/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` 也只重启当前步骤恢复链。
+- `flows/openai/background/steps/fetch-signup-code.js`：步骤 4 实现，负责注册验证码阶段的页面准备与验证码流程入口；邮箱注册继续走邮箱验证码，手机号注册改走短信验证码；当 provider 为 2925 时，会在邮箱轮询前先确保当前 2925 账号已自动登录。
+- `flows/openai/background/steps/fill-plus-checkout.js`：Plus 模式第 7 步实现，负责驱动 PayPal / GoPay checkout 页面选择付款方式、填写账单地址、提交订阅并等待跳转；GPC 模式则轮询队列任务，按远端 `api_waiting_for` 提交 OTP / PIN，并在任务失败、过期或取消时清理运行态。
+- `flows/openai/background/steps/gopay-manual-confirm.js`：GoPay 手动确认节点，负责在需要人工完成订阅时发布待确认运行态，并按当前 Plus 尾链动态生成“继续 OAuth / 继续导入 SUB2API / 继续导入 CPA”的提示文案。
+- `flows/openai/background/steps/gopay-approve.js`：GoPay 自动审批节点，负责接管 GoPay / GPC 相关标签页、识别 OTP / PIN / Pay now / Hubungkan 等页面状态，并在支付页失效时回退到重新创建 checkout。
+- `flows/openai/background/steps/fill-password.js`：步骤 3 实现，负责密码生成、保存、回填与提交；当前已改为身份中立，手机号注册遇到无密码页时会按页面状态自动跳过。
+- `flows/openai/background/steps/fill-profile.js`：步骤 5 实现，负责姓名、生日填写并把资料提交给注册页内容脚本。
+- `flows/openai/background/steps/oauth-login.js`：步骤 7 实现，负责刷新 OAuth 链接、登录和确保进入验证码页；当前会根据 `accountIdentifierType / accountIdentifier` 选择邮箱或手机号登录，手机号账号会先探测并切换手机号登录入口；普通可恢复登录态失败会按上限重试，但一旦识别到认证流程进入 `add-phone / 手机号页`，会立即退出步骤 7 内部重试。
+- `flows/openai/background/steps/open-chatgpt.js`：步骤 1 实现，负责打开 ChatGPT 官网并确认入口就绪。
+- `flows/openai/background/steps/paypal-approve.js`：Plus 模式第 8 步实现，负责驱动 PayPal 登录、关闭可见通行密钥提示、点击“同意并继续”，并等待授权流程离开 PayPal 页面。
+- `flows/openai/background/steps/cpa-session-import.js`：Plus 模式下的 CPA 会话导入尾节点，负责定位当前已登录的 ChatGPT / OpenAI 标签页、读取会话与 accessToken，并调用 `background/cpa-api.js` 直接导入 CPA。
+- `flows/openai/background/steps/platform-verify.js`：平台回调验证实现，普通模式为步骤 10；Plus 场景下只有仍走 OAuth 尾链时才会出现该节点，并按当前可见 `platform-verify` 步骤上报（常见为第 13 步）；负责 CPA 页面回调验证、SUB2API 管理接口 callback code/state 交换与账号创建，以及 Codex2API 的协议式 callback code/state 交换。
+- `flows/openai/background/steps/plus-return-confirm.js`：Plus 模式第 9 步实现，负责等待 PayPal 授权后回跳到 ChatGPT / OpenAI 页面，页面加载完成后固定等待 1 秒再完成。
+- `flows/openai/background/steps/sub2api-session-import.js`：Plus 模式下的 SUB2API 会话导入尾节点，负责读取当前 ChatGPT 会话，并调用 `background/sub2api-api.js` 的 `codex-session` 导入接口直接创建或更新 SUB2API 账号。
+- `core/flow-kernel/step-registry.js`：节点注册表工厂，负责保留 `flowId / nodeId / displayOrder / executeKey` 等稳定节点元数据，并把 flow-specific workflow node 映射到后台执行器。
+- `flows/openai/background/steps/submit-signup-email.js`：步骤 2 实现，负责按 `signupMethod` 在邮箱注册与手机号注册之间分发；切回已有注册页标签时会先等待加载完成并额外稳定 3 秒，再检查注册入口状态；邮箱分支会先点击官网“免费注册”再提交邮箱并清理旧手机号注册运行态，手机号分支会先点击官网“免费注册”并切到手机号注册入口，确认手机号输入页就绪后优先复用已有 signup activation，其次使用手动运行态手机号，最后才申请接码平台号码并提交，最后根据落地页判断是否跳过后续密码步骤。
 
 ## `content/`
 
 - `content/activation-utils.js`：内容脚本通用激活策略工具，负责按钮点击方式判断与平台回调可恢复失败文案判断。
-- `content/auth-page-recovery.js`：认证页共享恢复模块，统一封装 `Try again / 重试` 页识别、点击重试和等待退出重试页；当前由注册验证码等待、OAuth 登录恢复、OAuth 同意页重试恢复链路复用。
+- `flows/openai/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，并把页面内的按钮交互统一包进操作间延迟门控。
+- `flows/openai/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 与跳转完成状态，并向后台汇报授权页进度。
+- `flows/kiro/content/register-page.js`：Kiro 注册页内容脚本，负责识别 Kiro 官方登录页、AWS Builder ID 注册页、Kiro Web 登录完成页，并执行选择 Builder ID、填写邮箱、姓名、验证码、密码与“确认并继续 / 允许访问”等页面交互。
+- `flows/kiro/content/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 同意页”的结果反馈给后台。
-- `content/plus-checkout.js`：ChatGPT Plus checkout 页面脚本，负责读取 `/api/auth/session` 创建 Plus checkout、选择 PayPal、填写账单姓名、触发 Google 地址推荐、校验结构化地址字段并点击订阅。
+- `flows/openai/content/paypal-flow.js`：PayPal 页面脚本，负责识别登录表单、填写 PayPal 账号密码、在账号页固定执行 `focus -> clear -> fill -> blur` 重新触发邮箱输入事件、处理页面内可见通行密钥提示，并点击 PayPal 授权页的“同意并继续”按钮。
+- `flows/openai/content/phone-country-utils.js`：手机号国家/区号共享工具层，负责手机号纯数字归一化、国家文案/别名归一化、`+(44)` / `(+44)` / `+44` 区号提取、按号码最长区号匹配国家选项，并由注册页与后续手机号验证页共同复用。
+- `flows/openai/content/phone-auth.js`：认证页手机号验证脚本，负责识别 `add-phone / phone-verification` 页面、选择国家、填写手机号、提交短信验证码、触发重发短信，以及把“回到 add-phone / 进入 OAuth 同意页”的结果反馈给后台。
+- `flows/openai/content/plus-checkout.js`：ChatGPT Plus checkout 页面脚本，负责读取 `/api/auth/session` 创建 Plus checkout、选择 PayPal、填写账单姓名、触发 Google 地址推荐、校验结构化地址字段并点击订阅。
 - `content/qq-mail.js`：QQ 邮箱轮询脚本，负责网页邮箱验证码读取。
-- `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` 的管理接口直连路径。
+- `flows/openai/content/openai-auth.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 同意页。
+- `flows/openai/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 仍走 OAuth 尾链时的 `platform-verify` 节点。
-- `content/whatsapp-flow.js`：WhatsApp Web 读取脚本，负责在 GoPay 场景下从聊天消息中提取 OTP；它只参与轮询读取，不接入操作间延迟门控。
+- `flows/openai/content/vps-panel.js`：CPA 面板内容脚本，负责获取 OAuth 地址、提交回调 URL，并基于精确成功徽标与错误态做平台验证判定；当前支持普通步骤 10，以及 Plus 仍走 OAuth 尾链时的 `platform-verify` 节点。
+- `flows/openai/content/whatsapp-flow.js`：WhatsApp Web 读取脚本，负责在 GoPay 场景下从聊天消息中提取 OTP；它只参与轮询读取，不接入操作间延迟门控。
 
 ## `data/`
 
@@ -177,11 +177,11 @@
 
 ## `shared/`
 
-- `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` 配置。
+- `core/flow-kernel/flow-capabilities.js`：flow 能力矩阵归一化模块，负责根据 `activeFlowId` 与来源解析 sidepanel 的显隐能力、来源作用域、贡献模式边界、步骤范围 UI 作用域，以及 Plus 模式下 `账号接入策略` 的可选项、可编辑性与最终生效值。
+- `core/flow-kernel/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 判定。
+- `core/flow-kernel/settings-schema.js`：统一设置 schema 与归一化层，负责把持久配置收敛到 `settingsState.services.*` 与 `settingsState.flows.*` 结构，并维护 `activeFlowId`、OpenAI 的 integration target、Kiro 的 `flows.kiro.targetId / targets` 与 `stepExecutionRangeByFlow`。
+- `core/flow-kernel/source-registry.js`：运行时来源注册表，负责合并 flow runtime source 与共享 mail source，统一 source family、driver、URL 归属和 cleanup owner 判定。
 
 ## `sidepanel/`
 
@@ -387,7 +387,7 @@
 - `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/openai-auth-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 输出与侧边栏脚本加载顺序。
@@ -417,3 +417,5 @@
 - `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 处理。
+
+