@edgehero/pi-dispatch-admin 1.10.2 → 2.0.0

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@edgehero/pi-dispatch-admin",
-  "version": "1.10.2",
-  "description": "Operator console (a pi extension) + skill for pi-dispatch: run the pi coding agent as a self-hosted service. A /dispatch TUI for the queue, spend caps, run history, editable GitHub, GitLab, Forgejo and Azure DevOps triggers (cron/label/comment/PR/MR/work item), and scheduled pause windows — plus AI-operable, human-confirmed controls. Runs against a live pi-dispatch deployment.",
+  "version": "2.0.0",
+  "description": "Operator console for pi-dispatch, as a pi extension: a /dispatch panel over the queue, spend caps, scoped limits, run history and insights, editable cron and GitHub, GitLab, Forgejo and Azure DevOps triggers, pause windows, and human-confirmed tools your AI can operate.",
   "keywords": [
     "pi-package",
     "pi-extension",
@@ -19,7 +19,9 @@
     "job-queue",
     "cron",
     "tui",
-    "dashboard"
+    "dashboard",
+    "podman",
+    "docker"
   ],
   "license": "MIT",
   "author": "Rob Boerman",

package/skills/operate-pi-dispatch/SKILL.md

@@ -44,9 +44,11 @@ dialog before it takes effect**:
 - `dispatch_waits` — list the jobs the worker is HOLDING on a trigger's `run.waitFor` condition: job id,
   an id-only target, the operator's own words for what it waits on, and how long it has waited. Different
   from the queue's `delayed` count, which also mixes cron next-occurrences, retry backoff and quiet hours.
-- `dispatch_wait_cancel` — remove a held job so it never runs (confirm-gated). It is the only lever that
-  reaches one: a held job has spent nothing, so no budget cap will ever refuse it, and deleting the trigger
-  does not reach a job already enqueued.
+- `dispatch_wait_cancel` — remove a held job so it never runs (confirm-gated). The caps cannot do this: a
+  held job spends nothing while it waits, so no budget cap will refuse it, and deleting the trigger does not
+  reach a job already enqueued. The operator has the same lever without you: `pi-dispatch cancel <jobId>`
+  at a terminal, or `h` then `x` in the panel — that CLI verb also removes a plain queued job and stops a
+  RUNNING one (its record then says `operator-cancel`), both beyond this tool's reach.
 - `dispatch_limit_add` / `dispatch_limit_edit` / `dispatch_limit_delete` — manage scoped limits (per
   repo/folder budget caps and concurrency: `day`/`week`/`month` job-count caps refuse a job pre-spend with
   reason `scope-cap`, never retried; `concurrent` defers the excess, never drops it; `dispatch_limits`
@@ -132,6 +134,26 @@ cannot, and that it is an edit they make to `triggers.json` themselves.** Do not
 built or pulled on the worker's own host, because jobs run with `--pull=never` and nothing is fetched at
 job time; and `pi-dispatch doctor` lists every image their triggers name and flags one that is missing.
 
+## Tool exclusion — `run.excludeTools`, and why you cannot set it
+
+A trigger may carry `run.excludeTools`: built-in pi tools its jobs' sessions do NOT have. It exists so a
+read-only flow (a triage that must not edit, a report that must not run a shell) is read-only by
+construction rather than by request: the excluded tools are removed from the session's tool registry, so
+nothing inside the job can switch them back on, and every such job logs the active tool list read back.
+The drill-in states it beside the image row either way (`full pinned tool set` when absent).
+
+**You cannot change it, in either direction.** `dispatch_trigger_add` and `dispatch_trigger_edit` have no
+such parameter, and a chained job's request file can neither set nor drop it (the child inherits the
+parent's exclusions). This is a permission surface, and the widening direction (a name quietly dropped
+from the array) would read as harmless in any confirm dialog, which is exactly why no model-callable
+route exists.
+
+So if a user asks you to exclude a tool from a trigger, or to restore one: **say plainly that you cannot,
+and that it is an edit they make to `triggers.json` themselves.** Two useful things you *can* say: only
+the built-in names are legal (`read`, `bash`, `edit`, `write`, `grep`, `find`, `ls`; a misspelling
+refuses at load rather than silently excluding nothing), and a genuinely read-only trigger usually also
+wants `"packages": false`, because extension tools are not excludable.
+
 ## Vault secrets — `run.secrets`, and why you cannot set it
 
 A trigger may carry `run.secrets`: a map of environment variable name to an opaque **reference**, plus
@@ -267,8 +289,9 @@ What that means when you are asked about a job that "has not run":
   script is broken rather than the condition slow. `wait-expired` means a bound was reached.
   `wait-skew` / `wait-unreadable` mean two services in the deployment disagree about the field and one needs
   upgrading or restarting.
-- **Cancelling is an operator decision.** `dispatch_wait_cancel` needs a confirm, writes no run record (the
-  job never ran), and cannot be undone: the delivery is gone, and a webhook does not resend itself.
+- **Cancelling is an operator decision.** `dispatch_wait_cancel` needs a confirm, writes no run record of its
+  own (a held job usually never ran; one held again on a retry keeps whatever its earlier attempts recorded), and
+  cannot be undone: the delivery is gone, and a webhook does not resend itself.
 
 ## Scoped limits — and the folder mutex you cannot turn off