Veja como o seu sistema funciona. E como ele vem mudando.

O diagrama de ontem já não é o sistema de hoje.

Times herdam sistemas que ninguém consegue explicar inteiro. A documentação é escrita uma vez e envelhece no merge seguinte; pedir a um modelo para “documentar tudo” consome muitas chamadas e não garante que o texto bate com o código.

1. 01

   Diagramas que mentem

   Desenhados à mão uma vez, nunca mais conferidos contra o código.

2. 02

   Ninguém vê o que mudou

   A estrutura se move a cada versão, mas o que entrou, saiu ou foi alterado só aparece lendo o diff inteiro.

3. 03

   Onboarding lento

   Quem chega precisa descobrir sozinho por onde o pedido passa.

4. 04

   Status sem evidência

   “Pronto” e “em andamento” sem arquivo nem commit que sustentem; números citados sem origem.

Seis entregas, todas geradas do mesmo modelo.

O modelo de arquitetura mora no seu repositório, em Structurizr DSL. As páginas são geradas a partir desse modelo.

3.1

Fluxos e componentes

Navegue por visões, percorra fluxos e inspecione as relações e os caminhos de código de cada componente.

explorador/index.html

3.2

Saúde com evidências

Referências estáticas de testes, cobertura, histórico git e relatórios JUnit quando disponíveis. Ausência de dados é mostrada como desconhecida; referência a teste não comprova execução.

explorador · saúde

3.3

Leitor e decisões

Documentação com busca, diagramas e decisões registradas. O relatório de evolução apresenta as alterações por versão.

leitor/index.html

3.4

Métricas com origem

Cada número ligado a um componente aponta o arquivo e o commit de onde saiu. Um teste confere se a fonte ainda existe.

metricas/metricas.json

3.5

Teste de cobertura

Um pytest que falha quando algum módulo do código fica fora do modelo. O mapa não envelhece em silêncio: o CI avisa.

tests/test_arquitetura_cobertura.py

3.6 · base técnica

Modelo C4 em Structurizr DSL

Sistema, containers, componentes por área, relações nomeadas, visões e fluxos dinâmicos. Cada componente tem status: pronto, em andamento, aguardando, planejado ou fora do foco.

workspace.dsl · model/ · views/

# model/componentes-api.dsl (exemplo)
group "Roteamento" {
  roteador = component "Roteador" "Escolhe o agente" {
    properties {
      "status" "Em andamento"
      "codigo" "app/roteador.py"
    }
  }
}
roteador -> fila "Publica a tarefa"

Três comandos. Nada é escrito sem você ver antes.

# versão 0.1.0 no repositório · licença MIT
git clone https://github.com/skarL007/lodemap && cd lodemap
python -m lodemap instalar --perfil padrao            # simulação: só mostra
python -m lodemap instalar --perfil padrao --aplicar  # aplica, com backup e manifesto

python -m lodemap plano --repo .   # 0 tokens: módulos, tempo, arquivos
python -m lodemap consentir --repo . --escopos gerar,modelo
python -m lodemap reverter         # desfaz a última instalação

• Plano antes de tudoO plano conta os módulos, estima o tempo pela rodada medida e lista os arquivos que seriam criados. Não chama modelo. Se não achar módulo, avisa em vez de estimar zero.
• Consentimento por escopogerar (só scripts), gancho (commit) e modelo (passos com modelo, dentro de um teto mensal finito).
• O que o consentimento não éUm registro que a skill e os agentes leem e seguem. Nenhum hook o impõe; o único hook instalado só mostra um aviso uma vez.
• Gancho de commit opcionalSó executa scripts cujo hash foi aprovado. Depois de um git pull que os muda, registra o aviso e não roda nada até nova aprovação.

O que ele ainda não faz, escrito como diff.

• −
  Economia de tokens para agentes: não demonstrada.Num teste pré-registrado (Sonnet, 16 tarefas de navegação no chi e no axios, 3 rodadas cada), os tokens foram os mesmos com e sem o mapa: razão mediana 0,99. O acerto se manteve (recall 0,991 contra 0,977). Ele é antes de tudo um mapa para pessoas.
• −
  Ganho de entendimento para pessoas: não medido ainda.Ainda não há medição com leitores. O estudo está pré-registrado, com gabarito e análise fixados antes da coleta.
• −
  Telemetria em execução: fora do escopo.O modo Saúde reúne evidências estáticas e relatórios disponíveis. Ele não observa o sistema em execução; a árvore de trabalho não é verificada.
• −
  Evidências de teste são estáticas.A demo reúne cinco releases auditadas, de v1.17.0 a v1.21.1, mas o modo Saúde mostra só referências estáticas de testes: os relatórios de cobertura e JUnit estão ausentes, então o resultado de execução é desconhecido.
• −
  As fases que chamam modelo só rodaram no Windows.A suíte passa no CI em Linux, macOS e Windows (commit 47dfe73). Scripts, testes, regeneração e gancho rodaram também no Linux (Ubuntu 24.04); as fases que chamam modelo, só no Windows.
• −
  Ainda há frases falsas.Com a conferência, 5 de 213 descrições de módulo eram falsas segundo um juiz Sonnet no chi e no axios (antes dela, 15 de 108). A conferência usa cerca de 3,7 vezes os tokens.
• −
  Prova de relação só por imports.Macros do Rust, reflection e injeção de dependência não são seguidos. Java, Kotlin, C# e C/C++ ainda não têm medição em repositório real. Passos com modelo enviam à Anthropic o código que leem, pelo Claude Code.
• +
  Geração do mapa, explorador, leitor, gate e atualização incremental.Medidos em dois repositórios públicos, axios e rich. Gate estrutural 94,6, piso 84,6 e 72 módulos cobertos na demo v1.21.1.
• +
  Instalador reversível, permissão por escopo e gancho com hash aprovado.Suíte do produto: 616 testes aprovados no Windows (4 pulados) e 577 no Linux (43 pulados), commit bb347b5, 11/11/2026.
• +
  Teste pré-registrado publicado, com o resultado desfavorável.Licença MIT, README com números medidos, limites e segurança, e terminal em inglês ou português.