Runbook Executor

Who the node is. The id is the key the DOT pins.

id

runbook-executor

name

Runbook Executor

type

tool

phases

Deployment

What it does, and the prose the agent is handed when the graph runs.

action26 words

Run the cleared mitigation's steps against the resolved targets, dry run first, then for real, and return the command log with every exit code in order.

spec147 words

Run the cleared mitigation you are handed on mitigation against the target list attached to it and against no other host, whatever the runbook prose says. Execute the whole sequence as a dry run first, compare what it reports it would touch against that target list, and abort before the real run if the two differ by so much as one host. Then run the steps for real, in the order given, stopping at the first non-zero exit code: do not retry a failed step, do not improvise a rollback, and do not run a step the mitigation did not contain. Emit the command log on execution_log, every command as issued, its output and its exit code, in the order they ran, including the dry run and including the step that failed. You are done when that log is emitted, whether the mitigation completed or stopped early.in full above

model

whatever the graph supplies

agent

not named

skill

skills/runbook-executor.md

tools

Shell

mcp

none

params

timeout_s: 300, max_retries: 0, dry_run_first: true

What arrives, what leaves, which nodes it expects to hear from, and what may not.

inputs

mitigation : json

outputs

execution_log : report

dependencies

blast-radius-check

cannot

no type is refused

will_not

run a step the mitigation does not contain, touch a host outside the resolved target list

The keys the static analysis reads. Nothing here instructs the agent.

risk_markers

arbitrary-code-execution, secret-access

notes135 words

The highest-privilege node in the gallery and it scores accordingly: runbook steps are code the blueprint did not write, executed under credentials that reach production, arbitrary-code-execution and secret-access together, and neither is softened. max_retries: 0 means one execution and no automatic second one, which is what the spec above already says: a failed step stops rather than retrying blind, because re-running a half-applied mitigation is an incident decision. It was written max_iterations: 1, and engine spec §2.6 counts the attempts that follow the initial execution, so a runner read that as one run plus one retry and would have re-applied exactly the mitigation this card refuses to re-apply. Zero is a declared cap and not an absent one: Attractor's own default for max_retries is 0, and doc 3 §4.1's marker reads it as a bound.

The card's own version, and who wrote it.

version

1.1.0

author

autogen

provenance

not stated