@qfeius/everyline-cli 0.1.12 → 0.1.18

package/README.md

@@ -2,11 +2,11 @@
 
 EveryLine 命令行工具，支持合同审查工作流、审查清单和审查规则管理。
 
-本分支的两项 Skill 固定使用 blue 环境；下文配置、授权和审查示例均使用 blue Profile。
+公开版本默认使用 prod，且只提供 prod 环境预设。其他部署环境应通过自定义 Profile 配置，不在公开文档和安装包中暴露内部环境地址。
 
 ## 安装
 
-npm 包名为 `@qfeius/everyline-cli`，终端命令仍为 `everyline-cli`。blue 与 release 统一通过 `@latest` 安装和更新，共用不带环境后缀的正式版本号（例如 `0.1.11`）。npm 渠道和版本号不表示业务环境，本分支仍按实际连接地址核对 blue Profile。本地交付统一使用 `make package`，每次查询 npm 全部已发布版本，取其与本地版本的最高基础版本后递增 patch 号，并同步 CLI 与两项 Skill 后生成安装包。发布到 npm 前使用 `.tgz` 安装；发布配置与操作见 [npm 发布指南](docs/npm-release.md)。
+npm 包名为 `@qfeius/everyline-cli`，终端命令仍为 `everyline-cli`。本地交付统一使用 `make package`，根据 npm 全量已发布版本和本地版本递增补丁版本，并同步 CLI 与两项 Skill 后生成安装包。blue 和 release 分支共用纯 `x.y.z` 版本序列，不添加环境后缀，均发布到 npm `latest`。发布到 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 blue-user \
-  --env blue \
+everyline-cli config add prod-user \
+  --env prod \
   --default-identity user
 ~~~
 
@@ -52,7 +52,7 @@ everyline-cli config add blue-user \
 
 ~~~bash
 everyline-cli auth login \
-  --profile blue-user \
+  --profile prod-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；blue Profile 已内置独立 Device client。执行下面的命令前先按后文准备并固定对应宿主的会话变量：
+豆包（含本地电脑）和 WorkBuddy 统一使用 Device Grant；prod Profile 已内置各环境对应的独立 Device client。执行下面的命令前先按后文准备并固定对应宿主的会话变量：
 
 ~~~bash
-everyline-cli config add blue-user --env blue --default-identity user
-everyline-cli auth init --profile blue-user --as user --output json
+everyline-cli config add prod-user --env prod --default-identity user
+everyline-cli auth init --profile prod-user --as user --output json
 # 用户打开 verification_uri_complete 并完成授权后：
-everyline-cli auth complete --profile blue-user --as user --output json
+everyline-cli auth complete --profile prod-user --as user --output json
 ~~~
 
-`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 使用系统凭证库。
+`auth init` 不监听 `127.0.0.1`，不动态注册 client，也不复用 Codex 浏览器 client。prod 预设使用独立 Device client `zscli_bc60fee4de9913ae`；自定义环境使用 Device Grant 时，通过 `--oauth-device-client-id` 配置平台确认的 client。prod 不内置浏览器 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 blue-user \
+  --profile prod-user \
   --as user \
   --output json
 ~~~
 
 `auth status` 默认读取当前身份对应的安全缓存。OAuth metadata 声明 refresh grant 时，CLI 会在过期前五分钟尝试刷新；进入该窗口后缺少 refresh token 或刷新失败时提示手动重新授权，不回退使用旧 token；业务请求收到可信 `code=110004` 时只刷新并重放一次。服务端不支持刷新或返回 `invalid_grant` 时清理被拒绝的旧 token；并发写入的新 token 会保留。
 
-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。
+prod 预设已包含正式 OAuth metadata、business type、loopback redirect 和 scope；使用 `--env prod` 创建 user Profile 后，每次显式 Codex user 登录都会通过 metadata 声明的注册端点动态获取浏览器 client ID。prod 已内置 Device client `zscli_bc60fee4de9913ae`，豆包/WorkBuddy 可直接使用该预设。CLI 不把 AuthURL 直接当作 OAuth authorization endpoint。
 
 ## app 应用授权
 
 ### 创建 Profile
 
 ~~~bash
-export EVERYLINE_APP_ID='cli_blue_xxx'
+export EVERYLINE_APP_ID='cli_prod_xxx'
 
-everyline-cli config add blue-app \
-  --env blue \
+everyline-cli config add prod-app \
+  --env prod \
   --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 blue-app \
+    --profile prod-app \
     --as app \
     --app-secret-stdin \
     --output json
@@ -148,12 +148,12 @@ Agent 调用示例：
 
 ~~~bash
 everyline-cli auth status \
-  --profile blue-app \
+  --profile prod-app \
   --as app \
   --output json
 
 everyline-cli review run \
-  --profile blue-app \
+  --profile prod-app \
   --as app \
   --input review-run.json \
   --output json \
@@ -191,7 +191,7 @@ everyline-cli review run \
 
 ~~~bash
 everyline-cli review run \
-  --profile blue-user \
+  --profile prod-user \
   --as user \
   --input review-run.json \
   --dry-run
@@ -201,7 +201,7 @@ everyline-cli review run \
 
 ~~~bash
 everyline-cli review run \
-  --profile blue-user \
+  --profile prod-user \
   --as user \
   --input review-run.json \
   --output json \
@@ -226,7 +226,7 @@ review task result
 
 ~~~bash
 everyline-cli review file upload \
-  --profile blue-user \
+  --profile prod-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 blue-user --as user --stdin --name 采购合同.pdf --output json < attachment.pdf
+everyline-cli review file upload --profile prod-user --as user --stdin --name 采购合同.pdf --output json < attachment.pdf
 ~~~
 
 使用上传结果中的 businessId、fileId 和 fileHash 发起任务：
 
 ~~~bash
 everyline-cli review task start \
-  --profile blue-user \
+  --profile prod-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 blue-user \
+  --profile prod-user \
   --as user \
   --task-id 123456789 \
   --output json > result.json
@@ -265,20 +265,20 @@ CLI 已移除 --app-type 参数；文件上传也不再接受 --business-id。
 
 ## 自更新
 
-CLI 与两项本地 Skill 支持两种更新来源：经核验包名、版本和内容的 `.tgz`，或官方 npm 的 `latest` 渠道最新版。两者都由 npm 安装器完成同步，保留原安装 prefix 和账号配置。`latest` 渠道缺失或查询失败时保留现有安装；安装后仍核对实际连接地址为 blue，不从 npm 渠道或版本号推断业务环境。
+CLI 与两项本地 Skill 支持两种更新来源：用户提供的 `.tgz`，或官方 npm 的最新版。两者都由 npm 安装器完成同步，保留原安装 prefix 和账号配置。
 
 ```bash
 # 使用指定包，无需先发布到 npm；将路径替换为实际文件。
 npm install -g --foreground-scripts --allow-scripts=@qfeius/everyline-cli ./everyline-cli-<版本>.tgz
 
