@awebai/oats 0.22.16 → 0.22.19

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

@@ -0,0 +1,25 @@
+# OATS v0.22.17
+
+Two corrections found by installed acceptance of 0.22.16, nothing else.
+
+## oats.okf 1.6.1
+
+A provider view larger than one pipe buffer arrived cut at 65536 bytes
+with exit 0 when the kernel's operation runner or a Desktop read it: the
+provider wrote its envelope and exited at once, and on macOS Node writes
+to a pipe asynchronously. Every answer now leaves the provider whole
+before it exits. The catalog pins v1.6.1; scopes on 1.6.0 keep working
+for small views until their owners run
+`oats update oats.okf --to v1.6.1 --dir <scope>` and re-trust. The
+kernel's runner is unchanged; the regression covers a 128 KiB view
+through an actual pipe, directly and through `oats operation run`, and a
+300 KiB view from any provider.
+
+## Desktop
+
+Workspaces added at runtime survive an app restart: the opened set is
+persisted on its own (not the recent-suggestion store), restored and
+re-validated at startup with absent paths skipped and aliases collapsed,
+and a backend is reused only when it covers every restored workspace. A
+failed persistence write keeps the previous set and reports the failed
+add.

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

@@ -0,0 +1,101 @@
+# OATS v0.22.18
+
+Choose how an agent runs without replacing its home. Desktop offers
+**Start…** for stopped instances and **Restart with…** for running
+instances, with harness, model, permissions and named launch
+configurations. The kernel records what each home was started with and
+starts it again the same way.
+
+## Named launch configurations
+
+Define a reusable configuration in a scope's `oats-config.yaml`, or use
+**Manage launch configurations** in Desktop. A configuration chooses `pi`,
+`claude` or `codex`, an optional executable or wrapper, literal arguments,
+environment values or references, a default model and the shared `yolo`
+setting.
+
+```yaml
+launch-configs:
+  codex-personal:
+    runtime: codex
+    args: ["--profile", "personal"]
+    yolo: true
+```
+
+Arguments are passed literally; native configuration files and account
+settings stay under the harness's control. For environment credentials use
+a reference such as `API_KEY: {fromEnv: PERSONAL_KEY}`: the execution host
+resolves it each time the agent starts. The recorded recipe, receipts,
+previews, roster answers and spawn answers do not expose the value (the
+launch itself and its transport necessarily use it). A configuration cannot name the kernel's own launch
+environment or override environment a capability owns.
+
+An existing instance keeps its recorded launch configuration even if the
+scope's definition changes or disappears. Select a named configuration
+explicitly to apply its current definition. Changing only the model or
+permissions keeps the rest of the recorded invocation; choosing a harness
+without a configuration starts that harness's defaults, with no model
+carried across harnesses.
+
+`oats launch-config list | set | remove | preview` author and inspect
+configurations; `oats spawn --launch-config` starts a new instance under
+one; a soul may name a default (`launch-config:` in soul.yaml,
+`oats soul set --launch-config`).
+
+## Restart in place
+
+`oats session start` with a selection validates the requested launch
+(recipe, executable, references, capability preparation, runtime packages)
+and starts a stopped instance; it never stops a running harness. Only
+`oats session restart` does: it runs the same checks first, then sends
+SIGTERM to the harness under the pane's launcher and waits a bounded time
+for it to end; it does not escalate to a forced kill and refuses to launch
+a second harness if it cannot confirm the first has stopped, reporting what
+was signalled and observed. The instance keeps its home, identity, work and
+notes; OATS does not transfer a native conversation between harnesses.
+Save work before restarting.
+
+Capabilities take part through what was captured for the home: a capability
+may declare a `launch` hook to prepare another harness (under the settings
+captured at spawn, with the scope's current manifest and trust); a
+capability that contributed harness-specific arguments and cannot prepare
+the new one refuses the switch. Homes that predate launch recipes are
+converted narrowly from their recorded command when a selection asks for
+it; unrecognized arguments are refused by name.
+
+One limitation, stated rather than hidden: a runtime-package requirement is
+verified with the package manager's controlled list command under the
+launch's environment and executable, which cannot carry a configuration's
+arguments. When such a requirement applies and the configuration passes
+arguments, the launch is not reported verified (`E_LAUNCH_PROBE_UNSUPPORTED`):
+put native configuration a required package must see in a wrapper
+executable or the environment.
+
+```sh
+oats launch-config list --dir /path/to/team
+oats launch-config preview --home /path/to/instance --runtime codex --json
+oats session restart --home /path/to/instance --launch-config codex-personal
+```
+
+Local tmux and Herdr sessions use the same lifecycle operations. Registered
+servers support configuration management and start/restart choices through
+their installed OATS CLI (probe tokens `launch-config`, `session-restart`);
+existing remote homes keep their saved route, and an older kernel is
+refused after the compatibility probe, before any mutation or stop.
+
+## Desktop fixes
+
+Tabs from other workspaces stay hidden. Instance action menus are positioned
+correctly when opened and remain stable through roster refreshes. Failed
+launch preflight checks are shown in the invocation preview, and an accepted
+launch is not presented as a running agent until the terminal is observed.
+
+## Also in this release
+
+- Capture lock (source only; the installed capture service is unchanged):
+  nonce-checked ownership, cleanup of a failed initialization that respects
+  a replacement, release outcomes reported as observed, and the privacy
+  loader's exit no longer leaves a lock behind.
+- A design proposal for managing agents from an iPhone over Tailscale
+  (docs/design/2026-09-07-mobile-agent-management-proposal.md); no
+  implementation ships.

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

@@ -0,0 +1,115 @@
+# OATS v0.22.19
+
+Version 0.22.18 was tagged but never published: its hosted gate failed on
+four tests that pass on macOS and fail on Linux (two launch tests calling
+the kernel directly resolved the real harness binary on the test process
+PATH, one launch test spawned zsh, which the runner does not install, and
+one capture-lock test where Linux reused the inode of an unlinked
+directory). The tag stays fixed and unpublished. This release carries the
+same content with the corrections below.
+
+Choose how an agent runs without replacing its home. Desktop offers
+**Start…** for stopped instances and **Restart with…** for running
+instances, with harness, model, permissions and named launch
+configurations. The kernel records what each home was started with and
+starts it again the same way.
+
+## Named launch configurations
+
+Define a reusable configuration in a scope's `oats-config.yaml`, or use
+**Manage launch configurations** in Desktop. A configuration chooses `pi`,
+`claude` or `codex`, an optional executable or wrapper, literal arguments,
+environment values or references, a default model and the shared `yolo`
+setting.
+
+```yaml
+launch-configs:
+  codex-personal:
+    runtime: codex
+    args: ["--profile", "personal"]
+    yolo: true
+```
+
+Arguments are passed literally; native configuration files and account
+settings stay under the harness's control. For environment credentials use
+a reference such as `API_KEY: {fromEnv: PERSONAL_KEY}`: the execution host
+resolves it each time the agent starts. The recorded recipe, receipts,
+previews, roster answers and spawn answers do not expose the value (the
+launch itself and its transport necessarily use it). A configuration cannot name the kernel's own launch
+environment or override environment a capability owns.
+
+An existing instance keeps its recorded launch configuration even if the
+scope's definition changes or disappears. Select a named configuration
+explicitly to apply its current definition. Changing only the model or
+permissions keeps the rest of the recorded invocation; choosing a harness
+without a configuration starts that harness's defaults, with no model
+carried across harnesses.
+
+`oats launch-config list | set | remove | preview` author and inspect
+configurations; `oats spawn --launch-config` starts a new instance under
+one; a soul may name a default (`launch-config:` in soul.yaml,
+`oats soul set --launch-config`).
+
+## Restart in place
+
+`oats session start` with a selection validates the requested launch
+(recipe, executable, references, capability preparation, runtime packages)
+and starts a stopped instance; it never stops a running harness. Only
+`oats session restart` does: it runs the same checks first, then sends
+SIGTERM to the harness under the pane's launcher and waits a bounded time
+for it to end; it does not escalate to a forced kill and refuses to launch
+a second harness if it cannot confirm the first has stopped, reporting what
+was signalled and observed. The instance keeps its home, identity, work and
+notes; OATS does not transfer a native conversation between harnesses.
+Save work before restarting.
+
+Capabilities take part through what was captured for the home: a capability
+may declare a `launch` hook to prepare another harness (under the settings
+captured at spawn, with the scope's current manifest and trust); a
+capability that contributed harness-specific arguments and cannot prepare
+the new one refuses the switch. Homes that predate launch recipes are
+converted narrowly from their recorded command when a selection asks for
+it; unrecognized arguments are refused by name.
+
+One limitation, stated rather than hidden: a runtime-package requirement is
+verified with the package manager's controlled list command under the
+launch's environment and executable, which cannot carry a configuration's
+arguments. When such a requirement applies and the configuration passes
+arguments, the launch is not reported verified (`E_LAUNCH_PROBE_UNSUPPORTED`):
+put native configuration a required package must see in a wrapper
+executable or the environment.
+
+```sh
+oats launch-config list --dir /path/to/team
+oats launch-config preview --home /path/to/instance --runtime codex --json
+oats session restart --home /path/to/instance --launch-config codex-personal
+```
+
+Local tmux and Herdr sessions use the same lifecycle operations. Registered
+servers support configuration management and start/restart choices through
+their installed OATS CLI (probe tokens `launch-config`, `session-restart`);
+existing remote homes keep their saved route, and an older kernel is
+refused after the compatibility probe, before any mutation or stop.
+
+## Desktop fixes
+
+Tabs from other workspaces stay hidden. Instance action menus are positioned
+correctly when opened and remain stable through roster refreshes. Failed
+launch preflight checks are shown in the invocation preview, and an accepted
+launch is not presented as a running agent until the terminal is observed.
+
+## Also in this release
+
+- Capture lock (source only; the installed capture service is unchanged):
+  nonce-checked ownership, cleanup of a failed initialization that respects
+  a replacement, release outcomes reported as observed, and the privacy
+  loader's exit no longer leaves a lock behind. The initializing directory
+  is held open until its owner record is written or its cleanup finishes,
+  preventing its inode from being reused during cleanup; a replacement
+  directory is left alone.
+- Test fixtures: the launch tests resolve their fake harness binaries on the
+  test process PATH and exercise only the shells the host installs; no
+  kernel change.
+- A design proposal for managing agents from an iPhone over Tailscale
+  (docs/design/2026-09-07-mobile-agent-management-proposal.md); no
+  implementation ships.

package/docs/souls-and-instances.md

@@ -28,6 +28,7 @@ A soul is durable and committed. It is the part you review, improve, and keep.
 | `work` | `worktree` or `checkout`. |
 | `runtime` | `pi` or `claude` — the harness new instances launch on; a spawn can override with `--runtime`. For `claude`, the binary is `claude` unless a local-only `oats-claude-config` file (closest one walking up from the repo; one line naming the binary, e.g. `claude-personal`) selects another — a personal machine preference for account selection, never committed. With the aweb messaging integration active, claude sessions get the `aweb-channel` plugin wired at spawn for real-time push events. |
 | `model` | Optional default model — a `provider/id[:thinking]` pattern or a comma-separated preference list (`github-copilot/x:high, anthropic/x:high`); at spawn the first entry whose provider/model is available wins (pi models probed via `pi --list-models`). For the `claude` runtime the value is translated to what the claude CLI accepts: `anthropic/<id>[:thinking]` becomes the bare `<id>`, aliases and bare `claude-*` ids pass through, other providers' entries are dropped, and nothing usable falls back to claude's own default. A spawn can override it. |
+| `launch-config` | Optional default launch configuration for new instances (a name declared under `launch-configs:` in the scope's config; see docs/design/launch-configurations.md). `oats spawn --launch-config <name|none>` overrides it; `oats soul set --launch-config <name>` / `--no-launch-config` edit it. |
 
 A soul is model-agnostic as an artifact. Its files are plain operating docs,
 skills, and knowledge. `model` is only the default choice for new instances,