@sjawhar/pi-legion-envoy 7.9.0 → 7.9.2

package/README.md

@@ -73,10 +73,11 @@ package ships skills at `dist/skills` (not the plugin root itself), so the field
 for every session — including a headless Legion controller — to see the Legion skills at all.
 The tarball also ships `agents/`, the task agents Legion's prompts dispatch (`oracle`; the
 reviewer's pair `thermonuclear-deep-review` and `thermonuclear-code-quality`; `deep-worker`,
-which writes the implementer's code; and the planner's checks, `plan-gap-analyst` before it drafts
-and `plan-reviewer` after), which Oh My Pi discovers under any extension package root:
-an installed plugin in a pane, the explicit `--extension` root in a Sandbox pod. Each declares its
-model as a role the operator maps (`docs/kubernetes.md`, "Model roles"). The skills those agents and the
+which writes the implementer's code; and the planner's checks, `plan-gap-analyst` before it drafts,
+which also reads a spec before a human does, and `plan-reviewer` after), which Oh My Pi discovers
+under any extension package root: an installed plugin in a pane, the explicit `--extension` root in
+a Sandbox pod. Each declares its model as a role the operator maps (`docs/kubernetes.md`,
+"Model roles"). The skills those agents and the
 role prompts load (the pair's rubrics, the implementer's `ce-simplify-code`) ship in
 `dist/skills` with the rest. The Go daemon's boot gate and `legion probe-image` resolve every
 `task(agent="…")` and every `skill://<name>` those prompts name through the same launch, and

package/agents/plan-gap-analyst.md

@@ -1,9 +1,9 @@
 ---
 name: plan-gap-analyst
 description: |
-  Pre-planning gap analyst. Read-only. Use before drafting a plan: finds the hidden requirements,
-  ambiguities, and missing machine-checkable acceptance criteria an issue leaves unsaid, each with
-  what the plan must answer.
+  Pre-planning and spec gap analyst. Read-only. Use before drafting a plan, or before a spec reaches
+  a human: finds the hidden requirements, ambiguities, missing machine-checkable acceptance criteria,
+  and unsupported claims an issue or spec carries, each with what its author must answer.
 # @oracle is the deployment's `oracle` model role; the Go daemon's boot gate refuses to start unless the operator's settings give
 # this agent a model, through modelRoles.oracle or a task.agentModelOverrides entry for it (docs/kubernetes.md, Operator configuration).
 model: ["@oracle"]
@@ -14,8 +14,9 @@ blocking: true
 color: yellow
 ---
 
-You read an issue before its plan exists and find what the issue leaves unsaid that would derail
-the plan. You advise the planner; the planner owns the plan.
+You read an issue before its plan exists, or a spec before a human reads it, and find what it leaves
+unsaid or asserts without support that would derail the work. You advise its author; the author
+owns the document.
 
 ## What you look for
 
@@ -26,21 +27,27 @@ the plan. You advise the planner; the planner owns the plan.
    and what each would cost.
 3. **Acceptance a machine cannot check.** A criterion with no command, test, or request whose
    expected output decides it, or a requirement with no criterion at all.
+4. **Claims and requirements with no source.** A statement about how a system works today that the
+   code, its documentation or command output you were given does not show; and, when the caller
+   gave you the owner's words to check the document against, a requirement that traces to neither
+   them nor a cited fact. A requirement in a version a human approved has its source. Say what you
+   checked. You cannot run commands, so a claim about live state you cannot read is reported as
+   unverified, not as false.
 
 Read the code and the repository's own documentation before you call something a gap. A gap the
 issue, the code, or the documentation already answers is not a finding.
 
 ## What a finding contains
 
-- **The gap**, quoting the issue's words where it has them.
-- **The evidence**: the file and line, or the issue text, that shows it.
-- **What the plan must answer**: the question or decision the plan has to settle and, for an
-  acceptance gap, a check a machine could run. Say whether the code settles it or only the
+- **The gap**, quoting the document's words where it has them.
+- **The evidence**: the file and line, or the document's text, that shows it.
+- **What the author must answer**: the question or decision the plan or spec has to settle and, for
+  an acceptance gap, a check a machine could run. Say whether the code settles it or only the
   issue's owner can (a product choice).
 
-Report the findings that change the plan, the most work-changing first. Style, edge cases the plan
-can settle in passing, and the design you would have chosen are not findings. When nothing changes
-the plan, say so in one line.
+Report the findings that change the work, the most work-changing first, and every finding of the
+fourth kind. Style, edge cases the plan can settle in passing, and the design you would have chosen
+are not findings. When nothing changes the work, say so in one line.
 
 ## Constraints
 
@@ -49,4 +56,4 @@ the plan, say so in one line.
   tools: read with them if you need to, but write nothing through them — no issue, comment, ask,
   message, suggestion or document edit, and nothing sent or published.
 - Cite what you read. Anything you did not read is an assumption and is written as one.
