# Estado actual

Ultima actualizacao: 2026-08-25
Ambiente: apenas DEV
Versao: `pataniscAI-3.0.0-dev`
Git: repositorio `main` inicializado, ainda sem commit

Implementado no codigo-fonte: API autenticada, allowlist de IP, backend Ollama com o modelo mantido
em VRAM, transcricao em lote, validacao de limites, health check com estado da GPU, benchmark sem
dados pessoais, testes e instalador Windows.

Validado em 2026-08-25: 8 testes Python; smoke real da API contra o Ollama/RTX (4,2 s a frio e
0,48 s a quente numa imagem nao pessoal); lint e harness no PHP 7.3.33 do CT DEV; fallback real
para Tesseract com a API desligada; harness completo dos parsers Tesseract sem regressoes.

Instalado no PC Windows em `C:\pataniscAI` a 2026-08-25, com token local e tarefa agendada. O
`/health` local confirmou API pronta, Ollama 0.32.15, quatro modelos instalados e PaddleOCR-VL
carregado na RTX (940530727 bytes de VRAM).

Rede DEV concluida: a rota VPN foi acrescentada e a captura no Windows confirmou que a VPN faz NAT
do `.20` para `192.168.4.2`. A firewall e a allowlist aceitam apenas essa origem; `/health` remoto
respondeu em 0,14 s. A regra inicial para `192.168.69.20` rejeitava os pedidos por ver a origem NAT.
O `.env` do Sabichao DEV responde actualmente por HTTP; o cliente foi por isso alterado para ler
o token, por omissao, de `/etc/sabichao/pataniscai_token`, fora do webroot.

Baseline PaddleOCR-VL concluida nos 30 scans conhecidos, sem fallback: erros 14 -> 8, vazios
58 -> 97, media 40090 -> 18733 ms e p95 83156 -> 29532 ms. Reprova o gate de vazios e piora erros
em `naturalidade` e `val_rc`; formulario DEV continua em Tesseract. Detalhe em
`docs/baseline-paddleocr-vl-2026-08-25.md`. Holdout permanece intacto.

Afinacao Paddle em curso, sem alterar pesos:

- `val_rc`: o parser Tesseract escolhia a maior data como fallback, comportamento proibido na VLM.
  Ficaram duas transcricoes focadas (pagina completa + recorte inferior) e consenso de duas
  leituras; o fallback para a maior data continua desactivado na VLM. A tentativa adicional de
  validar pelos 90 dias oficiais foi rejeitada: a transcricao geral do Paddle nunca trouxe a data
  de emissao nos casos medidos, transformando todas as validades em vazio.
- `naturalidade`: scans 12 e 18 reproduzem 2 erros vindos das linhas rotuladas. O recorte focalizado
  foi instalado e testado, mas devolveu respostas sem o rotulo (66 a 3728 caracteres) e deixou o
  campo vazio nos 30 scans. A tarefa foi retirada do fluxo operacional; o prompt instalado fica
  dormente e inofensivo. A cobertura anterior foi restaurada.
- Regressao integral rejeitada: 30 scans, 2 erros mas `naturalidade=30 vazios` e `val_rc=30 vazios`;
  media 26501 ms e p95 38551 ms. Nunca promover estes numeros como melhoria.
- Testes actuais: 15/15 no PHP 7.3.33 real do CT DEV; lint PHP limpo. O formulario continua a usar
  Tesseract.
  Os testes Python completos não foram repetidos no Mac porque este checkout não tem `pytest`.

GLM-OCR medido e rejeitado. Foi necessário aplicar o prompt oficial `Text Recognition:` e parar
uma repetição infinita de blocos Markdown do pacote Ollama; num logótipo, 18,0 s/2400 tokens passou
para 0,58 s/36 tokens. Piloto de 5 scans: média 21517 ms, p95 23789 ms, boa cobertura de NCC,
validade CC e filiação, mas NISS 0/5 e `val_rc` 0/5, com 2 erros de naturalidade. O corpus integral
foi interrompido depois de o segundo processo exceder quase três minutos.

Decisao definitiva: trabalhar apenas com modelos OCR e fixar
`AuditAid/PaddleOCR-VL-1.6-0.9B:latest` (blob `71306567488b`). GLM-OCR foi rejeitado por lacunas e
latencia extrema. Qwen3-VL e Qwen3.5 foram excluidos por serem VLM generalistas; o ensaio Qwen3.5
teve controlo de 1,2 s, mas os cinco processos falharam por timeout e um diagnostico multipagina
mediu 42,5 s. O runtime Windows foi restaurado ao Paddle e o `/health` remoto confirmou
`ready=true`, modelo carregado na GPU e Ollama 0.32.15. Detalhe completo em
`docs/model-comparison-2026-08-25.md`.

Lote dos vazios ACEITE (2026-08-25, noite; so cliente PHP — API e modelo intocados): normalizacao
VLM->parser, consenso de documento do NISS e banding adaptativo em 2.a chamada para cartoes pobres.
Resultado nos 30 scans: zero erros novos, vazios 111->96 (niss 25->14, filho_de 17->14, ncc 18->17);
media 32,5 s / p95 49 s. Detalhe e regras de seguranca em `docs/baseline-paddleocr-vl-2026-08-25.md`
(seccao "Lote dos vazios"). O diagnostico provou que o Paddle quase nao transcreve fotos de cartoes
inteiras (84-88 chars de mediana) mas le bandas recortadas — e que ha ~1 falha transitoria por
timeout em runs continuos com a GPU quente.

