opencode serve: lifecycle logging + configurable launcher (Ollama)

[adamw]

Closes #10 - @JD557 let me know if this would work for you

Two related improvements to how orca runs the shared opencode serve process.

1. Log server start/stop to the run trace

The shared server started and stopped silently — the raw spawn: line shows
--port 0 (not the bound port) and there was no teardown line, so a long-lived
process was invisible in the trace. Now logs the resolved listening URL on start
and a stopping line at teardown (DEBUG → /tmp/orca-*.log).

This came out of issue #10, where a user was confused that orca had silently
started its own opencode server.

2. Configurable serve launcher (OpencodeLauncher)

The opencode binary was hardcoded, so there was no way to start the server via
ollama launch opencode — which injects Ollama's generated provider config
(OPENCODE_CONFIG_CONTENT) and is the zero-config path for local Ollama models
(issue #10). Hand-writing that provider config (npm package, baseURL, exact model
ids, raised num_ctx) is fiddly, so the launcher is the genuine easy path.

• New public OpencodeLauncher: default (plain opencode), ollama(model),
  and apply(Seq) for any wrapper. Threaded flow(opencodeLauncher = …) → DefaultFlowContext → OpencodeBackend → OpencodeServer → OpencodeArgs.serve
  (orca appends serve --port 0 --log-level WARN).
• ollama(model) → ollama launch opencode --model <model> --. --model is
  required (headless ollama launch otherwise falls back to interactive
  selection). It pins that one model as the server default, so a bare
  opencode turn routes to it — no withModel. Other Ollama ids are rejected,
  so switching models means relaunching.
• Teardown SIGINTs the process tree (CliProcess.sendSigIntTree, used only
  by the server) so a forking launcher can't orphan the real opencode serve.

flow(OrcaArgs(args), opencodeLauncher = OpencodeLauncher.ollama("qwen3-coder")):
  opencode.autonomous.run("…")   // routes to ollama/qwen3-coder

Docs

README documents both Ollama paths (launcher vs. manual opencode.json +
withModel); ADR 0017 records the decision.

Testing

65 opencode unit tests pass, including one asserting orca spawns the
launcher-wrapped argv. Not verified end-to-end against a live model here
(CPU-only + Ollama's model registry firewalled): validated by inspecting a
launcher-started server's injected /config (the ollama provider and default
model are present); a real agentic turn was too slow to finish on a 0.5B model.
A real-model run on capable hardware is recommended before relying on it.

[JD557]

I haven't compiled the code to test, but one thing that pops out to me from the description and the tests:

ollama(model) → ollama launch opencode --model --. --model is
required (headless ollama launch otherwise falls back to interactive
selection). It pins that one model as the server default, so a bare
opencode turn routes to it — no withModel. Other Ollama ids are rejected,
so switching models means relaunching.

(Emphasis mine)

This is true BUT if the model doesn't exist in the machine (this includes missing versions, for example, if I do ollama launch opencode --model gemma4 instead of ollama launch opencode --model gemma4:26b), ollama launches an interactive prompt asking do download the model.

I don't know how Orca will behave if that happens. The alternative is to pass a --yes flag. Unfortunately, there is no equivalent --no flag.

I don't know which would be the best default. Personally I think this is fine as is (I think I would rather have Orca crash/halt than to have it use the wrong model). But again, I didn't really check what happens if it tries launch an interactive prompt.

[adamw]

@JD557 good question :) so in case the model was missing, the flow was failing (it's a non-interactive terminal), but with a cryptic error message. So now you need to start ollama serve, and then when you use a non-existent model, you get:

▸ hi
ERROR orca.flow - flow aborted: opencode serve did not start:
Error: model "bogus:404" not found; run 'ollama pull bogus:404' first, or use --yes to auto-pull

You can't really use --yes so pulling is the only option

[JD557]

Thanks for confirming, looks good to me, then.

Thanks for the fix 👌