feat: add flow-aware kiro device auth workflow

项目完整链路说明.md

@@ -10,7 +10,10 @@
 
 ## 1. 项目目标
 
-这是一个 Chrome 扩展，用于自动执行一整套 OpenAI / ChatGPT OAuth 注册与登录流程。
+这是一个 Chrome 扩展，用于承载多套注册与认证自动化 flow。当前已注册两条主 flow：
+
+- `openai`：OpenAI / ChatGPT OAuth 注册、登录、平台绑定与 Plus 扩展链路
+- `kiro`：Builder ID device auth + `kiro.rs` 凭据上传链路
 
 它的核心价值不是“打开一个页面点几个按钮”，而是把下面这些环节串成一条完整可恢复的自动化链路：
 
@@ -25,6 +28,8 @@
 - 自动确认 OAuth 同意页
 - 把 localhost 回调提交到 CPA、SUB2API 或 Codex2API
 
+同时，这套扩展现在不再把“来源、步骤、侧边栏显隐、运行态字段”硬编码在单一 OpenAI 链路里，而是统一挂到 `flow registry + source registry + settings schema + step definitions` 这一层。Kiro 这类新 flow 可以复用共享邮箱服务与 IP 代理服务，但不会复用 OpenAI 的接码、Plus、平台绑定和贡献模式逻辑。
+
 ## 2. 核心运行参与者
 
 ### 2.1 Sidepanel
@@ -38,6 +43,8 @@
 - 向后台发送命令
 - 接收后台广播并更新 UI
 - 动态渲染步骤列表
+- 维护 `activeFlowId + sourceId` 的双层选择；`openai` flow 继续把 `panelMode` 作为 legacy 来源映射，`kiro` flow 则改用 `kiroSourceId`
+- 按当前 flow capability 决定显隐分组；Kiro flow 只显示来源下拉、`kiro.rs URL / API Key / region`、共享邮箱服务、共享 IP 代理与 Kiro 运行状态，不显示 OpenAI 接码 / Plus / 平台绑定配置
 - 管理顶部“贡献”按钮与贡献模式主面板；贡献模式本身是 sidepanel 的运行态 UI 模式，不是新的 `panelMode` 来源
 - 在贡献模式下复用同一套主自动流程启动，并在面板内展示贡献链路的 `OAUTH / 回调 / 总状态` 三块实时状态
 - 在顶部“贡献/使用”按钮下方展示一个非强制的内容更新轻提示；提示来源于 `flowpilot.qlhazycoder.top` 的公开公告 / 教程摘要，用户关闭后仅对当前 `promptVersion` 静默，下次内容版本变化后会重新出现
@@ -110,18 +117,32 @@
 - 极少量保留函数
 - Chrome 事件挂接入口
 
-### 3.3 步骤注册
+### 3.3 Flow / Source 注册
 
