Mapa de integração do serviço v2 (FastAPI do Carlos)

Fonte: código recebido em 13/09 às 10h40, lido em temp/oab-v2/ na pasta de trabalho. Toda referência arquivo:linha abaixo aponta para esse diretório, salvo quando marcada como repo: (cópia já adaptada em apps/llm-service/). Nada aqui foi inferido de documentação: o que não está no código está dito como ausente.

Situação da cópia no repositório: diff -rq entre temp/oab-v2/ e apps/llm-service/ mostra que só main.py, app_gestao.py, core/db.py, core/workspace.py, .gitignore e requirements.txt diferem (as mudanças são nossas: variáveis de ambiente, CORS, rota JSON da cidadã, comprovante). Os demais arquivos são idênticos. Ou seja, a v2 é a mesma base que já está no repositório; este mapa descreve a v2 tal como veio e marca o que a cópia já resolveu.

1. Visão geral

O serviço é um monólito FastAPI com três fluxos sobre um mesmo SQLite (gestao.db) e uma mesma pasta de arquivos (workspace/{hash}/):

1. Destilação local de PDF (app_gestao.py:140-198 e :538-586): a pessoa logada envia um PDF, uma BackgroundTask roda protocolo_pdf.json em 14 chamadas sequenciais à Groq (core/pipeline_pdf.py:199-358) e grava memoria_persistente.json, texto_tagueado.json, resumo_humanizado.md e questoes.json.
2. Página pública da cidadã GET /t/{hash} (app_gestao.py:815-857): resumo em markdown, quiz de múltipla escolha, chat em SSE e download de um PDF "assinado" após aprovação.

Além disso, main.py:471-563 serve o chat de bastidores para quem está logado (index.html), com agentes definidos em protocolo.json e uma memória de sessão por login (core/session.py).

Módulos:

Como sobe hoje:

• python main.py executa uvicorn.run("main:app", host="0.0.0.0", port=8000, reload=True) (main.py:571). PORT não é lido em lugar nenhum; reload=True está fixo.
• Dependências pip puras (requirements.txt:1-9: fastapi, uvicorn[standard], jinja2, python-multipart, groq, sqlmodel, pypdf, reportlab, httpx). Não há python-dotenv, Dockerfile, Procfile, runtime.txt nem pyproject.
• Só três leituras de ambiente em todo o código: API_KEY (main.py:26-29), RESUMO_ESTRUTURADO_API_BASE
• Caminhos relativos ao diretório de trabalho (CWD): gestao.db (core/db.py:9-10), workspace/ (core/workspace.py:6-7, criado no import), workspace/_sessoes/ (core/session.py:29-30), protocolo_pdf.json (core/pipeline_pdf.py:38) e templates em app_gestao.py:30. Já main.py resolve templates, static, protocolo.json, help.md e contexto_persistente.json contra BASE_DIR (pasta do arquivo, main.py:39-48). Rodar com CWD diferente da raiz do serviço divide o app em dois.
• No import: init_db() cria tabelas e aplica ALTER TABLE (core/db.py:71-109, chamado em main.py:58), e cria admin@local / trocar123 com papel="fornecedor" se não existir, registrando a senha em claro no log (main.py:60-68).
• help.md não existe na árvore; GET /api/help devolve o texto padrão de main.py:166.

2. Rotas

Convenções: "cookie" = cookie sessao obrigatório via Depends(usuario_atual); sem cookie válido a resposta é HTTP 303 com Location: /login (core/auth.py:48-52), não 401. _permite_ver = tarefa própria, ou qualquer tarefa quando papel != "advogado" (app_gestao.py:60-61).

2.1 Sessão e login

2.2 Painel

2.3 Tarefas (destilação local)

2.6 Cidadã (públicas, sem autenticação; o hash de 22 caracteres é o único segredo)

Observação: a página cliente_view.html usa a última tentativa (app_gestao.py:837) para o cartão de assinatura, mas o PDF usa a melhor (:1001); melhor não tem desempate (core/attempts.py:84-90).

2.7 Bastidores e chat de quem está logado

3. Formas de dados

