bmad-loop-sweep

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Deferred-Work Sweep Triage

延后工作 Sweep 分流

Goal: Classify every selected open entry in

{implementation_artifacts}/deferred-work.md

into a machine-readable triage plan the orchestrator can validate and execute.

This workflow is read-only and automation-native: it runs only inside a

bmad-loop

sweep session. You never edit the ledger, never edit code, never ask questions. Your sole output is the result file. (The one exception is migration mode, which edits exactly one file — the ledger.)

目标： 将

{implementation_artifacts}/deferred-work.md

中每个选定的 open 条目分类为编排器可验证并执行的机器可读分流计划。

本工作流是 只读且原生自动化：它仅在

bmad-loop

sweep 会话中运行。你绝不编辑台账，绝不编辑代码，也绝不提出问题。唯一输出是结果文件。（唯一例外是迁移模式，它恰好会编辑一个文件——台账。）

On Activation

激活时

Step 0: Automation Check & Mode Dispatch

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

Run:

echo "${BMAD_LOOP_MODE:-}"

If the output is not

, state that this skill only runs inside a bmad-loop sweep and end your turn. Otherwise read

./automation-mode.md

fully — its rules and result schema govern this entire run.

If the invocation carries

--migrate <manifest-path>

, this is a migration session, not triage: read

./migration-mode.md

and follow it instead of Steps 1–4 below.

运行：

echo "${BMAD_LOOP_MODE:-}"

如果输出不是

，说明此 skill 仅在 bmad-loop sweep 中运行，然后结束你的回合。否则，完整读取

./automation-mode.md

——其规则和结果 schema 管辖整个运行。

如果调用参数包含

--migrate <manifest-path>

，则这是 迁移会话，而非分流：读取

./migration-mode.md

并遵循其中的说明，而不是执行下面的第 1–4 步。

Step 1: Locate the ledger

第 1 步：定位台账

Run:

echo "${BMAD_LOOP_LEDGER:-}"

The printed path is the ledger — the orchestrator resolved it from the project's BMAD config (on v6

{implementation_artifacts}

, on v7 the active initiative folder), so read that file and never re-derive it; its directory is

{implementation_artifacts}

. Read the ledger in full. Open entries are

### DW-<n>:

blocks whose

status:

line is

open

. If the output is empty, or the ledger is missing or unreadable, escalate

CRITICAL

(

type: missing-ledger

) per automation-mode.md and end your turn.

An entry carrying an

archived:

line keeps only a stub here — its full body lives in the sibling

deferred-work-archive.md

, keyed by the same DW- id; read it there before classifying that entry. An

archived-body:

line says the same of an entry that was archived and later reopened: it is live work again, but the body it carried before that close is still in the archive file, in the block stamped with the date the line carries.

If the invocation carries

--only DW-1,DW-2,...

, those ids are the complete triage universe for this session. Read the full ledger, but verify and partition exactly those named open entries; do not add other raw-open entries to

open_ids

or any result category. The orchestrator has already applied the operator's named-subset or severity-floor selector and validates your result against this exact scope.

If the invocation carries

--feedback <path>

, read that file FIRST — it lists the deterministic validation errors your previous attempt's result.json failed on. Fix exactly those defects in this attempt's output.

运行：

echo "${BMAD_LOOP_LEDGER:-}"

打印出的路径就是台账——编排器已从项目的 BMAD 配置中解析出该路径（在 v6 中为

{implementation_artifacts}

，在 v7 中为当前 initiative 文件夹），因此读取该文件，绝不重新推导；其目录是

{implementation_artifacts}

。完整读取台账。Open 条目是

status:

行值为

open

的

### DW-<n>:

块。如果输出为空，或者台账缺失或无法读取，则按照 automation-mode.md 升级为

CRITICAL

（

type: missing-ledger

），然后结束回合。

带有

archived:

行的条目在此仅保留一个存根——其完整正文位于同目录的

deferred-work-archive.md

中，以相同的 DW- id 为键；在对该条目分类之前，先在归档文件中读取正文。

archived-body:

行针对的是曾被归档、后来又重新打开的条目：它现在重新成为活跃工作项，但它关闭前所带的正文仍位于归档文件中由该行所带日期标记的块内。

如果调用参数包含

--only DW-1,DW-2,...

