@awebai/oats 0.35.3 → 0.35.5

package/docs/execution-targets.md

@@ -170,6 +170,12 @@ The task's text never travels on a command line, where any local user could
 read it in the process list:
 
 - pi and Claude Code get `@TASK.md`, which each harness reads as the file.
+  pi sends it as the session's first prompt and refuses it if another
+  extension's turn (the @awebai/pi welcome) is running or starts while it is
+  being sent. The pi bridge (`@awebai/oats-pi`) holds it on pi's own path
+  until no turn is active, so it runs exactly once, unaltered; a pi
+  deployment without the bridge can sit idle with no task. The exception is
+  in the bridge's [README](../packages/pi/README.md).
 - Codex gets a fixed pointer to the file and reads it with a tool.
 - A home whose recorded command still hands over `"$(cat TASK.md)"` starts
   with its harness's safe prompt instead, and the command is saved that way.

package/docs/release-notes/v0.35.4.md

@@ -0,0 +1,31 @@
+# OATS 0.35.4
+
+## Fixed
+
+- **A Desktop workspace never waits silently on "Reading the deployment…",
+  and a folder that is not a deployment never drops the open ones**
+  (awebai/oats#461). With three or more deployments open, the third and later
+  ones were never read: the server started every deployment's reads at once
+  past the observer's two-read bound, and kept the refused ones on their
+  first "pending" forever. That is also why an empty deployment (no souls,
+  no instances) listed third never loaded; an empty answer is an
+  observation, shown as no instances. Deployments are now read two at a
+  time, each one every cycle. A launch from a folder that is not a
+  deployment (a parent such as `~/Agents` as the cwd or `--dir`), at a
+  moment when no saved deployment could be opened, saved that folder as the
+  whole open set; only deployments are saved now, and the saved set is
+  never replaced with nothing. Add workspace → Browse… on a folder without
+  `oats-local.yaml` is refused with an explanation and lists the
+  deployments in it (or the one it is inside) as one-click adds; setting up
+  a new deployment there is a secondary action. A workspace the Desktop's
+  server does not serve, or does not answer for within 45 s, shows an
+  error naming it, with Retry and Re-add workspace. Behaviour change in
+  the Desktop's own server: an explicit `?ws=` it does not serve (any id)
+  on `/api/panel` and `/api/agents` is now 404 `E_WORKSPACE_NOT_SERVED`
+  instead of the first workspace's answer.
+
+- **After upgrading from a version before 0.35.3, restart once a tmux
+  server that a Finder-launched Desktop started earlier** (awebai/oats#468).
+  Such a server keeps launchd's PATH for the sessions it starts. Restart it once to pick up the
+  new PATH. Restarting it ends the sessions in it, so do it when no instance
+  is running.

package/docs/release-notes/v0.35.5.md

@@ -0,0 +1,34 @@
+# OATS 0.35.5
+
+## Fixed
+
+- **Adding a workspace never drops a saved deployment that is missing at
+  that moment** (awebai/oats#472). A saved deployment on a volume that was
+  not mounted yet stayed saved at launch, but adding another workspace then
+  saved only the deployments that validated, and it was gone for good. The
+  same happened when the Desktop was launched on a new deployment. Now the
+  server is still started only with the deployments that are there, while
+  `workspace-open.json` keeps every saved one; the next launch serves it again
+  once it is back. Only an explicit remove drops a saved deployment (the
+  Desktop has no remove action yet).
+
+- **A pi instance launched with a task runs it, once, after the @awebai/pi
+  welcome** (awebai/oats#469). pi's interactive mode sends `@TASK.md` as the
+  session's first prompt with no streamingBehavior (pi 0.85.1
+  `interactive-mode.js:816`), so pi refused it ("Agent is already
+  processing…") when the @awebai/pi welcome turn was running or started
+  while the task was being sent, leaving the instance idle with no task.
+  With the bridge, the opening task now runs exactly once, after any turn
+  another extension starts, exactly as pi's input processing made it: the
+  bridge holds it on pi's own path until no turn is active, and never
+  sends, re-sends or alters a message. One exception remains: an extension
+  loaded behind the bridge that starts a turn (or awaits I/O while one
+  starts) inside its own input or before_agent_start handling of the
+  opening prompt can still make pi refuse the task, as before. The bridge
+  with @awebai/pi has no such handler and is fully covered. Tested against
+  pi 0.85.1; pi before 0.80.4, which has no `agent_settled` event, is
+  covered by a model of its behaviour only. The fix ships in
+  `@awebai/oats-pi` 0.35.5: a pi deployment must update the bridge to get it
+  (`oats update` updates an installed bridge; without one, `pi install
+  npm:@awebai/oats-pi`), then restart its pi sessions. The kernel alone does
+  not fix it. Claude and Codex launches are unchanged.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@awebai/oats",
-  "version": "0.35.3",
+  "version": "0.35.5",
   "description": "OATS (Open Agent Team Specification) — durable souls, disposable instances, targetable capability packages, and the runtime-neutral oats CLI/kernel.",
   "keywords": [
     "agents",