-# 使用已经发布到 npm latest 渠道的最新版。
+# 使用已经发布到 npm 的最新版。
 npm install -g --foreground-scripts --allow-scripts=@qfeius/everyline-cli @qfeius/everyline-cli@latest --registry https://registry.npmjs.org
 ```
 
 指定 tgz 时不因版本相同或 npm 查询失败跳过安装。更新后核对 CLI 与两项 Skill，重新读取或新建任务加载；豆包云端手动导入的 Skill 仍需在平台重新导入。详见 [更新与卸载](docs/everyline-cli-skill-guide.md#10-更新与卸载)。`everyline-cli update` 本身仍用于下述独立二进制 manifest 更新。
 
 
-`everyline-cli version` 输出 `latestVersion/isLatest/updateRequired/updateCommand`；检查失败时 `isLatest=null`，且不会把未知状态当成需要更新。普通 review/checklist/rule 命令确认存在新版本时，在 stderr 输出 `UPDATE_PENDING` 单行 JSON，但继续完成当前业务 API。Agent 在当前完整业务流程结束后执行其中的 `updateCommand`；旧 CLI 若仍返回 `@blue` 更新目标，改用上面的 `@latest` 安装命令并保留原 prefix。下一条新业务再使用新版 CLI 与 Skill。
+`everyline-cli version` 输出 `latestVersion/isLatest/updateRequired/updateCommand`；检查失败时 `isLatest=null`，且不会把未知状态当成需要更新。普通 review/checklist/rule 命令确认存在新版本时，在 stderr 输出 `UPDATE_PENDING` 单行 JSON，但继续完成当前业务 API。Agent 在当前完整业务流程结束后执行其中的 `updateCommand`，下一条新业务再使用新版 CLI 与 Skill。
 
 独立二进制可以通过 HTTPS manifest 检查和更新当前平台制品。地址按 `--manifest-url`、`EVERYLINE_CLI_UPDATE_MANIFEST_URL`、发布构建内置值的顺序选择：
 
@@ -323,9 +323,9 @@ manifest 示例：
 
 ~~~bash
 everyline-cli config list
-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 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 completion zsh
 ~~~
 
@@ -337,11 +337,9 @@ everyline-cli completion zsh
 
 - 不新增内部环境地址、内部域名或未确认的 OAuth 配置。
 - 不提交 app secret、access token、OAuth code、Keychain 内容或本地配置文件。
-- 使用 fake HTTP、临时 Profile 和测试 token 验证功能，不依赖真实环境凭证。
+- 使用 fake HTTP、临时 Profile 和测试 token 验证功能，不依赖真实 prod 凭证。
 - 运行 go test ./...、go vet ./... 和 make build。
 
- npm 安装版通过 `everyline-cli version --output json` 查询 npm 官方源的 `latest` 渠道版本，无需配置 manifest。发现新版后，在当前业务流程结束时执行返回的 `updateCommand`（旧 `@blue` 更新目标按前文迁移至 `@latest`），由 npm 安装器同步 CLI 和本地 Skills；检查失败时最新版本状态保持未知。独立二进制安装仍使用 HTTPS manifest。
+ npm 安装版通过 `everyline-cli version --output json` 查询 npm 官方源的 `latest` 版本，无需配置 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 @@
-7a76b67acf3edc1d1967d709b5d89aeea558cd953a41d47d07ce49007831f078  bin/darwin-amd64/everyline-cli
-206f296e60333fcd012fb8fcfbbdc87b8d843cd39e8d8ab3ee9fec94fc042ada  bin/darwin-arm64/everyline-cli
-16f1ab4e19b32e952710df5a9cb33322caeee4cbff242de9644d225d95312819  bin/linux-amd64/everyline-cli
-638ec0732a46c9d93f6c948dc1a0a6d38207dfc42d1ad92fa5bd347d7e7c32ee  bin/linux-arm64/everyline-cli
-d17f4403aee0757776908d92627b467b518f5aa6af2edeb6a12bdbbc1a362c56  bin/windows-amd64/everyline-cli.exe
-28084beb3a49e23c5c332f683d734deb262b0e797bdfc436f44f15f0bcc75264  bin/windows-arm64/everyline-cli.exe
+b33af8494eea8931dd8db022806fb8d134095dd4622c139cdfaf82ab780273f2  bin/darwin-amd64/everyline-cli
+3deb21c971ba189b518d9418870cb9078c74ed5713e8e608e78f8f76e2f65773  bin/darwin-arm64/everyline-cli
+94cb6616156826f06bb0ed88bb1d280cfa48755ae57f3d8fa3ace5f42d5c43b0  bin/linux-amd64/everyline-cli
+ed89b083fc0e63e289826338772aa564d53ead4dff23b848fb3b9992e76c93a8  bin/linux-arm64/everyline-cli
+763283b805ab694e72e23f9d38a2615dc154a648c484ae8c52e8bfc65c571008  bin/windows-amd64/everyline-cli.exe
+e93bfd5aa20b85716bc1f9b8ee45af00971abe791fbc10181aa340818caba466  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 应来自同一个发布版本，格式为 `主版本.次版本.补丁版本`。blue 与 release 共用全局递增版本号，并统一发布到 npm `latest` 渠道；`version.updateRequired` 触发业务结束后的延迟更新。安装前核验指定包的包名、版本和实际内容，`latest` 查询失败时保留原安装。npm 渠道和版本号不表示业务环境，本分支两项 Skill 仍按实际连接地址校验 blue Profile。
+CLI 和 Skill 应来自同一个发布版本。每次 Skill 发布（包括纯文案调整）都提升 `package.json` 统一版本、发布同版本 npm 包并更新远端 manifest，让 `version.updateRequired` 可以触发强制更新门禁。
 
 ## 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` 都不作为用户选择的依据；笼统的“开始授权”或“继续授权”也不等于选择了身份。
 
