@sjawhar/pi-legion-envoy 5.25.0 → 5.27.0

package/agents/thermonuclear-code-quality.md

@@ -4,6 +4,7 @@ description: Diff-scoped maintainability audit for structure, abstraction, file
 # @review is the deployment's `review` model role; the Go daemon's boot gate refuses to start unless the operator's settings give
 # this agent a model, through modelRoles.review or a task.agentModelOverrides entry for it (docs/kubernetes.md, Operator configuration).
 model: ["@review"]
+autoloadSkills: [thermonuclear-code-quality]
 ---
 
 # Thermonuclear Code Quality
@@ -12,7 +13,7 @@ Review only the supplied diff and changed-file context. Return findings with fil
 
 ## Process
 
-1. Load `skill://thermonuclear-code-quality` and treat its rubric as complete.
+1. Apply the complete rubric of `skill://thermonuclear-code-quality`, already in your context; do not read it again.
 2. Look first for structural simplification and deletion of accidental complexity.
 3. Trace module boundaries, call sites, and type contracts before claiming a problem.
 4. Prioritize structural issues over cosmetic nits.

package/agents/thermonuclear-deep-review.md

@@ -4,6 +4,7 @@ description: Diff-scoped security and correctness audit for bugs, breakages, dev
 # @review is the deployment's `review` model role; the Go daemon's boot gate refuses to start unless the operator's settings give
 # this agent a model, through modelRoles.review or a task.agentModelOverrides entry for it (docs/kubernetes.md, Operator configuration).
 model: ["@review"]
+autoloadSkills: [thermonuclear-deep-review]
 ---
 
 # Thermonuclear Deep Review
@@ -12,7 +13,7 @@ Review only the supplied diff and changed-file context. Return findings with fil
 
 ## Process
 
-1. Load `skill://thermonuclear-deep-review` and use its complete rubric.
+1. Apply the complete rubric of `skill://thermonuclear-deep-review`, already in your context; do not read it again.
 2. Trace effects across callers, package boundaries, configuration, and public contracts.
 3. Check feature gates and developer workflows when the change can affect either.
 4. Complete an independent review before reading PR discussion.

package/dist/legion.js

