@weotro/dx 0.1.7 → 0.1.8

package/package.json

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

package/skills/git-release/SKILL.md

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