Open question: does bulk selection and action fit a monitor, or is it out of scope

[moezdil]

siltide is read-only by design today: it watches devices and processes, it does not act on them. Marking several processes and killing them together, or marking several devices and running one action across them, is a real capability some fleet operators would want. It is also a meaningful scope change for a tool whose stated identity is monitoring, not control. Recording this as an open question for the owner to decide, not a committed feature: does siltide start taking actions, or does it stay observation-only and leave acting to the vendor's own tools?

[moezdil]

A recommendation, since this is yours to decide.

Stay observation-only, and split the issue in two. The question bundles two things that have very different costs:

Selection is already ours. Marking rows and acting on the marks inside the interface — filter to the marked set, export them, copy their PIDs, open them side by side, watch only those in the history view — changes nothing about what siltide is. It is still a monitor; it just stops making you retype what you already pointed at. It needs a set of keys (space to mark, A to mark the filtered set, \ to clear) and a marked-row style in every theme. Nothing leaves the process.

Action is a different tool. kill -9 across four PIDs on three nodes is the first thing in siltide that can be wrong in a way that costs someone a training run. It brings in a confirmation model, an audit trail of what was done and by whom, a permission story for --remote (the token is currently read-only by construction — the moment one endpoint acts, the whole API needs authorization, not just authentication), partial-failure reporting, and a support burden that is categorically unlike "it drew the wrong number".

The line I would draw: siltide never sends a signal. What it can do instead is make the action trivial to take elsewhere — a marked set yields kill 1234 5678 or kubectl delete pod a b -n ns on the clipboard, with the node and namespace already right. The operator runs it, in their shell, with their credentials and their history. We keep the read-only identity that makes siltide safe to install on a shared node, and they still do not have to retype anything.

If you want that, say so and I will open it as "mark rows, and hand the command to the shell" — selection plus clipboard, no execution. If you would rather siltide act, that is a design worth its own issue with the authorization model settled first, and it should not land in the same release as anything else.

[moezdil]

The selection half is done and merged: #154.

x marks a row, X marks the filtered set, y copies the identifiers, Y copies the command for them. siltide does not run it. Marks are held by identity, so they survive a sort, a filter and a refresh.

What this issue still asks is the other half: should siltide ever send the signal itself. That needs a confirmation model, an audit trail, partial-failure reporting, and an authorization story for --remote (the token is read-only by construction today; the moment one endpoint acts, the whole API needs authorization and not only authentication). Leaving it open for that decision, which should not land in the same release as anything else.