@@ -33611,7 +33611,7 @@ import { logger } from "@oh-my-pi/pi-utils";
 // package.json
 var package_default = {
   name: "@sjawhar/pi-legion-envoy",
-  version: "5.25.0",
+  version: "5.27.0",
   type: "module",
   omp: {
     extensions: [

package/dist/skills/AGENTS.md

@@ -16,7 +16,7 @@ event intake, process lifecycle, credentials, and role delivery.
 | `legion-retro/` | the implementer, at retro | the pre-merge retrospective and its Dispatch message |
 | `legion-worker/` | planner, implementer, tester, reviewer, merger | the phase contracts: handoffs, GitHub identity, PR body and READY discipline, the merge-gate order |
 | `thermonuclear-code-quality/` | the `thermonuclear-code-quality` agent | the maintainability rubric of the reviewer's pair |
-| `thermonuclear-deep-review/` | the `thermonuclear-deep-review` agent | the security and correctness rubric of the reviewer's pair |
+| `thermonuclear-deep-review/` | the `thermonuclear-deep-review` agent, and the reviewer (the Security Guidelines) | the correctness rubric of the reviewer's pair, with its tagged, diff-triggered Security Guidelines and the attack on the PR body's claims |
 
 The owning skill above is where each contract is defined; a role prompt that needs a contract from its own seat points there or restates only its own step. This file lists and does not restate.
 A Legion prompt (a skill here, a role prompt, or an agent definition in `packages/pi-envoy/agents/`) names a task agent only as `task(agent="<name>")` and a skill it tells the model to load only as `skill://<name>`. Those are the two forms the Go daemon's boot gate and `legion probe-image` resolve through Oh My Pi, refusing by name one it cannot find; a dispatch or a load written any other way goes unchecked. An agent or skill Legion's prompts name is shipped here or in `packages/pi-envoy/agents/`, unless Oh My Pi bundles it.

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

@@ -65,7 +65,13 @@ before step 3. The design gate is not a substitute for review and retro.
 ## Durable outputs
 
 Write the integrated learning as one or more discoverable documents under `docs/solutions/`.
-Organize by reusable topic rather than by pull request. Each document uses this front matter:
+Organize by reusable topic rather than by pull request. Search `docs/solutions/` for the topic
+first: when a document already states the rule, update it in place (sharpen the rule, add this
+issue and pull request to `related_issues`) rather than writing a sibling; when the new learning
+replaces an old document, set the old one's `status: superseded` and add
+`superseded_by: docs/solutions/<path>.md`. Open each document with the rule in a few imperative
+lines; the incident that taught it goes in an Evidence section below, never in the rule. Each
+document uses this front matter:
 
 ```yaml
 ---

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

@@ -287,7 +287,7 @@ rather than creating a replacement bookmark or PR.
 
 ## PR body, review, and the merge gate
 
-The implementer writes the pull request body in the READY format when it opens the pull request,
+The implementer writes the pull request body from the template when it opens the pull request,
 and every later phase edits its own lines of the live body rather than replacing it. Each proof
 (the implementer's `E2E (implementer)` line and `proof` array, the tester's `E2E (tester)` line
 and `proof` array) is the changed behaviour exercised on a production-like surface, recorded as

package/dist/skills/legion-worker/references/merge-gate.md

@@ -71,14 +71,17 @@ completion leaves the issue in reviewing until you finish.
   First `cd -- "$LEGION_WORKSPACE" && jj -R "$LEGION_WORKSPACE" git fetch && jj -R
   "$LEGION_WORKSPACE" diff --from <approved-sha> --to <tip-sha> --summary`, whose output is quoted
   in READY (an empty output is quoted as `no file changes above the approved head`); then the same
-  with `'~docs/solutions'` appended, which must print nothing. The merger always posts
-  `READY #<n> at <current sha> (approved at <approved sha>) for <KEY> (<pr url>)` (the shape
-  `packages/pi-envoy/roles/merger.md` defines), its summary, and the PR body's gate facts as a
-  `dispatch_message` on the issue. When the `Legion addressing` line names a merge queue, it also
-  publishes the same packet there with `envoy_publish`; a 404 means the Dispatch message remains
-  the durable notice and the merger stays idle. The READY packet names both the implementer's and
-  tester's `E2E` lines; a missing one is reported to the architect instead of published. Legion
-  never merges.
+  with `'~docs/solutions'` appended, which must print nothing. *The READY packet*: the merger
+  always posts `READY #<n> at <current sha> (approved at <approved sha>) for <KEY> (<pr url>)`
+  (the shape `packages/pi-envoy/roles/merger.md` defines), then the PR body's `Outcome:` line and
+  its `Not proven / risk:` value — every bullet under that label joined with `; ` on the one
+  READY line, or `none` — quoted from the `## For the reviewer` block at that same head (or one
+  line saying the body carries no brief — the packet still publishes), then the `--summary`
+  output and the PR body's gate facts, as a `dispatch_message` on the issue. When the `Legion
+  addressing` line names a merge queue, it also publishes the same packet there with
+  `envoy_publish`; a 404 means the Dispatch message remains the durable notice and the merger
+  stays idle. The READY packet names both the implementer's and tester's `E2E` lines; a missing
+  one is reported to the architect instead of published. Legion never merges.
 
 ## After the human merge
 

package/dist/skills/legion-worker/references/pr-body.md

@@ -4,12 +4,24 @@ Part of `skill://legion-worker`. Read it before you write or edit any line of th
 body, put a `proof` array in a handoff, verify another phase's proof, or run the simplify pass.
 Every path it cites is in sjawhar/legion.
 
-## The READY format
+## The pull request body template
 
-The implementer writes the PR body in the READY format from the moment the PR opens, and every
+The implementer writes the PR body from this template from the moment the PR opens, and every
 later phase keeps it current rather than replacing it:
 
 ```
+## For the reviewer
+
+**Outcome:** <one sentence a user of this repository would recognise: what someone can now do, or what stops going wrong>
+**Why:** <the problem, one or two sentences, ending with the Dispatch key in parentheses — the key only, never a URL>
+**Change:**
+- <two to five bullets, each one behaviour a user or operator meets, never a file name>
+**Look at first:** <one to three `path:line` places where a wrong decision would hurt> (the reviewer writes this line)
+**Proven by:** <the `E2E (implementer)` line's surface and run, one line>
+**Not proven / risk:**
+- <one line per claim recorded as unproven before READY>, or the single word `none` (the reviewer writes this line; `none` is invalid while such a claim stands)
+**Size:** <files changed, +added/−removed>
+
 ## Verification
 
 **CI:** `Tests` run <run-id> — jobs lint, typecheck, test all success at <head-sha>; `PR Title` run <run-id> — job pr-title success at <head-sha>.
@@ -28,10 +40,10 @@ left open <thread URL> — newest reply by <login> is not its opener's or the Le
 <verdict>. (omitted entirely on a docs-only PR — there is no code for either pass, so neither runs)
 
 **E2E (implementer):** <surface> — ran `<command or run id>`, observed <result>, at head <sha>.
-Negative control: <deliberately broken input> → <refusal or failure observed>.
+Negative control: <deliberately broken input or call> → <refusal or failure observed>.
 
 **E2E (tester):** <surface> — ran `<command or run id>`, observed <result>, at head <sha>.
-Negative control: <deliberately broken input> → <refusal or failure observed>.
+Negative control: <deliberately broken input or call> → <refusal or failure observed>.
 Verified the implementer's proof by <re-running its command | driving the same surface independently>.
 
 **Production:** <what was checked in production, how, what was observed> — merge commit <sha>.
@@ -42,11 +54,27 @@ Verified the implementer's proof by <re-running its command | driving the same s
 **Chain:** stacked on <base bookmark> frozen at <sha> / not stacked.
 ```
 
+## The brief for the human
+
+`## For the reviewer` is written for the person who merges; `## Verification` below it stays the
+ledger the reviewer and merger check against GitHub. The implementer writes `Outcome`, `Why`,
+`Change`, `Proven by`, and `Size` when the pull request opens, and keeps them true after every
+push; `Outcome` is a sentence a user of the repository would recognise, never "fix bug" or a file
+name, and `Why` ends with the Dispatch key, never a URL. The reviewer writes `Look at first` and
+`Not proven / risk` at each round, into the live body (`legion gh -- api
+repos/{owner}/{repo}/pulls/{number} --jq .body`, edit, then `--method PATCH ... -F body=@body.md`);
+`Not proven / risk` copies every claim recorded as unproven before READY — the tester's
+`failures`, the reviewer's own review, any proof-check comment already on the pull request —
+word for word, and `none` is a finding while one stands. The merger quotes `Outcome` and
+`Not proven / risk` from the body at the published head in the READY packet
+(*The READY packet* in `skill://legion-worker/references/merge-gate.md`); a stale `Outcome` that no
+longer describes the diff is a finding against the implementer, not a line the merger rewrites.
+
 ## What a proof is
 
 **A proof** is the changed behaviour exercised on the surface a user reaches it through, recorded
 as the exact command or run id, what was observed, the head SHA, and one negative control —
-a deliberately broken input and the refusal or failure observed. The surface is
+a deliberately broken input or call and the refusal or failure observed. The surface is
 **production-like** — the repository's real-process test harness and fixtures, a sandbox
 repository, a real browser, a devN stack, staging, or a local stack with real migrations, one that
 has the resource the change touches — and each `E2E` line carries a **link** to that run,

package/dist/skills/thermonuclear-deep-review/SKILL.md

@@ -56,6 +56,32 @@ The codebase might gate features behind feature flags or internal-only checks. D
 ## Intended Breakage Guidelines
 If a high-risk effect is an intentional, well-constrained change, do not report it as a defect. Report it when the scope or consequences appear unclear, including when a safeguard or feature gate is removed.
 
+## Claims in the PR body
+
+A safety or correctness claim written in a PR body is a claim like any other, and the only reader who catches a wrong one is the reader told to ATTACK it. Verifying reviewers read the code against the claim and pass; that is what they are for. Attack the body's claims, not only its diff.
+
+Two shapes to attack first:
+
+- **Neutralization ORDER, not coverage.** Any pipeline that sanitizes and then edits can create what it sanitized. The test is not "did it neutralize everything" but "can any later pass CREATE what was being neutralized".
+- **A severity resting on a third party's formatting is a dependency, not a mitigation.** Rate it as the bet it is, and fix rather than disclose.
+
+## Security Guidelines
+
+For each row whose surface the diff touches, answer with a file:line citation. End your report with one `Security:` line: each touched row's tag and its answer with file:line, or `Security: no sensitive surface in this diff.` when the diff touches none.
+
+| Tag | If the diff touches… | Answer, with file:line |
+| --- | --- | --- |
+| `authz` | an authorization or refusal check, or a new route, command, or tool | who may call it, who may not, where the diff enforces that, and what the unauthorized caller gets |
+| `secret` | a token, grant, secret file, credential helper, or its lifetime | what widened: who can read it, for how long, in which process |
+| `untrusted-input` | a subprocess, argv, path, template, or query built from text an outside party controls (an issue body, a PR comment, a webhook payload, model output) | the boundary that neutralizes it, and whether any later pass can re-create what was neutralized (order, not coverage) |
+| `prompt` | a prompt that embeds untrusted text into an agent's instructions | what delimits the untrusted region, and what the agent may do if it obeys that text (OWASP LLM01 prompt injection, LLM06 excessive agency) |
+| `supply-chain` | a dependency, lockfile, base image, or GitHub Action | the version, the pin (a digest or a SHA checked against its tag), and the permissions the workflow runs with |
+| `sandbox` | a sandbox or pod manifest, a capability, or a network policy | which isolation property changed, and against whom |
+| `agent-def` | an agent definition, skill, role prompt, `.omp/` config, or `AGENTS.md` | whether this diff can steer its own reviewers, and why this edit is trustworthy anyway |
+| `transport` | TLS/certificate verification, a signature, HMAC, or randomness source, or an unbounded read/write sized by untrusted input | what changed, the check or bound it relies on, and the ASVS V11/V12 identifier it maps to |
+
+Cite an OWASP ASVS v5.0.0 identifier where one applies (`v5.0.0-1.2.5` style). A security finding with no stated exploit path is not a finding: call it hardening and rank it Minor. A security finding that states an exploit path is always its own finding at its real priority, never folded into hardening. Report at most two hardening items, ranked, and fold the rest into one hardening paragraph. Start each security finding with its row's tag, `Security[<tag>]:`, so it can be told from the others and counted by row.
+
 ## Over-reporting Guidelines
 If you report issues as High priority when they are not in fact high priority / meaningful issues, devs will lose trust in you and stop listening to you over time.
 Never misreport priority or importance. Trace issues end to end and report only what the evidence supports.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sjawhar/pi-legion-envoy",
-  "version": "5.25.0",
+  "version": "5.27.0",
   "type": "module",
   "omp": {
     "extensions": [