@routerhub/agent-rules 1.5.117 → 1.5.119

package/AGENTS.base.md

@@ -33,6 +33,18 @@
 - ⚠️ **上述来源都找不到的，就写「待确认」或留空，禁止自行补全。** 错误的推断值比留空危害更大——留空会在运行时报错、立刻暴露；错误的推断值可能静默运行数月后才被发现（如请求打到了错误的环境），排查成本极高。
 - ⚠️ **代码中使用环境变量占位符（如 `process.env.XXX`）时，必须同时确认测试/生产部署脚本（或配置中心）已提供该变量的具体值。** 禁止只写占位符不落地——代码能编译不代表部署后取值非空。具体值的存放规则：敏感值（密钥、Token 等）必须配到 Nacos 配置中心，禁止写进部署脚本；非敏感值（域名、地址、端口、外部服务 URL 等）写入测试/生产各自的部署脚本。部署脚本中找不到的值仍按本规则写「待确认」或留空，禁止自行补全。
 
+## ⚠️ 可部署性自包含铁律（写代码之前考虑）
+
+- ⚠️ **写任何逻辑、用任何环境变量/配置值之前，必须先把"这个改动上线后部署怎么办"想清楚**：能直接写死的就写死，该放部署脚本的就放部署脚本，该配配置中心的就配配置中心。所有环境准备（建表、迁移、字段变更、初始化/导入数据、配置下发）一律内嵌到部署脚本自动完成。**达成的效果：上线时只需执行部署脚本，数据库迁移、人工改配置等一切操作全部免掉，上线后零操心。**
+- ⚠️ **触发时机是写代码之前，不是部署的时候。** 禁止先写代码、等要部署了再补部署脚本。每写一个涉及环境准备的改动，部署逻辑必须随之一起落地，不允许"代码完成、部署待办"的中间态。
+- ⚠️ **写完涉及环境准备的改动，必须当场自查三问**（参考 DELETE 铁律格式；任一答案为「是」而部署脚本无对应逻辑 → **该改动不算完成**）：
+  1. **改数据库了吗？** 新增/修改表、字段或数据 → 部署脚本必须有幂等 schema 确保逻辑（如 `ALTER TABLE ... ADD COLUMN IF NOT EXISTS`、`ensure_xxx()` 前置函数），加列/建表失败即停止部署。
+  2. **改配置了吗？** 新增/修改环境变量、Nacos 配置、部署脚本值 → 具体值必须已落地部署脚本或配置中心，禁止只写占位符或"待确认"。
+  3. **要初始化/搬运数据吗？** 需要初始化、导入、转换数据 → 必须脚本化进部署流程自动完成。
+- ⚠️ **发现「部署后还需要手动补步骤」= 部署流程有缺口**：一旦某次部署发现还要人工执行迁移、导数据、改配置等步骤功能才能用，必须当场把该步骤自动化进部署脚本，禁止继续靠记性每次手动补。**人为手动步骤是上线遗漏的根源**（测试环境做了、生产环境容易忘）。
+- ⚠️ **部署完成的定义 = 脚本执行完 → 功能直接可用 → 期间零人工补操作。** 未满足「零人工补操作」的部署不算完成，禁止在还需手动补步骤时宣称部署完成。
+- ⚠️ **「部署可用」≠「功能已验证」**：部署自动化到位只保证环境就绪、功能直接可操作；功能是否正确，仍需按既有验证铁律用真实数据验证，两者不冲突。
+
 ## ⚠️ 排查与协作铁律
 
 - ⚠️ **排查「以前能用、现在不行」类问题时禁止用绕过手段掩盖问题**（改配置屏蔽报错、写同步脚本搬数据、临时禁用校验等），必须先定位根因再修复。
