@sjawhar/pi-legion 10.26.0 → 10.27.1

package/dist/legion.js

@@ -16956,7 +16956,7 @@ async function bootLegionClaim(host2) {
 // package.json
 var package_default = {
   name: "@sjawhar/pi-legion",
-  version: "10.26.0",
+  version: "10.27.1",
   license: "Apache-2.0",
   type: "module",
   omp: {

package/dist/skills/legion-controller/references/slack-mentions.md

@@ -24,9 +24,16 @@ line.
 ## What a mention carries
 
 The delivery's `message` holds Slack's fields: `channel_id`, `user_id` (a Slack user id such as
-`U0123ABCD`), `text` (the mention itself appears in it as `<@U…>`, the app's own id), `ts` (the
-mention's own timestamp), `thread_ts` (the thread's root, only when the mention was posted inside a
-thread), and `bot_id` and `bot_name` when a bot posted it.
+`U0123ABCD`), `text` (the message's own words, then the display text its blocks and then its
+attachments carry, a line apiece; a line an object has already shown under another of its own
+names is left out, and so is one equal to the message's own words or to a line of them, while two
+objects saying the same thing both deliver it; an attachment's `fallback` comes last of that
+attachment and only when the attachment did not say it already; a mention a person typed
+in a Slack client carries its own words alone, since a `rich_text` block that only repeats those
+words is not read, while an app's rich text, which says more, is delivered; the mention itself
+appears in it as `<@U…>`, the app's own
+id), `ts` (the mention's own timestamp), `thread_ts` (the thread's root, only when the mention was
+posted inside a thread), and `bot_id` and `bot_name` when a bot posted it.
 
 ## Answer in the thread
 

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

@@ -254,16 +254,20 @@ reviewing until you finish.
 - **Nothing waits in the session for a deploy.** A `pending` ends the look: the daemon suspends
   your claim with its session and the issue's volume kept, the pod goes, and the daemon wakes the
   check (the pod comes back and your session resumes with a new check task) on Dispatch's
-  `issue.deployed` event for the pull request, or, for `sjawhar/legion`, on a Legion daemon's boot
-  on a build containing the merge, on Dispatch's `server.started` naming such a build, or on the
-  build the daemon read from Dispatch at its boot. The woken look's task names the event
-  (`Dispatch's issue.deployed: run <id> completed <t>`, `the Legion daemon's boot on build <sha>`,
-  `Dispatch's start on build <sha>`, `Dispatch's build <sha>`), and its `Production:` line names
-  it too, so the pull request carries the cause. Never poll for the deploy, never wait on a reply,
-  and never ask anyone for approval to deploy. Open a `dispatch ask` to a person only when the
-  instructions name nobody for that deploy; it starts with the production gap and why it matters,
-  then names the required install or restart step, its risk, and outcome-named options, and the
-  look still ends `pending`.
+  `issue.deployed` event for the pull request; when the project's `legion.yaml` names the
+  repository's deploy workflow (`projects.<KEY>.deploys`), at each completed run of that workflow
+  on the default branch whose named step (such as `Apply`) succeeded after the merge, once per such
+  job; or, for `sjawhar/legion`, on a Legion daemon's boot on a build containing the merge, on
+  Dispatch's `server.started` naming such a build, or on the build the daemon read from Dispatch at
+  its boot. A wake while a look is open is kept, and a `pending` then starts the next look at once.
+  The woken look's task names the event (`Dispatch's issue.deployed: run <id> completed <t>`,
+  `the deploy workflow's run: <repo> <workflow> run <id> attempt <n>, job <job name>: <step> succeeded at <t>`,
+  `the Legion daemon's boot on build <sha>`, `Dispatch's start on build <sha>`,
+  `Dispatch's build <sha>`), and its `Production:` line names it too, so the pull request carries
+  the cause. Never poll for the deploy, never wait on a reply, and never ask anyone for approval
+  to deploy. Open a `dispatch ask` to a person only when the instructions name nobody for that
+  deploy; it starts with the production gap and why it matters, then names the required install or
+  restart step, its risk, and outcome-named options, and the look still ends `pending`.
 - **The bounds.** A look is bounded at 2 hours: one that reports nothing ends as a `pending`
   would. The whole check is bounded by the project's `production_check_hours` (336, 14 days, by
   default) from the close, and the wake at that bound is the last look, told so in its task

package/package.json

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