voidmachine 4.0.0 → 5.0.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -1,14 +1,15 @@
1
1
  ---
2
2
  name: void-autopilot
3
- description: Use to run the continuous delivery loop, where a curator ranks the backlog, up to four workers each run void-implement to a PR, and a bounded review gates the GitHub merge queue until drained or stopped.
3
+ description: Use to run the continuous delivery loop, where a curator ranks the backlog, up to four workers each run void-implement to a PR, and a local review verdict gates each merge until drained or stopped.
4
4
  ---
5
5
 
6
6
  # autopilot
7
7
 
8
8
  A continuous loop that takes tickets from the tracker to the integration branch without a human
9
9
  at each merge. A curator ranks what is worth doing, up to four workers each carry one ticket to
10
- a pull request, a reviewer reads each one once, and GitHub merges what is green through its merge
11
- queue. Promotion to the branch that deploys stays human.
10
+ a pull request, a reviewer reads each one once, and the loop merges the head it passed, through
11
+ GitHub's merge queue when the base has one. A person who says they merge themselves gets every
12
+ reviewed pull request instead. Promotion to the branch that deploys stays human.
12
13
 
13
14
  **Attribution**: see `.source`.
14
15
 
@@ -22,25 +23,31 @@ then reviews..." inside autopilot, stop: that behaviour has one owner, and two c
22
23
  a ticket gets a different standard depending on how it was started.
23
24
 
24
25
  It never merges on a flag. Not on the command line, not because the checks are green, not because
25
- the diff is small. Consent to a machine merge is a durable declaration in the programme --
26
- `mergeGate: union-reviewed` together with a `deployBranch` -- and there is no `--auto-merge` on
27
- any path. Under `mergeGate: human` a ready pull request goes to a person; that wait is by design
28
- and never counts toward the streak that stops the loop. Promotion from the integration branch to the one that deploys stays human
29
- under both gates.
26
+ the diff is small. There is no `--auto-merge` on any path and no merge gate to configure: the loop
27
+ merges into the integration branch only a head a local verdict passed, and never into the branch
28
+ that deploys -- `autopilot.deployBranch`, or the repository's default branch when the programme
29
+ names none. When the person says they merge themselves, run `void-machine autopilot merges
30
+ --by-human`: from the next tick every reviewed pull request goes to them instead (see Who merges).
31
+ Promotion from the integration branch to the one that deploys stays human.
30
32
 
31
33
  It never merges a change to the machinery that judges merges. A pull request touching
32
34
  `.github/**`, `scripts/independent-review-check.mjs`, `.void/program.md`, `packages/core/hooks/**`,
33
35
  what a judging workflow runs from outside `.github`
34
36
  (`scripts/promotion-authority.mjs`, `scripts/auto-merge-contract.mjs`, `scripts/verify.mjs`,
35
37
  `packages/core/enforce/**`), what judges a publication (`scripts/prepare-release-artifact.mjs`,
36
- `scripts/verify-release-publication.mjs` and the two release contracts they read), the loop code that believes a verdict and arms a merge (`loop.ts`,
37
- `loop-observe.ts`, `review-signature.ts`, `commands/autopilot-loop.ts`), or the hooks installed here (`.void/hooks/**`, `.claude/settings.json`,
38
- `.codex/**`, `.void/config.json`) goes to a person with the file named (`protected-path`). A rename
38
+ `scripts/verify-release-publication.mjs` and the two release contracts they read), the loop code that believes a verdict and merges (`loop.ts`,
39
+ `loop-observe.ts`, `branch-identity.ts`, `commands/autopilot-loop.ts`), the local chain of judgment
40
+ (`packages/void-machine/src/**`, `commands/agents.ts`, `program.ts`, `judgments.ts`,
41
+ `merge-hold.ts`, the review command, its parser and the reviewer's definition,
42
+ `footprint-area.ts`), or the
43
+ runtime configuration installed here, which a reviewer running in a worktree of the head loads too
44
+ (`.void/hooks/**`, `.claude/**`, `.mcp.json`, `.codex/**`, `.void/config.json`) goes to a person with the file named (`protected-path`). A rename
39
45
  counts by its source and its destination. The programme adds paths through
40
46
  `autopilot.protectedPaths`; nothing removes from that floor.
41
47
 
42
- It never closes, cancels or deletes a ticket, and it never touches `main`, the secrets or the
43
- repository settings.
48
+ It never closes, cancels or deletes a ticket, and it never touches `main` or repository settings.
49
+ Autopilot consent alone never authorizes credential operations: these require separate explicit
50
+ scope under `void-security-guidance`. Role restrictions, including read-only reviewers, remain binding.
44
51
 
