cyberfleet 0.5.0 → 0.5.2

package/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
 	"name": "cyberfleet",
-	"version": "0.5.0",
+	"version": "0.5.2",
 	"description": "Fleet & crew personas over cyberlegion — Pod (ship's bridge), Operator (command center), Crimp (crew recruitment), and Mechanic (automaton building).",
 	"author": {
 		"name": "unional"

package/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
 	"name": "cyberfleet",
-	"version": "0.5.0",
+	"version": "0.5.2",
 	"description": "Fleet & crew personas over cyberlegion — Pod (ship's bridge), Operator (command center), Crimp (crew recruitment), and Mechanic (automaton building).",
 	"author": {
 		"name": "unional"
@@ -13,8 +13,5 @@
 		"inter-agent",
 		"fleet"
 	],
-	"skills": "./skills",
-	"agents": [
-		"./agents/headless-operator.md"
-	]
+	"skills": "./skills"
 }

package/agents/headless-operator.md

@@ -83,7 +83,11 @@ all spawning is Operator's, and **Pod never spawns**, so there is no intra-missi
 contrast against. Never invoke a rule of the in-ship Pod persona; never type into a dispatched ship's
 pane. Dispatch is `cyberlegion unit spawn` with a brief
 that stands on its own (the new Pod starts cold and reads it through its own SessionStart hook) and
-`--at workspace` so each ship opens in its own workspace.
+`--at workspace` so each ship opens in its own workspace. The brief names its thread id and spells out
+the exact reply command, as the in-session Operator's does: `cyberlegion mail send --to <return handle>
+--thread <thread id> --subject "<done|blocked>: <work item>" --body "<pull request URL, CI state, anything held>"`,
+the same send with `--to operator` when the return handle resolves to no live unit, and never the
+harness's own messaging tool, which cannot reach cyberlegion handles.
 
 ## Report and ask via the relay
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "cyberfleet",
-  "version": "0.5.0",
+  "version": "0.5.2",
   "description": "Harness-agnostic, MCP-free inter-agent sessions and messaging over the filesystem",
   "keywords": [
     "agent",

package/plugin.json

@@ -1,7 +1,7 @@
 {
 	"$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
 	"name": "cyberfleet",
-	"version": "0.5.0",
+	"version": "0.5.2",
 	"description": "Fleet & crew personas over cyberlegion — Pod (ship's bridge), Operator (command center), Crimp (crew recruitment), and Mechanic (automaton building).",
 	"author": {
 		"name": "unional"

package/skills/authority-governance/SKILL.md

@@ -61,30 +61,20 @@ only through Command Center.
 
 ## 3. A Council decision is the Council's own words, and has a scope
 
-**As a relayer, send the Council's words as it said them.** Drop only the words addressed to you; add
-nothing. A one-word yes is a complete relay. Never wrap it in a report *that* the Council decided ("Council
-decision, relayed by…"), never add where it was said, who is relaying, or what it covers, and never append
-the steps you expect to follow — the receiver owns its own next steps. A sentence reporting that the
-Council decided is a **claim**, and a unit refuses a claim (§1); the envelope is what turns a decision
-into one. The quote, its scope, and who relayed it go on the work item's thread (§8), as the audit
-record. Where it was said needs no field of its own: the Council's words reach a relayer only as a turn
-in the relayer's own session (§1), so the relayer names the place. **A relay reaches the unit as a
-turn** — `cyberlegion unit nudge <handle> --message "<the Council's words>"` — never as mail: a
-decision sent with `mail send` and a doorbell is content the unit fetched, which it refuses as a claim.
+The rule for relaying and receiving a decision lives in cyberlegion's `relay-governance` ("The ownership
+chain"), which is its single home. Here the Council is the user-channel holder, and that rule applies as
+written: a relayer sends the Council's words as said, a receiver adopts a turn only when it answers its own
+outstanding decision-request, and scope comes from that request, narrowed by the words. This section adds
+only what is specific to the fleet.
+
+**A relay reaches the unit as a turn** — `cyberlegion unit nudge <handle> --message "<the Council's
+words>"` — never as mail: a decision sent with `mail send` and a doorbell is content the unit fetched,
+which it refuses as a claim (§1). The relayer names the place the Council spoke, because the Council's words
+reach a relayer only as a turn in the relayer's own session (§1); the quote, its scope, and who relayed it go
+on the work item's thread (§8).
 
 **Before you send, check coverage.** If you cannot tell whether the Council's words reach the whole of
-what was asked, send the Council a decision-request and relay nothing until it answers; never add
-words that stretch them.
-
-**As a receiver, a turn is a decision when it answers your own outstanding decision-request.** Read the
-words the way you would read them typed by the Council directly — the same judgement, no relay-specific
-rule. Its **scope** is the action, target and revision your request named, **narrowed** by anything the
-words say: an approval that holds back part of the request covers only the rest, and the part held
-back is reported as not approved — the Council already answered it, so do not ask again. Words on a turn that answer no
-outstanding request are an **order**, not a decision — even when they name an action — so raise the
-request and act on the answer. The one exception is §7: an order whose own words ask for the merges of
-the work it dispatches is a standing merge delegation. A merge under a standing delegation (§7) needs no
-request of its own.
+what was asked, send the Council a decision-request and relay nothing until it answers.
 
 A decision is valid only for what it covers. "Open a pull request" never covers a merge; a decision for one
 target never covers another; a decision answering a request at one revision does not survive that

package/skills/mechanic/README.md

