* feat(w8): teammates wake a team workspace from the phone (team route long-poll wake, same access/billing/cap; owner route stays the fallback)
* test(w8): team wake refuses an admin on a private row, never returns the endpoint; phone never falls back on 401/403
* fix(w8): phone forgets cloud workspaces that are gone (missing from the complete registry list, or wake says not_found); never on transient errors
* fix(w8): prune only on the registry's own not_found for that workspace (lists are capped and skip hidden rows; status 404s are owner-only); restore a link whose host removal failed
* perf(w8): host prune is single-flight and remembers a confirmed-present workspace for 5 minutes
terminal.send text+Enter to a daemon-backed shell always waited the 500 ms agent paste
settle: the daemon's shell-foreground answer is lifecycle ownership, which is only proven
after a recovery or full-screen exit, never for a fresh or plain-command shell. On Linux
the idle-prompt claim now also accepts the shell's own /proc stat (process group is the
terminal foreground group, i.e. ps '+'), scoped to the target PTY; other hosts unchanged.
The acceptance wake split uses one persistent paired connection per wake (the desktop's
transport) by default; transport=cli keeps the per-call socket the CLI dials.
- auth.signed-out-create (D-1/D-4), proj.cloud-name (D-3), life.delete-unconfirmed (D-2,
team switch -> not_found), life.delete-after-oob-destroy; life.destroy now requires destroyed
and records the asleep-delete refusal
- starts signed out (dev auth) with no sign-in-then-relaunch workaround; mock keychain so a
fresh dev app identity does not block on a macOS Keychain prompt
- cloud vs local rows disambiguated by badge (Move to this computer reuses the name)
- upload/download helpers for staging and collecting a run on a paired Orca environment
- Forward tunnel early data (workspace-ports.forward-tunnel.early-data.v1). It is negotiated on
each attach: the client asks for it and the host echoes it in `ready`. The client sends up to
64 KiB, its receive credit and a half-close right behind Open. The host holds those bytes
until the destination connects, writes them before Opened, and drops them if the connect
fails. Old hosts and old clients keep the strict ordering, and the browser tunnel is unchanged.
New-connection HTTP GET through a forward on a real VM: p50 127 -> 64 ms, p95 138 -> 70 ms.
- SSH and port-forward idle-sleep activity now use ForwardUseMeter instead of the
2 KiB/min byte threshold. An idle VS Code remote window sends 2.3-3.0 KB/min of
keepalives, so it kept the VM awake forever. The meter counts packet bursts and
payload-sized packets instead; the unit tests replay traces recorded on the real VM.
- Downloads: files.stat now goes out with the first pages instead of one round trip ahead
of them.
On every Orca Cloud start and wake, orcad ran its disposable startup preflight child. That child is a
second full load of the 15 MB bundle plus the SQLite and node-pty probes, and it ran before main().
The cloud slot could never be qualified: qualification needed the managed-activation env, and the
marker lives in the slot directory, which is root-owned in the image. In-VM profiles showed the main
thread idle for about 580 ms waiting on that child.
- ORCA_ORCAD_STARTUP_QUALIFICATION_DIR names a writable directory for the startup-qualified marker
and opts the slot into qualification. The key is unchanged: artifact version, file stat identity,
runtime, ABI, kernel and launch env. It survives a stop and resume: inode, mtime and ctime are
identical after resume, and the first launch after resume skipped the preflight.
- The image creates /opt/orca/startup-qualification. The provisioning smoke run records the marker,
and orca-sandbox-start passes the env.
- Agent-state-rules live updates and speech-model warm-up now start after the ready line instead of
before it.
- Once the ready line is published, a terminal list warms the terminal path (worktree catalog,
daemon inventory) before the reconnecting desktop asks for it.
Real 4-vCPU VMs, readyMs median of 5: idle 1475 -> 903 ms; with 3 busy cores 1921 -> 1200 ms.
- remote-desktop guest setup tolerates a destroyed/partial guest on its first load read
(13 browser-manager suites)
- worktree Sleep handlers import the offline seam, not the whole offline service (6 worktrees ipc suites)
- ordinary http links open synchronously; only a runtime OAuth loopback URL waits for its relay
(terminal link and markdown link-routing suites)
- recipe options load through a promise so a missing VM bridge is a handled failure
Environment snapshots are built on a golden, so workspaces from them kept that golden's orcad and VM
scripts after rotation (e.g. no files.archiveStart). Each 5-minute tick, after the golden tick, every
environment whose active build's base_snapshot_id is not the current golden gets a background rebuild
of the active build's config (only the base image changes), attributed to system:golden-refresh and
billed like any build. The active build serves until the new one succeeds, then the newest-success
activation swaps it atomically; the old snapshot stays for rollback; a failed rebuild keeps the active
build, shows the usual failed build, and is not retried for that golden. At most 2 starts per tick
and 3 builds in flight overall. startBuild accepts an explicit config for this.
The Worker-started source build used the VM scripts, provision script and manifest pins embedded in
the Worker that started it, so a golden built from a newer commit could miss that commit's new VM
scripts (seen live: snap_HTsU from 19f900e has #122's orcad but not orca-desktop-proxy or
orca-desktop-page.js). source-build.sh now sources image/commit-provision-env.mjs from the fetched
checkout (no dependencies; mirrors provisionEnv, enforced by a test), so the image ships exactly that
commit. Tests also require every image/vm file to be a declared VM script and installed by provision.
Neil
Neil