# 恢复工作流程 ## 概述如果 BF 工作流程由于会话中断、达到上下文限制、错误等而在中间停止，则会分析 sprint-status.yaml 的状态，并从适当的点恢复工作流程。使用与 bf-execute 相同的史诗单元循环来维护人类系统边界。 ## 何时使用 * Claude Code 会话中断后继续工作流程时 * 当用户输入`/bf-resume` * 当用户想要使用“/bf-resume --from {EPIC-ID}”从特定史诗恢复时 ## 先决条件 * `docs/sprint-status.yaml` 存在 * `docs/tech-specs/{TICKET}-tech-spec.md` 存在 ## 错误处理 * sprint-status.yaml 不存在：“没有正在进行的冲刺。使用 `/bf-spec` 启动新的工作流程。”信息 * 技术规格不存在：“技术规格文件不存在。请先使用 `/bf-spec` 创建技术规格。”信息 * 在`--from`中指定不存在的EPIC-ID：注意“Epic '{EPIC-ID}'在sprint-status.yaml中不存在。可用的史诗：{史诗列表}” * yq 未安装：“yq 未安装。使用 `brew install yq` (macOS) 或 (Linux) 安装它。”信息 ## 说明 ### 1\.现状分析 **yq先决条件检查**（第一次）：命令 -v yq >/dev/null 2>&1 || { echo "❌ yq 未安装。安装：brew install yq"; 1号出口； } 阅读 docs/sprint-status.yaml 并分析当前的 sprint 状态。 ### 2\. --来自选项处理如果给出了“--from {EPIC-ID}”选项，**从头开始重新运行整个史诗**： * 将史诗中**所有**故事（包括完成）的`status`重置为`todo`，将`tdd`重置为`pending`，将`review`重置为`pending`： # 对史诗中的每个Story执行单独的yq命令（防止select+赋值组合的不稳定就地操作） yq -i '....status = "todo" | ....tdd =“待处理”| ....review =“待处理”' docs/sprint-status.yaml # 对每个 Story 重复执行 * Epic 的 e2e 状态也重置为“pending”： yq -i '...e2e = "pending"' docs/sprint-status.yaml * 如果`.ralph-progress/`目录下有对应史诗故事的进度文件（`{STORY-ID}.json`），则将其删除（清理之前的Ralph Loop进度文件）。 * 保留指标字段（之前尝试的记录）。 * 设置恢复点为**对应的史诗**。 > **注意**：`--from` 是史诗的完整重新运行。如果您只想重新运行不完整的 Story，请在不带“--from”的情况下运行它，它将自动确定。 ### 3\.确定自动恢复点当不带选项运行时，恢复点将根据以下优先级自动确定（**从顶部按顺序检查并应用第一个匹配**）： **a) 当没有 Story 时（sprint-status.yaml 存在但 Story 未创建）：** * 恢复点：**计划阶段**——从编排计划模式开始 **b) 如果有一个故事的状态为“status: in_progress”：** * 使用 git status 检查未提交的更改 * 有更改：用户被告知“{STORY-ID} 有未提交的更改正在进行中。”确认后处理： * **“保留更改”**（默认）：保留每个故事的分支： git checkout -b bf-stash/{故事-ID} git add --all -- ':!docs/' && git commit -m "[{TICKET}] 备份中止工作" git checkout {起源分支} 通知用户：“已备份分支`bf-stash/{STORY-ID}`。如有必要，您可以使用`gitcherry-pick`恢复它。”信息 * **“放弃更改”** ：使用 `git checkout -- .` 删除未提交的更改 * 无论哪种情况，重置为`status: todo`、`tdd:ending`、`review:pending`→当epic恢复时，从头开始实现一个新的代理 * 当多个故事同时进行时：识别每个故事的更改文件并将它们存储在单独的分支中。如果文件归属不清楚，请将整个文件保存在 `bf-stash/mixed-{EPIC-ID}` 中 * 如果 `ralph_stuck: true`：bf-lead-implement 崩溃无法报告给 Orchestrate。将其设置为“状态：已跳过”以防止编排重新处理它。 * 无变化（`ralph_stuck: false`）：检查 git log 中是否存在对应 Story ID 的提交。 git log --oneline --grep="{STORY-ID}" | git log --oneline --grep="{STORY-ID}" |头1 * **提交存在**：代理在提交后但在报告（包括 Lead 崩溃）之前停止。设置为“状态：完成”、“tdd：完成”。如果 `.ralph-progress/{STORY-ID}.json` 存在，则 `ralph_retries` 和 `ralph_approaches` 会反映在 sprint-status.yaml 中（`model_used` 由 bf-lead-implement 确定，因此在本例中保留为 `null`） * **提交不存在**：实施尚未开始或中途停止。重置为“状态：待办事项”、“tdd：待处理”、“审核：待处理” * 如果 `.ralph-progress/` 目录下有对应的 Story 进度文件，则将其删除（仅重置 Story） * 恢复点：**适用的史诗** **c) 如果您的史诗不完整（有些故事是“todo”或 e2e/review 不完整）：** * 恢复点：**对应的史诗**（编排史诗模式读取 sprint-status.yaml 并跳过已经完成的故事） **d) 如果所有史诗的 e2e 都是最终状态（“通过”|“跳过”|“升级”|“最大回归周期”）并且所有故事都是“审核：已批准”：** *“所有史诗都已完成。运行`/bf-archive-sprint`。”信息 * 结束。 ### 4\.恢复点的呈现工作流程恢复点分析 - 门票：{TICKET} - 当前状态：{状态摘要} - 恢复史诗：{epic-id}（总共 N 个中的第 M 个） - 跳过故事：{显示列表（如果有）} - 原因：{基于判断} 您想继续吗？如果有跳过（卡住）的故事，则会一起显示。由于它在之前的执行中已经自动跳过，因此如果有人想要修改它，他们可以在检查史诗结果时使用modification.md来指示它。 ### 5\.恢复执行用户确认后，根据恢复点： **计划未完成：** *生成一个编排（计划模式）（“模型：十四行诗”——计划模式充当一个简单的路由器） * 通过：技术规范路径、conventions.md 路径 * 收到后：向对方呈现 sprint-status.yaml 中的史诗/故事结构。 * 之后，进入史诗循环（第6步） **史诗般的简历：** * 输入与 bf-execute 相同的史诗循环（第 6 步） ### 6\.史诗循环（与 bf-execute 相同）我们将从恢复史诗开始按顺序游览。对于每个史诗： #### 6a。重生编排（史诗模式） * 使用任务工具`model: opus` * 传递：`mode: "epic"`、`epic_id`、技术规范路径、conventions.md 路径。 * 修改重新执行时：添加要传递的“modification_path”。 * 听： `"done"` \+ sprint-status.yaml 的路径 + review.md 的路径 #### 6b。呈现史诗般的成果编排完成后，它会读取 sprint-status.yaml 和 review.md 并将它们呈现给人类： ## 史诗 {EPIC-ID} 已完成 ### 故事结果 |故事|状态 |难度|重试次数 |卡住了| |--------|------|--------|----------------|--------| |故事1 |完成 | S | 0 | - | |故事2 |完成 |中号 | 2 | - | |故事3 |跳过（卡住）|左 | 5 |参见卡住.md | ### E2E：{通过|跳过 |升级 |最大回归周期} ### 集成审核：阻止 {N} 个案例，推荐 {N} 个案例 ### 详细信息：docs/reviews/{EPIC-ID}-review.md > ⚠️（仅在跳过所有故事时显示） > 这部史诗中的所有故事都被跳过（卡住）。当继续执行时，该功能将转至尚未执行的状态。您想继续吗？ 1. 进入下一个史诗 2.修改后重新运行（输入修改详情） 3. 工作流程中断 #### 6c。人类判断处理根据个人的选择： **1\.继续下一个史诗：** * 在 sprint-status.yaml 中反映史诗的人类接受状态（使用 `yq -i`）： * 将“状态：已跳过”的故事的“审核”设置为“已批准”（人类接受跳过） * 将“status:done”故事的“review”设置为“review:pending”为“approved”（人类接受阻止者） yq -i '....review = "approved"' docs/sprint-status.yaml yq -i '....review = "approved"' docs/sprint-status.yaml * 移至下一个史诗的 6a。 **2\.修改后重新运行：** * 一个人以文本形式输入更正。 * bf-resume 分析修改，推断目标 Story，并与人确认。 * 记录在`docs/reviews/{EPIC-ID}-modification.md`中（与bf-execute的modification.md格式相同）。 * **不要 git commit** — 文档/输出在第 4 阶段存档中集体提交。 * 在史诗模式下为同一史诗重新生成编排（传递“modification_path”）。 * 返回 6b 并再次呈现结果。 **3\.工作流程中断：** * 通知当前状态并退出。 ### 7\.完成完成完成所有史诗后，后处理步骤的指导方式与 bf-execute 相同。工作流程已完成。后续步骤： 1. /bf-archive-sprint — Sprint 归档 2. /bf-metrics — 指标分析（可选） 3. /bf-update-conventions — 更新约定 ## 输出格式恢复点分析结果通过对话框输出，并在用户确认后执行史诗单元循环。除了modification.md 之外，没有创建单独的文件。

男朋友简历

包含技能