@@ -212,6 +224,7 @@
 
 - ⚠️ **问题根因是"某个被多个服务/项目共用的基础设施配置（网关、负载均衡器、DNS、Ingress、防火墙规则、共享中间件/代理配置、共享配置中心 namespace 等）转发或配置错了"时，禁止把"直接改这个共享配置"当作默认修复方案**。共享基础设施上的改动会波及所有依赖它的其他流量/服务，波及范围和风险几乎总是大于当前这一个问题本身。优先方案是在自己服务的边界内收敛解决——如直连正确后端的独立地址、加一层自己控制的适配/转发，而不触碰上游共享设施。
 - ⚠️ **评估后确认必须改共享基础设施本身才能修复时，必须先向用户说明改动内容和影响范围（这份配置还被哪些其他服务/流量依赖），得到明确确认后才能执行**，禁止在诊断过程中把"顺手改一下共享配置"当成常规修复步骤直接执行——这类改动一旦出错，影响的不是一个功能，而是所有依赖这份共享配置的系统。
+- ⚠️ **共享存储字段变更（如 BigQuery 表加列、共享 DB 加字段）是最容易漏的手动步骤**：这类资源由多个系统共享（写入方、读取方、传输层），天然不在单一部署脚本的「本能覆盖范围」内。每次新增/修改后端读取的字段，必须同步检查对应的共享存储是否已加列/加字段，并把「幂等确保存在」逻辑内嵌进部署脚本（如 `ALTER TABLE ... ADD COLUMN IF NOT EXISTS`、`bq mk if-not-exists`、幂等的 `ensure_xxx()` 前置函数），而不是留给运维手动跑一次。参考模式：`deploy_backend()` 内先调用幂等 `ensure_usage_logs_schema()` 再部署，加列失败即停止部署，不产生「接口挂」的中间态；代码层面再加列存在性动态检测兜底（缺列时优雅降级，不报 `Unrecognized name`）。
 
 ## 网关/负载均衡 404 排查规范
 
@@ -232,10 +245,7 @@
 
 ## 部署规则
 
