Especificações técnicas
Consolidação do que foi definido para telas, processos e banco de dados do NEW FLOW LEGAL.
Escopo e status
| Item | Tipo | Status |
|---|---|---|
| Agente de Intake/Triagem (ativ. 4) | Agente Agno | spec completa |
| Sandbox de Agents (ativ. 5) | Settings: governança dos agents | spec 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 Sandbox | spec completa |
| Automações do Setup (ativ. 6) | Notificações + kickoff + filings | spec completa |
| Attorney Setup & Kickoff (ativ. 7) | Agente Agno (Yousa Chat, ativ. 37); agendamento Google via dash-backend | spec completa |
| Captura de transcrições → RAG (ativ. 8) | Fila + meet-sync + ingestão | spec completa |
| Agente do Caso (na tela do caso) | Agente Agno (consome o RAG) | a planejar |
| Telas (operação + Sandbox) | UI | protó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.
Processos (fluxo)
As etapas do caso, seus gatilhos, atores e onde entram IA/automação. Detalhe completo nos documentos de fluxo.
| Etapa | Gatilho | Atores | IA / Automação | Saída |
|---|---|---|---|---|
| 1. Intake / Triagem | case entra na triagem | Coordinator | Agente 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" | Coordinator | automação: finalização do setup (ativ. 6) cria filings+prazos, abre kickoff, notifica o time, avança o stage | equipe, estratégia, filings + deadlines |
| 3. Attorney Setup & Kickoff | handoff do Coordinator | Attorney 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. Kickoff | data confirmada → reunião → Finished | Attorney + cliente | Gemini grava/extrai notas + automação: captura da transcrição → RAG (ativ. 8) | notas + checklist + transcrição no RAG do caso |
| 5. After Kickoff Setup | kickoff encerrado | Attorney BR | valida checklist/notas da IA; automação: notifica responsáveis + alimenta o painel de prazos | responsáveis + prazos internos por doc/filing |
| 6. Produção & Filings | prazos definidos | equipe | painel de prazos (cruza filing + documentos) | filings (delivery / final / protocolo) |
Documentos de fluxo: Intake · Coordinator · Attorney Setup · Kickoff · After Kickoff.
Agentes de IA
Stack: Agno v2 (AgentOS) sobre OpenRouter; o backend orquestra os disparos. Gemini é usado na captura do kickoff (ecossistema Google).
| Agente | Entrada | Saída | Modelo | Integrações |
|---|---|---|---|---|
| Intake / Triagem spec completa | case_id + lead + transcrições + AILA | case_intake_reports + RAG do caso | OpenRouter (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 aprovada | conversa + intent=confirmed + data confirmada | OpenRouter | Yousa 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 caso | respostas com fontes | OpenRouter | RAG do caso, AILA (MCP) |
| Captura de Kickoff (notas) mapeado | reunião gravada | notas + checklist | Gemini (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-agent | Pai | Função |
|---|---|---|
| Resumo de transcrições | Intake | resume as reuniões de vendas em sinais úteis |
| Requisitos AILA | Intake | consulta a AILA (MCP) e monta os requisitos do tipo de caso |
| Team Fit Analyst | Intake | sugere 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).
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.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).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.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.
| Tela | Propósito | Componentes | Fonte de dados |
|---|---|---|---|
| Dashboard (operação) | visão de coordenação | CounterCard, tabela, bars, listas | cases, documents/petition_filings, case_intake_reports, case_team |
| Painel do Attorney | ações pendentes do attorney | cards de ação, tabela, listas | cases (do attorney), client_appointments, agent_client_messages, deadlines |
| Casos (lista) | listar/filtrar casos | ag-grid + chips de filtro | cases + clients + case_team + view de deadlines |
| Detalhe do caso | visão 360 do caso | tabs, timeline, tabelas | cases, case_intake_reports (Triagem), documents, petition_filings, notes_v2 |
| Calendário | deadlines + kickoffs | FullCalendar | documents.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 prontos | threads com badge de contexto, chips de filtro, mensagens com avatar, status de espera, caixa de resposta | notes_v2 |
case_intake_reports, case_agent_messages, RAG do casoagent_registry, agent_prompt_versions, agent_test_runsAbrir protótipo: Dashboard · Painel Attorney · Casos · Detalhe · Calendário · Coordinator Setup · Sandbox.
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
| Tabela | Papel no fluxo |
|---|---|
cases existente | entidade central; stage dirige o pipeline; case_type, strategy |
clients / leads existente | dados do cliente/lead (origem HubSpot→Airtable→sync) |
case_team existente | equipe (case↔user↔role); base de workload e histórico do time |
documents existente | checklist de documentos do caso |
document_types / checklist_types / demand_types existente | catálogo por case_type (referência de requisitos/checklist) |
petition_filings existente | filings do caso |
client_appointments existente | Case Event de Kickoff (type='kickoff', status "waiting scheduling"→"scheduled") |
notes_v2 existente | notas 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).
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.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ção | Uso | Status |
|---|---|---|
| Supabase | banco do sistema (leitura/escrita dos agentes e telas) | existente |
| Sync Airtable↔Supabase | origem dos casos (HubSpot→Airtable→Supabase) e espelho | existente |
| OpenRouter | modelo 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) |
| canal alternativo de comunicação | a integrar | |
| App mobile do cliente | onboarding ("o app") + push/in-app | a integrar (yousa-mobile) |
| Google Forms | formulário de asilo | a integrar |
| Google Calendar / Meet | evento de kickoff + transcrição, via dash-backend (yousa-sales). Nosso backend não guarda creds Google | a integrar · contrato em setup-meet-sync-monorepo.md |
| Gemini (Google) | captura do kickoff (notas + checklist) | a integrar |
| HubSpot | origem 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 advogados | a 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ção | Gatilho | Ações | Mecanismo | Status |
|---|---|---|---|---|
| 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 |
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.
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.
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)
| Tabela | Papel |
|---|---|
agent_registry | identidade do agent (+ parent_slug, modelo, runtime_snapshot de tools/MCPs) |
agent_prompt_versions | histórico imutável de prompts (no máx. 1 ativa por agent) |
agent_test_runs | execuçõ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 novo | conteú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/.