bmad-loop-sweep

延迟工作项扫描分类

目标： 将 {implementation_artifacts}/deferred-work.md 中每个选定的未关闭条目归类为机器可读的分类计划，供编排器验证并执行。

此工作流为只读且原生支持自动化：仅在 bmad-loop 扫描会话中运行。你绝不编辑台账，不编辑代码，也不提问。你唯一的输出是结果文件。（唯一例外是迁移模式，它只会编辑一个文件——台账。）

激活时

步骤 0：自动化检查与模式分派

运行：echo "${BMAD_LOOP_MODE:-}"

如果输出不是 1，说明此技能只能在 bmad-loop 扫描期间运行，然后结束本轮操作。否则，完整阅读 ./automation-mode.md——其中的规则和结果架构约束本次运行的全部过程。

如果调用包含 --migrate <manifest-path>，这就是迁移会话，而非分类：阅读 ./migration-mode.md 并遵循其中说明，而不是执行下面的步骤 1–4。

步骤 1：定位台账

运行：echo "${BMAD_LOOP_LEDGER:-}"

输出的路径就是台账——编排器已从项目的 BMAD 配置中解析该路径（v6 中为 {implementation_artifacts}，v7 中为活动计划文件夹），因此读取该文件，切勿重新推导路径；其目录为 {implementation_artifacts}。完整读取台账。未关闭条目是 ### DW-<n>: 块，其 status: 行的值为 open。如果输出为空，或者台账缺失或不可读，则按照 automation-mode.md 的规定升级为 CRITICAL（type: missing-ledger），然后结束本轮操作。

带有 archived: 行的条目在此处仅保留存根——其完整正文位于同级的 deferred-work-archive.md 中，以相同的 DW- ID 为键；分类该条目前，先读取归档中的内容。archived-body: 行表示条目曾被归档、之后又重新打开：它再次成为待处理工作，但关闭前的正文仍在归档文件中，位于以该行所示日期标记的块内。

如果调用包含 --only DW-1,DW-2,...，这些 ID 就是本次会话的完整分类范围。完整读取台账，但只核实并划分这些指定的未关闭条目；不要将其他原始未关闭条目加入 open_ids 或任何结果类别。编排器已经应用了操作者指定的子集或严重性下限筛选器，并会根据这一确切范围验证你的结果。

如果调用包含 --feedback <path>，请先读取该文件——它列出了你上一次尝试的 result.json 未通过的确定性验证错误。本次输出中只修正这些缺陷。

步骤 2：根据代码核实每个选定条目

台账中的状态并不可靠：后续工作通常已经解决了条目所述问题，却从未将其标记为已完成。对于分类范围内的每个条目：

1. 阅读其 location:（文件/组件），并检查当前代码树。
2. 检查所述问题是否仍然存在——阅读代码，搜索相关症状，并检查 git log，查看从条目 origin: 日期之后是否有提交改动过相关区域。
3. 无论问题是否仍存在，都记录具体证据。“可能已修复”不算证据；文件:行号或提交哈希才算。

如有可用的子 Agent，则并行核实；绝不询问是否可以这样做。

步骤 3：分类

将分诊范围内的每个条目准确归入一个类别：

• already_resolved — 代码中已不存在该问题。必须提供具体的 evidence（当前已处理该问题的文件:行号，或修复问题的提交）。协调器会确定性地关闭账本条目。
• bundles — 现在即可构建：修复所需的每个文件都已存在，无需等待未来的故事落地。将共享触点（同一文件、同一子系统或同一验证器模式）的条目分组成目标明确的单一工作包，规模以一个开发会话可完成为宜；单独成项的条目组成仅含一个条目的工作包。name 必须匹配 ^[a-z0-9][a-z0-9-]{1,39}\Z（kebab-case，最多 40 个字符；例如 unicode-string-hardening），intent 用 2–6 句话描述这一连贯目标。
• blocked — 只有在指定的未来故事/史诗落地后，修复才有意义（或才更容易实施）。逐字写出阻塞项名称。
• skip — 已被取代、无关紧要，或涉及项目明确排除的场景。说明原因。
• decisions — 必须由人做出选择。始终归为决策，绝不能归为工作包：重新协商规范中 <frozen-after-approval> 块内的任何内容、推翻经人工批准的范围决策、会波及尚未构建的使用方的 API 形态变更，以及因“auto-mode: needs human decision”而延期的条目。每项决策都要提供 2–4 个具体选项（每个选项包含一个 effect：build + 实施意图、close + 可选的解决说明，或 keep-open），并给出 recommendation。唯一例外：如果重新协商冻结块显然能带来净收益、不会造成破坏且能收紧行为，则可将其纳入工作包；不确定时，归为决策。

分诊范围内的每个条目都必须且只能出现在一个类别中。协调器会确定性地验证这一点；遗漏或重复计数任何条目都会导致整个结果失败并消耗一次重试。

如果某个工作包的预期交付物仅限于代码仓库内已配置的 implementation_artifacts 目录中的忽略内容，请在现有的 intent 字段中描述这些交付物及其位置。不要添加分诊回执字段，也不要代执行会话声明回执。该会话仅在其自身最后一份真实的 ## Auto Run Result 中，且实际交付物符合条件时，才可在 Status: 旁的独立一行写入 Artifact only: true；true 必须与标签位于同一行，且其后不得附加说明，绝不能仅依据旧产物作此声明。标记必须由当前会话撰写，位于围栏代码块之外，且不得附带协调器修复说明；frontmatter 不构成此声明，值必须是严格布尔值 true。常规工作成果探测必须先明确确认无更改，回执门槛则要求针对该目录获得明确的忽略文件列表。其他所有验证和账本关闭检查仍然适用。在隔离的工作树中，成功集成会在拆除前发布已接受的忽略工作包规范。其他忽略的普通文件必须在已接受规范的 artifact_deliverables frontmatter 列表中列出，并使用相对于 implementation_artifacts 的精确路径。请在工作包的 intent 中描述这些预期输出，以便执行会话声明它们。禁止使用目录、glob、绝对路径、路径遍历和符号链接；协调器拥有的账本和冲刺看板也不得列入；未声明的文件不会被复制。发布检查会核对执行前捕获的目标基线。若主工作区存在冲突更改，发布会暂停，并保留源产物以供恢复。仅有回执并不会发布文件。

步骤 4：写入结果并结束本轮

按照 ./automation-mode.md 编写 result.json，并用一行说明各类别分别包含多少条目。结束本轮。除结果文件外，不要编辑任何文件。