Today the extension is welded to the vendored opencode fork: fetch:opencode + opencode.lock.json pin the binary, the extension spawns opencode serve, and the chat iframe talks the fork's session protocol. As telaio (harmoniqs/telaio) matures — and as other harnesses appear — the extension should treat the harness as a swappable backend behind one adapter seam.
The seam, as it exists:
- binary provisioning:
scripts/fetch_opencode.mjs + opencode.lock.json (tag/ref/sha256 pin)
- process lifecycle:
opencode serve --port N spawn + health
- protocol: session/message/event REST + the iframe⇄extension bridge (
chat_bridge.ts)
What swappable means: a HarnessAdapter interface (provision → serve → session protocol → bridge), with opencode-vendored as the default adapter and telaio as the second. The extension UI should not know which harness serves it.
Notes: telaio already mirrors the opencode session/event spine by design (event-sourced JSONL, sessions). The fork's release pipeline (amicode-release.yml, tag v*-amicode.*) stays the opencode adapter's provisioning path regardless.
Why now-ish: every UI fix lands in the fork (LaTeX, buried output, buttons — all of 2026-08-02's work), which means the UI itself currently lives harness-side. Deciding what belongs to the extension vs the harness is prerequisite design work for telaio's productization.
Candidate first fleet:ready issue once the telaio GitHub App is installed.
Today the extension is welded to the vendored opencode fork:
fetch:opencode+opencode.lock.jsonpin the binary, the extension spawnsopencode serve, and the chat iframe talks the fork's session protocol. As telaio (harmoniqs/telaio) matures — and as other harnesses appear — the extension should treat the harness as a swappable backend behind one adapter seam.The seam, as it exists:
scripts/fetch_opencode.mjs+opencode.lock.json(tag/ref/sha256 pin)opencode serve --port Nspawn + healthchat_bridge.ts)What swappable means: a
HarnessAdapterinterface (provision → serve → session protocol → bridge), with opencode-vendored as the default adapter and telaio as the second. The extension UI should not know which harness serves it.Notes: telaio already mirrors the opencode session/event spine by design (event-sourced JSONL, sessions). The fork's release pipeline (
amicode-release.yml, tagv*-amicode.*) stays the opencode adapter's provisioning path regardless.Why now-ish: every UI fix lands in the fork (LaTeX, buried output, buttons — all of 2026-08-02's work), which means the UI itself currently lives harness-side. Deciding what belongs to the extension vs the harness is prerequisite design work for telaio's productization.
Candidate first
fleet:readyissue once the telaio GitHub App is installed.