[7/7] feat: gate model routing, handoff and remote controls

[BIackFIame]

Summary

Part 7/7 of the CanvasTTY agent-workflow series. The final part adds default-off model/account routing, autonomous or manual task goals, quota handoff, companion controls and remote-session integration. Approved execution targets bind CLI, account/model, environment and data class; authorization is rechecked at launch, restore, handoff and input. Assistant privacy defaults remain at least as strict as the core floor.

Review scope and dependencies

Depends on: #136.

This is a cumulative upstream PR: GitHub's Files changed tab includes earlier unmerged parts because all PRs target upstream main; cross-fork stacked bases are unsupported. Review this part in the isolated predecessor-to-head diff. The intended merge order follows the numbered series; do not merge a later part independently of its predecessors.

Requires the experimental Assistant, Accounts and Environments companions. Assistant contains offline benchmark ratings, weekly refresh, effort-aware comparisons and preview-model decisions. Keep Draft and default-off pending acceptance.

Validation and current blockers

Tested feature head: 65b7bf55cf727e2b46a51559218f43cf907da2f5. Local helpers, typecheck, build and secret audit passed; full suite: 2,127 passed, 12 skipped, zero failures. Historical fork CI passed on macOS, Linux and Windows using the exact candidate tree under a temporary workflow overlay. That overlay is not included here.

Draft: merge preview against updated upstream 6faadcdc found conflicts in src/preload/index.ts, src/renderer/src/features/workspace/WorkspaceCanvas.tsx, src/shared/contracts.ts. These historical results do not validate a conflict-resolved integration with current main. Preserve the newly accepted material/terminal-link behavior, resolve the overlaps, and rerun checks before marking ready.

Historical routing selected the expected model on 18/20 tasks, including two under-routed difficult tasks. A later real OpenCode/GLM run delivered three worker tasks without resends and passed 10/10 independent artifact checks in Suggest mode. Auto qualification and a separate verifier remain required. No quality or cost improvement is established. Latest execution-authority/privacy repairs have local and CI evidence, not a fresh live-provider/SSH run. Quota handoff, phone control and remote reconnect lack complete live acceptance; remote approval is not remote sandbox enforcement.

Series order

1. macOS clipboard
2. Orchestration, reviews and budgets — Draft
3. Worktrees and checkpoints — Draft
4. Timeline, usage and attention — Draft
5. Network policies and temporary secrets — Draft
6. Workspace context and navigation — Draft
7. Experimental routing, handoff and remote controls — Draft

Parts 2–7 are cumulative Draft PRs against upstream main, with an isolated layer diff in each description. Their tested feature heads currently conflict with newer upstream changes; integration and fresh checks are required before readiness. Part 7 also retains its independent experimental acceptance gate.

[howdeploy]

@BIackFIame, this needs a product and architecture rework before we can accept it into CanvasTTY core. The routing and harness work should be an explicitly installed, optional plugin. If that plugin needs capabilities the host does not currently expose, please propose narrowly scoped plugin-system changes separately.

The Settings screen from local DEV acceptance makes the problem clear: ordinary agent configuration now starts with an execution-destination policy editor, data classification, account/model binding and terminology about model ratings. This changes the scope and mental model of the application substantially.

1. Rebuild the UI within the existing design contract

The visual implementation needs to be rebuilt using our existing components and design language. A palette adjustment to the current form will not address the underlying composition and interaction problems.

Our UI contract defines concise default Agents settings, compact copy/control rows for simple settings, shared application tokens and the root UI scale. Detailed explanations belong in expandable help. The current ExecutionTargetSettings uses a separate fieldset/legend form and its own grid rules, native selects, inline paragraphs and a large creation form, bypassing the SettingGroup composition used around it.

In particular, SettingsPanel renders this editor unconditionally at the start of the Agents section. The policy being disabled does not hide or progressively disclose the configuration. The experimental routing gate therefore does not keep this complexity out of the default Settings experience.

Please rebuild the user flow using the established spacing, typography, controls, tokens and interaction patterns. Any additional host UI must have an agreed ownership and fit the existing Settings contract. Installing an optional plugin should lead to a clearly identified plugin configuration surface, rather than a new harness-administration form at the top of core Agents settings.

2. The configuration demands too much knowledge before explaining its benefit

The form asks the user to understand D0–D3, a default task class, a maximum destination class, a CLI, an account, a model, an environment and account-route identity. The practical question the user needs answered is much smaller: which agent should run this task, and what will it be allowed to receive?

“Model ratings do not grant access” introduces another system without showing a rating, explaining its source or connecting it to a concrete action. Your description places those ratings in the separate Assistant companion. Core Agents settings should not assume the user has installed that companion or understands its evaluation model.

The consequences also need clearer communication. In TerminalManager, inputChecked revalidates execution authorization for existing agent sessions, with an exception for Ctrl+C. Removing an approved destination can therefore prevent further interactive input to an already running session. The form's explanation about blocking new tasks does not adequately describe that effect.

Please start from a concrete user scenario, explain the resulting action and scope, and reveal advanced configuration only after deliberate opt-in. We do not want ordinary use of the canvas to require configuring a custom agent harness.

3. The coupling creates an ongoing integration burden

GitHub currently reports this head as MERGEABLE/CLEAN. The historical conflict notes in the description need updating. The architectural overlap remains significant even when Git can merge the text automatically.

The #136-to-#137 layer reaches TerminalManager, LaunchPipeline, TerminalSessionStore, SettingsStore, shared contracts, preload/IPC, orchestration tools, companion control and core Settings. Destination policy now participates in creation, prepared-launch validation, restoration, handoff and terminal input. Persistent session records carry authorization/classification state, while core settings store the destination list.

These are central paths that other work also changes: account preparation, terminal restart/restore, worker lifecycle, environment handling and companion input. Each future change must preserve this feature's authorization and privacy state across all of those paths. That is a semantic integration and maintenance cost; successful conflict resolution alone does not establish that those interactions are correct.

The core now also knows policy concepts and route identity associated with Assistant/Accounts/Environments. Disabling an experimental feature flag leaves that code, persisted state and UI ownership in the host. This is too broad a dependency for an optional harness feature.

4. Requested direction

Please split the work into an optional plugin implementation and any genuinely necessary, separately reviewable host API extensions:

• Put harness-specific configuration, model-rating/routing strategy, task goals and its policy UX in the plugin. Installing and enabling it must be an explicit choice; the normal canvas and Agents settings should retain their existing workflow without it.
• Start with the existing extension points documented in ARCHITECTURE.md: supervised plugin services, launch contributions, environments, session operations, decision hooks and plugin UI contributions. Map each required operation to an existing capability before proposing a new one.
• For a missing capability, open a focused core proposal explaining the concrete use case, request/response contract, permission and ownership rules, cancellation/revocation behavior, and behavior when the plugin is disabled or unavailable. A generic routing capability may be useful; adopting the entire harness policy model into core requires a separate product decision.
• Keep host security enforcement in the trusted main process: validation, permission checks, credential handling, environment ownership and refusal behavior remain host responsibilities. A plugin's model rating or recommendation must never grant itself access. Moving policy and UX into a plugin does not mean moving authoritative security checks into plugin-controlled code.
• Separate independently useful companion/remote-control changes from this harness work so they can be reviewed and accepted on their own requirements.

Please keep #137 in Draft while this boundary and the revised UI are worked out. For the next iteration, provide the plugin flow, identify the exact host APIs that are missing, and show how the redesigned interface follows the existing CanvasTTY components and contract. That gives us a concrete, smaller integration to review without making harness administration a built-in isolation and management layer of the canvas.