@sjawhar/opencode-legion-envoy 5.6.2 → 5.6.4

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sjawhar/opencode-legion-envoy",
-  "version": "5.6.2",
+  "version": "5.6.4",
   "license": "Apache-2.0",
   "type": "module",
   "main": "dist/src/server.js",

package/skills/dispatch/SKILL.md

@@ -84,7 +84,8 @@ a new version that keeps the human's own text, never a second "spec" artifact be
   it for your inference; an answer that is only a chosen option is recorded in the form
   `<name> chose "Commit author" on the question below (<date>)`, naming them from `dispatch_whoami`
   or the conversation, or "the person" when the token names no owner — never a name you were not
-  given. A point you inferred says so, with the reasoning; during a live brainstorming
+  given. A point you inferred says so, with the reasoning — a security concern, a restriction, or
+  a cost nobody measured is exactly this, not a settled constraint; during a live brainstorming
   conversation, `skill://dispatch-brainstorming` is stricter and keeps an inference out of the spec
   until the human has agreed to it. One carried in from another document keeps its provenance: an
   agent's inference there is marked one here, or stays out until the human raises it.

package/skills/legion-architect/SKILL.md

@@ -170,6 +170,20 @@ and request approval again as this section says. Later waves, re-scoping open ch
 same Acceptance, and integration-failure children need no spec edit and no new approval, and a
 child issue's spec is never gated: the root approval covers the tree.
 
+**A decision block for a read no pod can make.** An acceptance criterion sometimes needs
+evidence from a production or external system before a human can approve it: a measurement, a
+current count, a stored record. Check first whether the evidence is already reachable through a
+credential this tree's own pods carry — the model route every pod already has, and any further
+identity the operator's deployment configuration grants pods (read the pod's own environment,
+for example `AWS_CONFIG_FILE` or `AGENT_SECRETS_URL`, rather than assuming there is none; a
+credential can exist without any skill having told you so). When the evidence genuinely is not
+reachable, do not have a different running session perform the read on this tree's behalf and
+fold the result into the spec as if it were routine: write the missing capability as its own
+decision block — which external system, which read or write, why the spec needs it — addressed
+to the human, in the same spirit as the implementer reports a production-check gap (section 6) and leave it
+open until the human resolves it. A workaround substituted for that record only hides the gap
+from the next tree that hits it.
+
 ## 2. Children in flight
 
 Release only the next useful wave. A release is an explicit lifecycle write:

package/skills/legion-worker/SKILL.md

@@ -239,6 +239,17 @@ artifact, not a broken credential. Run credentialed commands from your own bash
 run that may outlast a minute with `gh run watch` in bash, which redeems once and then runs on the
 token it got.
 
+**Other credentials your pod may already carry.** Before reporting that a read is unreachable,
+check for them rather than assuming none exist: `AGENT_SECRETS_URL` and `AGENT_SECRETS_KEY_DIR`
+are set when the deployment enrolls pods with the agent-secrets broker (`docs/kubernetes.md`,
+"Operator configuration"), in which case `agent-secrets <SECRET> -- <command>` runs `<command>`
+with only the secrets this pod generation's grant allows — refuses closed, naming the secret, if
+the rule does not allow it. `AWS_CONFIG_FILE` is set when the deployment's `pod.volumes` carries a
+further projected token beyond the model route's own; read the file it names for what profiles it
+configures before assuming the AWS CLI has nothing to reach. Neither variable existing is a
+guarantee the read you need is covered — a refusal from either still means what it says — but
+neither should be assumed absent without checking.
+
 ## GitHub PR comment attribution
 
 Append this exact structured footer to **every** pull-request comment and review that this