@weotro/dx 0.1.6 → 0.1.8

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@weotro/dx",
-  "version": "0.1.6",
+  "version": "0.1.8",
   "type": "module",
   "license": "MIT",
   "repository": {

package/skills/cc-ship-issue-pr/SKILL.md

@@ -5,22 +5,9 @@ description: 仅在用户显式调用 $cc-ship-issue-pr、/cc-ship-issue-pr 或
 
 # CC Ship Issue PR
 
-Claude Code 入口：主进程守门并执行轻改动，Codex 承接重改动的方案讨论、实现与独立审查。
+Claude Code 入口：主进程执行轻改动，Codex 承接重改动的方案讨论、实现与独立审查。
 
-## 步骤一：Claude Code 门禁
-
-任何文件检查、Git/GitHub 操作或共享流程加载之前执行：
-
-```bash
-if [[ -z "${CLAUDECODE:-}" ]]; then
-  echo "cc-ship-issue-pr 仅允许 Claude Code 调用；当前运行时不是 Claude Code，已退出。"
-  exit 64
-fi
-```
-
-门禁失败后立即结束。门禁通过的完成标准是 `CLAUDECODE` 非空。
-
-## 步骤二：加载共享流程
+## 步骤一：加载共享流程
 
 ```bash
 AGENTS_ROOT="${AGENTS_HOME:-$HOME/.agents}"

package/skills/git-release/SKILL.md

@@ -7,14 +7,17 @@ description: 仅在用户显式调用 $git-release 或明确要求使用 git-rel
 
 ## 目标
 
-在 `release/vX.Y.Z` 或 `release/vX.Y.Z-<prerelease>.N` 分支上，完成从发布前检查、GitHub Release 创建、生产服务器验证到发布后回访 Issue 建立的全流程；若当前不在 release 分支，则先从最新 `main` 自动创建目标 release 分支。
+在 `release/vX.Y.Z` 或 `release/vX.Y.Z-<prerelease>.N` 分支上，完成发布前检查、GitHub Release 创建和本次发布部署完成后的回访审计 Issue 建立；若当前不在 release 分支，则先从最新 `main` 自动创建目标 release 分支。
 
 ## 执行原则
 
 - 全程使用中文输出。
 - 严格执行前置校验，任何硬性条件不满足时立即终止。
 - 发行说明必须结构化、可读、可追溯。
-- 发布完成必须留下一个可追踪的部署后回访 Issue；终端里临时打印 checklist 不算完成。
+- 发布完成必须留下一个可追踪的“部署完成后回访审计单” Issue；终端里临时打印 checklist 不算完成。
+- 回访 Issue 是审计本次 release 是否完整、正确落地的取证清单，不是部署操作手册。正文应围绕本次发布内容提出核对项，不编排部署步骤、命令顺序或服务器操作教程。
+- 本技能只编写回访审计 Issue，不执行生产验证。不得登录生产服务器、访问生产数据库、调用生产只读接口、查询生产监控或尝试取得生产凭据。
+- GitHub Release 创建成功不代表已经部署。所有需要部署完成后取证的审计项默认未勾选，留给运维或后续回访 agent 补充实际结果与证据。
 - 命令默认在仓库根目录执行。
 - 若能从当前 release 分支或自动建分支流程唯一推断出合法版本号，直接使用该版本继续发布，不要询问用户确认。
 
@@ -159,17 +162,14 @@ EOF
 
 4. 读回 Release，确认 tag、标题、正文和 URL 正确：`gh release view v<VERSION> --json tagName,name,body,url,isDraft,isPrerelease`。
 
-### 六、生产环境验证与发布后回访
+### 六、创建部署完成后回访审计 Issue
 
 1. 完整读取 [发布后回访契约](references/post-release-follow-up.md)。
-2. 从仓库实际部署配置和运维文档确定生产服务器、连接方式、服务、品牌、target、版本标记、数据库和只读验证入口；禁止猜测主机或使用历史地址。
-3. 直接登录每台相关生产服务器，核对实际运行版本/commit、进程或容器、health/readiness、关键日志、worker/cron 和资源状态，确认部署事实而不是依赖流水线状态。
-4. 根据发行说明、PR、迁移和运维脚本识别本次需要人工执行的脚本，使用迁移表、任务记录、审计日志、marker、状态命令和数据结果验证是否已经执行且结果符合预期。检查默认只读；未经当前用户明确授权，不执行生产写脚本、迁移、回填、重启或重新部署。
-5. 自动创建一个发布后回访 Issue。Issue 必须覆盖：发布与服务器版本一致性、服务健康、运维脚本执行状态、数据结果、配置、可观测性、本次变更特有验收、回滚准备和延迟观察窗口。
-6. 立即执行当前可验证的检查；只有附有脱敏命令、查询结果摘要、日志位置或可观察结果的项目才能勾选。缺生产权限或需要观察窗口的项目保持未勾选，并写清所需权限或最早检查时间。
-7. 使用 `gh issue view` 读回 Issue，确认没有占位符、每个生产目标和本次发布影响面都有对应检查项，并输出 Issue URL。
-
-GitHub Release 已创建但无法登录生产服务器、实际版本不匹配、必需运维脚本未执行或数据不符合预期时，仍然创建回访 Issue，把状态标为阻塞并立即向用户报告证据、影响、建议动作和重新验证项；不得静默修复或用“Release 已创建”掩盖生产问题。
+2. 以本次 Release 说明、`<last-release-tag>..HEAD` 的提交与 diff、关联 PR/Issue 为主，按需读取仓库内的部署配置、迁移、运维脚本和 ops manifest，建立“发布内容 -> 受影响对象 -> 发布后风险/预期行为 -> 审计证据”的映射。不得通过 SSH、生产域名、数据库、监控平台、云平台 API 或私有环境配置验证当前生产状态。
+3. 自动创建一个“本次 release 部署完成后的回访审计单” Issue。逐项覆盖本次发布中的新增、优化、修复、技术改进和运维提醒；只有与本次变更相关时，才加入版本一致性、服务健康、迁移、脚本、数据、配置、可观测性、业务验收、回滚或延迟观察项。
+4. 每个审计项写清关联发布内容、审计对象、通过标准和应附的脱敏证据。使用“核对/确认/观察”的审计表述，不写“登录、执行、重启、部署”等操作步骤，也不提供部署命令或操作顺序。
+5. Issue 初始状态写为“待部署完成后回访”。所有依赖部署后事实的 checklist 保持未勾选；Release、tag 或 CI 的成功只能作为发布信息，不能代替生产落地证据。
+6. 使用 `gh issue view` 读回 Issue，确认没有占位符；发行说明中的每项实质变更均有对应审计项或明确的不适用说明；正文不存在通用部署手册式步骤；然后输出 Issue URL。
 
 ## 终止条件
 
@@ -179,7 +179,7 @@ GitHub Release 已创建但无法登录生产服务器、实际版本不匹配
 - 当前分支不符合 release 分支命名规则，且无法从 `main` 自动创建 release 分支。
 - 版本号格式非法或与现有 tag 冲突。
 - 自上次发布以来无新提交。
-- 无法创建或读回发布后回访 Issue。
+- 无法创建或读回部署完成后回访审计 Issue。
 
 ## 输出模板
 
@@ -205,6 +205,6 @@ GitHub Release 已创建但无法登录生产服务器、实际版本不匹配
 - 分支名
 - tag 推送状态
 - Release URL
-- 生产服务器、实际运行版本与验证状态
-- 发布后回访 Issue URL
-- 已验证、阻塞、待授权、待观察项目数量
+- 预期部署环境、品牌与 target
+- 部署完成后回访审计 Issue URL
+- 待回访审计与待观察项目数量

package/skills/git-release/agents/openai.yaml

@@ -1,7 +1,7 @@
 interface:
   display_name: "Git Release"
-  short_description: "完成版本发布、生产服务器核验与发布后回访"
-  default_prompt: "使用 $git-release 执行发布，登录生产服务器核验版本、运维脚本和数据，并创建带证据的回访 Issue checklist。"
+  short_description: "完成版本发布并创建部署后的发布内容回访审计单"
+  default_prompt: "使用 $git-release 执行发布，并根据本次 Release 的实际变更创建部署完成后的回访审计 Issue；它是取证审计单，不是部署操作手册。"
 
 policy:
   allow_implicit_invocation: false

package/skills/git-release/references/post-release-follow-up.md

@@ -1,158 +1,134 @@
-# 发布后回访契约
+# 部署完成后回访审计 Issue 契约
 
-本文件只在 GitHub Release 创建成功后读取。目标是把部署后的未知风险变成一个有证据、可关闭的 Issue，而不是生成一张固定且无法证明完成的清单。
+本文件只在 GitHub Release 创建并读回成功后使用。产物是“本次 release 部署完成后的回访审计单”：用于在部署完成后核对本次发布是否完整、正确落地并留下证据，不用于指导如何部署。
 
-## 完成边界
+## 定位与边界
 
-`git-release` 本次调用完成的最低条件是：
+当前 `git-release` agent 负责：
 
-- Release 已读回确认；
-- 已从实际配置确定或明确无法确定生产服务器与验证入口；
-- 已登录所有相关生产服务器核对实际运行状态，或记录无法访问的证据；
-- 发布后回访 Issue 已创建并读回；
-- 本次发布涉及的每个环境、品牌、target、迁移、配置和用户可观察变化都有检查项；
-- 当前能自动验证的项目已执行，只有带证据的项目被勾选。
+- 从本次 Release 说明、提交、diff、关联 PR/Issue，以及必要的迁移、配置和运维清单中建立发布影响面；
+- 把每项实质发布内容转换为可判定、可取证的部署后审计项；
+- 创建并读回回访审计 Issue。
 
-回访 Issue 不要求在当前调用中关闭。需要观察窗口、人工账号或业务确认的项目保持未勾选，避免为了“流程完成”伪造通过状态。
+Issue 应描述“部署完成后要确认什么、什么结果算通过、需要什么证据”。不要描述部署动作、命令顺序、登录路径、重启流程或故障处置步骤；这些内容属于部署 runbook。
 
-## 生产服务器核验
+当前调用不连接或探测生产环境，包括 SSH、生产数据库、生产域名或 health 接口、监控平台、云平台部署 API、服务器日志和私有环境 profile，也不为此取得密钥、token 或生产权限。
 
-先检查仓库真实部署配置和运维文档，包括部署脚本、inventory、`dx/config/commands.json`、`dx/release/`、systemd/container 配置和 runbook。确定：
+GitHub Release、tag、CI 或部署工作流成功都不能证明生产已完成部署。Issue 初始状态统一写为“待部署完成后回访”，所有依赖生产事实的审计项保持未勾选。
 
-- 生产主机、SSH 入口、区域、品牌、服务与前端 target；
-- 服务由 systemd、Docker、Kubernetes、PM2、serverless 或其他方式运行；
-- 服务器上可验证版本/commit 的文件、环境变量、镜像标签、健康接口或运行参数；
-- 数据库、队列、worker、cron、缓存和第三方连接的只读检查入口；
-- 本次发布要求人工执行的迁移、回填、缓存刷新、配置生成或运维脚本。
+## 以本次发布内容为主线
 
-逐台登录本次涉及的生产服务器，使用仓库已有状态命令或等价的只读命令检查实际状态。按运行方式核对进程、容器、镜像、release 目录、符号链接、启动时间、health/readiness 和最近日志；命令必须收敛到明确服务，避免无边界扫描整台服务器。
+按以下优先级建立审计范围：
 
-服务器验证默认只读。不要执行重启、重新部署、迁移、回填、数据修复、缓存清空或其他生产写操作；发现需要执行时，在 Issue 和当前回复中写明命令、原因、影响和验证方式，等待用户对该具体动作授权。
+1. 本次 Release 的发布摘要、分类变更、运维提醒和升级指南；
+2. `<last-release-tag>..HEAD` 的提交、diff、关联 PR 与 Issue；
+3. 为理解上述变更而必须读取的迁移、配置、部署描述、脚本和 ops manifest。
 
-如果缺少主机信息、SSH 权限或数据库只读权限，在 Issue 中明确写“生产验证受阻”，附已检查的配置位置和失败命令。此状态属于阻塞，不得写成部署成功。
+为每项实质变更记录：
 
-## 动态生成检查项
+- **关联发布内容**：发行说明条目及对应 PR/Issue；
+- **受影响对象**：环境、品牌、target、服务、任务、数据库、接口或用户路径；
+- **部署后预期**：本次变化落地后可观察且可判定的结果；
+- **主要风险**：漏发、版本漂移、兼容性、迁移遗漏、数据偏差、配置缺失或行为回归；
+- **审计证据**：脱敏的版本/commit、状态摘要、迁移或任务记录、监控链接、日志时间窗、数据结果或行为截图。
 
-先从发行说明、提交、PR、Issue、运维提醒和部署配置建立“发布影响面”，再为每个影响面生成至少一个可验证检查。只保留本次适用的分支，但以下类别必须逐项判定是否适用，不能静默跳过。
+发行说明中的每项实质变更必须至少映射到一个审计项。纯文档、测试或内部重构若没有生产可观察影响，可以合并为一项发布完整性核对，或明确说明为何无需独立生产审计。
 
-### 发布与制品一致性
+不要为了填满固定栏目而生成与本次发布无关的通用检查。仓库无法确定的生产坐标或私有信息写为“由回访执行人按生产配置补充”，不要猜测。
 
-- tag、Release、版本文件和服务器实际运行 commit 指向同一版本；
-- 服务器上的制品、镜像、release 目录或构建产物使用正确版本与 commit；
-- 所有预期生产主机、品牌和 target 都运行目标版本，没有漏发、错发或部分节点仍运行旧版；
-- Release 不是意外的 draft/prerelease，除非版本本身要求如此。
+## 审计项写法
 
-### 服务器与服务状态
+每个 checklist 项包含：
 
-- 目标进程、容器、pod 或 function 正常运行，启动时间与本次发布一致；
-- health/readiness、端口、反向代理和服务间连接正常；
-- worker、cron、队列消费者和后台作业运行在目标版本；
-- 最近日志没有启动失败、error、panic、timeout、权限错误或重复重启；
-- CPU、内存、磁盘、连接数等没有因本次发布出现明显异常。
+- 关联的 Release 条目、PR 或 Issue；
+- 审计对象；
+- 明确的通过标准；
+- 应附的脱敏证据；
+- 审计时机：部署完成后立即、观察窗口结束后或下一轮计划任务后。
 
-### 运行时健康与可观测性
+使用审计语言，例如：
 
-- health/readiness、关键进程、容器或 serverless function 健康；
-- 发布后错误率、延迟、5xx、告警、日志异常没有明显回归；
-- 队列积压、定时任务、事件消费、webhook 或后台作业正常；
-- 域名、TLS、静态资源、CDN、缓存版本和 source map 符合预期。
+```markdown
+- [ ] `#123 修复订单重复提交`：核对生产订单接口在重复请求场景只产生一笔订单；通过标准为幂等键对应单条订单记录且无新增重复告警；附脱敏请求标识、结果摘要和观察窗口链接。（部署完成后立即）
+```
 
-### 数据、配置与兼容性
+避免写成操作手册，例如：
 
-- 本次迁移已应用到正确数据库，schema 与应用版本兼容；
-- 新增或变更的环境变量、secret、feature flag 和第三方配置已生效；
-- 公共 API、DTO、事件、数据库和客户端兼容性按发行说明验证；
-- 使用有边界的只读查询核对关键总数、不变量、状态分布和抽样结果；不得在输出中泄露密钥、令牌、个人信息或业务敏感原始数据；
-- 涉及数据修复或回填时，记录预期数量、实际数量、失败项和幂等/重跑状态。
+```markdown
+- [ ] 登录服务器，拉取代码，执行迁移，重启服务，然后运行 curl 检查接口。
+```
 
-### 运维脚本执行状态
+审计项可以要求提供某类证据，但不规定取得证据的具体命令。发现异常时记录结论并关联单独的问题 Issue；不要在审计单中展开修复或重新部署教程。
 
-- 从本次 PR、迁移、release note 和 runbook 列出所有需要人工执行的脚本，不能只检查熟悉的脚本；
-- 对每个脚本记录名称/版本、目标主机或数据库、预期效果和可验证完成标记；
-- 通过迁移表、任务表、审计日志、marker、脚本状态子命令或数据结果判断 `已执行 / 未执行 / 无法确认 / 不适用`；
-- “文件存在”或“有人说跑过”不算执行证据；
-- 未经授权不代替运维执行写脚本。未执行或结果异常时立即报告，并给出建议命令和执行后的复核查询。
+## 按影响选择审计维度
 
-### 用户与业务路径
+以下是选择维度，不是固定模板。只保留本次发布确实涉及的部分：
 
-- 为发行说明中的每个用户可观察变化生成对应 smoke check；
-- 覆盖登录/鉴权、核心读写路径、支付或其他高风险业务路径中本次受影响的部分；
-- 前端、管理端、移动端或多品牌变更分别验证对应入口，不能用一个端的通过代表全部端；
-- 修复项要复现旧失败条件并验证新行为，新增项要验证成功路径和关键错误路径。
+- **发布完整性**：多环境、多品牌、多 target 或多制品发布是否存在漏发与版本漂移；
+- **功能与修复**：新增能力、优化或缺陷修复对应的成功路径、关键失败路径和旧问题复现条件；
+- **迁移与数据**：schema、seed、回填、缓存刷新或数据修复的完成状态、数量、不变量与兼容性；
+- **配置与依赖**：新增或变更的环境变量、feature flag、secret、第三方连接或依赖版本是否按预期生效；
+- **异步与定时任务**：worker、队列、事件、webhook、cron 或后台任务在本次变化后的处理结果；
+- **可观测性**：与本次风险直接相关的错误率、延迟、日志、告警、资源或业务指标；
+- **延迟效应**：必须等待缓存过期、定时任务、流量积累或业务周期后才能判定的变化；
+- **回滚可用性**：仅当本次变更具有明显回滚风险时，核对上一稳定版本、数据兼容性和回滚入口仍可用。
 
-### 回滚与延迟观察
+## 完成边界
 
-- 记录上一稳定版本、回滚命令或恢复入口，以及迁移是否可逆；
-- 对需要时间才能暴露的问题设置观察窗口和最早复查时间，例如错误率、队列积压、定时任务或缓存过期；
-- 明确 Issue 关闭条件：所有必需项完成，阻塞项有结论，发现的问题已修复或拆成关联 Issue。
+`git-release` 本次调用完成的最低条件是：
+
+- Release 已读回确认；
+- 本次发布的每项实质变更已映射到审计项或不适用说明；
+- 每个审计项都有审计对象、通过标准、证据要求和时机；
+- Issue 已创建并读回，且没有占位符；
+- 所有依赖部署后事实的审计项均未勾选；
+- Issue 没有声称已经完成部署或生产验证，也没有写成部署操作步骤。
+
+回访审计单不要求在当前调用中关闭。部署完成后，由运维或后续回访 agent 在同一个 Issue 中补充实际结果、证据与异常关联。
 
 ## Issue 结构
 
-创建前先读取仓库 Issue 模板和现有 labels，沿用其结构与可用标签。标题使用：
+创建前读取仓库 Issue 模板和现有 labels，沿用可适用的结构与标签。标题使用：
 
 ```text
-chore(release): 回访 v<VERSION> 部署结果
+chore(release): 审计 v<VERSION> 部署后发布结果
 ```
 
-正文至少包含：
+正文根据本次发布影响动态增删章节，至少包含：
 
 ```markdown
-## 发布信息
+## 审计范围
 
 - 版本：v<VERSION>
 - Release：<URL>
 - Tag commit：<SHA>
-- 部署环境/品牌/target：<实际范围>
-- 生产服务器与服务：<脱敏主机标识和实际范围>
-- 实际运行版本/commit：<逐目标结果>
-- 生产验证时间：<时间与时区>
-- 验证状态：通过 / 阻塞 / 发现异常
-
-## 部署后检查清单
-
-### 发布与制品一致性
-
-- [ ] <检查对象、预期结果、验证命令或证据位置>
-
-### 生产服务器与服务
+- 对比范围：<last-tag>...v<VERSION>
+- 预期部署范围：<从仓库配置得出的环境/品牌/target；未知项由回访执行人补充>
+- 当前状态：待部署完成后回访
 
-- [ ] <检查项>
+## 本次发布影响摘要
 
-### 运行时与可观测性
+| 发布内容 | 关联项 | 受影响对象 | 主要风险 |
+| --- | --- | --- | --- |
+| <发行说明中的实质变更> | <PR/Issue> | <对象> | <风险> |
 
-- [ ] <检查项>
+## 部署后回访审计
 
-### 数据、配置与兼容性
+### <按本次发布内容归纳的主题，例如“订单幂等修复”>
 
-- [ ] <检查项或“不适用 + 证据”>
+- [ ] <关联发布内容、审计对象、通过标准、证据要求、审计时机>
 
-### 运维脚本
+### <仅在本次发布涉及延迟效应时保留：观察窗口>
 
-- [ ] <脚本、目标、预期结果、执行状态与证据>
+- [ ] <观察指标、通过标准、窗口结束时间和证据要求>
 
-### 本次变更验收
+## 审计结论
 
-- [ ] <逐项映射发行说明/PR/Issue 的用户可观察变化>
-
-### 回滚与观察窗口
-
-- [ ] <回滚入口已确认>
-- [ ] <观察指标、窗口、最早复查时间、负责人或所需权限>
-
-## 发现与后续
-
-- 当前阻塞：无 / <失败证据与恢复动作>
-- 关联问题：无 / #<issue>
-- 关闭条件：<所有必需检查完成且发现的问题有结论>
+- 当前结论：待部署完成后回访
+- 异常与关联 Issue：无；发现异常后补充
+- 关闭条件：本次发布的必需审计项均有结果与证据，异常均已有结论或关联 Issue
 ```
 
-正文通过 heredoc 或临时文件传给 `gh issue create --body-file`，禁止用字面量 `\n` 拼接。创建后用 `gh issue view <id> --json title,body,url,state` 读回。
-
-## 勾选与问题处理
+正文通过 heredoc 或临时文件传给 `gh issue create --body-file`，不要用字面量 `\n` 拼接。创建后用 `gh issue view <id> --json title,body,url,state` 读回。
 
-- 勾选项必须同时写入证据：脱敏命令与结果摘要、日志位置、只读查询汇总、监控链接或具体可观察结果。
-- “服务器能登录”“进程在运行”“页面能开”不能替代版本、脚本和数据的专项验证。
-- 检查失败时保留未勾选状态，在“发现与后续”记录严重级、时间、主机/服务、证据、影响和建议动作，并立即在当前回复中报告。
-- 发现问题后默认只报告和保全证据，不静默修改生产环境。修复需要生产写操作时等待用户对具体动作授权。
-- 新发现的问题超出本次回访可直接修复的范围时创建关联 Issue；回访 Issue 保持打开，直到该问题有明确处置结果。
-- 不适用项必须写出判定依据；不要为了模板完整保留空占位项。
+读回时确认：发布影响摘要覆盖所有实质变更；每项均有对应审计项或不适用说明；没有通用部署教程、未经取证的完成状态或虚构的生产信息。

package/skills/oo-ship-issue-pr/SKILL.md

@@ -5,26 +5,9 @@ description: 仅在用户显式调用 $oo-ship-issue-pr、/oo-ship-issue-pr 或
 
 # OO Ship Issue PR
 
-Codex 入口：主进程守门并执行轻改动，Claude Fable 5 优先承接重改动的方案讨论、实现与独立审查；Fable 额度不足时回退 Claude Opus 5，Claude 通道不可用时改派 fresh Codex subagent，不中断交付链。
+Codex 入口：主进程执行轻改动，Claude Fable 5 优先承接重改动的方案讨论、实现与独立审查；Fable 额度不足时回退 Claude Opus 5，Claude 通道不可用时改派 fresh Codex subagent，不中断交付链。
 
-## 步骤一：Codex 门禁
-
-任何文件检查、Git/GitHub 操作或共享流程加载之前执行：
-
-```bash
-if [[ -n "${CLAUDECODE:-}" ]]; then
-  echo "oo-ship-issue-pr 仅允许 Codex 调用；检测到 Claude Code 运行时，已退出。"
-  exit 64
-fi
-if [[ -z "${CODEX_THREAD_ID:-}" && -z "${CODEX_SESSION_ID:-}" ]]; then
-  echo "oo-ship-issue-pr 仅允许 Codex 调用；当前运行时不是 Codex，已退出。"
-  exit 64
-fi
-```
-
-`CLAUDECODE` 存在时优先拒绝，避免 Codex 启动的 Claude 子进程继承 `CODEX_*` 后误过门禁。门禁通过的完成标准是 `CLAUDECODE` 为空，且至少一个 Codex 身份变量非空。
-
-## 步骤二：加载共享流程
+## 步骤一：加载共享流程
 
 ```bash
 AGENTS_ROOT="${AGENTS_HOME:-$HOME/.agents}"