Agent Console — frontend multi-tenant agnóstico para IAs de CLI/TUI (foundations)

accepted

Nome RATIFICADO (2026-06-22): Koder Krew (krew) — escolhido via name-batch (leva agent-console-2026-06-22, brand-score; owner escolheu entre KrewKondu KorusKhelmKadenceKoveKommand). Produto em products/dev/kli. "Agent Console" permanece só como nome deste RFC/área.

🔁 EMENDA 2 — RATIFICADA PELO OWNER (2026-06-22, k-arch→k-go): este produto É o Koder Kli (unificar Krew→Kli). O conceito deste RFC — UI ricaagnóstica pra IAs CLITUI — é o que o owner chama de Kli. Uma sessão paralela criou um duplicado "Krew" pro mesmo conceito. Correção (D12, colapsar o duplicado): o produto é o Koder Kli; "Krew" é descontinuado como nome e unificado em Kli. O runtimedriversandboxauth feito sob `productsdev/kli vira o **backend do Kli** (headless-first interno — um produto). **A EMENDA 1 abaixo (Krew=runtime/Kli=UI como 2 produtos) fica SUPERSEDIDA.** **Triage NÃO é este RFC** (é productsdevtriage, specsoperator-cockpitcockpit.kmd). Proposta coordenada (Krew tem locks ativos): renomear krewkli mantendo o código. Notice: kli-krew-unify`.

🔁 EMENDA RATIFICADA (2026-06-22, owner via /k-arch/k-go) — re-escopo: Krew = RUNTIME/ENGINE. Análise de causa-raiz (architecture-quality D12) sobre os transcripts mostrou que o conceito "UI rica para IAs CLI" foi forkado em dois produtos (Kli + Krew) por colisão de timing entre sessões paralelas, não por um limite de domínio. Correção: o corte real é o que o headless-first já prescreve — núcleo headless ⟂ surfaces.

  • Krew (este RFC) = o RUNTIME/ENGINE headless multi-tenant: Agent Driver API +

    adapters por-IA + orquestração de services/ai/sandbox + auth/tenancy + roteamento (gateway). NÃO possui as surfaces. É exatamente o que o KREW-001 já constrói.

  • As surfaces (webdesktoptui) + render rico KVG/A2UI migram para o Koder Kli

    (products/dev/kli) — agora o produto-UI multi-surface, multi-tenant, para IAs CLI, que consome o Agent Driver API do Krew. Triagem (chat→tópicos) e o Operator Cockpit (metadados da Stack, owner via RBAC) tornam-se modos do Kli.

  • Relação: não são mais "irmãos co-consumidores do shell" — é camada: Kli

    (UI) → consome → Krew (runtime). O Krew vira primitivo reusável (Kli, kode-tui, koderrootbot, automação) à la services/ai/sandbox.

Impacto no build em voo do Krew: ~nulo (o trabalho atual É o runtime). O que muda: as surfaces saem deste RFC (Fase 2/4 abaixo) e passam à spec do Kli (specs/operator-cockpit/cockpit.kmd, recast nesta mesma data). §6 reescrita abaixo. Coordenação com as sessões KREW-001: notice kli-krew-rescope. Texto pré-emenda abaixo preservado como registro histórico.

Summary

Um produto B2D (products/dev/<slug>) que é uma interface de chat agnóstica + proxy de PTY para IAs que rodam em CLI/TUI (Claude Code, Codex, Gemini CLI, aider, o kode-tui, koderrootbot, …) — uma versão aprimorada dessas IAs de terminal, com UI rica multi-surface. É o equivalente Koder-nativo (e self-hosted) aos wrappers FOSS tipo claudecodeui/opcode, mas reusando o stack Koder e com saída rica (A2UI/KVG) que os FOSS não têm. Não duplica nenhum componente: é uma camada de composição (reuse-first verdict GREEN).

Motivation

IAs de CLI/TUI são poderosas mas presas ao terminal: render inline (o bug de scrollback-duplicado-no-resize), sem multiplexação visual de sessões, sem diffs/ file-tree/painéis, sem acesso por celular. Os FOSS (claudecodeui, opcode, claude-code-webui) resolvem isso embrulhando a CLI — mas são externos, AGPL de terceiros que rodam o agente com o acesso do usuário, e sem integração com o Koder Design / agents / gateway. Pela ótica self-hosted-first, a Koder Stack deve ter o seu — agnóstico (proxy de qualquer IA de console) e Koder-nativo.

