protocol — Manual

What it does

Runs a protocol from the catalog: a strict, pre-agreed order of actions. Loading one (skills(op="load")) only shows its text. start is the commitment — its steps are inserted into the todo plan after your current position, the run is logged, and every turn afterwards carries a reminder that it is still open.

A protocol is not advice. Its steps are executed in order, each one checked before the next; deviating is an execution error to report, not a variation to choose.

Parameters

Actions

start

{"op": "start", "id": "9c4d2b7a1e6f8035"}
{"op": "start", "name": "Корректное выключение инфраструктуры"}

The result names the plan positions the steps landed on, the preconditions, the post-checks, and the three escape hatches. One protocol runs at a time per session — close the active one before starting another.

Start a protocol when the user asks for it by name, or when its triggers match what they asked for. Do not start one to "see what it says" — load does that without committing to anything.

finish

{"op": "finish", "report": "Stopped apps, then databases; systemctl shows no app units; disk synced and unmounted."}

Refused unless every injected step is done or skipped, and refused outright if any step is failed — that run ends with fail. Skipping a step is legitimate only through on_already_done (verify the result exists, then mark it done or skipped with validation).

The report is the run's record: name the post-checks and what you saw for each.

cancel

{"op": "cancel", "reason": "user changed their mind before step 2; nothing was stopped"}

Use when the run cannot or should not continue. Still-open steps are marked skipped so the plan does not keep dangling work. Then tell the user what was and was not done.

fail

{"op": "fail", "reason": "step 2: postgres did not stop within 60 s; apps are still down, databases up"}

Use when reality diverged from the plan — a step failed, a precondition was false, the result is not what the protocol expected. Same step cleanup as cancel. This is the honest end of a run that did not go as agreed; never report a failed run as finished.

status

{"op": "status"}

Shows the active run and the state of its steps. Useful after a long tool chain or a compressed context.

Rules

• Mark each step done with todo(op="update") only after its check passes; the validation field is required.
• Do not reorder, merge, or silently skip steps. If a step is already done, follow on_already_done.
• Do not end the turn while a protocol is running: finish it, or cancel/fail it with the reason.
• The user reads the run's outcome as your report — not as a claim that the protocol "went fine".