Especificações técnicas

Consolidação do que foi definido para telas, processos e banco de dados do NEW FLOW LEGAL.

O caso percorre Intake → Coordinator → Attorney Setup → Kickoff → After Kickoff → Produção. Agentes de IA (Agno) e automações entram em pontos específicos; toda saída de IA é advisory e validada por humano. Esta página reúne as specs; os documentos de fluxo e o protótipo de telas estão linkados no menu.

Escopo e status

ItemTipoStatus
Agente de Intake/Triagem (ativ. 4)Agente Agnospec completa
Sandbox de Agents (ativ. 5)Settings: governança dos agentsspec completa
Método Claude for Legal no Intake + Chat no Sandbox (ativ. 11)Reforço do Intake (fonte, jurisdição, defaults conservadores) + aba Chat multi-turno no Sandboxspec completa
Automações do Setup (ativ. 6)Notificações + kickoff + filingsspec completa
Attorney Setup & Kickoff (ativ. 7)Agente Agno (Yousa Chat, ativ. 37); agendamento Google via dash-backendspec completa
Captura de transcrições → RAG (ativ. 8)Fila + meet-sync + ingestãospec completa
Agente do Caso (na tela do caso)Agente Agno (consome o RAG)a planejar
Telas (operação + Sandbox)UIprotótipo (mockup)

Princípios de engenharia

🤝 Advisory + gate humano

IA sugere; humano decide. Mensagens ao cliente e relatórios passam por aprovação.

♻️ Reuso do stack

Agno (OpenRouter), backend orquestra eventos (como no NPS), Supabase + sync Airtable.

⚖️ Compliance

COMP-04 (PII), COMP-05 (comunicação cliente), COMP-06 (uso de IA). Resultados ficam no sistema.

existente já no sistema extensão coluna/ajuste em tabela existente novo tabela/objeto novo proposto a validar

Processos (fluxo)

As etapas do caso, seus gatilhos, atores e onde entram IA/automação. Detalhe completo nos documentos de fluxo.

EtapaGatilhoAtoresIA / AutomaçãoSaída
1. Intake / Triagemcase entra na triagemCoordinatorAgente Agno classifica tipo, gaps, red flags automação: disparo do Intake (ativ. 4)relatório em case_intake_reports + RAG
2. Coordinator Setup"Finalizar setup"Coordinatorautomação: finalização do setup (ativ. 6) cria filings+prazos, abre kickoff, notifica o time, avança o stageequipe, estratégia, filings + deadlines
3. Attorney Setup & Kickoffhandoff do CoordinatorAttorney BR (+ Specialist/LA)Agente fala c/ cliente (Yousa Chat) até confirmar data + automação: agendamento (ativ. 7)data no Case Event + evento Google Calendar
4. Kickoffdata confirmada → reunião → FinishedAttorney + clienteGemini grava/extrai notas + automação: captura da transcrição → RAG (ativ. 8)notas + checklist + transcrição no RAG do caso
5. After Kickoff Setupkickoff encerradoAttorney BRvalida checklist/notas da IA; automação: notifica responsáveis + alimenta o painel de prazosresponsáveis + prazos internos por doc/filing
6. Produção & Filingsprazos definidosequipepainel de prazos (cruza filing + documentos)filings (delivery / final / protocolo)

Documentos de fluxo: Intake · Coordinator · Attorney Setup · Kickoff · After Kickoff.

🗓️
Prazos em duas camadas: deadlines do filing (production/revision/final) definidas pelo Coordinator; deadlines dos documentos dentro do filing definidas pelo Attorney BR no After Kickoff. O painel de prazos cruza as duas.

Agentes de IA

Stack: Agno v2 (AgentOS) sobre OpenRouter; o backend orquestra os disparos. Gemini é usado na captura do kickoff (ecossistema Google).

