Autoresearch rail v0: the copilot ↔ autoresearch switch and the interactive role loop

[aarontrowbridge]

Important

Problem — Amicode's chat has one mode axis (plan / build) and no way to enter the research loop interactively. The autoresearch reframe (#368) makes the loop the product, but until the telaio rail (WS4) and campaign machinery (WS5) land there is no user-facing surface that runs the scientific-method loop at all — the only autoresearch content is the staged QEC prototype.

Approach — Add a studio-level copilot ↔ autoresearch switch, built on the proven solver-mode machinery (app requests the switch; the extension re-preps the session config and restarts; the session resumes in the new mode). In autoresearch mode the session preps a research-rail instruction set in which Amico orchestrates hypothesizer / experimenter / analyzer role subagents, with the corrector invoked only as mechanical gates (detached solve/verify runs, hash-pinned validators). The agent can ask the user to pick a mode via a question card and the harness performs the switch. This is the interactive shadow of the loop — transport, not engine: durable orchestration, fleet dispatch, and warrants stay with WS4/WS5, and the role definitions live in content so telaio orchestrates the same roles later.

Scope — in: the switch (watcher + route + shell toggle), the research-rail instruction variant, role subagent registration, the mode-request tool seam, copilot regression parity · out: campaign engine, warrants, fleet, endpoint qualification, per-pack surfaces (WS7)

Acceptance Criteria

• A studio-level copilot ↔ autoresearch switch exists in the shell next to the solver control, reusing the switch-request → re-prep → restart machinery; switching preserves the session's problem context
• In autoresearch mode, the session's instructions make Amico the orchestrator of hypothesizer / experimenter / analyzer role subagents (registered as subagents, invocable via the task tool); the pulse-onboarding content remains available but is not the spine
• Corrector surfaces report mechanical-gate verdicts only — no LLM-opinion correction anywhere in the rail
• A mode-request seam lets the agent request a switch (the onset router gains an autoresearch entry); the extension performs it and the session resumes in the new mode
• The rail is labeled prototype-grade in-product; promotion to the catalog remains human-only
• Copilot mode behaves exactly as today (the compiled score content is byte-identical in copilot mode)

Testing Decisions

Extend the solver-mode watcher/toggle suites to the generalized mode state; prep-integration tests gain an autoresearch-mode variant asserting the role-loop instructions and the copilot byte-parity case; a round-trip test for the mode-request seam (request → switch → ready).

Key Decisions

• Two axes, kept orthogonal: the permission envelope (plan / build picker) and the studio state (copilot / autoresearch switch). Roles never appear in the picker.
• v1 is the interactive shadow of the loop — no new orchestration engine in the extension; durable execution belongs to telaio (WS4).
• The corrector is mechanical: agents route evidence and report verdicts; verdicts come from tool-grounded gates.
• The context window is a cache, not the database: loop state externalizes to the ledger and vault projections every iteration, so a crashed loop re-hydrates and resumes.
• The switch is studio-level state, not per-pack; pack-contributed surfaces arrive with WS7.

Constraints & Invariants

• Corrector independence: gates stay hash-pinned and outside agent-editable trees; below-threshold autonomy is a bug, not a mode.
• Promotion to the catalog is always human.
• Copilot-mode regression parity is a hard gate.

Prior Art

• The solver-mode switch machinery (extension watcher, fork route, shell toggle).
• The subagent registry (explore / general) as the role-profile mechanism.
• The staged qec-autoresearch skill + the research operating manual — the loop, proven on one domain.
• The onset router's question-card flow.

Source

Part of #368 · design conversation 2026-08-16 · Blocked by #369 (the rail builds on the pack loader).

[aarontrowbridge]

Reframe (design session 2026-08-17, recorded in the spec addendum): the switch is the harness switch. Amicode is the studio + harness switcher — opencode (open, the fork maintained long-term) and telaio (proprietary, subscription, a named entitlement bundle on the solver-toggle machinery). This issue's v0 is the opencode rail preview: the interactive role loop on the open harness — the free taste of autoresearch — with telaio proper arriving behind the same switch when its client lands.

Two scope additions:

• The shell control is a harness selector (opencode | telaio), beside the solver control, showing subscription state.
• Visual requirement: autoresearch-on must be unmistakable at a glance — direction: the Amico presence enters a spira state (animated ascending-loop wave + shell-wide accent theming + session-list marks), ambient not modal. A real design moment during implementation, not an afterthought.

ACs stand as written (the switch mechanics, role loop, mechanical-only corrector, copilot byte-parity); the picker is explicitly NOT an entry point — it stays opencode-internal permissions (plan/build).

[aarontrowbridge]

Convergence note from the same design session (vault memo note-20260817-autoresearch-pulse-stack-amico-run-rethink, v2.1): your role loop maps one-to-one onto the five-verb architecture we reduced the stack to — hypothesizer = AUTHOR (scripts + typed templates; #259 makes bad combinations TypeErrors), experimenter = EXECUTE (spec runner / thin cloud client), analyzer = VERIFY+REMEMBER (mechanical correctors + catalog staging). Your 'corrector invoked only as mechanical gates' is the doctrine verbatim.

One input for the rail's instructions: the experimenter path is author-in-code, record-in-data — agents write scripts that construct typed problems; the canonical ProblemSpec is derived and recorded at run start (never a hand-authored form). Specs remain as generated inputs (sweeps, stock problems, replay). This keeps the W2 interview path valuable but reframes it as a record/spec generator for stock problems, and it means the rail never needs a 'write problem.toml by hand' step. Derivation + ResultSpec land Piccolo-side as P6a (2.0 program), ahead of when the rail wants to consume records. The harness-switch reframe (opencode | telaio) is orthogonal and unaffected.