@sjawhar/opencode-legion-envoy 0.43.0 → 1.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.
package/dist/src/server.js
CHANGED
|
@@ -13628,6 +13628,11 @@ var ChildStatusEventPayloadSchema = object({
|
|
|
13628
13628
|
from: string2().optional(),
|
|
13629
13629
|
to: string2().optional()
|
|
13630
13630
|
});
|
|
13631
|
+
var SubscriptionRemovedEventPayloadSchema = object({
|
|
13632
|
+
session_id: string2().optional(),
|
|
13633
|
+
by: object({ kind: string2(), id: string2().optional() }).passthrough().optional(),
|
|
13634
|
+
topics: array(string2()).optional()
|
|
13635
|
+
});
|
|
13631
13636
|
// ../contracts/src/dispatch-snippet.ts
|
|
13632
13637
|
var HTML_ENTITIES = [
|
|
13633
13638
|
["<", "<"],
|
|
@@ -14125,8 +14130,7 @@ var LegionDaemonApi = {
|
|
|
14125
14130
|
roleTokens: record(string2(), string2()),
|
|
14126
14131
|
controlSubject: nonEmptyString,
|
|
14127
14132
|
gates: object({
|
|
14128
|
-
design: _enum2(["root-issues", "off"])
|
|
14129
|
-
merge: _enum2(["human", "off"])
|
|
14133
|
+
design: _enum2(["root-issues", "off"])
|
|
14130
14134
|
}).optional(),
|
|
14131
14135
|
secret: nonEmptyString
|
|
14132
14136
|
})
|
|
@@ -14135,14 +14139,6 @@ var LegionDaemonApi = {
|
|
|
14135
14139
|
request: architectCapability.extend({ generation: number2().int() }),
|
|
14136
14140
|
response: object({})
|
|
14137
14141
|
},
|
|
14138
|
-
MergeGate: {
|
|
14139
|
-
request: architectCapability.extend({ pr: number2().int().positive() }),
|
|
14140
|
-
response: object({
|
|
14141
|
-
approved: boolean2(),
|
|
14142
|
-
pr: number2().int().positive(),
|
|
14143
|
-
headSha: nonEmptyString
|
|
14144
|
-
})
|
|
14145
|
-
},
|
|
14146
14142
|
ProcessExit: {
|
|
14147
14143
|
request: architectCapability.extend({ generation: number2().int() }),
|
|
14148
14144
|
response: object({})
|
package/package.json
CHANGED
package/skills/AGENTS.md
CHANGED
|
@@ -34,6 +34,8 @@ directly for a durable human question; replies come back to the worker's own ses
|
|
|
34
34
|
## Durable artifacts
|
|
35
35
|
|
|
36
36
|
Phase handoffs are committed in lifecycle order: architect, plan, implement, test, and review.
|
|
37
|
-
|
|
37
|
+
A clean review ends with the `.legion/` deletion pushed by the implementer at the reviewer's
|
|
38
|
+
direction (the review App holds no `contents` permission and cannot push), which the reviewer
|
|
39
|
+
then approves; retro records its learning in
|
|
38
40
|
`docs/solutions/` and writes no handoff. GitHub comments and reviews carry the required Legion
|
|
39
41
|
footer so the daemon can attribute artifacts to their worker session.
|
package/skills/dispatch/SKILL.md
CHANGED
|
@@ -226,9 +226,11 @@ It returns `details` `{ issue, topic, message }`. `body` is capped at 2,000 char
|
|
|
226
226
|
|
|
227
227
|
## What comes back
|
|
228
228
|
|
|
229
|
-
A write result's `details.topic` subscribes the host to its owner
|
|
229
|
+
A write result's `details.topic` subscribes the host to its owner, and the first such subscription on an issue or document also tells
|
|
230
|
+
you so (an already-subscribed write stays quiet — no repeat notice). Issue writes use `notifications.dispatch.issue.<KEY>.>`;
|
|
230
231
|
project-document writes use `notifications.dispatch.document.<PROJECT>.<SLUG>.>`. The owner topic carries every Dispatch event; `notify`
|
|
231
|
-
only controls agent wake and routed delivery.
|
|
232
|
+
only controls agent wake and routed delivery. A human may unsubscribe you from the issue or document header; you are told with a
|
|
233
|
+
`subscription.removed` notice when that happens. After a restart, catch up with:
|
|
232
234
|
|
|
233
235
|
```ts
|
|
234
236
|
dispatch_read({ issue?, project?, artifact?, ref? })
|
|
@@ -164,28 +164,30 @@ Wait for the messaged implementer to report its durable retro result. Retro outp
|
|
|
164
164
|
`docs/solutions/` plus an issue comment; it must not create a `.legion` file or change
|
|
165
165
|
the reviewer-approved head after cleanup.
|
|
166
166
|
|
|
167
|
-
## 6. Architect sign-off and
|
|
167
|
+
## 6. Architect sign-off and merge
|
|
168
168
|
|
|
169
169
|
Sign off only when scope is fully met, integration evidence is current, corrective work
|
|
170
170
|
is complete, review is clean, retro completed, and no necessary work was silently
|
|
171
171
|
deferred. Make the sign-off comment explicit about that evidence.
|
|
172
172
|
|
|
173
|
-
|
|
173
|
+
Preserve this order exactly:
|
|
174
174
|
|
|
175
175
|
1. tester green and review cycles complete;
|
|
176
|
-
2.
|
|
177
|
-
|
|
178
|
-
|
|
179
|
-
|
|
180
|
-
|
|
181
|
-
|
|
182
|
-
|
|
183
|
-
|
|
184
|
-
|
|
185
|
-
|
|
186
|
-
|
|
187
|
-
|
|
188
|
-
|
|
176
|
+
2. on a clean review, `spawn_worker` the implementer once more to push only the `.legion/`
|
|
177
|
+
deletion (the review App holds no `contents` permission), then the reviewer approves that
|
|
178
|
+
head. The deletion must land before that approval, which is head-pinned. An implementer
|
|
179
|
+
completion always writes the issue's status as `testing`; this one is not a test round,
|
|
180
|
+
so on its `phase-complete` wake call `legion({ op: "set_status", issue, status: "retro" })`
|
|
181
|
+
before messaging the reviewer to approve;
|
|
182
|
+
3. retro completes without dirtying the branch beyond `docs/solutions/`;
|
|
183
|
+
4. the merger verifies the current head is the reviewer-approved head plus only the retro
|
|
184
|
+
commits and publishes `READY #<n> at <sha>` to `notifications.role.pr-queue`; it never
|
|
185
|
+
merges. The merge queue merges under its own authority and the repository's own rules
|
|
186
|
+
(branch protection, CODEOWNERS); whether a human must approve first is that repository's
|
|
187
|
+
setting, not Legion's, and you never ask for or wait on such an approval.
|
|
188
|
+
|
|
189
|
+
If anything else changes the head, return to review; do not let the merger publish `READY`
|
|
190
|
+
for an obsolete approval.
|
|
189
191
|
|
|
190
192
|
## 7. Close
|
|
191
193
|
|
|
@@ -193,7 +195,7 @@ After the merge result and sign-off are recorded, post the sign-off and close th
|
|
|
193
195
|
through the Legion write surface:
|
|
194
196
|
|
|
195
197
|
```text
|
|
196
|
-
dispatch_comment({ issue: "LEGION-40", body: "<sign-off: scope, integration evidence, review, retro,
|
|
198
|
+
dispatch_comment({ issue: "LEGION-40", body: "<sign-off: scope, integration evidence, review, retro, and merge>" })
|
|
197
199
|
legion({ op: "set_status", issue: "LEGION-40", status: "done" })
|
|
198
200
|
```
|
|
199
201
|
|
|
@@ -210,10 +212,11 @@ corresponding lifecycle procedure.
|
|
|
210
212
|
| `child-closed` | Read the child completion and remaining open children. Re-scope or close obsolete open work; release an appropriate next wave, or await `children-complete`. |
|
|
211
213
|
| `children-complete` | Execute steps 3–4: parent integration verification; failures become a new child wave, success advances to review and retro. |
|
|
212
214
|
| `child-reopened` | Treat the completion edge as reset. Reassess the reopened child and return the tree to children-in-flight; do not continue an already-started end-game. |
|
|
213
|
-
| `phase-complete` | Payload `{type:"phase-complete", issue, role, summary}`. May arrive live or via `catchup-overseer`'s `phaseCompletions`. Read the committed handoff for that phase, then spawn the next phase's owner, or `spawn_worker` on the same role again to resume it with corrections if the handoff shows unresolved gaps. |
|
|
215
|
+
| `phase-complete` | Payload `{type:"phase-complete", issue, role, summary}`. May arrive live or via `catchup-overseer`'s `phaseCompletions`. Read the committed handoff for that phase, then spawn the next phase's owner, or `spawn_worker` on the same role again to resume it with corrections if the handoff shows unresolved gaps. A `reviewer` completion whose GitHub review is `CHANGES_REQUESTED` (the daemon has already returned the issue's Dispatch status to `in_progress` for this) means `spawn_worker` the **implementer** again with the review findings — thread URLs and blocking items — as its task, then route back through tester and reviewer in order; never `spawn_worker` the reviewer directly off this wake and never proceed to retro on this verdict. A reviewer completion with an `APPROVED` review proceeds to retro (step 5). |
|
|
214
216
|
| `worker-queued` | Payload `{type:"worker-queued", issue, role}`. The deployment's worker cap is full; this role's spawn is queued. Do not respawn or retry — wait for `worker-started`. |
|
|
215
217
|
| `worker-started` | Payload `{type:"worker-started", issue, role}`. A previously queued role has been promoted and is now running. Treat it exactly as a normal spawn: resume tracking that role's live session. |
|
|
216
|
-
| `pr-ready` | Verify the live PR head, green status, and review state. Continue the review/retro/
|
|
218
|
+
| `pr-ready` | Verify the live PR head, green status, and review state. Continue the review/retro/merger order only for that current head. |
|
|
219
|
+
| `pr-review` | Payload `{type:"pr-review", state, author, body}`. Delivered to whichever role is currently active for the issue, falling back to you when no worker phase is active. Follows the same verdict rule as a reviewer's `phase-complete`: `state: "changes_requested"` sends the implementer back in with the review findings, then tester, then reviewer — never the reviewer again and never retro; `state: "approved"` proceeds toward retro (step 5) once the step 6 integration/merge-gate conditions are met. |
|
|
217
220
|
| `pr-blocked` | Read the failed CI evidence and recovery attempts. Assign a focused implementer or corrective child, then return it through testing and review; do not treat the blocked PR as final. |
|
|
218
221
|
| `pr-closed-unmerged` | Decide from current scope whether to reopen the work, send a fresh implementer, or cancel it with a reason. Delegate the repository action to the responsible phase worker and keep ownership. |
|
|
219
222
|
| `issue-comment` | Interpret the comment in the issue's design context. Answer it, adjust the plan, or relay it via `envoy_publish` to the responsible worker's role token; scope and product decisions remain with you. |
|
|
@@ -15,14 +15,15 @@ Follow this ordering exactly. It keeps the reviewed branch clean while preservin
|
|
|
15
15
|
retrospective's durable output.
|
|
16
16
|
|
|
17
17
|
1. Tester green and all code-review cycles finish.
|
|
18
|
-
2. The
|
|
18
|
+
2. The implementer pushes the `.legion/` deletion at the reviewer's direction, and the reviewer
|
|
19
|
+
approves that head.
|
|
19
20
|
3. Run this retro: commit durable learnings to `docs/solutions/` and post the issue comment.
|
|
20
21
|
Retro writes **no `.legion` file**, so it never re-dirties the cleaned handoff tree.
|
|
21
|
-
4.
|
|
22
|
-
|
|
22
|
+
4. The merger verifies the approved head, publishes `READY`, and pushes nothing; the merge queue
|
|
23
|
+
merges under the repository's own rules.
|
|
23
24
|
|
|
24
|
-
Do not start retro before step 2, skip it because the change seems mechanical, or
|
|
25
|
-
|
|
25
|
+
Do not start retro before step 2, skip it because the change seems mechanical, or publish `READY`
|
|
26
|
+
before step 3. The design gate is not a substitute for review and retro.
|
|
26
27
|
|
|
27
28
|
## Two perspectives
|
|
28
29
|
|
|
@@ -84,4 +85,4 @@ Before returning, verify all of the following:
|
|
|
84
85
|
- The learning documents and issue comment both exist.
|
|
85
86
|
- No `.legion` file was created or modified by retro.
|
|
86
87
|
- The fresh-eyes analysis was considered alongside the implementer's context.
|
|
87
|
-
-
|
|
88
|
+
- The merger remains a subsequent step, not work performed by retro.
|
|
@@ -219,8 +219,9 @@ Negative control: <deliberately broken input> → <refusal or failure observed>.
|
|
|
219
219
|
never from a handoff — then runs `task(agent="thermonuclear-deep-review")` and
|
|
220
220
|
`task(agent="thermonuclear-code-quality")` once at that head and records the verdict.
|
|
221
221
|
Skip the `Thermo` line entirely on a docs-only PR. Post every correctness finding as a
|
|
222
|
-
PR review comment and return the issue to the architect; when clean,
|
|
223
|
-
push
|
|
222
|
+
PR review comment and return the issue to the architect; when clean, have the architect send
|
|
223
|
+
the implementer back to push the `.legion/` deletion (the review App cannot push), then
|
|
224
|
+
review **that** head and approve it by name.
|
|
224
225
|
- Once a base is frozen for others to stack on, never rewrite it — fixes land as new
|
|
225
226
|
commits on top, and the `Chain` line records what is frozen.
|
|
226
227
|
- The merger confirms the approved head still equals the current head, then publishes
|
|
@@ -262,8 +263,8 @@ cd -- "$LEGION_WORKSPACE" && \
|
|
|
262
263
|
|
|
263
264
|
Do not report phase completion until the write, existence check, and handoff commit
|
|
264
265
|
succeed; when an issue branch exists, its push is also required. This is the committed
|
|
265
|
-
copy the next phase reads after revival.
|
|
266
|
-
|
|
266
|
+
copy the next phase reads after revival. It is removed once, at the end of a clean review: the
|
|
267
|
+
implementer pushes that deletion at the reviewer's direction. No other phase removes it.
|
|
267
268
|
|
|
268
269
|
## Completion: report to the architect, then stay
|
|
269
270
|
|