45
52
  ---
46
53
 
@@ -52,7 +59,9 @@ the `autopilot` block, so there is nothing to ask: not which ticket, not which p
52
59
  That file is also the consent, and consent is never inferred. An absent `.void/program.md`, a
53
60
  `status` other than `executing`, an `autopilot` block that is missing or unreadable, or
54
61
  `autopilot.enabled: false` all mean the same thing -- say so and stop. `void-machine autopilot next`
55
- refuses the same cases; inventing a target claims tickets nobody agreed to hand over.
62
+ refuses the same cases; inventing a target claims tickets nobody agreed to hand over. A programme
63
+ still written for the 4.0 merge gate (`autopilot.schemaVersion: 1` with `mergeGate`) is refused
64
+ too, with its migration; a former `mergeGate: human` runs `autopilot merges --by-human` first.
56
65
 
57
66
  ---
58
67
 
@@ -84,9 +93,10 @@ skip a step, merge, or decide that a refusal does not apply to it.
84
93
  **Workers**, one per slot. Each carries one ticket from claim to an open pull request, in its own
85
94
  worktree, by running `void-implement` whole.
86
95
 
87
- **Reviewer.** The independent pass of `void-implement`, run by GitHub itself: the
88
- `independent-review` job, in a fresh context, on the exact head SHA of every ready pull request.
89
- There is no second review at merge time: its check is what GitHub requires.
96
+ **Reviewer.** The independent pass of `void-implement`, invoked by ORCH through
97
+ `void-orchestrate` in a fresh read-only context on the exact head SHA. `autopilot review`
98
+ prepares and collects its canonical receipt locally. There is no second review at merge
99
+ time: the merge happens on that head alone.
90
100
 
91
101
  A role that starts doing another's job is the failure this split exists to prevent: an orchestrator
92
102
  that "just looks at the diff" becomes a reviewer nobody bounded, and a worker that posts its own
@@ -145,9 +155,11 @@ Act on each returned action, then ask again:
145
155
  | `wait` | nothing; the reason says who is working |
146
156
  | `hand-back-to-worker` | give the ticket back to its worker, alive or respawned in the same worktree, with the reason and the pull request; a respawned worker resumes its mission (see Respawning) |
147
157
  | `mark-human-wait` | record it in `recent` with its `reason`, which `recent` requires and the recap repeats, put the decision's `humanWaitLabel` on the ticket, comment the reason and detail, free the slot; keep reporting its pull request and footprint, which hold its ground until that pull request merges or closes |
148
- | `enable-auto-merge` | `void-machine autopilot arm --ticket <id> --pr <n> --head <headSha>`: it records the head, arms on exactly that head and reads GitHub back; never `gh pr merge --auto` by hand, never `--admin` |
158
+ | `merge` | `void-machine autopilot merge --ticket <id> --pr <n> --head <headSha>`, on a base with no merge queue: it proves again the hold, the verdict and the target, merges exactly that head with `--match-head-commit`, and arms the native auto-merge on it when the base's policy refuses a direct merge; never `gh pr merge` by hand, never `--admin` |
159
+ | `update-branch` | `void-machine autopilot update-branch --pr <n> --head <headSha>`: GitHub merges the base into the branch if its head is still that one; the new head is reviewed before anything merges it |
160
+ | `enable-auto-merge` | `void-machine autopilot arm --ticket <id> --pr <n> --head <headSha>`, on a base with a merge queue: the same guards, then it records the head, arms on exactly that head and reads GitHub back; never `gh pr merge --auto` by hand, never `--admin` |
149
161
  | `disable-auto-merge` | `void-machine autopilot disarm --pr <n>`, before the action that follows it for the same ticket; it turns its auto-merge off, then takes it out of the merge queue, and fails while GitHub still shows either; never `gh pr merge --disable-auto` alone, which leaves a queued pull request in the queue |
150
- | `rerun-review-check` | `gh run rerun <run> --failed`: the review job failed on this head without posting a verdict, a crash or an output it refused; twice at most per run, then `review-check-reruns-exhausted` |
162
+ | `review` | `void-machine autopilot review --ticket <id> --pr <n> --head <headSha> --round <round> --mission <canonical-id>`; on awaiting-native-review use `void-orchestrate` for the actual reviewer, record canonical receipts, then repeat to collect. The same attempt keeps its 30 minute deadline; failures retain the existing budget |
151
163
  | `requeue` | the same command, to put an ejected head back in the queue; the kernel bounds how often |
152
164
  | `drain` | take nothing new; keep acting on the tickets in flight |
