omp-conductor 0.3.20 → 0.3.22

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "omp-conductor",
-  "version": "0.3.20",
+  "version": "0.3.22",
   "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.",

package/skills/conductor-onboarding/SKILL.md

@@ -121,24 +121,37 @@ any agent is: it is long-lived, it can see everything that merged since the last
 release, and batching is exactly the judgement a per-issue session cannot make.
 
 So frame it as **three** options, in this order, and name the default. Each one
-maps to an `authority` answer the wizard asks for directly — the interview
-decides *which answer to give*, and `/conductor setup` is what records it. Never
-write authority into the brief by hand: the config is what words the brief, and
-a hand-edit is a second source that outlives the operator's memory of making it.
+maps to two independent wizard answers:
+
+- `authority.release` says **who owns the release decision**;
+- `releasePolicy` is the mechanical tool gate that says whether release-shaped
+  commands may run at all.
+
+The interview decides both answers, and `/conductor setup` records them. Never
+write either value into the brief or hand-edit `config.json`: config is the
+single source, and the wizard's dry run is where the operator sees the combined
+grant.
 
 1. **Humans release.** *(default, and what the package ships)* Work ends at a
-   green PR. Merging is a separate human action; releasing is a separate human
-   action after that. Neither a worker nor the orchestrator ever tags, pins,
-   publishes, or deploys. "This needs releasing" becomes something the
-   orchestrator *reports*. → `authority: merge=human, release=human`; answer
-   **no** to both wizard confirms.
-2. **The orchestrator releases up to a named boundary.** Delegating part of the
-   release to the supervising session, with the stopping line written down.
-   → usually `merge=orchestrator, release=orchestrator`, with the boundary in
-   the procedure rather than in the grant; `merge=orchestrator, release=human`
-   when the line falls before the tag.
-3. **The orchestrator releases fully.** → `merge=orchestrator,
-   release=orchestrator`.
+   green PR. Merging is a separate decision; releasing is a separate human
+   action. Neither a worker nor the orchestrator tags, pins, publishes, or
+   deploys. "This needs releasing" becomes something the orchestrator reports.
+   → `authority.release=human`, `releasePolicy=none`; answer **no** to both
+   release confirms.
+2. **The orchestrator releases up to a named boundary.** Delegate release
+   authority only when its leg includes the first release action (for example,
+   creating a tag or dispatching a release workflow). → usually
+   `authority.release=orchestrator`, `releasePolicy=operator-brief`, with the
+   boundary in the procedure rather than in the grant. If its leg ends before
+   that action, use `authority.release=human`, `releasePolicy=none`.
+3. **The orchestrator releases fully.** →
+   `authority.release=orchestrator`, `releasePolicy=operator-brief`.
+
+Merge authority is its own confirm in every option. Also say what opening the
+tool gate means: it is project-wide and is passed to worker sessions as well as
+the orchestrator. It does not grant workers release authority — their brief
+still stops them at a green PR — but it removes the mechanical block. Never open
+it until the operator has reviewed the release procedure and stopping boundary.
 
 Then ask the question that makes option 2 real:
 
@@ -443,12 +456,15 @@ PR URL, an issue number, or a named check actually read.* "Should be fine",
 "looks green" and "probably passing" are not evidence.
 
 Know what is *not* up there, though, because operators expect it to be: the
-orchestrator's own merge and release authority is **not** a hard boundary. It is
-config — the two `authority` answers — and it defaults to none. What is fixed
-above the banner is that a *worker* never merges or releases, and that PRs land
-one at a time with a freshness re-check. Delegating a release to the
-orchestrator does not touch either of those, so it needs no negotiation with the
-shipped half.
+orchestrator's merge and release authority is **not** a hard boundary. It comes
+from the two `authority` answers in config. Release execution has a second,
+independent config control: `releasePolicy=none` mechanically blocks tags,
+publishing, releases, and deploy commands even when
+`authority.release=orchestrator`; `operator-brief` opens that gate for the
+reviewed procedure. What is fixed above the banner is that a *worker* never
+merges or releases, and that PRs land one at a time with a freshness re-check.
+Changing either release control needs no negotiation with the shipped half, but
+both must agree with the procedure below the banner.
 
 **Below the banner — rewrite from the interview.**
 
@@ -552,9 +568,11 @@ label; whether to rename the state labels; routing label prefix; then per repo t
 routing key, clone URL, default branch and **pre-push gates** (your Step 2
 proposal, in `cmd @ cwd` form); whether to add another repo; whether to set up
 **code-graph discovery** and the root its clones live under (Step 8); caps; the
-authority confirms; the worker model; the Telegram chat id for tier 2; the
-escalation fallback; whether an orchestrator session already runs elsewhere; the
-report scope; and finally whether to write `ORCHESTRATOR.md` + `POLICY.md`.
+merge and release authority confirms; the independent **Release tool gate**
+confirm (`none` or `operator-brief`); the worker model; the Telegram chat id for
+tier 2; the escalation fallback; whether an orchestrator session already runs
+elsewhere; the report scope; and finally whether to write `ORCHESTRATOR.md` +
+`POLICY.md`.
 
 The end of the wizard is load-bearing:
 
@@ -565,6 +583,12 @@ The end of the wizard is load-bearing:
 - **Nothing changes before consent.** Setup creates no label, file, database, or
   arm marker before the operator agrees. Never answer that consent prompt for
   the operator.
+- **Review authority and gate together.** If the procedure assigns tags,
+  publishing, release creation, or deploy commands to the orchestrator, the dry
+  run must show both `release=orchestrator` and
+  `releasePolicy=operator-brief`. `release=orchestrator` with
+  `releasePolicy=none` assigns the job while mechanically preventing it. A
+  human-owned release should normally remain `releasePolicy=none`.
 - **The host plan is part of consent.** For an external orchestrator, setup names
   the heartbeat file and both safety gates. It also names the staged systemd
   unit. An invalid existing heartbeat stops setup before any write.

package/src/briefs/orchestrator.md

@@ -151,6 +151,13 @@ actually asked, in one message, from evidence you already hold or go and fetch.
 Then stop. Do not continue loop narration in the same reply, and do not restate
 in-progress work unless they asked for it. The loop resumes on the next tick.
 
+A message may also reach you **mid-tick** (delivery is steering: it arrives
+between two of your tool calls). Treat it as an interrupt, not a new tick:
+answer it immediately with `telegram_send` in one message, then return to the
+duty you were in the middle of and finish it. Never abandon or restart the tick
+because a message arrived, and never batch the answer "for the report" — the
+person is waiting now.
+
 ## Escalation tiers
 
 | Tier | Meaning | Handled by |