gt patrol new instantiates patrol formulas with ZERO steps (bare root) while bd mol wisp materialises all of them — patrols run as silent no-ops and report success

Summary

gt patrol new pours patrol molecules bare-root (Steps: 1). The same formula, in the same store, at the same moment, pours fully (Steps: 27) through bd mol wisp. The step-materialisation happens correctly through the bd path and not at all through the gt path.

The practical consequence is that the whole patrol layer is inert but reports success — every patrol wisp is created, exits 0, prints a plausible wisp id, and then executes none of its steps. Nothing in the output indicates the patrol is a no-op, which is why it survives entire sessions unnoticed.

Reproduction (controlled, same formula/store/moment)

gt patrol new --role deacon      -> hq-wisp-bl5v   bd mol show: 'Steps: 1'   (bare root)
bd mol wisp mol-deacon-patrol    -> hq-wisp-m8z1   bd mol show: 'Steps: 27'  (all steps present)

The formula is not at fault: bd formula show mol-deacon-patrol reports Steps (26), so beads parses the TOML correctly. gt formula show mol-deacon-patrol also exits 0 and renders.

Scope: not one formula, and not one rig

Confirmed jointly by two independent patrol agents across three rigs:

Control: mol-dog-doctor, instantiated the same day, shows Steps:4 with a real tree. So the molecule engine pours multi-step molecules correctly right now — it is the patrol path specifically that pours bare.

Second, compounding fault

The same action also fails to register on the hook: gt patrol new exits 0 and prints a wisp id, but the wisp never appears on gt hook. So both the step-pour and the hook registration fail in one action, and neither surfaces an error.

Why this is severe

Patrols are the supervision layer. While this is live, anything that depends on patrol steps executing did not happen and raised no error — health checks, merge-queue gates, stuck-worker detection. In our town a witness cycle completed only because a human nudge said a worker had been dispatched; the patrol itself contributed nothing.

It also makes a class of downstream fixes unfixable-as-filed: setting pre-merge gate commands on a patrol formula is a false fix, because there is no step to consume them. Correct order is (1) fix bare-root instantiation, (2) set commands, (3) acceptance-check that a fresh patrol wisp reports Steps > 1.

Suggested acceptance criterion

gt patrol new --role <any> produces a wisp whose bd mol show reports the same step count as bd mol wisp <formula> for the same formula, and that wisp appears on gt hook.

Environment

gt 1.1.0 (pinned), beads 1.1.2, macOS 15.6 / darwin 25.6.0, Dolt-backed bd store.

Related existing issue: #4494 (gt patrol new --role refinery: rig config injection unreliable) — same command, different symptom; this report is about step materialisation rather than config injection.