153
165
  | `freeze` | stop acting, once the disarms before it succeeded |
@@ -159,12 +171,20 @@ send each back to the agent that produced it.
159
171
 
160
172
  **Spawning.** Every worker gets its worktree before it starts, at the durable location the
161
173
  doctrine's worktree rule names, reused when its branch already has one. A worker never chooses its
162
- own checkout and never works in the main one. When the project uses the cockpit presentation
163
- described in the harness's native supervision guide, each worker and reviewer is launched once in
164
- its own surface to the right of the orchestrator; without it, workers are native subagents. The
165
- presentation shows the loop; it never grants a permission, a proof or a merge.
166
-
167
- **Respawning.** A respawned worker resumes; it never starts the ticket again. Its code is in its
174
+ own checkout and never works in the main one. Compose `void-orchestrate` to choose supported
175
+ native delegation, including the session-host selection policy and the Herdr adapter
176
+ with its central files when applicable. Count writers,
177
+ researchers and reviewers against available dispatch capacity; the ticket cap is unchanged.
178
+ An assigned worker executes the unit once, without recursively delegating the complete cycle.
179
+ `liveWorkers` reflects reconciled actual sessions and current evidence, never stale pane hints.
180
+ No permission is widened. Collect results before closure; uncertainty requires reconciliation.
181
+
182
+ **Respawning.** A hand-back goes to the same native session that holds the ticket, with the
183
+ reason and pull request as data. Re-read mission, Git and actual session evidence; consult central
184
+ brief/report and fresh Herdr identities only when that adapter is selected. Never a second run
185
+ beside an existing or uncertain invocation. A missing session is reported; retain its evidence.
186
+
187
+ A respawned worker resumes; it never starts the ticket again. Its code is in its
168
188
  worktree and its branch, its progress in its mission journal, `.void/machine/runs/<mission>/events.jsonl`
169
189
  under the installation root, which is the main checkout and not the worktree. It finds its mission
170
190
  as the open one whose `mission.json` carries the ticket id as its title, runs
@@ -194,24 +214,36 @@ GitHub keeps an auto-merge armed across a push by anyone with write access, show
194
214
  no armed head, and its required check trusts the status alone. So `arm` records the head it armed,
195
215
  and `next` returns `disable-auto-merge` when it can no longer vouch for an armed pull request: its
196
216
  head moved since `arm` recorded it (then `hand-back-to-worker`, `head-moved-after-arming`: the new
197
- head is unreviewed), the seal no longer proves a clean verdict on the armed head (then
198
- `mark-human-wait`, `armed-verdict-unproven`), or nothing recorded the arming (then
199
- `mark-human-wait`, `ambiguous-state`). An armed merge survives a tick only while the loop vouches
200
- for its head and hands it to nobody (`wait merging`, `rerun-review-check`): a worker at work, any
217
+ head is unreviewed), no clean local verdict holds the armed head (then
218
+ `mark-human-wait`, `armed-verdict-unproven`), nothing recorded the arming (then
219
+ `mark-human-wait`, `arming-unrecorded`), or a person took the merges back (then
220
+ `mark-human-wait`, `human-merge-hold`). An armed merge survives a tick only while the loop vouches
221
+ for its head and hands it to nobody (`wait merging`): a worker at work, any
201
222
  hand-back, a human wait and an immediate stop all come with the disarm. Disarm first, always.
202
223
 
