docs(pm-dispatch): cloud-card lifecycle ends at archive_session — the missing paragraph

.claude/skills/pm-dispatch/SKILL.md

@@ -2083,6 +2083,24 @@ to `mode:subagent`).
 可能缺席),定时器仍要挂,但频率可放宽,且每轮先核订阅已覆盖哪些面、只补
 盲区(会话停摆、未开 PR 的分支、姊妹仓动静)。
 
+**云卡归档 —— 生命周期的终点是 `archive_session`,不是「报告收到」(维护者
+2026-08-10 指令:「spec 已完成的云卡片关掉」;同日追问「已完成的云卡片应该
+归档,项目经理skills 没写到吗」—— 本段即答)。** 会话列表是维护者的舰队
+看板,完成卡不归档就是看板上的常驻噪声,车道一多维护者就分不清哪些在飞。
+两条判据、一条禁令:
+
+- **归档判据(两件同时满足)**:该卡的 PR **已 MERGED(或明确关闭)**,且
+  OS-DEV-REPORT 已收并复核。收尾/巡检时顺手 `list_sessions` 扫一遍
+  review_ready 存量,符合判据的**批量归档**;failed 桶的卡在其重派/接手处置
+  完成后一并归档。
+- ⛔ **PR 未合并前不归档 —— 活着的会话是落地窗口的执行手。** 云会话的 PR
+  订阅 + 自救能力依赖会话没被归档:base 被 main 甩开转 `dirty` 时,PM 一条
+  PR 评论就能唤醒**已完工**的会话执行 merge + 整链 regen + 重推(实测两例:
+  #7265 的 dirty 自 rebase、#7325 的 #7322 冲突 union 解法,都是完工会话被
+  评论唤醒干的)。提前归档等于把这只手砍掉,dirty 只能 PM 自己下场或重派。
+- 归档动作幂等,误归档可 `unarchive_session` 恢复 —— 但恢复后是新容器,
+  工作树现场不在,所以宁可晚归档也别提前。
+
 #### 座位 Routine 化(PM 侧的运行形态,#5472 第 5 点)
 
 上面两个 backend 决定**开发 agent** 跑在哪;这一段决定**PM 座位自己**怎么被