@qfeius/everyline-cli 0.1.9 → 0.1.10-blue.0

package/README.md

@@ -2,11 +2,11 @@
 
 EveryLine 命令行工具，支持合同审查工作流、审查清单和审查规则管理。
 
-公开版本只提供 prod 环境预设。其他部署环境应通过自定义 Profile 配置，不在公开文档和安装包中暴露内部环境地址。
+本分支的两项 Skill 固定使用 blue 环境；下文配置、授权和审查示例均使用 blue Profile。
 
 ## 安装
 
-npm 包名为 `@qfeius/everyline-cli`，终端命令仍为 `everyline-cli`。 本地交付统一使用 `make package`，每次自动递增补丁版本，并同步 CLI 与两项 Skill 后生成安装包。发布到 npm 前使用 `.tgz` 安装；发布配置与操作见 [npm 发布指南](docs/npm-release.md)。
+npm 包名为 `@qfeius/everyline-cli`，终端命令仍为 `everyline-cli`。本分支通过 `@blue` 安装和更新。本地交付统一使用 `make package`，每次自动递增 blue 预发布序号，并同步 CLI 与两项 Skill 后生成安装包。发布到 npm 前使用 `.tgz` 安装；发布配置与操作见 [npm 发布指南](docs/npm-release.md)。
 
 npm 全局安装会同步登记 Codex 和 WorkBuddy 的两项 Skill。切换 Node/npm 安装目录时，安装器会校验旧链接所属的 EveryLine 包并更新链接，保留已有授权状态；迁移中途失败会尝试恢复原链接。用户自建目录或其他来源的同名 Skill 会保留并提示冲突。需要手动备份时，请放在 Skill 扫描目录之外，避免仅添加 `.bak` 后缀后仍被作为同名 Skill 加载。
 
@@ -43,8 +43,8 @@ user 身份不需要 app-id；app 身份必须配置 app-id。建议为不同身
 ### 创建 Profile
 
 ~~~bash
-everyline-cli config add prod-user \
-  --env prod \
+everyline-cli config add blue-user \
+  --env blue \
   --default-identity user
 ~~~
 
@@ -52,7 +52,7 @@ everyline-cli config add prod-user \
 
 ~~~bash
 everyline-cli auth login \
-  --profile prod-user \
+  --profile blue-user \
   --as user \
   --timeout 3m
 ~~~
@@ -61,16 +61,16 @@ CLI 会先读取 OAuth metadata 的 `registration_endpoint` 并动态注册浏
 
 user Token 过期且未刷新成功后，通过新的授权链接手动登录：Codex 重新执行 `auth login --profile <profile> --as user --no-open-browser --timeout 3m`；豆包/WorkBuddy 在原会话中执行 `auth init --profile <profile> --as user --output json`，展示本次返回的完整授权链接，用户完成后执行一次 `auth complete`。以 `auth status` 的 `authenticated=true` 确认恢复，再继续原业务操作。
 
-豆包（含本地电脑）和 WorkBuddy 统一使用 Device Grant；dev/test Profile 已内置独立 Device client。执行下面的命令前先按后文准备并固定对应宿主的会话变量：
+豆包（含本地电脑）和 WorkBuddy 统一使用 Device Grant；blue Profile 已内置独立 Device client。执行下面的命令前先按后文准备并固定对应宿主的会话变量：
 
 ~~~bash
-everyline-cli config add test-user --env test --default-identity user
-everyline-cli auth init --profile test-user --as user --output json
+everyline-cli config add blue-user --env blue --default-identity user
+everyline-cli auth init --profile blue-user --as user --output json
 # 用户打开 verification_uri_complete 并完成授权后：
-everyline-cli auth complete --profile test-user --as user --output json
+everyline-cli auth complete --profile blue-user --as user --output json
 ~~~
 
-`auth init` 不监听 `127.0.0.1`，不动态注册 client，也不复用 Codex 浏览器 client。dev/test 预设使用独立 Device client `zscli_c77221e810ce3977`；prod 或自定义环境使用 Device Grant 时，通过 `--oauth-device-client-id` 配置平台确认的 client。dev/test/prod 均不内置浏览器 client ID；Codex 本地每次显式 user 登录会调用 metadata 声明的 `registration_endpoint`，保存返回值后启动 OAuth Authorization Code + PKCE，且不覆盖 Device client。豆包 AgentKit 的安全凭证存储要求注入 base64 编码的 32 字节 `EVERYLINE_CLI_CREDENTIAL_KEY_V1`，WorkBuddy 使用系统凭证库。
+`auth init` 不监听 `127.0.0.1`，不动态注册 client，也不复用 Codex 浏览器 client。blue 预设使用独立 Device client `zscli_bc60fee4de9913ae`，不内置浏览器 client ID；Codex 本地每次显式 user 登录会调用 metadata 声明的 `registration_endpoint`，保存返回值后启动 OAuth Authorization Code + PKCE，且不覆盖 Device client。豆包 AgentKit 的安全凭证存储要求注入 base64 编码的 32 字节 `EVERYLINE_CLI_CREDENTIAL_KEY_V1`，WorkBuddy 使用系统凭证库。
 
 WorkBuddy 必须在第一次 `auth init` 前固定一个 `CODEBUDDY_SESSION_ID`，并在 `auth init`、用户回复“已授权”后的 `auth complete` 以及后续 `auth status` 中复用同一值。`auth complete` 本地提示没有待完成事务时，先用原值重试 `auth complete`；只有服务端状态明确为 `denied`、`expired` 或 `invalid_grant` 后才开始新的授权事务，避免让用户重复打开授权链接。
 
@@ -80,24 +80,24 @@ WorkBuddy 必须在第一次 `auth init` 前固定一个 `CODEBUDDY_SESSION_ID`
 
 ~~~bash
 everyline-cli auth status \
-  --profile prod-user \
+  --profile blue-user \
   --as user \
   --output json
 ~~~
 
 `auth status` 默认读取当前身份对应的安全缓存。OAuth metadata 声明 refresh grant 时，CLI 会在过期前五分钟尝试刷新；进入该窗口后缺少 refresh token 或刷新失败时提示手动重新授权，不回退使用旧 token；业务请求收到可信 `code=110004` 时只刷新并重放一次。服务端不支持刷新或返回 `invalid_grant` 时清理被拒绝的旧 token；并发写入的新 token 会保留。
 
-prod 预设已包含正式 OAuth metadata、business type、loopback redirect 和 scope；使用 `--env prod` 创建 user Profile 后，每次显式 Codex user 登录都会通过 metadata 声明的注册端点动态获取浏览器 client ID。prod 当前不内置 Device client，豆包/WorkBuddy 使用 prod 时需显式配置 `--oauth-device-client-id`。CLI 不把 AuthURL 直接当作 OAuth authorization endpoint。
+blue 预设已包含 OAuth metadata、business type、loopback redirect 和 scope；使用 `--env blue` 创建 user Profile 后，每次显式 Codex user 登录都会通过 metadata 声明的注册端点动态获取浏览器 client ID。blue 已内置独立 Device client，豆包/WorkBuddy 使用 blue 时直接采用预设。CLI 不把 AuthURL 直接当作 OAuth authorization endpoint。
 
 ## app 应用授权
 
 ### 创建 Profile
 
 ~~~bash
-export EVERYLINE_APP_ID='cli_prod_xxx'
+export EVERYLINE_APP_ID='cli_blue_xxx'
 
-everyline-cli config add prod-app \
-  --env prod \
+everyline-cli config add blue-app \
+  --env blue \
   --default-identity app \
   --app-id "$EVERYLINE_APP_ID"
 ~~~
@@ -111,7 +111,7 @@ export EVERYLINE_APP_SECRET='从 Secret Manager 注入的值'
 
 printf '%s' "$EVERYLINE_APP_SECRET" | \
   everyline-cli auth login \
-    --profile prod-app \
+    --profile blue-app \
     --as app \
     --app-secret-stdin \
     --output json
@@ -127,7 +127,7 @@ app-id 的来源优先级为：--app-id > Profile 专用环境变量 > EVERYLINE
 
 全局安装 npm 包时，`postinstall` 会把两项 Skill 同步登记到 Codex 的 `$HOME/.agents/skills`、WorkBuddy 的 `$HOME/.workbuddy/skills`，并同步已发现或显式指定的豆包本地技能目录。首次安装建立授权门禁：旧 token 保留，但必须完成一次新的 user/app 授权后才能调用审查、清单或规则业务命令。项目局部安装和 `npx` 临时执行不登记用户级 Skill；豆包云端导入路径仍使用 `make skill-assets` 生成的两个独立 ZIP。Skill 不修改或替代 CLI 接口。
 
-首次安装使用 `npm install -g --foreground-scripts --allow-scripts=@qfeius/everyline-cli @qfeius/everyline-cli@latest`，让安装器提示可见。Codex、WorkBuddy 和豆包均需在确认 CLI 与 Skill 就绪后，由 Agent 在回复正文展示统一安装完成文案；豆包静态 ZIP 导入在导入后首次运行时完成这一检查和提示。
+首次安装使用 `npm install -g --foreground-scripts --allow-scripts=@qfeius/everyline-cli @qfeius/everyline-cli@blue`，让安装器提示可见。Codex、WorkBuddy 和豆包均需在确认 CLI 与 Skill 就绪后，由 Agent 在回复正文展示统一安装完成文案；豆包静态 ZIP 导入在导入后首次运行时完成这一检查和提示。
 
 在 Codex、WorkBuddy 或豆包电脑版安装并验证完整交互流程，请参阅 [EveryLine CLI 交互 Skill 安装与验证](docs/everyline-cli-skill-guide.md)；评审全部对话分支，请参阅 [EveryLine CLI Skill 全量交互场景](docs/everyline-cli-skill-interaction-scenarios.md)。
 