AgenteEntradaSaídaModeloIntegrações
Intake / Triagem
spec completa
case_id + lead + transcrições + AILAcase_intake_reports + RAG do casoOpenRouter (claude-sonnet-4.6)Supabase, yousa-sales (transcrições), AILA (MCP), RAG do caso
Client Messenger (Attorney/Kickoff)
spec completa fala c/ cliente
caso + datas aprovadas + msg aprovadaconversa + intent=confirmed + data confirmadaOpenRouterYousa Chat (WhatsApp; canal trocado na ativ. 37). O agendamento no Google é feito pelo backend via dash-backend, não é MCP do agent.
Agente do Caso
a planejar
pergunta do advogado + RAG do casorespostas com fontesOpenRouterRAG do caso, AILA (MCP)
Captura de Kickoff (notas)
mapeado
reunião gravadanotas + checklistGemini (Google)Google Meet → Supabase

Sub-agents internos

Rodam por dentro de um agent (não são agents de produção separados). O Sandbox mostra o trace (resultado/diálogo) quando o agent é acionado.

Sub-agentPaiFunção
Resumo de transcriçõesIntakeresume as reuniões de vendas em sinais úteis
Requisitos AILAIntakeconsulta a AILA (MCP) e monta os requisitos do tipo de caso
Team Fit AnalystIntakesugere o Attorney ideal pelo histórico do time

Agente de Intake - contrato

Endpoint no Agno: POST /triage { case_id }, disparado pelo backend quando o caso entra na triagem. Pipeline de 8 passos:

# pipeline
1. coletar lead (cases+clients+leads) + checar recorrência (clients/cases por email/phone)
2. achar reuniões no yousa-sales (match email/phone, fallback "review")
3. resumir transcrições .......... sub-agent interno (trace no Sandbox)
4. classificar tipo de caso + confiança
5. requisitos da AILA via MCP .... sub-agent interno (trace no Sandbox)
6. comparar requisitos × (resumo + lead) → tem / falta
7. produzir relatório
8. gravar em case_intake_reports + indexar no RAG do caso
# saída estruturada (Pydantic)
IntakeReport:
  case_type_suggested: str        # entre os CaseType
  confidence: float               # 0..1
  overview: str                   # resumo do cliente para o advogado
  green_flags:      [ {item, reason} ]
  red_flags:        [ {item, severity, reason, escalate} ]   # escalate = crítica
  requirement_gaps: [ {field, issue, hint_to_sales} ]
  pre_strategy: str               # sugestão advisory; alimenta a aba Estratégia
  readiness_score: int            # 0..100 (pronto p/ kickoff)
  prior_case_refs:  [ {client_id|case_id, note} ]
  aila_citations:   [ {title, aila_url, snippet} ]
  transcript_summary: str         # resumo; nunca a transcrição crua
  source_meetings: [ ids ]   match_status: ok|review|none

Config por case_type (aila_query + checklist objetivo seed + red flags) em intake_rules.yaml no repo do Agno. Red flags sensíveis (criminal, overstay, negativa anterior, fraude) são marcadas como críticas com ênfase máxima no card (sem notificação automática; decisão de escalar é do advogado).

🤖
Registro no Sandbox: o agent nasce com manifesto (specs/Yousa Agno/Studio e Sandbox/Tarefas/5-agent-sandbox/REGISTERING-AN-AGENT.md) e aparece em Settings/Agents com prompt, versões, tools, MCPs e o trace dos sub-agents. O advogado pode conversar com o agent (chat inline, texto e áudio) sobre o caso.
⚖️
Método Claude for Legal (ativ. 11): o Intake segue o método da suíte open-source Claude for Legal (anthropics/claude-for-legal), portado como módulo de instrução (apps/agno/legal_method.py) — nenhuma chamada à API gerenciada da Anthropic, nenhuma PII sai da nossa infra (COMP-04). Toda afirmação jurídica cita a fonte (AILA, dossiê ou transcrição — sem fonte, marca não verificado); premissas de jurisdição ficam explícitas; determinações sensíveis (admissibilidade, fraude, criminal bars) nunca são concluídas — viram red flag de severidade alta com recomendação de consulta ao Managing Attorney. Toda saída carrega attorney_review_required=true e o disclaimer de revisão (COMP-06). Prompt atualizado entra como versão draft nova no Sandbox automaticamente (não ativa sozinho).
🔌
Conexão com a AILA (ativ. 12): o Intake consulta a AILA pela API REST (POST /ask do apps/aila-api, no Railway), via intake/aila.py com AILA_API_URL+AILA_API_TOKEN. Um servidor MCP formal é opcional (atividade 10); a API REST já entrega requisitos + fontes. Em falha, degrada e marca não verificado.
🧪
Ambiente de Teste (dry-run, ativ. 12): no Sandbox dá para rodar o agent sobre um cliente real (o pipeline lê os dados de verdade via tools), mas em dry-run: nada é gravado nem enviado. Em vez de aplicar, mostra o resultado e o que seria gravado (would_write: case_intake_reports + RAG). Endpoint POST /triage {`{ case_id, dry_run:true }`}.

