@sjawhar/pi-legion 8.7.1 → 8.9.0

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 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.7.1",
15312
+ version: "8.9.0",
15313
15313
  license: "Apache-2.0",
15314
15314
  type: "module",
15315
15315
  omp: {
@@ -15321,7 +15321,7 @@ var package_default = {
15321
15321
  ]
15322
15322
  },
15323
15323
  legion: {
15324
- daemonApiVersion: 17
15324
+ daemonApiVersion: 18
15325
15325
  },
15326
15326
  repository: {
15327
15327
  type: "git",
@@ -156,16 +156,16 @@ before new work: anything unpushed is gone. That message stays in history; recon
156
156
  - **Before pushing, check ancestry:** `jj -R "$LEGION_WORKSPACE" log -r 'ancestors(@, 5)'`
157
157
  — verify only your issue's commits are in the chain, not unrelated work.
158
158
 
159
- **Shared operation safety:** Every Legion issue workspace is a `jj workspace` of one shared
160
- clone, so they all share one operation log: `jj undo`, `jj abandon`, and
161
- `jj op restore|revert|abandon|undo` rewrite it for every tree at once. The extension refuses them in every
162
- phase-worker pane before they run — a `bash` command in any position of a pipeline or `&&`
163
- chain, with or without `-R`, judged on the whole argument list (a supervised service's start
164
- included); `eval` code; and stdin written to a service (a `write` to `proc://<id>`) — from your
165
- own tool calls and from any `task` subagent you spawn (it runs in your pane, against the same
166
- log), and a `bash` command whose quoted text merely mentions `jj`
167
- with one of those words (a heredoc, an echo, a commit message) is refused too: write such text
168
- with the `write` tool or say "operation-log rollback" instead. `jj restore <paths>`,
159
+ **Shared operation safety:** Under tmux every issue workspace is a `jj workspace` of one shared
160
+ clone and operation log; under Kubernetes each issue pod has its own, shared by that issue's roles
161
+ alone. Either way `jj undo`, `jj abandon`, and `jj op restore|revert|abandon|undo` rewrite a log
162
+ other agents work in. The extension refuses them in every phase-worker pane before they run — a
163
+ `bash` command in any position of a pipeline or `&&` chain, with or without `-R`, judged on the
164
+ whole argument list (a supervised service's start included); `eval` code; and stdin written to a
165
+ service (a `write` to `proc://<id>`) — from your own tool calls and from any `task` subagent you
166
+ spawn (it runs in your pane, against the same log), and a `bash` command whose quoted text merely
167
+ mentions `jj` with one of those words (a heredoc, an echo, a commit message) is refused too: write
168
+ such text with the `write` tool or say "operation-log rollback" instead. `jj restore <paths>`,
169
169
  `jj op log`, and `jj op show` stay allowed. Recover forward only: a new commit
170
170
  (`jj -R "$LEGION_WORKSPACE" new`) or `jj -R "$LEGION_WORKSPACE" restore <paths>` of files.
171
171
  Anything else, stop and send the owning architect the `jj -R "$LEGION_WORKSPACE" log`
@@ -398,9 +398,9 @@ re-runs it at once. While the pull request conflicts with its base (GitHub shows
398
398
  a body edit re-judges nothing there either; a push cures both, but only once the pull request is
399
399
  mergeable, so the implementer forward-merges a conflicting one first (*Reintegrating the base* in
400
400
  `skill://legion-worker/references/conflicts-and-rewrites.md`). Its ancestry check refuses
401
- unless `@-` descends from `legion/<KEY>@origin` (or the branch is not on GitHub yet): every issue
402
- workspace shares one clone, so another role's push moves `legion/<KEY>@origin` here at once, and
403
- a push that did not descend from it would move the remote branch sideways onto your commit and
401
+ unless `@-` descends from `legion/<KEY>@origin` (or the branch is not on GitHub yet): your issue's
402
+ roles share one clone (under tmux every issue does), so another role's push moves the remote branch
403
+ here at once, and a push not descending from it would move it sideways onto your commit and
404
404
  drop theirs. A handoff commit never sits on an implementer's unpushed chain: when the issue moves
405
405
  back to planning, the implementer's unpushed commits stay off the bookmark until the implementer
406
406
  returns, and the planner writes its handoff on the remote tip.
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@sjawhar/pi-legion",
3
- "version": "8.7.1",
3
+ "version": "8.9.0",
4
4
  "license": "Apache-2.0",
5
5
  "type": "module",
6
6
  "omp": {
@@ -12,7 +12,7 @@
12
12
  ]
13
13
  },
14
14
  "legion": {
15
- "daemonApiVersion": 17
15
+ "daemonApiVersion": 18
16
16
  },
17
17
  "repository": {
18
18
  "type": "git",