pi-onlyne 0.8.0 → 0.9.1

package/README.md

@@ -189,14 +189,14 @@ The extension also supports `.onlyne/channels/loopback/in` when FIFO IO is enabl
 
 ## Swarm mode
 
-Swarm mode lets `onlyne-swarm` own task routing for a generated agent workspace. Enable it in `.onlyne/config.toml`:
+Swarm mode lets `onlyne-swarm >= 0.5.0` own task routing for a generated agent workspace. `pi-onlyne 0.9.1` uses the scheduler's `delivery: scheduler` header for task claims and binds a scheduler-created pane to its `ONLYNE_SWARM_TASK`, so these versions upgrade together. Enable it in `.onlyne/config.toml`:
 
 ```toml
 [swarm]
 enabled = true
 ```
 
-A swarm Pi session subscribes to loopback events, reports `swarm_ready`, accepts one hop atomically, spawns continuations with `swarm_send` (fire-and-forget), and writes `swarm_complete` (done signal). Scheduler then sends a header-only recycle control wire; pi-onlyne intercepts it before model delivery, sends `swarm_recycled`, stops the watch, clears the slot, and self-exits. `swarm_quit` sends the same ack with `quit:<reason>` then self-exits, so the scheduler records failed immediately. Downstream results travel through files and the ledger; nothing waits.
+A swarm Pi session subscribes to loopback events, reports `swarm_ready`, accepts one scheduler-delivered hop atomically, spawns continuations with `swarm_send` (fire-and-forget), and writes `swarm_complete` (done signal). A raw `swarm_send` relay carries no `delivery` header and only creates the scheduler task row; the scheduler's second delivery adds `delivery: scheduler`, which pi-onlyne uses as the claim gate. This keeps arbitrary role prose out of transport authentication. Scheduler then sends a header-only recycle control wire; pi-onlyne intercepts it before model delivery, sends `swarm_recycled`, stops the watch, clears the slot, and self-exits. `swarm_quit` sends the same ack with `quit:<reason>` then self-exits, so the scheduler records failed immediately. Downstream results travel through files and the ledger; nothing waits.
 
 For automatic startup in a generated workspace, add `.pi/onlyne.json`:
 

package/SPEC.md

@@ -84,14 +84,27 @@ One session sees one toolset. The surface is chosen at `session_start` from
 - When swarm is on, generic in/out auto-handling is disabled: the scheduler owns
   input/output. Only loopback messages carrying a `---swarm` body header enter
   the session, via the `followUp` task queue.
-- Session model: one session carries exactly one hop, no exceptions. A new
-  header claims the slot; any further header while claimed is ignored
-  (the scheduler always opens a new session, so this guard never fires
-  on the normal path). No waiting, no callbacks, no parent bookkeeping.
+- Session model: one session carries exactly one scheduler-delivered hop. A
+  `delivery: scheduler` header field claims the slot; raw `swarm_send` relay
+  wires and out wires omit it and never claim. Any further delivered header
+  while claimed is ignored (the scheduler always opens a new session, so this
+  guard never fires on the normal path). No waiting, no callbacks, no parent
+  bookkeeping.
 - Startup handshake: swarm watch sends the `swarm_ready` op
   (`{workspace, terminal_handle}`) so the scheduler can match a pending task.
   `ONLYNE_SWARM_TASK` env and `ORCA_TERMINAL_HANDLE`/`ONLYNE_TERMINAL_HANDLE`
-  provide fallback correlation.
+  provide fallback correlation. **`ONLYNE_SWARM_TASK` is a hard binding:** a
+  newly created terminal may replay history only for that exact task id. If
+  its FIFO delivery has not reached history yet, the session waits for the
+  live inbound event; it never claims a newest/old workspace-local task.
+  Sessions with no env task (manual ready pool) retain newest-unclosed
+  fallback replay.
+- Hop activity (v0.9.1, R4): `agent_start` with a live claimed task sends
+  `swarm_busy` (`{workspace, terminal_handle, task_id}`); `agent_end` with
+  the turn ended and no out sends `swarm_idle` (same fields plus
+  `pending_exit`, mirroring whether the hop still awaits `swarm_complete`).
+  Both are fire-and-forget over the existing swarm event channel; the
+  scheduler treats missing rows as race residue and drives its own TTLs.
 - Tools: `swarm_complete({text})` writes the out message carrying this hop's
   header (the scheduler's done signal). Scheduler sends a `---swarm-ctl`
   recycle wire; pi-onlyne intercepts it, sends `swarm_recycled`, stops the

package/dist/index.d.ts

@@ -1,2 +1,27 @@
 import { type ExtensionAPI } from "@earendil-works/pi-coding-agent";
+import { type Workspace } from "./workspace.js";
+import { type SwarmReportKind } from "./swarm.js";
+import { type StateContext } from "./session.js";
+/** Swarm task slot: one session carries exactly one hop. No waiting, no callbacks. */
+interface SwarmTask {
+    taskId: string;
+    from: string;
+    transferSendTo: string;
+    attempt: number;
+}
 export default function onlyne(pi: ExtensionAPI): void;
+/** Test seam: drive the lifecycle-report wiring against a stub daemon socket.
+ * No live pi session and no real daemon are involved; the seam exposes the
+ * same closures the hooks call. Mirrors `__swarmSlotForTest`. */
+export declare function __swarmReportForTest(): {
+    setWorkspace: (ws: Workspace | null) => void;
+    beginSession: (appendEntry: StateContext["appendEntry"], taskId: string) => {
+        generation: number;
+        seq: number;
+    };
+    setTask: (task?: SwarmTask) => void;
+    reportTaskId: () => string | null;
+    emit: (kind: SwarmReportKind) => Promise<boolean>;
+    beat: () => void;
+};
+export {};