-- 发版统一执行 `./release.sh`。
-- ⚠️ **部署流程必须自包含、可直接使用**：开发过程中涉及的任何环境准备工作（数据迁移、建表、字段变更、初始化数据、配置下发等），都必须内嵌到部署流程中自动完成。部署到测试环境 / 生产环境后，功能应直接可用，**不依赖任何人记得在部署前后手动补做步骤**。
-- ⚠️ **发现「需要手动补做的步骤」= 部署流程有缺口**：若某次部署发现还需要人工执行迁移、导数据、改配置等额外步骤功能才能用，说明该步骤未被自动化——应把它纳入部署流程，而不是继续靠记性每次手动补。**人为手动步骤是上线遗漏的根源**（测试环境做了、生产环境容易忘）。
-- ⚠️ **「部署可用」≠「功能已验证」**：部署自动化到位只保证环境就绪、功能直接可操作；功能是否正确，仍需按既有验证铁律用真实数据验证，两者不冲突。
+- 发版统一执行 `./release.sh`。（自包含铁律见上方「⚠️ 可部署性自包含铁律」章节）
 - ⚠️ 部署测试环境必须使用 `/deploy-test` skill。任何包含「部署测试」「发布测试」「上线测试」「部署test」「推到test」「部署到测试环境」等表述的需求，必须先调用 `Skill` 工具加载 `deploy-test`，严禁跳过 skill 直接执行部署操作。
 - ⚠️ 部署测试环境的正确流程是：当前分支 → 合并到 test 分支 → 推送 test → 触发部署 → 切回原分支。禁止直接在 test 分支上提交代码，禁止跳过合并步骤直接部署功能分支。
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@routerhub/agent-rules",
-  "version": "1.5.117",
+  "version": "1.5.119",
   "description": "Shared Copilot agent rules and guidelines for RouterHub projects",
   "main": "AGENTS.base.md",
   "bin": {

package/rules/global.md

@@ -33,6 +33,18 @@ name: "通用规则"
 - ⚠️ **上述来源都找不到的，就写「待确认」或留空，禁止自行补全。** 错误的推断值比留空危害更大——留空会在运行时报错、立刻暴露；错误的推断值可能静默运行数月后才被发现（如请求打到了错误的环境），排查成本极高。
 - ⚠️ **代码中使用环境变量占位符（如 `process.env.XXX`）时，必须同时确认测试/生产部署脚本（或配置中心）已提供该变量的具体值。** 禁止只写占位符不落地——代码能编译不代表部署后取值非空。具体值的存放规则：敏感值（密钥、Token 等）必须配到 Nacos 配置中心，禁止写进部署脚本；非敏感值（域名、地址、端口、外部服务 URL 等）写入测试/生产各自的部署脚本。部署脚本中找不到的值仍按本规则写「待确认」或留空，禁止自行补全。
 
+## ⚠️ 可部署性自包含铁律（写代码之前考虑）
+
+- ⚠️ **写任何逻辑、用任何环境变量/配置值之前，必须先把"这个改动上线后部署怎么办"想清楚**：能直接写死的就写死，该放部署脚本的就放部署脚本，该配配置中心的就配配置中心。所有环境准备（建表、迁移、字段变更、初始化/导入数据、配置下发）一律内嵌到部署脚本自动完成。**达成的效果：上线时只需执行部署脚本，数据库迁移、人工改配置等一切操作全部免掉，上线后零操心。**
+- ⚠️ **触发时机是写代码之前，不是部署的时候。** 禁止先写代码、等要部署了再补部署脚本。每写一个涉及环境准备的改动，部署逻辑必须随之一起落地，不允许"代码完成、部署待办"的中间态。
+- ⚠️ **写完涉及环境准备的改动，必须当场自查三问**（参考 DELETE 铁律格式；任一答案为「是」而部署脚本无对应逻辑 → **该改动不算完成**）：
+  1. **改数据库了吗？** 新增/修改表、字段或数据 → 部署脚本必须有幂等 schema 确保逻辑（如 `ALTER TABLE ... ADD COLUMN IF NOT EXISTS`、`ensure_xxx()` 前置函数），加列/建表失败即停止部署。
+  2. **改配置了吗？** 新增/修改环境变量、Nacos 配置、部署脚本值 → 具体值必须已落地部署脚本或配置中心，禁止只写占位符或"待确认"。
+  3. **要初始化/搬运数据吗？** 需要初始化、导入、转换数据 → 必须脚本化进部署流程自动完成。
+- ⚠️ **发现「部署后还需要手动补步骤」= 部署流程有缺口**：一旦某次部署发现还要人工执行迁移、导数据、改配置等步骤功能才能用，必须当场把该步骤自动化进部署脚本，禁止继续靠记性每次手动补。**人为手动步骤是上线遗漏的根源**（测试环境做了、生产环境容易忘）。
+- ⚠️ **部署完成的定义 = 脚本执行完 → 功能直接可用 → 期间零人工补操作。** 未满足「零人工补操作」的部署不算完成，禁止在还需手动补步骤时宣称部署完成。
+- ⚠️ **「部署可用」≠「功能已验证」**：部署自动化到位只保证环境就绪、功能直接可操作；功能是否正确，仍需按既有验证铁律用真实数据验证，两者不冲突。
+
 ## ⚠️ 排查与协作铁律
 
 - ⚠️ **排查「以前能用、现在不行」类问题时禁止用绕过手段掩盖问题**（改配置屏蔽报错、写同步脚本搬数据、临时禁用校验等），必须先定位根因再修复。
@@ -212,6 +224,7 @@ name: "通用规则"
 
 - ⚠️ **问题根因是"某个被多个服务/项目共用的基础设施配置（网关、负载均衡器、DNS、Ingress、防火墙规则、共享中间件/代理配置、共享配置中心 namespace 等）转发或配置错了"时，禁止把"直接改这个共享配置"当作默认修复方案**。共享基础设施上的改动会波及所有依赖它的其他流量/服务，波及范围和风险几乎总是大于当前这一个问题本身。优先方案是在自己服务的边界内收敛解决——如直连正确后端的独立地址、加一层自己控制的适配/转发，而不触碰上游共享设施。
 - ⚠️ **评估后确认必须改共享基础设施本身才能修复时，必须先向用户说明改动内容和影响范围（这份配置还被哪些其他服务/流量依赖），得到明确确认后才能执行**，禁止在诊断过程中把"顺手改一下共享配置"当成常规修复步骤直接执行——这类改动一旦出错，影响的不是一个功能，而是所有依赖这份共享配置的系统。
+- ⚠️ **共享存储字段变更（如 BigQuery 表加列、共享 DB 加字段）是最容易漏的手动步骤**：这类资源由多个系统共享（写入方、读取方、传输层），天然不在单一部署脚本的「本能覆盖范围」内。每次新增/修改后端读取的字段，必须同步检查对应的共享存储是否已加列/加字段，并把「幂等确保存在」逻辑内嵌进部署脚本（如 `ALTER TABLE ... ADD COLUMN IF NOT EXISTS`、`bq mk if-not-exists`、幂等的 `ensure_xxx()` 前置函数），而不是留给运维手动跑一次。参考模式：`deploy_backend()` 内先调用幂等 `ensure_usage_logs_schema()` 再部署，加列失败即停止部署，不产生「接口挂」的中间态；代码层面再加列存在性动态检测兜底（缺列时优雅降级，不报 `Unrecognized name`）。
 
 ## 网关/负载均衡 404 排查规范
 
@@ -232,10 +245,7 @@ name: "通用规则"
 
 ## 部署规则
 
-- 发版统一执行 `./release.sh`。
-- ⚠️ **部署流程必须自包含、可直接使用**：开发过程中涉及的任何环境准备工作（数据迁移、建表、字段变更、初始化数据、配置下发等），都必须内嵌到部署流程中自动完成。部署到测试环境 / 生产环境后，功能应直接可用，**不依赖任何人记得在部署前后手动补做步骤**。
-- ⚠️ **发现「需要手动补做的步骤」= 部署流程有缺口**：若某次部署发现还需要人工执行迁移、导数据、改配置等额外步骤功能才能用，说明该步骤未被自动化——应把它纳入部署流程，而不是继续靠记性每次手动补。**人为手动步骤是上线遗漏的根源**（测试环境做了、生产环境容易忘）。
-- ⚠️ **「部署可用」≠「功能已验证」**：部署自动化到位只保证环境就绪、功能直接可操作；功能是否正确，仍需按既有验证铁律用真实数据验证，两者不冲突。
+- 发版统一执行 `./release.sh`。（自包含铁律见上方「⚠️ 可部署性自包含铁律」章节）
 - ⚠️ 部署测试环境必须使用 `/deploy-test` skill。任何包含「部署测试」「发布测试」「上线测试」「部署test」「推到test」「部署到测试环境」等表述的需求，必须先调用 `Skill` 工具加载 `deploy-test`，严禁跳过 skill 直接执行部署操作。
 - ⚠️ 部署测试环境的正确流程是：当前分支 → 合并到 test 分支 → 推送 test → 触发部署 → 切回原分支。禁止直接在 test 分支上提交代码，禁止跳过合并步骤直接部署功能分支。
 

package/skills/deploy-test/SKILL.md

@@ -87,7 +87,7 @@ git checkout "$ORIGINAL_BRANCH"
 
 - ⚠️ 推送 test 后必须立即执行 `git push origin test`
 - ⚠️ 部署完成后必须立即切回原功能分支
-- ⚠️ 部署必须自包含：migration、配置变更、依赖检查全部脚本化自动执行，禁止部署后人工补操作
+- ⚠️ 部署必须自包含：migration、配置变更、依赖检查全部脚本化自动执行，禁止部署后人工补操作（自包含铁律见 AGENTS.base.md「⚠️ 可部署性自包含铁律」章节，写代码之前就要考虑）
 - ⚠️ 合并到 test 发生冲突时，必须用 `-X theirs`（以当前功能分支为准），因为当前分支是最新代码，test 旧版本直接覆盖即可。
 - 禁止直接往 test 分支提交代码
 - 敏感信息（密钥、Token）必须从 Nacos 配置中心拉取，不得写死