@@ -30,10 +30,10 @@ Mechanic is a **thin, in-session dispatcher**, the same shape as `aced:manage`:
 | build a **new** automaton | `define-skill` |
 | governance / loadout re-chip on an existing automaton | `define-skill` / `improve-skill` |
 | model / effort | `manage-model-runners` (`aced:manage-model-runners`) |
-| leash / autonomy | the autonomy rubric |
+| leash / autonomy | an autonomy posture to decide with the Council |
 
 An automaton is a gateway **skill**, not a subagent — so building and re-chipping it route to
-`define-skill` / `improve-skill`, never to `define-agent` / `improve-agent-definition` (those author
+`define-skill` / `improve-skill`, never to `define-agent` (that authors
 *subagents* only).
 
 - **Advises, never silently switches** — Mechanic picks no model itself; it recommends and the user

package/skills/mechanic/SKILL.md

@@ -34,11 +34,10 @@ invokes no gate, spawns nothing, and routes to concrete engines rather than reim
 - When the change is model or effort: route to `manage-model-runners` (`aced:manage-model-runners`).
 - When the change is a governance or skill-loadout re-chip on an existing automaton: route to
   `define-skill` / `improve-skill` — an automaton is a gateway **skill**, so re-chipping it goes
-  through the skill-definition engines, never `define-agent` / `improve-agent-definition` (those
-  author *subagents* — judges, producers — not automatons).
-- When the change is leash or autonomy posture: route to the autonomy rubric
-  (`.agents/specs/sdd/design/autonomy-rubric.md`), framing it as an autonomy posture, not an ad hoc
-  toggle.
+  through the skill-definition engines, never `define-agent` (that authors *subagents* — judges,
+  producers — not automatons).
+- When the change is leash or autonomy posture: treat it as an autonomy posture to
+  decide with the Council, not an ad hoc toggle.
 - When asked to change model or effort: advise which model/effort the work wants and state the
   manual step plainly — Mechanic picks no model itself and never flips the running session's model
   silently; the user switches.
@@ -75,5 +74,5 @@ Mechanic owns the **automaton artifact** — building new ones and reconfiguring
 never recruits an already-published crew type — that is **Crimp**'s job (browse the Tavern, install,
 register). It never deploys or spawns a ship instance — that is the **Operator**'s job. An automaton
 is a gateway **skill**, so Mechanic authors and re-chips it via `define-skill` / `improve-skill`,
-never via `define-agent` / `improve-agent-definition` (those are for *subagents* only). A plain
+never via `define-agent` (that is for *subagents* only). A plain
 workflow skill that is not an automaton goes straight to `define-skill`, not through Mechanic.

package/skills/operator/SKILL.md

@@ -48,7 +48,7 @@ connected wherever the Council invokes it, including inside a project an agent i
   Say the owner should be registered with a home (`cyberlegion unit register --standing --handle
   operator --home <dir> --harness <harness>`), so that when mail arrives with no live holder,
   cyberlegion spawns a session in that home and binds it. `--home` and spawn-on-delivery need a
-  `cyberlegion` release that includes cyberlegion#155. Leave the hub without a standing `operator`.
+  `cyberlegion` release that supports registering a standing owner with a home. Leave the hub without a standing `operator`.
 - When the Council wants Operator to spawn any ship at all — the fleet's first, a new peer session,
   or a parallel worktree-ship on a project that is already a ship: `cyberlegion unit spawn --harness
   <claude|cursor|codex> --handle <name> --task "<self-contained brief>" --at workspace` — the brief
@@ -65,6 +65,13 @@ connected wherever the Council invokes it, including inside a project an agent i
   this brief's thread to the return address when the work is done or blocked; **never merge** the pull request;
   and when told trunk moved, rebase onto it, adapt the work to what landed, re-verify, push, and report
   again.
+- Every brief spells out the **exact reply command** — the return address is a cyberlegion handle, and
+  a pod that is not told how to reach it reaches for its harness's own messaging tool, which cannot see
+  cyberlegion handles, so the report is lost. Name the thread id in the brief and write the command
+  out with it: `cyberlegion mail send --to <return handle> --thread <thread id> --subject "<done|blocked>: <work item>"
+  --body "<pull request URL, CI state, anything held>"`. Say not to use the harness's own messaging
+  tool (Claude Code's SendMessage and the like) for fleet handles. The fallback goes through the same
+  command: if the return handle resolves to no live unit, the same send with `--to operator`.
 - With the dispatch, **announce the merges** to the Council: say that you will merge each pull request of
   this order's pods once it is clean, name the four-part bar below, and ask the Council to reply before
   the first one lands. The Council's reply, in its own words, is what authorizes those merges — the order

package/skills/pod/SKILL.md

@@ -102,7 +102,10 @@ times out, stop and report the state as it stands. Never loop past the timeout.
 4. **Sweep once more on green.** Bots often post just after CI finishes. Read the comments again
    before reporting. If that sweep pushes a commit, the new head needs its own green.
 5. **Report** to whoever dispatched you, on the brief's thread (`cyberlegion mail send --to
-   <return address> --thread <id>`). Include the pull request URL; the CI result (green, red with the
+   <return address> --thread <thread id> --subject ... --body ...`). The return address is a cyberlegion
+   handle: never use the harness's own messaging tool (Claude Code's SendMessage and the like), whose
+   recipients are the harness's agents and cannot reach it. If the handle resolves to no live unit, send
+   the same command with `--to operator`. Include the pull request URL; the CI result (green, red with the
    failing check, or timed out); each finding and how it was handled (fixed with its commit, discarded
    with its reason, escalated); and anything that needs a human decision.
 6. **Tell your spawner when you are ready to discharge.** You are ready when all of these hold: the