@sjawhar/pi-legion 8.5.0 → 8.5.1
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/legion.js +1 -1
- package/dist/skills/legion-worker/SKILL.md +17 -12
- package/package.json +1 -1
package/dist/legion.js
CHANGED
|
@@ -15309,7 +15309,7 @@ function onEnvoyRoleRegained(listener) {
|
|
|
15309
15309
|
// package.json
|
|
15310
15310
|
var package_default = {
|
|
15311
15311
|
name: "@sjawhar/pi-legion",
|
|
15312
|
-
version: "8.5.
|
|
15312
|
+
version: "8.5.1",
|
|
15313
15313
|
license: "Apache-2.0",
|
|
15314
15314
|
type: "module",
|
|
15315
15315
|
omp: {
|
|
@@ -59,7 +59,11 @@ only on this phase's artifact.
|
|
|
59
59
|
|
|
60
60
|
You never start another Legion role: the daemon starts every phase worker itself, from its fixed
|
|
61
61
|
workflow table. You may still use ordinary `task` subagents for your own phase work; none of them
|
|
62
|
-
is a Legion role.
|
|
62
|
+
is a Legion role. A subagent runs in your pane as you, with every host tool but the `legion` tool
|
|
63
|
+
(it is never offered one), so a `legion` command from its bash, a completion included, is yours at
|
|
64
|
+
the daemon: give a subagent no completion step. Today such a command runs on the per-call grant
|
|
65
|
+
your own last credentialed call wrote, within its 60 seconds (*Four facts about `gh`*, below);
|
|
66
|
+
LEGION-631 (dispatch://LEGION-631) replaces that grant with the role's mounted token file.
|
|
63
67
|
Escalate a product, scope, design, cross-phase, or lifecycle decision to the owning architect with
|
|
64
68
|
`envoy_publish` to its role topic (`notifications.role.` followed by its encoded token, see
|
|
65
69
|
above), carrying the verified facts and the decision needed. A `write` to `agent://` only reaches
|
|
@@ -422,17 +426,18 @@ check write no `.legion/<issue>/<phase>.json`, commit no handoff, and report wit
|
|
|
422
426
|
|
|
423
427
|
## Completion: report to the architect, then stay
|
|
424
428
|
|
|
425
|
-
Report completion to the architect
|
|
426
|
-
`summary
|
|
427
|
-
|
|
428
|
-
|
|
429
|
-
|
|
430
|
-
|
|
431
|
-
|
|
432
|
-
|
|
433
|
-
|
|
434
|
-
|
|
435
|
-
invent a different completion protocol — this is the
|
|
429
|
+
Report completion to the architect with the `legion` tool's `handoff_complete` and a two-sentence
|
|
430
|
+
`summary`. This publishes your phase's completion to the architect's role and clears the daemon's
|
|
431
|
+
record of this issue's active phase. A shell `legion handoff complete`, should one run, completes
|
|
432
|
+
the phase at the daemon just as well and is not refused, but only the tool call tells the
|
|
433
|
+
extension's phase stall: after a shell completion the reminder arrives when the turn settles and
|
|
434
|
+
again after each later Envoy delivery's turn, until a tool `handoff_complete` next succeeds (in
|
|
435
|
+
practice the next phase's). A completion made on that reminder is refused and closes nothing —
|
|
436
|
+
`HANDOFF_NOT_CURRENT_PHASE` once the phase has moved, `HANDOFF_ALREADY_RECORDED` where a
|
|
437
|
+
completion moves nothing (the implementer before its pull request exists; the production check) —
|
|
438
|
+
so answer the reminder with a WAITING line saying the phase was completed from the shell. Do not
|
|
439
|
+
add pipeline labels, run a controller loop, or invent a different completion protocol — this is the
|
|
440
|
+
whole contract.
|
|
436
441
|
|
|
437
442
|
A reviewer's phase ends with its completion, not with its review; the order of a review round
|
|
438
443
|
(the handoff push; for an approval, CI settled green at that head; the review of that head; then
|