-- Do not write the plan.
+- Do not write the plan or edit the document.

package/dist/envoy.js

@@ -33150,6 +33150,7 @@ function followsAsk(owner) {
   return `You follow this ask: its answer and replies reach you directly. For every event on ${owner.label}: envoy_subscribe ${owner.topic}`;
 }
 var triageAdviceShown = new Set;
+var SPEC_CHECK_REMINDER = 'Has a fresh reader checked this spec? Each claim about how a system works today should trace to code read or a command run, and each requirement to the human\'s words or a cited fact. If not, have a fresh read-only subagent (`plan-gap-analyst` on Oh My Pi) check it now and fix what it finds. See the `dispatch-first` skill, "Design in the spec".';
 function renderAdvice(tool, key, advice, opts) {
   if (advice === undefined)
     return [];
@@ -34403,6 +34404,7 @@ async function executeDispatchTool(input) {
         return {
           text: [
             `Created ${created.key}: ${created.title} ${notSubscribed(issueTopic(created.key))}`,
+            ...spec === undefined ? [] : [SPEC_CHECK_REMINDER],
             ...adviceLines
           ].join(`
 `),
@@ -34967,7 +34969,8 @@ ${trailer.join(`
       const details = await followedAskDetails(client, result.ask, resolved.artifact);
       const outcome = result.recorded ? `Approval requested for ${resolved.artifact.name} (document id ${resolved.artifact.id}) at version ${result.version} (ask ${result.ask.id}).` : `The approval request for ${resolved.artifact.name} (document id ${resolved.artifact.id}) at version ${result.version} (ask ${result.ask.id}) already waits on the human, so this call changed nothing: nothing since it last reached the human (a newer version, a human's reply in its thread, or your progress note) left it waiting on you.`;
       return {
-        text: `${outcome} The human's Inbox asks: ${JSON.stringify(result.ask.question)}. The answer arrives as artifact.approved or artifact.changes_requested. An edit before the answer moves this request to the new version and leaves it waiting on you, and an edit after approval makes the approval stale: either way, request again for the new version once the human has agreed to every point in it, which hands this request back or opens a new one.`,
+        text: `${outcome} The human's Inbox asks: ${JSON.stringify(result.ask.question)}. The answer arrives as artifact.approved or artifact.changes_requested. An edit before the answer moves this request to the new version and leaves it waiting on you, and an edit after approval makes the approval stale: either way, request again for the new version once the human has agreed to every point in it, which hands this request back or opens a new one.${result.recorded ? `
+${SPEC_CHECK_REMINDER}` : ""}`,
         details: { ...details, artifact: resolved.artifact.id, version: result.version }
       };
     }

package/dist/legion.js

@@ -15905,6 +15905,7 @@ function followsAsk(owner) {
   return `You follow this ask: its answer and replies reach you directly. For every event on ${owner.label}: envoy_subscribe ${owner.topic}`;
 }
 var triageAdviceShown = new Set;
+var SPEC_CHECK_REMINDER = 'Has a fresh reader checked this spec? Each claim about how a system works today should trace to code read or a command run, and each requirement to the human\'s words or a cited fact. If not, have a fresh read-only subagent (`plan-gap-analyst` on Oh My Pi) check it now and fix what it finds. See the `dispatch-first` skill, "Design in the spec".';
 function renderAdvice(tool, key, advice, opts) {
   if (advice === undefined)
     return [];
@@ -17158,6 +17159,7 @@ async function executeDispatchTool(input) {
         return {
           text: [
             `Created ${created.key}: ${created.title} ${notSubscribed(issueTopic(created.key))}`,
+            ...spec === undefined ? [] : [SPEC_CHECK_REMINDER],
             ...adviceLines
           ].join(`
 `),
@@ -17722,7 +17724,8 @@ ${trailer.join(`
       const details = await followedAskDetails(client, result.ask, resolved.artifact);
       const outcome = result.recorded ? `Approval requested for ${resolved.artifact.name} (document id ${resolved.artifact.id}) at version ${result.version} (ask ${result.ask.id}).` : `The approval request for ${resolved.artifact.name} (document id ${resolved.artifact.id}) at version ${result.version} (ask ${result.ask.id}) already waits on the human, so this call changed nothing: nothing since it last reached the human (a newer version, a human's reply in its thread, or your progress note) left it waiting on you.`;
       return {
-        text: `${outcome} The human's Inbox asks: ${JSON.stringify(result.ask.question)}. The answer arrives as artifact.approved or artifact.changes_requested. An edit before the answer moves this request to the new version and leaves it waiting on you, and an edit after approval makes the approval stale: either way, request again for the new version once the human has agreed to every point in it, which hands this request back or opens a new one.`,
+        text: `${outcome} The human's Inbox asks: ${JSON.stringify(result.ask.question)}. The answer arrives as artifact.approved or artifact.changes_requested. An edit before the answer moves this request to the new version and leaves it waiting on you, and an edit after approval makes the approval stale: either way, request again for the new version once the human has agreed to every point in it, which hands this request back or opens a new one.${result.recorded ? `
+${SPEC_CHECK_REMINDER}` : ""}`,
         details: { ...details, artifact: resolved.artifact.id, version: result.version }
       };
     }
@@ -18028,7 +18031,7 @@ function endInjectedUserTurns(sessionID) {
 // package.json
 var package_default = {
   name: "@sjawhar/pi-legion-envoy",
-  version: "7.9.0",
+  version: "7.9.2",
   license: "Apache-2.0",
   type: "module",
   omp: {

package/dist/skills/AGENTS.md

@@ -9,7 +9,7 @@ event intake, process lifecycle, credentials, and role delivery.
 | `ce-simplify-code/` | the implementer, once per pull request | the behaviour-preserving simplify pass, in the implementer's first implementing round (Legion's copy of the MIT-licensed Compound Engineering skill; `LICENSE` beside it) |
 | `dispatch/` | every role, and any session writing to Dispatch | specs, asks, comments, artifacts, and messages on native Dispatch |
 | `dispatch-brainstorming/` | any session with Dispatch that starts a design conversation or writes a plan, as `dispatch-first` directs | the design conversation in the issue's spec, turn by turn to one approval, and the plan as the issue's `plan.md`; in a session with Dispatch it replaces superpowers' `brainstorming` and `writing-plans` |
-| `dispatch-first/` | every session with Dispatch configured, injected by each host plugin on every request (Oh My Pi), on every `SessionStart` (startup, resume, clear, compact, fork) and `SubagentStart` (Claude Code), or as an instruction file (OpenCode) | searching Dispatch before acting, extending the existing issue, citing decisions, closing duplicates; kept under 60 lines and 6,000 characters |
+| `dispatch-first/` | every session with Dispatch configured, injected by each host plugin on every request (Oh My Pi), on every `SessionStart` (startup, resume, clear, compact, fork) and `SubagentStart` (Claude Code), or as an instruction file (OpenCode) | searching Dispatch before acting, extending the existing issue, citing decisions, closing duplicates, the fresh-reader check before a spec reaches a human; kept under 60 lines and 6,000 characters |
 | `envoy/` | every role | subscriptions, agent-to-agent messages, and topic formats |
 | `legion-architect/` | root and sub-architects | tree ownership, decomposition, waves, gates, integration, sign-off |
 | `legion-controller/` | the controller root process | wake routing, keeping the admission slots full from `todo`, the daily report, escalation |

package/dist/skills/dispatch-first/SKILL.md

@@ -50,7 +50,7 @@ found yourself.
 A design conversation with a person, or the implementation plan that follows one, uses
 `skill://dispatch-brainstorming`: read it before your first design question on a change, the spec,
 or that plan. It replaces superpowers' `brainstorming` and `writing-plans` here, even when the user
-invokes one by name. A Legion architect's own issue spec follows `skill://legion-architect`.
+invokes one by name. A Legion architect's own issue spec follows `skill://legion-architect`. Before a spec's first version and each approval request, have a fresh read-only subagent (on Oh My Pi, `task(agent="plan-gap-analyst")`) check it against the code, the human's words and any command output a claim rests on, and resolve what it flags.
 
 ## Load the full skill before you write
 

package/dist/skills/legion-worker/SKILL.md

@@ -386,7 +386,11 @@ It pushes `@-` through the provisioned credential helper, which authenticates as
 which pushes skip CI and which commit-message keywords it refuses. While the head commit carries
 `skip-checks: true`, a pull-request body edit alone starts no GitHub workflow run, so a check that
 re-judges the body re-runs on that head only after a later push; on a code head the same edit
-re-runs it at once. Its ancestry check refuses
+re-runs it at once. While the pull request conflicts with its base (GitHub shows it
+`CONFLICTING`), no workflow triggered `on: pull_request` runs for any of its activity types, so
+a body edit re-judges nothing there either; a push cures both, but only once the pull request is
+mergeable, so the implementer forward-merges a conflicting one first (*Reintegrating the base* in
+`skill://legion-worker/references/conflicts-and-rewrites.md`). Its ancestry check refuses
 unless `@-` descends from `legion/<KEY>@origin` (or the branch is not on GitHub yet): every issue
 workspace shares one clone, so another role's push moves `legion/<KEY>@origin` here at once, and
 a push that did not descend from it would move the remote branch sideways onto your commit and

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sjawhar/pi-legion-envoy",
-  "version": "7.9.0",
+  "version": "7.9.2",
   "license": "Apache-2.0",
   "type": "module",
   "omp": {