@@ -148,12 +148,12 @@ Agent 调用示例：
 
 ~~~bash
 everyline-cli auth status \
-  --profile prod-app \
+  --profile blue-app \
   --as app \
   --output json
 
 everyline-cli review run \
-  --profile prod-app \
+  --profile blue-app \
   --as app \
   --input review-run.json \
   --output json \
@@ -191,7 +191,7 @@ everyline-cli review run \
 
 ~~~bash
 everyline-cli review run \
-  --profile prod-user \
+  --profile blue-user \
   --as user \
   --input review-run.json \
   --dry-run
@@ -201,7 +201,7 @@ everyline-cli review run \
 
 ~~~bash
 everyline-cli review run \
-  --profile prod-user \
+  --profile blue-user \
   --as user \
   --input review-run.json \
   --output json \
@@ -226,7 +226,7 @@ review task result
 
 ~~~bash
 everyline-cli review file upload \
-  --profile prod-user \
+  --profile blue-user \
   --as user \
   --file ./contract.pdf \
   --name 采购合同.pdf \
@@ -236,14 +236,14 @@ everyline-cli review file upload \
 沙箱宿主只提供原始附件字节流时，可保持相同上传契约并改用 stdin：
 
 ~~~bash
-everyline-cli review file upload --profile prod-user --as user --stdin --name 采购合同.pdf --output json < attachment.pdf
+everyline-cli review file upload --profile blue-user --as user --stdin --name 采购合同.pdf --output json < attachment.pdf
 ~~~
 
 使用上传结果中的 businessId、fileId 和 fileHash 发起任务：
 
 ~~~bash
 everyline-cli review task start \
-  --profile prod-user \
+  --profile blue-user \
   --as user \
   --data '{"businessId":"biz-001","fileId":123456,"fileHash":"<upload.fileHash>","config":{"selectedPosition":"xxx公司","selectedAuditRole":"甲方","reviewStrength":"中立","matchContractTypeRulePackage":true}}' \
   --output json
@@ -253,7 +253,7 @@ everyline-cli review task start \
 
 ~~~bash
 everyline-cli review task result \
-  --profile prod-user \
+  --profile blue-user \
   --as user \
   --task-id 123456789 \
   --output json > result.json
@@ -265,14 +265,14 @@ CLI 已移除 --app-type 参数；文件上传也不再接受 --business-id。
 
 ## 自更新
 