-身份明确后，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。
+身份明确后，用户本轮没有指定 Profile 或环境时，Codex、WorkBuddy 和豆包统一默认 prod：user 复用或创建 `prod-user`，app 复用 `prod-app`，缺少时在取得非敏感 app ID 后创建。当前 dev、test、blue Profile 不会被默认继承；用户本轮显式指定的 Profile 或环境优先。宿主差异只影响 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 身份：推荐用于人工交互验证
 
-blue Profile 可由 Agent 自动创建；手工等价命令为：
+默认 prod Profile 可由 Agent 自动创建；手工等价命令为：
 
 ```bash
-everyline-cli config add blue-user \
-  --env blue \
+everyline-cli config add prod-user \
+  --env prod \
   --default-identity user
 
-everyline-cli config use blue-user
+everyline-cli config use prod-user
 ```
 
 Codex 本地交互可完成浏览器 OAuth 登录：
 
 ```bash
 everyline-cli auth login \
-  --profile blue-user \
+  --profile prod-user \
   --as user \
   --no-open-browser \
   --timeout 3m
@@ -300,7 +300,7 @@ everyline-cli auth login \
 
 ```bash
 everyline-cli auth status \
-  --profile blue-user \
+  --profile prod-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 blue-user --as user --output json
+everyline-cli auth init --profile prod-user --as user --output json
 ```
 
 把 `verification_uri_complete` 从 `https://` 到最后一个 query 参数逐字保留为链接目标，并展示 `[点击授权](<verification_uri_complete>)`。用户主动点击并完成授权后只检查一次：
 
 ```bash
-everyline-cli auth complete --profile blue-user --as user --output json
+everyline-cli auth complete --profile prod-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` 才继续。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`。
+只有 `status=succeeded` 才继续。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：prod 使用独立 Device client `zscli_bc60fee4de9913ae`，不动态注册也不复用浏览器 client；自定义环境需显式配置平台确认的 Device 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 blue-app \
-  --env blue \
+everyline-cli config add prod-app \
+  --env prod \
   --default-identity app \
   --app-id "$EVERYLINE_APP_ID"
 
-everyline-cli config use blue-app
+everyline-cli config use prod-app
 
 printf '%s' "$EVERYLINE_APP_SECRET" | \
   everyline-cli auth login \
-    --profile blue-app \
+    --profile prod-app \
     --as app \
     --app-secret-stdin \
     --output json
@@ -515,7 +515,7 @@ $everyline-review 使用 prod-user Profile 和 user 身份审查 /absolute/path/
 
 ### Skill 在上传前提示 CLI 版本不满足要求
 
-解析 `version --output json`。`updateRequired=true` 时先记住 `updateCommand`，继续完成当前完整业务流程；CLI 同时会在 stderr 输出 `code=UPDATE_PENDING`、当前版本、最新版本、更新命令和 `updateAfter=current_business_workflow`。全部业务 API 结束并保留结果后执行一次更新命令；旧 CLI 若返回 `@blue` 更新目标，使用下文 `@latest` 安装命令并保留原 npm prefix。再次检查版本，下一条新业务重新加载新版 Skill，并按实际连接地址校验 blue Profile。
+解析 `version --output json`。`updateRequired=true` 时先记住 `updateCommand`，继续完成当前完整业务流程；CLI 同时会在 stderr 输出 `code=UPDATE_PENDING`、当前版本、最新版本、更新命令和 `updateAfter=current_business_workflow`。全部业务 API 结束并保留结果后原样执行一次更新命令，再次检查版本；下一条新业务重新加载新版 Skill。
 
 CLI 与两项 Skill 更新并校验成功后展示“EveryLine CLI 已更新完成。目前支持合同审查，以及审查清单、规则和规则分组配置。”，复用同次授权中用户已选的身份；尚未选择时先单选 user/app，再对匹配的 Profile 和身份执行一次 `auth status`。只有 `authenticated=true` 时追加“当前已存在生效授权，可直接调用cli能力；”；`authenticated=false` 时追加“使用前需要先完成账号授权，我现在可以为你打开授权页面或生成授权链接。”，已有继续授权请求时直接按已选身份继续，否则等待用户确认。状态查询报错时保留未知状态并报告原始错误，不从 token 文件或安装成功推断授权有效。
 
@@ -557,7 +557,7 @@ everyline-cli version --output json
 
 也可以将 tgz 作为工作任务附件提供，然后告诉 Agent：“使用 everyline-review 技能，按附件 tgz 更新 CLI 和两项 Skill，不从 npm 查询最新版。”即使包版本相同，也按指定包安装并同步可管理的 Skill 内容；无需该包先发布到 npm。
 
-**从 npm latest 渠道更新到最新版**：
+**从 npm 更新到最新版**：
 
 ```bash
 npm install -g --foreground-scripts --allow-scripts=@qfeius/everyline-cli @qfeius/everyline-cli@latest --registry https://registry.npmjs.org

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