203
- **The review runs in GitHub.** `.github/workflows/independent-review.yml` reviews every ready
204
- pull request into the base on `pull_request_target`: GitHub runs its workflow, scripts and
205
- instructions from the default branch, which only a person merges into, so a change to the review
206
- takes effect once promoted there; the head is read as data and never run, and the verdict becomes the
207
- `independent-review` check on that head, posted by the review App, a GitHub App holding the Checks
208
- permission alone. Branch protection requires the check from that App, so the same name from any
209
- workflow's `GITHUB_TOKEN` does not count. For each merge group, `independent-review-queue.yml`, on
210
- `workflow_run` of `ci` and also from the default branch, posts the App's check on the group commit
211
- once every head of the group carries it. No key or secret for it lives on this machine, so neither a
212
- worker nor a compromised dependency it runs can forge an approval: the App's key and the
213
- `CLAUDE_CODE_OAUTH_TOKEN` live in the `independent-review` environment, whose deployment branch
214
- policy admits the default branch alone.
224
+ **The review is local.** `autopilot review` prepares the exact head in a detached worktree,
225
+ checks its `HEAD` before and after collection and refuses any protected path. ORCH invokes the
226
+ native reviewer there. Collection requires the canonical independent receipt and actual matching
227
+ request/start/completion: reviewedCommit, baseCommit, acceptanceCriteriaHash, distinct writer and
228
+ reviewer, read-only scope and authentic native-context or review-artifact provenance. A central
229
+ report marked done proves none of these. The verdict is recorded in
230
+ `.void/machine/autopilot/reviews/<ticket>/<head>.json`; `next` decides on that record alone.
231
+ One attempt runs per head, pending rereads do not reset its deadline, recorded verdicts are
232
+ immutable and rounds are counted from existing records. Legacy in-flight runs retain their own
233
+ collector and journals. A verdict posted on the pull request is a copy for people. Checks,
234
+ protected paths, shared-state fingerprints, human holds and merge permissions are unchanged.
235
+ Remove a review worktree with the ticket's own only after the pull request is observed merged.
236
+
237
+ **Who merges.** The loop, by default. When the person says they merge themselves, run
238
+ `void-machine autopilot merges --by-human`; `--automatic` gives the merges back, and bare
239
+ `merges` prints the state. The hold is a file in the machine's state,
240
+ `.void/machine/autopilot/merge-hold.json`, never the programme, which is protected and versioned:
241
+ it takes effect on the next tick, with no pull request, and every decision reports it in
242
+ `merges`. It hands a pull request over after the review, never before: a head is reviewed, its
243
+ checks settle, then it goes to the person (`mark-human-wait`, `human-merge-hold`), and an armed
244
+ merge is disarmed first. A hold file that cannot be read counts as a hold. Those waits never
245
+ count toward the streak that stops the loop. A hold only takes authority away; removing it
246
+ returns to the default the person already accepted.
215
247
 
216
248
  **No state lives in the session.** Who holds which ticket comes from the tracker (status, assignee,
217
249
  pull request link, the human-wait label); the rest comes from GitHub. The label is the one every
@@ -223,12 +255,11 @@ request whenever they exist, whatever its status: a ticket still ready but with
223
255
  request is a unit in flight, and the kernel resumes it instead of seating a second worker. A
224
256
  ticket whose state is ambiguous goes to a human rather than being relaunched.
225
257
 
226
- **Judgments live on the pull request.** The reviewer's verdict and a worker's conflict class are
227
- comments carrying a machine block: two HTML comment markers around a fenced JSON value. The verdict
228
- is posted only by the review job, beside its check; `next` believes the job's latest verdict on the
229
- head only when that check agrees with it, and a block anyone else posts is text. The conflict class is the block `void-machine autopilot judgment conflict-class`
230
- prints for the JSON on its stdin. `next` reads both from GitHub and admits them again, so the
231
- tracker you pipe in never carries them and a restart loses nothing.
258
+ **Judgments survive a restart.** A worker's conflict class is a comment carrying a machine block:
259
+ two HTML comment markers around a fenced JSON value, the block `void-machine autopilot judgment
260
+ conflict-class` prints for the JSON on its stdin; `next` reads it from GitHub and admits it again.
261
+ The review verdict is the local record above, never a comment. The tracker you pipe in carries
262
+ neither, so a restart loses nothing.
232
263
 
233
264
  ---
234
265
 
@@ -244,8 +275,9 @@ through `mission verify`, a committed candidate through `mission writer-event`.
244
275
  only these typed events, no free note; what is not yet one of them does not survive a respawn, and
245
276
  uncommitted edits survive only in the worktree. When its proofs are green it runs
246
277
  `autopilot fingerprint --after <ticket>`, pushes its own branch, opens one pull request towards the
247
- base, ready for review rather than as a draft, and moves the ticket to In Review. The review job's
248
- pass is that cycle's independent review; it reviews ready pull requests only, so a draft waits.
278
+ base, ready for review rather than as a draft, and moves the ticket to In Review. The reviewer the
279
+ orchestrator invokes is that cycle's independent review; it reviews ready pull requests only, so a
280
+ draft waits.
249
281
  Blocking findings come back as a hand-back and are corrected as a batch, per `void-implement`.
250
282
 
251
283
  On a hand-back the worker reads the reason: failing checks, blocking findings, a conflict, or a
@@ -255,7 +287,7 @@ never by rewriting pushed history, re-runs its proofs, and pushes again.
255
287
  May: run every `void-implement` pass whose predicate fires, run its own gates, apply a migration in
256
288
  dev/local only, push its own branch without force, and open or update its own pull request.
257
289
 
