A procedure can only be run once: no way to replay a checklist or a runbook

[vmillet-dev]

A checklist ticked once is finished for good. Running the same procedure again means unticking twelve boxes by hand — so nobody does: the note gets read rather than followed, and the ticking that was the point stops being used.

Separate the template from the run. "Release 0.2.0" is an instance of "Release checklist", with its own ticks, its own start, its own state. The template stays blank.

Release checklist                          3 runs

  ● 0.2.0    in progress   4/9     started 2 h ago
    0.1.4    done          9/9     12 March
    0.1.3    done          9/9     28 February

What it actually buys

Not the convenience of unticking. The application knows what you have written; it knows nothing about what you have done. A run is the first record of the second kind — "did we actually rotate the certificates in June?" becomes a question it can answer, and a half-finished deployment becomes something you can come back to rather than something you reconstruct.

It applies to both list-shaped kinds, so it should be built on top of the runbook (#76) rather than beside it.

What has to be decided

• What happens when the template changes mid-run. A step inserted at position 3 while a run has ticked 1 to 5 has no good automatic answer. Either a run snapshots the steps it started with — honest, and it makes a run a real historical record — or it follows the template and the ticks shift under the user. The snapshot is almost certainly right, and it costs a copy of the items per run.
• Is there a "current" run? The compact window ([A compact always-on-top window, for the note you are acting on #38]) and the card need to know which one they are showing. One active run per template is the simple answer; several is the honest one for anyone deploying two environments at once.
• Does a run belong in search? Probably not — it is progress, not content. But then matches_search needs to know to skip it, which is the fourth entry in a list CLAUDE.md keeps.
• Retention. Runs accumulate forever unless something says otherwise. The trash already has the shape of an answer (RETENTION, a purge at startup and on read) and this is the third thing that would use it.

Cost and traps

• The state is a third table keyed the same way as the other two: (run_id, position). That is the pattern store/related.rs was created to hold — it said the side tables were one pattern written three times, and this is the fourth.
• updated_at must not move. Ticking a step inside a run is not editing the note; refreshing the column would float every procedure you are halfway through to the top of the canvas. Same reasoning that gave set_placeholder_values a command of its own rather than a NotePatch field.
• The interface is the heavy part, and heavier than the runbook's: a note with instances needs somewhere to list them, a notion of the current one, and a way to start and finish one. This is the ticket to hold back until the runbook has been lived with for a few months — long enough to know whether procedures actually get replayed, or only read.
• Export is an open question of its own: a bundle carrying runs is a bundle carrying history, which is a different thing from carrying a library. Leaving them out of transfer on the first pass is defensible.

Done when: the same procedure can be run twice without touching the template, a run left half-finished can be picked up where it stopped, and the answer to "when did we last do this" is in the application rather than in a memory.