feat: rebuild kiro flow as independent desktop auth pipeline

项目完整链路说明.md

@@ -13,7 +13,7 @@
 这是一个 Chrome 扩展，用于承载多套注册与认证自动化 flow。当前已注册两条主 flow：
 
 - `openai`：OpenAI / ChatGPT OAuth 注册、登录、平台绑定与 Plus 扩展链路
-- `kiro`：Builder ID device auth + `kiro.rs` 凭据上传链路
+- `kiro`：AWS Builder ID 注册页 + 桌面授权 + `kiro.rs` 凭据上传链路
 
 它的核心价值不是“打开一个页面点几个按钮”，而是把下面这些环节串成一条完整可恢复的自动化链路：
 
@@ -43,7 +43,7 @@
 - 向后台发送命令
 - 接收后台广播并更新 UI
 - 动态渲染步骤列表
-- 维护 `activeFlowId + sourceId` 的双层选择；`openai` flow 继续把 `panelMode` 作为 legacy 来源映射，`kiro` flow 则改用 `kiroSourceId`
+- 维护 `activeFlowId + targetId` 的双层选择；`openai` flow 继续把 `panelMode` 归一为 legacy integration target，`kiro` flow 则使用独立的 `flows.kiro.targetId`
 - 按当前 flow capability 决定显隐分组；Kiro flow 只显示来源下拉、`kiro.rs URL / API Key`、共享邮箱服务、共享 IP 代理与 Kiro 运行状态，不显示 OpenAI 接码 / Plus / 平台绑定配置
 - 管理顶部“贡献”按钮与贡献模式主面板；贡献模式本身是 sidepanel 的运行态 UI 模式，不是新的 `panelMode` 来源
 - 在贡献模式下复用同一套主自动流程启动，并在面板内展示贡献链路的 `OAUTH / 回调 / 总状态` 三块实时状态
@@ -132,7 +132,7 @@
 
 ### 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。