Telas

Protótipo navegável (look shadcn + design system). Componentes do frontend: shadcn, ag-grid (tabelas), FullCalendar (calendário), dnd-kit (boards), CounterCard/StatusBadge/Header/Sidebar.

TelaPropósitoComponentesFonte de dados
Dashboard (operação)visão de coordenaçãoCounterCard, tabela, bars, listascases, documents/petition_filings, case_intake_reports, case_team
Painel do Attorneyações pendentes do attorneycards de ação, tabela, listascases (do attorney), client_appointments, agent_client_messages, deadlines
Casos (lista)listar/filtrar casosag-grid + chips de filtrocases + clients + case_team + view de deadlines
Detalhe do casovisão 360 do casotabs, timeline, tabelascases, case_intake_reports (Triagem), documents, petition_filings, notes_v2
Calendáriodeadlines + kickoffsFullCalendardocuments.internal_deadline, deadlines de filing, client_appointments
Notes do caso (protótipo)conversas do caso por contexto (caso, documento, filing, evento) num só lugar; protótipo com dados fictícios, sem afirmar identidade do cliente, navegação no app ou resumo/banner prontosthreads com badge de contexto, chips de filtro, mensagens com avatar, status de espera, caixa de respostanotes_v2
Coordinator Case Setupsetup do caso + card de triagem + chat inline com o agentwizard, card do agente, chat (texto/áudio)case_intake_reports, case_agent_messages, RAG do caso Sandbox de Agents (Settings)observabilidade/governança: prompt, versões, playground, tools/MCPs, sub-agentsabas, diff, playground, traceagent_registry, agent_prompt_versions, agent_test_runs

Abrir protótipo: Dashboard · Painel Attorney · Casos · Detalhe · Calendário · Coordinator Setup · Sandbox.

📱
Regra de UI: todas as telas responsivas (mobile-first), seguindo o design system YousaLaw (navy/blue, status colors, radius 10px). Telas read-heavy usam ag-grid; o detalhe usa tabs.

Banco de dados

Supabase (Postgres). Reusa o schema existente e adiciona o mínimo necessário. RLS habilitada em todas as tabelas.

Tabelas existentes reusadas

TabelaPapel no fluxo
cases existenteentidade central; stage dirige o pipeline; case_type, strategy
clients / leads existentedados do cliente/lead (origem HubSpot→Airtable→sync)
case_team existenteequipe (case↔user↔role); base de workload e histórico do time
documents existentechecklist de documentos do caso
document_types / checklist_types / demand_types existentecatálogo por case_type (referência de requisitos/checklist)
petition_filings existentefilings do caso
client_appointments existenteCase Event de Kickoff (type='kickoff', status "waiting scheduling"→"scheduled")
notes_v2 existentenotas do caso, incluindo as geradas pelo Gemini no kickoff

Novos objetos & extensões

case_intake_reports novo spec T-1

