Collection Runs

Collection Runs turn the "get a status" chore into one action: pick a connected device, run an ordered set of read-only commands, and DRAGON captures each command's output into a saved, timestamped snapshot — summarized by the copilot, diffable against a later run, and exportable. Re-run the set next week and see exactly what changed: config drift, version deltas, neighbor and inventory changes.

Since v1.3.0 the sets themselves are yours: create, duplicate, edit, and delete your own command sets — hand-typed or drafted by the copilot from a plain-English prompt — with a guided builder and live test-runs, and a device's collection history feeds the copilot automatically, with drift between runs surfacing as an insight with no model call.

v1.4.0 takes a run from one device to many, and from read-only to operator-owned: a set can run against saved devices that are not open — DRAGON connects, runs, and disconnects on its own — or fan out across a whole folder at once with a live per-device roster; a set you authored can be put in operator mode so its config and destructive steps run too; a pager pause on an unfamiliar device no longer stalls a run; and the editor was regrouped into clear sections.

This remains the one feature where the core transmits commands without a human keypress, under a strict stance: the core may auto-send only commands a classification guard proves read-only, unless a human has put a set they authored in operator mode. Anything else is skipped, never transmitted, and every auto-sent command is written to the audit log.

The workspace #

The Collection workspace is a master–detail layout. The left pane is a searchable, relevance-ranked set list — search by name, by platform (cisco, debian, …), or by command text — that stays wide until you select something. The right pane switches between running a set, editing one inline, and viewing a snapshot with its diff. The editor is grouped into four sections — Details (name and platforms), Commands (with the AI draft helper folded in above the command box), Run options (the context and operator-mode toggles), and Test run — and the per-command classifier list is a collapsed accordion whose header still shows the count of steps that are not read-only.

Command sets #

A set is an ordered list of commands bound to one or more device platforms. Three sources coexist:

Built-in — the vendor-maintained default read-only sets for Cisco and Juniper network gear (show version, show run, show int status, …) and Linux/Unix servers (uptime, df -h, free, ps, …). Built-ins stay read-only and cannot be deleted; duplicate one to make it yours.
User — sets you created or duplicated, fully editable.
Generated — sets the copilot drafted; they stay marked as generated across edits.

A set carries one "add this set's output to the copilot's context when it runs" toggle — the opt-in the snapshot context digest honors, below. It maps onto every step, so a set that had individual commands opted in before v1.4.0 shows the toggle on. Sets are bounded at 100 steps, and every edit propagates to all open windows immediately.

The Collection builder #

New Collection opens a guided workspace to author a set:

Pick the target platform(s).
Hand-type commands, or draft them with AI from a natural-language prompt — "BGP & interface health on Cisco IOS" becomes a proposed command list. A draft always lands in the editor for review; it never runs directly. Drafting is a normal model call: redacted, license-gated, and audited.
Every command shows a live read-only/skip badge as you type — the same rules-only classifier that gates the run, evaluated locally with no model involved — so you know before saving which steps will auto-run and which will be skipped.
Test-run the draft against a live session to see sample output before you commit it. A test-run goes through the full read-only gate and writes the same per-command audit entries as a real run, but nothing is saved — no snapshot is persisted.
Optionally switch the set into operator mode — "run all commands, including config and destructive" — with a live count of how many steps that affects. The toggle is yours alone to set; see below.

Saving deliberately does not reject non-read-only commands — you may save anything, and the gate applies at run time, where non-read-only steps skip and warn. This keeps the classification decision in one place and current, instead of freezing a stale save-time verdict into the store.

Running a collection #

The Run against panel on a set is one checklist — connected sessions first, then saved devices grouped by folder with per-folder select-all — and one Run button that adapts to the selection:

One connected session runs the set against it directly, as before.
One saved device that is not open runs headlessly: DRAGON opens it with its saved parameters and Vault or keychain credential, runs the set, and disconnects — no terminal tab appears. A device that would need a typed secret (a keyboard-interactive login, or a password with nothing stored) is reported as skipped with the reason rather than attempted. Single-device runs keep the interactive host-key prompt, exactly as opening the device by hand would.
Several devices, or a folder, run as a batch: each device opens headlessly, runs, and disconnects, with fan-out capped at 5 concurrent so a large folder cannot exhaust the session budget. A live roster shows every device's state — connecting, running, done, failed, or skipped — and, at the end, its ran, skipped, and failed counts. A failure while opening or running one device is contained to that device.

Whichever path starts it, DRAGON runs the set's commands in order, waiting for the device prompt to return after each one, with a per-command timeout so a mis-detected prompt bounds the step instead of hanging the run. A command whose output matches the profile's error signatures is flagged; by default the run continues past errored steps. Progress streams live per command, and the finished snapshot — every command with its captured output, plus skip, error, or timeout flags — is stored with its timestamps and summarized by the copilot. History, the history filter, and the snapshot viewer label devices by their saved-session name rather than login@host.

The read-only gate #

The gate is the security crux of this subsystem, because it is the one place DRAGON crosses its "suggest, never execute" line — under the narrow exception that only proven-read-only commands may be auto-sent.

Every command a set could auto-run — a real run or a builder test-run — is re-classified at run time by the same rules-only classifier that tags copilot suggestions: profile rules first, then a conservative built-in ruleset. A command auto-runs only when the result is exactly read-only. Anything else — config-impacting, destructive, or unknown — is skipped with a warning and recorded; it is never transmitted. Unknown commands default to config-impacting, so the failure mode is a skipped step, not an executed write.

