日常工作流

RSP 根据用户意图、仓库权威信息、尚未明确的重要决策、风险与当前证据，选择所需 Skill 和工作流深度。范围明确的直接任务无需制造 Change 或规划阶段。职责按需选择；权限充分时在同一请求内推进到完成，无需人为续行提示。

选择当前工作

先根据请求、项目指令和现有归属证据，区分有界直接任务与跟踪工作。没有选定或必需 WorkOwner 的直接任务无需查询跟踪状态、readiness 或初始化 RSP。必需的跟踪记录缺失或损坏仍是缺口，不能借直接任务绕过。需要有效配置时，独立获取 rsp config --json，不以 status 成功为前提。

对于跟踪工作，用 status 和 show 检查；获得选择权限后，通过拥有该操作的 CLI 修改 focus。

rsp status
rsp focus <work-ref>
rsp show <work-ref>

.rsp/focus.d/ 中的标记文件组成轻量的 open-work FocusSet，表示当前仍在推进的候选 Change。使用选定的 WorkRef 明确查看；show --focused 要求恰好一个标记。存在多个聚焦的 Change 时，AI 根据用户明确提及、当前请求、状态和依赖选择默认操作对象；只有在修改或交付边界仍然实质不清楚时才询问。对于分组工作，先阅读同级 Group Brief，再阅读选定的子 Change。

修改前检查工作树，并保留无关的已修改、已暂存或未跟踪内容。聚焦、自动 focus 与就绪都不授予产品修改、Git、生命周期、发布或批准权限。

路由工作

结果或范围不清楚 → 塑造
有界设计问题 → Shape（无规划权限时只读）
原因不明的失败 → Implement 的只读诊断；原因确认且修正获授权时再修复
显式要求或具体风险需要测试先行 → Implement 的测试先行方法
证据充分的普通变更 → Implement 与自身相称检查
固定比较范围的请求 → 审查
已授权的仓库文档或 Skill 写作 → Doc
已接受的固定发现 → Implement 修正；Core 协调所需复审
发布说明写作 → Doc 的发布方法
固定范围的发布文档评审 → Review 的 Document 流水线
已授权但没有 WorkOwner 的发布检查 → Core 与项目声明的检查

职责明确时可直接调用对应能力，无需先完整执行 Core。各能力在目标、范围、权限、基线和必需证据不变时选择允许的方法。一轮有界修正及其检查由 Implement 完成；跨能力的修正／审查循环归 Core 所有。明确命名的检查、溯源操作和必需独立 worker 仍是要求。跟踪工作保留现有 Change，无需第二份计划或工作流状态。

根据实际义务选择深度，而不是按文件数量：

• 范围明确且已授权的修复使用 Implement 及其相称检查。需要解决重要决策时使用 Shape；单独请求或要求收集验证证据时使用 Verify。
• 相互独立且就绪的工作可分派给不同 worker。依赖方等待前置工作；共享生成产物或测试资源的 worker 顺序执行，除非已确认安全隔离。
• 仅审查的请求保持只读。修复并审查的组合请求使用 Core 的唯一有界循环，并保留所需独立审查者。

RSP 决定是否委派，以及依赖已就绪的工作能否安全并行；宿主提供实际 worker、隔离、等待和取消机制。分组工作先检查 rsp status --json，使用第一个就绪依赖波次，并在进入下一波前重新检查。worker 完成不等于结果已验收或执行相互独立。必需的执行归属和不同 worker 证据必须来自实际观察；可选委派可以退回本地执行，必需独立性不能替代。

父任务读取路由、权限和验收判断所需的指导，worker 读取自身执行方法。父任务在亲自执行或需要解决具体边界／证据问题时，再读取 worker 的方法细节；worker 的必要阅读、父任务结果核验和必需独立检查仍须完成。

自动代理默认关闭，明确代理义务仍须满足；启用后由用户或主代理决定数量。关闭策略独立：普通完成和检查点提交保持打开，最终交付按 ask／auto／manual 处理。见工作流策略。

保持 Change 与现实同步

• 实现推翻原计划时更新 Proposal、Spec 或 Design。
• 仅在结果存在后勾选 Tasks。
• 在 Verify 的 ### Required 下记录验收关键证据，在 ### Optional 下记录额外环境、兼容性、规模或信心覆盖；Optional 遗漏保持可见但不阻断完成。
• 把尚未解决的外部或技术约束保留在 Blockers。
• 优先选择成本最低的决定性验证。仅当新测试保护可观察行为或真实边界，并带来独立的长期信心时才保留。