，这些 id 就构成本次会话完整的分流范围。完整读取台账，但只核验并划分指定的这些 open 条目；不要把其他原始 open 条目加入

open_ids

或任何结果类别。编排器已应用操作者的命名子集或 severity-floor 选择器，并会根据这一精确范围验证结果。

如果调用参数包含

--feedback <path>

，先读取该文件——其中列出了上一次尝试的

result.json

未通过的确定性验证错误。在本次尝试的输出中恰好修复这些缺陷。

Step 2: Verify every selected entry against the code

第 2 步：对照代码核验每个选定条目

Ledger statuses are known-unreliable: entries are often resolved by later work but never marked done. For EACH entry in the triage universe:

Read its
```
location:
```
(file/component) in the current tree.
Check whether the described issue still exists — read the code, grep for the symptom, check
```
git log
```
for commits that touched the area since the entry's
```
origin:
```
date.
Record concrete evidence either way. "Probably fixed" is not evidence; a file:line or commit hash is.

Use sub-agents for parallel verification when available; never ask permission.

台账状态已知不可靠：条目常常已被后续工作解决，却从未标记为 done。对分流范围中的每个条目：

读取当前目录树中其
```
location:
```
（文件/组件）。
检查所描述的问题是否仍然存在——读取代码、grep 症状，并检查
```
git log
```
，找出自条目的
```
origin:
```
日期以来触及该区域的提交。
无论结论如何，都记录具体证据。“Probably fixed”不是证据；file:line 或 commit hash 才是证据。

可用时使用 sub-agents 并行核验；绝不请求许可。

Step 3: Partition

第 3 步：划分

Classify each entry in the triage universe into exactly ONE category:

already_resolved — the issue no longer exists in the code. Requires concrete
```
evidence
```
(file:line that now handles it, or the commit that fixed it). The orchestrator closes the ledger entry deterministically.
bundles — buildable now: every file the fix needs already exists and no future story has to land first. Group entries that share a touchpoint (same file, same subsystem, same validator pattern) into cohesive single-goal bundles sized for one dev session; an entry that stands alone is a one-entry bundle.
```
name
```
matches
```
^[a-z0-9][a-z0-9-]{1,39}\Z
```
(kebab-case, at most 40 characters; e.g.
```
unicode-string-hardening
```
), and
```
intent
```
is 2–6 sentences describing the one cohesive goal.
blocked — the fix is only meaningful (or meaningfully easier) after a named future story/epic lands. Name the blocker verbatim.
skip — superseded, moot, or tied to a scenario the project explicitly excludes. Give the reason.
decisions — a human must choose. ALWAYS a decision, never a bundle: renegotiating anything inside a spec's
```
<frozen-after-approval>
```
block, reversing a deliberate human-approved scope decision, API-shape changes that ripple to unbuilt consumers, and entries deferred with reason "auto-mode: needs human decision". Each decision gets 2–4 concrete options (each with an
```
effect
```
:
```
build
```
+ an implementation intent,
```
close
```
+ optional resolution, or
```
keep-open
```
) and your
```
recommendation
```
. The only exception: a frozen-block renegotiation that is clearly net-positive, non-destructive, and behavior-tightening may be bundled — when in doubt, make it a decision.

Every entry in the triage universe appears in exactly one category. The orchestrator validates this deterministically; a missed or double-counted entry fails the whole result and burns a retry.

For a bundle whose intended deliverables are confined to ignored content in the configured

implementation_artifacts

directory strictly inside the code repository, describe those deliverables and their location in the existing

intent

field. Do not add a triage receipt field or assert a receipt on the executing session's behalf. That session may write

Artifact only: true

on its own line beside

Status:

, with

true

on the same line as the label and no trailing explanation, in its own last genuine

## Auto Run Result

only when its actual deliverables qualify, never based on old artifacts alone. The marker must be authored in the current session, outside fenced blocks and without an orchestrator repair note; frontmatter does not assert it, and the value must be the strict boolean

true

. The ordinary proof-of-work probe must first positively find no changes, and the receipt gate requires a positive ignored-file listing scoped to that directory. All other verification and ledger-close checks still apply. In an isolated worktree, successful integration publishes the accepted ignored bundle spec before teardown. Additional ignored regular files must be named in the accepted spec's

artifact_deliverables

frontmatter list, using exact paths relative to

implementation_artifacts

