LeIA
Entender antes de assinar. LeIA pega o documento jurídico que a pessoa recebeu, explica em português simples
com o trecho original sempre ao lado, responde dúvidas apenas com o que está escrito ali, confere se ela entendeu
e emite um comprovante verificável desse entendimento. Um advogado revisa e libera antes de o link chegar ao cidadão.
Hoje fica registrado que a pessoa recebeu o documento. Não fica registrado que ela entendeu.
A plataforma não presta consultoria, não interpreta o caso concreto e não substitui o advogado.
Os limites estão escritos em docs/POSITIONING.md e aparecem na própria interface.
O que o sistema faz
- Entrada. O documento entra pela conta do advogado ou pela conta do próprio cidadão. Um pipeline de 14 tarefas
lê o PDF, separa as cláusulas e escreve a explicação, sempre com o trecho literal que a sustenta.
- Revisão humana. Quando quem enviou é advogado, nada chega ao cidadão antes da aprovação dele.
- Leitura. O cidadão percorre um tópico por vez, ouve o texto se quiser e pergunta o que não entendeu.
A resposta cita o trecho; pergunta fora do documento recebe recusa explícita.
- Conferência. Perguntas de compreensão com correção por rubrica, número de tentativas limitado,
e ponto a rever quando erra.
- Comprovante. JSON canônico, SHA-256 e carimbo de tempo por OpenTimestamps. O comprovante traz um QR
para conferência por terceiro. Nenhum dado pessoal vai para o registro público.
Demonstração
Em "Ver um exemplo" a jornada roda sobre uma tarefa real, processada pelo pipeline a partir de
examples/contrato-honorarios-exemplo.pdf, que é um contrato fictício.
Arquitetura
apps/web Next.js 16 · React 19 · Tailwind 4 · PWA instalável
app/ telas da cidadã, painel do advogado, comprovante, verificação pública, docs
components/ primitivas de interface e componentes de jornada
lib/ cliente da API, markdown das docs, espelho do registro em TypeScript
apps/llm-service FastAPI · SQLModel · Postgres · Groq (openai/gpt-oss-120b)
leia/ API v3: contas, documentos, dúvidas, registro público e carimbo
core/ banco, autenticação, tentativas, workspace, PDF do comprovante
protocolo_pdf.json pipeline declarativo de 14 tarefas
mock/ serviço falso, roda a interface inteira sem chave de modelo
O navegador fala só com o app, e o app fala com o serviço. Quem faz a ponte são as rotas em app/api/*, que
encaminham para o endereço em SERVICE_URL ou respondem pelo mock interno quando não há serviço configurado.
É esse desenho que permite a sessão viver num cookie que script de página não alcança, porque cookie não
atravessa origens. O contrato entre os dois está em
docs/API-V3-CONTRACT.md; os diagramas de caso de uso e de sequência, em
docs/USE-CASES.md; as decisões e o fluxo de dados, em docs/ARCHITECTURE.md.
Como rodar
Pré-requisitos: Node 24 com pnpm 9, Python 3.12. Nada mais é obrigatório para ver a interface inteira.
Só a interface, sem chave de modelo
git clone https://github.com/deegalabs/leia.git && cd leia/apps/web
pnpm install
pnpm dev # http://localhost:3000, usando o mock interno
Sistema completo
# 1. serviço cognitivo
cd apps/llm-service
python3 -m venv .venv && . .venv/bin/activate
pip install -r requirements.txt
cp .env.example .env # preencha GROQ_API_KEY e ADMIN_PASSWORD
set -a; . ./.env; set +a
uvicorn main:app --port 8000
# 2. aplicação, em outro terminal
cd apps/web
printf 'SERVICE_URL=http://localhost:8000\n' > .env.local
pnpm install && pnpm dev
Sem chave da Groq, troque o serviço pelo mock: uvicorn mock.app:app --port 8000.
Detalhes de cada lado em apps/llm-service/README.md e
apps/web/README.md.
Testes
cd apps/llm-service && .venv/bin/python -m pytest -q
cd apps/llm-service && .venv/bin/python -m evals.run # bateria de avaliação do motor
cd apps/web && pnpm test && pnpm lint && pnpm build
A bateria mede o que o motor promete, sobre casos gravados de tarefas reais, sem chave de modelo.
O que ela mede e o que ela deliberadamente não mede está em apps/llm-service/evals/README.md.
Os mesmos comandos rodam na integração contínua a cada pull request.
Como contribuir
O caminho é sempre issue, branch, pull request. Ninguém escreve direto na main.
- Abra uma issue com um dos modelos (erro,
melhoria) e espere a issue ser aceita antes de escrever código.
- Crie a branch a partir da
main, nomeada pelo tipo e pelo número da issue: fix/123-nome-curto,
feat/124-nome-curto, docs/125-nome-curto.
- Escreva o teste antes da correção. O teste precisa falhar por causa do problema, e só então o código muda.
Um teste que já nasce passando não prova nada.
- Commits em inglês, no padrão Conventional Commits,
escopo no nome do app:
fix(web): ..., feat(service): ..., docs: ....
- Abra o pull request apontando a issue que ele fecha. A integração contínua roda sozinha e a Vercel publica
uma prévia da aplicação.
- O merge exige uma aprovação e a integração contínua verde. Depois do merge na
main, a aplicação e o serviço
sobem em produção automaticamente.
O guia completo, com a divisão de pastas e o que nunca entra no repositório, está em
docs/CONTRIBUTING.md.
Regras que valem para todo mundo
- Interface e documentação em português simples, sem juridiquês e sem travessão. Código, identificadores e commits
em inglês.
- Nenhum dado pessoal real em
examples/ ou evidence/. Chave de API nunca entra no repositório, só em variável
de ambiente.
- Nenhuma afirmação sobre o documento sem o trecho literal que a sustenta.
- Arquivo gerado pela plataforma não carrega metadado de ferramenta.
Configuração do repositório
| Item | Como está |
|---|
| Branch de produção | main, protegida: pull request obrigatório, uma aprovação, CI verde, sem force push |
| Integração contínua | .github/workflows/ci.yml, testes do serviço e do app em todo pull request |
| Aplicação | Vercel, projeto leia, diretório raiz apps/web, produção na main, prévia por pull request |
| Serviço | Railway, projeto leia, serviço llm-service, diretório raiz apps/llm-service, deploy na main |
| Sinal de vida | GET /health no serviço, é ele que autoriza a versão nova a assumir |
| Segredos | variáveis de ambiente nas duas plataformas, nunca no repositório, modelo em .env.example |
Documentação
Conferir um registro sem depender do serviço: scripts/verify_cli.py registro.json <hash>.
Origem e licença
Nasceu no Hackathon da Cidadania OAB-PR, 6ª edição, Curitiba, 12 e 13 de setembro de 2026, na categoria Inovação
Aberta e Cidadania. Mantido pela Deega Labs. Licença MIT.