Network platforms are covered by the built-in show/display family rules. For Linux, a conservative read-only allowlist covers commands that are read-only regardless of arguments — uname, uptime, df, free, ps, dmesg, journalctl, and pure readers such as cat, grep, ls, and stat. Ambiguous verbs (ip, systemctl, mount, find) are deliberately excluded unless an explicit read-only subcommand rule covers them — a wrong allowlist entry would let a writing command auto-run, so the list is reviewed, not generous.

v1.3.0 hardens the gate for the new authoring surfaces, closing the ways a read-only verb could still smuggle a write:

In-band control characters are refused everywhere. The classifier reads a command's leading token, but the transport sends the whole line — so show version followed by a Ctrl-U kill-line and reload would classify as read-only yet execute reload. Every ingress of user-authored command text rejects commands carrying CR/LF, any other control character, DEL, or a Unicode line separator, and the executor itself — the single point that transmits to a device — refuses a control-bearing line even if it classified read-only.
Shell constructs downgrade the classification. A read-only-classified command carrying redirection, chaining, or substitution (>, <, ;, &, backticks, $() — or a pipe into anything other than a network read-only filter keyword (include, exclude, begin, section, match, count, …) — is not treated as read-only. show run | include bgp stays read-only; show > /etc/passwd and ping | tee /etc/x are skipped.

The executor is the single code path that transmits without a keypress — one choke point to test and audit. Each auto-sent (or skipped) command writes an auto_exec audit entry carrying provenance, the command, its classification, and its outcome. See redaction and audit.

Operator mode #

The read-only gate exists to stop an AI from transmitting a config or destructive command on its own. Applied to a set a human wrote, reviewed, test-ran, and clicked Run on, it removed a capability every incumbent terminal already trusts the operator with. v1.4.0 separates the two: the gate stays hard for anything the AI drafted and for every automatic caller, and a human may mark a set they authored to run in full.

Operator mode is a per-set toggle in the editor's Run options. It is taken verbatim from the editor when you save — never preserved from a model draft and never inferable from anything the AI produced. A generated set cannot carry it, and duplicating a set does not inherit it; you re-affirm on the copy.
An operator-mode set runs every step, config and destructive alike. Steps stay badged by class in the editor, the run, and the snapshot, and a pre-run banner makes the mode unmistakable. A destructive step that ran is recorded in the audit log as exactly that.
The control-character backstop is unconditional in both modes: a line that carries an in-band control character is refused regardless, because it guards transmit integrity — the command shown is the command sent — not command class.
Sets saved before v1.4.0 stay read-only-gated until you turn the toggle on.
Against a local shell, an operator-mode set executes on your own workstation rather than a remote device — same mechanism, different blast radius.

Pagers on unfamiliar devices #

Profiles for Cisco and Juniper disable paging before a run. For any other profile — generic-fallback, an unknown device, some serial consoles — a --More-- pause used to stall every step to its timeout. During a run or test-run DRAGON now watches the unterminated tail of the output for a built-in set of generic pager markers (--More--, -- More --, Press any key to continue, Press <SPACE>, and the like), consulted only for profiles that declare no markers of their own, and advances the pager with a single space. A space is never a newline, so a run still never auto-transmits a command; advances are rate-capped per session. If a step times out anyway, DRAGON sends a pager-quit keystroke and lets the device settle before the next command, so its first character cannot be eaten as a pager keystroke.

Snapshots and diff #

Snapshots are stored in the application database and listed as per-device history, filterable by session and date. The snapshot viewer shows per-command output with per-block copy-to-clipboard, skips and warnings, errors, and the AI summary, with a fullscreen mode for long output.

Select two snapshots of the same set and DRAGON renders a side-by-side diff — the fastest answer to "what changed since last time?". The copilot can explain a diff on demand: the diff text is re-redacted and the model call is audited like any other. Snapshot output passes through the standard capture pipeline, so it is ANSI-stripped, pagination-collapsed, and redacted before it is stored.

Snapshots are exportable through the native save dialog, using the same daemon-side write path as audit export.

Drift insights #

When a re-run of a set shows the device's captured state changed, DRAGON raises a drift insight — which commands changed output, what is new or gone, and any step that went from clean to errored. Detection is deterministic: steps are paired by position and compared for output equality, with no model call — so drift insights carry no license gate, no token cost, and no egress. The insight lands in the copilot panel like any other.

Snapshot history follows the device, not the session: runs from a saved-tree session are keyed to that saved node, so history survives reconnects and new tabs. Runs from an ad-hoc, unsaved session are scoped to that session only and end with it — a documented limitation.

Collection history in the copilot's context #

For a device with collection history, the copilot's answers are grounded in its recent runs automatically. Context assembly injects a compact collection baseline for the session's device: one-line summaries of recent runs, what changed since the previous same-set run, and output excerpts only for commands whose set opted them into context. So "what drifted since last week?" and troubleshooting start from a real captured baseline rather than only the live window.

The opt-in is the privacy boundary: built-in sets never opt output in — they contribute run summaries and drift, never raw output — and a duplicated set exposes a command's output only when you switch that command's toggle on. The digest is hard-capped in size so a show run cannot blow the context budget, and it is re-redacted at context assembly like every other context piece. See copilot and RAG.

Boundaries #

A batch or headless run targets saved-tree devices; an ad-hoc, unsaved session runs singly against its own live tab.
Closing the window mid-batch does not abort the batch; the read-only gate and per-step timeouts bound what a detached batch can do.
Headless runs never prompt: a device that needs a typed secret is skipped with a reason, not attempted.
A stored set's classification outcome can change across DRAGON upgrades as the classifier improves — by design; the audit trail records what actually ran or skipped on each run.