create table case_intake_reports (
  id                   bigint primary key generated always as identity,
  case_id              int references cases(id) on delete cascade,
  case_type_suggested  text,
  confidence           numeric,            -- 0..1
  overview             text,
  requirement_gaps     jsonb default '[]', -- {field, issue, hint_to_sales}
  green_flags          jsonb default '[]', -- {item, reason}
  red_flags            jsonb default '[]', -- {item, severity, reason, escalate}
  pre_strategy         text,
  readiness_score      int,                -- 0..100
  prior_case_refs      jsonb default '[]', -- recorrência: {client_id|case_id, note}
  transcript_summary   text,               -- resumo; nunca a transcrição crua
  source_meetings      jsonb default '[]', -- ids das reuniões (yousa-sales)
  match_status         text default 'ok'
                       check (match_status in ('ok','review','none')),
  aila_citations       jsonb default '[]', -- {title, aila_url, snippet}
  model                text,
  status               text default 'draft'
                       check (status in ('draft','reviewed','error')),
  error_message        text,
  created_at           timestamptz default now()
);
create index on case_intake_reports (case_id, created_at desc);

documents - extensão extensão

alter table documents
  add column internal_deadline date,            -- prazo interno (After Kickoff)
  add column responsible_id    uuid references users(id);  -- quem produz

petition_filings - extensão extensão

alter table petition_filings
  add column deadline_production date,  -- definidas pelo Coordinator
  add column deadline_revision   date,
  add column deadline_final      date;

agent_client_messages novo proposto

Thread do agente de comunicação/kickoff (Etapa 3). Permite gate de aprovação, continuidade e auditoria.

create table agent_client_messages (
  id          bigint primary key generated always as identity,
  case_id     int references cases(id) on delete cascade,
  channel     text,   -- whatsapp | email | app
  direction   text,   -- outbound | inbound
  body        text,
  status      text,   -- draft | awaiting_approval | sent | received
  approved_by uuid references users(id),
  created_at  timestamptz default now()
);

case_knowledge_chunks novo spec T-8

RAG do caso (pgvector no YousaLawDB). O intake indexa overview + resumo + dados + requisitos AILA; base de contexto para a futura IA dos advogados. Sem transcrição crua.

create extension if not exists vector;
create table case_knowledge_chunks (
  id          bigint primary key generated always as identity,
  case_id     int references cases(id) on delete cascade,
  source_type text,   -- overview | transcript_summary | case_data | aila_requirement
  content     text,
  embedding   vector(N),
  metadata    jsonb default '{}',
  created_at  timestamptz default now()
);

case_agent_messages novo spec T-9

Chat do advogado com o agent sobre o caso (texto e áudio). O áudio é transcrito; o arquivo cru não é guardado.

create table case_agent_messages (
  id         bigint primary key generated always as identity,
  case_id    int references cases(id) on delete cascade,
  role       text check (role in ('user','agent')),
  content    text,
  source     text check (source in ('text','audio')),
  created_at timestamptz default now()
);

Sandbox de Agents (Settings) novo spec ativ. 5

Registro e governança dos agents: agent_registry (identidade + parent_slug + modelo + runtime_snapshot), agent_prompt_versions (histórico imutável, 1 ativa), agent_test_runs (playground, retenção 30d). Detalhe em specs/Yousa Agno/Studio e Sandbox/Tarefas/5-agent-sandbox/.

View do Painel de Prazos & Responsáveis proposto

União de documentos (prazo interno + responsável) e filings (deadlines por etapa) - alimenta a tela de prazos com filtros (responsável, tipo de caso, tipo de documento, demanda).

🔗
Relações: case_intake_reports.case_id → cases.id · documents.responsible_id → users.id · agent_client_messages.case_id → cases.id. Tudo gira em torno de cases, sincronizado com o Airtable pelo serviço de sync existente.
🔒
PII (COMP-04): clients/leads contêm PII; o agente lê o necessário e grava só o relatório. Mensagens ao cliente (agent_client_messages) e notas ficam no sistema, sem ferramentas externas.

Integrações

O que cada etapa precisa conectar e o estado atual no sistema.