-[data/step-definitions.js](c:/Users/projectf/Downloads/codex注册扩展/data/step-definitions.js) 提供共享步骤元数据，并会按 `plusPaymentMethod / signupMethod` 解析当前运行态应显示的步骤标题。  
-[background/steps/registry.js](c:/Users/projectf/Downloads/codex注册扩展/background/steps/registry.js) 负责把“步骤元数据”映射到“步骤执行器”。
+[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.*` 配置结构互转。
+
+这意味着：
+
+- flow 是第一层边界，source 是第二层边界
+- “显示什么配置”“允许什么步骤”“哪些运行态字段属于哪个 flow” 都不再由 sidepanel 或 background 临时硬编码
+- 共享服务目前主要是 `email` 与 `proxy`
+
+### 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 则输出固定的 3 节点 workflow。
+[background/steps/registry.js](c:/Users/projectf/Downloads/codex注册扩展/background/steps/registry.js) 负责把“workflow node 元数据”映射到“步骤执行器”，同时保留 `flowId / nodeId / displayOrder / executeKey` 等稳定节点元数据。
 
 这意味着：
 
 - 步骤顺序靠 `order`
 - 步骤文件名靠语义
 - 新增步骤时不需要重命名后续文件
+- 非 OpenAI flow 不需要复用旧的数字 step registry；直接按 node workflow 注册即可
 
-### 3.4 日志步骤号链路
+### 3.5 日志步骤号链路
 
 日志步骤号不再从日志正文里提取，也不再兼容旧的 `步骤 X` / `Step X` 文本解析。
 
@@ -137,6 +158,7 @@
 
 保存运行态：
 
+- 当前 flow 选择：`activeFlowId / flowId`
 - 当前步骤状态
 - 当前 sidepanel UI 模式 `contributionMode`
 - 贡献 OAuth 会话字段：
@@ -148,6 +170,7 @@
   - `contributionStatusMessage`
   - `contributionLastPollAt`
 - OAuth 链接
+- Kiro 运行态：`kiroDeviceCode / kiroLoginUrl / kiroAuthStatus / kiroRefreshToken / kiroUploadStatus / kiroAuthorizedEmail / kiroCredentialId`
 - 当前轮冻结后的注册方式 `resolvedSignupMethod`
 - 当前统一账号标识 `accountIdentifierType / accountIdentifier`
 - 当前邮箱 / 密码
@@ -184,6 +207,8 @@
 
 保存持久配置与账号运行历史：
 
+- 当前 flow 与来源配置：`activeFlowId`、OpenAI 的 `panelMode`、Kiro 的 `kiroSourceId`
+- flow-aware 配置树：`flows.openai.*`、`flows.kiro.*`
 - CPA / SUB2API 配置
 - Codex2API 配置
 - IP 代理持久配置：`ipProxyEnabled`、服务商、模式、API 地址、服务商配置快照、账号列表、固定 Host / Port / Protocol / Username / Password、地区参数、session 与自动切换阈值
@@ -202,6 +227,7 @@
 - 接码开关、接码平台 `phoneSmsProvider`，以及 HeroSMS / 5sim 各自的 API Key、国家/地区、价格上限和平台扩展设置
 - iCloud 相关偏好
 - LuckMail API 配置
+- Kiro 来源配置：`kiroRsUrl / kiroRsKey / kiroRegion / kiroRsPriority / kiroRsEndpoint / kiroRsAuthRegion / kiroRsApiRegion`
 - 自动运行默认配置
 - OAuth 授权后链总超时开关 `oauthFlowTimeoutEnabled`：默认开启；关闭后会立即清空已存在的 OAuth 总预算 deadline，仅保留各步骤本地等待超时
 - flow 级执行范围配置 `stepExecutionRangeByFlow`：按 flowId 保存，例如 `openai: { enabled: true, fromStep: 3, toStep: 6 }`；侧栏中的 `codex` 会归一到内部默认 flowId `openai`。这是通用配置结构，但当前只给 codex/openai flow 暴露 UI。
@@ -211,7 +237,7 @@
 注意：
 
 - `contributionMode` 不属于持久配置，也不参与导入/导出；它只存在于运行态
-- `panelMode` 当前表示 `cpa | sub2api | codex2api` 三个来源；贡献模式仍不是新的来源枚举
+- `panelMode` 现在只代表 `openai` flow 下的 `cpa | sub2api | codex2api` 三个 legacy 来源；`kiro` flow 使用独立的 `kiroSourceId`
 
 账号运行历史会默认通过 [scripts/hotmail_helper.py](c:/Users/projectf/Downloads/codex注册扩展/scripts/hotmail_helper.py) 的本地 helper 地址尝试同步写入 `data/account-run-history.json` 快照文件；如果 helper 没有运行，则静默跳过，不再要求用户先手动打开一个“本地同步”开关。
 这条配置链路独立于 `mailProvider` 和 Hotmail 的接码模式。
@@ -591,6 +617,40 @@ Plus 模式可见步骤：
 等待模型：
 
 - Plus Checkout 和 PayPal 专用步骤使用“无限等待但可停止”的后台等待 helper。
+
+## 6.2 Kiro Flow 链路
+
+Kiro flow 的目标不是复用 OpenAI 注册链，而是单独完成“拿 Builder ID refresh token -> 上传到 `kiro.rs`”这条链路。
+
+当前节点只有 3 个：
+
+1. `kiro-start-device-login`
+2. `kiro-await-device-login`
+3. `kiro-upload-credential`
+
+链路如下：
+
+1. sidepanel 把当前 flow 切到 `kiro`，来源固定为 `kiro-rs`
+2. 用户填写 `kiro.rs URL / API Key / region`
+3. 步骤 1 调用 AWS Builder ID OIDC：
+   - 注册 public client
+   - 请求 `device_authorization`
+   - 打开 `verificationUriComplete`
+   - 保存 `kiroDeviceCode / kiroLoginUrl / kiroClientId / kiroClientSecret`
+4. 步骤 2 轮询 token 接口，直到用户完成 device login：
+   - 成功后保存 `kiroRefreshToken`
+   - 状态进入 `ready_to_upload`
+5. 步骤 3 调用 `kiro.rs` Admin API：
+   - 先探活 `/api/admin/credentials`
+   - 再用 `x-api-key` 上传 Builder ID 凭据
+   - payload 会带上 `refreshToken / clientId / clientSecret / region`
+   - 如果当前启用了共享 IP 代理，也会把 `proxyUrl / proxyUsername / proxyPassword` 一并上传
+
+这条链路的关键边界是：
+
+- Kiro 只复用共享邮箱服务和共享 IP 代理服务，不复用 OpenAI 接码 / Plus / 平台绑定 / 贡献模式链路
+- Kiro 自动运行不再走 OpenAI 专用步骤文案和重开逻辑，而是走通用 linear node runner
+- Kiro 节点完成回写直接按 `flowId=kiro` 写运行态，不会再误入 OpenAI 的旧 `step` 分支
 - 每次页面加载完成后固定等待 1 秒，再继续下一次输入、点击或状态判断。
 - 第一版不实时抓取外部地址网站；地址自动化只依赖本地 seed query 和 checkout 页面内置 Google 地址推荐。
 
@@ -944,6 +1004,7 @@ Hide My Email 获取与管理链路：
    - 如果当前生成方式是 `custom-pool`，会先按当前目标轮次把邮箱池中的对应邮箱写回运行态
    - fresh-attempt reset 会保留 `stepExecutionRangeByFlow`，避免重置运行态时丢失用户设置的执行窗口
 5. 执行 `runAutoSequenceFromStep`
+   - 如果当前 `activeFlowId !== openai`，后台会切到通用 linear node runner，按当前 flow 的 workflow node 顺序执行，并复用统一的完成状态与 idle watchdog
    - 如果 `stepExecutionRangeByFlow` 已启用，自动运行只会遍历允许范围内的 workflow node；范围外节点会被跳过，`getFirstUnfinishedNodeId` 与保存进度判断也只统计允许节点
    - 手动执行、手动跳过、completion signal 执行和 `executeNodeAndWait` 都会在后台校验执行范围，范围外节点即使被外部消息或旧状态触发，也会直接报错，不会真正执行
    - 步骤 7 内部仍保留登录态恢复的有限重试，但 `add-phone / 手机号页` 属于立即跳出的不可重试错误
@@ -971,6 +1032,7 @@ 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)
 4. 自动运行链路是否需要纳入
 5. Step 状态传播和侧边栏展示是否需要适配
 6. 测试是否要补