258
- May not: enable auto-merge, merge anything, post a verdict or re-run the review job, move a ticket to Done, close or cancel a ticket, touch another ticket's branch or worktree,
290
+ May not: enable auto-merge, merge anything, post or record a verdict, run `autopilot review`, move a ticket to Done, close or cancel a ticket, touch another ticket's branch or worktree,
259
291
  prune the mission journals, or write the git state the repository shares -- `refs/stash`, tags,
260
292
  notes, remotes, the repository config.
261
293
 
@@ -263,11 +295,11 @@ notes, remotes, the repository config.
263
295
 
264
296
  ## Reviewer
265
297
 
266
- The `independent-review` job, on every push to a ready pull request and when one is marked ready.
267
- Its instructions are `.github/review/prompt.md` on the base; it reads the diff and the head with
268
- read-only tools and returns `blocking` and `advisory` findings under a JSON schema. The job binds
269
- them to the head and the round, posts the verdict comment and concludes the check: success with no
270
- blocking finding, failure otherwise, failure too when the output is missing or out of bounds.
298
+ `independent-code-reviewer`, collected by `autopilot review` on the head of a ready pull request.
299
+ Its brief carries the diff against the merge base as data, what blocks, and the answer it returns:
300
+ its own completion contract, each finding classified, a blocking one located at `path:line` in the
301
+ head. The kernel binds the answer to the head and the round; a reviewer that could not judge, whose
302
+ verdict contradicts its findings, or whose answer the contract refuses, gives no verdict.
271
303
 
272
304
  **What blocks.** Only what is wrong or dangerous, with a concrete scenario: incorrect behaviour, a
273
305
  vulnerability, an unstable or empty proof, a broken consumer. Each blocking finding names its
@@ -279,17 +311,20 @@ orchestrator, and never come back into the loop.
279
311
 
280
312
  **Rounds.** After a correction, round 2 is handed round 1's blocking findings and checks only those
281
313
  against the new diff; it opens no new general reading. Still blocking after round 2, the kernel
282
- hands the ticket to a human with the finding. The kernel counts rounds on GitHub, one per head the
283
- job blocked, not from the round a verdict announces, and a job that failed without a verdict is a
284
- crash it re-runs, not a round.
314
+ hands the ticket to a human with the finding. The kernel counts rounds from the local records, one
315
+ per head a verdict blocked, not from the round a verdict announces, and a reviewer that failed
316
+ without a verdict is an attempt it delegates again, not a round.
285
317
 
286
318
  ---
287
319
 
288
320
  ## Conflicts and the merge queue
289
321
 
290
- When the base has a merge queue, GitHub rebuilds the combined commit of every pull request ahead
291
- and reruns the required checks, `independent-review` included, before it merges. Two tickets green
292
- alone and broken together cannot reach the base.
322
+ A head merges once a clean local verdict holds it, no check on it fails or is pending (a head no
323
+ check runs on merges on its verdict alone), no protected path is touched and its branch is up to
324
+ date with the base. When the base has a merge queue, GitHub rebuilds the combined commit of every
325
+ pull request ahead and reruns the required checks before it merges. Two tickets green alone and
326
+ broken together cannot reach the base. Required checks a repository adds on the base are one more
327
+ gate GitHub enforces at merge time; the loop needs none.
293
328
 
294
329
  A pull request ejected from the queue whose head still passes its checks and carries a clean
295
330
  verdict has nothing for its worker to fix: the kernel answers `requeue`, at most twice for the same
@@ -302,11 +337,11 @@ sends the ticket to a human. A worker never picks a side of a semantic conflict
302
337
  moving.
303
338
 
304
339
  **Serial fallback.** Without a merge queue, merges run one at a time: the oldest ready pull request
305
- (or the one already merging) holds the turn, is updated on the base when it is behind, re-checked,
306
- merged, then the next. Same guarantee, lower throughput. The kernel keeps the turn; you do not.
307
- It holds only if the base refuses a pull request that is not up to date, so `next` checks that the
308
- base requires it (classic protection or a ruleset) and refuses the tick, naming the fix, when
309
- nothing readable says so.
340
+ (or the one already merging) holds the turn. The kernel reads whether the base moved past its head
341
+ itself, since GitHub reports it only under a protection that requires it: a head behind gets
342
+ `update-branch`, its new head is reviewed again, then merged, then the next. `merge` reads it once
343
+ more just before merging. Same guarantee, lower throughput; the residual window is a person
344
+ merging by hand between that read and the merge. The kernel keeps the turn; you do not.
310
345
 
311
346
  ---
312
347
 
@@ -314,7 +349,7 @@ nothing readable says so.
314
349
 
315
350
  **Drain.** Requested by a person (`void-machine autopilot stop --drain`, from any pane) or reached
