omp-conductor 0.16.0 → 0.16.2

package/README.md

@@ -114,6 +114,31 @@ For what the host needs before anything runs — `bun`, an authenticated `gh`,
 `omp-telegram` for the escalation channel — see the
 [Install prerequisites](https://github.com/TerrifiedBug/conductor/blob/main/omp/REFERENCE.md#install-prerequisites) in the reference.
 
+### Shell completions
+
+`omp-conductor complete` generates completions for zsh, bash, fish, and
+PowerShell. Load them for the current shell:
+
+```bash
+source <(omp-conductor complete zsh)
+# or
+source <(omp-conductor complete bash)
+```
+
+For a persistent zsh install:
+
+```bash
+mkdir -p ~/.omp/conductor
+omp-conductor complete zsh > ~/.omp/conductor/completions.zsh
+echo '[ -f ~/.omp/conductor/completions.zsh ] && source ~/.omp/conductor/completions.zsh' >> ~/.zshrc
+```
+
+Use `bash` and `~/.bashrc` for the equivalent bash install. In fish, run
+`omp-conductor complete fish | source`; in PowerShell, run
+`omp-conductor complete powershell | Out-String | Invoke-Expression`.
+After a successful interactive setup, the wizard offers to install zsh or bash
+completions this way and adds the rc source line only when it is absent.
+
 ## Quick start
 
 1. Install `omp-conductor` and `omp-telegram`. Pair the Telegram bot and enable its bridge.

package/REFERENCE.md

@@ -2240,6 +2240,8 @@ omp-conductor watch list [--project NAME]
 omp-conductor daemon [--once] [--port N] [--project NAME]
 omp-conductor resume [--project NAME]
 omp-conductor brief-upgrade [--migrate|--retrofit] [--apply] [--file PATH] [--project NAME]
+omp-conductor complete <zsh|bash|fish|powershell>
+omp-conductor complete -- <args...>
 omp-conductor help
 ```
 
@@ -2285,6 +2287,7 @@ omp-conductor help
 | `--retrofit` | — | Only for `brief-upgrade`. Propose (or with `--apply`, write) a `YOURS TO EDIT` banner before the first owned-topic heading on a hand-written brief. |
 | `--apply` | — | Only for `brief-upgrade`. Confirms `--migrate` / `--retrofit`. On its own it exits `2`: the legacy single-file merge was removed in 0.4.3. |
 | `--file PATH` | — | Only for `brief-upgrade`. Check a brief that is not where the wizard would have put it, on a host that may have no config at all. |
+| `complete <zsh\|bash\|fish\|powershell>` | none | Print a shell completion script. Source it directly for a session or save it and source the file from the shell rc. Interactive setup offers the persistent zsh/bash install; fish and PowerShell remain available manually. `complete -- <args...>` is the fast shell callback protocol: static verbs, subcommands, flags and setup areas come from the command manifest, while project names load from config and fail empty on any read error. |
 | `help`, `--help`, `-h` | none | Print usage. An unknown or missing verb prints it too, and exits `2`. |
 
 Pause is a sentinel under the state directory and survives a daemon restart.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "omp-conductor",
-  "version": "0.16.0",
+  "version": "0.16.2",
   "type": "module",
   "license": "MIT",
   "description": "A 24/7 dispatcher that takes ready GitHub issues to green, mergeable PRs using omp coding sessions, with tiered escalation first to an orchestrator session and then to a human.",
@@ -33,6 +33,7 @@
     "schema": "bun run src/generate-schema.ts"
   },
   "dependencies": {
+    "@bomb.sh/tab": "0.0.22",
     "yaml": "^2.9.0",
     "zod": "^4"
   },

package/schema/config.schema.json

@@ -305,6 +305,7 @@
           "modelFallbacks": {},
           "modelFallbackThreshold": {},
           "ompSettings": {},
+          "workerAdvisor": {},
           "escalation": {
             "type": "object",
             "properties": {

package/src/admission.ts

@@ -29,6 +29,7 @@ import type {
 } from "./types.ts";
 import { readPlanUsage, type PlanUsageStatus, type UsageSource } from "./usage.ts";
 import type { CriticalBaseProbe, CriticalBaseVerdict, RunLaneProbe } from "./gitops.ts";
+import { repoSlugFor } from "./gitops.ts";
 import { branchName, type Routed } from "./routing.ts";
 import { parseDependsOn } from "./depends-on.ts";
 
@@ -51,6 +52,17 @@ export interface AdmissionDeps {
   escalate(e: Escalation): Promise<void>;
   probeCriticalBase?: CriticalBaseProbe;
   probeWorktreeLane?: RunLaneProbe;
+  /**
+   * Reads one issue's tracker state in a repository the admission tracker is
+   * NOT bound to — the cross-repo half of the Depends-on interlock (#420).
+   * The tracker bound to `project.tracker.repo` can only answer same-repo
+   * references; a `owner/repo#n` prerequisite naming a different routed repo
+   * goes through this. Undefined means "could not tell" (same posture as
+   * {@link Tracker.issueSnapshot}); a routed prerequisite it cannot answer
+   * fails that candidate closed. Unset, admission fails a routed cross-repo
+   * prerequisite closed too — the daemon always wires it.
+   */
+  probeIssueIn?: (repo: string, issue: number) => Promise<IssueSnapshot | undefined>;
 }
 /** `stops` are the operational ends that each require one resume. */
 export function hasContinuationBudget(stops: number, maxContinuations: number): boolean {
@@ -190,6 +202,22 @@ function isPathLike(token: string): boolean {
   return token !== "" && !/\s/.test(token) && (token.includes("/") || /\.[A-Za-z0-9]{1,10}$/.test(token));
 }
 
+/**
+ * Where a `owner/repo` cross-repo reference can be read. Only repositories
+ * routed in THIS fleet are resolvable (#420): the issue source repo
+ * (`project.tracker.repo`) is answered by the existing tracker, and any routed
+ * work repo by {@link AdmissionDeps.probeIssueIn}. Anything else is unresolved
+ * — the caller fails closed rather than guess which repo was meant, and never
+ * silently resolves the reference against the candidate's own repo.
+ */
+function crossRepoTarget(project: ProjectConfig, ownerRepo: string): "tracker" | "routed" | undefined {
+  if (ownerRepo === project.tracker.repo) return "tracker";
+  for (const routed of Object.values(project.routing.repos)) {
+    if (repoSlugFor(routed) === ownerRepo) return "routed";
+  }
+  return undefined;
+}
+
 /**
  * Which routed candidates get a worker this tick — in queue order, never more
  * than `slots` of them. Every non-admission receives a stable reason code.
@@ -623,13 +651,14 @@ export async function admitCandidates(
       continue;
     }
 
-    // The Depends-on interlock (#419): a candidate declares the same-repo
-    // issues it must not be dispatched before, and any *open* prerequisite
-    // holds it until every referenced issue is closed. Prerequisite state is
-    // read fresh from the tracker at claim time, every pass — never cached
-    // across ticks — so a prerequisite that reopens re-holds on the next tick.
-    // Only same-repo `#<n>` references are resolved here; cross-repo
-    // references and graph cycles are later slices (#420/#421).
+    // The Depends-on interlock (#419/#420): a candidate declares the issues it
+    // must not be dispatched before — same-repo (`#123`) or cross-repo
+    // (`owner/repo#123`) — and any *open* prerequisite holds it until every
+    // referenced issue is closed. Prerequisite state is read fresh from the
+    // tracker at claim time, every pass — never cached across ticks — so a
+    // prerequisite that reopens re-holds on the next tick. Cross-repo
+    // references resolve only against repositories routed in this fleet;
+    // graph cycles are a later slice (#421).
     const dependsOn = parseDependsOn(r.issue.body);
     if (dependsOn.malformed.length > 0) {
       // A marker line with no strict `#<n>` reference (e.g. `Depends-on:
@@ -686,6 +715,81 @@ export async function admitCandidates(
         continue;
       }
     }
+    if (dependsOn.crossRefs.length > 0) {
+      // The cross-repo half (#420): each `owner/repo#n` is read from the repo
+      // it names. The fully qualified form travels in the `detail` string, so
+      // status/digest render it as `blocked by owner/repo#123` while same-repo
+      // refs stay compact `blocked by #5`.
+      let blocking: string | undefined;
+      let unreadable: string | undefined;
+      let unresolved: string | undefined;
+      for (const ref of dependsOn.crossRefs) {
+        const where = crossRepoTarget(project, ref.repo);
+        const full = `${ref.repo}#${ref.issue}`;
+        if (where === undefined) {
+          unresolved = full;
+          break;
+        }
+        let state: IssueSnapshot | undefined;
+        try {
+          if (where === "tracker") {
+            // The qualified form of the candidate's own tracker repo: the
+            // same state read the same-repo interlock uses.
+            state = await tracker.issueSnapshot(ref.issue);
+          } else if (d.probeIssueIn === undefined) {
+            // No resolver wired — fail closed, never guess the issue's state.
+            state = undefined;
+          } else {
+            state = await d.probeIssueIn(ref.repo, ref.issue);
+          }
+        } catch {
+          state = undefined;
+        }
+        if (state?.state === "open") {
+          blocking = full;
+          break;
+        }
+        if (state === undefined) {
+          unreadable = full;
+          break;
+        }
+      }
+      // Same fail-closed posture as same-repo refs: an open prerequisite
+      // holds, an unreadable one holds (the next tick rereads it fresh), and
+      // an unresolved repo holds because the dispatcher cannot verify the
+      // dependency — it is never silently treated as closed. Only the
+      // unresolved repo also surfaces one material event for grooming, and it
+      // follows the malformed-declaration escalation's stable-summary
+      // dedupe, so repeated ticks page once, not per tick.
+      if (blocking !== undefined) {
+        hold(issue, "depends-on", `blocked by ${blocking}`);
+        log(`#${issue} held (depends-on): cross-repo prerequisite ${blocking} is open`);
+        continue;
+      }
+      if (unreadable !== undefined) {
+        hold(issue, "depends-on", `prerequisite ${unreadable} state unreadable`);
+        log(`#${issue} held (depends-on): cross-repo prerequisite ${unreadable} state unreadable`);
+        continue;
+      }
+      if (unresolved !== undefined) {
+        hold(issue, "depends-on", `blocked by ${unresolved} — repo not routed in this fleet`);
+        log(`#${issue} held (depends-on): cross-repo prerequisite ${unresolved} is not a routed repo`);
+        await safeEscalate(d, {
+          tier: 1,
+          project: project.name,
+          issue,
+          summary: `#${issue} depends on ${unresolved}, a repo not routed in this fleet — held until groomed`,
+          detail: [
+            r.issue.title,
+            r.issue.url,
+            `Unroutable prerequisite: ${unresolved}`,
+            "Depends-on cross-repo references must name a repository routed in this project",
+            "(`routing.repos` or the tracker repo). Groom the body or route the repo.",
+          ].join("\n"),
+        });
+        continue;
+      }
+    }
 
     // The file-lane interlock (#555): a candidate whose declared lane overlaps
     // a live run's *actual* lane is held until that run's work has merged, so

package/src/briefs/orchestrator.md

@@ -381,12 +381,27 @@ did not arrive.
 
 ## Human messages
 
-A human writing to you between ticks is not a tick. Answer with a **single
-`telegram_send` call** — one message, the answer only, from evidence you already
-hold or go and fetch. Never answer as plain end-of-turn text: on this session,
-text you merely write reaches nobody — if you do not call `telegram_send`, the
-person gets silence. While handling any turn, produce no visible commentary
-between tool calls — reasoning stays in thinking, actions stay in tools.
+A human writing to you between ticks is not a tick, and how a reply reaches
+them depends on which of three shapes this turn is — a shape the brief states,
+never something a session infers from a tool's error:
+
+- **A locally injected tick** has no inbound message and no topic to keep:
+  hand anything reportable to the outbox with `omp-conductor report`, and reach
+  the operator directly with `omp-conductor message --text "<the message>"`,
+  declaring the escalation category when you are asking. Your tick prompt names
+  this shape — it carries the delivery rule that says when a tick was injected
+  locally.
+- **A turn that began as an inbound Telegram message** is answered with a
+  **single `telegram_send` call** — one message, the answer only, from evidence
+  you already hold or go and fetch — omitting **both** `chat_id` and `thread_id`
+  so the reply keeps the topic the message came from.
+- **An interactive terminal session**, started by hand, is one the operator is
+  reading live: there, end-of-turn text **is** the delivery, and Telegram is
+  used only when it must demonstrably arrive — `telegram_send` resolves
+  `chat_id` from the last inbound message and refuses without one.
+
+While handling any turn, produce no visible commentary between tool calls —
+reasoning stays in thinking, actions stay in tools.
 
 **Reply where the message arrived.** `thread_id` defaults to the active topic
 *only while `chat_id` is omitted*, so a fleet whose Telegram is a forum topic

package/src/briefs/policy.md

@@ -85,11 +85,19 @@ authoritative. All four scopes, spelled out:
   interrupt when operator availability permits; everything else waits for one
   daily rollup.
 
-**Delivery.** Never rely on end-of-turn text reaching anyone. The provable
-delivery paths are `omp-conductor report` (reports — persisted and retried by
-the daemon) and `telegram_send` (direct messages). `telegram_ask` is the decision
-primitive, not Telegram delivery evidence. Everything else is noise or silence.
-Hand every reportable event to the conductor's outbox:
+**Delivery.** A reply reaches the operator by the shape of the turn it answers.
+A **locally injected tick** delivers through the outbox — `omp-conductor report`
+for anything reportable, `omp-conductor message` to reach the operator directly —
+because a report written as end-of-turn text on a tick reaches nobody. A turn
+that **began as an inbound Telegram message** answers with `telegram_send`,
+omitting `chat_id` and `thread_id` so the reply keeps its topic. An **interactive
+terminal session** is read live by the operator, so end-of-turn text *is* the
+delivery there; `telegram_send` resolves `chat_id` from the last inbound message
+and refuses without one, so it is used only when the message must demonstrably
+arrive. The provable delivery paths are `omp-conductor report` (persisted and
+retried by the daemon) and `telegram_send` (direct messages); `telegram_ask` is
+the decision primitive, not delivery evidence. Hand every reportable event to
+the conductor's outbox:
 
 ```
 omp-conductor report --text "<the whole report>"          # a material event