IntegraçãoUsoStatus
Supabasebanco do sistema (leitura/escrita dos agentes e telas)existente
Sync Airtable↔Supabaseorigem dos casos (HubSpot→Airtable→Supabase) e espelhoexistente
OpenRoutermodelo dos agentes Agno (claude-sonnet-4.6)existente (no yousa-agno)
WhatsApp (Meta API)mensagens ao cliente + respostas (agente de kickoff)existente (reuso do NPS)
E-mailcanal alternativo de comunicaçãoa integrar
App mobile do clienteonboarding ("o app") + push/in-appa integrar (yousa-mobile)
Google Formsformulário de asiloa integrar
Google Calendar / Meetevento de kickoff + transcrição, via dash-backend (yousa-sales). Nosso backend não guarda creds Googlea integrar · contrato em setup-meet-sync-monorepo.md
Gemini (Google)captura do kickoff (notas + checklist)a integrar
HubSpotorigem do lead (comercial)existente · leitura direta fora do MVP do agente
yousa-sales (Supabase zgjuknnfigirxbcktddf)transcrições das reuniões de vendas (match por email/phone)a integrar · leitura read-only
AILA Research (Supabase uwjgumhqvqglffgqrcsu)requisitos por tipo de caso, via MCP (wrapper da API Fastify)base existe · MCP a criar
RAG do caso (pgvector no YousaLawDB)contexto do caso para o chat e a futura IA dos advogadosa criar
STT (transcrição de áudio)entrada por voz no chat do agent (Whisper via OpenRouter/OpenAI)a integrar

Documento de especificações · NEW FLOW LEGAL · sujeito à revisão do advogado responsável. Implementação não iniciada (exceto onde marcado "existente").

Automações

Orquestradas pelo backend (padrão do NPS: evento → ação). Princípios: transacional onde toca várias tabelas, idempotente (reexecutar não duplica), gate humano onde fala com cliente, fila no padrão sync_inbox (claim + lease + retry + DLQ) para trabalho assíncrono.

AutomaçãoGatilhoAçõesMecanismoStatus
Disparo do Intake
(ativ. 4)
caso entra na triagem (stage) backend chama o Agno → grava case_intake_reports + indexa no RAG do caso trigger/evento → endpoint (como o NPS) spec
Finalização do Setup
(ativ. 6)
Coordinator clica "Finalizar setup" cria petition_filings (prazos) + abre kickoff (client_appointments "waiting scheduling") + notifica o time (notifications) + avança o stage endpoint transacional + idempotente spec
Agendamento do Kickoff
(ativ. 7)
cliente confirma a data (via agent/Yousa Chat) client_appointments → "scheduled" + appointment_date + evento no Google Calendar (com Meet) + notifica o Attorney webhook Yousa Chat → agent → backend chama o dash-backend (create-and-enable): cria evento + liga transcrição, devolve google_event_id/google_space_id (retriável) spec
Captura de transcrição → RAG
(ativ. 8)
reunião do caso → status Finished fila aciona o meet-sync (dash-backend, leitura por google_event_id) → busca transcrição → indexa no case_knowledge_chunks (RAG) + cria atividade (notes_v2) trigger → fila meeting_transcript_jobs (claim+lease+retry/backoff+DLQ) spec
🔑
Integração Google fica num lugar só (decisão): o dash-backend (yousa-sales) é o único dono da integração Google (service account + Domain-Wide Delegation). Nosso backend não guarda credencial Google: chama POST /meetings/create-and-enable (cria evento + Meet + liga auto-recording/transcrição, devolve google_event_id/google_space_id) e GET /meetings/by-event/:id/transcript (leitura), só com MEET_SYNC_URL + MEET_SYNC_SERVICE_TOKEN. As creds Google já estão no Railway (projeto "Yousa sales"); única config nova: adicionar o scope calendar.events (RW) à DWD. Contrato documentado no yousa-sales (docs/setup-meet-sync-monorepo.md).

Garantias transversais

⚛️ Atomicidade

A finalização do setup roda as ações numa transação: falha em uma reverte tudo (nada parcial).

🔁 Idempotência

Reexecutar não duplica: filings, kickoff, notificações e ingestão de transcrição têm guardas por caso/reunião.

⏳ Assincronia

