diff --git a/background/kiro/publisher-kiro-rs.js b/background/kiro/publisher-kiro-rs.js
index dc02afc..a99d739 100644
--- a/background/kiro/publisher-kiro-rs.js
+++ b/background/kiro/publisher-kiro-rs.js
@@ -4,6 +4,7 @@
   const kiroStateApi = root?.MultiPageBackgroundKiroState || null;
   const DEFAULT_REGION = kiroStateApi?.DEFAULT_REGION || 'us-east-1';
   const DEFAULT_TARGET_ID = kiroStateApi?.DEFAULT_TARGET_ID || 'kiro-rs';
+  const BUILDER_ID_PROFILE_ARN = 'arn:aws:codewhisperer:us-east-1:638616132270:profile/AAAACCCCXXXX';
 
   function isPlainObject(value) {
     return Boolean(value) && typeof value === 'object' && !Array.isArray(value);
@@ -207,6 +208,7 @@
       region,
       email,
       refreshToken,
+      profileArn: BUILDER_ID_PROFILE_ARN,
       clientId,
       clientSecret,
       authMethod: 'idc',
@@ -364,6 +366,7 @@
 
         const uploadResult = await uploadBuilderIdCredential(baseUrl, apiKey, {
           refreshToken: uploadInput.refreshToken,
+          profileArn: uploadInput.profileArn,
           authMethod: uploadInput.authMethod,
           clientId: uploadInput.clientId,
           clientSecret: uploadInput.clientSecret,
diff --git a/md/kiro-flow-独立重构开发方案.md b/md/kiro-flow-独立重构开发方案.md
index ff142b3..2527c1e 100644
--- a/md/kiro-flow-独立重构开发方案.md
+++ b/md/kiro-flow-独立重构开发方案.md
@@ -12,7 +12,7 @@
 4. 等待回到 Kiro Web 登录完成页，建立 Kiro Web 登录态
 5. 基于已有 Kiro Web / Builder ID 浏览器会话打开桌面端授权页
 6. 监听 localhost callback，用授权码与 PKCE 换取桌面端 Builder ID 凭据
-7. 将 `refreshToken / clientId / clientSecret / machineId / email` 等字段上传到 `kiro.rs`
+7. 将 `refreshToken / profileArn / clientId / clientSecret / machineId / email` 等字段上传到 `kiro.rs`
 
 这条链路的核心判断是：能被 `kiro.rs` 稳定使用的不是注册页里某个临时结果，而是 Kiro 桌面端授权链路产生的 Builder ID 凭据。
 
@@ -23,7 +23,7 @@
 - **两套 flow 分开**：Kiro flow 独立使用 `background/kiro/*`、`content/kiro/*`、`kiroRuntime` 和自己的 9 个节点，不复用 OpenAI 的页面、接码、Plus、平台绑定逻辑。
 - **只抽公共能力**：Kiro 只复用邮箱服务、账户密码生成、IP 代理和 `kiro.rs` 目标配置；这些能力本身是跨 flow 基础设施，不带 OpenAI 业务语义。
 - **来源与目标清晰**：Kiro 的目标固定为 `kiro-rs`；运行页面来源按 runtime source 识别，注册子链路覆盖 Kiro Web 与 Builder ID 注册页，桌面授权子链路只覆盖 Builder ID authorize 页。
-- **上传到 `kiro.rs`**：上传器只按 `kiro.rs` 新增凭据接口构建 payload，不上传 `profileArn`，不引入本地账号管理项目里的私有字段。
+- **上传到 `kiro.rs`**：上传器只按 `kiro.rs` 新增凭据接口构建 payload，并固定上传 BuilderId 的 Kiro runtime `profileArn`；不引入本地账号管理项目里的私有字段。
 - **不考虑旧兼容**：设计中不保留旧字段别名、不保留旧入口回退、不保留“失败后换旧链路”的分支。
 
 ### 2.2 完整性分析
@@ -33,7 +33,7 @@
 - UI 配置：Kiro flow、`kiro.rs URL`、`API Key`、共享邮箱、共享密码、共享代理。
 - 注册页面：官方 Kiro 登录页、Builder ID 注册页、授权确认页、Kiro Web 登录完成页。
 - 桌面授权：OIDC client 注册、PKCE、authorize URL、localhost callback、token exchange。
-- 上传：`kiro.rs` baseUrl 归一化、API Key 鉴权、payload 构建、machineId 计算、上传状态回写。
+- 上传：`kiro.rs` baseUrl 归一化、API Key 鉴权、payload 构建、BuilderId profileArn 固定映射、machineId 计算、上传状态回写。
 - 自动运行：Kiro 9 节点 linear workflow，执行范围、状态、日志、失败停止与轮次汇总走通用 runner，但节点实现完全属于 Kiro。
 - 测试：覆盖状态模型、source 归属、注册页状态机、桌面授权 gate、上传器 payload、sidepanel flow 选择。
 
@@ -128,6 +128,7 @@ kiroRuntime: {
 ```js
 {
   refreshToken,
+  profileArn,
   clientId,
   clientSecret,
   region,
@@ -146,8 +147,8 @@ kiroRuntime: {
 
 - `machineId = sha256("KotlinNativeAPI/" + refreshToken)`
 - `region / authRegion / apiRegion` 使用 Kiro 默认固定值
+- `profileArn` 使用 BuilderId 固定值 `arn:aws:codewhisperer:us-east-1:638616132270:profile/AAAACCCCXXXX`
 - `proxy*` 仅在当前共享代理存在且可解析时上传
-- 不上传 `profileArn`
 
 ## 4. 设计自检
 
diff --git a/tests/background-kiro-publisher-kiro-rs-module.test.js b/tests/background-kiro-publisher-kiro-rs-module.test.js
index 6b085bc..45f393b 100644
--- a/tests/background-kiro-publisher-kiro-rs-module.test.js
+++ b/tests/background-kiro-publisher-kiro-rs-module.test.js
@@ -17,7 +17,7 @@ test('kiro publisher exposes a factory and upload payload helpers', () => {
   assert.equal(typeof api?.buildMachineId, 'function');
 });
 
-test('kiro publisher builds kiro.rs payload from desktop auth runtime without profileArn', async () => {
+test('kiro publisher builds kiro.rs payload from desktop auth runtime with BuilderId profileArn', async () => {
   const api = loadPublisherApi();
   const payload = api.buildKiroRsPayload({
     kiroTargetId: 'kiro-rs',
@@ -51,6 +51,7 @@ test('kiro publisher builds kiro.rs payload from desktop auth runtime without pr
     region: 'us-east-1',
     email: 'aws-user@example.com',
     refreshToken: 'refresh-token-001',
+    profileArn: 'arn:aws:codewhisperer:us-east-1:638616132270:profile/AAAACCCCXXXX',
     clientId: 'client-001',
     clientSecret: 'secret-001',
     authMethod: 'idc',
@@ -62,7 +63,6 @@ test('kiro publisher builds kiro.rs payload from desktop auth runtime without pr
   });
   assert.equal(machineId.length, 64);
   assert.match(machineId, /^[0-9a-f]{64}$/);
-  assert.equal(Object.prototype.hasOwnProperty.call(payload, 'profileArn'), false);
 });
 
 test('kiro publisher reads latest kiro.rs key from background state instead of stale node snapshot', async () => {
@@ -113,6 +113,7 @@ test('kiro publisher reads latest kiro.rs key from background state instead of s
         method: options.method || 'GET',
         apiKey: options.headers?.['x-api-key'],
         authorization: options.headers?.Authorization,
+        body: options.body ? JSON.parse(options.body) : null,
       });
       if ((options.method || 'GET') === 'GET') {
         return {
@@ -162,6 +163,10 @@ test('kiro publisher reads latest kiro.rs key from background state instead of s
   assert.equal(requests[0].authorization, 'Bearer live-key');
   assert.equal(requests[1].apiKey, 'live-key');
   assert.equal(requests[1].authorization, 'Bearer live-key');
+  assert.equal(
+    requests[1].body.profileArn,
+    'arn:aws:codewhisperer:us-east-1:638616132270:profile/AAAACCCCXXXX'
+  );
   assert.equal(completed.length, 1);
   assert.equal(completed[0].nodeId, 'kiro-upload-credential');
 });
diff --git a/项目完整链路说明.md b/项目完整链路说明.md
index d1d8360..4b3ce3a 100644
--- a/项目完整链路说明.md
+++ b/项目完整链路说明.md
@@ -661,7 +661,7 @@ Kiro flow 的目标不是复用 OpenAI 注册链，而是独立完成“Kiro 官
 6. 步骤 9 调用 `kiro.rs` Admin API：
    - 先探活 `/api/admin/credentials`
    - 再用 `x-api-key` 上传桌面端 Builder ID 凭据
-   - payload 固定包含 `refreshToken / clientId / clientSecret / region / authRegion / apiRegion / machineId / email`
+   - payload 固定包含 `refreshToken / profileArn / clientId / clientSecret / region / authRegion / apiRegion / machineId / email`
    - 如果当前启用了共享 IP 代理，也会把 `proxyUrl / proxyUsername / proxyPassword` 一并上传
    - 上传结果保存到 `kiroRuntime.upload`
 
@@ -670,7 +670,7 @@ Kiro flow 的目标不是复用 OpenAI 注册链，而是独立完成“Kiro 官
 - Kiro 只复用共享账户密码、共享邮箱服务和共享 IP 代理服务，不复用 OpenAI 接码 / Plus / 平台绑定 / 贡献模式链路
 - Kiro 自动运行走通用 linear node runner，但执行器、运行态、页面驱动和上传器全部独立在 `background/kiro/*` 与 `content/kiro/*`
 - Kiro 运行态统一落在 `kiroRuntime` 命名空间，不再散落为多个平铺字段
-- `kiro.rs` 上传不再发送 `profileArn`，machineId 固定按 `sha256("KotlinNativeAPI/" + refreshToken)` 生成
+- `kiro.rs` 上传固定发送 BuilderId profileArn `arn:aws:codewhisperer:us-east-1:638616132270:profile/AAAACCCCXXXX`，machineId 固定按 `sha256("KotlinNativeAPI/" + refreshToken)` 生成
 - Kiro 注册页覆盖 `app.kiro.dev` 与 AWS Builder ID 页面；桌面授权页只绑定 AWS authorize 页面，二者由后台按 source 动态注入，避免同域 AWS 页面被错误归到另一条 Kiro 子链路
 
 ## 7. 邮箱与 provider 链路
diff --git a/项目文件结构说明.md b/项目文件结构说明.md
index f5d2acc..a368f2f 100644
--- a/项目文件结构说明.md
+++ b/项目文件结构说明.md
@@ -56,7 +56,7 @@
 - `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` 地址归一化、连通性探测、machineId 计算、上传 payload 构建与最终凭据上传。
+- `background/kiro/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` 页面区分开，避免自动运行误停机。
@@ -216,7 +216,7 @@
 - `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 兑换和授权态更新。
-- `tests/background-kiro-publisher-kiro-rs-module.test.js`：测试 `kiro.rs` 发布器已接入且导出工厂，并覆盖 machineId 生成、payload 构建、连通性探测与上传成功/失败处理。
+- `tests/background-kiro-publisher-kiro-rs-module.test.js`：测试 `kiro.rs` 发布器已接入且导出工厂，并覆盖 BuilderId profileArn、machineId 生成、payload 构建、连通性探测与上传成功/失败处理。
 - `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 在保留手机号身份场景下的共享持久化传参。