You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Problem — Switching harnesses today means the command palette (amicode.selectHarness) and a settings read. The registry, the ADR-0011 Harness Contract, and the telaio descriptor all exist; the affordance is buried where nobody touches it mid-flow. The composer is where the work happens — the harness choice belongs there. Approach — Ride the solver-mode trio, the proven in-product switcher pattern: a harness control in the composer (a fourth select-slot alongside agent/model/variant) → its selection POSTs to a new engine route /amicode/harness → the extension half does the registry resolution + server restart, with the same switching → ready file-handshake shape solver-mode uses and a banner narrating the switch. The picker's honest disclosure carries over verbatim: switching harnesses switches session history — sessions are harness-local by design. Approaches considered — Status-popover placement only (rejected as the primary: the ask is composer-level; the popover can link to it later); per-session harness identity (rejected for this slice: no engine multiplexing machinery exists — named follow-up); silent restart (rejected: solver-mode's narrated banner is the honest pattern). Scope — in: the composer harness control (honest availability — unresolvable harnesses render disabled with the reason), the engine route + extension handshake + restart, the harness.telaio entitlement read-side gate enforced at the UI, harness-aware degradation of composer controls under telaio (contract v1 accepts no agent/model/variant → those slots dim with a why). out: per-session harness identity, cross-harness session continuity, upstream_mode changes, new harness descriptors. Assumptions — The harness.ts registry and amicode.selectHarness palette command stay the source of truth; the composer control is a new front on the same state, not a competing one.
Acceptance Criteria
The composer shows a harness select; choosing a different harness restarts the server on it, with the switching → ready narration (the solver-mode pattern end to end)
An unresolvable or unentitled harness renders disabled with its reason — never silently absent, never selectable-then-failing
Under telaio, agent/model/variant slots dim with an honest "not accepted by this harness" affordance; under opencode everything behaves as today
The palette command and the composer control are one source of truth (same registry, same setting) — switching from either lands the same state, and a test pins it
The disclosure copy ("switching harnesses switches session history") shows at the point of switching
Testing Decisions
Extend the existing extension harness tests (registry resolution + the picker) and the app's composer-component tests (the select-slot pattern has coverage to mirror); the engine route gets route-level tests in the solver-mode route's file; the handshake state machine reuses the solver-mode tests' shape.
Key Decisions
Process-level switching stays — no schema change, no per-session multiplexing in this slice; the follow-up (per-session harness) is named, not smuggled in.
One registry, two fronts: palette and composer read/write the same setting through the same resolution path; divergence is a red.
The restart is narrated, not hidden: banner while switching, disclosure before committing.
The entitlement gate lives at the UI read (disabled-with-reason), not as a hidden failure at spawn time.
Constraints & Invariants
harness.telaio entitlement enforcement must not regress the palette command's behavior for entitled users.
The opencode default path must be byte-for-byte behaviorally unchanged when the control is untouched.
No new session-identity fields; sessions remain harness-local.
Prior Art
The solver-mode trio (status-popover control → /amicode/solver-mode engine route → extension handshake + restart + banner) — the pattern to mirror
The harness registry module and the amicode.selectHarness palette command (the seams this feature fronts)
ADR-0011 — the Harness Contract and the descriptor registry (availability, entitlement, resolve semantics)
The composer's existing select slots (agent/model/variant) — the UI pattern and test coverage to follow
The solver-mode engine route — the route/handshake shape to clone
Source
Aaron's ask, 2026-09-24 ("i really want a harness switcher in the chat box"), in the re-land campaign (sessions/session-20260924-research-engine-reland.md).
Important
Problem — Switching harnesses today means the command palette (
amicode.selectHarness) and a settings read. The registry, the ADR-0011 Harness Contract, and the telaio descriptor all exist; the affordance is buried where nobody touches it mid-flow. The composer is where the work happens — the harness choice belongs there.Approach — Ride the solver-mode trio, the proven in-product switcher pattern: a harness control in the composer (a fourth select-slot alongside agent/model/variant) → its selection POSTs to a new engine route
/amicode/harness→ the extension half does the registry resolution + server restart, with the sameswitching→readyfile-handshake shape solver-mode uses and a banner narrating the switch. The picker's honest disclosure carries over verbatim: switching harnesses switches session history — sessions are harness-local by design.Approaches considered — Status-popover placement only (rejected as the primary: the ask is composer-level; the popover can link to it later); per-session harness identity (rejected for this slice: no engine multiplexing machinery exists — named follow-up); silent restart (rejected: solver-mode's narrated banner is the honest pattern).
Scope — in: the composer harness control (honest availability — unresolvable harnesses render disabled with the reason), the engine route + extension handshake + restart, the
harness.telaioentitlement read-side gate enforced at the UI, harness-aware degradation of composer controls under telaio (contract v1 accepts no agent/model/variant → those slots dim with a why). out: per-session harness identity, cross-harness session continuity,upstream_modechanges, new harness descriptors.Assumptions — The
harness.tsregistry andamicode.selectHarnesspalette command stay the source of truth; the composer control is a new front on the same state, not a competing one.Acceptance Criteria
switching→readynarration (the solver-mode pattern end to end)Testing Decisions
Extend the existing extension harness tests (registry resolution + the picker) and the app's composer-component tests (the select-slot pattern has coverage to mirror); the engine route gets route-level tests in the solver-mode route's file; the handshake state machine reuses the solver-mode tests' shape.
Key Decisions
Constraints & Invariants
harness.telaioentitlement enforcement must not regress the palette command's behavior for entitled users.Prior Art
/amicode/solver-modeengine route → extension handshake + restart + banner) — the pattern to mirroramicode.selectHarnesspalette command (the seams this feature fronts)Source
Aaron's ask, 2026-09-24 ("i really want a harness switcher in the chat box"), in the re-land campaign (
sessions/session-20260924-research-engine-reland.md).