-CLI 与两项本地 Skill 支持两种更新来源：用户提供的 `.tgz`，或官方 npm 的最新版。两者都由 npm 安装器完成同步，保留原安装 prefix 和账号配置。
+CLI 与两项本地 Skill 支持两种更新来源：经核验属于 blue 的 `.tgz`，或官方 npm 的 blue 渠道最新版。两者都由 npm 安装器完成同步，保留原安装 prefix 和账号配置。blue 渠道缺失或版本不属于 blue 时保留现有安装，不回退其他环境。
 
 ```bash
 # 使用指定包，无需先发布到 npm；将路径替换为实际文件。
 npm install -g --foreground-scripts --allow-scripts=@qfeius/everyline-cli ./everyline-cli-<版本>.tgz
 
-# 使用已经发布到 npm 的最新版。
-npm install -g --foreground-scripts --allow-scripts=@qfeius/everyline-cli @qfeius/everyline-cli@latest --registry https://registry.npmjs.org
+# 使用已经发布到 npm blue 渠道的最新版。
+npm install -g --foreground-scripts --allow-scripts=@qfeius/everyline-cli @qfeius/everyline-cli@blue --registry https://registry.npmjs.org
 ```
 
 指定 tgz 时不因版本相同或 npm 查询失败跳过安装。更新后核对 CLI 与两项 Skill，重新读取或新建任务加载；豆包云端手动导入的 Skill 仍需在平台重新导入。详见 [更新与卸载](docs/everyline-cli-skill-guide.md#10-更新与卸载)。`everyline-cli update` 本身仍用于下述独立二进制 manifest 更新。
@@ -323,9 +323,9 @@ manifest 示例：
 
 ~~~bash
 everyline-cli config list
-everyline-cli config show prod-user --output yaml
-everyline-cli auth status --profile prod-user --as user --output json
-everyline-cli auth logout --profile prod-user --as user
+everyline-cli config show blue-user --output yaml
+everyline-cli auth status --profile blue-user --as user --output json
+everyline-cli auth logout --profile blue-user --as user
 everyline-cli completion zsh
 ~~~
 
@@ -337,9 +337,11 @@ everyline-cli completion zsh
 
 - 不新增内部环境地址、内部域名或未确认的 OAuth 配置。
 - 不提交 app secret、access token、OAuth code、Keychain 内容或本地配置文件。
-- 使用 fake HTTP、临时 Profile 和测试 token 验证功能，不依赖真实 prod 凭证。
+- 使用 fake HTTP、临时 Profile 和测试 token 验证功能，不依赖真实环境凭证。
 - 运行 go test ./...、go vet ./... 和 make build。
 
- npm 安装版通过 `everyline-cli version --output json` 查询 npm 官方源的 `latest` 版本，无需配置 manifest。发现新版后，在当前业务流程结束时执行返回的 `updateCommand`，由 npm 安装器同步 CLI 和本地 Skills；检查失败时最新版本状态保持未知。独立二进制安装仍使用 HTTPS manifest。
+ npm 安装版通过 `everyline-cli version --output json` 查询 npm 官方源的 `blue` 渠道版本，无需配置 manifest。发现新版后，在当前业务流程结束时执行返回的 `updateCommand`，由 npm 安装器同步 CLI 和本地 Skills；检查失败时最新版本状态保持未知。独立二进制安装仍使用 HTTPS manifest。
 
 两项 Skill 使用 `metadata.version` 标记实际加载版本。`npm pack` / `npm publish` 的 prepack 和 `scripts/build-skill-bundles.sh` 会自动从 `package.json` 同步该版本；发布前仍需以相同版本构建 CLI。每个会话首次使用时展示 Skill、CLI 和 npm 最新安装包版本，发现新版后在当前业务结束时更新；宿主文件已更新而会话仍旧时提示新建任务。
+
+CLI 仅内置 blue 预设，已移除 dev、test、prod；未指定环境或自定义地址的 `config add` 默认使用 blue。两项 Skill 固定使用 blue，选择 `blue-user` / `blue-app` 或其他实际连接到 blue 的 Profile；显式指定其他环境或非 blue Profile 时报告不匹配并停止该请求，已有配置和凭据不会迁移。blue 默认 Device client ID 为 `zscli_bc60fee4de9913ae`；OAuth metadata 默认使用 `https://myaccount-b.qfei.cn/.well-known/oauth-authorization-server/contract-review`，并内置 `contract-review` 业务、`contract-review:full` scope 和本机回调地址。

package/bin/checksums.txt

@@ -1,6 +1,6 @@
-3761bd018f3213e3a14a5a1bda71af232a37af6576014dbe348bcf4392100e0c  bin/darwin-amd64/everyline-cli
-0f2085e98f9cf7899d821c709bff54a89b573e93741368312a38c494b8d678bb  bin/darwin-arm64/everyline-cli
-90ceeb917c350d67db7ae73efcbb5e3a066d2b61040ab5397cd0592f8f9a56a6  bin/linux-amd64/everyline-cli
-0606437014e2a84860ad8f495dc6a4d923741601a09490f485b88285423a532d  bin/linux-arm64/everyline-cli
-f6685ebe999a5f4997b308a1c9b420fcc0d7e8b08ef6c6a847dd583597b87b50  bin/windows-amd64/everyline-cli.exe
-ba9d96b7d59682a2fd0967676a3ed2e45c15a3353071e85b329346d423812189  bin/windows-arm64/everyline-cli.exe
+5d8cd2c8907863a43e77b57a2e8e66eb6c127a06f1efa632e56816619185f731  bin/darwin-amd64/everyline-cli
+2c66576936d5aeb32ecf2554b410fad22d9862278726b9e21bb4d79c2baceef2  bin/darwin-arm64/everyline-cli
+6778e292af31cd4914651cc7630f9c4b3d92a745f897dd87eb01ccbde681c5f4  bin/linux-amd64/everyline-cli
+a2c7459347512e60bdf76e54d28e0b94ed2c4b799034627814e420302c277a6a  bin/linux-arm64/everyline-cli
+9ad5fa4bfaef2456082b0f7096f41298e338fa0470cecd2916ea7de9178f927b  bin/windows-amd64/everyline-cli.exe
+d437e8d3a3b80d61bbc1903c3130a64a472618540ffebf8e98e096db1702e862  bin/windows-arm64/everyline-cli.exe

package/docs/everyline-cli-skill-guide.md

@@ -26,7 +26,7 @@ OpenAI 官方文档将 Skill 定义为包含 `SKILL.md` 及可选 references、s
 
 Codex 本地任务直接使用宿主文件路径和 loopback OAuth。WorkBuddy 使用本机 CLI、系统凭证库和 Device Grant。豆包普通工作任务在本地电脑和远端沙箱中都使用 Device Grant，并固定 `SESSION_ID` 与初始工作目录；远端沙箱使用 Linux CLI，以及宿主提供的原始附件字节流或完整下载 URL，用户 macOS 路径不作为沙箱文件路径。
 
-CLI 和 Skill 应来自同一个发布版本。每次 Skill 发布（包括纯文案调整）都提升 `package.json` 统一版本、发布同版本 npm 包并更新远端 manifest，让 `version.updateRequired` 可以触发强制更新门禁。
+CLI 和 Skill 应来自同一个 blue 发布版本（格式为 `<版本>-blue.<序号>`）。每次发布提升 `package.json` 统一版本，并将同版本 npm 包发布到 `blue` 渠道；`version.updateRequired` 触发业务结束后的延迟更新。安装前确认指定包、版本和环境属于 blue；blue 渠道缺失时保留原安装，不回退其他环境。
 
 ## 2. 全局安装包同步 CLI、Codex、WorkBuddy 和豆包本地 Skills
 
@@ -260,7 +260,7 @@ $everyline-review 使用当前 prod-user Profile 和 user 身份检查 CLI 版
 
 所有 Agent 在发起授权前都先让用户选择身份。同次授权已有用户明确的 `user` 或 `app` 选择时直接复用；尚未明确时，WorkBuddy 使用 `AskUserQuestion` 单选并设置 `multiSelect=false`，Codex 在 `request_user_input` 可用时使用互斥单选，豆包在原生单选组件可用时使用该组件。没有原生组件时统一显示 `1. user（个人账号授权）` 和 `2. app（应用授权）`，等待用户回复 `1/2` 或 `user/app`。收到选择前不匹配或创建 Profile，也不执行身份相关的状态查询或授权命令。Profile 名称、默认身份、唯一候选、历史 token 和 CLI `nextAction` 都不作为用户选择的依据；笼统的“开始授权”或“继续授权”也不等于选择了身份。
 
-身份明确后，用户本轮没有指定 Profile 或环境时，Codex、WorkBuddy 和豆包统一默认 test：user 复用或创建 `test-user`，app 复用 `test-app`，缺少时在取得非敏感 app ID 后创建。当前 dev、blue、prod Profile 不会被默认继承；用户本轮显式指定的 Profile 或环境优先。宿主差异只影响 user 的授权协议：Codex 本地使用 OAuth/PKCE，豆包和 WorkBuddy 使用 Device Grant。
+身份明确后，Codex、WorkBuddy 和豆包统一固定使用 blue：user 复用或创建 `blue-user`，app 复用 `blue-app`，缺少时在取得非敏感 app ID 后创建。显式指定其他环境时，说明当前 Skill 仅支持 blue 并停止该环境的操作；显式 Profile 也必须按实际连接地址核验为 blue。当前 dev、test、prod 或自定义环境的 Profile 不会被使用，也不会把其凭据迁移到 blue。首次使用、继续任务和授权恢复都遵守此规则。宿主差异只影响 user 的授权协议：Codex 本地使用 OAuth/PKCE，豆包和 WorkBuddy 使用 Device Grant。
 
 user 流程取得 CLI 返回的完整授权 URL 后，优先生成宿主原生链接按钮，按钮文字固定为“点击授权”；没有链接按钮时显示 `[点击授权](<FULL_AUTHORIZATION_URL>)`。链接目标逐字保留 CLI 返回值及全部 query 参数，由用户主动点击，Agent 不自动打开浏览器，也不为改变展示方式创建第二笔授权事务。app 流程没有此链接，继续使用下方隐藏输入 app secret 的方式。
 
@@ -268,21 +268,21 @@ user 流程取得 CLI 返回的完整授权 URL 后，优先生成宿主原生
 
 ### user 身份：推荐用于人工交互验证
 
-默认 test Profile 可由 Agent 自动创建；手工等价命令为：
+blue Profile 可由 Agent 自动创建；手工等价命令为：
 
 ```bash
-everyline-cli config add test-user \
-  --env test \
+everyline-cli config add blue-user \
+  --env blue \
   --default-identity user
 
-everyline-cli config use test-user
+everyline-cli config use blue-user
 ```
 
 Codex 本地交互可完成浏览器 OAuth 登录：
 
 ```bash
 everyline-cli auth login \
-  --profile test-user \
+  --profile blue-user \
   --as user \
   --no-open-browser \
   --timeout 3m
@@ -300,7 +300,7 @@ everyline-cli auth login \
 
 ```bash
 everyline-cli auth status \
-  --profile test-user \
+  --profile blue-user \
   --as user \
   --output json
 ```
@@ -310,13 +310,13 @@ everyline-cli auth status \
 豆包（含“本地电脑”模式）和 WorkBuddy 统一使用 Device Grant。豆包在首次 `auth status` 前固定 `SESSION_ID` 和初始工作目录；宿主未提供时只生成一次 UUID，所有命令显式注入相同值，并由执行工具设置相同工作目录。下面的豆包命令应带 `SESSION_ID=<same-session-id>` 前缀；AgentKit 仍使用平台工作区与注入密钥。完成这些准备后执行：
 
 ```bash
-everyline-cli auth init --profile test-user --as user --output json
+everyline-cli auth init --profile blue-user --as user --output json
 ```
 
 把 `verification_uri_complete` 从 `https://` 到最后一个 query 参数逐字保留为链接目标，并展示 `[点击授权](<verification_uri_complete>)`。用户主动点击并完成授权后只检查一次：
 
 ```bash
-everyline-cli auth complete --profile test-user --as user --output json
+everyline-cli auth complete --profile blue-user --as user --output json
 ```
 
 WorkBuddy 在第一次 `auth init` 前固定一个非敏感的 `CODEBUDDY_SESSION_ID`，上面两条命令和随后的 `auth status` 都添加相同的 `CODEBUDDY_SESSION_ID=<same-session-id>` 前缀。若 `auth complete` 提示本地没有待完成事务，先恢复首次命令使用的原值并重试 `auth complete`；此时不要执行 `auth init --restart`。只有 CLI 明确返回 `denied`、`expired` 或 `invalid_grant`，并经用户同意后，才创建新的授权事务。
@@ -327,7 +327,7 @@ user Token 过期且未刷新成功后，保持原 Profile、user 身份和宿
 
 用户完成手动登录后，Device 流程执行一次 `auth complete`，再用 `auth status` 确认 `authenticated=true`，只恢复原业务步骤一次。进入到期前五分钟窗口后，缺少 refresh token 或刷新失败时，按 CLI 提示手动重新授权。
 
-只有 `status=succeeded` 才继续。dev/test/prod 环境预设提供 `contract-review` metadata、回调地址和 `contract-review:full` scope。Codex 每次显式 `auth login --as user` 会读取 metadata 的 `registration_endpoint`，动态注册浏览器 client 并执行 OAuth Authorization Code + PKCE。豆包/WorkBuddy 的 `auth init` 只走 Device Grant：dev/test 使用独立 Device client `zscli_c77221e810ce3977`，不动态注册也不复用浏览器 client；prod 或自定义环境需显式配置平台确认的 Device client。metadata 未声明 `device_authorization_endpoint` 时由认证服务补齐对应业务的 Device Grant；远端沙箱不回退到 `auth login`。豆包 AgentKit 还需注入 base64 编码的 32 字节 `EVERYLINE_CLI_CREDENTIAL_KEY_V1`。
+只有 `status=succeeded` 才继续。blue 环境预设提供 `contract-review` metadata、回调地址和 `contract-review:full` scope。Codex 每次显式 `auth login --as user` 会读取 metadata 的 `registration_endpoint`，动态注册浏览器 client 并执行 OAuth Authorization Code + PKCE。豆包/WorkBuddy 的 `auth init` 只走 Device Grant：blue 使用预设的独立 Device client `zscli_bc60fee4de9913ae`，不动态注册也不复用浏览器 client。metadata 未声明 `device_authorization_endpoint` 时由认证服务补齐对应业务的 Device Grant；远端沙箱不回退到 `auth login`。豆包 AgentKit 还需注入 base64 编码的 32 字节 `EVERYLINE_CLI_CREDENTIAL_KEY_V1`。
 
 ### app 身份：适合无浏览器设备
 
@@ -339,16 +339,16 @@ macOS 或 Linux：
 export EVERYLINE_APP_ID='<APP_ID>'
 export EVERYLINE_APP_SECRET='<APP_SECRET>'
 
-everyline-cli config add test-app \
-  --env test \
+everyline-cli config add blue-app \
+  --env blue \
   --default-identity app \
   --app-id "$EVERYLINE_APP_ID"
 
-everyline-cli config use test-app
+everyline-cli config use blue-app
 
 printf '%s' "$EVERYLINE_APP_SECRET" | \
   everyline-cli auth login \
-    --profile test-app \
+    --profile blue-app \
     --as app \
     --app-secret-stdin \
     --output json
@@ -557,10 +557,10 @@ everyline-cli version --output json
 
 也可以将 tgz 作为工作任务附件提供，然后告诉 Agent：“使用 everyline-review 技能，按附件 tgz 更新 CLI 和两项 Skill，不从 npm 查询最新版。”即使包版本相同，也按指定包安装并同步可管理的 Skill 内容；无需该包先发布到 npm。
 
-**从 npm 更新到最新版**：
+**从 npm blue 渠道更新到最新版**：
 
 ```bash
-npm install -g --foreground-scripts --allow-scripts=@qfeius/everyline-cli @qfeius/everyline-cli@latest --registry https://registry.npmjs.org
+npm install -g --foreground-scripts --allow-scripts=@qfeius/everyline-cli @qfeius/everyline-cli@blue --registry https://registry.npmjs.org
 everyline-cli version --output json
 ```
 

package/docs/everyline-cli-skill-interaction-scenarios.md

@@ -74,7 +74,7 @@ flowchart TD
 | ENTRY-03 | 已支持 | `帮我操作普通智书 contract-cli` | 根据 Skill 边界不接管 | 交由其他能力处理 |
 | READY-01 | 已支持 | 新会话首次调用 | 执行 `command -v`、`version --output json` 和根帮助；解析首次安装授权字段 | 命令和版本可读取 |
 | READY-02 | 已支持 | CLI 已安装 | 使用现有版本，不主动升级 | 继续读取目标命令帮助 |
-| READY-03 | 已支持 | 已要求安装 CLI/Skill，CLI 未安装 | 优先安装用户指定版本或 `.tgz`，否则执行 `npm install -g --foreground-scripts --allow-scripts=@qfeius/everyline-cli @qfeius/everyline-cli@latest` | 安装校验后在回复正文展示统一文案 |
+| READY-03 | 已支持 | 已要求安装 CLI/Skill，CLI 未安装 | 优先安装用户指定版本或 `.tgz`，否则执行 `npm install -g --foreground-scripts --allow-scripts=@qfeius/everyline-cli @qfeius/everyline-cli@blue` | 安装校验后在回复正文展示统一文案 |
 | READY-04 | 受限 | 宿主只完成静态 Skill 导入 | 首次运行时验证 CLI；用户已要求安装时补做 CLI 安装，安装失败报告真实原因 | CLI 和 Skill 就绪后在回复正文展示统一文案 |
 | READY-05 | 受限 | 目标命令或参数在实时帮助中缺失 | 列出缺口，不模拟或猜测接口 | 停止该业务操作 |
 | READY-06 | 受限 | 旧版 `reviewStrength` 只接受 `0/1/2` | 不维护数字映射，不上传合同 | 停止合同审查；只读能力仍可继续 |
@@ -92,10 +92,10 @@ flowchart TD
 
 | ID | 状态 | 用户示例或条件 | Skill 处理 | 结束条件 |
 | --- | --- | --- | --- | --- |
-| PROFILE-01 | 已支持 | 用户明确提供 Profile | 先明确 user/app 选择，再使用 `config show <profile> --output json` 校验、读取并固定该 Profile；Profile 名称和默认身份不代替选择 | 后续命令显式传递 Profile |
-| PROFILE-02 | 已支持 | 用户未提供 Profile 和环境 | 先明确 user/app 选择，Codex、WorkBuddy、豆包统一选择 test 环境；复用身份兼容的 test Profile，没有时创建 `test-user` 或取得 app ID 后创建 `test-app` | 固定 test Profile，不继承 dev/blue/prod 当前 Profile |
-| PROFILE-02A | 已支持 | 用户本轮明确指定 Profile 或环境 | 校验并采用用户选择 | 显式选择覆盖默认 test |
-| PROFILE-02B | 已支持 | 默认名称已被其他环境占用 | 不覆盖同名 Profile，展示冲突并请求显式 Profile | 防止静默改写环境配置 |
+| PROFILE-01 | 已支持 | 用户明确提供 Profile | 先明确 user/app 选择，再使用 `config show <profile> --output json` 校验实际连接地址为 blue、读取并固定该 Profile；Profile 名称和默认身份不代替选择 | 后续命令显式传递 Profile |
+| PROFILE-02 | 已支持 | 用户未提供 Profile 和环境 | 先明确 user/app 选择，Codex、WorkBuddy、豆包统一选择 blue 环境；复用身份兼容的 blue Profile，没有时创建 `blue-user` 或取得 app ID 后创建 `blue-app` | 固定 blue Profile，不继承 dev/test/prod 当前 Profile |
+| PROFILE-02A | 已支持 | 用户本轮明确指定 Profile 或环境 | 只采用实际连接地址属于 blue 的 Profile；指定其他环境或非 blue Profile 时说明不匹配并停止 | 不执行其他环境的授权或业务，也不静默改发到 blue |
+| PROFILE-02B | 已支持 | 默认名称已被其他环境占用 | 不覆盖同名 Profile，展示冲突并请求实际属于 blue 的 Profile | 防止静默改写环境配置 |
 | PROFILE-03 | 受限 | 用户显式指定的 Profile 缺失或与显式环境不一致 | 不猜测或覆盖该 Profile | 用户修正后重新调用 |
 | AUTH-01 | 已支持 | `使用 user 身份审查` | 直接选择 user，不再询问身份 | 查询 user 授权状态 |
 | AUTH-02 | 已支持 | `使用 app 身份查询清单` | 直接选择 app，不再询问身份 | 查询 app 授权状态 |
@@ -106,7 +106,7 @@ flowchart TD
 | AUTH-07 | 受限 | user 取消、失败或授权失效 | 返回 CLI 真实原因 | 停止业务调用 |
 | AUTH-08 | 已支持 | app 需要 secret | 只通过 stdin 或等价安全凭证源提供 | 登录后重新查询状态 |
 | AUTH-09 | 受限 | app 或 user 授权失败 | 不自动切换到另一身份 | 返回真实失败并停止 |
-| AUTH-10 | 受限 | 默认 test Profile 创建失败，或 app 身份缺少 app ID | 返回真实配置错误；app ID 只作为非敏感输入单独取得 | 配置条件补齐后重新调用 |
+| AUTH-10 | 受限 | 默认 blue Profile 创建失败，或 app 身份缺少 app ID | 返回真实配置错误；app ID 只作为非敏感输入单独取得 | 配置条件补齐后重新调用 |
 | AUTH-11 | 已支持 | Profile 与身份已确定 | 每条授权、查询和写入命令都携带相同 `--profile/--as` | 不回退默认上下文 |
 | AUTH-12 | 受限 | app 授权需要重新输入 secret | 只让用户在自己的终端或平台密钥入口通过安全 stdin 输入，不在对话中索取内容 | 用户完成终端操作后回读状态 |
 | AUTH-13 | 受限 | 服务端返回 `http=200 code=10003 msg=invalid param` | 原样报告通用参数错误；CLI 未指出具体字段时不推断 app ID/secret 失效、变更或轮换 | 保持原 Profile 和 app 身份，等待用户重试或主动指定变更 |
@@ -121,13 +121,13 @@ flowchart TD
 | AUTH-22 | 已支持 | WorkBuddy 发起授权且用户未指定身份 | 调用 `AskUserQuestion`，设置 `multiSelect=false`，选项为 user/app | 用户单选后才查询对应身份状态 |
 | AUTH-23 | 已支持 | 豆包发起授权且用户未指定身份 | 优先使用原生单选组件；组件不可用时展示稳定编号 `1. user`、`2. app` | 用户回复有效编号或身份后继续 |
 | AUTH-24 | 已支持 | user 授权入口已生成 | 用户自己点击“点击授权”；Agent 不自动打开浏览器，不在展示切换时重启授权 | 保持唯一授权事务 |
-| AUTH-25 | 已支持 | 仅有一个 `test-user` Profile，默认身份为 user，且存在历史 token | 仍先让用户单选 user/app；不从 Profile 或 token 推断选择 | 用户选择后才匹配 Profile 和查询状态 |
+| AUTH-25 | 已支持 | 仅有一个 `blue-user` Profile，默认身份为 user，且存在历史 token | 仍先让用户单选 user/app；不从 Profile 或 token 推断选择 | 用户选择后才匹配 Profile 和查询状态 |
 | AUTH-26 | 已支持 | 用户只说“开始授权”或“继续授权”，同次授权尚未选择身份 | 将其作为继续授权意图，仍先单选 user/app；已有明确选择时复用 | 身份明确后按对应流程继续 |
 | AUTH-27 | 已支持 | 豆包并发调用 `auth init`，或同一首次安装 `eventId` 重放 `auth init --restart` | CLI 通过 Profile 级锁只创建一笔 Device 事务；重放返回原授权入口及 `reused=true`，Skill 不重复展示 | 用户只打开一个授权页面 |
 | AUTH-28 | 已支持 | 豆包“本地电脑”模式没有宿主会话变量 | 首次 `auth status` 前只生成一次 `SESSION_ID` 并固定初始目录；所有授权和业务命令显式复用，执行 `auth init` / `auth complete` | 与 WorkBuddy 一样展示 `/device` 链接，不进入 loopback OAuth |
 | AUTH-29 | 已支持 | 豆包本地存在同名 Profile 的旧 OAuth token，但当前 Device 会话未授权 | 状态返回 `authenticated=false/source=device`；业务取 token 和刷新引导到 `auth init`，Device 失效操作保留浏览器缓存 | 当前 Device 会话独立完成授权 |
 
-当前 Skill 只自动创建缺失的默认 test Profile；其他环境的 Profile 仍由用户显式管理。Skill 会读取并固定本次 Profile，避免后续独立进程回退到其他环境或身份。
+当前 Skill 固定使用 blue，只自动创建缺失的 blue Profile；显式指定其他环境时停止该环境的操作。Skill 会读取并固定本次 Profile，避免后续独立进程回退到其他环境或身份。
 
 ## 6. 合同来源交互
 
@@ -289,7 +289,7 @@ flowchart TD
 
 | ID | 状态 | 当前范围 |
 | --- | --- | --- |
-| GAP-01 | 未定义 | 默认 test 以外的自动 Profile 创建、更新或切换 |
+| GAP-01 | 不支持 | blue 以外的环境或 Profile，包括用户显式指定和恢复历史任务 |
 | GAP-02 | 未定义 | 自动升级现有 CLI |
 | GAP-03 | 未定义 | 创建或更新规则分组 |
 | GAP-04 | 未定义 | 清单、规则或分组的批量删除交互 |
@@ -306,10 +306,10 @@ flowchart TD
 
 以下最小集合可覆盖主要分支：
 
-1. `$everyline-review 使用 test-user Profile 和 user 身份检查授权状态，先不要上传文件。`
-2. 在消息中附加一份合同并发送：`$everyline-review 使用 test-user Profile 和 user 身份审查这个附件；强度中立。`
-3. `$everyline-review 使用 test-user Profile 和 user 身份审查 /absolute/path/合同.pdf。`
-4. `$everyline-review 使用 test-user Profile 和 user 身份审查 https://example.test/合同.pdf；使用内置规则包；强度中立。`
+1. `$everyline-review 使用 blue-user Profile 和 user 身份检查授权状态，先不要上传文件。`
+2. 在消息中附加一份合同并发送：`$everyline-review 使用 blue-user Profile 和 user 身份审查这个附件；强度中立。`
+3. `$everyline-review 使用 blue-user Profile 和 user 身份审查 /absolute/path/合同.pdf。`
+4. `$everyline-review 使用 blue-user Profile 和 user 身份审查 https://example.test/合同.pdf；使用内置规则包；强度中立。`
 5. `$everyline-review 列出我可用的自定义审查清单和其中的规则。`
 6. `$everyline-review 创建一个采购合同审查清单。`
 7. `$everyline-review 给“采购合同清单”增加“付款条件风险”规则。`

package/docs/npm-release.md

@@ -2,42 +2,44 @@
 
 npm 包名为 `@qfeius/everyline-cli`，终端命令和两项 Skill 名称保持不变。公共源固定为 `https://registry.npmjs.org/`。生成 `.tgz`、推送源码与发布 npm 是三个独立步骤，只有发布成功后才能通过包名安装。
 
+本分支固定使用 blue 环境。安装、检查更新和发布统一使用 `blue` dist-tag；版本格式为 `<版本>-blue.<序号>`，与其他环境的版本分开。blue 渠道尚未发布或返回其他环境版本时，检查结果为未知，保留现有安装；不回退其他渠道。
+
 ## 一次性配置
 
-1. 在 npm 包的 Trusted Publisher 中配置 GitHub 仓库 `qfeius/everyline-cli` 和工作流 `npm-publish.yml`，供 OIDC 发布。确认 npm 账号有 `@qfeius` 下此包的发布权限。首次发布前先检查组织权限和包名归属。
-2. npm 发布使用 OIDC 临时身份，无需为 GitHub Release 配置 `NPM_TOKEN`。
-3. 将 `.github/workflows/release.yml` 推送到 GitHub。工作流使用 GitHub 自动提供的 token 创建 Release，无需另配 GitHub token。
+1. 确认 npm 账号有 `@qfeius` 下此包的发布权限。首次发布前先检查组织权限和包名归属。
+2. npm 使用已配置的 GitHub OIDC trusted publisher，绑定 `qfeius/everyline-cli` 的 `npm-publish.yml`；发布工作流保留 `id-token: write` 权限。
+3. 将两条发布工作流推送到 GitHub。`release.yml` 使用 GitHub 自动提供的 token 创建 Release 并上传制品；`npm-publish.yml` 单独发布 npm，避免两个任务争抢同一版本。
 
-Token 权限说明：[npm CI/CD 文档](https://docs.npmjs.com/using-private-packages-in-a-ci-cd-workflow/)。
+发布授权说明：[npm trusted publishing 文档](https://docs.npmjs.com/trusted-publishers/)。
 
 ## 发布步骤
 
-1. 在准备发布的分支更新 `package.json.version`。正式版如 `0.0.8`，预发布版如 `0.0.8-beta.1`。已发布版本不能覆盖。
+1. 在 blue 分支更新 `package.json.version`，例如 `0.1.10-blue.0`；保留 `publishConfig.tag=blue`。已发布版本不能覆盖。
 2. 执行 `make release-check`。构建脚本会同步两项 Skill 的版本；提交版本及相关改动。
 3. 创建并推送与包版本完全一致的标签，例如：
 
 ```bash
-git tag v0.0.8
+git tag v0.1.10-blue.0
 git push github HEAD
-git push github v0.0.8
+git push github v0.1.10-blue.0
 ```
 
 上例中的版本须替换为本次版本。`github` 为本仓库指向 GitHub 的远端名称。
 
-标签触发两条独立工作流：`release.yml` 校验版本、运行测试和安装校验，发布 GitHub 原生二进制制品、npm 安装包和两项 Skill ZIP；`npm-publish.yml` 通过 OIDC 发布 npm。GitHub 制品发布不依赖 NPM_TOKEN。正式版发布到 `latest`；预发布版使用版本后缀首段作为 dist-tag，例如 `test.1` 使用 `test`。
+同一标签触发两条工作流；两者都校验已提交版本、blue 渠道、Windows 打包和完整发布检查。`release.yml` 发布 GitHub 预发布制品、npm 安装包和两项 Skill ZIP；`npm-publish.yml` 通过 OIDC 发布 npm 包并回查 blue 渠道。npm 发布始终使用 `--tag blue`，不覆盖 `latest` 或 `beta`。
 
 GitLab 流水线继续负责测试、构建和保存 `.tgz`，不重复发布 npm。
 
 ## 安装与验证
 
-发布完成后安装正式版：
+发布完成后安装 blue 渠道最新版：
 
 ```bash
-npm install -g --foreground-scripts --allow-scripts=@qfeius/everyline-cli @qfeius/everyline-cli@latest --registry https://registry.npmjs.org
+npm install -g --foreground-scripts --allow-scripts=@qfeius/everyline-cli @qfeius/everyline-cli@blue --registry https://registry.npmjs.org
 everyline-cli version --output json
 ```
 
-预发布版将 `@latest` 替换为对应 dist-tag，例如 `@test`。安装包内含六个平台的二进制，不需要再次从 GitHub 下载。
+安装包内含六个平台的二进制，不需要再次从 GitHub 下载。检查更新只查询 blue 渠道，并拒绝不含 `-blue.<序号>` 的版本。
 
 尚未发布到 npm 时，使用构建后的本地包：
 
@@ -46,14 +48,14 @@ make package
 npm install -g --foreground-scripts --allow-scripts=@qfeius/everyline-cli "./dist/everyline-cli-<版本>.tgz"
 ```
 
-`make package` 每次先将补丁版本递增一位（例如 `0.0.7 → 0.0.8`），再同步两项 Skill、重新构建六个平台的二进制并生成 `.tgz`；不会提交代码、创建 Git 标签或发布到 npm。若当前是预发布版本，按 npm 的 patch 规则转为对应正式版本。文件名中的版本以实际产物为准。日常交付使用 `make package`；`npm pack` 仅用于 CI 已固定版本的发布和内部校验，不自动升版。两个 `*-skill.zip` 是 Skill 导入包，不替代 CLI 安装包。
+`make package` 每次递增 blue 预发布序号（例如 `0.1.10-blue.0 → 0.1.10-blue.1`），再同步两项 Skill、重新构建六个平台的二进制并生成 `.tgz`；不会提交代码、创建 Git 标签或发布到 npm。文件名中的版本以实际产物为准。日常交付使用 `make package`；`npm pack` 仅用于 CI 已固定版本的发布和内部校验，不自动升版。两个 `*-skill.zip` 是 Skill 导入包，不替代 CLI 安装包。
 
 ## 从旧包名迁移
 
 仅当 `npm ls -g --depth=0` 确认已安装旧 npm 包 `everyline-cli` 时使用以下步骤。新用户直接安装 scoped 包，无需 `--force`。所有命令使用同一个 npm 全局目录；旧包使用自定义 prefix 时，每条命令均追加相同的 `--prefix`。
 
 ```bash
-npm install -g --force --foreground-scripts --allow-scripts=@qfeius/everyline-cli @qfeius/everyline-cli@latest --registry https://registry.npmjs.org
+npm install -g --force --foreground-scripts --allow-scripts=@qfeius/everyline-cli @qfeius/everyline-cli@blue --registry https://registry.npmjs.org
 everyline-cli --help
 npm uninstall -g everyline-cli
 npm rebuild -g --foreground-scripts --allow-scripts=@qfeius/everyline-cli @qfeius/everyline-cli
@@ -64,7 +66,7 @@ everyline-cli version --output json
 
 ## 发布失败
 
-- npm OIDC 身份校验失败：核对 npm Trusted Publisher 配置的仓库与 `npm-publish.yml` 工作流名称。
+- OIDC 授权失败：核对 npm trusted publisher 绑定的仓库、工作流文件和 GitHub `id-token: write` 权限。
 - npm 403：核对 scope、包写权限、token 有效期及非交互发布权限。
 - 版本已存在：不要覆盖；核对已发布结果，需要变更时提升版本并创建新标签。
 - GitHub Release 已生成但 npm 发布失败：npm 包尚未发布成功；解决错误后可安装 Release 中的 `.tgz`，再处理 npm 发布。不要仅凭 Release 存在宣称 npm 已可安装。

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@qfeius/everyline-cli",
-  "version": "0.1.9",
+  "version": "0.1.10-blue.0",
   "description": "EveryLine CLI 工具的 npm/npx 薄包装",
   "license": "UNLICENSED",
   "repository": {
@@ -33,6 +33,7 @@
   "scripts": {
     "postinstall": "node scripts/install.js",
     "prepack": "node scripts/verify-package-version.js && node scripts/sync-skill-versions.js",
+    "prepublishOnly": "node scripts/verify-package-version.js --publish",
     "test": "node --test tests/release/*.test.js"
   },
   "engines": {
@@ -40,6 +41,7 @@
   },
   "publishConfig": {
     "registry": "https://registry.npmjs.org/",
-    "access": "public"
+    "access": "public",
+    "tag": "blue"
   }
 }

package/scripts/install.js

@@ -20,7 +20,8 @@ const { buildDoubaoSkillPlans, inspectDoubaoSkillRegistration, installDoubaoSkil
 
 // skillNames 是同一份 npm 包向 Codex、WorkBuddy 和豆包发布的两项职责分离 Skill。
 const skillNames = ["everyline-review", "everyline-review-config"];
-const deprecatedSkillNames = ["everyline-shared"];
+// 两个历史公共入口都由 everyline-review 接管，升级时按原有来源校验迁出。
+const deprecatedSkillNames = ["everyline-shared", "everyline-cli"];
 const installStateSchema = "everyline.install-state.v1";
 // 安装提示与 Agent 事件共用文案；先说明可协助授权，用户要求登录后再选择 user/app。
 const firstInstallMessage = "EveryLine CLI 已安装完成。目前支持合同审查，以及审查清单、规则和规则分组配置。使用前需要先完成账号授权，我现在可以为你打开授权页面或生成授权链接。";

package/scripts/package-version.js

@@ -23,4 +23,15 @@ if (require.main === module) {
   process.stdout.write(normalizePackageVersion(process.argv[2]));
 }
 
-module.exports = { normalizePackageVersion };
+/**
+ * validateBlueRelease 校验 blue 发布的版本后缀与 npm 渠道，避免覆盖其他环境。
+ * 入参：version string 为标签中的版本；channel string 为包声明的发布渠道。
+ * 返回值：void；非 blue 版本、构建元数据或其他渠道时抛出错误。
+ */
+function validateBlueRelease(version, channel) {
+  if (channel !== "blue" || normalizePackageVersion(version) !== version || !/^\d+\.\d+\.\d+-blue\.\d+$/.test(version)) {
+    throw new Error("blue 发布必须使用 <版本>-blue.<序号> 和 blue 渠道");
+  }
+}
+
+module.exports = { normalizePackageVersion, validateBlueRelease };

package/scripts/verify-package-version.js

@@ -2,10 +2,12 @@
 
 const { readFileSync } = require("node:fs");
 const { join } = require("node:path");
-const { normalizePackageVersion } = require("./package-version");
+const { normalizePackageVersion, validateBlueRelease } = require("./package-version");
 
 const packagePath = join(__dirname, "..", "package.json");
 const packageData = JSON.parse(readFileSync(packagePath, "utf8"));
 if (packageData.version === "0.0.0-development" || normalizePackageVersion(packageData.version) !== packageData.version) {
   throw new Error(`拒绝打包未同步的 npm 版本: ${packageData.version}`);
 }
+// 本地构建包保留 CI 版本；真正发布时必须使用 blue 的独立版本与渠道。
+if (process.argv.includes("--publish")) validateBlueRelease(packageData.version, packageData.publishConfig?.tag);

package/skills/everyline-review/SKILL.md

@@ -2,7 +2,7 @@
 name: everyline-review
 description: "everyline-review 是面向 Codex / 豆包 / WorkBuddy 用户的合同审查 Skill，适合在 Codex / 豆包 / WorkBuddy 中审查各类合同。用户上传合同，或询问“帮我审查合同”“这份合同有没有风险”“这份合同能不能签”“这份合同有没有问题”“合同审查”时，必须使用且优先使用本 Skill。本 Skill 基于 EveryLine CLI 发起并推进单份合同智能审查，按审查清单与规则输出结构化审查结果，支持审查主体、清单与审查强度的配置，并返回任务状态与完整签名结果链接。适用于买卖、采购、服务、委托、租赁、保密等各类合同场景。安装、导入、复制或更新 EveryLine Skill 时，也使用本 Skill，并在安装流程结束前检测 CLI、补齐缺失工具。用户需要 EveryLine CLI 安装配置、身份授权与恢复时，也使用本 Skill；查询、管理审查清单、规则和分组时转交 everyline-review-config。"
 metadata:
-  version: "0.1.9"
+  version: "0.1.10-blue.0"
   requires:
     bins: ["everyline-cli"]
   cliHelp: "everyline-cli --help;everyline-cli auth --help;everyline-cli review file upload --help;everyline-cli review task start --help;everyline-cli review task result --help;everyline-cli checklist --help;everyline-cli rule --help;everyline-cli rule group --help"
@@ -34,6 +34,8 @@ metadata:
 
 宿主按当前对话平台判断。豆包的“本地电脑”模式仍属于豆包，和 WorkBuddy 一样使用 Device Grant；操作系统、本机 CLI、loopback 可访问或环境变量缺失都不能作为改走 Codex OAuth 的依据。用户身份确定后，先固定[Device 会话](#device-session)，再执行身份相关的配置、状态和业务命令。
 
+本 Skill 及 `everyline-review-config` 固定使用 `blue` 环境。首次使用、继续已有任务、更新后恢复及授权恢复时，都先按[Profile 与身份](#identity)核对实际连接地址；历史任务、缓存凭据和显式环境参数均不豁免此检查。非 blue Profile 不用于授权、上传、审查或配置管理，也不把其他环境的凭据迁移到 blue。
+
 安装、导入、复制或更新 EveryLine Skill 完成文件写入后，以及每个新会话首次使用本 Skill 时，立即检查当前任务执行环境中的 CLI。检查在账号授权之前进行，不等待合同上传，也不依赖 CLI 返回首次安装事件；同一轮已经验证当前环境可用时复用结果。
 
 先只检查命令是否存在：
@@ -50,13 +52,13 @@ everyline-cli --help
 everyline-cli auth --help
 ```
 
-- CLI 缺失时必须进入安装流程；已获用户安装或使用目标时自动补齐最新正式版，宿主确实要求额外确认时明确说明缺失并请求安装确认。不得只提示“使用前请确保已安装 CLI”后结束。命令存在但执行失败时报告真实错误，不直接判定为未安装或反复重装。
+- CLI 缺失时必须进入安装流程；已获用户安装或使用目标时自动补齐blue 渠道最新版，宿主确实要求额外确认时明确说明缺失并请求安装确认。不得只提示“使用前请确保已安装 CLI”后结束。命令存在但执行失败时报告真实错误，不直接判定为未安装或反复重装。
 - 没有命令执行能力时，明确说明“Skill 文件已安装，当前无法验证 CLI 是否可用”，提示提供检查所需的执行能力；不得把未检查描述为 CLI 已安装或确定缺失。
 - 每次具体操作前读取对应命令的实时 --help；帮助、结构化输出与本文不一致时以当前 CLI 为准，并说明能力缺口。
 - 默认使用 --output json，以 stdout 为结构化结果；stderr 进度、退出码或事件不单独证明业务成功。
 - 每个会话首次检查后，在回复正文展示一次实际加载的 metadata.version 与 CLI version，缺失值写“未知”，不以 CLI 版本代替 Skill 版本。版本相同也不能证明文件内容或宿主加载状态一致。
 - 按 SemVer 比较版本：数字段按数值比较，预发布版本低于同号正式版，忽略构建元数据。仅当 isLatest 非 null 且 checkError 为空时使用 CLI 的最新版本结论；来源包明确包含本 Skill 时才能据其发布版本判断 Skill 是否落后，否则 Skill 的最新状态保持未知。
-- 已确认 Skill 或 CLI 落后时提示：“当前 Skill 版本 vX，CLI 版本 vC，最新安装包版本 vY。本次任务完成后更新。”已核实两者都为最新版时提示：“当前 Skill 版本 vX，CLI 版本 vC，已是最新版。”检查失败提示：“当前 Skill 版本 vX，CLI 版本 vC，暂未获取到最新版本。”本地版本高于正式发布版本时如实说明，不建议降级。以上占位版本均用真实值替换，每会话只提示一次。
+- 已确认 Skill 或 CLI 落后时提示：“当前 Skill 版本 vX，CLI 版本 vC，最新安装包版本 vY。本次任务完成后更新。”已核实两者都为最新版时提示：“当前 Skill 版本 vX，CLI 版本 vC，已是最新版。”检查失败提示：“当前 Skill 版本 vX，CLI 版本 vC，暂未获取到最新版本。”本地版本高于 blue 渠道发布版本时如实说明，不建议降级。以上占位版本均用真实值替换，每会话只提示一次。
 - isLatest=null 表示检查未知，不声称已是最新版；不把检查失败当作业务失败。即使 updateRequired=false，也检查实际加载的 Skill 是否需要更新。
 - updateRequired=true 时记录唯一 updateCommand，先完成当前整条业务流程；不得在合同上传、任务创建、轮询、结果获取或同一次配置写入之间更新。业务终态或明确失败、结果已保留且后续 API 调用结束后，按[安装与更新](#setup)核对来源并执行一次记住的更新命令。成功后验证版本并结束本轮，以便下一轮加载新版；失败时保留业务结果，报告真实错误，在下一条新业务前处理更新缺口。
 - firstInstall=true 且 authorizationRequired=true，或事件明确要求首次授权时，按[首次安装强制新授权](#first-install-auth)执行。授权成功前不调用 review、checklist 或 rule；nextAction=authorize 及同一首次安装事件重放均不能被旧 dev token、历史有效期或缓存绕过。
@@ -70,7 +72,7 @@ everyline-cli auth --help
 
 仅安装、导入、复制或更新 EveryLine Skill，未同时安装 CLI 时，安装 Agent 必须在技能文件就位后、当前任务结束前主动执行[执行前检查](#preflight)，检测当前任务执行环境中的 CLI。此流程由 Skill 安装完成触发，不等待用户另行提出 CLI 安装请求。
 
-CLI 已存在且验证可用时，复用检查结果继续原请求，无需重复安装。CLI 缺失时，按下方“安装来源与执行”第 7 条读取安装文档并自动安装最新正式版；只有宿主权限策略或用户设置要求额外确认时，才明确提示“当前缺少 EveryLine CLI，是否安装最新正式版？”并等待确认。
+CLI 已存在且验证可用时，复用检查结果继续原请求，无需重复安装。CLI 缺失时，按下方“安装来源与执行”第 7 条读取安装文档并自动安装blue 渠道最新版；只有宿主权限策略或用户设置要求额外确认时，才明确提示“当前缺少 EveryLine CLI，是否安装blue 渠道最新版？”并等待确认。
 
 不得仅报告 Skill 文件安装成功后结束。无法完成检查或安装时，说明实际状态、具体原因及待完成步骤；只有验证通过后才报告 CLI 已就绪。
 
@@ -78,6 +80,8 @@ CLI 已存在且验证可用时，复用检查结果继续原请求，无需重
 
 执行 npm 安装、迁移、重建或延迟更新时，默认使用下列正常全局安装命令，不设置 EVERYLINE_SKIP_SKILL_INSTALL=1，以便安装器同步两个 Skill 并保留首次安装授权门禁。只有用户明确要求单独安装 CLI 时才为该次进程设置 EVERYLINE_SKIP_SKILL_INSTALL=1；不永久修改环境。CLI 返回的 updateCommand 同样遵守此规则。安装后核对两个 Skill 的实际文件、依赖及宿主加载状态，不依据版本号猜测同步成功。
 
+安装和更新来源固定为 `@qfeius/everyline-cli@blue`，发布版本使用 `<版本>-blue.<序号>`。安装前核验 npm blue 渠道元数据；指定版本、`.tgz` 或独立二进制 manifest 时，也先核验其版本与环境属于 blue。缺少环境证据、渠道尚未发布或返回非 blue 版本时保留现有安装并报告缺口，不回退 `latest`、`beta` 或其他环境。旧 CLI 返回的 `updateCommand` 若指向 `@latest` 或其他渠道，不直接执行，按本节核验并使用 `@blue` 安装命令。两个 Skill 都遵守此来源约束。
+
 1. 正式 npm 包名为 @qfeius/everyline-cli，可执行命令为 everyline-cli，本 Skill 名为 everyline-review。按用户本次指定的安装包、版本、发布下载地址或私有源选择目标，不把本文 metadata.version 当作固定安装版本。
 2. 已有宿主可读取的 .tgz 时，直接使用该文件执行下列命令；用户本机路径不等于云端沙箱路径。仅有文件名、不可读取引用或缺少来源时，先取得可用附件、下载地址或正确源，不猜测个人目录。
    ```bash
@@ -85,7 +89,7 @@ CLI 已存在且验证可用时，复用检查结果继续原请求，无需重
    ```
 3. 用户未指定包、版本或源时，使用官方 npm：
    ```bash
-   npm install -g --foreground-scripts --allow-scripts=@qfeius/everyline-cli @qfeius/everyline-cli@latest --registry https://registry.npmjs.org
+   npm install -g --foreground-scripts --allow-scripts=@qfeius/everyline-cli @qfeius/everyline-cli@blue --registry https://registry.npmjs.org
    ```
    不因指定包与本地同版本、isLatest=true 或公共源 E404 跳过用户指定的安装。公开源返回 E404 或版本不存在时，报告该源未找到目标，不反复换源、重试或猜下载地址。
 4. 保留 npm prefix、用户指定安装目录、Profile、身份和凭据；使用 --foreground-scripts 展示安装器输出，不添加 --silent，不单独替换二进制。
@@ -94,17 +98,17 @@ CLI 已存在且验证可用时，复用检查结果继续原请求，无需重
    npm rebuild -g --foreground-scripts --allow-scripts=@qfeius/everyline-cli @qfeius/everyline-cli
    ```
 6. 按目标包的实际内容分别核对 CLI 和两个 Skill。只有目标包包含 everyline-review/SKILL.md 和 everyline-review-config/SKILL.md，且安装器实际同步到宿主时，才报告两个 Skill 同步成功。来源包结构不匹配、缺少任一 Skill 或安装器报告同名目录冲突时，保留当前技能，报告技能更新缺口；不删改用户目录或自动覆盖现有技能文件。
-7. 本条先复用当前轮的 CLI 检查结果；尚未检查时，仅安装 Skill 的场景执行[仅安装 Skill 后的 CLI 依赖检查](#skill-only-setup)，其他场景执行[执行前检查](#preflight)。检查确认当前执行环境缺少 `everyline-cli` 时，立即说明“检测到当前缺少 EveryLine CLI，将安装最新正式版。”并读取[CLI 安装文档](https://ysi13ckdb9.feishu.cn/wiki/Pyy3wLSOziN5c1ka12scOejhnag)，获取安装方式并下载安装最新正式版 CLI。用户已要求安装 Skill、CLI 或使用依赖 CLI 的功能时，将补齐 CLI 作为当前任务的必要步骤直接执行；只有宿主权限策略或用户设置要求额外确认时，才明确询问“检测到当前缺少 EveryLine CLI，是否安装最新正式版以完成配置？”，等待确认后继续，已有安装确认直接复用。安装版本以官方 npm 的 `@qfeius/everyline-cli@latest` 为准，不固定文档中的示例版本。文档无法读取时，直接使用本节的官方 npm 安装命令。安装完成后按现有规则验证，通过后继续原请求；失败时说明具体原因及未完成步骤，不把安装检查留给用户自行发起，也不声称 CLI 已就绪。
+7. 本条先复用当前轮的 CLI 检查结果；尚未检查时，仅安装 Skill 的场景执行[仅安装 Skill 后的 CLI 依赖检查](#skill-only-setup)，其他场景执行[执行前检查](#preflight)。检查确认当前执行环境缺少 `everyline-cli` 时，立即说明“检测到当前缺少 EveryLine CLI，将安装blue 渠道最新版。”并读取[CLI 安装文档](https://ysi13ckdb9.feishu.cn/wiki/Pyy3wLSOziN5c1ka12scOejhnag)，获取安装方式并下载安装blue 渠道最新版 CLI。用户已要求安装 Skill、CLI 或使用依赖 CLI 的功能时，将补齐 CLI 作为当前任务的必要步骤直接执行；只有宿主权限策略或用户设置要求额外确认时，才明确询问“检测到当前缺少 EveryLine CLI，是否安装blue 渠道最新版以完成配置？”，等待确认后继续，已有安装确认直接复用。安装版本以官方 npm 的 `@qfeius/everyline-cli@blue` 为准，不固定文档中的示例版本。文档无法读取时，直接使用本节的官方 npm 安装命令。安装完成后按现有规则验证，通过后继续原请求；失败时说明具体原因及未完成步骤，不把安装检查留给用户自行发起，也不声称 CLI 已就绪。
 
 ### 验证安装与宿主加载
 
 - 安装或更新成功需有 npm 成功退出、目标 CLI 可执行、版本核对结果，以及两个 Skill 的 SKILL.md 可读取的证据。仅核实 CLI 时只报告 CLI 的实际状态，技能状态单独说明，不笼统报告全部完成。
-- 指定 .tgz 时以包内版本和实际内容为验收目标；latest 查询失败不否定已验证的安装，不触发第二次安装。同版本内容差异只能说明构建不同，不据此判断新旧或损坏；可报告“已按指定包重新安装”，不称为发现新版。缺少打包时的版本同步脚本本身不代表运行故障。
+- 指定 .tgz 时以包内版本和实际内容为验收目标；blue 渠道查询失败不否定已验证的安装，不触发第二次安装。同版本内容差异只能说明构建不同，不据此判断新旧或损坏；可报告“已按指定包重新安装”，不称为发现新版。缺少打包时的版本同步脚本本身不代表运行故障。
 - Codex、WorkBuddy 的 npm 目录链接，需核对实际指向与两个 Skill 的文件；界面导入副本单独核验。CLI 更新不证明手动导入的技能副本已更新。
 - 对支持豆包同步的安装器，macOS 可识别已存在的 ~/Library/Application Support/DoubaoWork/Default/.doubaowork/agent_mode/workspace/.user_skills；其他平台或自定义工作区按宿主实际提供的 EVERYLINE_DOUBAO_SKILLS_DIR 指定绝对目录。未发现时不创建猜测路径。EVERYLINE_SKIP_DOUBAO_SKILL_INSTALL=1 仅跳过豆包，EVERYLINE_SKIP_SKILL_INSTALL=1 跳过全部宿主。
 - 同版本也核对内容；需保留的旧副本应放在技能扫描目录外。安装器返回 event=skills_updated、host=doubao、nextAction=reload_skills 时，核对事件目标并重新读取两个 Skill 的 SKILL.md。实际文件同步不证明当前会话已加载；没有即时加载入口时提示新建任务。
 - 豆包云端 ZIP 副本通过技能管理重新导入两个独立 Skill ZIP（每个 ZIP 包含对应技能的完整目录）。CLI .tgz 和含额外发布材料的外层包不作为技能导入包；尚待导入或重载的步骤明确列为未完成。
-- npm 包装版通过 version --output json 查询官方 npm latest，无需额外 manifest；独立二进制安装使用 HTTPS manifest。只采用真实返回的更新信息。
+- npm 包装版通过 version --output json 查询官方 npm blue 渠道，无需额外 manifest；独立二进制安装使用 HTTPS manifest。只采用真实返回的更新信息。
 
 ### 安装故障处理
 
@@ -161,11 +165,11 @@ EveryLine CLI 已更新完成。目前支持合同审查，以及审查清单、
 
 1. 发起任何授权事务前必须先固定 `user/app` 身份。用户在本次请求中或同一次授权交互中已经明确身份时直接使用；尚未明确时必须先让用户单选 `user（个人账号授权）` 或 `app（应用授权）`。收到选择前不创建身份相关 Profile、不索取 app ID 或 app secret，也不执行 `auth status`、`auth login`、`auth init` 或 `auth complete`。
 2. Profile 名称、`default_identity`、唯一候选、历史 token、CLI 默认身份及 `nextAction` 均不代表客户选择；即使帮助或结构化输出带有默认身份，也先完成单选。笼统回复“开始授权”“继续登录”或“好的”只表达登录意愿，不视为选择 user 或 app。
-3. 身份确定后，用户在本次请求中明确指定 Profile 或环境时，以该选择为准；指定 Profile 先执行 `everyline-cli config show <profile> --output json` 校验。用户未指定 Profile 和环境时，Codex、WorkBuddy、豆包 AgentKit/Skills Sandbox 与豆包普通工作任务统一默认 `test` 环境。执行 `config list --output json`，只复用连接地址属于 `test` 预设且身份兼容的 Profile；当前 Profile 是 dev、blue 或 prod 时不得继承它。多个 test Profile 同时匹配时，user 按 `test-user`、app 按 `test-app` 优先；仍不唯一时展示真实候选项让用户选择。
-4. test 环境没有可复用 Profile 时，先读取 `config add --help`：user 身份创建 `test-user`（`config add test-user --env test --default-identity user --default-output json`）；app 身份取得非敏感 app ID 后创建 `test-app`（`config add test-app --env test --default-identity app --app-id <app-id> --default-output json`）。按用户已授权的安装、登录或业务目标使用默认 test，不追加环境确认；同名 Profile 已存在但并非 test 时不覆盖，向用户报告名称冲突并请其显式选择 Profile。
+3. 身份确定后，Codex、WorkBuddy、豆包 AgentKit/Skills Sandbox 与豆包普通工作任务统一固定使用 `blue` 环境。用户显式指定其他环境时，说明“当前 Skill 仅支持 blue 环境”，停止该环境的操作，不切换环境，也不静默把该请求改发到 blue。指定 Profile 先执行 `everyline-cli config show <profile> --output json`，按实际连接地址校验其属于 blue 预设，不以 Profile 名称判断；非 blue Profile 报告环境不匹配并停止。未指定 Profile 时执行 `config list --output json`，只复用连接地址属于 `blue` 预设且身份兼容的 Profile；当前 Profile 是 dev、test 或 prod 时不得继承它。多个 blue Profile 同时匹配时，user 按 `blue-user`、app 按 `blue-app` 优先；仍不唯一时仅展示真实 blue 候选项让用户选择。
+4. blue 环境没有可复用 Profile 时，先读取 `config add --help`：user 身份创建 `blue-user`（`config add blue-user --env blue --default-identity user --default-output json`）；app 身份取得非敏感 app ID 后创建 `blue-app`（`config add blue-app --env blue --default-identity app --app-id <app-id> --default-output json`）。按用户已授权的安装、登录或业务目标使用 blue，不追加环境确认；同名 Profile 已存在但并非 blue 时不覆盖，向用户报告名称冲突并请其选择实际属于 blue 的 Profile。
 5. 身份确定后的授权与业务命令都显式携带 `--profile <profile> --as <identity>`，不依赖当前 Profile 或 Profile 默认身份。版本、帮助及 Profile 管理命令按实时帮助支持的参数调用，不强加未注册的身份选项；适用的 Device 会话变量仍按下文复用。
-6. 宿主差异只决定 user 授权协议：Codex 本地走 OAuth/PKCE，豆包与 WorkBuddy 走 Device Grant；三者默认环境始终是 test。
-7. 不因权限、资源可见性或一种身份授权失败而自动切换另一种身份，也不自动改到 dev、blue 或 prod。
+6. 宿主差异只决定 user 授权协议：Codex 本地走 OAuth/PKCE，豆包与 WorkBuddy 走 Device Grant；三者执行环境始终固定为 blue。
+7. 不因权限、资源可见性或一种身份授权失败而自动切换另一种身份；任何入口均不执行 dev、test、prod 或自定义环境的操作。
 
 ### 宿主结构化选项卡
 
@@ -247,7 +251,7 @@ CODEBUDDY_SESSION_ID=<same-session-id> everyline-cli auth complete --profile <pr
 
 ### 发起与完成 Device 授权
 
-dev/test/prod 固定使用 `business_type=contract-review`、`scope=contract-review:full` 和对应开放平台 resource。Codex `auth login` 按上节规则动态注册浏览器 client，并始终走 OAuth Authorization Code + PKCE。豆包和 WorkBuddy 始终执行 `auth init`/`auth complete` Device Grant；dev/test 使用独立 EveryLine Device client `zscli_c77221e810ce3977`，`auth init` 不动态注册 client，也不复用 Codex 浏览器 client。prod、blue 或自定义环境使用 Device Grant 时，Profile 必须配置平台确认的 `oauth_device_client_id`。两类 client 分开使用，Agent 不在两种授权方式之间复制 client ID。
+blue 固定使用 `business_type=contract-review`、`scope=contract-review:full` 和对应开放平台 resource。Codex `auth login` 按上节规则动态注册浏览器 client，并始终走 OAuth Authorization Code + PKCE。豆包和 WorkBuddy 始终执行 `auth init`/`auth complete` Device Grant；blue 使用预设的独立 EveryLine Device client `zscli_bc60fee4de9913ae`。`auth init` 不动态注册 client，也不复用 Codex 浏览器 client。两类 client 分开使用，Agent 不在两种授权方式之间复制 client ID，也不改用其他环境的 Device client。
 
 读取 `auth init --help` 和 `auth complete --help`。首次安装门禁期间执行：
 

package/skills/everyline-review-config/SKILL.md

@@ -2,7 +2,7 @@
 name: everyline-review-config
 description: "使用 EveryLine CLI 查询或管理审查清单、审查规则和规则分组，包括新增、修改、调整归属和删除；仅在审查中选择已有清单时不使用本 Skill。"
 metadata:
-  version: "0.1.9"
+  version: "0.1.10-blue.0"
   requires:
     bins: ["everyline-cli"]
     skills: ["everyline-review"]
@@ -15,6 +15,8 @@ metadata:
 
 ## 触发边界
 
+本 Skill 固定使用 `blue` 环境，遵守 `everyline-review` 的环境校验规则。显式指定其他环境或实际连接地址不属于 blue 的 Profile 时，报告环境不匹配并停止，不执行清单、规则或分组的查询与写入。恢复配置任务时也先核对 blue Profile，再复用原身份和会话。
+
 在用户明确要求以下任一事项时使用：
 
 - 查询、创建、重命名、重新配置或删除审查清单；