[Meta] Run hosted channels in the cloud with local workspaces #13

Run channels in team-deployed cloud cells while repositories, lanes, shells, browser and desktop tools stay on the team's workspace machines. A hosted channel is where the channel and durable pi state run; this work does not move tool execution into the cloud. Ace does not operate a hosting service, and the tailnet remains the sole authority for team membership and collaboration access.

Existing implementation and evidence

• Hosted channel service, Durable Object storage, workspace transport and ace new --hosted <url> landed in 3ff0b97. 1a2e1f3 fixed the initial workspace connection.
• The directory and deployment instructions already exist. The current configured directory was reachable in the October 7 read-only audit; its listing contained no hosted channels. That observation does not establish whether a channel service has been deployed elsewhere.
• PR #85 records real model/tool execution and completed-run replay through the workspace adapter in a local Workers/Durable Objects runtime. It does not certify deployed Cloudflare behavior, interruption during a tool, or a second physical machine.
• Initial deployed qualification on one physical workspace machine is recorded in #176: real model/local tools, persistence, reset recovery, clean disconnect/reconnect and idle behavior passed with the fix now merged in fix(channel): keep hosted runs resident while busy #186 (80c67ca). Another actual client/teammate machine and physical sleep/network-partition recovery remain open.

Pilot blockers

• Hosted idle hibernation interrupts active tools while local shell keeps running #183 — Idle hibernation interrupts active hosted tools while their original local shell keeps running. Fixed in fix(channel): keep hosted runs resident while busy #186, merged as 80c67ca on October 7 after CI passed; Hosted idle hibernation interrupts active tools while local shell keeps running #183 is closed. Deployed regressions passed for quiet completion, delayed/ordinary Kill, Stop, later idle hibernation and genuine-reset recovery.

Delivered movement slice

• Initial Move channels between local and hosted with the same workspace #181 slice — merged in feat: move idle channels between a host and a hosting service #194 (11e4f405). One idle owned channel can move local → hosted → local through the CLI and a Move to: context-menu section over applicable known hosted services or the same local workspace. Stable identity and complete pi state include work added while hosted; the workspace and lane paths stay in place. The bounded representation is pi schema 1, up to 32 MiB, with busy refusal and exclusive cutover. Real roundtrip/menu evidence passed, as did PR and main CI. There are no automatic backups or dependency on Back up and restore hosted channels #178. Move channels between local and hosted with the same workspace #181 remains open for backup/recovery, live-run movement, interruption/retry hardening, broader portability and broader app discovery/setup/preferences; this does not add a setup wizard or other-workspace moves.

Hosted-channel milestones, in priority order

• 1. Verify a deployed hosted channel with a local workspace #176 — Deployed pilot: dedicated real services, a real model and local shell, persistence across upgrade, workspace disconnect/reconnect, another actual client machine, interrupted model/tool work, Stop/Kill cleanup and observed idle behavior.
• 2. Create hosted channels and show workspace status in the app #177 — App creation and workspace status: configure/select the team's service, create inside a project, and show hosted location plus workspace connectivity.
• 3. Back up and restore hosted channels #178 — Backup and restore: document and exercise recovery against an existing hosted channel, using provider-native recovery where it meets the need; define portability separately where required.
• 4. Keep hosted channels available when their workspace is offline #179 — Lifecycle and discovery: keep the hosted channel reachable and manageable independently of its workspace connection, with consistent identity/location and explicit tool availability.
• 5. Let hosted agents discover and message team channels #180 — Hosted outbound messaging: discover team channels, deliver attributed messages/invocations, reply by stable identity, and verify deduplication/reconnect and destination sharing policy.

These are implementation priorities, not a claim that each item depends on every item above it. Fix focused defects exposed by the pilot and attach their evidence before treating deployed operation as qualified.

Optional later milestones

• Reach hosted channels from a browser without a host gateway #182 — Browser access without a reachable host gateway, using per-person identity tied to tailnet authority. This preserves the original browser-access request without adding Ace accounts or putting a shared host secret in a browser.

Related work, not prerequisites for the pilot

Execution-host handoff #49, cross-gateway/team terminals #11, directory push #14, project identity acceptance #15, local peer-agent messaging #57/#160, lobbies #17 and real-phone qualification #18 have their own scopes. #10 is baseline two-host collaboration and does not establish hosted-channel acceptance. Owners already have terminal access through their workspace host; general forwarding/teammate terminal rights remain #11.

Keep the channel runtime-neutral, protocol types shared and durable state in pi-durable. Existing channels are permanent data; stored-format changes need versioned migrations verified against a backup. Preserve the app's project-first flow and the distinction between cell availability and workspace execution.

Tracked by #58; the deployed pilot and findings also link from dogfooding #5. Original scope: CLI creation already existed, while app creation, outbound messaging and browser access remained. Migrated from TODO.md — During dogfooding.