Proximo passo (Fase 4, exige o ritual Windows): frente do CC — opcoes de geracao por tipo
(repeat_penalty/num_predict) e eventual prompt focado, guiados pelos eval_count do diagnostico.

Harness autónomo concluído no CT DEV: conta PROD `pataniscai_benchmark@192.168.4.2`, limitada por
coluna a `SELECT` nas duas tabelas do corpus; configuração DEV fora do webroot, `root:www-data`
`0640`; pipe sem persistência, runner background com lock e holdout recusado. PHP 7.3, selftests,
46 fixtures e ligação real passaram. Reprodução autónoma: 30/30, zero falhas, Paddle 5 erros/96
vazios, média 32944 ms e p95 49584 ms; Tesseract 14/58, 40090/83156 ms. O processo sobreviveu ao
fecho da sessão SSH; holdout e concorrência foram recusados com exits 2/5. Detalhe em
`DEPLOY-UPDATE-2026-08-25-HARNESS-CT.md`.

Fase 4 da frente do CC instalada no Windows: prompt e opcoes curtas apenas para
`cc_frente_identificacao`, com PaddleOCR-VL congelado. O instalador concluiu, 15/15 testes Python
passaram e `/health` confirmou `ready=true`, modelo carregado na GPU e Ollama 0.32.15.

Regressao encontrada e corrigida (2026-08-26): as bandas focadas `bf1`/`bf2` reenviavam o MESMO
recorte que a banda geral homologa (centro/sul), e a contagem de corroboracao no cliente PHP contava
por STRING, nao por posicao fisica — duas copias do mesmo recorte (mesmo lixo, `temperature=0`)
confirmavam-se uma a outra. Corrigido em `funcoes/pataniscai_client.php` do develop: corroboracao
passa a contar posicoes distintas (norte/centro/sul/principal). Reproduzido autonomamente no CT
(30/30, zero falhas): 5 erros/90 vazios, os mesmos 5 erros ja conhecidos (nada novo), vazios
melhores que o lote anterior (ncc/validade_cc/niss/filho_de a 14 cada). Detalhe em
`/Volumes/www/develop/docs/PROJECT_STATE.md` (secção "Corrigida regressão na corroboração de
bandas") e `docs/DECISIONS.md` do mesmo repo.

Baseline corrente depois da correcao, log autonomo
`development-20260826-001401.log`: 30/30, zero fallback, 5 erros/90 vazios, media 33980 ms e p95
50118 ms. `ncc` e `validade_cc`: 16 certos, 0 errados, 14 vazios cada. O runtime focado esta
comprovado por 40 tarefas com `eval_count<=160`.

E2E real no formulario DEV concluido em 2026-08-26 sobre um processo ja exposto do corpus Protek,
montado em modo apenas leitura: scan 16, `engine_version=pataniscAI-3.0.0-dev`, sucesso, 3/3
documentos OCR, 11 campos, zero avisos e 16454 ms. O formulario nao foi submetido. O Sabichao DEV
foi logo reposto em Tesseract e no caminho NAS normal. A prova final de fallback passou com a tarefa
Windows parada: pedido pataniscAI caiu integralmente para Tesseract, 3 documentos, sucesso,
`fallback=tesseract`, um aviso e 24248 ms. A tarefa foi reiniciada e `/health` confirmou
`ready=true`, PaddleOCR-VL carregado na GPU e Ollama 0.32.15. E2E e fallback estao fechados;
segue-se a afinacao de `val_rc`. Holdout continua fechado.

Producao permanece intocada. O Tesseract continua a ser referencia e fallback.

Candidato `val_rc` preparado, ainda nao instalado no Windows: o scan 31 provou que a pagina geral
era reenviada sem recorte e contava como confirmacao da propria leitura errada. O cliente passou a
usar evidencia identificada e dois recortes geometricamente distintos; a tarefa nova transcreve
emissao+validade sem calcular datas. Fixture RED, 58/58 testes PHP 7.3 e harness Tesseract passaram.
Com o cliente corrigido e a API antiga, o scan 31 passou de erro a vazio. Pacote, hash, validacoes e
rollback em `DEPLOY-UPDATE-2026-08-26-VAL-RC1.md`.

Projeto VLM colocado em pausa por decisao do utilizador em 2026-08-26, para avaliar Apple Vision
como motor OCR no futuro Mac mini 24/7. A tentativa de instalar o candidato `val_rc` no Windows
nao concluiu: o ZIP nao existia no destino, o pytest recebeu `--basetemp` sem argumento e o pip nao
conseguiu substituir `pataniscai-api.exe` por estar em uso. O `/health` posterior confirma apenas
o runtime Paddle anterior, ainda operacional. Nao correr benchmark nem abrir holdout enquanto a
comparacao Apple Vision nao estiver concluida.