@@ -92,10 +92,10 @@ flowchart TD
 
 | ID | 状态 | 用户示例或条件 | Skill 处理 | 结束条件 |
 | --- | --- | --- | --- | --- |
-| 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-01 | 已支持 | 用户明确提供 Profile | 先明确 user/app 选择，再使用 `config show <profile> --output json` 校验、读取并固定该 Profile；Profile 名称和默认身份不代替选择 | 后续命令显式传递 Profile |
+| PROFILE-02 | 已支持 | 用户未提供 Profile 和环境 | 先明确 user/app 选择，Codex、WorkBuddy、豆包统一选择 prod 环境；复用身份兼容的 prod Profile，没有时创建 `prod-user` 或取得 app ID 后创建 `prod-app` | 固定 prod Profile，不继承 dev/test/blue 当前 Profile |
+| PROFILE-02A | 已支持 | 用户本轮明确指定 Profile 或环境 | 校验并采用用户选择 | 显式选择覆盖默认 prod |
+| PROFILE-02B | 已支持 | 默认名称已被其他环境占用 | 不覆盖同名 Profile，展示冲突并请求显式 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 | 受限 | 默认 blue Profile 创建失败，或 app 身份缺少 app ID | 返回真实配置错误；app ID 只作为非敏感输入单独取得 | 配置条件补齐后重新调用 |
+| AUTH-10 | 受限 | 默认 prod 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 | 已支持 | 仅有一个 `blue-user` Profile，默认身份为 user，且存在历史 token | 仍先让用户单选 user/app；不从 Profile 或 token 推断选择 | 用户选择后才匹配 Profile 和查询状态 |
+| AUTH-25 | 已支持 | 仅有一个 `prod-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 固定使用 blue，只自动创建缺失的 blue Profile；显式指定其他环境时停止该环境的操作。Skill 会读取并固定本次 Profile，避免后续独立进程回退到其他环境或身份。
+当前 Skill 只自动创建缺失的默认 prod Profile；其他环境的 Profile 仍由用户显式管理。Skill 会读取并固定本次 Profile，避免后续独立进程回退到其他环境或身份。
 
 ## 6. 合同来源交互
 
@@ -289,7 +289,7 @@ flowchart TD
 
 | ID | 状态 | 当前范围 |
 | --- | --- | --- |
-| GAP-01 | 不支持 | blue 以外的环境或 Profile，包括用户显式指定和恢复历史任务 |
+| GAP-01 | 未定义 | 默认 prod 以外的自动 Profile 创建、更新或切换 |
 | GAP-02 | 未定义 | 自动升级现有 CLI |
 | GAP-03 | 未定义 | 创建或更新规则分组 |
 | GAP-04 | 未定义 | 清单、规则或分组的批量删除交互 |
@@ -306,10 +306,10 @@ flowchart TD
 
 以下最小集合可覆盖主要分支：
 
-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；使用内置规则包；强度中立。`
+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；使用内置规则包；强度中立。`
 5. `$everyline-review 列出我可用的自定义审查清单和其中的规则。`
 6. `$everyline-review 创建一个采购合同审查清单。`
 7. `$everyline-review 给“采购合同清单”增加“付款条件风险”规则。`

package/docs/npm-release.md

@@ -2,44 +2,42 @@
 
 npm 包名为 `@qfeius/everyline-cli`，终端命令和两项 Skill 名称保持不变。公共源固定为 `https://registry.npmjs.org/`。生成 `.tgz`、推送源码与发布 npm 是三个独立步骤，只有发布成功后才能通过包名安装。
 
