@sjawhar/claude-envoy 1.7.1 → 1.8.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/.omp-plugin/plugin.json
CHANGED
package/dist/envoy-channel.js
CHANGED
|
@@ -52057,6 +52057,13 @@ var legionHeldOutboxRow = object({
|
|
|
52057
52057
|
waitedSeconds: number2().int().nonnegative(),
|
|
52058
52058
|
waitsOn: number2().int().positive()
|
|
52059
52059
|
});
|
|
52060
|
+
var legionWakeWaiting = object({
|
|
52061
|
+
claim: nonEmptyString,
|
|
52062
|
+
issue: issueKey,
|
|
52063
|
+
role: _enum2(LEGION_ROLES),
|
|
52064
|
+
kind: nonEmptyString,
|
|
52065
|
+
dueAt: timestamp
|
|
52066
|
+
});
|
|
52060
52067
|
var legionIssue = object({
|
|
52061
52068
|
key: nonEmptyString,
|
|
52062
52069
|
generation: number2().int().nonnegative(),
|
|
@@ -52158,6 +52165,7 @@ var LegionStateResponse = object({
|
|
|
52158
52165
|
pendingStatusWrites: array(legionPendingStatusWrite),
|
|
52159
52166
|
heldOutboxRows: array(legionHeldOutboxRow),
|
|
52160
52167
|
strandedClaims: array(legionStrandedClaim),
|
|
52168
|
+
wakesWaiting: array(legionWakeWaiting).optional(),
|
|
52161
52169
|
controllerLocator: legionControllerLocator.optional(),
|
|
52162
52170
|
agentSecretsLogin: legionAgentSecretsLoginView.optional(),
|
|
52163
52171
|
capabilities: array(legionCapabilityState),
|
|
@@ -55082,9 +55090,9 @@ var import_nats2 = __toESM(require_mod4(), 1);
|
|
|
55082
55090
|
|
|
55083
55091
|
// package.json
|
|
55084
55092
|
var name = "@sjawhar/claude-envoy";
|
|
55085
|
-
var version2 = "1.
|
|
55093
|
+
var version2 = "1.8.0";
|
|
55086
55094
|
var legion = {
|
|
55087
|
-
daemonApiVersion:
|
|
55095
|
+
daemonApiVersion: 53
|
|
55088
55096
|
};
|
|
55089
55097
|
|
|
55090
55098
|
// src/channel-forwarder.ts
|
|
@@ -25,6 +25,7 @@ except a clear defect a role reports ([Issues handed to Legion](#issues-handed-t
|
|
|
25
25
|
- When a `dispatch` command fails, or a `curl` read of Dispatch fails or prints no JSON array, act on nothing it would decide and name its first line in your summary (the turn's last message), because an empty read is no evidence. A Slack read answers a JSON object, and `skill://legion-controller/references/slack-mentions.md` holds its own success test.
|
|
26
26
|
- Before you say that a service or an API is out of reach, run the call through the secrets broker's client with the secret your instructions name (`skill://agent-secrets`), and report it unreachable only with the command you ran and its output.
|
|
27
27
|
- Write every Dispatch comment, message and ask as `skill://dispatch-writing-specs`'s "Rules for the text" say.
|
|
28
|
+
- A message that must reach more than 4 role topics is yours to send and nobody else's (`skill://envoy`). Send it to no more than 4 topics a minute, and send none while a daemon restart or a pod roll is under way, because each publish wakes a session that reads its whole context again, which the provider charges as uncached input: a mean of 576,083 tokens a wake, a median of 493,636 and a ninetieth percentile of 1,327,888. Spread the rest over later turns, and name in your summary the topics you have not sent to yet.
|
|
28
29
|
|
|
29
30
|
Launch, `gh`, pull requests, takeover: `skill://legion-controller/references/session.md`.
|
|
30
31
|
|
|
@@ -85,6 +86,8 @@ when the holder lets go. `dispatch read` each root in `admission.trees` whose `p
|
|
|
85
86
|
`admitted`. When `Claimed by:` is `nobody` or ends `· not running`, `envoy_publish` `<KEY>: the
|
|
86
87
|
claim is free; claim it again.` to `notifications.role.<issues.<KEY>.architect.locator.claim>`.
|
|
87
88
|
|
|
89
|
+
Before you publish to more than one role topic, read whether a wave of wakes is already running, in the state `read_state` returns: `wakesWaiting`, every wake the daemon's pacing holds until its turn, which is empty at every moment outside a wave; `daemon.startedAt`, since a restart minutes old is a wave; and each claim's `updateRound`, which an open pod-update round sets. While any of the three says a wave is running, publish nothing and say so in your summary, because your wake would land on the same minute as the daemon's own.
|
|
90
|
+
|
|
88
91
|
## Issues handed to Legion
|
|
89
92
|
|
|
90
93
|
The daemon works only issues carrying the Dispatch label `legion` (any case). Work reaches Legion
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@sjawhar/claude-envoy",
|
|
3
|
-
"version": "1.
|
|
3
|
+
"version": "1.8.0",
|
|
4
4
|
"license": "Apache-2.0",
|
|
5
5
|
"description": "Claude Code channel plugin for Legion's Envoy bus",
|
|
6
6
|
"type": "module",
|
|
@@ -19,7 +19,7 @@
|
|
|
19
19
|
"AGENTS.md"
|
|
20
20
|
],
|
|
21
21
|
"legion": {
|
|
22
|
-
"daemonApiVersion":
|
|
22
|
+
"daemonApiVersion": 53
|
|
23
23
|
},
|
|
24
24
|
"repository": {
|
|
25
25
|
"type": "git",
|
package/skills/envoy/SKILL.md
CHANGED
|
@@ -77,6 +77,7 @@ Every topic starts with `notifications.`.
|
|
|
77
77
|
|
|
78
78
|
- Send to one session with `envoy_send`, to the one session that holds a named duty with a role, and to a group with a team topic.
|
|
79
79
|
- Publish to a role with `envoy_publish(topic="notifications.role.<role>", ...)`; never subscribe to a role topic, because the listener forwards a role message to its holder only. A publish returns once the holder's session confirmed it, with the live `holder` and its `holder_state`. When nobody holds the role, Envoy keeps the message for the session that claims the role next: the answer says it was kept, and that session is handed it once, within one hour of the keep. A holder that is not `live` returns an error instead: that refusal names the holder, its `holder_state` (`unresponsive` or `gone`), its `last_seen` and `claim_released: false`, and nothing was forwarded and nothing kept, so publish the message again once the holder answers rather than starting a replacement for it or taking anything from it. A live holder that did not confirm the message within about 4 seconds errs too, and you see that one after about 8 seconds, because the client tries once more. No error releases the role's claim: a holder whose `holder_state` is `unresponsive` keeps its role. `envoy_role_get(role=...)` finds the holder first. The stream keeps a forward on the holder's inbox, so a holder that was forwarded to gets it once from its own durable consumer, also after a restart or a reconnect.
|
|
80
|
+
- A message that must reach more than 4 role topics is the project controller's to send, not yours. Each publish wakes a session, and a woken session reads its whole context again, which the provider charges as uncached input: a mean of 576,083 tokens a wake, a median of 493,636 and a ninetieth percentile of 1,327,888. The controller is also the one session that can read whether a wave of wakes is already running, and a fan-out sent into a daemon restart or a pod roll is what puts an Anthropic organization over its per-minute uncached-input cap. Send the controller the topics and the text, and it sends them at its own rate (`skill://legion-controller`).
|
|
80
81
|
- For a team, the group subscribes to `notifications.team.<name>.>`, and any member publishes to `notifications.team.<name>.all`. Envoy treats any other `notifications.` topic that no source in the table uses the same way. It reaches every session subscribed when it is published, yours too when you subscribe. The listener also asks each other session that holds its own NATS connection and registered the topic (every session that follows it with `envoy_subscribe`) to confirm the message; your own session is never asked. A publish returns an error naming each such session that did not confirm within about 4 seconds, and you see it after about 8 seconds, because the client tries once more. A session named with `receipt_timeout` still gets the message: the listener kept a copy in that session's inbox, which the session reads back once its connection returns. An `unresponsive` session is sent the message the same way, asked for no receipt and named under `unresponsive` in the answer, which is no failure. A session that stopped without unregistering stays in the registry until the reaper finds it `gone`, and is named until then; a named session is not a failed delivery to the others. A team topic is not kept for a session that subscribes later. A topic outside `notifications.` is refused.
|
|
81
82
|
- How a role claim survives a resume, a fork or a dead process: `skill://envoy/references/roles.md`.
|
|
82
83
|
- In a Legion pane, the plugin claims your role at session start; read `skill://envoy/references/legion.md` before you claim, release or publish to a role, or answer a role delivery failure there.
|