3.1 Modelos do banco (core/db.py:16-59)

Valores de status efetivamente gravados: criada (app_gestao.py:169, 291, 422, 559, 684, 730), processando falhou (pipeline_pdf.py:236, 251, 297), assinada (app_gestao.py:892). enviada só aparece na tupla de app_gestao.py:825 e nunca é gravado. Não existe concluida.

Datas são datetime.utcnow() sem fuso (naive UTC) em todos os modelos.

3.2 Tentativa e hash_imutavel (core/attempts.py:21-72)

aprovado = acertos >= max(1, int(total * 0.83))                       # :49, comentário diz "10/12"; int(12*0.83) = 9
hash_imutavel = sha256("PARA.AI|{tarefa_hash}|{numero}|{respostas_json}|{ip}|{ua}|{ts}")   # :25-26

Com 3 questões aprova com 2, com 6 com 4, com 12 com 9. O hash não tem salt e inclui IP, user-agent e timestamp: é recalculável a partir dos campos impressos no PDF assinado. ip vem de request.client.host (app_gestao.py:880), sem tratar X-Forwarded-For.

3.3 questoes.json (saída da T14, protocolo_pdf.json:165-174; gravado em core/pipeline_pdf.py:333-334)

{"questoes": [{"id": 1, "area": "identificacao|fatos|fundamentos|pedidos|contexto",
               "enunciado": "<= 120 chars, termina em ?", "alternativas": ["4 x <= 80 chars"],
               "correta": 0, "justificativa": "<= 120 chars", "dificuldade": "facil"}]}

A quantidade é inconsistente no próprio prompt: nome "T14 · 3 Perguntas Fáceis" (:167), missão "GERE 3 PERGUNTAS", "DISTRIBUIÇÃO OBRIGATÓRIA (total: 3)" cujos itens somam 3+4+2+2+1 = 12, contrato "id: inteiro sequencial 1 a 6" e "EXATAMENTE 6 objetos". A nova rodada pede 12 (app_gestao.py:752); a página diz "10 de 12" (cliente_view.html:248, 497) e "≥ 10/12" (:310). A correção usa len(questoes) em tempo de execução (core/attempts.py:40).

3.4 memoria_persistente.json (saída da T6, protocolo_pdf.json:77-85; gravado em core/pipeline_pdf.py:317-319)

{"memoria_persistente": {"identificacao": [item], "datas_valores": [item], "fatos": [item],
                         "fundamentos": [item], "pedidos": [item], "total_fragmentos": 0}}
item = {"campo": "<enum por classe>", "valor": "...", "trecho_verbatim": "<cópia exata do texto>",
        "pos_trecho_verbatim": "1234:1280", "sintese_relacao": null}

Enums de campo: identificacao autor|reu|juiz|advogado_autor|advogado_reu|ministerio_publico|testemunha|perito (:29); datas_valores data_fato|data_contrato|data_decisao|data_intimacao|prazo|valor_pedido|valor_contrato|valor_dano|valor_multa|valor_deposito (:40); fatos acontecimento_principal|fato_secundario|contexto|consequencia|dano (:51); fundamentos artigo_lei|artigo_cf|sumula|tema_repetitivo|jurisprudencia|principio|doutrina (:62); pedidos principal|sucessivo|subsidiario|liminar|expediente|custas|honorarios (:73). O texto da regra escreve a posição como "[inicio:fim]" e o exemplo obrigatório como "1234:1280" (:29); nenhum código em core/ lê esse campo, e nenhum código confere que trecho_verbatim é substring de texto_extraido.txt.

3.5 Sínteses com lastro T7..T11 (protocolo_pdf.json:88-140)

Uma por classe, gravada só como T7_SINTESE_FATOS.json ... T11_SINTESE_CONTEXTO.json (core/pipeline_pdf.py:304), sem consolidação e sem rota JSON; só via GET /tarefas/{id}/artefato/T7_SINTESE_FATOS.json com cookie (app_gestao.py:781).

