@edgehero/pi-dispatch-admin 1.0.0 → 1.1.0

package/README.md

@@ -4,7 +4,7 @@
 
 # pi-dispatch: run the pi coding agent as a self-hosted service
 
-**Let a coding agent work on your repositories while you are not watching, without surprise bills and without giving it the keys to your machine.** [pi](https://github.com/earendil-works/pi) is a superb coding agent, but it has no job queue, no spend limit, and, by its own README, no permission system. pi-dispatch adds exactly those, so you can run pi unattended and safely: on a cron schedule, on your repo's issues and PRs, or straight from the CLI. Every job runs in an isolated container, spend is bounded before a single token is spent, and everything the agent did (and what it cost) is recorded, graphed and priced for you.
+**Let a coding agent work on your repositories while you are not watching, without surprise bills and without giving it the keys to your machine.** [pi](https://github.com/earendil-works/pi) is a superb coding agent, but it has no job queue, no spend limit, and, by its own README, no permission system. pi-dispatch adds exactly those, so you can run pi unattended and safely: on a cron schedule, on your repo's issues and PRs, or straight from the CLI. Every job runs in an isolated container, spend is bounded before a single token is spent, and everything the agent did (and what it cost) is recorded, graphed and priced for you. On a forge you stay in the loop at both ends: a job starts only when someone with write access to the repo asks for one, by a label, an `@pi` comment or a review, and what comes back is a pull request you review and land, because pi-dispatch never merges anything. This is not another agent to weigh against the one you already use; it is the queue, the budget and the box for the pi you already run.
 
 > This npm package, **`@edgehero/pi-dispatch-admin`**, is the **operator console** (a pi extension). The service itself is `@edgehero/pi-dispatch` (worker + CLI) and `@edgehero/pi-dispatch-receiver` (the webhook edge); the [main repo](https://github.com/edgehero/pi-dispatch) has the container image, docs, and SECURITY.md.
 

package/dist/index.mjs

@@ -7598,6 +7598,12 @@ var init_build = __esm({
   }
 });
 
+// ../worker/src/egress.mjs
+var init_egress = __esm({
+  "../worker/src/egress.mjs"() {
+  }
+});
+
 // ../worker/src/forges.mjs
 function isForgeKind(kind) {
   return typeof kind === "string" && Object.hasOwn(FORGES, kind);
@@ -7698,6 +7704,7 @@ function defaultSettingsFile() {
 var CHAIN_DEPTH_MAX_DEFAULT, CHAIN_MAX_PER_JOB_DEFAULT;
 var init_config2 = __esm({
   "../worker/src/config.mjs"() {
+    init_egress();
     init_forges();
     CHAIN_DEPTH_MAX_DEFAULT = 1;
     CHAIN_MAX_PER_JOB_DEFAULT = 2;
@@ -8071,9 +8078,6 @@ function validateReplicas(run, at, path) {
   if (run.kind === "local") {
     throw configError(`${at}: run.replicas is not available on a cron trigger -- a local job's /workspace IS the operator's folder, bind-mounted read-write, so two replicas would edit one working tree with no gate and no undo: ${path}`);
   }
-  if (run.kind !== "github") {
-    throw configError(`${at}: run.replicas is not yet covered for ${run.kind} triggers (github only in this version); every forge mints its branch the same way, so this is a gap to close, not a limit: ${path}`);
-  }
   if (!Number.isInteger(replicas) || replicas < 2 || replicas > REPLICAS_MAX) {
     throw configError(`${at}: run.replicas must be an integer between 2 and ${REPLICAS_MAX} when present -- ${REPLICAS_MAX} is the ceiling because PI_CONCURRENCY defaults to 3, so a further replica would queue instead of racing, and 1 is refused because a one-member replica set is a flag that does nothing (got ${JSON.stringify(replicas)}): ${path}`);
   }
@@ -8700,12 +8704,15 @@ function buildDockerRunArgs({
   name,
   memory = "4g",
   cpus = "2",
+  network = null,
   extraFlags = []
 }) {
   if (!image) throw new Error("docker run: image is required");
   if (!name) throw new Error("docker run: container name is required");
   if (!workspace) throw new Error("docker run: workspace mount is required");
-  const args = ["run", `--name=${name}`, ...ISOLATION_FLAGS, `--memory=${memory}`, `--cpus=${cpus}`, ...extraFlags];
+  const args = ["run", `--name=${name}`, ...ISOLATION_FLAGS, `--memory=${memory}`, `--cpus=${cpus}`];
+  if (network) args.push(`--network=${network}`);
+  args.push(...extraFlags);
   for (const [k, v] of Object.entries(env ?? {})) {
     if (v === void 0 || v === null) continue;
     args.push("-e", `${k}=${v}`);
@@ -38768,7 +38775,7 @@ import { promisify as promisify4 } from "node:util";
 function sandboxContainerName(jobId) {
   return `${SANDBOX_NAME_PREFIX}${sanitizeJobId(jobId)}`;
 }
-function buildSandboxRunArgs({ image, name, workspace, jobDir, publish = [], term, idleSeconds = 0 }) {
+function buildSandboxRunArgs({ image, name, workspace, jobDir, publish = [], term, idleSeconds = 0, network = null, egressEnv: proxyEnv = {} }) {
   return buildDockerRunArgs({
     image,
     name,
@@ -38777,9 +38784,20 @@ function buildSandboxRunArgs({ image, name, workspace, jobDir, publish = [], ter
     // The ONLY two variables, and neither is a credential. TERM so the shell renders; TMOUT so a
     // forgotten session closes itself. `buildDockerRunArgs` skips undefined, so an unset TERM or a
     // disabled idle timeout emits nothing rather than an empty string.
+    // A sandbox joins the SAME kind of network a job did, by the same builder, so the boundary cannot
+    // land on job containers and miss this one. Leaving sandboxes on the default bridge was the tempting
+    // alternative and it is the wrong one: it reads as a convenience (install a missing dependency while
+    // debugging) and it is a WIDER reach than the run the sandbox exists to reproduce. A shell that can
+    // go where the run could not is not reproducing the run. Nothing an operator wants is lost, because
+    // the forge and the registry are on the allowlist a job needed anyway.
+    network,
     env: {
       TERM: term || void 0,
-      TMOUT: idleSeconds > 0 ? String(idleSeconds) : void 0
+      TMOUT: idleSeconds > 0 ? String(idleSeconds) : void 0,
+      // Still NO CREDENTIALS, and that clause is untouched: a proxy URL is not a credential, and
+      // buildContainerEnv is still not reused here. The env is two variables about the terminal and,
+      // when a policy is armed, three about the network.
+      ...proxyEnv
     },
     // Ahead of the env and the mounts, and well ahead of the image, which buildDockerRunArgs keeps as
     // the final positional. `--entrypoint` also clears the image's CMD; this repo's Dockerfile sets
@@ -40231,7 +40249,11 @@ function renderRunDetail(record, inner, styler, allRuns = [], sandbox = null) {
   out.push(kv("chain", chainBits.join(" \xB7 ")));
   if (r.replica > 0) {
     const sibs = (Array.isArray(allRuns) ? allRuns : []).filter(
-      (x) => x?.replica > 0 && x.replica !== r.replica && x.target === r.target && x.flow === r.flow
+      // `kind` is load-bearing since #187, not decoration: `target` is repo + separator + number, and
+      // targetFor renders github and forgejo with the SAME `#`, so a github `o/r#5` and a forgejo `o/r#5`
+      // are one string. While only github could replicate, no two replica runs could collide; now they can,
+      // and naming a stranger's job as your sibling is worse than naming none.
+      (x) => x?.replica > 0 && x.replica !== r.replica && x.kind === r.kind && x.target === r.target && x.flow === r.flow
     );
     const repBits = [`r${r.replica}/${r.replicas ?? "?"}`];
     repBits.push(sibs.length > 0 ? `sibling ${sibs.map((s) => `r${s.replica} ${s.jobId}`).join(", ")}` : "no sibling in this window");
@@ -40845,8 +40867,8 @@ var init_setup_wizard = __esm({
     init_deployment_pointer();
     init_read_model();
     init_index();
-    RUNTIME_VERSION = "1.0.0";
-    RECEIVER_VERSION = "1.0.0";
+    RUNTIME_VERSION = "1.1.0";
+    RECEIVER_VERSION = "1.1.0";
     RUNTIME_PKG = "@edgehero/pi-dispatch";
     RECEIVER_PKG = "@edgehero/pi-dispatch-receiver";
     NUDGE_MARKER_BASENAME = "pi-dispatch-setup.nudged";
@@ -41051,12 +41073,16 @@ function registerTools(pi) {
   pi.registerTool({
     name: "dispatch_trigger_add",
     label: "pi-dispatch add trigger",
-    description: "Adds a trigger to triggers.json and applies it live. The operator MUST approve a confirm dialog showing the entry; with no interactive operator it is refused. `flow` is the .pi/skills/<name> skill the job runs (its SKILL.md is the agent's instructions). `kind` = cron|label|comment|pull_request. cron (local) needs id, pattern, `folder` (absolute host path the job runs in), `flow`, and `task` (the prompt text handed to the agent), and may set optional model/provider/maxTurns for that schedule (omit = deployment default). label needs labels[]+flow; comment needs phrase+flow; pull_request needs action[] (+ optional labels[]) + flow. Webhook triggers take an optional `forge` = github (default) | gitlab, which also decides which action words pull_request accepts: github is labeled|opened|synchronize|reopened|review_submitted, gitlab is open|update|reopen|approved. A github review_submitted trigger may also set reviewState[] (approved|changes_requested|commented) to narrow which verdicts fire; omitted, all three do. For webhook triggers the repo and the task come from the triggering issue/PR event \u2014 set only the match + flow \u2014 and they run under the deployment default model.",
+    description: "Adds a trigger to triggers.json and applies it live. The operator MUST approve a confirm dialog showing the entry; with no interactive operator it is refused. `flow` is the .pi/skills/<name> skill the job runs (its SKILL.md is the agent's instructions). `kind` = cron|label|comment|pull_request. cron (local) needs id, pattern, `folder` (absolute host path the job runs in), `flow`, and `task` (the prompt text handed to the agent), and may set optional model/provider/maxTurns for that schedule (omit = deployment default). label needs labels[]+flow; comment needs phrase+flow; pull_request needs action[] (+ optional labels[]) + flow. Webhook triggers take an optional `forge` = github (default) | gitlab | forgejo | azure, which also decides which action words pull_request accepts: github is labeled|opened|synchronize|reopened|review_submitted, gitlab is open|update|reopen|approved, forgejo is label_updated|opened|synchronized|reopened, azure is created|updated. An azure label or comment trigger must also set `repository` (a work item belongs to a project, not a repository), and an azure pull_request trigger may not carry labels[] at all. A github review_submitted trigger may also set reviewState[] (approved|changes_requested|commented) to narrow which verdicts fire; omitted, all three do. For webhook triggers the repo and the task come from the triggering issue/PR event \u2014 set only the match + flow \u2014 and they run under the deployment default model.",
     executionMode: "sequential",
     parameters: typebox_exports.Object({
       kind: typebox_exports.String(),
       flow: typebox_exports.String(),
       forge: typebox_exports.Optional(typebox_exports.String()),
+      // buildTriggerEntry has always READ `f.repository`, and the schema has always stripped it -- so an
+      // azure label/comment trigger was unauthorable by the model, refused at the write for want of a field
+      // it had no way to send. Surfaced by #187 widening what the description above must say about forges.
+      repository: typebox_exports.Optional(typebox_exports.String()),
       id: typebox_exports.Optional(typebox_exports.String()),
       pattern: typebox_exports.Optional(typebox_exports.String()),
       folder: typebox_exports.Optional(typebox_exports.String()),

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@edgehero/pi-dispatch-admin",
-  "version": "1.0.0",
+  "version": "1.1.0",
   "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.",
   "keywords": [
     "pi-package",

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

@@ -122,14 +122,16 @@ job time; and `pi-dispatch doctor` lists every image their triggers name and fla
 
 ## The forge a trigger listens to — `run.kind`
 
-A webhook trigger names its forge: `"kind": "github"` or `"kind": "gitlab"`. Everything else about the
-trigger is the same — the `on.type`, the `{any, all, none}` label predicate, `flow`, `packages`, `image`.
+A webhook trigger names its forge: `"kind"` is `github`, `gitlab`, `forgejo` or `azure`. Everything else
+about the trigger is the same — the `on.type`, the `{any, all, none}` label predicate, `flow`, `packages`,
+`image`, `replicas`.
 
-Two things are NOT the same, and both refuse at load rather than misbehaving quietly:
+Three things are NOT the same, and all of them refuse at load rather than misbehaving quietly:
 
 - **`pull_request` actions are the forge's own words.** GitHub takes
   `labeled | opened | synchronize | reopened | review_submitted`; GitLab takes
-  `open | update | reopen | approved`. A word
+  `open | update | reopen | approved`; Forgejo takes
+  `label_updated | opened | synchronized | reopened`; Azure takes `created | updated`. A word
   from the wrong forge is refused when the file is written. It would not break anything otherwise — it
   would simply never match an event, and the trigger would look configured while doing nothing.
   `review_submitted` is GitHub's `pull_request_review` event: it fires on **every** submitted review, so
@@ -138,6 +140,29 @@ Two things are NOT the same, and both refuse at load rather than misbehaving qui
   load, because a narrowing that cannot apply reads as one that does.
 - **One `comment` trigger per forge.** Two GitHub comment triggers are refused; one GitHub and one GitLab
   are fine.
+- **Azure names no repository.** A work item belongs to a project, so an azure `label` or `comment` trigger
+  MUST set `run.repository` (the repo within the project to clone) and every other forge's must not. An
+  azure `pull_request` trigger may not carry a label predicate at all: Azure tags work items, never pull
+  requests, so `any`/`all`/`none` could never match and a rule that loads clean and never fires reads as a
+  broken harness.
+
+## Racing two agents on one event — `run.replicas`
+
+`"replicas": 2` on a `label`, `comment` or `pull_request` trigger turns one delivery into **two independent
+paid jobs**: two containers, two branches (`pi/issue-7-r1` and `-r2`), two review requests, one human
+picking. It works on every forge. Absent, nothing changes.
+
+Three things to say when an operator asks about it:
+
+- **It multiplies spend, and the caps are the only ceiling.** Each replica reserves its own budget slot
+  before its own tokens, so a `replicas: 2` trigger firing ten times a day consumes twenty slots of the
+  daily cap, not ten. Nothing is discounted; that is the feature, not an oversight.
+- **You cannot set it from here.** There is no `replicas` parameter on `dispatch_trigger_add` or
+  `_edit`, and no panel key. It is a reviewed edit to `triggers.json`, deliberately: a spend multiplier is
+  plainly a capability a model should not gain. Say so rather than looking for a way around it.
+- **It refuses on cron, and beside `resume`.** A local job's `/workspace` IS the operator's folder, so two
+  replicas would edit one working tree with no gate and no undo. And a resumed run continues one lineage
+  where replicas exist to fork it.
 
 `dispatch_trigger_add` takes an optional `forge` parameter, defaulting to `github`. Unlike `image`, this
 one IS offered to the model — a model that can already add a GitHub trigger can already arm a paid run,