feat(req): REQ 连续推进（continuous）模式 + checkpoint

- 新增 req-workflow/skills/references/continuous-mode.md：阶段自动循环、hard/soft 门禁分级、checkpoint schema、恢复协议、停止格式、staging 终点约定
- req / req-workflow SKILL.md 增加 continuous 小节与门禁分级说明
- 版本号、CHANGELOG、docs/skill-routing.md、catalog.json 同步

skills-req/req-plugin/skills/SKILL.md

@@ -29,21 +29,24 @@ analysis → design → dev → review → testing → [待部署池] → releas
 - **讨论结束后必须输出方案确认摘要**（强制流程：讨论 → 摘要 → 用户确认 → PRD）：
   1. AI 输出结构化摘要（`## 讨论结论` 章节），`ai-proj req update` 追加到 description 末尾
   2. AskUserQuestion 确认：「方案确认通过」或「需要修改」
-  3. **用户确认后才能开始 PRD 编写，禁止跳过确认**
+  3. 用户确认后才能开始 PRD 编写；**无人值守/连续模式下「讨论摘要确认」按 soft 门禁处理** — 在 `## 讨论结论` 标注「待用户确认」并写入 checkpoint 后继续，但不得据此自行变更方案或需求范围（方案/范围变更仍是 hard 门禁）
 - 需求描述三段式（技术方案写入 PRD，不写在需求中）：
   1. **需求描述** — 问题背景、现状痛点
   2. **预期结果** — 期望达到的效果
   3. **验收标准** — 可检查的完成条件（checklist，≥2 条）
 - PRD 文档是提交评审的前置条件；代码评审是测试的前置条件
-- **force=true 禁止自动使用** — 门禁未通过时必须 AskUserQuestion 确认 + 记录跳过原因
-- **评审必须用户确认** — 禁止 AI 自审批
+- **force=true 禁止自动使用** — 门禁未通过时必须 AskUserQuestion 确认 + 记录跳过原因（**hard 门禁**）
+- **评审必须用户确认** — 禁止 AI 自审批（**hard 门禁**）
+- **只有 hard 门禁才必须停下问人** — hard：需求方案确认、PRD 评审通过、生产发布授权、`force` 放行、密钥/权限缺失、需求范围变更；硬门禁未清空时禁止推进下一阶段
+- **soft 门禁不停** — 讨论摘要确认、部署范围确认属 soft：无人值守/连续模式下按默认策略继续（摘要写 `## 讨论结论` 后即推进；部署范围按 REQ 关联任务推导），把「待用户确认」写入 checkpoint / REQ 备注，交付时统一列出
+- **每次阶段切换写 checkpoint** — 写 `.ai-proj/req-<id>.state.json`（`stage` / `evidence` / `next_command` / `blockers`），新会话先读它再推进；规则见 `req-workflow` 技能的 `references/continuous-mode.md`
 - **归档前 AC 逐条验收（Gate 0，强制）** — `/req done` 必须先提取需求描述中的验收标准逐条确认，无 AC 或有未确认项均阻断，用户必须提供证据或说明跳过原因
 - **归档前类型化门禁检查** — Gate 0 通过后，`/req done` 再按需求类型（code/skill/ops）动态检查
 - **部署是项目级动作**，由 `/req deploy` 统一触发
 - **需求完成后必须 git 提交并 push** — commit 格式：`feat(skill): REQ-XXXX 需求标题`
 - **操作前先确认实际 ID** — 从 URL 提取 ID（如 `/requirements/897` → ID=897）
 - **务实路线关闭也必须补全关联任务** — 每个进度条阶段需创建关联任务
-- **阶段内容门禁（防空转）** — `/req next` 时检查关键阶段任务是否有实质内容
+- **阶段内容门禁（防空转）** — `/req next` 时检查关键阶段任务是否有实质内容（连续模式下缺内容就补齐文档再推进，不停下等确认）
 - **复用盘点先于估工（Gate 5，强制）** — PRD 必须含「现有实现与复用盘点」章节：每个能力点给出**现有实现（file:line）+ 结论（复用 / 改造 / 新增）**；结论=复用/改造的只按「接入差异」估工，结论=新增的必须写「为什么现有实现不能满足」。没有 file:line 证据、或标「未排查」的，**禁止 submit、禁止按全新增估工**；独立复查由非 PRD 写作者用 grep 复核并在 note 留命令与命中结果
 - **Harness 环境检测** — `/req dev` 启动开发前，快速检测项目基础设施（`.husky/` 存在？`scripts/check-*.sh` 存在？）。若两者都不存在（Level 0），输出一行提示：「项目无质量护栏，建议先运行 `/harness init`」。检测结果不阻塞开发，仅提示
 
@@ -149,7 +152,7 @@ PDV 结论: ✅ 全部通过 / ❌ {N}项失败，阻断推进
 | **testing** | 测试任务有文档，含测试结果表格，含通过/失败结论 |
 | **staging** | 部署任务有文档，含健康检查结果 |
 
-未通过 → AskUserQuestion（补充文档 or 强制跳过+记录原因）
+未通过 → AskUserQuestion（补充文档 or 强制跳过+记录原因）；continuous 模式下默认「补文档后继续」并写 checkpoint，不停下等待
 
 ### 部署门禁（推进到 released 前）