{"sintese_fatos": {"campo": "sintese_fatos", "valor": "<1 a 3 parágrafos em linguagem simples>",
                   "lastro": ["fatos[0]", "fatos[1]", "datas_valores[0]"], "pos_trechos_origem": ["1234:1280"]}}

lastro indexa itens de memoria_persistente (é o elo tópico -> trecho literal). resumo_estruturado.json da API externa é outra fonte, com outro esquema (3.7); processo.resumo_classe_* citado em docs/LLM-API-CONTRACT.md pertence a essa API externa, não ao pipeline local.

3.6 resumo_humanizado.md (T13, tipo_saida: "texto", protocolo_pdf.json:154-162; core/pipeline_pdf.py:325-331)

Markdown de até 2800 caracteres com seções fixas: # Resumo em uma linha, ## 👥 Quem está nesta história, ## 📖 O que aconteceu, ## 💭 O que a pessoa sente e busca, ## 🤝 O que está sendo pedido, ## 🧭 Onde a história está agora. O prompt proíbe artigos, datas, número de processo, termos jurídicos e frases com mais de 15 palavras; dado ausente vira "não foi informado". Persona: história para uma criança de 10 anos (:161). Se o modelo devolver um dict, o código usa .resumo_humanizado ou .texto (pipeline_pdf.py:327-330).

3.9 Eventos log.jsonl (core/workspace.py:27-30)

Linha {"ts": iso utc, "tipo": str, ...extras}. Tipos: criada{tarefa_id, advogado_id}, pdf_salvo{nome, bytes}, pipeline_start{tarefa_id}, texto_extraido{chars}, task_start{id, idx, total}, task_done{id, tempo}, task_error{id, erro}, erro_extracao{erro}, erro_protocolo{erro} (só em LogEvento), pipeline_done{elapsed}, reprocessar, clonada{origem, rodada}, cliente_abriu{ip, ua}, tentativa{numero, acertos, total, aprovado, hash}, pdf_assinado_baixado{tentativa}, pdf_assinado_admin{tentativa}, resumo_estruturado_start|job|status|erro|done, jurisprudencia_start|job|status|erro|done. Em task_* o campo é id (T1_IDENTIFICADOR_PARTES ... T14_QUESTOES), não step.

3.10 Outros arquivos

• meta.json (app_gestao.py:176-184, 298-305, 429-437, 566-573, 738-745): {hash, titulo, advogado: {id, email, nome}, pdf_nome, pdf_bytes?, consulta?, criada_em, origem?}; clones: {hash, titulo, clone_de, clone_hash, rodada, criada_em}.
• workspace/_sessoes/{token}.json (core/session.py:26-35, 62-87): {jurisprudencia, resumo_estruturado, chat}, cada parte null ou {hash, titulo, processado_em, resumo_estruturado}; na aba chat, resumo_estruturado = {memoria_persistente, resumo_humanizado} (core/pipeline_pdf.py:344-356).
• contexto_persistente.json (main.py:180-202): lista global {role, content ("[USUARIO] ..." ou "[<agente>] ..."), timestamp, agent?}; hoje contém [].
• texto_tagueado.json (T12, protocolo_pdf.json:143-151): {"_ui": {classe: [{pos: "a:b", categoria, cor}]}} com cores fixas por classe.

4. Workflow protocolo_pdf.json

Cabeçalho (:2-17): workflow.start = "T1_IDENTIFICADOR_PARTES", workflow.output = {wrapper_key: "processo", id_key: "id_processo"}, workflow.defaults = {provider: "groq", modelo: "openai/gpt-oss-120b", max_completion_tokens: 10000, temperature: 0.0, stream: true, loop: true, parallel: false}. O executor lê apenas tasks e workflow.start (core/pipeline_pdf.py:255, 261) e, por task, id, nome, missao, modelo, tipo_saida, contexto_adicional, temperature, max_completion_tokens, transitions[0].target (:86-98, 264, 283, 313). defaults, output, provider, fase e reasoning_effort não são lidos. Padrões reais por task: temperature 0.0, max_completion_tokens 8000 (:97-98), top_p=1, stream=True, reasoning_format="parsed" com fallback se o SDK recusar (:99-108). Provedor: só Groq, via AsyncGroq criado em main.py:30 e passado ao pipeline.