A transcrição do Google é assíncrona; a fila reprograma com backoff até existir e manda para DLQ no limite.

🤝 Gate humano

A mensagem inicial ao cliente exige aprovação do Attorney; o agent só conduz o agendamento depois.

🔔 Notificações

In-app (sino, notifications) para o time atribuído, com prioridade elevada quando há red flag crítica.

♻️ Reuso

Reaproveita o padrão do NPS (evento→ação), o trigger de client_appointments "Finished" e a fila sync_inbox.

🔗
Plataforma já existente reaproveitada: sync Airtable↔Supabase (origem dos casos), dispatch do NPS (WhatsApp/Meta + trigger client_appointments→Finished) e o meet-sync (Google Meet) do yousa-sales.

Specs completas: automações do setup em specs/Yousa Legal/Intake Setup/1 - Intake/Tarefas/6-setup-automations/, agendamento em specs/Yousa Legal/Intake Setup/2 - Pre-Kickoff/Tarefas/7-attorney-setup-kickoff/, captura de transcrição em specs/Yousa Legal/Intake Setup/4 - Kick Off/Tarefas/8-captura-transcricoes-caso/.

Agents & Sandbox

Em Settings/Agents: um ambiente para ver e governar todos os agents e sub-agents do sistema. Um agent criado no código aparece aqui automaticamente.

Como um agent entra no sistema

Cada agent declara um manifesto (slug, owner, descrição, modelo, tools, MCPs, parent_slug para sub-agents, talks_to_client). No boot do AgentOS, o registro é sincronizado e o agent passa a aparecer no Sandbox. Convenção em specs/Yousa Agno/Studio e Sandbox/Tarefas/5-agent-sandbox/REGISTERING-AN-AGENT.md.

🔑
Regra de ouro: o prompt no código é apenas o seed inicial. Em produção, a fonte do prompt é o Sandbox (DB). Editar o prompt no código não tem efeito depois do seed; muda-se pela tela.

O que o Sandbox oferece

📝 Prompt versionado

Histórico imutável, diff entre versões e reverter. Edição cria um draft; ativar coloca no ar (vale na hora, sem redeploy).

▶️ Playground

Testar com inputs reais (ex.: 10 leads), escolher o modelo (OpenRouter) e ver a saída + o trace dos sub-agents. Runs salvos (retenção 30d, COMP-04).

🛠️ Tools & MCPs

Funções nativas (com assinatura) e MCPs conectados (servidor + funções), capturados por introspecção + manifesto.

🧭 Sub-agents

Aninhados no agent pai; o trace mostra o resultado/diálogo de cada um quando o agent roda.

🤖 Modelo

Escolher o modelo por execução de teste e promover a padrão do agent (persistido no registry).

🛡️ Governança (COMP-06)

Editar/ativar/promover é restrito ao Coordinator; agents que falam com cliente exibem aviso de revisão de attorney.

💬 Chat (ativ. 11)

Sessão multi-turno com o agent da página, streaming (SSE), picker de modelo, painel de trace de tools e lista de conversas anteriores. Agent-scoped — distinto do chat do advogado sobre o caso. Retenção 30d (COMP-04); acesso restrito ao Coordinator.

Tabelas (Sandbox)

TabelaPapel
agent_registryidentidade do agent (+ parent_slug, modelo, runtime_snapshot de tools/MCPs)
agent_prompt_versionshistórico imutável de prompts (no máx. 1 ativa por agent)
agent_test_runsexecuções do playground (área de teste, retenção 30d)
agent_chat_sessions novoíndice das sessões de chat (ativ. 11) — agent, modelo, quem criou, status
agent_chat_messages novoconteúdo + trace sanitizado por mensagem (ativ. 11), retenção 30d via pg_cron

Spec completa em specs/Yousa Agno/Studio e Sandbox/Tarefas/5-agent-sandbox/ (plan + tarefas + QA + REGISTERING-AN-AGENT.md). Método Claude for Legal + Chat em specs/Yousa Agno/Agentes/Tarefas/11-legal-method-and-agent-chat/.