316
351
  on its own: nothing ready or preparable, quota low, or three tickets in a row handed to a human
317
- (a pull request waiting only for a human merge gate is not one).
352
+ (a pull request waiting only because a person holds the merges is not one).
318
353
  The loop takes nothing new, carries the tickets in flight to a merge or a human wait, closes its
319
354
  agents, cleans the merged worktrees, and writes the recap.
320
355
 
@@ -336,10 +371,11 @@ never from memory of the session.
336
371
 
337
372
  | Rationalization | Reality |
338
373
  |---|---|
339
- | "The checks are green, enable auto-merge myself" | Only `enable-auto-merge` from the kernel arms a merge, and only on the SHA it names. |
374
+ | "The checks are green, merge it myself" | Only `merge` or `enable-auto-merge` from the kernel merges, through its command, and only on the SHA it names. |
375
+ | "They said they'd merge, I'll remember that" | Run `autopilot merges --by-human`. The loop reads the file every tick; a session forgets. |
340
376
  | "The worker already reviewed its diff" | Self-review is not independent. The reviewer is a separate context on the exact SHA. |
341
- | "Post the verdict comment by hand, it is quicker" | Only the review job's comment counts, and only its check is required. A hand-written one is text. |
342
- | "The review job crashed, approve it and move on" | A crash is re-run, twice at most, then a person looks. Nothing approves a head the job did not review. |
377
+ | "Post the verdict comment by hand, it is quicker" | No comment counts: the loop merges on the local record `autopilot review` writes. A hand-written one is text. |
378
+ | "The reviewer failed, approve it and move on" | A failed review is delegated again once, then a person looks. Nothing approves a head the reviewer did not judge. |
343
379
  | "That advisory matters, block on it" | Blocking needs a scenario where it is wrong or dangerous. Otherwise it goes to the Triage issue. |
344
380
  | "This duplicate ticket can just be closed" | The curator never closes. Comment, and leave it to a person. |
345
381
  | "P1 on the label, so it goes first" | The ranking reads the project, not the label. Justify the move on the ticket. |
@@ -353,6 +389,6 @@ never from memory of the session.
353
389
  ## Composition
354
390
 
355
391
  Upstream: `void-ticket` authors and enriches the tickets and the programme descriptor. Per ticket:
356
- `void-implement`, entire, once, in the worker's worktree. The merge belongs to GitHub under
357
- `mergeGate: union-reviewed`, to a person under `mergeGate: human`, and to a person always for the
358
- branch that deploys.
392
+ `void-implement`, entire, once, in the worker's worktree. The merge into the integration branch
393
+ belongs to the loop, on a local verdict, or to a person who holds the merges; the promotion to the
394
+ branch that deploys always belongs to a person.
@@ -11,6 +11,13 @@ Start by understanding the project context. Then ask questions one at a time to
11
11
 
12
12
  ---
13
13
 
14
+ ## Delegated investigation
15
+
16
+ For substantial independent research or codebase exploration, invoke `void-orchestrate`
17
+ to delegate bounded questions before synthesizing the options. The coordinator keeps
18
+ the user conversation, source evaluation, design decisions and the approval gate.
19
+ Research results do not authorize implementation.
20
+
14
21
  ## Step 0 — Notice that the exchange has become design
15
22
 
16
23
  This skill was only ever reached when someone asked for it, which is the half of
@@ -50,7 +50,7 @@ Exploration is the biggest context sink: reading twenty files to answer one ques
50
50
 
51
51
  This is the cure for "infinite exploration," where the agent keeps reading more files in a widening search and the window fills with material it will never cite. Dispatch a subagent, state the question, accept the conclusion.
52
52
 
53
- Vendored targets: `superpowers:dispatching-parallel-agents` (fan out several investigations at once) and `superpowers:subagent-driven-development` (run independent plan steps in subagents). Until vendored, use those directly.
53
+ Invoke `void-orchestrate` for the native delegation contract. If capabilities are unavailable, follow its explicit fallback without weakening a mandatory independent review.
54
54
 
55
55
  A subagent must return a **compacted structured summary** — findings, the answer, the relevant file:line pointers — never the raw bytes it read. Raw output dumped back into the main window defeats the delegation.
56
56
 