Execução (core/pipeline_pdf.py:199-358): status="processando"; extração com pypdf; erro de extração ou de parse do protocolo -> falhou; loop sequencial seguindo transitions[0].target; cada task grava {id}.json; qualquer task com erro -> falhou e retorno (:296-298); ao final consolida memoria_persistente.json (T6), texto_tagueado.json (T12), resumo_humanizado.md (T13) e questoes.json (T14) por id fixo (:317-334, renomear uma task no JSON descarta o artefato em silêncio); status="pronta"; registra a aba chat na memória de sessão apenas quando session_token foi passado (:344-356), o que só /api/pdf/destilar faz. Sem retry, sem timeout, sem retomada: se o processo cair no meio, a tarefa fica processando para sempre e reprocessar responde 409 (app_gestao.py:670-671). O texto do PDF entra como dado dentro de uma etiqueta sorteada por chamada, que o papel de sistema nomeia, e o conteúdo do documento tem as etiquetas removidas antes de entrar; é a defesa contra injeção de prompt.

sem chave", api.py:22); polling GET /status/{job_id} a cada 1,5 s até done/error ou 600 s (api.py:30-31), erros de status são engolidos e o loop continua; depois GET /result/{job_id} e gravação dos arquivos. Timeouts httpx de 60 s (submit/result) e 30 s (status/rerun). Os hosts padrão não foram verificados como existentes.

5. Valores fixos que viram variável de ambiente

Lista consolidada de variáveis (nome, obrigatória, padrão, o que substitui):

6. Armazenamento e persistência

Tarefa.workspace_path guarda str(Path("workspace") / hash) (app_gestao.py:171 e equivalentes): se o diretório base mudar entre deploys, os registros antigos apontam para o caminho velho.

7. Deploy no Railway

O que a cópia em apps/llm-service/ já traz: Dockerfile (python:3.12-slim, WORKDIR /app, DATA_DIR=/data, CMD uvicorn main:app --host 0.0.0.0 --port ${PORT:-8000}) e railway.toml (builder Dockerfile, startCommand uvicorn main:app --host 0.0.0.0 --port $PORT, healthcheckPath = "/login", restartPolicyType = "ON_FAILURE"). Para a v2 pura, os pontos são:

• Start command: uvicorn main:app --host 0.0.0.0 --port $PORT --workers 1 --proxy-headers --forwarded-allow-ips='*'. Nunca python main.py (main.py:571 fixa 8000 e reload=True). --proxy-headers é o que faz request.client.host (app_gestao.py:842, 880) e request.base_url (:623) enxergarem o IP real e https atrás do proxy do Railway; sem isso todo hash_imutavel e todo PDF assinado registram o IP interno do proxy.
• Porta: só via $PORT no comando; o código não lê PORT.
• Workers: exatamente 1 processo e 1 instância. BackgroundTasks rodam no processo web (app_gestao.py:195, 312, 444, 583, 694, 755), SQLite é arquivo, o bootstrap do admin roda no import (main.py:58-70) e a memória de sessão é arquivo local. Um restart no meio do pipeline deixa a tarefa em processando sem recuperação.
• CWD: /app (raiz do serviço), por causa dos caminhos relativos listados na seção 1.
• Volume: montar em /data e apontar DATA_DIR=/data (cópia) ou, na v2 pura, fazer o CWD ser o volume e copiar templates/, static/ e protocolo_pdf.json para lá. Sem volume, cada deploy apaga banco, PDFs, tentativas e usuários.
• Estáticos: /static só monta se static/ existir ao lado de main.py (main.py:47-48); dashboard.html:7 aponta para /static/img/beeroot_ico.png, que não existe (404 inofensivo). As páginas carregam Tailwind, marked e Google Fonts de CDN; o navegador precisa de saída para esses hosts.
• Primeira execução: automática. init_db() cria tabelas e aplica ALTER TABLE idempotentes (core/db.py:71-109); criar_usuario_inicial insere o admin (main.py:60-68). Não há rota de cadastro: outros usuários entram direto no SQLite com core.auth.hash_senha. Trocar a senha antes de expor a URL.
• Variáveis mínimas: GROQ_API_KEY (na v2, API_KEY), ADMIN_PASSWORD, DATA_DIR, CORS_ORIGINS (origem do app na Vercel), CLIENT_APP_URL (para o painel gerar o link da cidadã apontando ao app), BASE_URL. Sem dotenv: definir nas variáveis do serviço.
• Health check: GET /login responde 200 sem cookie (app_gestao.py:67-73). As rotas com cookie respondem 303, não 401.
• CORS: a v2 não tem CORSMiddleware em nenhum arquivo; a cópia adiciona com CORS_ORIGINS (repo:main.py:44-49). Sem isso o app Next em outra origem não consegue chamar /api/t/{hash}, /quiz nem /chat pelo navegador. As rotas com cookie SameSite=Lax não funcionam cross-site de qualquer forma; o app Next não as usa.
• SSE: /api/t/{hash}/chat e /api/chat são POST com text/event-stream e X-Accel-Buffering: no (app_gestao.py:972, main.py:562); manter o proxy sem buffer. EventSource não serve (é POST): usar fetch + ReadableStream, como apps/web/lib/api.ts:44-68 já faz.
• Python: __pycache__ é cpython-312 e o código usa int | str em anotações (core/pipeline_pdf.py:203); 3.11+ serve, 3.12 testado localmente. Sem pacotes de sistema (pypdf e reportlab são puros).
• Duração: 14 chamadas sequenciais à Groq com 8k a 12k tokens por task e o texto inteiro em T1..T5; contar minutos por PDF e limites de taxa da Groq. Pré-processar os PDFs de exemplo antes da auditoria.
• Escrita no diretório do código: POST /api/protocolo reescreve protocolo.json (main.py:172) e /api/chat anexa a contexto_persistente.json (main.py:190); ambos somem no próximo deploy e exigem filesystem gravável.

8. Página da cidadã hoje e o que o app Next precisa

8.1 O que a v2 entrega hoje

• Espera: GET /t/{hash} devolve cliente_aguarde.html (spinner, tarefa.status, <meta refresh 5>) enquanto o status não é pronta/enviada/assinada (app_gestao.py:825-830). Não há rota JSON pública de status: /api/tarefas/{id}/status e /api/pdf/{hash}/log|destilado exigem o cookie de quem enviou (app_gestao.py:204, 228, 797).
• Página (cliente_view.html): cabeçalho com marca e tarefa.titulo (:228-232); cartão 1 com resumo_md renderizado por marked no navegador (:235-238, 357-368); cartão 2 com o quiz, inclusive data-correta (:253) e justificativa (:268) no HTML; cartão 3 "Assinatura digital" com hash_imutavel, data, numero, acertos/total e link para /t/{hash}/pdf-assinado quando a última tentativa foi aprovada (:290-314); gaveta de chat (:322-345).
• Não existe na v2 nenhum JSON público com a tarefa (título, status, resumo, questões, última tentativa). Esses valores só entram no HTML em app_gestao.py:845-857.

8.2 O que o app Next (apps/web) consome e de onde sai

O cliente em apps/web/lib/api.ts espera:

Para onde apontar: NEXT_PUBLIC_API_BASE = URL do serviço no Railway (apps/web/.env.example), e CORS_ORIGINS no serviço com a origem da Vercel.

8.3 Tópicos com trecho literal: de onde tirar

1. memoria_persistente.json (T6): cinco classes de itens {campo, valor, trecho_verbatim, pos_trecho_verbatim}; o trecho_verbatim é o que o app mostra como "trecho original".
2. T7_SINTESE_FATOS.json ... T11_SINTESE_CONTEXTO.json: um texto simples por classe com lastro apontando para os itens de (1). É o elo tópico -> trecho que o app precisa; hoje fica só em arquivo, sem rota JSON, e não é consolidado (core/pipeline_pdf.py:304, 317-334).
3. resumo_humanizado.md (T13): seis seções ## já em linguagem simples, sem nomes de lei nem datas; é o que a cópia usa como tópicos, com um casamento heurístico ao trecho (8.2).

