OmniRoute/task-c3-report.md

Task C3 — requirements no repeat do Conductor + foco na task nova + teste de auth

Branch feat/orch-fase3-c · commit a7d430fe9ee3ae1fd1d86ff0083318fc1e96005b (fix(dashboard): carry conductor requirements and focus the repeated task, corpo com Refs #12639).

O que mudou, por item

1. src/lib/conductor/hubProxy.ts — requirements no schema de detalhe

• hubTaskSchema ganhou requirements: z.object({ cli: z.string().nullish(), model: z.string().nullish() }).nullish().catch(null). O .catch(null) é deliberado: o MESMO schema parseia a lista em getFleetSnapshot (z.array(hubTaskSchema).parse(rawTasks)) — sem ele, um requirements de formato inesperado numa única task faria o parse inteiro lançar e o snapshot cair para {offline: true}.
• ConductorTaskDetail ganhou cli: string | null e model: string | null (com JSDoc); getConductorTaskDetail preenche com t.requirements?.cli ?? null / ?? null.
• Origem do shape: é exatamente o objeto que createConductorTask (mesmo arquivo, linhas ~238-241) envia para o hub (body.requirements = { cli?, model? }) — não foi inventado.

2. drawer/useDrawerDetail.ts

• repeatReqForConductor agora envia cli: d.cli ?? undefined / model: d.model ?? undefined. undefined, nunca null — o Zod real da rota (src/app/api/conductor/tasks/route.ts) tem cli: z.string().optional() / model: z.string().optional(), e null daria 400. JSON.stringify descarta as chaves undefined, então o corpo sai idêntico ao de hoje quando não há requirement. Os dois campos são independentes (um pode existir sem o outro) — há teste para esse caso.
• jsonRpcErrorCode deixou de ler res.json() e passou a receber o corpo já parseado; novo readJsonBody(res) lê o corpo UMA vez (um body só pode ser consumido uma vez, e agora o id da task nova sai do mesmo corpo). Body não-JSON/vazio ⇒ null, sem virar falha (mantém o contrato anterior: "corpo ilegível não é evidência de falha, o status já valeu").
• performAction passou a devolver { ok, body } em vez de boolean.
• Novo export function newNodeIdFrom(node, body): string | null — extrai o id da task criada e devolve já no formato do canvas (com prefixo), porque setParams({ node }) casa contra snapshot.nodes.find(n => n.id === nodeId) e os ids em mergeSnapshot.ts são prefixados:
  • conductor: body.task_id → conductor:task:<id>
  • cloud-agent: body.data.id → cloud-agent:<id>
  • a2a: body.result.task.id → a2a:<id> (envelope real de /a2a message/send v0.3) Leitura defensiva: id ausente/vazio/não-string ⇒ null (nunca um prefixo pelado), corpo não-objeto ⇒ null, nunca lança.
• No hook: approve/cancel continuam Promise<boolean> (via runBooleanAction) — de propósito: eles agem sobre a task já aberta e a resposta do cloud-agent pode ecoar o id da MESMA task, o que faria o painel "navegar" para onde já está. Só repeat devolve RepeatOutcome { ok, newNodeId } (interface exportada).

3. drawer/OrchestrationDrawer.tsx

• RepeatButton consome RepeatOutcome e chama onActionDone(newNodeId ?? undefined).
• onActionDone virou (newNodeId?: string) => void no RepeatButton, DrawerActions e no componente exportado. DrawerActions.run() (approve/cancel) segue chamando onActionDone() sem argumento.

4. OrchestrationPageClient.tsx

• Novo onActionDone memoizado: refetch() e, se veio id, setParams({ node: newNodeId }). A aba History renderiza o próprio drawer (HistoryTab.tsx) e não foi tocada — seu onActionDone={() => …} ignora o argumento extra, então o comportamento lá continua idêntico (re-amostra nowMs, não navega), como o plano pede.

5. Testes

• tests/unit/conductor-routes-auth.test.ts: src/app/api/conductor/tasks/route.ts entrou no array ROUTES; o regex do proxy ganhou a alternativa createConductorTask\(.
• tests/unit/conductor-create-route.test.ts: removido o teste de fonte duplicado (route: requireManagementAuth antes de criar a task no hub), substituído por um comentário apontando para o array. fs/path continuam usados pelo resto do arquivo.
• tests/unit/ui/orchestrationDrawerRepeat.test.tsx (786 → 971 linhas, cap 1200 — não precisou dividir): 3 describes novos, 6 testes:
  • repeatReqFor conductor com cli/model; com ambos null (corpo idêntico ao atual e sem as strings cli/model); com só cli setado.
  • newNodeIdFrom nas três fontes (prefixado), corpos malformados ⇒ null, fonte sem contrato ⇒ null.
  • drawer: repeat de conductor faz POST com cli/model e chama onActionDone exatamente uma vez com "conductor:task:t_new", com o toast repeatDone.

TDD — evidência

C3.2 (vermelho) npx vitest run tests/unit/ui/orchestrationDrawerRepeat.test.tsx:

 Test Files  1 failed (1)
      Tests  6 failed | 29 passed (35)

(falhas: newNodeIdFrom is not a function ×3, corpo sem cli/model ×3 — a última: expected { …(4) } to match object { cli: 'claude', model: 'sonnet' })

node --import tsx/esm --test tests/unit/conductor-routes-auth.test.ts tests/unit/conductor-create-route.test.ts já passou nesse ponto (ℹ pass 11 / fail 0) — divergência menor com o plano: a mudança do array ROUTES é ampliação de cobertura + de-duplicação, não a prova de um defeito, então ela não tinha como "falhar antes". A rota já chamava requireManagementAuth corretamente.

C3.4 (verde):

$ npx vitest run tests/unit/ui/orchestrationDrawerRepeat.test.tsx
 Test Files  1 passed (1)
      Tests  35 passed (35)

$ node --import tsx/esm --test tests/unit/conductor-routes-auth.test.ts tests/unit/conductor-create-route.test.ts tests/unit/client-bundle-no-server-only-10692.test.ts
✔ src/app/api/conductor/tasks/route.ts: requireManagementAuth antes do proxy ao hub (4.175999ms)
ℹ tests 12
ℹ pass 12
ℹ fail 0

$ npx vitest run tests/unit/ui/
 Test Files  210 passed (210)
      Tests  1200 passed (1200)
   Duration  179.85s

$ node --import tsx/esm --test tests/unit/conductor-hub-proxy.test.ts tests/unit/conductor-fleet-mirror.test.ts tests/unit/conductor-fleet-route.test.ts tests/unit/conductor-delegate.test.ts
ℹ tests 17
ℹ pass 17
ℹ fail 0

Gates

$ npm run typecheck:core
EXIT=0   (sem saída de erro)

$ npm run check:dashboard-typecheck
[dashboard-typecheck] OK — 206 pre-existing error(s), all within frozen baseline.
EXIT=0

$ npx eslint <os 7 arquivos alterados>
EXIT=0   (zero erros, zero warnings)

$ npm run check:file-size
[file-size] OK — 136 arquivos congelados, cap 1200 para novos (4588 arquivos verificados)
[test-file-size] OK — 40 test files congelados, testCap 1200 para novos (5495 test files verificados)

Hooks do husky rodaram no commit (lint-staged + docs-sync + any-budget + tracked-artifacts, todos PASS); nada de --no-verify.

Divergências entre plano e código real

1. newNodeIdFrom prefixado (não previsto explicitamente no plano). O plano diz "extrair o id da task nova (task_id no Conductor, data.id no Cloud Agent) e chamar onActionDone com ele". O id CRU não serve para setParams({ node }): o canvas indexa por id prefixado (conductor:task:<id>, cloud-agent:<id>, a2a:<id> — mergeSnapshot.ts / routeFor). Segui o código: newNodeIdFrom já devolve o id de canvas. O plano não citava o a2a; incluí porque o repeat do drawer também atende a2a e o envelope (result.task.id) é verificável em src/app/a2a/route.ts:250.
2. performAction "devolve o corpo parseado" — só o repeat propaga o id. approve/cancel ficaram Promise<boolean> de propósito (ver item 2 acima): o POST de approve/cancel do cloud-agent pode devolver o id da MESMA task, e navegar para ela seria ruído. Cumprimento do espírito do plano ("o drawer extrai o id da task nova") sem o efeito colateral.
3. .catch(null) no requirements. O plano não pedia; adicionei porque hubTaskSchema também parseia a LISTA de tasks, e um campo novo estrito ali seria um vetor de "snapshot vira offline por causa de um campo estranho de uma task".
4. A mudança em conductor-routes-auth.test.ts não é um teste que falha antes (explicado acima).
5. ConductorTaskDetail estende FleetTask; cli/model foram adicionados só no detalhe (não em FleetTask/toFleetTask), porque o repeat lê o DETALHE carregado, não o nó.

Fora de escopo (não feito, é da Task C4)

changelog.d/fixes/orchestration-followups.md, o comentário na issue #12639 e a bateria completa (lint total, test:vitest, check:cycles, i18n) continuam pendentes na C4.