@@ -129,8 +129,7 @@ Decompose long tasks into sub-tasks with their own gates (composes with `void-pl
129
129
  - **`void-debug`**: investigate without drowning the window — gather evidence in a subagent, bring back the timeline and root cause, not every log line read.
130
130
  - **`void-plan`**: owns the approved execution structure; mutable progress remains with its declared provider.
131
131
  - **`void-checkpoint`**: owns semantic session residue; the lifecycle hook owns only the delimited mechanical block it must preserve.
132
- - **`superpowers:dispatching-parallel-agents`** (vendored target): fan out independent investigations to protect the main window.
133
- - **`superpowers:subagent-driven-development`** (vendored target): run independent plan steps in fresh-context subagents.
132
+ - **`void-orchestrate`**: delegate bounded independent investigations with fresh context by default; it owns capability fallback, dispatch bounds, isolation and collection. Keep conclusions and evidence references in the coordinator rather than full child transcripts.
134
133
 
135
134
  This skill absorbs the "context-engineering / anti-context-rot" concept; other skills do the work, this one keeps the window clean enough for them to do it well.
136
135
 
@@ -13,6 +13,15 @@ One ticket, taken from ready to shipped, with the coverage a senior expert team
13
13
 
14
14
  ---
15
15
 
16
+ ## Assign the writer once
17
+
18
+ The interactive coordinator invokes `void-orchestrate` to delegate substantial
19
+ implementation to one writer before starting this cycle. An agent already assigned the unit
20
+ executes it: never delegate this complete workflow again. Tiny direct work and
21
+ capability fallbacks follow that policy without skipping triggered quality gates.
22
+ Preserve one `leadWriterId` through corrections; the coordinator retains user intent
23
+ and decisions. Pass any orchestrator-owned panel contract unchanged.
24
+
16
25
  ## Canonical team orchestration
17
26
 
18
27
  When the caller supplies `panel.provider: orchestrator`, the orchestrator owns specialist
@@ -28,16 +37,16 @@ materializes its runtime-neutral specialist envelopes from the current plan.
28
37
  the worktree and code; specialists and the independent reviewer never edit.
29
38
  2. Start with `mission start --ticket <ticket>` and follow `mission dispatch --id <mission>
30
39
  --json`. The frozen task and controller own routing, state and correction budget. Before
31
- implementation, invoke only the risk-relevant preparation specialists returned by dispatch.
32
- Supply their exact envelopes and context packs; collect each result without inventing a
33
- completion. Record each actual start and completion with `mission specialist-event --id <mission>`.
34
- A missing response calls for resumption, not another correction cycle.
40
+ implementation, launch only the risk-relevant preparation specialists returned by dispatch,
41
+ each envelope through `void-orchestrate` using the native runtime (pass 5). Collect each result without
42
+ inventing a completion. Record each actual start and completion with `mission specialist-event
43
+ --id <mission>`. A missing response resumes the run it already has, never another cycle.
35
44
  3. The implementer implements and verifies, then commits the candidate. Record the pending
36
45
  writer receipt with `mission writer-event --id <mission>`. Review must bind an exact
37
46
  `reviewedCommit`, `baseCommit` and `acceptanceCriteriaHash`; a mutable worktree is insufficient.
38
47
  Prefer a dedicated worktree pinned to that commit, with native read-only permissions.
39
- 4. Dispatch one independent general review. Use the runtime's native separate reviewer context
40
- and preserve its actual result. Submit the canonical completion and minimal review receipt:
48
+ 4. Dispatch one independent general review through `void-orchestrate` in a fresh native
49
+ read-only context, preserving its actual invocation. Preserve its actual result. Submit the canonical completion and minimal review receipt:
41
50
  task, reviewer and writer identities, exact subject, conclusions, proofs and resolutions.
42
51
  Native context identity supplements provenance; missing or refused identity alone does not
43
52
  invalidate an executed, traceable independent review. Use the supported artifact provenance
@@ -92,7 +101,7 @@ Run in order. Each pass names the skill it composes and the predicate that fires
92
101
  2. **Architecture pass** (IF it touches structure, a module boundary, the data model, or public types). Compose `void-hexagonal-architecture`, `void-domain-driven-design`, agents `type-design-analyzer` + `doctrine-critic`. Confirm the applicable ADR is honored.
93
102
  3. **Source grounding** (ALWAYS; the source depends on what the change touches). Read the relevant sources before the first line, per the Anti-rustine section of `PHILOSOPHY.md`. For a third-party configuration, schema or call signature, compose `void-source-driven-development`: official documentation **of the installed version**, never an upgrade by default. For internal code, read the owning contract, types, source and project docs of what you are about to change. Assumed semantics produce bugs that cost hours to find, and the assumption is invisible in the diff — which is why this runs before the writing rather than at review. Cite a source briefly when it helps understand or record a choice; a missing citation never blocks on its own.
94
103
  4. **Migration safety** (IF it changes a DB schema or ships a migration). Compose `void-migrations` (and `void-drizzle-migration-safe` on a Drizzle/Postgres stack): zero-downtime, two-phase, batched backfill, locking analysis. **Once the migration is generated and safety-reviewed, apply it to the dev/local database before the TDD and E2E passes run** — otherwise those tests execute against a stale schema and prove nothing about the new shape. **This cycle only ever applies to dev/local; production migrations run through CI / GitHub Actions on merge, never from a worker or this session** (see the `void-migrations` anti-rule). A schema change must never reach the rest of the cycle without this pass.
95
- 5. **Convene the panel** (ALWAYS once, in `team` mode). Call `mission dispatch --json` and act on what it returns. In `team` mode its first action is `invoke-specialists` at `stage: 'pre-implementation'`: the panel speaks **before** the first line is written, which is the whole reason it exists. Invoke each returned envelope's exact `agentName` in a fresh context and paste that envelope's `contextPack` into the prompt verbatim -- the diff, the touched paths, the artifacts, and `omitted` naming what the budget refused. Do not point a specialist at a file to read and do not send it exploring: its turns are few, and a specialist that spends them looking returns nothing. Record `started`, then `completed` or `failed`, for every envelope. Findings from this pass are the brief the writer implements against; a `blocked` verdict stops the cycle here rather than after the code exists. Later dispatches follow the controller's current stage and never replay this preparation pass.
104
+ 5. **Convene the panel** (ALWAYS once, in `team` mode). With `panel.provider: orchestrator`, consume ORCH's supplied panel and never launch another. Otherwise call `mission dispatch --json`: its first `invoke-specialists` action is at `stage: 'pre-implementation'`, before code. Compose `void-orchestrate` for native invocation. Pass the envelope's runtime, agentName, missionId, contextPack, reviewSubject and reviewScope unchanged; record actual starts and complete results using `mission specialist-event`. Reconcile an existing invocation before dispatch; uncertain identity means no launch. Keep at most four simultaneous agents, wait in bounded slices, and never fail an agent merely because a wait timed out. Findings brief the single writer; a concrete blocked verdict is resolved before implementation. Later controller stages reuse this transport and never replay preparation. Missing required capability is diagnosed, never fabricated.
96
105
  6. **TDD implementation** (ALWAYS). The single lead writer composes `void-tdd` + `void-testing`. Red, green, refactor. Unit tests for the behavior, green before moving on. Review specialists remain read-only.
97
106
  7. **Async + idempotency** (IF it sends email, calls an external side-effecting API, enqueues a job, or mints a single-use token). Compose `void-async-safety`: idempotency keys, replay/dedup window, bounded retries, single-use enforcement.
98
107
  8. **End-to-end tests** (IF it touches a user-facing flow). Write/extend the E2E suite (Playwright). The path a user actually walks, not just the unit.
@@ -0,0 +1,16 @@
1
+ Distilled from official contracts, checked against installed versions on 2026-10-08:
2
+ - Herdr 0.9.0 automation: https://raw.githubusercontent.com/herdrdev/herdr/v0.9.0/docs/next/website/src/content/docs/agent-automation.mdx
3
+ - Herdr 0.9.0 restoration: https://raw.githubusercontent.com/herdrdev/herdr/v0.9.0/docs/next/website/src/content/docs/session-state.mdx
4
+ - Herdr metadata implementation: https://github.com/herdrdev/herdr/blob/v0.9.0/src/metadata_tokens.rs
5
+ - Herdr resume_argv version boundary: https://github.com/herdrdev/herdr/blob/v0.9.2/CHANGELOG.md
6
+ - Native runtime CLI help (Codex and Claude) and mission-engine review-receipt/specialist-lifecycle contracts in this repository.
7
+ Adaptations/rejections: docs/plans/skill-audits/void-orchestrate.md.
8
+
9
+ Adaptive delegation, researched 2026-10-13 (distilled, no upstream code copied):
10
+ - OpenAI native subagents: https://learn.chatgpt.com/docs/agent-configuration/subagents
11
+ - Anthropic research teams: https://www.anthropic.com/engineering/multi-agent-research-system
12
+ - OpenClaw context and collection: https://docs.openclaw.ai/tools/subagents/tool-reference
13
+ - OpenClaw lifecycle: https://docs.openclaw.ai/tools/subagents/slash-command
14
+ - OpenClaw responsibilities: https://docs.openclaw.ai/concepts/parallel-specialist-lanes
15
+ - Hermes delegation: https://hermes-agent.nousresearch.com/docs/user-guide/features/delegation
16
+ - Hermes task selection: https://hermes-agent.nousresearch.com/docs/guides/delegation-patterns