-本分支固定使用 blue 业务环境。blue 与 release 的安装、检查更新和发布统一使用 `latest` dist-tag，共用同一套递增编号；版本使用 `主版本.次版本.补丁版本`，例如 `0.1.11`，不再添加环境后缀。npm 渠道和版本号不表示业务环境，实际业务仍按 Profile 连接地址校验。npm 版本在整个包名下唯一，发布流程应依次执行，避免两次并行打包选中同一个尚未发布的版本。`latest` 渠道尚未发布或查询失败时，检查结果为未知，保留现有安装。
-
 ## 一次性配置
 
 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，避免两个任务争抢同一版本。
+2. 在 npm 包 `@qfeius/everyline-cli` 的 Trusted Publisher 中绑定 GitHub 仓库 `qfeius/everyline-cli` 和工作流文件 `npm-publish.yml`。不配置长期 `NPM_TOKEN`。
+3. 将 `.github/workflows/npm-publish.yml` 推送到 GitHub。该工作流使用 GitHub 自动提供的 token 创建 Release，并通过 GitHub OIDC 发布 npm。
 
-发布授权说明：[npm trusted publishing 文档](https://docs.npmjs.com/trusted-publishers/)。
+Trusted Publishing 说明：[npm Trusted Publishers 文档](https://docs.npmjs.com/trusted-publishers/)。
 
 ## 发布步骤
 
-1. 在 blue 分支执行 `node scripts/package-version.js --bump`，或使用包含升版步骤的 `make package`。脚本查询 npm 全部已发布版本，与本地版本比较后递增补丁号；保留 `publishConfig.tag=latest`。已发布版本不能覆盖。
-2. 执行 `make release-check`。构建脚本会同步两项 Skill 的版本；提交版本及相关改动。
-3. 创建并推送与包版本完全一致的标签，例如：
+1. 确定尚未发布的新版本。blue 和 release 共用 npm 包的全局递增版本序列，版本统一为纯 `x.y.z`，不添加 `-blue`、`-release`、`-beta` 等后缀或构建元数据；已发布版本不重复使用。
+2. 执行 `make release-check`，确认当前源码可以构建和安装。
+3. 创建并推送新版本标签，例如：
 
 ```bash
-git tag v0.1.11
+git tag v0.1.12
 git push github HEAD
-git push github v0.1.11
+git push github v0.1.12
 ```
 
 上例中的版本须替换为本次版本。`github` 为本仓库指向 GitHub 的远端名称。
 
-同一标签触发两条工作流；两者都校验已提交版本、`latest` 渠道、Windows 打包和完整发布检查。`release.yml` 发布 GitHub Release 制品、npm 安装包和两项 Skill ZIP；`npm-publish.yml` 通过 OIDC 发布 npm 包并回查 `latest` 渠道。blue 与 release 的 npm 发布始终使用 `--tag latest`，发布成功后 `latest` 指向本次版本。
+标签只触发 `npm-publish.yml` 一条工作流，内部并行运行两个独立 job：一个以 Tag 为版本来源，运行测试和安装校验、发布 GitHub 原生二进制制品，并上传 npm 安装包和两项 Skill ZIP；另一个从同一 Tag 写入构建版本，通过 OIDC 发布 npm。任一 job 失败时可以只重跑失败 job。blue 和 release 分支的 `publishConfig.tag` 均固定为 `latest`，环境由对应分支的包内容决定；后发布的版本更新同一个 `latest`。发布前置校验拒绝预发布后缀和构建元数据。
 
 GitLab 流水线继续负责测试、构建和保存 `.tgz`，不重复发布 npm。
 
 ## 安装与验证
 
-发布完成后安装 `latest` 渠道最新版：
+发布完成后安装正式版：
 
 ```bash
 npm install -g --foreground-scripts --allow-scripts=@qfeius/everyline-cli @qfeius/everyline-cli@latest --registry https://registry.npmjs.org
 everyline-cli version --output json
 ```
 
-安装包内含六个平台的二进制，不需要再次从 GitHub 下载。新版本检查更新查询 `latest` 渠道，发布目标使用不带后缀的正式版本。历史客户端若仍查询 `blue`、返回 `@blue` 更新目标或因旧版本校验显示未知，使用上述 `@latest` 安装命令升级，并保留原 npm prefix。安装完成后仍按实际连接地址核对 blue Profile。
+`@latest` 指向两个分支中最后发布的版本；需要固定某次构建时，将它替换为明确的 `@<x.y.z>`。安装包内含六个平台的二进制，不需要再次从 GitHub 下载。
 
 尚未发布到 npm 时，使用构建后的本地包：
 
@@ -48,7 +46,9 @@ make package
 npm install -g --foreground-scripts --allow-scripts=@qfeius/everyline-cli "./dist/everyline-cli-<版本>.tgz"
 ```
 
-`make package` 取本地及 npm 全部已发布版本中最高的基础版本，再将 patch 加一；历史预发布版本参与比较时去掉后缀。例如 blue 已发布 `0.1.11`，即使 release 本地仍为 `0.1.8`，下次也会生成 `0.1.12`。查询失败时停止，保留本地版本。升版后同步两项 Skill、重新构建六个平台的二进制并生成 `.tgz`；不会提交代码、创建 Git 标签或发布到 npm。文件名中的版本以实际产物为准。日常交付使用 `make package`；`npm pack` 仅用于 CI 已固定版本的发布和内部校验，不自动升版。两个 `*-skill.zip` 是 Skill 导入包，不替代 CLI 安装包。
+`make package` 比较 npm 全量已发布版本与本地版本，取最高基础版本后将补丁版本递增一位。例如 blue 已发布 `0.1.11`，即使 release 本地仍是 `0.1.8`，下一次打包也使用 `0.1.12`。历史预发布版本按其 `x.y.z` 基础版本参与比较，产物始终不带环境后缀。查询失败时停止选号，不退回分支各自累加。随后同步两项 Skill、重新构建六个平台的二进制并生成 `.tgz`；不会提交代码、创建 Git 标签或发布到 npm。文件名中的版本以实际产物为准。日常交付使用 `make package`；`npm pack` 仅用于 CI 已固定版本的发布和内部校验，不自动升版。两个 `*-skill.zip` 是 Skill 导入包，不替代 CLI 安装包。
+
+`make package` 查询版本并不预留 npm 版本号；两个分支应依次打包发布。若并发工作选择了同一版本，后发布的一方重新执行 `make package` 选号，再提交对应版本和标签。
 
 ## 从旧包名迁移
 
@@ -66,8 +66,8 @@ everyline-cli version --output json
 
 ## 发布失败
 
-- OIDC 授权失败：核对 npm trusted publisher 绑定的仓库、工作流文件和 GitHub `id-token: write` 权限。
-- npm 403：核对 scope、包写权限、token 有效期及非交互发布权限。
+- npm OIDC 认证失败：核对 Trusted Publisher 中的 GitHub 组织、仓库和工作流文件名是否分别为 `qfeius`、`everyline-cli` 和 `npm-publish.yml`。
+- npm 403：核对 npm 组织权限、包发布权限及 Trusted Publisher 配置。
 - 版本已存在：不要覆盖；核对已发布结果，需要变更时提升版本并创建新标签。
 - GitHub Release 已生成但 npm 发布失败：npm 包尚未发布成功；解决错误后可安装 Release 中的 `.tgz`，再处理 npm 发布。不要仅凭 Release 存在宣称 npm 已可安装。
 

package/package.json

@@ -1,12 +1,16 @@
 {
   "name": "@qfeius/everyline-cli",
-  "version": "0.1.12",
+  "version": "0.1.18",
   "description": "EveryLine CLI 工具的 npm/npx 薄包装",
   "license": "UNLICENSED",
   "repository": {
     "type": "git",
     "url": "git+https://github.com/qfeius/everyline-cli.git"
   },
+  "homepage": "https://github.com/qfeius/everyline-cli#readme",
+  "bugs": {
+    "url": "https://github.com/qfeius/everyline-cli/issues"
+  },
   "bin": {
     "everyline-cli": "scripts/run.js"
   },

package/scripts/verify-package-version.js

@@ -9,5 +9,5 @@ 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 版本；真正发布时必须使用 x.y.z 正式版本与 latest 渠道。
+// 本地构建包保留 CI 版本；release 发布使用 x.y.z 正式版本与 latest 渠道。
 if (process.argv.includes("--publish")) validateRelease(packageData.version, packageData.publishConfig?.tag, "latest");

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.12"
+  version: "0.1.18"
   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,8 +34,6 @@ 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 返回首次安装事件；同一轮已经验证当前环境可用时复用结果。
 
 先只检查命令是否存在：
@@ -52,13 +50,13 @@ everyline-cli --help
 everyline-cli auth --help
 ```
 
-- CLI 缺失时必须进入安装流程；已获用户安装或使用目标时自动补齐 npm latest 渠道最新版，宿主确实要求额外确认时明确说明缺失并请求安装确认。不得只提示“使用前请确保已安装 CLI”后结束。命令存在但执行失败时报告真实错误，不直接判定为未安装或反复重装。
+- CLI 缺失时必须进入安装流程；已获用户安装或使用目标时自动补齐最新正式版，宿主确实要求额外确认时明确说明缺失并请求安装确认。不得只提示“使用前请确保已安装 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，暂未获取到最新版本。”本地版本高于 npm latest 渠道发布版本时如实说明，不建议降级。以上占位版本均用真实值替换，每会话只提示一次。
+- 已确认 Skill 或 CLI 落后时提示：“当前 Skill 版本 vX，CLI 版本 vC，最新安装包版本 vY。本次任务完成后更新。”已核实两者都为最新版时提示：“当前 Skill 版本 vX，CLI 版本 vC，已是最新版。”检查失败提示：“当前 Skill 版本 vX，CLI 版本 vC，暂未获取到最新版本。”本地版本高于正式发布版本时如实说明，不建议降级。以上占位版本均用真实值替换，每会话只提示一次。
 - isLatest=null 表示检查未知，不声称已是最新版；不把检查失败当作业务失败。即使 updateRequired=false，也检查实际加载的 Skill 是否需要更新。
 - updateRequired=true 时记录唯一 updateCommand，先完成当前整条业务流程；不得在合同上传、任务创建、轮询、结果获取或同一次配置写入之间更新。业务终态或明确失败、结果已保留且后续 API 调用结束后，按[安装与更新](#setup)核对来源并执行一次记住的更新命令。成功后验证版本并结束本轮，以便下一轮加载新版；失败时保留业务结果，报告真实错误，在下一条新业务前处理更新缺口。
 - firstInstall=true 且 authorizationRequired=true，或事件明确要求首次授权时，按[首次安装强制新授权](#first-install-auth)执行。授权成功前不调用 review、checklist 或 rule；nextAction=authorize 及同一首次安装事件重放均不能被旧 dev token、历史有效期或缓存绕过。
@@ -72,7 +70,7 @@ everyline-cli auth --help
 
 仅安装、导入、复制或更新 EveryLine Skill，未同时安装 CLI 时，安装 Agent 必须在技能文件就位后、当前任务结束前主动执行[执行前检查](#preflight)，检测当前任务执行环境中的 CLI。此流程由 Skill 安装完成触发，不等待用户另行提出 CLI 安装请求。
 
-CLI 已存在且验证可用时，复用检查结果继续原请求，无需重复安装。CLI 缺失时，按下方“安装来源与执行”第 7 条读取安装文档并自动安装 npm latest 渠道最新版；只有宿主权限策略或用户设置要求额外确认时，才明确提示“当前缺少 EveryLine CLI，是否安装 npm latest 渠道最新版？”并等待确认。
+CLI 已存在且验证可用时，复用检查结果继续原请求，无需重复安装。CLI 缺失时，按下方“安装来源与执行”第 7 条读取安装文档并自动安装最新正式版；只有宿主权限策略或用户设置要求额外确认时，才明确提示“当前缺少 EveryLine CLI，是否安装最新正式版？”并等待确认。
 
 不得仅报告 Skill 文件安装成功后结束。无法完成检查或安装时，说明实际状态、具体原因及待完成步骤；只有验证通过后才报告 CLI 已就绪。
 
@@ -80,8 +78,6 @@ CLI 已存在且验证可用时，复用检查结果继续原请求，无需重
 
 执行 npm 安装、迁移、重建或延迟更新时，默认使用下列正常全局安装命令，不设置 EVERYLINE_SKIP_SKILL_INSTALL=1，以便安装器同步两个 Skill 并保留首次安装授权门禁。只有用户明确要求单独安装 CLI 时才为该次进程设置 EVERYLINE_SKIP_SKILL_INSTALL=1；不永久修改环境。CLI 返回的 updateCommand 同样遵守此规则。安装后核对两个 Skill 的实际文件、依赖及宿主加载状态，不依据版本号猜测同步成功。
 
-默认安装和更新来源为 `@qfeius/everyline-cli@latest`。blue 与 release 共用全局递增的 `主版本.次版本.补丁版本` 正式版本号，统一使用 npm `latest` 渠道。安装前核验 npm `latest` 元数据；指定版本、`.tgz` 或独立二进制 manifest 时，核验包名、版本和实际内容。渠道尚未发布或查询失败时保留现有安装并报告缺口。npm 渠道和版本号不表示业务环境；两个 Skill 仍按[Profile 与身份](#identity)核对实际连接地址为 blue。旧 CLI 返回的 `updateCommand` 若指向 `@blue` 或其他旧渠道，按本节使用 `@latest` 安装命令并保留原 npm prefix；用户明确指定安装包、版本或源时遵守第 1 条。
-
 1. 正式 npm 包名为 @qfeius/everyline-cli，可执行命令为 everyline-cli，本 Skill 名为 everyline-review。按用户本次指定的安装包、版本、发布下载地址或私有源选择目标，不把本文 metadata.version 当作固定安装版本。
 2. 已有宿主可读取的 .tgz 时，直接使用该文件执行下列命令；用户本机路径不等于云端沙箱路径。仅有文件名、不可读取引用或缺少来源时，先取得可用附件、下载地址或正确源，不猜测个人目录。
    ```bash
@@ -98,17 +94,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，将安装 npm latest 渠道最新版。”并读取[CLI 安装文档](https://ysi13ckdb9.feishu.cn/wiki/Pyy3wLSOziN5c1ka12scOejhnag)，获取安装方式并下载安装 npm latest 渠道最新版 CLI。用户已要求安装 Skill、CLI 或使用依赖 CLI 的功能时，将补齐 CLI 作为当前任务的必要步骤直接执行；只有宿主权限策略或用户设置要求额外确认时，才明确询问“检测到当前缺少 EveryLine CLI，是否安装 npm latest 渠道最新版以完成配置？”，等待确认后继续，已有安装确认直接复用。安装版本以官方 npm 的 `@qfeius/everyline-cli@latest` 为准，不固定文档中的示例版本。文档无法读取时，直接使用本节的官方 npm 安装命令。安装完成后按现有规则验证，通过后继续原请求；失败时说明具体原因及未完成步骤，不把安装检查留给用户自行发起，也不声称 CLI 已就绪。
+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 已就绪。
 
 ### 验证安装与宿主加载
 
 - 安装或更新成功需有 npm 成功退出、目标 CLI 可执行、版本核对结果，以及两个 Skill 的 SKILL.md 可读取的证据。仅核实 CLI 时只报告 CLI 的实际状态，技能状态单独说明，不笼统报告全部完成。
-- 指定 .tgz 时以包内版本和实际内容为验收目标；latest 渠道查询失败不否定已验证的安装，不触发第二次安装。同版本内容差异只能说明构建不同，不据此判断新旧或损坏；可报告“已按指定包重新安装”，不称为发现新版。缺少打包时的版本同步脚本本身不代表运行故障。
+- 指定 .tgz 时以包内版本和实际内容为验收目标；latest 查询失败不否定已验证的安装，不触发第二次安装。同版本内容差异只能说明构建不同，不据此判断新旧或损坏；可报告“已按指定包重新安装”，不称为发现新版。缺少打包时的版本同步脚本本身不代表运行故障。
 - 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 latest，无需额外 manifest；独立二进制安装使用 HTTPS manifest。只采用真实返回的更新信息。
 
 ### 安装故障处理
 
@@ -165,11 +161,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. 身份确定后，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。
+3. 身份确定后，用户在本次请求中明确指定 Profile 或环境时，以该选择为准；指定 Profile 先执行 `everyline-cli config show <profile> --output json` 校验。用户未指定 Profile 和环境时，Codex、WorkBuddy、豆包 AgentKit/Skills Sandbox 与豆包普通工作任务统一默认 `prod` 环境。执行 `config list --output json`，只复用连接地址属于 `prod` 预设且身份兼容的 Profile；当前 Profile 是 dev、test 或 blue 时不得继承它。多个 prod Profile 同时匹配时，user 按 `prod-user`、app 按 `prod-app` 优先；仍不唯一时展示真实候选项让用户选择。
+4. prod 环境没有可复用 Profile 时，先读取 `config add --help`：user 身份创建 `prod-user`（`config add prod-user --env prod --default-identity user --default-output json`）；app 身份取得非敏感 app ID 后创建 `prod-app`（`config add prod-app --env prod --default-identity app --app-id <app-id> --default-output json`）。按用户已授权的安装、登录或业务目标使用默认 prod，不追加环境确认；同名 Profile 已存在但并非 prod 时不覆盖，向用户报告名称冲突并请其显式选择 Profile。
 5. 身份确定后的授权与业务命令都显式携带 `--profile <profile> --as <identity>`，不依赖当前 Profile 或 Profile 默认身份。版本、帮助及 Profile 管理命令按实时帮助支持的参数调用，不强加未注册的身份选项；适用的 Device 会话变量仍按下文复用。
-6. 宿主差异只决定 user 授权协议：Codex 本地走 OAuth/PKCE，豆包与 WorkBuddy 走 Device Grant；三者执行环境始终固定为 blue。
-7. 不因权限、资源可见性或一种身份授权失败而自动切换另一种身份；任何入口均不执行 dev、test、prod 或自定义环境的操作。
+6. 宿主差异只决定 user 授权协议：Codex 本地走 OAuth/PKCE，豆包与 WorkBuddy 走 Device Grant；三者默认环境始终是 prod。
+7. 不因权限、资源可见性或一种身份授权失败而自动切换另一种身份，也不自动改到 dev、test 或 blue。
 
 ### 宿主结构化选项卡
 
@@ -251,7 +247,7 @@ CODEBUDDY_SESSION_ID=<same-session-id> everyline-cli auth complete --profile <pr
 
 ### 发起与完成 Device 授权
 
-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。
+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；prod 预设提供独立 EveryLine Device client `zscli_bc60fee4de9913ae`，`auth init` 不动态注册 client，也不复用 Codex 浏览器 client。自定义环境使用 Device Grant 时，Profile 必须配置平台确认的 `oauth_device_client_id`。两类 client 分开使用，Agent 不在两种授权方式之间复制 client ID。
 
 读取 `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.12"
+  version: "0.1.18"
   requires:
     bins: ["everyline-cli"]
     skills: ["everyline-review"]
@@ -15,8 +15,6 @@ metadata:
 
 ## 触发边界
 
-本 Skill 固定使用 `blue` 环境，遵守 `everyline-review` 的环境校验规则。显式指定其他环境或实际连接地址不属于 blue 的 Profile 时，报告环境不匹配并停止，不执行清单、规则或分组的查询与写入。恢复配置任务时也先核对 blue Profile，再复用原身份和会话。
-
 在用户明确要求以下任一事项时使用：
 
 - 查询、创建、重命名、重新配置或删除审查清单；
@@ -48,7 +46,7 @@ everyline-cli rule group --help
 
 先复用 `everyline-review` 的首次使用提示、Profile、身份与授权门禁检查；将本 Skill 实际加载的 `metadata.version` 用于版本提示，同一会话不重复提示。固定 `<profile>` 与 `<identity>`，授权与业务命令显式携带 `--profile <profile> --as <identity>`。每条 user 命令复用同一 Device 会话：豆包普通工作任务（含本地电脑）注入同一 `SESSION_ID` 并使用同一初始工作目录，WorkBuddy 注入同一 `CODEBUDDY_SESSION_ID`，AgentKit 保留平台工作区与注入密钥。
 
-记录 `version` 返回的 `updateRequired`，独立配置任务在查询或单次已确认写入及回读完成后更新；组合任务还需等后续审查取得终态、结果已获取且整条业务流程结束，避免两个阶段之间替换 CLI。安装与更新遵守 `everyline-review` 的规则，默认使用 `@qfeius/everyline-cli@latest`；旧 CLI 的 `@blue` 更新目标也按该规则迁移至 `@latest`。npm 渠道和版本号不表示业务环境，更新后仍按实际连接地址校验 blue Profile。
+记录 `version` 返回的 `updateRequired`，独立配置任务在查询或单次已确认写入及回读完成后更新；组合任务还需等后续审查取得终态、结果已获取且整条业务流程结束，避免两个阶段之间替换 CLI。
 
 在每次写入前，再读取将要执行的具体子命令 `--help` 和 CLI 提供的请求结构说明。只使用实时帮助中已注册的命令、参数和请求字段，不凭本文猜测请求体。