Nenhum código (v2 ou cópia) verifica que trecho_verbatim é substring de texto_extraido.txt. A frase do app "Trecho conferido: copiado exatamente do seu documento" (apps/web/components/Journey.tsx:147) hoje não tem lastro em código; precisa de uma checagem server-side (substring, ou pos_trecho_verbatim contra o texto) antes de ser exibida.

8.4 Lacunas para o app Next

• GET /api/t/{hash} público: ausente na v2; presente na cópia (repo:leia/api_citizen.py). Precisa entrar na v2 do Carlos ou a cópia é o que vai ao ar.
• CORS: ausente na v2; presente na cópia.
• Resposta do quiz vaza o gabarito (erros[].correta, justificativa, alternativas) e a página do serviço embute data-correta no HTML. Para o app Next basta não renderizar, mas o JSON continua público: remover no servidor (core/attempts.py:108-116).
• Sem status de falha exposto de forma útil: com falhou, a cópia devolve questoes: [] e topicos: null (repo:leia/api_citizen.py:86-87) e o app fica repetindo a espera a cada 8 s (Journey.tsx:63).
• eventos[] da espera trazem id (T1_... a T14_...), idx e total; o app lê step (Journey.tsx:80), que não existe.
• ultima_tentativa é a última por numero (repo:leia/api_citizen.py:93, como em app_gestao.py:837), enquanto o PDF assinado usa a melhor. O app só olha aprovado (Journey.tsx:42), então funciona, mas os dois cartões podem divergir.
• Chat sem citação: a resposta é texto livre, a recusa ("não foi informado") depende só do prompt (app_gestao.py:932-942) e nada é gravado. ADR-0004 (citação literal e recusa explícita) não é atendido pelo serviço; o app não tem como mostrar sourceQuote na resposta.
• Quantidade de questões indefinida (3, 6 ou 12, seção 3.3): o app já lê total da resposta, o que basta.
• titulo da tarefa criada por /api/pdf/destilar é o nome do arquivo (app_gestao.py:167); o app o exibe em "Vou explicar o documento "{titulo}"" (Journey.tsx:104).
• Títulos das seções da T13 começam com emoji (## 👥 ...); viram titulo dos tópicos e são lidos em voz alta pelo SpeakButton (Journey.tsx:137).
• Sem rubrica, sem pergunta aberta, sem laço de reexplicação: "assinatura" = primeira tentativa de múltipla escolha que atinge o limiar (app_gestao.py:891-897). O app trata a reprovação com "Ler a explicação de novo" (Journey.tsx:223), que é o que dá para fazer com o que existe.

9. Privacidade e LGPD

Pontos de decisão para o produto:

• O hash_imutavel inclui IP e user-agent sem salt (core/attempts.py:25): quem tiver o PDF recalcula o hash, e o hash "prova" dados pessoais. Diverge de SPEC-001 (hash salgado sem nada pessoal). A cópia contorna gerando um payload canônico próprio (repo:leia/registry.py:48-72) com salt = hash_imutavel[:40] (repo:leia/api_citizen.py:110), mas o hash_imutavel original continua sendo gravado e impresso.
• O link /t/{hash} e suas APIs (quiz, chat, PDF) não expiram e não têm autenticação: quem tem o hash pode enviar tentativas que mudam o status para assinada, conversar sobre o documento e baixar o PDF com IP e navegador da pessoa que respondeu.
• O gabarito viaja ao navegador (cliente_view.html:253, 268) e na resposta do quiz (core/attempts.py:108-116).
• O chat público é um endpoint de LLM sem limite e sem autenticação (app_gestao.py:914-973), com custo e superfície de injeção (o resumo e a memória derivados do PDF entram no system prompt).
• O PDF assinado sai do pypdf/reportlab com metadados padrão (core/pdf_sign.py:140-168 nunca toca writer.metadata) e com o rodapé "Documento gerado automaticamente" (:127): contraria a regra da pasta de trabalho sobre metadados e marcadores de geração automática.
• Transcrições do chat da cidadã não são guardadas (app_gestao.py:946-967): não há registro do que ela perguntou nem do que foi respondido, além da linha da tentativa.

O que não deve ir ao repositório público (repos/leia): main.py com a chave (main.py:28), qualquer __pycache__ (a chave está em main.cpython-312.pyc), gestao.db, workspace/ (contém PDFs reais; o exemplo do Carlos tem um processo real com nomes), .env, _legacy/, protocolo.json.bak_historia_infantil (não referenciado). O .gitignore da v2 já cobre .env, *.db, workspace/, _legacy/ e __pycache__/ (.gitignore:1-8), mas não protege a chave que está no fonte: rotacionar a chave na Groq antes do primeiro push.

10. Perguntas em aberto para o Carlos

1. A v2 é a mesma base que já está em apps/llm-service/ (só nossos 4 arquivos diferem). Podemos publicar a cópia com GET /api/t/{hash}, CORS e variáveis de ambiente, ou você prefere aplicar essas mudanças na sua árvore e reenviar?
2. Quantas questões a T14 deve gerar de fato (3, 6 ou 12)? O prompt diz as três coisas (protocolo_pdf.json:167-173), a nova rodada pede 12 (app_gestao.py:752) e a página diz "10 de 12" (cliente_view.html:248). Com 12 o limiar int(12*0.83) aprova com 9, não 10 (core/attempts.py:49).
3. Podemos tirar correta, justificativa e alternativas de erros[] na resposta do quiz (core/attempts.py:108-116) e data-correta do HTML? O app não precisa deles e o JSON é público.
4. Podemos expor as sínteses T7..T11 (com lastro) e a memoria_persistente em uma rota JSON pública sem dados de quem enviou, ou consolidá-las em um topicos.json no fim do pipeline (core/pipeline_pdf.py:313-334)? É o que dá ao app o "trecho original" por tópico com lastro real, no lugar do casamento por palavras da cópia.
5. Aceita adicionar no pipeline uma conferência de que cada trecho_verbatim existe em texto_extraido.txt (substring ou pos_trecho_verbatim), marcando os que falham? Hoje nada confere (core/), e o app promete "copiado exatamente".
6. hash_imutavel com IP, user-agent e timestamp sem salt (core/attempts.py:21-26), e IP e navegador impressos no PDF (core/pdf_sign.py:105-106): podemos trocar pelo payload canônico salgado de SPEC-001 e tirar IP/UA do PDF? E manter ip/user_agent só no banco, ou nem isso?
7. request.client.host (app_gestao.py:842, 880) atrás do proxy do Railway vira o IP interno a menos que o uvicorn suba com --proxy-headers --forwarded-allow-ips='*'. Você concorda com esse start command?
8. As tarefas de /tarefas/nova, reprocessar e nova-rodada não passam session_token ao pipeline (app_gestao.py:583, 694, 755), então não atualizam a aba chat da memória de sessão; é intencional?
9. protocolo_jurisprudencia.json, _legacy/, protocolo.json.bak_historia_infantil e core/pd_extract.py (0 bytes, removido) não são usados por nada; podemos deixar fora do repositório público?
10. POST /api/protocolo reescreve protocolo.json no diretório do código (main.py:172) e GET /api/contexto mostra o histórico de todos os usuários (main.py:180-185, 503-505): manter assim para a demo ou desligar as duas rotas?
11. Chat da cidadã: aceita que a resposta traga o trecho_verbatim usado (ou um {"cita": ...} no SSE) e uma recusa explícita quando a resposta não está na memória, e que a conversa seja gravada em log.jsonl para virar transcrição?
12. Status: confirma que os valores finais são pronta e assinada, que enviada não é gravado por nada (app_gestao.py:825) e que falhou deve aparecer para a cidadã como "não deu certo, fale com quem enviou"?
13. Onde ficam os prompts do workflow para apontarmos em prompts/workflow/ (hoje só protocolo_pdf.json:19-185 e o system prompt inline em app_gestao.py:932-942)?