BUILD LOG

Uma estrada ainda em construção

De v0.1 a v0.5.22 — 156 dias, 116 versões. Isto não é uma lista de recursos; são os erros que cometemos, as regras que conquistamos e as lacunas que ainda não preenchemos.

156 dias: desde o primeiro lançamento
116: versões
9: snapshots de arquitetura
20+: verificações de arquitetura

Snapshot de dados 2026-11-01 · números coletados do repositório do Liri por sync-facts e health:arch

Ir para a linha do tempo

Origem

Em 25 de maio de 2026, o Liri lançou a v0.1: 100 commits e um assistente de IA de terminal que realmente rodava.

O problema era concreto — deixar o modelo morar no terminal, ler arquivos, executar comandos e editar código, em vez de conversar em uma caixa de texto na web. Modelos locais primeiro, porque arquivos pessoais não deveriam sair da máquina; segurança integrada, porque o assistente recebe um computador de verdade, não apenas uma API.

Nos três meses seguintes, os recursos foram adicionados camada por camada: ferramentas, 27 canais de mensagens, um cliente desktop, voz, uma base de conhecimento. Em agosto, o repositório já tinha mais de 4.000 arquivos.

Foi também quando o problema foi nomeado em voz alta. A revisão de código de 18 de junho de 2026 encontrou o LocalHTTPService com 7.200 linhas e o ChatManager com 3.263, com 150 arquivos de teste para 3.742 arquivos de código-fonte. Dois meses depois veio a primeira pontuação de saúde da arquitetura: 10/40, nota D, com 105 arquivos acima do limite, nenhum deles registrado.

A lição: se um projeto pode ser entregue a outra pessoa depende não de quantos recursos ele tem, mas das regras que ele desenvolve depois de bater em uma parede.

Cinco pontos de virada

Ordenados por causa, não por calendário — alguns períodos se sobrepõem.

2026-05-25 → 2026-08

Primeiro os recursos, depois os limites

Situação: A v0.1 tinha 100 commits; entregar valia mais que estruturar.
Decisão: Preencher os recursos primeiro: ferramentas, canais, desktop, voz, conhecimento — um de cada vez.
Custo: A primeira auditoria foi feia: LocalHTTPService com 7.200 linhas, ChatManager com 3.263, proporção de testes para código-fonte em torno de 4% e a primeira pontuação de saúde de 10/40 (D), com 105 arquivos acima do limite e nenhum registrado.
Resultado: Mais de 4.000 arquivos, 69 ferramentas, 27 canais, 429 componentes de desktop.

Evidência CHANGELOG v0.1 Revisão de código, 18 de junho de 2026

↳ Como entrar — Vai adicionar um recurso? Comece um módulo em app/src, não dentro do núcleo.

2026-08-09 → 2026-09-30

Aprender a nos medir

Situação: Todo mundo sentia o problema; ninguém conseguia dizer o tamanho dele.
Decisão: Transformar a qualidade da arquitetura em uma pontuação repetível com um registro, exigindo que todo arquivo acima do limite fosse registrado — abandonando a suposição de que a limpeza sobrevive só à disciplina.
Custo: Registrar não é dividir: o ChatManager cresceu de 3.263 para 7.036 linhas (desde então foi dividido até 2,570). A própria pontuação continuou mudando, então ela é um check-up, não um KPI.
Resultado: Nove snapshots; arquivos acima do limite não registrados caíram de 105 para 0 (depois voltaram a 2); a lista virou um registro rastreável.

Evidência architecture-health-history.json architecture-health.ts

↳ Como entrar — Assuma um arquivo acima do limite para dividir (veja Formas de ajudar abaixo).

2026-10-08 → 10-09

Uma exclusão errada comprou um processo de exclusão

