Conditional branches: a qualifier the parser reads as a step

[m2ux]

Summary

A technique's Protocol is parsed into steps by a regex that strips leading whitespace before it matches. An author who indents a bullet to qualify the instruction above it — a condition, a fallback, an error path — gets something different from what they wrote: the qualifier arrives at the parser as a step in its own right, sitting beside the instruction rather than under it. A reader of the file sees a caveat. A run sees an unconditional instruction.

There is a guard that measures this class. It is not registered, so nothing runs it. Registering it is finding 3 of #491, and it cannot be done while the corpus still contains the class, because the guard would go red on the day it landed. This pull request empties the class so the registration has somewhere to land, and settles the shape a note takes while it is there.

What happens today

Eleven sub-bullets across eight techniques in five workflows carry a conditional qualifier at an indent. Five of them are in work-package, which is the workflow most runs pass through.

Two are worth naming because the run consequence is concrete rather than theoretical, and both were confirmed by parsing the file through the loader rather than by reading it. In the worktree creation technique, the phase that materialises a worktree parses to five steps, of which steps three and four are the two branches of create_branch — whether to pass -b — standing as consecutive unconditional instructions. A run reading them in order attempts both forms. In the path restore technique, the interactive and non-interactive checkout forms sit the same way, under a For each path iteration the parser does not carry into them.

The remaining nine are error paths and fallbacks: what to do when the workflow-server cannot be reached, when the issue is already assigned, when the gitnexus binary is absent, when the analyze CLI exits non-zero, when a framework is unfamiliar, when no review comments are found, when the changed-file set is empty.

The fix

Each qualifier becomes a note beneath the instruction it qualifies. A line opening with a blockquote marker fails the step regex and folds into the instruction above, so the caveat stays attached to what it qualifies and never reaches a run as an instruction of its own. The worktree phase now parses to three steps, with both branches inside step two.

The shape of a note is settled at the same time, because the corpus held two conventions and the canon named only one. A note carrying two or more items gives each one a bullet, so alternatives read as the list they are. A lone caveat is the note's own prose, having no list to express. Both shapes are equally invisible to the step regex — the bullet sits after the blockquote marker, so the line still fails the match.

Principle 31 and AP-59 in the workflow-design canon state that rule. Forty-five note lines across twenty groups in seventeen techniques take the bulleted shape, which is every multi-item note in the corpus; the hundred lone caveats already had the right shape and are untouched.

Verification

The corpus is green before and after: 27 guards pass on the merge base and 27 pass here, measured with the tooling at origin/main. The branch-as-step guard itself goes from 11 violations to none.

Step counts were taken by loading the affected techniques through the markdown technique loader, so the claim that a note folds into its instruction is measured rather than inferred.

That guard is not part of the sweep yet, so this pull request does not turn a red check green. What it does is make the registration possible, and the registration is where the check appears.

Scope

The eleven qualifiers, the note shape, and the canon that states it. No technique gains or loses a step, an input, or an output.

Acceptance criteria

• No protocol phase in the corpus encodes a conditional branch as an indented bullet.
• Every note carrying more than one item bullets its items, and every lone caveat does not.
• The canon describes the shape the corpus uses, with no surviving description of the other one.
• The full corpus sweep passes at the same 27 as the merge base.

Non-goals

This does not register the guard. That is a code-branch change and follows once this merges and the submodule pointer moves.

This does not cover mutually exclusive branches written as top-level peer bullets. The guard deliberately leaves those alone — separating them from a phase that legitimately handles several cases in sequence needs judgement the guard cannot supply.

Nothing enforces the bulleting rule; the guard measures the branch-as-step class and is indifferent to the shape of a compliant note. The rule is stated in the canon and applied across the corpus, and a future note that ignores it goes unmeasured.

The other two corpus findings in #491 — the re-entered activity with no forward exit, and the deferred-items register with no raiser — are not in this pull request.