@routerhub/agent-rules 1.5.208 → 1.5.209

package/AGENTS.base.md

@@ -181,6 +181,7 @@ agent-rules 生成的规则文件分两层，行为与归属不同，评审/发
 - ⚠️ **功能验收 / 取证（给人看的截图、报告、PR 效果图）必须在「别人能直接打开的环境」（测试环境域名）上做，禁止用本地环境的结果交差。** 本地环境（`localhost` / `127.0.0.1` / `vite dev` / 各类「一键启动」脚本 / `file:///` 本机文档）的证据只有你自己看得到：它依赖你本机的数据库、配置中心取值、未提交的代码、正在跑的进程与端口——别人照同样的命令跑，得到的是另一套环境，复现不出你截图里的样子。**证据的价值在于别人能独立打开、独立复核；打不开的证据等于没有证据。**
 - ⚠️ **正确顺序：改完代码 → 部署到测试环境（走 `/deploy-test`）→ 在测试环境域名上操作取证。** 禁止在本地截完图再补一句「测试环境效果相同」——那是推断，不是证据（呼应「⚠️ 环境配置禁止推断」）。
 - ⚠️ **本地环境允许用于开发中的即时联调与排错，但产出的截图/结果一律不得作为交付证据。** 一句话自查：**这张图 / 这个 URL 发给别人，他在自己电脑上能直接打开看到同一个页面吗？** 不能 → 它不是证据，先部署到测试环境再重新取证。
+- ⚠️ **交出去的「入口」不只是截图 URL，还包括命令——两者都必须是别人拿到就能直接用的**：给 URL → 别人在浏览器里一贴就能打开（测试环境 / 线上域名）；给命令（curl / 部署脚本 / 复现步骤）→ 别人在自己机器上复制粘贴就能跑，**不得引用只有你本机才有的东西**（本机路径、`localhost:端口`、容器名、未提交的文件、正在跑的本机服务）。一句话自查：**这段内容我原样发给同事，他什么都不问、也不用额外装什么，能直接跑起来吗？** 不能 → 先补齐成别人可执行的形态（换成测试环境域名、补全参数）再交付（命令的完整性要求见「⚠️ 截图规范」）。
 - ⚠️ **依赖中间件的证据（Redis / 数据库 / 日志）同样连测试环境实例取证**，禁止截本机 Docker 里的 Redis / 本地库——本机实例的值与测试环境无关，证明不了任何事。
 - ⚠️ **例外（仅此两种，且必须在报告里写明「本地环境」及原因）**：① 功能尚未部署到测试环境、且用户明确要求「先看本地效果」；② 该环境客观无法部署（如纯本地离线工具）。除此以外一律先部署再取证。
 - **类比**：请朋友来家里看新装修，却只发一张你自己手机里的照片——他既进不来、也没法确认这照片是不是你家。把地址给他（测试环境域名），他推门进来自己看，这才叫证据。

package/PULL_REQUEST_TEMPLATE.md

@@ -82,6 +82,7 @@ Closes #
 ## Test Plan
 
 <!-- 硬性必填：如何验证改动正确，附可复现步骤或证据（命令 + 结果、手动操作步骤、日志、请求响应、修复前后对比）。 -->
+<!-- ⚠️ 给出的命令 / URL 必须是别人拿到就能直接用的（测试环境 / 线上域名，不含本机私有路径、端口、容器名）；命令先在终端实际跑一遍再贴。 -->
 <!-- 禁止只写「tested locally / 测了没问题」。 -->
 
 ## Screenshots

package/package.json

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

package/rules/global.md

@@ -181,6 +181,7 @@ agent-rules 生成的规则文件分两层，行为与归属不同，评审/发
 - ⚠️ **功能验收 / 取证（给人看的截图、报告、PR 效果图）必须在「别人能直接打开的环境」（测试环境域名）上做，禁止用本地环境的结果交差。** 本地环境（`localhost` / `127.0.0.1` / `vite dev` / 各类「一键启动」脚本 / `file:///` 本机文档）的证据只有你自己看得到：它依赖你本机的数据库、配置中心取值、未提交的代码、正在跑的进程与端口——别人照同样的命令跑，得到的是另一套环境，复现不出你截图里的样子。**证据的价值在于别人能独立打开、独立复核；打不开的证据等于没有证据。**
 - ⚠️ **正确顺序：改完代码 → 部署到测试环境（走 `/deploy-test`）→ 在测试环境域名上操作取证。** 禁止在本地截完图再补一句「测试环境效果相同」——那是推断，不是证据（呼应「⚠️ 环境配置禁止推断」）。
 - ⚠️ **本地环境允许用于开发中的即时联调与排错，但产出的截图/结果一律不得作为交付证据。** 一句话自查：**这张图 / 这个 URL 发给别人，他在自己电脑上能直接打开看到同一个页面吗？** 不能 → 它不是证据，先部署到测试环境再重新取证。
+- ⚠️ **交出去的「入口」不只是截图 URL，还包括命令——两者都必须是别人拿到就能直接用的**：给 URL → 别人在浏览器里一贴就能打开（测试环境 / 线上域名）；给命令（curl / 部署脚本 / 复现步骤）→ 别人在自己机器上复制粘贴就能跑，**不得引用只有你本机才有的东西**（本机路径、`localhost:端口`、容器名、未提交的文件、正在跑的本机服务）。一句话自查：**这段内容我原样发给同事，他什么都不问、也不用额外装什么，能直接跑起来吗？** 不能 → 先补齐成别人可执行的形态（换成测试环境域名、补全参数）再交付（命令的完整性要求见「⚠️ 截图规范」）。
 - ⚠️ **依赖中间件的证据（Redis / 数据库 / 日志）同样连测试环境实例取证**，禁止截本机 Docker 里的 Redis / 本地库——本机实例的值与测试环境无关，证明不了任何事。
 - ⚠️ **例外（仅此两种，且必须在报告里写明「本地环境」及原因）**：① 功能尚未部署到测试环境、且用户明确要求「先看本地效果」；② 该环境客观无法部署（如纯本地离线工具）。除此以外一律先部署再取证。
 - **类比**：请朋友来家里看新装修，却只发一张你自己手机里的照片——他既进不来、也没法确认这照片是不是你家。把地址给他（测试环境域名），他推门进来自己看，这才叫证据。