+[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` 等稳定节点元数据。
 
 这意味着：
@@ -170,7 +170,7 @@
   - `contributionStatusMessage`
   - `contributionLastPollAt`
 - OAuth 链接
-- Kiro 运行态：`kiroDeviceCode / kiroLoginUrl / kiroAuthStatus / kiroRefreshToken / kiroUploadStatus / kiroAuthorizedEmail / kiroCredentialId`
+- Kiro 运行态：使用 `kiroRuntime.session / register / desktopAuth / upload` 命名空间，保存注册页授权码/地址、桌面授权 PKCE 凭据、上传状态和当前 Kiro 会话进度
 - 当前轮冻结后的注册方式 `resolvedSignupMethod`
 - 当前统一账号标识 `accountIdentifierType / accountIdentifier`
 - 当前邮箱 / 密码
@@ -207,7 +207,7 @@
 
 保存持久配置与账号运行历史：
 
-- 当前 flow 与来源配置：`activeFlowId`、OpenAI 的 `panelMode`、Kiro 的 `kiroSourceId`
+- 当前 flow 与目标配置：`activeFlowId`、OpenAI 的 `panelMode`（归一到 integration target）、Kiro 的 `flows.kiro.targetId`
 - flow-aware 配置树：`flows.openai.*`、`flows.kiro.*`
 - CPA / SUB2API 配置
 - Codex2API 配置
@@ -227,7 +227,7 @@
 - 接码开关、接码平台 `phoneSmsProvider`，以及 HeroSMS / 5sim 各自的 API Key、国家/地区、价格上限和平台扩展设置
 - iCloud 相关偏好
 - LuckMail API 配置
-- Kiro 来源配置：`kiroRsUrl / kiroRsKey / kiroRsPriority / kiroRsEndpoint / kiroRsAuthRegion / kiroRsApiRegion`
+- Kiro 目标配置：`flows.kiro.targetId` 与 `flows.kiro.targets["kiro-rs"] = { baseUrl, apiKey }`
 - 自动运行默认配置
 - OAuth 授权后链总超时开关 `oauthFlowTimeoutEnabled`：默认开启；关闭后会立即清空已存在的 OAuth 总预算 deadline，仅保留各步骤本地等待超时
 - flow 级执行范围配置 `stepExecutionRangeByFlow`：按 flowId 保存，例如 `openai: { enabled: true, fromStep: 3, toStep: 6 }`；侧栏中的 `codex` 会归一到内部默认 flowId `openai`。这是通用配置结构，但当前只给 codex/openai flow 暴露 UI。
@@ -237,7 +237,7 @@
 注意：
 
 - `contributionMode` 不属于持久配置，也不参与导入/导出；它只存在于运行态
-- `panelMode` 现在只代表 `openai` flow 下的 `cpa | sub2api | codex2api` 三个 legacy 来源；`kiro` flow 使用独立的 `kiroSourceId`
+- `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 没有运行，则静默跳过，不再要求用户先手动打开一个“本地同步”开关。
 这条配置链路独立于 `mailProvider` 和 Hotmail 的接码模式。
@@ -620,39 +620,55 @@ Plus 模式可见步骤：
 
 ## 6.2 Kiro Flow 链路
 
-Kiro flow 的目标不是复用 OpenAI 注册链，而是单独完成“拿 Builder ID refresh token -> 上传到 `kiro.rs`”这条链路。
+Kiro flow 的目标不是复用 OpenAI 注册链，而是独立完成“注册 Builder ID -> 获取桌面端 refresh token -> 上传到 `kiro.rs`”这条链路。
 
-当前节点只有 3 个：
+当前 Kiro workflow 固定为 9 个节点：
 
-1. `kiro-start-device-login`
-2. `kiro-await-device-login`
-3. `kiro-upload-credential`
+1. `kiro-open-register-page`
+2. `kiro-submit-email`
+3. `kiro-submit-name`
+4. `kiro-submit-verification-code`
+5. `kiro-submit-password`
+6. `kiro-complete-register-consent`
+7. `kiro-start-desktop-authorize`
+8. `kiro-complete-desktop-authorize`
+9. `kiro-upload-credential`
 
 链路如下：
 
-1. sidepanel 把当前 flow 切到 `kiro`，来源固定为 `kiro-rs`
+1. sidepanel 把当前 flow 切到 `kiro`，target 固定为 `kiro-rs`
 2. 用户填写 `kiro.rs URL / API Key`
-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：
+3. 步骤 1~6 在 AWS Builder ID 注册页完成：
+   - 清理 AWS Builder ID 相关 cookies
+   - 打开注册页并等待邮箱输入框
+   - 通过共享邮箱服务生成注册邮箱并提交
+   - 填写姓名、拉取验证码、设置账户密码
+   - 点击“确认并继续 / 允许访问”，完成 Builder ID 注册页授权
+   - 保存注册页授权码、授权地址、注册邮箱和当前页面状态到 `kiroRuntime.register`
+4. 步骤 7 在后台注册桌面 OIDC client，并生成 PKCE 参数：
+   - 生成 `state / codeVerifier / codeChallenge`
+   - 生成 localhost callback `redirectUri`
+   - 构建桌面授权地址并打开授权标签页
+5. 步骤 8 在桌面授权页完成浏览器侧授权：
+   - 处理可能出现的 relogin、OTP、consent
+   - 监听 `http://127.0.0.1:<port>/oauth/callback?...`
+   - 校验 callback `state`
+   - 用 `authorization_code + PKCE` 兑换 `accessToken / refreshToken`
+   - 保存 `clientId / clientSecret / refreshToken / accessToken` 到 `kiroRuntime.desktopAuth`
+6. 步骤 9 调用 `kiro.rs` Admin API：
    - 先探活 `/api/admin/credentials`
-   - 再用 `x-api-key` 上传 Builder ID 凭据
-   - payload 会带上 `refreshToken / clientId / clientSecret / region`
+   - 再用 `x-api-key` 上传桌面端 Builder ID 凭据
+   - payload 固定包含 `refreshToken / clientId / clientSecret / region / authRegion / apiRegion / machineId / email`
    - 如果当前启用了共享 IP 代理，也会把 `proxyUrl / proxyUsername / proxyPassword` 一并上传
+   - 上传结果保存到 `kiroRuntime.upload`
 
 这条链路的关键边界是：
 
-- Kiro 只复用共享邮箱服务和共享 IP 代理服务，不复用 OpenAI 接码 / Plus / 平台绑定 / 贡献模式链路
-- Kiro 自动运行不再走 OpenAI 专用步骤文案和重开逻辑，而是走通用 linear node runner
-- Kiro 节点完成回写直接按 `flowId=kiro` 写运行态，不会再误入 OpenAI 的旧 `step` 分支
-- 每次页面加载完成后固定等待 1 秒，再继续下一次输入、点击或状态判断。
-- 第一版不实时抓取外部地址网站；地址自动化只依赖本地 seed query 和 checkout 页面内置 Google 地址推荐。
+- Kiro 只复用共享账户密码、共享邮箱服务和共享 IP 代理服务，不复用 OpenAI 接码 / Plus / 平台绑定 / 贡献模式链路
+- Kiro 自动运行走通用 linear node runner，但执行器、运行态、页面驱动和上传器全部独立在 `background/kiro/*` 与 `content/kiro/*`
+- Kiro 运行态统一落在 `kiroRuntime` 命名空间，不再散落为多个平铺字段
+- `kiro.rs` 上传不再发送 `profileArn`，machineId 固定按 `sha256("KotlinNativeAPI/" + refreshToken)` 生成
+- Kiro 注册页和桌面授权页不再静态注入 content script，而是由后台按 source 动态注入，避免同域 AWS 页面被错误归到旧 source
 
 ## 7. 邮箱与 provider 链路