. Describe these intended outputs in the bundle's

intent

so the executing session can declare them. Directories, globs, absolute paths, traversal, symlinks, and the orchestrator-owned ledger and sprint board are forbidden; undeclared files are not copied. Publication checks destination baselines captured before execution. Conflicting main-checkout changes pause publication and retain source artifacts for recovery. The receipt alone does not publish files.

将分流范围中的每个条目归入且仅归入一个类别：

already_resolved — 该问题在代码中已不存在。必须提供具体
```
evidence
```
（现在处理该问题的 file:line，或修复它的提交）。编排器将以确定性方式关闭该台账条目。
bundles — 当前可构建：修复所需的每个文件都已存在，且无需先完成任何 future story。将共享同一修改点（同一文件、同一子系统或同一 validator 模式）的条目归并为适合一次开发会话完成的凝聚型单目标 bundle；独立条目则作为一个单条目 bundle。
```
name
```
必须匹配
```
^[a-z0-9][a-z0-9-]{1,39}\Z
```
（kebab-case，最多 40 个字符；例如
```
unicode-string-hardening
```
），
```
intent
```
则用 2–6 个句子描述同一个凝聚目标。
blocked — 只有在某个指定的 future story/epic 落地后，修复才有意义（或才会明显更容易完成）。原样写出 blocker 名称。
skip — 已被取代、已失去意义，或与项目明确排除的场景有关。给出原因。
decisions — 必须由人工选择。始终归为 decision，绝不能归为 bundle：重新协商 spec 的
```
<frozen-after-approval>
```
块内的任何内容，推翻人工明确批准的范围决策，波及尚未构建使用方的 API-shape 变更，以及以
```
auto-mode: needs human decision
```
为原因延后的条目。每个 decision 都要提供 2–4 个具体选项（每个选项都有一个
```
effect
```
：
```
build
```
+ 实施意图、
```
close
```
+ 可选解决方案，或
```
keep-open
```
），以及你的
```
recommendation
```
。唯一例外是：对 frozen block 的重新协商若明显带来净收益、不具破坏性且能收紧行为，则可以归入 bundle；如有疑问，归为 decision。

分流范围中的每个条目都必须且只能出现在一个类别中。编排器会对其进行确定性验证；漏掉或重复计入任何条目都会导致整个结果失败，并消耗一次重试。

对于预期交付物仅限于严格位于代码仓库内部的已配置

implementation_artifacts

目录中被忽略内容的 bundle，请在现有

intent

字段中描述这些交付物及其位置。不要添加分流回执字段，也不要代替执行会话声明回执。执行会话可以在其自身最近一次真实的

## Auto Run Result

中，于

Status:

旁另起一行写入

Artifact only: true

；

true

必须与标签位于同一行，且后面不得有说明文字。仅当该会话的实际交付物符合条件时才可以这样做，绝不能仅依据旧有 artifacts 作出声明。该标记必须由当前会话生成，位于 fenced blocks 之外，且不得带有 orchestrator 修复注记；frontmatter 不能代替声明该标记，值必须严格为布尔值

true

。常规 proof-of-work 探针必须先明确确认没有变更，而回执门禁要求提供限定于该目录的已忽略文件列表，作为正向证明。所有其他验证和台账关闭检查仍须适用。在隔离的 worktree 中，成功集成后会在 teardown 之前发布已接受的 ignored bundle spec。额外的已忽略普通文件必须在已接受 spec 的

artifact_deliverables

frontmatter 列表中逐一列明，并使用相对于

implementation_artifacts

的精确路径。请在 bundle 的

intent

中描述这些预期输出，以便执行会话进行声明。禁止目录、globs、绝对路径、路径穿越、symlinks，以及 orchestrator 所属的台账和 sprint board；未声明的文件不会被复制。发布操作会检查执行前捕获的目标基线。主检出目录中发生冲突变更时，会暂停发布并保留源 artifacts 以便恢复。仅生成回执不会发布文件。

Step 4: Write the result and end your turn

第 4 步：写入结果并结束回合

Write the result.json per

./automation-mode.md

and state in one line how many entries went to each category. End your turn. Do not edit any file other than the result file.

按照

./automation-mode.md

写入

result.json

，并用一行说明每个类别分别归入了多少条目。结束回合。除结果文件外，不得编辑任何其他文件。