@routerhub/agent-rules 1.5.194 → 1.5.195

package/AGENTS.base.md

@@ -170,6 +170,13 @@ agent-rules 生成的规则文件分两层，行为与归属不同，评审/发
   - **类比：一扇推拉门，两个人同时从两边推——门没坏、两个人也都没错，可在同一个瞬间两边同时用力，谁也推不开。表面像「门卡住了」，其实是时序撞上了；解决办法不是修门，是让两边错开时间。**
   - 反面示例：解释「强制改密后登录卡死」只报「PublicRoute 弹回 + persist 残留 + handle401 对踢」机制链，不给「来回踢的窗口里你点的登录被吞了」这版人话——用户每个词都认识，却无法确认「对，就是我遇到的那个」。
   - 自查：报这类根因前先自问——「把这段文字只发给用户、不附任何口头解释，他能复现并确认『对，就是它』吗？」能 = 合格；不能 = 先补人话版再发。
+- ⚠️ **带「状态切换 + 跳转」的流程，验证必须主动演练「前置强制状态」与「切换后不等落定立即抢操作」两条时序路径，禁止只走正常路径就算验证完成。** 上一条（时序抢跑识别）解决「撞上了要认出」，本条解决「根本没机会撞上」——凡流程含改密 / 强制改密 / 强制下线 / 登出 / 会话过期自动重登 / 被踢等「状态一变、页面就跳走」的环节，功能验证清单不能只测 happy path，必须额外覆盖两条时序路径，缺一不算验证完成：
+  1. **前置强制状态**：先造出「运营强制置出来的状态」（如 `must_change_password=1` 的账号）再走完整流程——happy path 测不到的，恰恰是这些被置出的状态触发的分支；
+  2. **切换后立即抢操作**：状态切换（改密成功 / 登出 / 被踢 / token 失效）后**不等页面与请求落定，马上点下一步**（立即点登录 / 快速连点 / 立刻刷新）——时序类 bug 就藏在「过渡没完成就抢」的那一下，等页面稳定再点永远踩不中。
+  - **验证顺序**：先正常路径（证明功能能用）→ 再两条时序路径（证明过渡态不卡、不残留、不被吞）；时序路径复现不出问题时，才可判定验证通过。
+  - **类比：验证「两个人同时过一扇门会不会撞上」，不能让测试每次都只让一个人过门——必须专门安排「两个人同时过」这一下，才可能撞出问题；只验单人次 = 门永远不撞 = 问题测不出来。**
+  - 反面示例：验证「强制改密后重新登录」，只测「改密成功 → 页面稳定 → 输入新密码登录」正常路径，不造 `must_change_password=1` 账号、不在改密成功被弹回的 1.5s 窗口里抢点登录——bug 永远复现不了，上线后用户一操作就卡在 Signing in…。
+  - 自查：验证这类流程前先自问——「前置的『被强制状态』我造了吗？切换后的『不等落定立即抢』我试了吗？」任一为否 = 时序路径没测全，先补再交付。
 
 ## Git 规范
 

package/package.json

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

package/rules/global.md

@@ -170,6 +170,13 @@ agent-rules 生成的规则文件分两层，行为与归属不同，评审/发
   - **类比：一扇推拉门，两个人同时从两边推——门没坏、两个人也都没错，可在同一个瞬间两边同时用力，谁也推不开。表面像「门卡住了」，其实是时序撞上了；解决办法不是修门，是让两边错开时间。**
   - 反面示例：解释「强制改密后登录卡死」只报「PublicRoute 弹回 + persist 残留 + handle401 对踢」机制链，不给「来回踢的窗口里你点的登录被吞了」这版人话——用户每个词都认识，却无法确认「对，就是我遇到的那个」。
   - 自查：报这类根因前先自问——「把这段文字只发给用户、不附任何口头解释，他能复现并确认『对，就是它』吗？」能 = 合格；不能 = 先补人话版再发。
+- ⚠️ **带「状态切换 + 跳转」的流程，验证必须主动演练「前置强制状态」与「切换后不等落定立即抢操作」两条时序路径，禁止只走正常路径就算验证完成。** 上一条（时序抢跑识别）解决「撞上了要认出」，本条解决「根本没机会撞上」——凡流程含改密 / 强制改密 / 强制下线 / 登出 / 会话过期自动重登 / 被踢等「状态一变、页面就跳走」的环节，功能验证清单不能只测 happy path，必须额外覆盖两条时序路径，缺一不算验证完成：
+  1. **前置强制状态**：先造出「运营强制置出来的状态」（如 `must_change_password=1` 的账号）再走完整流程——happy path 测不到的，恰恰是这些被置出的状态触发的分支；
+  2. **切换后立即抢操作**：状态切换（改密成功 / 登出 / 被踢 / token 失效）后**不等页面与请求落定，马上点下一步**（立即点登录 / 快速连点 / 立刻刷新）——时序类 bug 就藏在「过渡没完成就抢」的那一下，等页面稳定再点永远踩不中。
+  - **验证顺序**：先正常路径（证明功能能用）→ 再两条时序路径（证明过渡态不卡、不残留、不被吞）；时序路径复现不出问题时，才可判定验证通过。
+  - **类比：验证「两个人同时过一扇门会不会撞上」，不能让测试每次都只让一个人过门——必须专门安排「两个人同时过」这一下，才可能撞出问题；只验单人次 = 门永远不撞 = 问题测不出来。**
+  - 反面示例：验证「强制改密后重新登录」，只测「改密成功 → 页面稳定 → 输入新密码登录」正常路径，不造 `must_change_password=1` 账号、不在改密成功被弹回的 1.5s 窗口里抢点登录——bug 永远复现不了，上线后用户一操作就卡在 Signing in…。
+  - 自查：验证这类流程前先自问——「前置的『被强制状态』我造了吗？切换后的『不等落定立即抢』我试了吗？」任一为否 = 时序路径没测全，先补再交付。
 
 ## Git 规范