@qfeius/everyline-cli 1.0.1 → 1.0.2

package/bin/checksums.txt

@@ -1,6 +1,6 @@
-dabaddbc22850c05b2b1667ffabff5bbd303252f55dcf9b0ab7b639853db8a40  bin/darwin-amd64/everyline-cli
-a146a706aa2c8793dc45c2ab13e19de387fa320c6c185384701df48c55808207  bin/darwin-arm64/everyline-cli
-bd3bd9187ce78321616f20c13f14ad3696b61a93266c21b0089a842e884afaf9  bin/linux-amd64/everyline-cli
-92f3b7374e9a779b156af88bb064ec6dede43b13057c8b41ffd57469fc5bd853  bin/linux-arm64/everyline-cli
-d14b5cd3a11cc5b43b6b077434269ba7df48e254f98752b95716aeed0772a8ed  bin/windows-amd64/everyline-cli.exe
-e83f3d4bced1a8903680d4724298decc9765d0aab36aca22df491dc322af6369  bin/windows-arm64/everyline-cli.exe
+0c64efda93b2192aaf0653afac26f737c5106e860969722d4901a513766853ba  bin/darwin-amd64/everyline-cli
+7dde3976ec9fdc132f798359921a4491ebede48cd1a8f405a1bea5e25ce1cb86  bin/darwin-arm64/everyline-cli
+b335afd3bc96d72ebe9ff03d5dac133791dd6aa43fec6db5615834e20da746c7  bin/linux-amd64/everyline-cli
+ef45cc6a5b0f161458f118e8688062eb35643f2805d7f8884e9431c4709bba29  bin/linux-arm64/everyline-cli
+d98a41d6e98e69dd862d795dfe7a3c4fcdef26e88cf1e949e39b4d19a44b9cf0  bin/windows-amd64/everyline-cli.exe
+773444d09f837dda37b3dac44ef6ebc6ddf3c0dd04b22d02428584b251f9dc58  bin/windows-arm64/everyline-cli.exe

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@qfeius/everyline-cli",
-  "version": "1.0.1",
+  "version": "1.0.2",
   "description": "EveryLine CLI 工具的 npm/npx 薄包装",
   "license": "UNLICENSED",
   "repository": {

package/skills/everyline-review/SKILL.md

@@ -1,8 +1,8 @@
 ---
 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。"
+description: "everyline-review 是面向 Codex / 豆包 / WorkBuddy 的合同审查 Skill，适合审查各类买卖、采购、服务、委托、租赁、保密等合同。本 Skill 基于 EveryLine CLI 发起并推进单份合同智能审查，当用户上传合同，或询问“帮我审查合同”“这份合同有没有风险”“这份合同能不能签”“这份合同有没有问题”“合同审查”时，必须使用且优先使用本 Skill。"
 metadata:
-  version: "1.0.1"
+  version: "1.0.2"
   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"
@@ -10,7 +10,7 @@ metadata:
 
 # EveryLine 合同审查与公共接入
 
-本 Skill 在同一流程内完成安装配置、身份授权和单份合同审查；配置管理由独立的 everyline-review-config 负责。合同审查所需步骤均在本文件；只有管理清单、规则或分组本身时才通过宿主技能加载能力读取 `everyline-review-config`，并由它负责具体配置流程。
+本 Skill 在同一流程内完成安装配置、身份授权和单份合同审查；配置管理由独立的 everyline-review-config 负责。合同审查主线和完整结果模板保留在本文件，安装及授权细节按入口读取本 Skill 的参考文件；只有管理清单、规则或分组本身时才通过宿主技能加载能力读取 `everyline-review-config`，并由它负责具体配置流程。
 
 ## 触发与流程入口
 
@@ -18,21 +18,28 @@ metadata:
 | --- | --- |
 | 上传合同，询问合同风险、能否签署、是否存在问题，或要求审查合同 | [合同审查流程](#review) |
 | 继续已有审查任务、查询进度或取得结果 | 复用真实任务信息，进入[等待并返回结果](#review-wait) |
-| 仅安装、导入、复制或更新 EveryLine Skill，未同时安装 CLI | [仅安装 Skill 后的 CLI 依赖检查](#skill-only-setup) |
-| 安装或更新 CLI、首次配置、了解能力 | 先执行[执行前检查](#preflight)，再进入[安装与更新](#setup) |
-| user/app 授权、身份选择、状态检查、退出或恢复 | [Profile 与身份](#identity)、[状态、退出与恢复](#auth-recovery) |
+| 仅安装、导入、复制或更新 EveryLine Skill，未同时安装 CLI | [仅安装 Skill 后的 CLI 依赖检查](references/setup.md#skill-only-setup) |
+| 安装或更新 CLI、首次配置、了解能力 | 先执行[执行前检查](#preflight)，再进入[安装与更新](references/setup.md#setup) |
+| user/app 授权、身份选择、状态检查、退出或恢复 | [Profile 与身份](#identity)、[状态、退出与恢复](references/auth.md#auth-recovery) |
 | 查询、创建、修改或删除清单、规则、分组 | 通过宿主技能加载能力读取 `everyline-review-config` |
 
-- 仅安装、导入、复制或更新 EveryLine Skill 后，处理安装的 Agent 必须在当前轮结束前主动读取已安装的 `everyline-review/SKILL.md`，并进入[仅安装 Skill 后的 CLI 依赖检查](#skill-only-setup)。触发条件是 Skill 文件就位，不以用户已经发起 CLI 安装为前提。仅复制技能文件不代表 CLI 已就绪；不得把 CLI 检查推迟到新会话或用户再次提出审查请求。宿主不支持自动重载时，通过文件读取能力读取主 Skill 后继续检查；缺少读取或执行能力时，明确说明尚未完成的检查及所需能力。
+- 仅安装、导入、复制或更新 EveryLine Skill 后，处理安装的 Agent 必须在当前轮结束前主动读取已安装的 `everyline-review/SKILL.md`，并进入[仅安装 Skill 后的 CLI 依赖检查](references/setup.md#skill-only-setup)。触发条件是 Skill 文件就位，不以用户已经发起 CLI 安装为前提。仅复制技能文件不代表 CLI 已就绪；不得把 CLI 检查推迟到新会话或用户再次提出审查请求。宿主不支持自动重载时，通过文件读取能力读取主 Skill 后继续检查；缺少读取或执行能力时，明确说明尚未完成的检查及所需能力。
 - 用户只上传单份合同且未指定其他任务时，直接进入审查引导；多个合同候选先选择本次文件。用户明确要求起草、改写、翻译、一般法律咨询或使用其他合同工具时，按其实际目标处理，不由本 Skill 发起审查。
 - “用清单 A 审查合同”属于审查流程中的已有清单选择；“新建或修改清单后审查合同”先读取 `everyline-review-config` 完成配置确认、写入和回读，再携带真实清单 ID 及已有参数继续审查。审查请求本身不代表用户确认配置写入。
 - 各入口共用[执行前检查](#preflight)、[Profile 与身份](#identity)及[通用边界](#boundaries)。遇到安装或鉴权缺口时保留原目标与已确认输入，处理完成后回到中断步骤，不重新询问合同、主体、强度或清单。
 - 本文及 `everyline-review-config` 中以 auth、config、review、checklist、rule 开头的命令均为 everyline-cli 子命令；执行时补全程序名，使用当前宿主实际可读路径和真实返回值替换占位符，不固定个人路径或安装版本。
 
+## 参考文件读取约定
+
+- 安装、升级、迁移、重建、仅安装 Skill 或检查发现 CLI 缺失时，执行相关操作前完整读取 [references/setup.md](references/setup.md)。
+- 进入身份相关配置、状态、授权、恢复或业务步骤前，先读取 [references/auth.md](references/auth.md) 中当前身份与宿主的适用分支；豆包和 WorkBuddy 必须在首次配置或状态命令之前完成会话准备。用户尚未明确身份时，先按本文件的身份选择规则收集选择。
+- 同一任务已读取且文件未变化时复用，不因进入新的步骤反复加载。安装与授权无关的任务不预先读取 setup.md。
+- 主文件中的资源相对路径以本 Skill 根目录解析；参考文件中的链接以该参考文件所在目录解析，从 references/ 返回主文件使用 `../SKILL.md`。引用文件缺失或不可读时先定位并修复资源缺口，未能读取的规则不能靠猜测跳过。
+
 <a id="preflight"></a>
 ## 执行前检查
 
-宿主按当前对话平台判断。豆包的“本地电脑”模式仍属于豆包，和 WorkBuddy 一样使用 Device Grant；操作系统、本机 CLI、loopback 可访问或环境变量缺失都不能作为改走 Codex OAuth 的依据。用户身份确定后，先固定[Device 会话](#device-session)，再执行身份相关的配置、状态和业务命令。
+宿主按当前对话平台判断。豆包的“本地电脑”模式仍属于豆包，和 WorkBuddy 一样使用 Device Grant；操作系统、本机 CLI、loopback 可访问或环境变量缺失都不能作为改走 Codex OAuth 的依据。用户身份确定后，先固定[Device 会话](references/auth.md#device-session)，再执行身份相关的配置、状态和业务命令。
 
 安装、导入、复制或更新 EveryLine Skill 完成文件写入后，以及每个新会话首次使用本 Skill 时，立即检查当前任务执行环境中的 CLI。检查在账号授权之前进行，不等待合同上传，也不依赖 CLI 返回首次安装事件；同一轮已经验证当前环境可用时复用结果。
 
@@ -42,7 +49,7 @@ metadata:
 command -v everyline-cli
 ```
 
-Windows PowerShell 使用 `Get-Command everyline-cli -ErrorAction SilentlyContinue` 完成等价检查。命令不存在时，立即进入[安装与更新](#setup)第 7 条处理缺失，不继续调用 version 或其他 CLI 子命令。命令存在或安装成功后，才执行：
+Windows PowerShell 使用 `Get-Command everyline-cli -ErrorAction SilentlyContinue` 完成等价检查。命令不存在时，立即进入[安装来源与执行](references/setup.md#安装来源与执行)第 7 条处理缺失，不继续调用 version 或其他 CLI 子命令。命令存在或安装成功后，才执行：
 
 ```bash
 everyline-cli version --output json
@@ -58,90 +65,24 @@ everyline-cli auth --help
 - 按 SemVer 比较版本：数字段按数值比较，预发布版本低于同号正式版，忽略构建元数据。仅当 isLatest 非 null 且 checkError 为空时使用 CLI 的最新版本结论；来源包明确包含本 Skill 时才能据其发布版本判断 Skill 是否落后，否则 Skill 的最新状态保持未知。
 - 已确认 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)核对来源并执行一次记住的更新命令。成功后验证版本并结束本轮，以便下一轮加载新版；失败时保留业务结果，报告真实错误，在下一条新业务前处理更新缺口。
+- updateRequired=true 时记录唯一 updateCommand，先完成当前整条业务流程；不得在合同上传、任务创建、轮询、结果获取或同一次配置写入之间更新。业务终态或明确失败、结果已保留且后续 API 调用结束后，按[安装与更新](references/setup.md#setup)核对来源并执行一次记住的更新命令。成功后验证版本并结束本轮，以便下一轮加载新版；失败时保留业务结果，报告真实错误，在下一条新业务前处理更新缺口。
 - firstInstall=true 且 authorizationRequired=true，或事件明确要求首次授权时，按[首次安装强制新授权](#first-install-auth)执行。授权成功前不调用 review、checklist 或 rule；nextAction=authorize 及同一首次安装事件重放均不能被旧 dev token、历史有效期或缓存绕过。
 - 审查前还需核对[审查能力](#review-readiness)；配置管理的具体命令就绪检查在 `everyline-review-config` 中执行。
 
 <a id="setup"></a>
 ## 安装与更新
 
+执行 CLI 安装、更新、迁移、重建或延迟更新前，先完整读取[安装与更新细则](references/setup.md#setup)，按其中的来源选择、执行、验证和完成引导继续。任务中途发现更新时，仍先完成当前整条业务流程。
+
 <a id="skill-only-setup"></a>
 ### 仅安装 Skill 后的 CLI 依赖检查
 
-仅安装、导入、复制或更新 EveryLine Skill，未同时安装 CLI 时，安装 Agent 必须在技能文件就位后、当前任务结束前主动执行[执行前检查](#preflight)，检测当前任务执行环境中的 CLI。此流程由 Skill 安装完成触发，不等待用户另行提出 CLI 安装请求。
-
-CLI 已存在且验证可用时，复用检查结果继续原请求，无需重复安装。CLI 缺失时，按下方“安装来源与执行”第 7 条读取安装文档并自动安装最新正式版；只有宿主权限策略或用户设置要求额外确认时，才明确提示“当前缺少 EveryLine CLI，是否安装最新正式版？”并等待确认。
-
-不得仅报告 Skill 文件安装成功后结束。无法完成检查或安装时，说明实际状态、具体原因及待完成步骤；只有验证通过后才报告 CLI 已就绪。
-
-### 安装来源与执行
-
-执行 npm 安装、迁移、重建或延迟更新时，默认使用下列正常全局安装命令，不设置 EVERYLINE_SKIP_SKILL_INSTALL=1，以便安装器同步两个 Skill 并保留首次安装授权门禁。只有用户明确要求单独安装 CLI 时才为该次进程设置 EVERYLINE_SKIP_SKILL_INSTALL=1；不永久修改环境。CLI 返回的 updateCommand 同样遵守此规则。安装后核对两个 Skill 的实际文件、依赖及宿主加载状态，不依据版本号猜测同步成功。
-
-1. 正式 npm 包名为 @qfeius/everyline-cli，可执行命令为 everyline-cli，本 Skill 名为 everyline-review。按用户本次指定的安装包、版本、发布下载地址或私有源选择目标，不把本文 metadata.version 当作固定安装版本。
-2. 已有宿主可读取的 .tgz 时，直接使用该文件执行下列命令；用户本机路径不等于云端沙箱路径。仅有文件名、不可读取引用或缺少来源时，先取得可用附件、下载地址或正确源，不猜测个人目录。
-   ```bash
-   npm install -g --foreground-scripts --allow-scripts=@qfeius/everyline-cli <实际安装包路径>
-   ```
-3. 用户未指定包、版本或源时，使用官方 npm：
-   ```bash
-   npm install -g --foreground-scripts --allow-scripts=@qfeius/everyline-cli @qfeius/everyline-cli@latest --registry https://registry.npmjs.org
-   ```
-   不因指定包与本地同版本、isLatest=true 或公共源 E404 跳过用户指定的安装。公开源返回 E404 或版本不存在时，报告该源未找到目标，不反复换源、重试或猜下载地址。
-4. 保留 npm prefix、用户指定安装目录、Profile、身份和凭据；使用 --foreground-scripts 展示安装器输出，不添加 --silent，不单独替换二进制。
-5. 只有 npm ls -g --depth=0 确认旧无 scope 包 everyline-cli 占用同一全局命令时，才执行一次带 --force 的新包安装以迁移。新包验证成功后卸载旧 npm 包，再运行下列命令恢复入口并重新验证；任一步失败即停止后续迁移，普通安装不使用 --force。
-   ```bash
-   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 已就绪。
-
-### 验证安装与宿主加载
-
-- 安装或更新成功需有 npm 成功退出、目标 CLI 可执行、版本核对结果，以及两个 Skill 的 SKILL.md 可读取的证据。仅核实 CLI 时只报告 CLI 的实际状态，技能状态单独说明，不笼统报告全部完成。
-- 指定 .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/postinstall 失败：未启动时说明“安装命令尚未启动”；中断且退出结果未确认时标记“待验证”，不假定未改动或已成功。
-- 非权限类进程创建故障最多做一次同环境最小只读探测，例如 pwd。仍失败就停止自动安装尝试，说明阶段、原始错误、是否启动与恢复步骤；不反复等待、变换工具或重跑安装。文件可读取不代表执行环境正常。
-- 明确权限拒绝或拦截时遵循宿主审批，不通过改换执行通道或提权规避。持续环境异常可建议重启当前任务或执行环境，不声称等待几秒必然恢复；用户反馈恢复后先做一次只读探测再继续。
-
-### 首次使用引导
-
-Codex、WorkBuddy 和豆包都按“Skill 文件就位 → 当前环境 CLI 检查 → 缺失时安装或取得必要确认 → 验证 → 回复正文展示结果”执行。安装任务不能停在 Skill 文件复制成功。终端日志或工具 JSON 不代替正文说明。同会话只展示一次；仅安装时放在最终回复，安装后继续授权或业务时在身份选择前展示。
-
-- 已确认本会话首次安装、宿主首次导入且首次运行、用户明确首次使用，或 CLI 明确要求首次配置时，使用下方统一文案。
-- 缺少 firstInstall/authorizationRequired 或字段为 false，不否定已确认的首次安装事实；字段缺失、未登录、无历史任务或无默认身份本身也不构成首次安装信号。
-- 已确认升级时使用[更新完成引导](#update-guidance)；同版本重装不重新触发首次介绍，未完成授权门禁继续遵守。
-- 豆包 ZIP 导入不执行 npm postinstall。Agent 负责安装或导入技能时，应在当前轮读取主 Skill 并立即检查该任务环境中的 CLI；缺失时按第 7 条安装或请求必要确认。纯平台静态导入且没有执行中的 Agent 时，不声称已经完成 CLI 检查；宿主下一次实际读取本 Skill 时立即补做。WorkBuddy 在当前宿主内验证，不要求用户去其他宿主或终端查看完成提示。
-
-只有 CLI 可执行、版本检查及技能文件验证通过后，才展示以下安装完成文案；仅技能文件复制成功时不得展示。CLI 缺失且等待必要确认时，明确展示第 7 条的安装确认提示；未能检查或安装失败时说明真实状态。
-
-原样展示：
-
-EveryLine CLI 已安装完成。目前支持合同审查，以及审查清单、规则和规则分组配置。使用前需要先完成账号授权，我现在可以为你打开授权页面或生成授权链接。
-
-仅要求安装时，展示后等待用户决定是否授权；同次请求已经要求继续授权或业务时，复用该目标，先完成身份选择，授权成功后恢复原步骤。已明确选择身份时不重复询问。
+仅安装、导入、复制或更新 Skill 后，在当前轮结束前进入[Skill-only 依赖检查](references/setup.md#skill-only-setup)；不能只报告文件复制成功或将 CLI 检查推迟到新会话。
 
 <a id="update-guidance"></a>
 ### 更新完成引导
 
-安装验证完成后，原样展示：
-
-EveryLine CLI 已更新完成。目前支持合同审查，以及审查清单、规则和规则分组配置。
-
-复用更新前已确认的 Profile 与身份，按[身份规则](#identity)补齐缺失选择后，执行一次 auth status --profile <profile> --as <identity> --output json。不得从安装退出码、token 文件存在或历史有效期推断状态。
-
-- authenticated=false：原样展示“使用前需要先完成账号授权，我现在可以为你打开授权页面或生成授权链接。”已有登录意愿时继续，否则等待用户决定。
-- authenticated=true：原样展示“当前已存在生效授权，可直接调用cli能力；”。
-- 状态调用失败：报告真实错误，状态保持未知，不展示有效或失效分支。每次更新只展示一次完成文案和一个状态分支。
-- 若更新发生在成功审查同一轮，相关说明在过程消息中展示，最终审查回复仍按[成功结果输出](#review-output)保持统一结构。
+更新和文件验证完成后，按[更新完成引导](references/setup.md#update-guidance)复用已确认身份检查授权，并展示对应完成文案。
 
 <a id="first-install-auth"></a>
 ## 首次安装强制新授权
@@ -149,8 +90,8 @@ EveryLine CLI 已更新完成。目前支持合同审查，以及审查清单、
 当 `version` 返回 `firstInstall=true`、`authorizationRequired=true`，或 stderr 返回 `event=first_install` 时：
 
 1. 先让用户选择 `user/app` 身份，再确定 Profile；可复用已有非敏感 Profile 配置，但不得把旧 token 的本地有效期当作本次授权完成。
-2. 调用 `auth status` 时应看到 `authenticated=false`、`source=first_install` 和机器可读的 `nextAction`；按当前宿主执行下方授权流程。
-3. Codex 本地 user 必须执行一次新的 `auth login`；豆包/WorkBuddy user 必须只执行一次 `auth init --restart` 并在用户确认后执行一次 `auth complete`；app 必须执行一次新的 `auth login --as app`。同一 `eventId` 的首次安装事件在授权完成前可能重放，重放时保留已经生成的 Device 事务和授权入口，不再次执行 `auth init`。WorkBuddy app 登录由用户在自己的终端按下方命令完成。
+2. 调用 `auth status` 时应看到 `authenticated=false`、`source=first_install` 和机器可读的 `nextAction`；按当前宿主执行[授权细则](references/auth.md)中的对应流程。
+3. Codex 本地 user 必须执行一次新的 `auth login`；豆包/WorkBuddy user 必须只执行一次 `auth init --restart` 并在用户确认后执行一次 `auth complete`；app 必须执行一次新的 `auth login --as app`。同一 `eventId` 的首次安装事件在授权完成前可能重放，重放时保留已经生成的 Device 事务和授权入口，不再次执行 `auth init`。WorkBuddy app 登录由用户在自己的终端按[应用授权](references/auth.md#app-auth)中的命令完成。
 4. 不先执行 `auth logout`，也不手工删除 `tokens.json` 或 Device 凭证；新授权成功后由 CLI 覆盖对应凭证并原子解除门禁。
 5. 授权成功后重新执行 `auth status` 和 `version --output json`。只有 `authenticated=true` 且 `authorizationRequired=false` 才恢复原业务步骤。
 
@@ -163,7 +104,7 @@ EveryLine CLI 已更新完成。目前支持合同审查，以及审查清单、
 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 与豆包普通工作任务统一默认 `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 会话变量仍按下文复用。
+5. 身份确定后的授权与业务命令都显式携带 `--profile <profile> --as <identity>`，不依赖当前 Profile 或 Profile 默认身份。版本、帮助及 Profile 管理命令按实时帮助支持的参数调用，不强加未注册的身份选项；适用的 Device 会话变量仍按[固定 Device 会话](references/auth.md#device-session)复用。
 6. 宿主差异只决定 user 授权协议：Codex 本地走 OAuth/PKCE，豆包与 WorkBuddy 走 Device Grant；三者默认环境始终是 prod。
 7. 不因权限、资源可见性或一种身份授权失败而自动切换另一种身份，也不自动改到 dev、test 或 blue。
 
@@ -180,145 +121,32 @@ EveryLine CLI 已更新完成。目前支持合同审查，以及审查清单、
 - 豆包与 WorkBuddy 的 `auth init` 返回 `status=pending` 时，以 `verification_link_text` 作为按钮或 Markdown 链接文字，该字段固定为 `点击授权`；旧版 CLI 缺少该字段时也使用 `点击授权`。不根据历史对话、旧卡片标题或 URL 页面标题另取文案，回复正文中的链接文字必须逐字一致。
 - `<FULL_AUTHORIZATION_URL>` 必须用本次 CLI 返回值逐字替换，保留从 `https://` 到最后一个 query 参数的全部字符，不省略、解码、重拼或删除参数。只隐藏展示文字，不改动链接目标。
 - 链接生成后由用户主动点击跳转。Agent 不代替用户打开页面，不为生成另一种展示形式重启授权，也不在按钮或 Markdown 链接之外重复输出同一个裸 URL。
-- app 授权没有浏览器授权链接；用户选择 app 后按下方 app ID 与隐藏输入 app secret 的流程执行，不生成虚假的“点击授权”按钮。
+- app 授权没有浏览器授权链接；用户选择 app 后按[应用授权](references/auth.md#app-auth)中的 app ID 与隐藏输入 app secret 流程执行，不生成虚假的“点击授权”按钮。
 
 <a id="user-auth"></a>
 ## user 授权
 
-豆包与 WorkBuddy 先按“固定 Device 会话”准备运行时，再执行；这里及后文的每条 CLI 命令都必须携带已固定的会话变量：
-
-```bash
-everyline-cli auth status --profile <profile> --as user --output json
-```
-
-只有 `authenticated=true` 表示授权有效。未授权时按宿主选择流程：
-
-| 宿主 | user 授权方式 | 运行时要求 |
-| --- | --- | --- |
-| Codex 本地任务 | `auth login` OAuth/PKCE | CLI 与浏览器共享本机 loopback |
-| 豆包 AgentKit / Skills Sandbox | `auth init` + `auth complete` Device Grant | `SKILL_SESSION_WORKSPACE` 和平台注入的 `EVERYLINE_CLI_CREDENTIAL_KEY_V1` |
-| 豆包普通工作任务（含“本地电脑”模式） | `auth init` + `auth complete` Device Grant | 首次 `auth status` 前固定 `SESSION_ID`，宿主缺失时只生成一次；每条命令显式传入并从同一初始工作目录执行 |
-| WorkBuddy | `auth init` + `auth complete` Device Grant | 同一授权事务内固定的 `CODEBUDDY_SESSION_ID` 和系统凭证库 |
-
-### Codex 本地 OAuth
-
-读取 `auth login --help`，执行：
-
-```bash
-everyline-cli auth login --profile <profile> --as user --no-open-browser --timeout 3m
-```
-
-该命令会先读取当前 authorization server metadata 的 `registration_endpoint`，通过该端点动态注册浏览器 public client，再使用返回的 `client_id` 发起 OAuth/PKCE；即使 Profile 中留有旧 `oauth_client_id`，本次显式登录也会用新返回值替换它。Agent 不单独调用注册接口，不猜测注册路径，也不复用或改写输出中的 client ID。浏览器 client 与 `oauth_device_client_id` 分开保存，Codex 登录不覆盖 Device client。
-
-Agent 保持该命令在同一个运行会话中等待 loopback callback，从 CLI 输出取得完整授权 URL，并按“点击授权入口”展示 `[点击授权](<FULL_AUTHORIZATION_URL>)`。用户主动点击并在浏览器完成授权；Agent 不调用系统浏览器打开命令。工具执行应保留后台会话，或提供至少三分钟的进程存活时间；取得链接后及时展示，工具短暂返回不代表 CLI 已退出。保持同一次登录会话，不为切换展示方式重启登录。
-
-### 豆包与 WorkBuddy Device Grant
-
-豆包沙箱与用户本机浏览器不共享网络命名空间；用户浏览器中的 `127.0.0.1:8000` 指向用户本机。豆包和 WorkBuddy Device 运行时不得执行 `auth login --profile <profile> --as user`，也不得等待 loopback callback。豆包“本地电脑”模式同样遵循此规则，不因 CLI 与浏览器都在本机而切换到 OAuth/PKCE。
-
-固定流程为：CLI 执行 `auth init` → 将完整 HTTPS 授权链接生成为“点击授权”入口 → 用户主动点击并在任意浏览器批准 → 用户在新消息中确认“已授权” → CLI 执行一次 `auth complete` 查询账号服务并保存凭证。
+执行 user 身份的配置、状态、授权或恢复命令前，先读取[用户授权细则](references/auth.md#user-auth)及其中当前宿主的准备要求。Codex 本地使用 OAuth/PKCE，豆包和 WorkBuddy 使用 Device Grant；授权成功后继续原业务步骤。
 
 <a id="device-session"></a>
 ### 固定 Device 会话
 
-豆包普通工作任务（含“本地电脑”模式）在首次 `auth status` 前固定 `SESSION_ID` 和任务初始工作目录：优先复用宿主已有的稳定 `SESSION_ID`；宿主未提供时只生成一次 UUID，保存为当前任务上下文。不要每次命令都重新生成，也不要仅在一次 shell 中 `export` 后假定后续工具调用会继承。此后 `config`、`auth status`、`auth init`、`auth complete`、退出及所有 user 业务命令都显式传入同一 `SESSION_ID`，工具的工作目录始终设置为同一初始目录。审查或配置管理恢复执行时也必须携带这两个值。
-
-```bash
-# 各次工具调用的工作目录均为已记录的任务初始目录；占位符复用同一个已生成值。
-SESSION_ID=<same-session-id> everyline-cli auth status --profile <profile> --as user --output json
-SESSION_ID=<same-session-id> everyline-cli auth init --profile <profile> --as user --output json
-# 用户在新消息中确认已授权后：
-SESSION_ID=<same-session-id> everyline-cli auth complete --profile <profile> --as user --output json
-SESSION_ID=<same-session-id> everyline-cli auth status --profile <profile> --as user --output json
-```
-
-豆包 AgentKit / Skills Sandbox 已提供 `SKILL_SESSION_WORKSPACE` 时，保留平台工作区与注入密钥，不用生成的 `SESSION_ID` 替换该模式。运行时缺失提示应通过补齐并复用会话变量解决；豆包不得照抄缺少会话变量时返回的本地 `auth login` 建议。`source=cache` 的历史本机 OAuth 状态不作为豆包 Device 授权成功依据；准备好运行时后以 `source=device` 查询当前会话状态。
-
-WorkBuddy 在第一次 `auth init` 前取得并冻结一个非敏感的 `CODEBUDDY_SESSION_ID`：优先记录宿主已有的稳定值；宿主未提供时只生成一次，并把该值保留为当前授权事务状态。首次 `auth status` 之前也必须完成此准备，避免查询到本地 OAuth 缓存。`auth init`、`auth complete` 和随后的 `auth status` 都显式复用完全相同的值，不使用每次命令都会变化的通用 `SESSION_ID`。等价调用形式如下，其中两处 `<same-session-id>` 必须逐字相同：
-
-```bash
-CODEBUDDY_SESSION_ID=<same-session-id> everyline-cli auth init --profile <profile> --as user --output json
-CODEBUDDY_SESSION_ID=<same-session-id> everyline-cli auth complete --profile <profile> --as user --output json
-```
-
-如果 `auth complete` 返回“没有待完成的 Device 授权”，先恢复 `auth init` 使用的原 `CODEBUDDY_SESSION_ID` 并重试一次 `auth complete`；这次本地存储未命中的失败没有请求 token endpoint，不计作重复兑换。不得因此直接执行 `auth init --restart`。只有 CLI 明确返回 `denied`、`expired` 或 `invalid_grant`，并且用户同意重新授权时，才开始新事务；原标识已经丢失时先如实说明事务状态丢失并等待用户决定。
-
-豆包遇到同样的本地事务未命中时，先恢复原 `SESSION_ID` 和初始工作目录，再重试一次 `auth complete`，遵循相同的新事务规则。
-
-### 发起与完成 Device 授权
-
-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`。首次安装门禁期间执行：
-
-```bash
-everyline-cli auth init --restart --profile <profile> --as user --output json
-```
-
-非首次安装的普通未授权流程执行一次：
-
-```bash
-everyline-cli auth init --profile <profile> --as user --output json
-```
-
-- 将 `verification_uri_complete` 作为不可拆分的完整 HTTPS URL，按“点击授权入口”生成 `[点击授权](<verification_uri_complete>)`；展示文字可以隐藏 URL，但链接目标必须逐字一致，不省略、拆分、解码或重拼 query。
-- `auth init` 返回 `reused=true` 表示复用了已经存在的 Device 事务；同一会话已经展示过该链接时不再次生成按钮、链接或浏览器页面。首次安装事件重放、状态复查或工具重试都不得触发第二次 `auth init --restart`。
-- 展示链接后结束当前轮次。只有用户在新消息中明确表示已完成浏览器授权，才执行一次 `auth complete`。
-- `pending` 表示仍待用户完成；结束本轮，不持续轮询。
-- `succeeded` 后重新执行 `auth status`，再继续被中断的业务步骤一次。
-- `denied`、`expired`、`invalid_grant` 先说明真实状态；用户明确同意重新授权后使用 `auth init --restart`。
-- `uncertain` 不重复兑换同一个 device code；保留状态并停止当前业务操作。
-- metadata 缺少 `device_authorization_endpoint` 时原样报告认证服务能力缺口，不在远端沙箱回退到 loopback 登录，也不猜测 endpoint 或 client ID。
-
-Device code、access token、refresh token 和加密密钥不进入对话、日志或普通配置。`EVERYLINE_CLI_CREDENTIAL_KEY_V1` 由豆包运行平台稳定注入，不在会话中临时生成或展示。
+豆包和 WorkBuddy 在首次身份相关配置或状态查询前，先按[固定 Device 会话](references/auth.md#device-session)准备并保存当前宿主会话标识与工作目录，后续命令复用；已有授权也不能跳过此准备。
 
 <a id="app-auth"></a>
 ## app 授权
 
-用户已选择 app 后，先按下方顺序固定 app ID 和 Profile，再执行 `auth status --profile <profile> --as app --output json`。未授权时读取 `auth login --help`，只采用帮助中真实存在的安全入口：
-
-- app 授权先取得并固定非敏感的 app ID，再进入 app secret 输入；两个连续阶段的顺序不得颠倒。当前消息和目标 Profile 都没有 app ID 时，只询问一次 app ID；该轮不同时请求 app secret。已有唯一 app ID 时直接复用，不重复询问。
-- 取得 app ID 后先创建或校验目标 Profile，再查询 app 授权状态。只有 `authenticated=false` 时才发起一次 `auth login --as app`；同一次登录事务只输入一次 app secret。登录命令结束后只执行一次 `auth status` 验证，不再次启动登录或要求第二次输入 secret。
-- 登录失败时保留已固定的 Profile 和 app ID，报告原始错误后结束本次尝试；不自动重跑 `auth login`。只有用户随后明确要求重试时才开始一笔新的登录事务，并在该新事务中输入一次 app secret。
-- Codex 本地在 app ID 固定后，让用户在自己的终端通过 `--app-secret-stdin` 隐藏输入一次；豆包在 app ID 固定后使用平台密钥入口完成一次安全输入或注入，再由 Agent 发起一次登录；WorkBuddy 按下方专用终端命令执行。三个宿主都不在对话里收集 app secret。
-- WorkBuddy 不使用对话文字输入、`AskUserQuestion`、选项卡或 Agent 捕获的 stdin 收集 app secret。取得非敏感的 Profile、app ID 和当前 WorkBuddy Node `bin` 目录后，把下面的一行命令替换成真实值并完整展示，让用户在自己的 WorkBuddy 终端亲自执行，然后结束当前轮等待用户确认：
-
-```bash
-export PATH=<WORKBUDDY_NODE_BIN>:$PATH && everyline-cli auth login --profile <profile> --as app --app-id <app-id> --app-secret-stdin
-```
-
-- 命令启动后 CLI 显示 `App secret:`，用户直接输入并按回车；终端不回显字符。Agent 不代为执行这条登录命令，不读取、转发或复述输入内容。
-- 用户回复已完成后，只执行 `auth status --profile <profile> --as app --output json` 验证；以 `authenticated=true` 为成功依据，不要求用户提供登录输出。
-- `<WORKBUDDY_NODE_BIN>` 使用当前 WorkBuddy 实际 Node 可执行文件所在目录，例如 `/Users/<user>/.workbuddy/binaries/node/versions/<version>/bin`，不固定用户名或 Node 版本。
-- Codex 本地或 CI 仍可使用由用户直接操作的隐藏输入或管道形式的 `--app-secret-stdin`；Agent 捕获 stdin 时让用户在自己的终端完成输入。
-- 需要重新输入 secret 时，只让用户在自己的终端或平台密钥入口操作；不得要求用户在对话中提供、粘贴或转述 app secret，也不得以“告诉我如何获取”为由索取其内容。
-- 平台托管网页或剪贴板入口仅在实时帮助明确注册且用户选择后使用。
-- app secret 不放入命令参数、普通环境变量、输入 JSON、日志或对话。
-- 持久化只交给 CLI 支持的安全存储；登录后再次以 `authenticated=true` 判定成功。
-- user 与 app 凭据按身份独立保存；发起 app 授权不得先调用 user 的 `auth logout`。发起或重试 app 授权只显式使用 `--as app`，也不得把退出登录当作身份切换步骤。
-- app token 过期只表示当前 token 不可继续使用；不推断凭据已变更或轮换，也不证明已保存的 app ID 或 app secret 无效。
-- 服务端返回 `http=200 code=10003 msg=invalid param` 时原样报告通用参数错误及已有 request ID；除非 CLI 结构化结果明确指出具体凭据字段，不得将其归因为 app ID 或 app secret 错误。
-- app 授权失败后保持原 Profile 和 app 身份，不自动建议改用其他 Profile 或 user 身份；下一步仅提示用户在自己的终端通过实时帮助确认的安全入口重试，或等待用户主动指定新的 Profile/身份。
+执行 app 身份配置、状态查询或登录前，先读取[应用授权细则](references/auth.md#app-auth)，按原顺序处理 app ID、Profile、授权状态与安全凭据输入。
 
 <a id="auth-recovery"></a>
 ## 状态、退出与恢复
 
-- 状态：只展示身份、授权状态、必要到期状态和下一步，不展示凭据来源、存储路径或敏感错误上下文。
-- 退出：只有用户明确要求时执行对应身份的 `auth logout`；先读取帮助，执行后回读状态。
-- 未授权或凭据过期：原身份已经由用户在本次流程中明确选择时继续该身份；否则先完成 user/app 单选再重新授权，成功后只重试原业务操作一次。
-- user Token 进入五分钟刷新窗口且刷新失败、或明确过期时，保留当前 Profile、user 身份和宿主会话，重新生成一次授权链接供用户手动登录。Codex 执行一次 `auth login --profile <profile> --as user --no-open-browser --timeout 3m`，按上节方式保留进程并及时展示链接；豆包/WorkBuddy 按错误提示执行一次 `auth init --restart --profile <profile> --as user --output json`，按本 Skill 的授权入口规则展示新返回的完整 URL，待用户在新消息中确认完成后执行一次 `auth complete`。
-- 用户已明确要求“过期后重新生成授权链接手动登录”时直接按该策略恢复，不重复确认重新授权意愿。恢复操作尚未开始时按错误提示执行一次 --restart；已生成待完成事务后复用原链接，后续只执行 auth complete，只有该事务明确为 `expired`、`denied` 或 `invalid_grant` 时才执行一次 `auth init --restart`，不因状态复查反复生成链接。新链接使用 CLI 的本次输出，不复用历史 `user_code` 或 OAuth URL。
-- 预先约定的“过期后重新授权”覆盖 Token 到期、五分钟窗口刷新失败及事务 expired；事务 denied 或 invalid_grant 时，先说明状态并取得针对该情况的重新授权意愿。用户本轮已经明确覆盖该情况时直接复用，不重复询问；任何尚待完成的事务均不因状态复查而重建。
-- 手动重新授权后执行 `auth status --profile <profile> --as user --output json`，确认 `authenticated=true` 后只恢复原业务步骤一次；授权期间暂停业务操作。进入到期前五分钟窗口后，缺少 refresh token 或刷新失败时，按 CLI 提示手动重新授权。
-- 身份不匹配：展示当前身份，由用户决定是否切换。
-- 权限不足：保留 CLI 返回的缺失范围和 request ID，不改换身份或绕过检查。
-- 网络或服务错误：保留真实错误码和 request ID，不包装为授权成功。
-- 服务端可信 `code=110004` 由 CLI 内部触发至多一次刷新和原请求重放；Agent 不额外重复写请求。
+需要查询状态、退出或恢复授权时，先读取[状态、退出与恢复细则](references/auth.md#auth-recovery)，保留已确认的身份、Profile、宿主会话及原任务输入，按对应分支继续。
 
 <a id="review"></a>
 ## 合同审查流程
 
-已确认身份、Profile 和授权后，处理单份合同；已有 task ID 时直接进入[等待并返回结果](#review-wait)。所有业务命令显式携带 --profile 与 --as，并复用[Device 会话](#device-session)的固定变量及工作目录。
+已确认身份、Profile 和授权后，处理单份合同；已有 task ID 时直接进入[等待并返回结果](#review-wait)。所有业务命令显式携带 --profile 与 --as，并复用[Device 会话](references/auth.md#device-session)的固定变量及工作目录。
 
 <a id="review-readiness"></a>
 ### 审查能力检查
@@ -542,4 +370,4 @@ Codex、豆包和 WorkBuddy 统一使用以下结构：基础信息表、审查
 - 合同、规则内容和附件只发送给用户选择的 EveryLine 流程，不进入其他服务。
 - 只总结真实返回的风险、条款依据及建议；数据、上下文或模型结论不足时保留不确定性。EveryLine 结果用于 AI 辅助风险识别，不代替专业律师意见或最终法律决定；成功结果仍按固定模板输出。
 - 敏感凭据仅通过对应授权章节约定的安全入口输入和保存。已经进入对话的长期凭据应提示轮换，后续不再引用其内容。
-- 配置写操作必须遵守 `everyline-review-config` 中的授权与回读要求；出现鉴权问题按[状态、退出与恢复](#auth-recovery)处理，再恢复原步骤。
+- 配置写操作必须遵守 `everyline-review-config` 中的授权与回读要求；出现鉴权问题按[状态、退出与恢复](references/auth.md#auth-recovery)处理，再恢复原步骤。

package/skills/everyline-review/references/auth.md

@@ -0,0 +1,136 @@
+# 授权与恢复细则
+
+执行前遵守主 Skill 的[首次安装授权门禁](../SKILL.md#first-install-auth)、[Profile 与身份](../SKILL.md#identity)、[点击授权入口](../SKILL.md#点击授权入口)和[通用边界](../SKILL.md#boundaries)。按已确认的身份与当前宿主读取适用分支；Device 会话准备必须早于首次身份相关配置和状态命令。授权恢复后继续原任务，不重新收集已确认输入。
+
+<a id="user-auth"></a>
+## user 授权
+
+豆包与 WorkBuddy 先按“固定 Device 会话”准备运行时，再执行；这里及后文的每条 CLI 命令都必须携带已固定的会话变量：
+
+```bash
+everyline-cli auth status --profile <profile> --as user --output json
+```
+
+只有 `authenticated=true` 表示授权有效。未授权时按宿主选择流程：
+
+| 宿主 | user 授权方式 | 运行时要求 |
+| --- | --- | --- |
+| Codex 本地任务 | `auth login` OAuth/PKCE | CLI 与浏览器共享本机 loopback |
+| 豆包 AgentKit / Skills Sandbox | `auth init` + `auth complete` Device Grant | `SKILL_SESSION_WORKSPACE` 和平台注入的 `EVERYLINE_CLI_CREDENTIAL_KEY_V1` |
+| 豆包普通工作任务（含“本地电脑”模式） | `auth init` + `auth complete` Device Grant | 首次 `auth status` 前固定 `SESSION_ID`，宿主缺失时只生成一次；每条命令显式传入并从同一初始工作目录执行 |
+| WorkBuddy | `auth init` + `auth complete` Device Grant | 同一授权事务内固定的 `CODEBUDDY_SESSION_ID` 和系统凭证库 |
+
+### Codex 本地 OAuth
+
+读取 `auth login --help`，执行：
+
+```bash
+everyline-cli auth login --profile <profile> --as user --no-open-browser --timeout 3m
+```
+
+该命令会先读取当前 authorization server metadata 的 `registration_endpoint`，通过该端点动态注册浏览器 public client，再使用返回的 `client_id` 发起 OAuth/PKCE；即使 Profile 中留有旧 `oauth_client_id`，本次显式登录也会用新返回值替换它。Agent 不单独调用注册接口，不猜测注册路径，也不复用或改写输出中的 client ID。浏览器 client 与 `oauth_device_client_id` 分开保存，Codex 登录不覆盖 Device client。
+
+Agent 保持该命令在同一个运行会话中等待 loopback callback，从 CLI 输出取得完整授权 URL，并按“点击授权入口”展示 `[点击授权](<FULL_AUTHORIZATION_URL>)`。用户主动点击并在浏览器完成授权；Agent 不调用系统浏览器打开命令。工具执行应保留后台会话，或提供至少三分钟的进程存活时间；取得链接后及时展示，工具短暂返回不代表 CLI 已退出。保持同一次登录会话，不为切换展示方式重启登录。
+
+### 豆包与 WorkBuddy Device Grant
+
+豆包沙箱与用户本机浏览器不共享网络命名空间；用户浏览器中的 `127.0.0.1:8000` 指向用户本机。豆包和 WorkBuddy Device 运行时不得执行 `auth login --profile <profile> --as user`，也不得等待 loopback callback。豆包“本地电脑”模式同样遵循此规则，不因 CLI 与浏览器都在本机而切换到 OAuth/PKCE。
+
+固定流程为：CLI 执行 `auth init` → 将完整 HTTPS 授权链接生成为“点击授权”入口 → 用户主动点击并在任意浏览器批准 → 用户在新消息中确认“已授权” → CLI 执行一次 `auth complete` 查询账号服务并保存凭证。
+
+<a id="device-session"></a>
+### 固定 Device 会话
+
+豆包普通工作任务（含“本地电脑”模式）在首次 `auth status` 前固定 `SESSION_ID` 和任务初始工作目录：优先复用宿主已有的稳定 `SESSION_ID`；宿主未提供时只生成一次 UUID，保存为当前任务上下文。不要每次命令都重新生成，也不要仅在一次 shell 中 `export` 后假定后续工具调用会继承。此后 `config`、`auth status`、`auth init`、`auth complete`、退出及所有 user 业务命令都显式传入同一 `SESSION_ID`，工具的工作目录始终设置为同一初始目录。审查或配置管理恢复执行时也必须携带这两个值。
+
+```bash
+# 各次工具调用的工作目录均为已记录的任务初始目录；占位符复用同一个已生成值。
+SESSION_ID=<same-session-id> everyline-cli auth status --profile <profile> --as user --output json
+SESSION_ID=<same-session-id> everyline-cli auth init --profile <profile> --as user --output json
+# 用户在新消息中确认已授权后：
+SESSION_ID=<same-session-id> everyline-cli auth complete --profile <profile> --as user --output json
+SESSION_ID=<same-session-id> everyline-cli auth status --profile <profile> --as user --output json
+```
+
+豆包 AgentKit / Skills Sandbox 已提供 `SKILL_SESSION_WORKSPACE` 时，保留平台工作区与注入密钥，不用生成的 `SESSION_ID` 替换该模式。运行时缺失提示应通过补齐并复用会话变量解决；豆包不得照抄缺少会话变量时返回的本地 `auth login` 建议。`source=cache` 的历史本机 OAuth 状态不作为豆包 Device 授权成功依据；准备好运行时后以 `source=device` 查询当前会话状态。
+
+WorkBuddy 在第一次 `auth init` 前取得并冻结一个非敏感的 `CODEBUDDY_SESSION_ID`：优先记录宿主已有的稳定值；宿主未提供时只生成一次，并把该值保留为当前授权事务状态。首次 `auth status` 之前也必须完成此准备，避免查询到本地 OAuth 缓存。`auth init`、`auth complete` 和随后的 `auth status` 都显式复用完全相同的值，不使用每次命令都会变化的通用 `SESSION_ID`。等价调用形式如下，其中两处 `<same-session-id>` 必须逐字相同：
+
+```bash
+CODEBUDDY_SESSION_ID=<same-session-id> everyline-cli auth init --profile <profile> --as user --output json
+CODEBUDDY_SESSION_ID=<same-session-id> everyline-cli auth complete --profile <profile> --as user --output json
+```
+
+如果 `auth complete` 返回“没有待完成的 Device 授权”，先恢复 `auth init` 使用的原 `CODEBUDDY_SESSION_ID` 并重试一次 `auth complete`；这次本地存储未命中的失败没有请求 token endpoint，不计作重复兑换。不得因此直接执行 `auth init --restart`。只有 CLI 明确返回 `denied`、`expired` 或 `invalid_grant`，并且用户同意重新授权时，才开始新事务；原标识已经丢失时先如实说明事务状态丢失并等待用户决定。
+
+豆包遇到同样的本地事务未命中时，先恢复原 `SESSION_ID` 和初始工作目录，再重试一次 `auth complete`，遵循相同的新事务规则。
+
+### 发起与完成 Device 授权
+
+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`。首次安装门禁期间执行：
+
+```bash
+everyline-cli auth init --restart --profile <profile> --as user --output json
+```
+
+非首次安装的普通未授权流程执行一次：
+
+```bash
+everyline-cli auth init --profile <profile> --as user --output json
+```
+
+- 将 `verification_uri_complete` 作为不可拆分的完整 HTTPS URL，按“点击授权入口”生成 `[点击授权](<verification_uri_complete>)`；展示文字可以隐藏 URL，但链接目标必须逐字一致，不省略、拆分、解码或重拼 query。
+- `auth init` 返回 `reused=true` 表示复用了已经存在的 Device 事务；同一会话已经展示过该链接时不再次生成按钮、链接或浏览器页面。首次安装事件重放、状态复查或工具重试都不得触发第二次 `auth init --restart`。
+- 展示链接后结束当前轮次。只有用户在新消息中明确表示已完成浏览器授权，才执行一次 `auth complete`。
+- `pending` 表示仍待用户完成；结束本轮，不持续轮询。
+- `succeeded` 后重新执行 `auth status`，再继续被中断的业务步骤一次。
+- `denied`、`expired`、`invalid_grant` 先说明真实状态；用户明确同意重新授权后使用 `auth init --restart`。
+- `uncertain` 不重复兑换同一个 device code；保留状态并停止当前业务操作。
+- metadata 缺少 `device_authorization_endpoint` 时原样报告认证服务能力缺口，不在远端沙箱回退到 loopback 登录，也不猜测 endpoint 或 client ID。
+
+Device code、access token、refresh token 和加密密钥不进入对话、日志或普通配置。`EVERYLINE_CLI_CREDENTIAL_KEY_V1` 由豆包运行平台稳定注入，不在会话中临时生成或展示。
+
+<a id="app-auth"></a>
+## app 授权
+
+用户已选择 app 后，先按下方顺序固定 app ID 和 Profile，再执行 `auth status --profile <profile> --as app --output json`。未授权时读取 `auth login --help`，只采用帮助中真实存在的安全入口：
+
+- app 授权先取得并固定非敏感的 app ID，再进入 app secret 输入；两个连续阶段的顺序不得颠倒。当前消息和目标 Profile 都没有 app ID 时，只询问一次 app ID；该轮不同时请求 app secret。已有唯一 app ID 时直接复用，不重复询问。
+- 取得 app ID 后先创建或校验目标 Profile，再查询 app 授权状态。只有 `authenticated=false` 时才发起一次 `auth login --as app`；同一次登录事务只输入一次 app secret。登录命令结束后只执行一次 `auth status` 验证，不再次启动登录或要求第二次输入 secret。
+- 登录失败时保留已固定的 Profile 和 app ID，报告原始错误后结束本次尝试；不自动重跑 `auth login`。只有用户随后明确要求重试时才开始一笔新的登录事务，并在该新事务中输入一次 app secret。
+- Codex 本地在 app ID 固定后，让用户在自己的终端通过 `--app-secret-stdin` 隐藏输入一次；豆包在 app ID 固定后使用平台密钥入口完成一次安全输入或注入，再由 Agent 发起一次登录；WorkBuddy 按下方专用终端命令执行。三个宿主都不在对话里收集 app secret。
+- WorkBuddy 不使用对话文字输入、`AskUserQuestion`、选项卡或 Agent 捕获的 stdin 收集 app secret。取得非敏感的 Profile、app ID 和当前 WorkBuddy Node `bin` 目录后，把下面的一行命令替换成真实值并完整展示，让用户在自己的 WorkBuddy 终端亲自执行，然后结束当前轮等待用户确认：
+
+```bash
+export PATH=<WORKBUDDY_NODE_BIN>:$PATH && everyline-cli auth login --profile <profile> --as app --app-id <app-id> --app-secret-stdin
+```
+
+- 命令启动后 CLI 显示 `App secret:`，用户直接输入并按回车；终端不回显字符。Agent 不代为执行这条登录命令，不读取、转发或复述输入内容。
+- 用户回复已完成后，只执行 `auth status --profile <profile> --as app --output json` 验证；以 `authenticated=true` 为成功依据，不要求用户提供登录输出。
+- `<WORKBUDDY_NODE_BIN>` 使用当前 WorkBuddy 实际 Node 可执行文件所在目录，例如 `/Users/<user>/.workbuddy/binaries/node/versions/<version>/bin`，不固定用户名或 Node 版本。
+- Codex 本地或 CI 仍可使用由用户直接操作的隐藏输入或管道形式的 `--app-secret-stdin`；Agent 捕获 stdin 时让用户在自己的终端完成输入。
+- 需要重新输入 secret 时，只让用户在自己的终端或平台密钥入口操作；不得要求用户在对话中提供、粘贴或转述 app secret，也不得以“告诉我如何获取”为由索取其内容。
+- 平台托管网页或剪贴板入口仅在实时帮助明确注册且用户选择后使用。
+- app secret 不放入命令参数、普通环境变量、输入 JSON、日志或对话。
+- 持久化只交给 CLI 支持的安全存储；登录后再次以 `authenticated=true` 判定成功。
+- user 与 app 凭据按身份独立保存；发起 app 授权不得先调用 user 的 `auth logout`。发起或重试 app 授权只显式使用 `--as app`，也不得把退出登录当作身份切换步骤。
+- app token 过期只表示当前 token 不可继续使用；不推断凭据已变更或轮换，也不证明已保存的 app ID 或 app secret 无效。
+- 服务端返回 `http=200 code=10003 msg=invalid param` 时原样报告通用参数错误及已有 request ID；除非 CLI 结构化结果明确指出具体凭据字段，不得将其归因为 app ID 或 app secret 错误。
+- app 授权失败后保持原 Profile 和 app 身份，不自动建议改用其他 Profile 或 user 身份；下一步仅提示用户在自己的终端通过实时帮助确认的安全入口重试，或等待用户主动指定新的 Profile/身份。
+
+<a id="auth-recovery"></a>
+## 状态、退出与恢复
+
+- 状态：只展示身份、授权状态、必要到期状态和下一步，不展示凭据来源、存储路径或敏感错误上下文。
+- 退出：只有用户明确要求时执行对应身份的 `auth logout`；先读取帮助，执行后回读状态。
+- 未授权或凭据过期：原身份已经由用户在本次流程中明确选择时继续该身份；否则先完成 user/app 单选再重新授权，成功后只重试原业务操作一次。
+- user Token 进入五分钟刷新窗口且刷新失败、或明确过期时，保留当前 Profile、user 身份和宿主会话，重新生成一次授权链接供用户手动登录。Codex 执行一次 `auth login --profile <profile> --as user --no-open-browser --timeout 3m`，按上节方式保留进程并及时展示链接；豆包/WorkBuddy 按错误提示执行一次 `auth init --restart --profile <profile> --as user --output json`，按本 Skill 的授权入口规则展示新返回的完整 URL，待用户在新消息中确认完成后执行一次 `auth complete`。
+- 用户已明确要求“过期后重新生成授权链接手动登录”时直接按该策略恢复，不重复确认重新授权意愿。恢复操作尚未开始时按错误提示执行一次 --restart；已生成待完成事务后复用原链接，后续只执行 auth complete，只有该事务明确为 `expired`、`denied` 或 `invalid_grant` 时才执行一次 `auth init --restart`，不因状态复查反复生成链接。新链接使用 CLI 的本次输出，不复用历史 `user_code` 或 OAuth URL。
+- 预先约定的“过期后重新授权”覆盖 Token 到期、五分钟窗口刷新失败及事务 expired；事务 denied 或 invalid_grant 时，先说明状态并取得针对该情况的重新授权意愿。用户本轮已经明确覆盖该情况时直接复用，不重复询问；任何尚待完成的事务均不因状态复查而重建。
+- 手动重新授权后执行 `auth status --profile <profile> --as user --output json`，确认 `authenticated=true` 后只恢复原业务步骤一次；授权期间暂停业务操作。进入到期前五分钟窗口后，缺少 refresh token 或刷新失败时，按 CLI 提示手动重新授权。
+- 身份不匹配：展示当前身份，由用户决定是否切换。
+- 权限不足：保留 CLI 返回的缺失范围和 request ID，不改换身份或绕过检查。
+- 网络或服务错误：保留真实错误码和 request ID，不包装为授权成功。
+- 服务端可信 `code=110004` 由 CLI 内部触发至多一次刷新和原请求重放；Agent 不额外重复写请求。

package/skills/everyline-review/references/setup.md

@@ -0,0 +1,84 @@
+# 安装与更新细则
+
+本文件承接主 Skill 的安装与更新入口。执行前遵守[执行前检查](../SKILL.md#preflight)、[Profile 与身份](../SKILL.md#identity)和[通用边界](../SKILL.md#boundaries)；完成后返回原任务。
+
+<a id="setup"></a>
+## 安装与更新
+
+<a id="skill-only-setup"></a>
+### 仅安装 Skill 后的 CLI 依赖检查
+
+仅安装、导入、复制或更新 EveryLine Skill，未同时安装 CLI 时，安装 Agent 必须在技能文件就位后、当前任务结束前主动执行[执行前检查](../SKILL.md#preflight)，检测当前任务执行环境中的 CLI。此流程由 Skill 安装完成触发，不等待用户另行提出 CLI 安装请求。
+
+CLI 已存在且验证可用时，复用检查结果继续原请求，无需重复安装。CLI 缺失时，按下方“安装来源与执行”第 7 条读取安装文档并自动安装最新正式版；只有宿主权限策略或用户设置要求额外确认时，才明确提示“当前缺少 EveryLine CLI，是否安装最新正式版？”并等待确认。
+
+不得仅报告 Skill 文件安装成功后结束。无法完成检查或安装时，说明实际状态、具体原因及待完成步骤；只有验证通过后才报告 CLI 已就绪。
+
+### 安装来源与执行
+
+执行 npm 安装、迁移、重建或延迟更新时，默认使用下列正常全局安装命令，不设置 EVERYLINE_SKIP_SKILL_INSTALL=1，以便安装器同步两个 Skill 并保留首次安装授权门禁。只有用户明确要求单独安装 CLI 时才为该次进程设置 EVERYLINE_SKIP_SKILL_INSTALL=1；不永久修改环境。CLI 返回的 updateCommand 同样遵守此规则。安装后核对两个 Skill 的实际文件、依赖及宿主加载状态，不依据版本号猜测同步成功。
+
+1. 正式 npm 包名为 @qfeius/everyline-cli，可执行命令为 everyline-cli，本 Skill 名为 everyline-review。按用户本次指定的安装包、版本、发布下载地址或私有源选择目标，不把[主 Skill](../SKILL.md) 的 metadata.version 当作固定安装版本。
+2. 已有宿主可读取的 .tgz 时，直接使用该文件执行下列命令；用户本机路径不等于云端沙箱路径。仅有文件名、不可读取引用或缺少来源时，先取得可用附件、下载地址或正确源，不猜测个人目录。
+   ```bash
+   npm install -g --foreground-scripts --allow-scripts=@qfeius/everyline-cli <实际安装包路径>
+   ```
+3. 用户未指定包、版本或源时，使用官方 npm：
+   ```bash
+   npm install -g --foreground-scripts --allow-scripts=@qfeius/everyline-cli @qfeius/everyline-cli@latest --registry https://registry.npmjs.org
+   ```
+   不因指定包与本地同版本、isLatest=true 或公共源 E404 跳过用户指定的安装。公开源返回 E404 或版本不存在时，报告该源未找到目标，不反复换源、重试或猜下载地址。
+4. 保留 npm prefix、用户指定安装目录、Profile、身份和凭据；使用 --foreground-scripts 展示安装器输出，不添加 --silent，不单独替换二进制。
+5. 只有 npm ls -g --depth=0 确认旧无 scope 包 everyline-cli 占用同一全局命令时，才执行一次带 --force 的新包安装以迁移。新包验证成功后卸载旧 npm 包，再运行下列命令恢复入口并重新验证；任一步失败即停止后续迁移，普通安装不使用 --force。
+   ```bash
+   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)，其他场景执行[执行前检查](../SKILL.md#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 查询失败不否定已验证的安装，不触发第二次安装。同版本内容差异只能说明构建不同，不据此判断新旧或损坏；可报告“已按指定包重新安装”，不称为发现新版。缺少打包时的版本同步脚本本身不代表运行故障。
+- 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/postinstall 失败：未启动时说明“安装命令尚未启动”；中断且退出结果未确认时标记“待验证”，不假定未改动或已成功。
+- 非权限类进程创建故障最多做一次同环境最小只读探测，例如 pwd。仍失败就停止自动安装尝试，说明阶段、原始错误、是否启动与恢复步骤；不反复等待、变换工具或重跑安装。文件可读取不代表执行环境正常。
+- 明确权限拒绝或拦截时遵循宿主审批，不通过改换执行通道或提权规避。持续环境异常可建议重启当前任务或执行环境，不声称等待几秒必然恢复；用户反馈恢复后先做一次只读探测再继续。
+
+### 首次使用引导
+
+Codex、WorkBuddy 和豆包都按“Skill 文件就位 → 当前环境 CLI 检查 → 缺失时安装或取得必要确认 → 验证 → 回复正文展示结果”执行。安装任务不能停在 Skill 文件复制成功。终端日志或工具 JSON 不代替正文说明。同会话只展示一次；仅安装时放在最终回复，安装后继续授权或业务时在身份选择前展示。
+
+- 已确认本会话首次安装、宿主首次导入且首次运行、用户明确首次使用，或 CLI 明确要求首次配置时，使用下方统一文案。
+- 缺少 firstInstall/authorizationRequired 或字段为 false，不否定已确认的首次安装事实；字段缺失、未登录、无历史任务或无默认身份本身也不构成首次安装信号。
+- 已确认升级时使用[更新完成引导](#update-guidance)；同版本重装不重新触发首次介绍，未完成授权门禁继续遵守。
+- 豆包 ZIP 导入不执行 npm postinstall。Agent 负责安装或导入技能时，应在当前轮读取主 Skill 并立即检查该任务环境中的 CLI；缺失时按第 7 条安装或请求必要确认。纯平台静态导入且没有执行中的 Agent 时，不声称已经完成 CLI 检查；宿主下一次实际读取本 Skill 时立即补做。WorkBuddy 在当前宿主内验证，不要求用户去其他宿主或终端查看完成提示。
+
+只有 CLI 可执行、版本检查及技能文件验证通过后，才展示以下安装完成文案；仅技能文件复制成功时不得展示。CLI 缺失且等待必要确认时，明确展示第 7 条的安装确认提示；未能检查或安装失败时说明真实状态。
+
+原样展示：
+
+EveryLine CLI 已安装完成。目前支持合同审查，以及审查清单、规则和规则分组配置。使用前需要先完成账号授权，我现在可以为你打开授权页面或生成授权链接。
+
+仅要求安装时，展示后等待用户决定是否授权；同次请求已经要求继续授权或业务时，复用该目标，先完成身份选择，授权成功后恢复原步骤。已明确选择身份时不重复询问。
+
+<a id="update-guidance"></a>
+### 更新完成引导
+
+安装验证完成后，原样展示：
+
+EveryLine CLI 已更新完成。目前支持合同审查，以及审查清单、规则和规则分组配置。
+
+复用更新前已确认的 Profile 与身份，按[身份规则](../SKILL.md#identity)补齐缺失选择后，执行一次 auth status --profile <profile> --as <identity> --output json。不得从安装退出码、token 文件存在或历史有效期推断状态。
+
+- authenticated=false：原样展示“使用前需要先完成账号授权，我现在可以为你打开授权页面或生成授权链接。”已有登录意愿时继续，否则等待用户决定。
+- authenticated=true：原样展示“当前已存在生效授权，可直接调用cli能力；”。
+- 状态调用失败：报告真实错误，状态保持未知，不展示有效或失效分支。每次更新只展示一次完成文案和一个状态分支。
+- 若更新发生在成功审查同一轮，相关说明在过程消息中展示，最终审查回复仍按[成功结果输出](../SKILL.md#review-output)保持统一结构。

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

@@ -2,7 +2,7 @@
 name: everyline-review-config
 description: "使用 EveryLine CLI 查询或管理审查清单、审查规则和规则分组，包括新增、修改、调整归属和删除；仅在审查中选择已有清单时不使用本 Skill。"
 metadata:
-  version: "1.0.1"
+  version: "1.0.2"
   requires:
     bins: ["everyline-cli"]
     skills: ["everyline-review"]
@@ -11,7 +11,7 @@ metadata:
 
 # everyline-review-config
 
-使用 `everyline-cli` 管理审查清单、审查规则和规则分组。执行本 Skill 前通过宿主技能加载能力读取 `everyline-review` 中的「执行前检查」「安装与更新」「Profile 与身份」和「通用边界」，遵守其安装、身份、授权、结构化输出和安全约定；出现鉴权问题时进入其「状态、退出与恢复」。配置管理始终由本 Skill 负责，复用公共接入后返回中断步骤，不进入合同上传或审查流程。不要假定跨 Skill 相对路径可用；依赖未安装时先安装或导入 `everyline-review`，豆包云端分别导入两个 ZIP。
+使用 `everyline-cli` 管理审查清单、审查规则和规则分组。执行本 Skill 前通过宿主技能加载能力读取 `everyline-review` 中的「执行前检查」「安装与更新」「Profile 与身份」和「通用边界」，并按其入口读取适用的 `references/setup.md` 或 `references/auth.md`，遵守其安装、身份、授权、结构化输出和安全约定；出现鉴权问题时进入其「状态、退出与恢复」。这些参考路径以已加载的 `everyline-review` 根目录解析，不以本 Skill 目录或假定的兄弟目录解析。Device 宿主在首次身份相关配置或状态命令前完成其中的会话准备。配置管理始终由本 Skill 负责，复用公共接入后返回中断步骤，不进入合同上传或审查流程。不要假定跨 Skill 相对路径可用；依赖未安装时先安装或导入 `everyline-review`，豆包云端分别导入两个 ZIP。
 
 ## 触发边界