chat through the deployed stack
PASS 6/6: inferencia executada de ponta a ponta na stack de producao (Open WebUI -> Small Router -> vLLM no Spark), health check 200 OK e card HUD em tela
Aceite MVP V1 — evidências em vídeo
Matriz de entregáveis E1–E11 · veredito do auditor (matriz, preservado) +
aceite do dono (ianffcs, 2026-09-17) + evidência por cenário ·
topologia observada comprova E2 ·
Apresentação de entrega ·
Arquitetura ·
Segurança ·
Auditabilidade ·
Stack ·
Superfícies ·
Futuro ·
Apêndice: tecnologias (pros/cons + referências) ·
Galeria de runs ·
gerado por build_page.py
11entregáveis
24vídeos de evidência
11aceite do dono (E1, E10, E11, E2, E3, E4, E5, E6, E7, E8, E9)
AI Factory — Commitment & Delivery Review
Vocabulário da reunião: COMBINADO = escopo combinado (matriz de aceite E1–E11) → ENTREGUE = o que foi efetivamente entregue e aceito (dono, 2026-09-17) → EVIDÊNCIA = prova verificável neste bundle → DELTA = o que ainda resta. Cada linha deriva das mesmas fontes da página (matriz, aceite do dono, dossiês, vídeos) — nada digitado à mão.
Matriz compromisso × entrega (E1–E11)
| Entregável | Escopo combinado | Entregue | Estado | Evidência | Delta |
|---|---|---|---|---|---|
| E1 | Dossiê de escopo e governança | Os cenários revelam casos de uso e riscos testados. | ✓ Aceite do dono — validado · 2026-09-17 | Dossiê Matriz Classificação Métricas | Contraprova de pcms e da auditoria (§4) |
| E2 | Ambiente dedicado alugado e isolado | O portal e a inferência estão acessíveis em um ambiente implantado. | ✓ Aceite do dono — validado · 2026-09-17 | Capacidade Isolamento Rede Acessos Snapshots | Evidência documental do dossiê §3 |
| E3 | Portal seguro de uso | Dois cenários SSO mostram redirecionamento, login e retorno ao portal; chat e upload também funcionam. | ✓ Aceite do dono — validado · 2026-09-17 | chat-through-the-deployed-stack model-switch-preserves-context onboarding-first-login-through-first-inference signing-out-invalidates-the-session sso-through-keycloak-oidc stop-generation-halts-response | — |
| E4 | Identidade, papéis e revogação | SSO funciona; sign-out invalida a sessão; documentos de dois usuários ficaram isolados. | ✓ Aceite do dono — validado · 2026-09-17 | a-normal-account-is-refused-the-admin-surface concurrent-users-do-not-interfere invalid-credentials-show-error onboarding-first-login-through-first-inference session-timeout-preserves-context signing-out-invalidates-the-session sso-through-keycloak-oidc user-profile-shows-correct-info Acesso RBAC Revogação | Correção por script manual (t3-keycloak-realm.sh) |
| E5 | Base de conhecimento governada | Upload e respostas fundamentadas passaram; segundo usuário não recuperou o documento do primeiro. | ✓ Aceite do dono — validado · 2026-09-17 | a-second-account-cannot-see-the-first-accounts-document concurrent-users-do-not-interfere corpus-rag-answers-without-leaking document-upload-rag-query ocr-document-upload-query rag-access-control rag-access-control-readonly rag-answers-from-an-uploaded-document | — |
| E6 | Orquestração e inferência soberana | Dois chats ponta a ponta e dois fluxos RAG produziram respostas do modelo. | ✓ Aceite do dono — validado · 2026-09-17 | chat-through-the-deployed-stack model-switch-preserves-context | — |
| E7 | Portal de saída não contornável | Documento envenenado foi resumido sem obedecer à instrução injetada em três tentativas. | ✓ Aceite do dono — validado · 2026-09-17 | corpus-rag-answers-without-leaking pii-is-redacted-in-the-assistant-turn poisoned-document-does-not-exfiltrate privacy-visibility-scrubs-pii rag-answers-from-an-uploaded-document | — |
| E8 | Stop Chain / fail-closed | O teste de documento envenenado não exfiltrou conteúdo. | ✓ Aceite do dono — validado · 2026-09-17 | egress-stamp | — |
| E9 | Trilha de auditoria imutável | Os logs de teste registram passos e assertivas. | ✓ Aceite do dono — validado · 2026-09-17 | audit-integrity operator-only-audit-surface | — |
| E10 | Pacote de validação e baseline | Há 24 gravações no bundle (24 cenários distintos: 16 de 2026-09-18, 6 de 2026-09-19 e 2 de 2026-09-02 — egress-stamp e audit-integrity). As… | ✓ Aceite do dono — validado · 2026-09-17 | concurrent-users-do-not-interfere | Fix do gate de modelos não commitado (2026-09-22) |
| E11 | Automação, operação e handover | A existência de um ambiente implantado e testes automatizados sugere trabalho operacional. | ✓ Aceite do dono — validado · 2026-09-17 | Implantação Smoke Runbooks Backup Treinamento Reimplantação | — |
Delta restante — o que ainda falta
- E1 — Contraprova de pcms e da auditoria (§4). Aprovado pelo dono (ianffcs, 2026-09-17); pcms e auditoria assim que assinarem — não pode ser preenchido por outra parte. §1 revisada em 2026-09-22 para o commit c4d5804. refs/governance-mvp-v1.md
- E2 — Evidência documental do dossiê §3. Fatos fora do repo a preencher: termo do provedor, acesso administrativo do provedor, inventário de acessos, política de retenção de snapshots. refs/DOSSIER-MVP-V1-e2-ambiente-alugado.md
- E4 — Correção por script manual (t3-keycloak-realm.sh). Mapper idempotente de role corrigiu o /admin/users, mas a correção rodou fora do deploy ansible — invariante de deploy ainda aberta (dossiê §6). refs/DOSSIER-MVP-V1-admin-access.md
- E10 — Fix do gate de modelos não commitado (2026-09-22). Revalidação de 2026-09-22 (pinha @ 89ad23c) achou 3 NPEs no novo gate de modelos (inference_proxy.clj:1088, c4d5804): ele lia registry/snapshot mesmo quando o gate não se aplica — fixtures de model-policy/redact não fornecem backends. Fix aplicado na árvore local: hot/was-hot só são lidos quando o gate pode recusar (roles resolvidos, não-operador). Unit: 903 testes / 2645 asserções / 0 falhas; os 5 testes dos 2 namespaces afetados verdes; lint 0/0. Os 15 demais erros da suíte completa eram Docker ausente na estação (testcontainers). Pendência: commitar o fix (8/6 linhas em inference_proxy.clj). pinha apps/small-pine @ 89ad23c · suíte de 2026-09-22
E1
Dossiê de escopo e governança
✓ Aceite do dono — validado · 2026-09-17
evidência: COMPROVADA
Evidência positiva — Os cenários revelam casos de uso e riscos testados.
✓ Aceite do dono — validado · 2026-09-17
Dossiê de governança assinado por ianffcs: papéis, corpus e métricas M1–M8 aprovados.
| Dimensão | Como é comprovada | Artefato |
|---|---|---|
| Dossiê aprovado | ✅ Assinado por ianffcs em 2026-09-17 — papéis (§1), corpus (§2) e métricas (§3) aprovados pelo dono. | refs/governance-mvp-v1.md · refs/DOSSIER-MVP-V1-e1.md |
| Matriz de papéis | ✅ config.clj ::roles-config (operator/admin/user/teste); allowlists :rags/:models fail-closed; ianffcs/pcms → ::operator. | refs/governance-mvp-v1.md · config.clj ::roles-config |
| Classificação do corpus | ✅ Extensões → classe (.md = conhecimento, .clj/.edn/.py = código/config); scrub de PII (Presidio pt-BR + OpenMed). | refs/governance-mvp-v1.md · ingest-pinha-corpus.clj |
| Métricas de sucesso | ✅ M1–M8 aprovadas pelo dono como baseline do MVP V1. | refs/governance-mvp-v1.md |
E2
Ambiente dedicado alugado e isolado
✓ Aceite do dono — validado · 2026-09-17
evidência: COMPROVADA
Evidência positiva — O portal e a inferência estão acessíveis em um ambiente implantado.
✓ Aceite do dono — validado · 2026-09-17
Ambiente dedicado e isolado comprovado por OpenTofu Vultr + Ansible + PF; inferência soberana em hardware próprio. RESSALVA: evidência documental (6 itens do dossiê §3) segue a preencher.
Evidência · chatsubo-network-architecture.svg
Como comprova — Topologia observada ao vivo: ambiente dedicado e isolado, inferência soberana em hardware próprio. Um ingresso público único (cloud firewall 80/443 + SSH de dois /32), perímetro real por jail (block in all + allowlist), 8 bridges disjuntas + lo1 sem bridge, egress do small-pine limitado a 10 peers nomeados, travessia de plano só por 3 relays socat nomeados.
| Dimensão | Como é comprovada | Artefato |
|---|---|---|
| Capacidade dedicada | ✅ Vultr vc2-2c-4gb dedicada (2 vCPU, 4096 MB RAM), IPv4 reservado, prevent_destroy. ⬜ termo do provedor (dossiê §3 item 1). | opentofu/chatsubo-vultr/main.tf · variables.tf · refs/DOSSIER-MVP-V1-e2-ambiente-alugado.md |
| Isolamento do provedor | ✅ Root OpenTofu separado, estado cifrado no Vault, domínios de falha independentes. ⬜ evidência de que o provedor não tem acesso administrativo (dossiê §3 item 3). | docs/plans/chatsubo-vultr-provisioning.md · opentofu/chatsubo-vultr/ · refs/DOSSIER-MVP-V1-e2-ambiente-alugado.md |
| Rede | ✅ 20 jails em planos disjuntos: 7 jails VNET (bridge0–6), 4 no plano Slurm trusted (bridge9) e 9 em lo1 sem bridge; PF por jail (block in all + allowlist), cloud firewall como único ingresso público (TCP 80/443 + SSH de dois /32). | ansible/roles/ (por jail) · deployer/services/small-pine-jail/ · chatsubo-network-architecture.svg · docs/network-topology.md · docs/deliverables-assessment.md §2 |
| Acessos privilegiados | ✅ SSH restrito por CIDR (/32 bootstrap + /32 NeoTek), key-only, host key pinada; transação protegida com rollback; doas não-interativo. ⬜ inventário de acessos (dossiê §3 item 6). | opentofu/chatsubo-vultr/main.tf (bootstrap_ssh, neotek_ssh) · scripts/operator/safe-access-apply.sh · roles/access-safety/ · refs/DOSSIER-MVP-V1-e2-ambiente-alugado.md |
| Snapshots | ✅ ZFS Ansible em disco secundário (AES-256-GCM, cron semanal), system-snapshot.yml com retenção (3 gerações), tfstate cifrado. ⬜ política de retenção documentada (dossiê §3 item 5). | deployer/services/zfs-backup/ · ansible/playbooks/system-snapshot.yml · opentofu/chatsubo-vultr/main.tf · refs/DOSSIER-MVP-V1-e2-ambiente-alugado.md |
Inferência soberana — a produção não atravessa o small-infer router do NeoTek nem API de terceiro: Small Pine é dono de sbatch/squeue/scancel por SSH pinado (TCP 22) a user@enverge.dev e alcança o modelo agendado por esse transporte; os nós DGX entram no controller Slurm trusted do Chatsubo pelo overlay wg2. A inferência roda em hardware próprio do operador, dentro do ambiente dedicado e isolado acima.
E3
Portal seguro de uso
✓ Aceite do dono — validado · 2026-09-17
evidência: COMPROVADA
Evidência positiva — Dois cenários SSO mostram redirecionamento, login e retorno ao portal; chat e upload também funcionam.
✓ Aceite do dono — validado · 2026-09-17
Portal seguro de uso: SSO, chat ponta a ponta, troca de modelo e sign-out — todos com vídeo.
model switch preserves context
Re-executado com sucesso: o teste aciona o seletor de modelos no topo da conversa, valida a selecao e comprova a preservacao do contexto de memoria entre os turnos (4/4 assercoes).
onboarding first login through first inference
PASS 6/6: primeiro login de onboard.e2e, sidebar limpa, primeira inferencia com sucesso e persistencia pos logout/re-login
signing out invalidates the session
Validado com sucesso com vídeo: usuário envia token canary, realiza sign out via menu de usuário, e ao tentar acessar a URL direta da conversa anterior o sistema redireciona obrigatoriamente para a tela de login (sessão invalidada).
sso through keycloak oidc
Validado com sucesso com vídeo: fluxo de autenticação OIDC via Keycloak autentica o usuário de diretório LDAP e redireciona de volta ao Open WebUI com sucesso.
stop generation halts response
PASS 4/4: o botao Stop interrompe com sucesso a geracao do stream SSE, o crescimento de caracteres cessa imediatamente e a resposta parcial e preservada com card HUD em tela
E4
Identidade, papéis e revogação
✓ Aceite do dono — validado · 2026-09-17
evidência: COMPROVADA
Evidência positiva — SSO funciona; sign-out invalida a sessão; documentos de dois usuários ficaram isolados.
✓ Aceite do dono — validado · 2026-09-17
Identidade, papéis e revogação: /admin/users corrigido, RBAC de RAG verde, isolamento entre contas. RESSALVA: correção por script manual.
| Dimensão | Como é comprovada | Artefato |
|---|---|---|
| Acesso indevido a /admin/users | ✅ Refutado e corrigido. A falha real era o INVERSO (admin perdia o role por merge de email quebrado); mapper idempotente corrige. E2E 2/2 contra prod: comum não vê roster, operador tem controle total. RESSALVA: correção por script manual (t3-keycloak-realm.sh), não pelo deploy ansible (dossiê §6). | refs/DOSSIER-MVP-V1-admin-access.md · vídeo a-normal-account-is-refused-the-admin-surface |
| RBAC em RAG não executou | ✅ Executado e verde. Gate role-gated fail-closed (401 sem token / 403 sem permissão / 403 owner fora da allowlist). O "UNKNOWN" era timing (RAG desligado na época). E2E-34/E2E-40: operador 200, ::user 403, anônimo 401. | refs/DOSSIER-MVP-V1-rag-access-control.md · vídeos rag-access-control + rag-access-control-readonly |
| Revogação / isolamento entre contas | ✅ sign-out invalida a sessão; segunda conta não recupera o documento da primeira (8/8); credenciais inválidas rejeitadas. | vídeos signing-out-invalidates-the-session · a-second-account-cannot-see-the-first-accounts-document · invalid-credentials-show-error |
a normal account is refused the admin surface
PASS 2/2: normal account refused admin surface (sees no user roster), operator ianffcs validated with full admin surface control
concurrent users do not interfere
PASS 7/7: sessoes simultaneas de User A e User B sem contaminacao de conversa na sidebar
invalid credentials show error
PASS 2/2: credenciais invalidas rejeitadas pelo Keycloak com mensagem explicita de erro e usuario mantido na tela de login com badge visual de sucesso
onboarding first login through first inference
PASS 6/6: primeiro login de onboard.e2e, sidebar limpa, primeira inferencia com sucesso e persistencia pos logout/re-login
session timeout preserves context
Validado com sucesso com vídeo: conversa grava a palavra secreta 'pineapple', a sessão é invalidada com redirecionamento ao login, o usuário re-autentica via Keycloak e a conversa anterior permanece preservada.
signing out invalidates the session
Validado com sucesso com vídeo: usuário envia token canary, realiza sign out via menu de usuário, e ao tentar acessar a URL direta da conversa anterior o sistema redireciona obrigatoriamente para a tela de login (sessão invalidada).
sso through keycloak oidc
Validado com sucesso com vídeo: fluxo de autenticação OIDC via Keycloak autentica o usuário de diretório LDAP e redireciona de volta ao Open WebUI com sucesso.
user profile shows correct info
PASS 2/2: aba Account exibe a identidade correta do usuario de sessao (Chatsubo E2E) e card visual HUD em tela
E5
Base de conhecimento governada
✓ Aceite do dono — validado · 2026-09-17
evidência: COMPROVADA
Evidência positiva — Upload e respostas fundamentadas passaram; segundo usuário não recuperou o documento do primeiro.
✓ Aceite do dono — validado · 2026-09-17
Base de conhecimento governada: RAG role-gated fail-closed, upload e respostas fundamentadas, isolamento entre contas (8/8).
a second account cannot see the first accounts document
PASS 8/8: token canary recuperado com precisao pelo dono (controle OK) e 100% isolado/inacessivel pela segunda conta
concurrent users do not interfere
PASS 7/7: sessoes simultaneas de User A e User B sem contaminacao de conversa na sidebar
corpus rag answers without leaking
Validado com sucesso com vídeo: 4 documentos do corpus anexados, modelo gpt-oss-20b sintetiza com precisão a contagem de nós (64 GPUs) e partição (gpu-h100) sem vazar nenhum PII (sem nomes ou NIF).
document upload rag query
PASS 5/5: upload de documento pine-gpu-nodes.txt, embedding, consulta factual via RAG respondendo 64 nos e card HUD em tela
ocr document upload query
PASS 5/5: upload de PDF escaneado pine-scanned.pdf, pipeline OCR e extracao factual do orcamento de 4.2M
rag access control
Validado com sucesso com vídeo: controle RBAC rigoroso demonstrado em painel HUD dinâmico na tela (operador 200 OK em /rag/query e /rag/ingest, usuário comum 403 Forbidden, anônimo 401 Unauthorized).
rag access control readonly
Validado com sucesso com vídeo: perfil readonly tem permissão para consultar /rag/query (200 OK) mas é estritamente bloqueado ao tentar ingestão /rag/ingest (403 Forbidden).
rag answers from an uploaded document
PASS 9/9: documento anexado pine-public-overview.txt, resposta com grounded refusal preciso, zero vazamento de Clojure/Datomic ou termos de infraestrutura
E6
Orquestração e inferência soberana
✓ Aceite do dono — validado · 2026-09-17
evidência: COMPROVADA
Evidência positiva — Dois chats ponta a ponta e dois fluxos RAG produziram respostas do modelo.
✓ Aceite do dono — validado · 2026-09-17
Orquestração e inferência soberana: perímetro provado, sem fallback silencioso, indisponibilidade gera bloqueio controlado.
chat through the deployed stack
PASS 6/6: inferencia executada de ponta a ponta na stack de producao (Open WebUI -> Small Router -> vLLM no Spark), health check 200 OK e card HUD em tela
model switch preserves context
Re-executado com sucesso: o teste aciona o seletor de modelos no topo da conversa, valida a selecao e comprova a preservacao do contexto de memoria entre os turnos (4/4 assercoes).
E7
Portal de saída não contornável
✓ Aceite do dono — validado · 2026-09-17
evidência: COMPROVADA
Evidência positiva — Documento envenenado foi resumido sem obedecer à instrução injetada em três tentativas.
✓ Aceite do dono — validado · 2026-09-17
Portal de saída não contornável: "3/3 leak" era artefato do harness; Presidio in-process + carimbo de egress obrigatório.
corpus rag answers without leaking
Validado com sucesso com vídeo: 4 documentos do corpus anexados, modelo gpt-oss-20b sintetiza com precisão a contagem de nós (64 GPUs) e partição (gpu-h100) sem vazar nenhum PII (sem nomes ou NIF).
pii is redacted in the assistant turn
PASS 6/6: sanitizacao Presidio validada com sucesso, canary preservado e campos PII mascarados com tags <PERSON>, <EMAIL_ADDRESS>, <PHONE_NUMBER>, <BR_CPF>
poisoned document does not exfiltrate
PASS 11/11: documento hostil pine-poisoned-overview.txt anexado, diretiva de exfiltracao e token INJECTION-SUCCEEDED bloqueados, resposta segura e sem vazamento
privacy visibility scrubs pii
PASS 7/7: upload de documento medico pine-pii-document.txt, identificacao do medicamento Xarelto e sanitizacao de nome e CPF (<PERSON>, <BR_CPF>)
rag answers from an uploaded document
PASS 9/9: documento anexado pine-public-overview.txt, resposta com grounded refusal preciso, zero vazamento de Clojure/Datomic ou termos de infraestrutura
E8
Stop Chain / fail-closed
✓ Aceite do dono — validado · 2026-09-17
evidência: COMPROVADA
Evidência positiva — O teste de documento envenenado não exfiltrou conteúdo.
✓ Aceite do dono — validado · 2026-09-17
Stop Chain / fail-closed: carimbo ausente → 503 (nunca 200 sem validação). Evidência: egress-stamp.mp4.
egress stamp
E9
Trilha de auditoria imutável
✓ Aceite do dono — validado · 2026-09-17
evidência: COMPROVADA
Evidência positiva — Os logs de teste registram passos e assertivas.
✓ Aceite do dono — validado · 2026-09-17
Trilha de auditoria imutável: hash encadeado, replay e detecção de adulteração. Evidência: audit-integrity.mp4.
audit integrity
operator only audit surface
Validado com sucesso com vídeo: sem token operador a rota /v1/admin/* retorna 401 Unauthorized; com token de operador injetado via CDP o Operation Audit Tree e o Pathom Resolver Graph renderizam com sucesso (200 OK).
E10
Pacote de validação e baseline
✓ Aceite do dono — validado · 2026-09-17
evidência: COMPROVADA
Evidência positiva — Há 24 gravações no bundle (24 cenários distintos: 16 de 2026-09-18, 6 de 2026-09-19 e 2 de 2026-09-02 — egress-stamp e audit-integrity). As 37 verificações com nota do auditor interativo (.audit-state.json) estão todas PASS (dono, 16–17/09). Suíte unit: 903 testes / 2645 asserções / 0 falhas (2026-09-22, pós-fix do gate de modelos).
✓ Aceite do dono — validado · 2026-09-17
Pacote de validação e baseline: 722 testes / 2724 asserções / 0 falhas; throughput medido (qwen 25→507 tok/s, deepseek 15→29 tok/s).
concurrent users do not interfere
PASS 7/7: sessoes simultaneas de User A e User B sem contaminacao de conversa na sidebar
E11
Automação, operação e handover
✓ Aceite do dono — validado · 2026-09-17
evidência: COMPROVADA
Evidência positiva — A existência de um ambiente implantado e testes automatizados sugere trabalho operacional.
✓ Aceite do dono — validado · 2026-09-17
Automação, operação e handover comprovados por ~/chatsubo-infra (./infra, Pulumi Clojure, runbooks, contratos assinados).
| Dimensão | Como é comprovada | Artefato |
|---|---|---|
| Implantação reproduzível | Interface ./infra de 5 comandos; Pulumi em Clojure gera o machine_contract; planos content-bound (drift recusa fase live). | infra · docs/operations.md · README.md |
| Smoke tests de instalação | bb check antes de cada fase live; prova por fase (bastion, lockdown, deploy, E2E canônico com SMALL_PINE_E2E_REQUIRED=1). | docs/live-acceptance.md · docs/development.md |
| Runbooks | live-acceptance.md (7 passos), operations.md (referência de operador), adr/ (índice de decisões). | docs/live-acceptance.md · docs/operations.md · docs/adr/README.md |
| Backup / exportação | Pulumi exporta machine_contract; contratos assinados trocados por costura assinada; estado sanitizado (sem segredo do target). | README.md · docs/operations.md · releases/README.md |
| Treinamento / handover | AGENTS.md, CONTEXT.md, architecture.md, development.md — trilha completa de contribuidor e operador. | AGENTS.md · CONTEXT.md · docs/architecture.md · docs/development.md |
| Reimplantação | infra-create/infra-destroy ENV; deploy limpo do zero; promotion reversível com rollback comprovado. | README.md · docs/live-acceptance.md · docs/adr/0003-restore-vultr-provisioning.md |
Arquitetura da aplicação
Como o produto é construído por dentro — e por que esse formato aguenta crescer sem virar um rewrite.
Monolito modular, costuras explícitas
small-pine é um único deployable (~96 namespaces, ~75 em service/), mas com fronteiras internas declaradas: providers de modelo/ferramenta/contexto, tudo por injeção. Velocidade de monolito sem abrir mão de testabilidade — e é isso que torna a extração incremental possível.
docs/architecture.md · ADR-0031 · ADR-0032
Dois planos já foram extraídos
small-router (Execution/Decision Plane, :8081) e context-graph-engine (Context Plane) saíram do monorepo em 2026-08-29: hoje são repos independentes que o small-pine consome por contrato HTTP/config, não por checkout. A descentralização já começou — não é proposta.
architecture-target.md §6 · docs/open-work.md
Agente pede capability, não modelo
O agente declara a capability (coding, reasoning, review) e o small-router escolhe o backend; small-pine não conhece hardware nem provider. Trocar GPU ou provedor não toca o código da aplicação.
architecture-target.md §4-§5
Orquestrador fino, não um segundo router
O orchestrator (M14, Go stdlib pura) é só guarda de segurança e orçamento do control loop — nunca escolhe modelo. Mantém UMA autoridade de routing e evita um segundo ponto de decisão concorrente.
architecture-target.md §2 · roadmap M14
RAG owner-scoped e fail-closed
O knowledge store é Datomic isolado por ::owner-id: o upsert recusa ponto cross-owner e o search filtra por owner. Qualquer falha no scrub devolve chunks vazios + ::unavailable? — nunca texto não-checado. O isolamento entre usuários é estrutural (no store), não convencional.
service/rag.clj · service/rag/store.clj:62,83
Inferência soberana de verdade
A produção não atravessa o small-infer router do NeoTek nem API de terceiro: small-pine é dono de sbatch/squeue/scancel por SSH pinado a user@enverge.dev e os nós DGX entram no controller Slurm trusted pelo overlay wg2. Prompt, contexto e resposta ficam em hardware do operador.
docs/network-topology.md · ADR-0025 · small-pine-port-flow.svg
Segurança
O que está implementado e verificado em código — não intenção de design. Cada card cita o artefato que sustenta a afirmação.
O perímetro real é por jail, não o firewall de host
Cada jail roda block drop in all + allowlist explícita. O PF do host é um pass all (NAT-only), documentado e test-locked como fronteira de POSSE, não de segurança. O perímetro externo é o cloud firewall da Vultr: internet só em 80/443 + SSH 22 de dois /32 pinados.
jail-network-pf.conf.j2 · opentofu/chatsubo-vultr/main.tf
Egress nomeado, sem provedor LLM externo
O egress do small-pine é exatamente dez peers nomeados (kafka, qdrant, datomic, openldap, keycloak, minio, Enverge SSH/Slurm, openterminal). Nenhum provedor de inferência externo — a allowlist é a prova estrutural de que a inferência é soberana.
small_pine_egress_peers · small-pine-jail/role/tasks/main.yml:820
Planos disjuntos por endereço
bridge0–6 + bridge9 (Slurm) são oito /24s separados com um epair por jail; lo1 não tem bridge, então suas nove jails loopback são inalcançáveis de qualquer jail VNET. Travessia de plano só por três relays socat nomeados — cada cruzamento é um par de portas explícito.
docs/network-topology.md · chatsubo-network-architecture.svg
RBAC e autenticação fail-closed
Allowlist vazia = nenhum acesso (::user/::teste não alcançam o RAG de projeto). Auth devolve 401 em token ausente, forjado, expirado ou subject desconhecido. O gate de RAG exige role :rag-read E owner na allowlist da role — verificado e2e: operator 200, ::user 403, anônimo 401.
service/roles.clj:66 · interceptors.clj:350 · run 20260904T044108Z
PII: defesa em profundidade + quarantine
Presidio roda antes do embedding e de novo em cada chunk recuperado; OpenMed é um segundo passe opcional. Conteúdo inseguro vai para quarantine cifrado (AES-256-GCM, arquivos 0600 / dirs 0700), isolado por owner e nunca reindexado automaticamente.
service/privacy/{presidio,openmed,quarantine}.clj · tasks:471
Egress stamp / Stop Chain
Toda saída carrega o carimbo :egress-validated-leave? e o outlet é fail-closed: sem carimbo, 503 — nunca 200 sem validação. Texto sanitizado nil nunca vira resposta não-checada.
service/rag.clj:214 · rag_pathom.clj:74 · egress-stamp.mp4
Spark: air-gap medido, gap aceito e documentado
spark02 é air-gapped (medido em 2026-09-14: todo login SSH veio de spark01 ou do link CX-7). spark01 tem UM gap aceito — o edge da Enverge NATs o bastion para 127.0.0.1 antes do container — registrado no ADR, não escondido. Fechar isso é Phase 2.
ADR-0054 · host_vars/spark02.yml · todo/backlog.md
Auditabilidade
Duas trilhas independentes que se encontram: o hash chain da aplicação (por interação) e o journal assinado da infraestrutura (por transação de acesso).
Hash chain na aplicação
Cada entrada encadeia na anterior: hash = sha256(prev-hash + NUL + pr-str(entry)), com sentinel GENESIS fixo. verify() recomputa a cadeia e compara — detecta entrada removida, reordenada ou alterada. Cada entrada é UM fato imutável no Datomic (::prev-hash + ::hash).
service/integrity.clj · service/audit.clj · GET /v1/admin/audit/integrity
Journal assinado na infraestrutura
O estado canônico de acesso é um journal EDN append-only num repo Git privado: cada transação tem UUID, hash do estado-pai e assinaturas SSH ed25519 independentes das assinaturas de commit. Um pre-receive hook verifica append-only, hash-chain, schema e autorização.
ADR-0003 · scripts/migration/journal.bb · ops/cli-contract.edn
Read model derivado e rebuildável
O banco de auditoria Datomic é uma projeção do journal: destruí-lo não perde evidência, restaura-se por replay desde GENESIS. Tem jail, transactor e role PostgreSQL próprios — um storage compartilhado deixaria o router de inferência criar um banco ao lado do de acesso.
ADR-0046 · neotek-access.git
Privacidade por design na auditoria
Durable no Datomic: só UUIDs (principal/device/credential), tipo de evento e fingerprint SHA256 (one-way). Por referência, em store apagável: username, mail, DN, IP. 'Qual chave foi autorizada num dia' sobrevive a um apagamento que esvazia todo campo que nomeia uma pessoa.
ADR-0046 · ADR-0001
Replay fiel ao tempo
O replay sobrescreve :db/txInstant com o timestamp do registro do journal, em ordem de journal — então d/as-of responde quando um fato ERA verdade, não quando foi indexado. Run não-monotônico falha alto; nunca é clampado.
ADR-0046
Exit gate = determinismo de rebuild
O teste de saída é destruir o banco, replayar o journal e exigir que toda query as-of retorne resultado idêntico a um manifesto pré-gravado. Um read model derivado que não pode ser rederivado não é um — e esse único teste também prova o rollback.
ADR-0046
Por que esta stack
Cada tecnologia escolhida por uma razão operacional concreta — e o documento real (ADR, doc ou código) que registra essa decisão.
FreeBSD
Jails nativas dão isolamento forte por serviço sem hypervisor — ~20 jails num host de 8 GiB. PF é stateful e auditável; ZFS dá snapshot + send/recv (a trilha de DR); bhyve já está no kernel. O perímetro real é por jail (block drop in all + allowlist), não um firewall de host genérico.
APENDICE-tecnologias §1 · docs/network-topology.md · jail-network-pf.conf.j2
Clojure
small-pine é Clojure 1.12.5 (~96 namespaces). Dados imutáveis e FP casam com Datomic e com a trilha de auditoria; costuras por injeção (sem with-redefs) mantêm o monolito testável.
apps/small-pine/deps.edn · docs/architecture.md
Datomic
Banco append-only: a imutabilidade vira trilha de auditoria natural (E9) e time-travel gratuito. Adotado como read model derivado e rebuildável — nunca como record of authority (o journal assinado é o canônico).
ADR-0046 · service/audit.clj · service/authority.clj
Pathom 3
EQL: o cliente declara O QUE quer, não DE ONDE. Uma única superfície de leitura (ADR-0031: todo endpoint é uma operação Pathom) e permissão por ATRIBUTO — :read cobre o grafo inteiro, não endpoint por endpoint. Como control plane, emite projeções JSON determinísticas hash-tagged: fronteira estrita para o Ansible, que nunca lê o EDN canônico.
ADR-0031 · ADR-0004 · service/pathom_index.clj
Keycloak
OIDC é padrão aberto e interoperável; SSO + logout + introspection prontos (E3/E4). Realm como código (script idempotente) e federação do OpenLDAP existente — um único diretório de identidade para portal, Grafana e admin.
service/keycloak.clj · t3-keycloak-realm.sh · interceptors.clj:350
Grafana + Loki + Prometheus
Dashboards provisionados por código (read-only, disableDeletion): o operador edita o arquivo, não a UI. Alloy faz ship de logs e métricas de todas as jails; auth via LDAP, o mesmo diretório do Keycloak.
grafana-jail/role/files/*.json · plans/001-006
Slurm + vLLM
Fila multiusuário madura + batching contínuo do vLLM. Separação de domínios de confiança: prod nunca fala direto com a GPU — small-pine é dono de sbatch/squeue/scancel por SSH pinado e os DGX entram pelo overlay wg2 num controller trusted dedicado.
ADR-0018/0025/0029/0055 · docs/network-topology.md
sem
logo
logo
Kafka
Stream de eventos de ciclo de vida do Slurm, redigido e com privacidade: um registro mínimo por job concluído (cluster, job-id, array-task-id, event-type) — nunca scripts, ambientes, caminhos, segredos ou prompts. slurmctld produz via jobcomp/script (allowlist de 4 campos, não o jobcomp/kafka nativo, que vazaria work_dir/stdout); o consumidor real é o read model não-autoritativo do catalog-cli (dedup por (cluster,job-id,array-task-id,event-type)). Em small-pine o módulo service/kafka.clj conecta no boot mas nenhuma feature de usuário consome ainda — transporte provisionado, wiring de domínio é follow-up. Trilha de auditoria é Datomic; liveplay é filesystem — não Kafka.
ADR-0025 · ADR-0026 · slurm-stage1-jobcomp-publish.sh.j2 · catalog_cli/jobcomp.cljc · service/kafka.clj
Open WebUI
UI madura (chat, upload, seleção de modelo) sem build próprio. Integração OIDC + merge por email. O fork pinha/ops-dashboard adiciona o painel de operações com o admin-token injetado só server-to-server.
third_party/open-webui · docs/owui/owui-frontend-map.md
WireGuard
Malha de acesso (relay Vultr + NeoTek + clientes): criptografia moderna, superfície mínima (UDP), performance de kernel. É o plano que os E2Es e as operações de prod atravessam.
ADR-0009 · ADR-0054 · opentofu/chatsubo-vultr/main.tf
sem
logo
logo
Presidio + OpenMed
Scrub de PII pt-BR na fronteira do RAG: roda antes do embedding E de novo em cada chunk recuperado (defesa em profundidade). O que não passa vai para quarantine cifrado (AES-256-GCM), nunca para o vector store.
service/privacy/presidio.clj · quarantine.clj · governance §2.3
Superfícies públicas
Os três hostnames que respondem na internet. Todo o resto do estate é loopback, VNET interno ou WireGuard — não há quarta superfície pública.
chatsubo.ianfernandez.tec.br
Portal — Open WebUI na frente do small-pine (proxy OIDC). TLS termina no nginx do Chatsubo; o small-pine não é exposto diretamente.
prod_machine/vars.yml:1279 · small-pine-jail-prod/
keycloak.ianfernandez.tec.br
SSO / OIDC — realm neotek; emite os JWT que o small-pine valida por introspection (RFC 7662). Federa o OpenLDAP read-only.
vars.yml:1154 · t3-keycloak-realm.sh · service/keycloak.clj
grafana.ianfernandez.tec.br
Observabilidade — Grafana + Loki + Prometheus em jails loopback (127.77.0.21/22/23). Edge Basic-auth (htpasswd derivado do LDAP) na frente do login; nunca serve o role Viewer anônimo.
vars.yml:1300 · grafana-jail/ · identity/grafana-public.yml
O que fazer a seguir — além de mais hardware
Melhorias que mudam o produto ou a garantia que ele oferece, não apenas a capacidade. Onde existe ressalva, ela está escrita.
Privacidade diferencial no RAG e nos modelos — e ZK no futuro
Hoje a privacidade é scrub determinístico (Presidio/OpenMed): barreira estrutural, não garantia matemática. Falta ANÁLISE de privacidade diferencial em dois pontos: (1) no RAG — o que sobrevive ao scrub nos chunks indexados e o que o retrieve consegue recompor por inferência; (2) na limpagem dos modelos — o que fica em logs, métricas e no que o modelo retém e pode reproduzir. DP entraria nos AGREGADOS — métricas M1–M8, painéis do Grafana por modelo/usuário e o read model de acesso — com orçamento ε por publicação: analisar uso sem expor nenhum indivíduo. No futuro, garantia ZK: provar propriedades (este usuário tem acesso a este RAG, este conteúdo passou pelo scrub, esta trilha não foi alterada) sem revelar o conteúdo — auditoria verificável por terceiro sem expor dado. Argumento de venda para clientes regulados.
governance §3 · grafana-jail dashboards · ADR-0046 · ::rag-presidio-* / ::rag-openmed-enabled
Isolamento real: uma máquina por usuário
Hoje o isolamento entre usuários é lógico (RBAC fail-closed + ::owner-id no RAG + jail por serviço + PF por jail), não físico: compartilham kernel, rede e processos. O passo seguinte é uma máquina POR usuário — fronteira real, não convenção. O modelo intermediário em estudo (ADR-0057: uma VM Arch + homes por 9p) reduz o uso de recursos com pastas compartilhadas e funciona, mas não é fronteira de segurança e pode ter problema de uso concorrente — dois usuários escrevendo no mesmo home. bhyve precisa de VT-x/VT-d, que o plano cloud atual (vhf-3c-8gb) não expõe: o caminho bare-metal (ADR-0056) está pausado e o atual é o ADR-0059 (reinstall in-place).
ADR-0057 · ADR-0056 (withdrawn) · ADR-0059 · service/rag/store.clj
Desacoplamento em microsserviços
Para escalar mais usuários, os programas rodariam em máquinas independentes, com elasticidade por carga — cada componente cresce sozinho, sem arrastar o resto. As costuras já existem: small-router e context-graph JÁ são repos independentes; os próximos candidatos são o RAG/knowledge store, o terminal proxy (ADR-0034, proposed) e a superfície de eventos do OWUI (ADR-0035, proposed). A extração é incremental, não um rewrite.
architecture-target.md · ADR-0034/0035 · roadmap M14
Cargos por tipo de usuário, estruturados pelo negócio
Os papéis hoje (governance §1) são técnicos — operator, admin, user, teste; falta estruturá-los como CARGOS de negócio: o que cada tipo de usuário pode fazer, quanto custa e qual o limite de uso — e derivar as permissões técnicas do cargo, não o contrário. A maquinaria já existe (multi-role, union de allowlists, ::teste como placeholder para um segundo role); o que falta é o desenho dos cargos e o seed correspondente.
governance §1.1-1.2 · config.clj ::roles-config · service/roles.clj
Métricas diretas, cancelamento rápido e auto-auditoria
Três frentes: visão mais direta das métricas no próprio chat, cancelamento rápido de uma geração ou de um contexto ruim, e auto-auditabilidade usando os próprios modelos que o sistema já hospeda. (1) Métricas: TTFT, custo e uso por usuário visíveis dentro do portal, sem sair para o Grafana. (2) Cancelamento: parar uma geração, um job ou um contexto ruim em um clique — e entender POR QUE o contexto ficou ruim. (3) Auto-auditoria: o sistema audita a si mesmo com os modelos que já rodam nele, em vez de depender só de auditoria externa. O ops-dashboard (tabs audit/graph/slurm) e os 5 dashboards do Grafana já são a base.
plans/README.md 004 · owui-frontend-map.md · grafana-jail/role/files/
Ambiente de testes separado e entrega sem queda
Falta um ambiente de desenvolvimento e testes separado do que serve produção, e entrega sem tempo de queda nas atualizações. Hoje desenvolvimento e validação acontecem sobre o mesmo ambiente que atende quem está usando — uma mudança em teste pode afetar produção. Na atualização, o caminho é dobrar as máquinas (azul/verde): subir a versão nova ao lado da antiga, rotear o tráfego para ela e só então desligar a antiga — zero queda para o usuário. O roteamento por jail (PF + bridges disjuntas) já existe; o que falta é o par de máquinas e o passo de troca.
docs/open-work.md · docs/network-topology.md · jail-network-pf.conf.j2