@sjawhar/opencode-legion-envoy 6.1.0 → 6.3.0

package/dist/src/server.js

@@ -13605,6 +13605,12 @@ var askEventPayloadFields = {
   question: exports_external.string().optional(),
   options: exports_external.array(exports_external.object({ label: exports_external.string().optional() })).optional(),
   answer: exports_external.object({ selected: exports_external.array(exports_external.string()).nullish(), text: exports_external.string().nullish() }).nullish(),
+  previous_answer: exports_external.object({
+    user: exports_external.string().optional(),
+    selected: exports_external.array(exports_external.string()).nullish(),
+    text: exports_external.string().nullish(),
+    at: exports_external.string().optional()
+  }).nullish(),
   anchor: exports_external.object({
     quote: exports_external.string().optional(),
     mark_id: exports_external.string().optional(),
@@ -16595,8 +16601,10 @@ function eventHead(event) {
     case "ask.handed_back":
     case "ask.resolved":
       return textHead(event.payload.question);
-    case "ask.answered":
-      return `${textHead(event.payload.question)} -> ${textHead(askAnswerText(event.payload.answer))}`;
+    case "ask.answered": {
+      const previousAnswer = event.payload.previous_answer;
+      return `${textHead(event.payload.question)} -> ${textHead(askAnswerText(event.payload.answer))}${previousAnswer === undefined ? "" : ` (was: ${textHead(askAnswerText(previousAnswer))})`}`;
+    }
     case "comment.created":
     case "comment.answered":
     case "comment.anchor_refreshed":
@@ -16637,8 +16645,9 @@ function childrenSummary(issue2) {
   ].join(`
 `);
 }
-function askSummary({ ask, replies }, graph) {
+function askSummary({ ask, replies, answers }, graph) {
   const answer = ask.answer;
+  const earlierAnswers = answers.slice(0, -1);
   const chain = replies.flatMap((reply) => [
     `${reply.id} \xB7 ${actorText(reply.author)}`,
     `Body: ${reply.body}`
@@ -16655,6 +16664,10 @@ function askSummary({ ask, replies }, graph) {
       `- Selected: ${answer.selected.length === 0 ? "none" : answer.selected.join(", ")}`,
       ...answer.text === null ? [] : [`- Text: ${answer.text}`]
     ],
+    ...earlierAnswers.length === 0 ? [] : [
+      "Earlier answers:",
+      ...earlierAnswers.map((earlier) => `- ${earlier.at} \xB7 ${earlier.user} \xB7 ${askAnswerText(earlier)}`)
+    ],
     ...ask.resolution === undefined ? [] : [
       "Resolution:",
       `- By: ${ask.resolution.actor.id}`,

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sjawhar/opencode-legion-envoy",
-  "version": "6.1.0",
+  "version": "6.3.0",
   "license": "Apache-2.0",
   "type": "module",
   "main": "dist/src/server.js",

package/skills/dispatch/SKILL.md

@@ -338,7 +338,7 @@ permission you already hold, an API that replaces the click. One ask per item, `
 when work is stopped on it; while it is open, keep working on everything that is not.
 
 Once an ask is open (who answers it, handing a human a to-do, editing, retracting or resolving it,
-answering a clarification, whose turn a reply gives), see
+answering a clarification, whose turn a reply gives, an answer the human changes), see
 [Asks after they open](skill://dispatch/references/asks.md).
 
 ## Architecture components

package/skills/dispatch/references/asks.md

@@ -45,6 +45,9 @@ dispatch_edit_ask({
 At least one field besides `ask` is required. Use this only while the same decision remains open: it keeps the prior text in the event
 log and invalidates any answer draft against the prior `edited_at` revision, so the human sees the new wording and explicitly reconfirms.
 An answered or resolved ask cannot be edited. If the decision is moot or superseded, retract the old ask and open a new one.
+A human can change an answer they gave. The change arrives as another `ask.answered` frame whose
+`previous_answer` names the answer it replaced, through the same route the first answer took, and
+`dispatch_read` of the ask lists every earlier answer. Act on the newest answer.
 
 An ask that lives as an `ask` block in a document keeps its question and options in the block, and `dispatch_edit_ask` writes the
 block along with the row, so the edit stands and the document reads the same. It changes only the fields you name: pass `urgency`

package/skills/dispatch/references/document-edits.md

@@ -197,6 +197,6 @@ an existing paragraph is the question that should become a decision.
 
 An ask block has two ids: the block id, shown as `:::ask{#<id> …}` in the rendered document and
 taken bare by `move`/`delete` in `block` (the `block:<id>` form is only for `before`/`after`
-anchors), and the ask id, which `dispatch_open_asks`, the dashboard's `?ask=` link, `dispatch_read`
-and `dispatch_comment({ reply_to_ask })` use. They differ; `dispatch://KEY/ask/<block-id>` answers
-`not found`.
+anchors), and the ask id, which `dispatch_open_asks`, the dashboard's ask links (`/asks/<id>`,
+`?ask=`), `dispatch_read` and `dispatch_comment({ reply_to_ask })` use. They differ;
+`dispatch://KEY/ask/<block-id>` answers `not found`.

package/skills/legion-architect/SKILL.md

@@ -230,9 +230,10 @@ review and the merge-gate sequence by the daemon's table.
 
 Retro is mandatory for every issue that passed review, before merge, and the daemon runs it: when
 the reviewer's approval ends the review round, it moves the issue to `retro` and starts the
-implementer on it, resuming the same agent from its session (a worker is suspended when its phase
-ends, never after an idle window). You start nothing for it. Never `envoy_publish` to a finished
-worker's role topic to start retro: a suspended role is not running to receive it.
+implementer on it, in the same agent's session, which stayed live after its phase ended (every
+started role stays live until its issue closes). You start nothing for it. Never `envoy_publish` to
+the implementer's role topic to start retro: the daemon's start is what records which role owns
+the task.
 
 Wait for the implementer to report its durable retro result. Retro output is
 `docs/solutions/`, the PR body content the repository's instructions derive from the pull

package/skills/legion-worker/SKILL.md

@@ -68,10 +68,10 @@ into a spec yourself: the architect decides whether the human must answer it and
 since a new version of an approved root spec closes the tree's design gate. A standalone to-do
 only a human can do is a `dispatch_ask`, and its replies return to your own session.
 
-Because the same agent is always resumed for its phase, you may receive more than one
-assignment across your lifetime: once the daemon ends your phase it suspends you, and when a later
-event (a review round, a red check) starts your role again it resumes this same session with a new
-prompt. Treat it as a continuation — re-read the current issue and your own prior handoff, since
+Because the same agent works its role until the issue closes, you may receive more than one
+assignment across your lifetime: your session stays live after your phase ends, and when a later
+event (a review round, a red check) starts your role again the new prompt arrives in this same
+session. Treat it as a continuation — re-read the current issue and your own prior handoff, since
 time has passed — never as a fresh identity.
 
 ## Deployment instructions
@@ -93,9 +93,9 @@ implementer's production check after the merge
 Reach any live role on this issue the same way you reach the architect: `envoy_publish` to
 `notifications.role.` followed by that role's encoded token. Use it when you need context an
 earlier phase has that its handoff doesn't cover — ask the planner why a constraint was
-scoped that way, ask the implementer what a commit actually did. The daemon suspends a role when
-its phase ends, so a role that finished is not running to answer you: read its committed handoff
-instead.
+scoped that way, ask the implementer what a commit actually did. A role that finished its phase
+stays live and answers until its issue leaves the workflow. If a publish is rejected with 404,
+read that role's committed handoff.
 
 ## Workspace and handoff precedence
 
@@ -111,10 +111,14 @@ Never rely on the inherited cwd. Every later repository shell command **MUST** b
 native filesystem tool paths **MUST** be absolute under that workspace. Do not create an
 isolated worktree, change the workspace topology, or mix another issue's work into it.
 Concurrent issues have disjoint workspaces; only the currently active phase mutates this
-one. After you complete, treat `$LEGION_WORKSPACE` as read-only: a finished role is not running to
-answer questions or to keep editing. Do not create new commits, run
-`jj -R "$LEGION_WORKSPACE" new`, or touch tracked files once your own handoff is committed
-(and, for the implementer, pushed) — a code change belongs to whichever phase is active now.
+one. After you complete and go idle, treat `$LEGION_WORKSPACE` as read-only in every later
+turn, including one an Envoy question starts: you are kept alive to answer questions, not to keep
+editing. Do not create new commits, run `jj -R "$LEGION_WORKSPACE" new`, or touch tracked files
+once your own handoff is committed (and, for the implementer, pushed) — a code change belongs to
+whichever phase is active now. The same holds once the Go daemon has taken your phase back without
+your completion: CI settling red while you tested, or reviewed a round you had not completed,
+moves the issue to `implementing` and interrupts your turn, and the implementer starts only once
+that turn has ended. Do not resume the interrupted work afterward.
 
 On every start, and especially after revival or re-creation, read the issue and then the
 committed predecessor handoffs in lifecycle order from
@@ -463,13 +467,18 @@ do:
 Quote the answer verbatim in what you tell the architect: with the run and phase it names, the
 difference between "my work is lost" and "my work belongs to the previous run" is visible.
 
-**Stay in this session afterward.** Your process does not exit on its own when your phase
-completes: the daemon suspends it when it ends your phase, at the end of your turn, so a finished
-role is not running to answer questions. When the daemon starts your role again it resumes this
-same session from its session file, with a new prompt, so it is still you: you are the one resumed
-if this phase's work needs to run again. Re-read `$LEGION_WORKSPACE` and your own committed handoff
-then, without mutating anything until the new prompt asks for it (see Workspace and handoff
-precedence above).
+**Stay in this session afterward.** Your process does not exit when your phase completes; it
+stays live until your issue leaves the workflow. No move between phases stops it, and only an
+explicit stop does: the issue closing; a move to `backlog`, `icebox` or `triage` (a child by a
+person or its architect's `park_child`, or the root, which stops the whole tree); a child set back
+to `todo` (which stops the interrupted phase's worker, not earlier roles); or an operator stop.
+A stop keeps your session, and a crash relaunches it. Your next assignment arrives in this same
+session. Other roles on
+this issue may reach you through Envoy with
+questions about the work you did — answer them, reading `$LEGION_WORKSPACE` and your own
+committed handoff as needed, without mutating anything (see Workspace and handoff
+precedence above). You will also be the one resumed, with a new prompt in this same
+session, if this phase's work needs to run again.
 
 When blocked on a product, scope, design, lifecycle, or cross-phase decision, `envoy_publish` the
 owning architect a concise message: issue, phase, verified observation, what you tried, and the