Situação: O código havia acumulado uma camada de “superfícies mortas” aparentemente não usadas. A limpeza da v0.4.69 tratou o subsistema de sandbox e isolamento como código morto: 170 arquivos alterados, +9.340 / −10.174 linhas.
Decisão: No dia seguinte, a v0.4.71 desfez tudo — 24 arquivos restaurados (IsolationManager, EnhancedSandboxManager, PTYSandbox, SSHSandbox, docker/** e outros, além de 5 suítes de teste) e 21 arquivos vivos revertidos para acompanhar.
Custo: Excluir agora leva mais tempo: primeiro você escreve a evidência. Ainda é mais barato que um rollback.
Resultado: A v0.4.72 transformou a exclusão em processo, code-deletion.md (CD01–CD07): reunir evidências, desacoplar pontos de entrada e só então excluir. “Ninguém parece usar” deixou de ser motivo.

Evidência CHANGELOG v0.4.69 / v0.4.71 / v0.4.72

↳ Como entrar — Revise um “candidato a código morto” segundo o CD01–CD07.

2026-10-10 → 10-22

Transformar regras em portões

Situação: As regras viviam em documentos e dependiam de disciplina; documentos e código começaram a divergir.
Decisão: Cada regra virou bloqueio de CI em vez de recomendação: cinco portões mais doc-gate e um job obrigatório sandbox-negative; 413 chaves de baseline de hardcoding; um vocabulário de estados com 34 valores e 1.795 pares de baseline; portões de superfície de inicialização, de módulo crítico e de superfície do núcleo.
Custo: Alguns segundos por commit, e as baselines precisam ser regeneradas a cada mudança de vocabulário — o ponto é que as definições não podem mais divergir em silêncio.
Resultado: Violações de lint:arch em 0; os testes cresceram de 3.029 para 7.488.

Evidência Lista de portões do AGENTS.md Workflow de CI

↳ Como entrar — Rode os portões locais (bun run ci) antes de enviar — corrija o que ficar vermelho.

2026-10-05 → 10-28

Encolher o núcleo: de 5.336 linhas a um pacote próprio

Situação: O core era ao mesmo tempo a implementação de entrada e o quintal compartilhado de todo mundo — qualquer pessoa podia adicionar coisas nele.
Decisão: Três passos: encolher (CoreAPIImpl 5.336 → 2.521 linhas), extrair (@openliri/kernel como pacote próprio; core de 146 para 113 arquivos, com os portões de núcleo K01–K08) e então evacuar (37 módulos que falhavam na regra “zero I/O / zero dependência para cima” foram movidos para app/src, mais de 470 imports atualizados e cinco famílias de baseline regeneradas).
Custo: Uma grande migração e regeneração total das baselines; desde 18 de outubro o trabalho entra em lotes e a densidade de commits é deliberadamente menor.
Resultado: O núcleo agora expõe uma interface fina; contribuições externas finalmente têm um limite.

Evidência CHANGELOG v0.5.22

↳ Como entrar — Novos recursos vivem fora do limite do núcleo e começam em app/src.

Arquitetura: em camadas, como um sistema operacional

A arquitetura não foi inventada do zero. Núcleo fino, limites de subsistema, direção única de dependência, portões e observabilidade vêm de décadas de prática em sistemas operacionais; os guias de padrões de projeto e de engenharia publicados para agentes nos últimos dois anos convergem para as mesmas perguntas — camadas, limites, estado, governança e avaliação. Nós nos restringimos pelo primeiro caminho e nos auditamos pelo segundo.

Conceito de SO → onde o Liri está

Conceito	No Liri	Status
Núcleo	@openliri/kernel como pacote próprio com uma interface pública fina, protegido por K01–K08	Entregue
Subsistemas	Ferramentas / canais / memória / roteamento / sandbox / tarefas / voz / desktop — cada um com seus pontos de entrada e limites	Convergindo
Drivers	Adaptadores de provedor, adaptadores de canal e 6 backends de sandbox (Landlock / Docker / SSH / PTY / macOS / Windows)	Entregue
Processos e agendamento	Execução de sessão, PDCA, Swarm, Cron	Entregue
Modelo de permissões	Cinco camadas de defesa mais quatro estágios de aprovação (requested → presented → decided → recorded)	Aguardando auditoria
Observabilidade e auditoria	Log de eventos, livro de custos, livro de evidências	Entregue
Mantenedores	Ainda não estabelecido: sem donos de subsistema e sem caminho de passagem de bastão	Ausente

Com o que nos comparamos

Nos comparamos item a item com padrões de projeto de agentes e guias de engenharia publicamente disponíveis: todos os 21 padrões têm implementações reais, mas 3 dos interruptores principais vêm desligados por padrão — por isso só afirmamos “implementado”, nunca “ativo por padrão”. O ciclo de engenharia é auditado do mesmo jeito: arquitetura, build, execução, governança e otimização.

Três lacunas

Mantenedores de subsistema

Sem donos não há caminho de passagem de bastão. Esta é a peça mais parecida com um SO e a que nos falta.

Contratos de subsistema

O desenho do contrato existe, mas não está verificado se o livro / LoopProfile foi implementado — a promessa de estabilidade de interface ainda não está fixada.

Portão de cobertura

Cerca de 4% no momento da revisão; a CI roda mais de 20 verificações de arquitetura, mas ainda não há limite de cobertura.

Para ser honesto: a pontuação de saúde da arquitetura ainda é D (10/40); dos 142 arquivos acima do limite, 141 ainda não estão registrados; o maior continua no chat (o ChatManager foi dividido de 7.036 para 2,570 linhas). O núcleo existe, os limites estão convergindo, os mantenedores ainda não existem — é isso que significa “ainda não terminado”.

Expandir as 8 camadas funcionais atuais

Visão geral da arquitetura

8 camadas funcionais, do ponto de entrada ao feedback; no código, impostas por 6 portões de dependência (entry > ui > app > service > infra > core)

Camada de entrada multimodal

Entre no Liri por qualquer superfície

Terminal REPL

Interface de terminal feita com React + Ink, com o sistema de companheiro Buddy integrado

Cliente desktop Tauri

429 componentes TSX em 32 páginas de recursos (Tauri 2.11 + React 19)

Gateway MCP / canais

MCP Server + 27 canais de mensagens (WeChat, DingTalk, Feishu, Telegram e outros)

CLI / API HTTP

Três executáveis — Liri / liri-memory / liri-ink — e uma API HTTP

Primeira camada de segurança

Toda entrada passa por um filtro de segurança

Análise AST em Rust no tempo de compilação

A camada FFI analisa a AST do Bash com base em 37 regras de comandos perigosos

Análise semântica em TypeScript

Comandos somente leitura compostos são avaliados trecho a trecho, com motivo da recusa atribuível

Motor de regras Guardrail

14 padrões de injeção + 10 regras específicas de shell

Classificador AutoMode

Avalia o risco da tarefa automaticamente e decide entre permitir, perguntar e negar

Camada de roteamento inteligente

Escolha do modelo pelo tipo e pela dificuldade da tarefa

19 tipos de tarefa detectados

codificação, escrita, análise, ferramentas, tradução, busca, ideação, conversa e outros

4 níveis

simple / medium / complex / reasoning

Pipeline de decisão em 5 etapas

interruptor → caminho rápido → aderência da sessão → julgamento do LLM → resolução de nível

FallbackChain

Failover ordenado quando o provedor principal está indisponível, junto com RetryPolicy

Camada de injeção do segundo cérebro

Base de conhecimento + memória + eventos de sessão: três fontes de contexto recuperáveis

Base de conhecimento

Markdown em disco e indexação semântica, com recuperação híbrida por palavra-chave / vetor / RRF

Sistema de memória

Memória em camadas com tabela vetorial SQLite e recuperação ponderada por relevância

Eventos de sessão

events.jsonl somente em acréscimo — reproduzível e auditável

DreamEngine

Consolida conhecimento quando ocioso: coletar → analisar → gerar → gravar → indexar

Loop de decisão TAOR

Think → Act → Observe → Reason

Think

4 estratégias de agente: geral / codificação / exploração / planejamento

Act

69 ferramentas integradas, registradas dinamicamente conforme a variante de build

Observe

Avaliação de resultados, janelas de contexto em camadas e compactação automática

Reason

Gestão de orçamento de tokens + retomada por checkpoint + disjuntor por rodada

Camada de sandbox de execução

Os comandos rodam isolados e degradam com honestidade quando não há isolamento disponível

Linux Landlock

Restrições de acesso ao sistema de arquivos em nível de núcleo

macOS / Windows

Sandbox do sistema com Low IL / objeto Job como fallback

Contêiner Docker

Isolamento completo em contêiner com limites de recursos e políticas de rede

SSH / PTY

Ambientes remotos limpos de execução e caminhos de pseudo-terminal controlados

Camada de tarefas de longa duração

De uma única conversa a trabalhos de vários dias

Pipeline PDCA

Ciclo Plan-Do-Check-Act que avança o progresso conforme artefatos reais existem

Swarm multiagente

AgentSwarm com orquestração em conselho e descoberta dinâmica via registro

Agendamento Cron

expressões once / interval / cron, com fusos horários

Persistência de tarefas

Snapshots de sessão, retomada por ponto de parada e contagens regressivas visíveis durante a espera

Camada de feedback e evolução

Cada interação deixa evidência verificável

Indução de padrões de falha

Os padrões de falha são generalizados de volta em prompts e habilidades, fechando o ciclo de melhoria

Livro de custos

Cobrado pela tabela de preços do banco, registrando o nome real do modelo devolvido pelo provedor

Portões de avaliação

Conjuntos de referência integrados, pontuação de confiabilidade pass^k e medição de segurança em pares

Reprodução de eventos

O contexto de cada chamada ao modelo pode ser reconstruído depois

Filosofia de arquitetura

🛡️

Segurança integrada

Segurança não é plugin — é o DNA de cada camada

🏠

Local-first

Dados locais, funciona offline, privacidade protegida por padrão

🧠

Roteamento inteligente

19 classes de tarefa mapeadas para o nível de modelo certo

🧬

Segundo cérebro

Base de conhecimento, memória e logs de eventos: três camadas de contexto recuperáveis

🔄

Ciclo verificável

Lições de falhas voltam ao sistema e portões bloqueiam regressões

🔌

Multimodal unificado

Terminal, desktop, IM e API compartilham um único motor

Ver status completo

Linha do tempo

Uma entrada por mês — apenas arquitetura e governança, sem commits rotineiros.

2026-05-25 v0.1: 100 commits, o assistente de terminal roda
2026-06-18 Primeira revisão de código: um monólito de 7.200 linhas, proporção de testes para código-fonte ~4%
2026-08-09 Primeira pontuação de saúde: 10/40 (D), 105 arquivos acima do limite não registrados
2026-10-09 Sandbox apagado por uma limpeza → rollback total; processo de exclusão CD01–CD07 no dia seguinte
2026-10-20 Portão de vocabulário de estados entra no ar: 34 valores, 1.795 pares de baseline
2026-10-28 Evacuação do núcleo concluída; ferramentas visíveis ao modelo limitadas a 12 / 1.397 tokens
2026-10-28 Site de documentação bilíngue e esta página entram no ar

Novas entradas mensais serão adicionadas aqui.

Formas de ajudar

Esta página não é um relatório de encerramento, é um convite. Três lacunas, todas precisando de mãos.

Lista de auditoria de segurança

Regras de comandos perigosos: 37 regras — onde ficam, como disparam; monte um caso e confira se acerta a regra esperada
Regras de injeção de prompt: 14 regras — alimente um documento malicioso e veja se ele é barrado
Regras de shell: 10 entradas de permissão / bloqueio — tente caminhos de contorno (pipes, subshells, codificação)
Degradação do sandbox: quando cada um dos 6 backends degrada e se ele falha fechado
Estágios de aprovação: requested → presented → decided → recorded — procure estágios ausentes ou fora de ordem
Superfície de privilégio: uma chamada de ferramenta consegue contornar o classificador de permissões e gravar ou executar diretamente?

Pontos de entrada: app/src/security, app/src/sandbox, app/src/permission.

Relate detalhes de vulnerabilidade em particular via SECURITY.md — não abra uma issue pública. Issues públicas servem apenas para o processo e a cobertura da auditoria.

Assumir ou perguntar nas Issues Abrir o caminho de segurança

Prefere financiar? Veja a página de patrocínio