Epic: Capability-aware task routing across canonical runtimes

[dcellison]

Goal

Preserve the capability-aware routing foundation for a future concrete,
non-conversation workload without changing how ordinary conversations select
their runtime.

Reconciled status

The useful foundation is complete:

• canonical model/provider inventory and per-principal backend grants;
• a small capability vocabulary backed by adapter/runtime evidence;
• principal-scoped, read-only eligibility reports with accepted and rejected
  candidate explanations;
• deterministic routing policy and durable decision evidence in the canonical
  runtime layer;
• authorization, workspace, and service constraints that fail closed.

The initial consumer was not valid. PR #1213 exposed per-message task-class
routing in the Workshop composer and personal routing controls in Settings.
That interaction was an implementation assumption, not a demonstrated user
need. PR #1218 removed those controls and made Workshop reject caller-supplied
task_class values before creating a message, run, or artifact.

Ordinary Telegram and Workshop conversations therefore use only the
principal's explicitly selected backend and model. There is no hidden task
classification or automatic runtime switching.

Future-work gate

Do not resume this epic as a generic routing feature. Any future work must
start with a separate issue naming a concrete non-conversation consumer, such
as an automated workflow or explicit agent delegation, and must define:

• why one runtime cannot serve the workload;
• who explicitly requests or configures the route;
• the required capability and authorization evidence;
• visible decision and failure behaviour;
• evaluation criteria showing that routing improves the workload;
• confirmation that principal conversation defaults remain unchanged.

The existing schema and routing internals may remain dormant until such a
consumer exists. No destructive downgrade is required.

Outcome

The architectural foundation is retained, the premature user interaction is
removed, and this issue has no remaining actionable implementation scope.

[dcellison]

Triage by Kai

Triage summary: This is a foundational epic to introduce explicit backend routing in Kai, selecting Claude Code, Codex, ACP-style, or other backends by role/task while preserving a shared memory/context contract and operator controls. It depends on memory parity and scoped retrieval work first, then adds routing policy, capability metadata, fallbacks, logging, and tests.

Priority: high
Labels applied: (none added)

[dcellison]

Architecture audit — 2026-08-11

This epic is partially delivered, but its remaining work should not be implemented literally from the current body.

Kai now has five first-class adapters, an administrator-owned backend registry, backend-neutral scheduled/review/triage execution, per-role model routing, and explicit default/per-user backend selection. No backend has implicit priority.

The remaining useful work is deterministic capability-aware task routing, eligibility explanations, conservative fallback policy, and operator inspection. That belongs in the Kai Workshop execution architecture after the v2.0 qualification work in #811. When rewritten, it must describe all backends symmetrically and must not name any backend as an implicit compatibility fallback.

[dcellison]

Reconciled after #1218. The capability and eligibility foundation remains available, but the premature per-message routing interaction has been removed. Future routing work must begin from a concrete non-conversation consumer with explicit evaluation criteria.