Decisões travadas (owner, 2026-06-21 — via /k-go + /k-arch)

  1. Multi-tenant desde o dia 1. Produto multi-usuário de verdade (não owner-only).

    → auth Koder ID, isolamento de sessão por tenant, RLS, quotas, billing-ready (multi-tenant-by-default.kmd).

  2. Todas as superfícies (web + desktop + tui).headless-first é central:

    um núcleo headless único, surfaces como renderizadores (L4 app/{web,desktop,tui}, RFC-006).

  3. Produto-irmão consumindo o shell do SDK (Decisão 3, selada por k-arch→k-go).

    Mora em products/dev/<slug>; consome o shell do SDK (koder_web_kit#030 + scaffold do koder_kit) + o núcleo headless. O Operator Cockpit é um irmão co-consumidor do mesmo shell — nunca host nem dependência (§6).

Arquitetura — núcleo headless + adapters + surfaces

        surfaces (renderizadores)                 núcleo headless (1 só)
  ┌───────────┬───────────┬───────────┐     ┌───────────────────────────────┐
  │ app/web   │ app/desktop│ app/tui   │────▶│  Agent Driver API (REST/gRPC) │
  │ (Verge/   │ (Flutter   │ (Bubble   │     │  - sessão por tenant (RLS)    │
  │  web_kit  │  koder_kit │  Tea, Go) │     │  - multiplex de N sessões     │
  │  shell)   │  scaffold) │           │     │  - stream de I/O (SSE/ws)     │
  └───────────┴───────────┴───────────┘     └──────────────┬────────────────┘
                                                            │
                              ┌─────────────────────────────┼───────────────────┐
                              ▼                             ▼                    ▼
                      ┌───────────────┐          ┌──────────────────┐  ┌────────────────┐
                      │ adapter por-IA│          │ execução          │  │ backend nativo │
                      │ (claude/codex/│          │ - server-side     │  │ services/ai/   │
                      │  gemini/aider/│          │   sandbox (web)   │  │  {agents,      │
                      │  kode-tui/…)  │          │ - PTY local       │  │   gateway}     │
                      └───────┬───────┘          │   (desktop/tui)   │  │ = 1 backend    │
                              │                  └────────┬─────────┘  │   entre vários │
                              ▼                           ▼            └────────────────┘
                      engines/sdk/koder_terminal (PTY + xterm/web-terminal render)
  • Adapter por-IA (o "agnóstico"): cada IA de console é um adapter declarativo

    (binário, args, padrão de prompt/stream, parsing de output). Espelha o modelo multi-CLI do claudecodeui. O runtime nativo Koder (agents+gateway) entra como um backend entre vários, não o único.

  • Dois modelos de execução (Decisão 2 = todas as surfaces habilita ambos):
    • server-side sandbox (web/multi-tenant): as IAs rodam em sandboxes

      isoladas por-tenant no host do produto. Tech de sandbox = open question §8.

    • PTY local (desktop/tui): dirige as IAs da própria máquina do usuário

      via companion local.

  • Render do terminal: sempre via engines/sdk/koder_terminal (não reinventar).

Reuse map (camada de composição — nada duplicado)

Camada Reusa Papel
PTY / terminal engines/sdk/koder_terminal spawnar + renderizar o terminal das IAs
backend nativo services/ai/agents + services/ai/gateway runtime de agente + roteamento multi-provedor (1 backend plugável)
execução por-tenant services/ai/sandbox (sandbox-RFC-001/002) isolar a execução das IAs por sessão/tenant (Incus→Firecracker, netpolicy default-deny+allowlist, quotas, audit) — resolve §8#1
shell web koder_web_kit#030 (landing-shell) nav + layout web (compartilhado com o cockpit via SDK)
shell desktop koder_kit scaffold/safe_scaffold shell Flutter
tema/auth SDK + Koder ID (auth/oauth-flow.kmd) Verge + login
saída rica A2UI (canvas) + KVG (ai-RFC-001) widgetsdiagramas emitidos pelo agente, além de textomarkdown
contrato de UI de IA `specs/ai-ui