仅用精确的依赖阻塞项指向另一个可执行 Change：

- requires `authentication/session-model`: 必须先落地会话归属关系

验证与审查

完成最后的相关修改后，复用被测范围和相关内容、依赖、配置、工具、输入及环境仍然适用的可追溯通过证据。输入或被测边界变化会使相应证据失效；运行缺失、失败或已失效的必需检查及按风险选择的额外覆盖。显式重跑要求、当前观察和必需独立执行仍然有效；仅仅切换阶段不会使证据失效。工具或环境缺失表示验证不可用；实际执行发现缺陷表示验证失败，二者都不能描述为通过。

遇到纯工具障碍时，先诊断原因并检查实际副作用，再决定恢复。可在同一边界内继续只读或已证明可安全重复的工作；不得盲目重放一次性操作或绕过安全拒绝。允许的替代方法必须保留必需证据，不能用较弱结果替代精确命名的检查。未知修改、缺少必需证据或独立 worker、权限变化仍须停止，并报告已观察副作用、缺失条件和安全的下一步。

Review 对固定比较范围给出当前语义判断并保持只读；可复用的通过检查不能替代审查。对于已授权的修正与审查，Core 核实发现，将每轮有界修正及受影响检查交给 Implement，再获取新的 Review。已接受且未超范围的发现在限定修正次数内自动继续；Implement 不得自证审查通过或另起循环。出现重要决策、权限变化、必需证据不可用或无法收敛时停止，并保留所需独立性。

在这个范围内，Code 检查行为与工具语义，Document 检查解释与使用指导。API 注释与可复制示例可能需要两者；普通注释和示意伪代码仅接受适用检查。把实现作为证据读取，不会使它成为被审目标；代码围栏也不授予执行权限。文本与行为不一致时只报告一个根因，不自动认定实现正确。职责边界见按证据组合套件。

持久化判断与归档

仅更新现有 Tasks/Verify 时，检查所属 Change 是否存在矛盾，直接记录实际结果并核对更新后的证据。若已接受的范围、合同、设计和稳定知识仍准确，且没有准备生命周期收尾或最终交付，检查通过或恢复执行本身不增加 Doc/写回阶段。必需检查、Review 和未完成结果仍须如实保留。发现矛盾或需要更新知识时，退出这条直接路径。

需要更新稳定知识，或正在准备生命周期收尾/最终交付时，分别判断是否需要：

• 更新已有 Spec 或作用域指令，或创建新的持久化 Spec；
• 为长期理由创建或更新 Decision Record。

普通知识更新只需核实相关事实、更新对应归属并协调受影响的工作记录。保留未完成工作；这不要求最终的整份 Change 收敛、readiness 或关闭决定。

最终交付或准备关闭时，先核实结果事实，提炼有用的 Focus 内容，并把需要更新的稳定知识写回对应归属。然后收敛整个 Change：保留已交付变化、重要失败、限制和证据指针，移除过时计划、重复 Specs 和会话流水。检查最终 Change 与已更新的知识文档，完成所需 Review，再获取当前 readiness。必要写回与最终一致性检查仍须完成；已经收敛的记录无需美化性改写或例行无变更报告。

对获得独立生命周期权限的已跟踪 Change，通过拥有该操作的 CLI 检查就绪状态并在允许时归档。普通未跟踪工作没有归档步骤；方法选择不授权手动修改 focus 或归档文件：

rsp ready <work-ref> --json
rsp archive <work-ref>

rsp ready 提供必须完成门禁、可选覆盖警告与语义审查信号，不提供语义批准。要求 completionGate: pass 和 archiveReady: yes，并在收尾前检查实际必需证据与持久化判断。Tasks、Required Verify 或 blocker 未完成时，rsp archive 会 fail closed；成功后检查生命周期 diff，交付前再检查完整的目标交付范围。提交、推送、发布、部署、批准与人工验收仍是独立权限。

恢复

如果后续证据表明原验收条件实际未满足，使用明确理由重开同一标识：

rsp reopen <work-ref> --reason "<验收条件仍未满足的原因>"

多个归档匹配时，增加精确的 --from .rsp/archives/... 路径。Group 已关闭时先重开 Group。真正的新范围或独立交付的修正使用新 Change。