Exoclaw + Task Scheduling + Adapters

[61cygni]

Adds Exoclaw, a long-running local agent example built on the TypeScript harness, with support for scheduled sandbox tasks and host-managed external adapters. I tried as much as possible to keep changes to examples/exoclaw/. PR is relatively large because I had to add task support and adapter support, modify sandbox support for different lifespan and scoping.

• Adds Exoclaw setup, prompts, docs, and launcher script for running the REPL, scheduler runner, and adapter runner together.
• Adds scheduled task storage/runtime support so Exoclaw can create recurring sandbox tasks and wake the conversation with run results.
• Adds the adapter runtime and tools for long-running IRC, WhatsApp, and Signal workers, including inbound wakeups and explicit outbound replies.

Manually tested fresh Exoclaw setup with Signal, WhatsApp, IRC, scheduled tasks, and adapter replies

[Alexsun1one]

findings from testing origin/adapters yesterday. items below still reproduce on the PR head — they're worker.ts / harness-layer behavior not the rust restructure. 4 inline notes anchored to specific lines, 3 here without a clean single-line anchor.

--env-file-if-exists vars dont reach worker subprocesses

crates/cli/src/env.rs::CliEnvironment::load parses .env into a HashMap<String, String> and returns via into_vars() without calling std::env::set_var. when the adapter runtime spawns workers via Command::new(...).env(...), the child only sees EXO_* + secretEnv + parent shell env. .env-only vars are invisible to the worker.

repro: a feishu adapter reading process.env.FEISHU_APP_ID died with Feishu adapter needs an app id even though the var was in .env and exo was launched with --env-file-if-exists .env.

fix: call std::env::set_var on each loaded entry, or document .env as exo-internal and require workers to use secretEnv. current behavior is a footgun — .env looks like standard dotenv but isnt.

apple-container default sandbox backend fails with generic ENOENT on macs without it

conversation send returns Error: No such file or directory (os error 2) within 2s on fresh macs because the default backend is apple-container and the container CLI isnt installed.

fix: detect container on PATH and fall back to local-process with a warning, or replace the ENOENT with a backend-specific error naming the missing binary.

workaround: --sandbox-backend local-process.

lingua TS materialization breaks the OpenAI tool_calls adjacency contract

when an assistant turn contains N tool_calls, lingua's TS-side materialization fails to keep the N corresponding tool messages adjacent. the follow-up chat-completions request 400s on providers that enforce this (deepseek and others).

repro: 3 disable_adapter calls in one assistant turn, the follow-up 400s. lingua-ts bug surfacing in exo's turn loop.

[Alexsun1one]

two retractions on my earlier review (#4374207281), on re-read:

re: .env not reaching workers (review body) - on second thought .env not reaching workers is probably by design, workers should use secretEnv explicitly. the gap is the cli flag name doesnt hint at this. so its a doc issue not a bug. ignore the original framing.

re: lingua tool_calls adjacency (review body) - actually this one is out of scope. lingua materialization is a lingua bug, just surfaces in exo's turn loop. should be in the lingua repo not here. sorry for the noise.

[Alexsun1one]

follow-up to my earlier review. one substrate-level item that didnt fit inline, plus a store-layer concurrency pattern i noticed reading the rust side. 5 inline notes anchored to specific lines.

turn-stale spec contradicts the scheduler/adapter wakeup paths

crates/exoharness/src/basic.rs::ensure_conversation_head enforces strict turn-owned head: while a turn is in flight, any external write to the same conversation makes the turn unresumable. the test stale_turn_artifact_write_reports_unresumable_turn at crates/exoharness/src/basic_tests.rs:178 confirms this is intended. it deliberately writes an artifact from outside the turn and asserts the in-flight turn fails with turn is stale and cannot be resumed.

but this PR has multiple writers to the same conversation by design:

• crates/executor/src/conversation_wakeup.rs::send_conversation_wakeup calls conversation.send(SendRequest { input: vec![user_message], session_id: None }) on each scheduled task fire. that opens a new session and advances head.
• examples/exoclaw/adapter-architecture.md second paragraph: "A scheduled task ... writes output, wakes the conversation, and exits."
• the mermaid diagram in the same file shows both scheduler -> convo and runtime -> wakeup -> convo.

so scheduler-runner + adapter-runtime are designed as legitimate writers, but any concurrent user turn on that conversation fails. concrete from yesterday on origin/adapters (same commit as this PR head 599aed25):

• user turn started 04:57:18.926Z
• every-1m scheduler task fired in the gap, advanced head to 04:57:20.788Z, 1.8s
• user turn next add_events failed with turn is stale and cannot be resumed: conversation head advanced outside this turn

any user turn that takes more than the cron tick interval is unsafe on a conversation that also has scheduled tasks or active adapters. with a single @every 1m task, any user turn longer than ~60s is at risk. with @every 10s (or an active adapter relaying inbound messages), the risk window shrinks to seconds.

the docs say a scheduled task "wakes the conversation" but the conversation has a single-writer invariant. these cant both hold under load.

i noticed you flagged the same risk in 3 inline comments on crates/executor/src/adapter/runtime.rs (L88, L230, L268). but the runtime.rs fix path defers to send_conversation_wakeup, which does exactly the head-advance that triggers the invariant. so those comments are right about the danger but the implementation still walks into it on the wakeup path.

two substrate-level fix shapes:

1. serialize: scheduler/adapter wakeups queue and wait for the in-flight turn to finish before opening a new session on the same conversation. preserves the strict turn-owned head invariant, eliminates user-visible stale errors.
2. partition: scheduler/adapter writes land on a separate (system-scoped) conversation, and the user conversation only consumes wakeup signals via a queue rather than as direct conversation.send writes. strict head stays correct on user conversations.

store-layer concurrency, smaller theme

the file-based stores added in this PR (AdapterStore, SchedulerStore) do read-modify-write without flock or atomic rename. with scheduler-runner + adapter-runtime + the main REPL all reaching into $root/.exo/adapters/*.json or $root/.exo/scheduled-tasks/tasks/*.json, two near-simultaneous writes can lose updates. inline notes on the specific call sites plus a related check-then-create race on ensure_conversation_sandbox and a config-path footgun on the adapter worker commands.

if either turn-stale direction works, i can prototype.

[ankrgyl]

generally lgtm