Otito

Contexto de repositório local-first e determinístico, mapas de código e análise de impacto de mudanças para agentes de codificação — além de um gate de prontidão para merge que dá aos mantenedores evidência independente antes de um humano aprovar um merge.

GitHub

Experimente este MCPPatrocinado

Documentação

Òtítọ́

Os modelos geram a mudança. A Otito prova se é seguro fazer o merge.

otito demo

otito

  ___ _____ ___ _____ ___
 / _ \_   _|_ _|_   _/ _ \
| | | || |  | |  | || | | |
| |_| || |  | |  | || |_| |
 \___/ |_| |___| |_| \___/

O loop genérico de agentes (prompts, tentativas, roteamento de ferramentas, edição de arquivos) está se tornando infraestrutura. Modelos de fronteira já planejam, buscam em repositórios, usam ferramentas e se recuperam de erros. Os fornecedores de modelos estão empacotando harnesses nativos com ferramentas de arquivo e execução em sandbox. Competir nesse espaço é uma aposta perdida.

O que continua estrategicamente importante é o harness de confiança: contexto preciso do repositório, limites de permissão e sandbox, validação exata contra o código alterado, políticas sensíveis a risco, CODEOWNERS e aprovação humana, recibos reproduzíveis e evidência independente que o modelo não pode conceder a si mesmo. Modelos mais fortes aumentam essa necessidade, porque as equipes deixarão que eles alterem mais código com menos supervisão.

Òtítọ́ é essa camada de confiança independente. É local-first, determinística e agnóstica em relação ao modelo: descobre repositórios, constrói índices locais, gera contexto consciente da tarefa antes de um agente editar, pontua o quanto uma mudança realmente afeta e controla a prontidão para merge. Funciona da mesma forma todas as vezes, sem servidor, sem conta e sem que o código saia da máquina. Não compete com Codex, Claude Code, Gemini, Cursor ou futuros harnesses nativos. Integra-se a eles e continua funcionando à medida que os modelos mudam por baixo.

Fluxo de trabalho de agente confiável

Novo na v1.9.2: otito agora está listado em mcpservers.org.

Request -> context -> scoped change -> exact validation -> review evidence -> human decision

A Otito ajuda o agente a entender e delimitar uma tarefa antes de editar e, em seguida, dá ao mantenedor evidências para decidir se deve confiar no resultado. Um gate local aprovado nunca é uma aprovação automática de merge: CI hospedado, revisão do GitHub, CODEOWNERS e a decisão humana de release permanecem como autoridades separadas.

Ela não tenta substituir harnesses nativos de agentes, opensrc, code-structure, Daytona ou Harnss. Ela dá a desenvolvedores e agentes de codificação uma única CLI que pode:

Gates de merge determinísticos são o núcleo diferenciado. Este é o checkpoint humano-no-loop que um modelo não pode avaliar por si mesmo:

pontuar a prontidão para merge de mudanças locais e pull requests com uma única ferramenta review_gate (gate na CLI)
executar um plano de validação protegido contra a árvore exata em staging e reter um recibo limitado de seus resultados
vincular mudanças em staging de web, API e contratos compartilhados em um único recibo de workspace
resolver CODEOWNERS para revisores obrigatórios e expor avisos de decisão do proprietário
verificar expectativas de proteção de branch e checks obrigatórios antes do merge
gerar contexto acionável de revisão de PR a partir de diffs de git e comentários opcionais do GitHub
provar continuamente o gate local contra um controle válido commitado e um corpus adversarial de mudanças com otito eval --gate-effectiveness

Contexto local-first alimenta os gates:

inspecionar um repositório
descobrir e indexar repositórios locais
manter um catálogo local e pesquisar nele
gerar pacotes de contexto conscientes da tarefa antes de um agente planejar ou editar
gerar mapas de código JSON-first com suporte a AST para agentes
gerar um harness de setup/validação/runtime para um repositório
produzir relatórios em Markdown ou JSON
estimar o tamanho de tokens de contexto para artefatos gerados
executar um servidor MCP para hosts de agentes com um cache de índice por usuário persistido que nunca suja um repositório inspecionado
expor metadados de ferramentas simples e amigáveis para agentes
verificar a disponibilidade de ferramentas
gerar HTML de estrutura TypeScript por meio de code-structure
pesquisar código-fonte de dependências por meio de opensrc

Documentação

O site MkDocs publicado é um guia prático de descoberta e entrega:

Leia em:

https://bashbop.github.io/otito/

Início Rápido

Mapas de código usam o compilador TypeScript para JS/TS e extratores de linguagem dedicados para Go, C#, Python, Java, Ruby e Rust (veja src/lib/code-map/ast-languages.js). Ferramentas externas opcionais são necessárias apenas para consulta de código-fonte de dependências e relatórios de estrutura HTML.

Instale o pacote publicado a partir do npm:

npm install -g @bashbop/otito
otito doctor
otito index ~/projects --discover
otito context "add a new MCP tool" --path .

Você também pode executar um comando sem instalação global:

npx -y @bashbop/otito doctor

Para desenvolvimento de código-fonte:

git clone https://github.com/BASHBOP/otito.git
cd otito
npm ci
npm run ci
node src/cli.js doctor

A versão atual está disponível via npm, GitHub Releases e no MCP Registry como io.github.BASHBOP/otito.

Execute a Otito como camada de confiança dentro de um workspace de agente Herdr:

herdr plugin install BASHBOP/otito/integrations/herdr
herdr plugin pane open --plugin bashbop.otito --entrypoint trust-status

O plugin Herdr usa a CLI otito instalada independentemente. O Herdr é dono dos terminais persistentes de agentes e worktrees; a Otito é dona do contexto, impacto, revisão e evidência determinística de gate.

otito repo . --json
otito discover ~/projects --depth 2 --json
otito index ~/projects --discover
otito catalog
otito search "events controller"
otito context "add a new MCP tool" --path .
otito impact . "add a new MCP tool" --top 12
otito ax . "add a new MCP tool"
otito map . --json
otito harness . --out .otito/harness.md
otito pr . --base origin/main --out .otito/pr-review.md
otito review . --request "add a new MCP tool" --base origin/main
otito gate . --staged --base origin/main
otito gate . --staged --run-validation
otito mcp
otito report . --out .otito/report.md
otito workspace /path/to/web /path/to/api --out .otito/workspace.md
otito workspace-gate /path/to/web /path/to/api --request "ship the product change" --out .otito/workspace-gate.md

Ferramentas externas opcionais:

npm install -g opensrc code-structure

Então:

otito deps zod --query parse
otito structure . --out .otito/structure.html

Exemplos de Uso

Objetivo	Comando	Saída
Inspecionar um repositório	`otito repo . --json`	Fatos do repositório, scripts, linguagens, entrypoints e estado do git
Construir um mapa de código	`otito map . --json`	Arquivos-fonte, domínios, imports, exports, símbolos e rotas
Preparar contexto de tarefa	`otito context "add a new MCP tool" --path .`	Arquivos primários, arquivos relacionados, testes, padrões e comandos de validação
Gerar um harness de agente	`otito harness . --out .otito/harness.md`	Comandos de setup, validação, runtime e contexto
Aplicar gate a uma mudança exata em staging	`otito gate . --staged --run-validation`	Resultados de validação versionados vinculados à árvore Git em staging
Aplicar gate a uma mudança de produto	`otito workspace-gate ../web ../api --request "ship change"`	Um recibo em vários repositórios em staging
Revisar mudanças locais	`otito pr . --base origin/main --out .otito/pr-review.md`	Arquivos alterados, prompts de risco, alvos de revisão e dicas de teste
Indexar projetos locais	`otito index ~/projects --discover`	Índices externos por usuário mais um catálogo local
Pesquisar repositórios indexados	`otito search "events controller"`	Correspondências ranqueadas em caminhos, domínios, rotas, imports, exports e símbolos
Executar o servidor MCP	`otito mcp`	Servidor MCP stdio expondo ferramentas otito
Rastrear uso e desempenho	`otito dashboard`	HTML autocontido a partir de um log de uso local opt-in (desativado por padrão)
Ajudar a melhorar a Otito	`otito telemetry share on`	Opte separadamente por um evento de uso anônimo mínimo; sem prompts, caminhos, dados de repositório ou conteúdo de código-fonte

Para Codex, Claude Desktop, VS Code, Cursor, Gemini CLI, Kimi Code, orientação de handoff Grok e trechos genéricos de clientes stdio, veja Fluxos de Trabalho MCP e de Agentes.

otito vs alternativas

Abordagem	Pontos fortes	Onde otito difere
Contexto Sourcegraph / Cody	Busca de código hospedada poderosa e contexto baseado em embeddings em toda a organização	otito é local-first e determinística: sem servidor, sem conta, sem código saindo da máquina, e a mesma consulta sempre produz o mesmo pacote
Arquivos `CLAUDE.md` / regras escritos à mão	Orientação curada e rica em intenção	Contexto escrito à mão fica desatualizado; otito regenera o contexto a partir do código real (símbolos, imports, rotas, testes) a cada execução e complementa um `CLAUDE.md` curto
`grep` / `ripgrep`	Correspondência de texto rápida e universal	otito ranqueia arquivos inteiros por intenção de tarefa em caminhos, símbolos, exports e testes, e então adiciona padrões e comandos de validação. O resultado é um pacote de contexto, não uma lista de linhas correspondentes

Gates de Qualidade

Use o gate completo antes de abrir um pull request ou publicar um release:

npm run ci

O gate executa:

npm run format:check
npm run lint
npm run typecheck
npm run version:check
npm test
npm run test:coverage
npm run eval:accuracy
npm run eval:harness
npm run eval:gate
npm run audit
npm run smoke

A cobertura atualmente limita arquivos-fonte a 70% de linhas, 60% de branches e 75% de funções. Artefatos gerados sob .otito/ são ignorados por git, linting e formatação; mantenha relatórios duráveis lá em vez de commitá-los.

A avaliação de execução do harness executa apenas comandos vetted de instalação, teste, typecheck e build contra fixtures commitadas. Ela desativa scripts de ciclo de vida de instalação, aplica timeouts e nunca executa comandos inferidos de um repositório de cliente.

A avaliação de eficácia do gate cria repositórios Git isolados a partir de uma base commitada, aplica diretórios ou patches de mudança revisados e invoca o gate local real em staging. Sua linha de base prova que uma mudança válida é permitida e que seis mudanças conhecidamente ruins são bloqueadas por seus motivos codificados. Ela não pode executar comandos fornecidos pelo corpus nem inspecionar um repositório de cliente.

Verificações de desempenho

Execute o benchmark da CLI ao alterar startup, varredura de repositório ou comportamento de mapa de código:

npm run benchmark:cli -- --iterations 5
npm run benchmark:cli -- --iterations 5 --json

Ele mede os caminhos leves version e help mais uma execução completa de context. Os tempos incluem startup do Node e execução de comandos. Compare resultados na mesma máquina e checkout; o benchmark relata medições, mas não impõe limites dependentes de máquina no CI.

otito segue Versionamento Semântico. Pull requests devem identificar se são mudanças sem impacto de versão, patch, minor ou major; os mantenedores aplicam a versão final do pacote durante o release.

Para trabalho mais longo na camada de confiança, use o Loop Operacional Builder-Founder para manter cada sessão ligada a contexto, mudanças focadas, gates visíveis, decisões humanas e evidência durável.

Contribuindo

Contribuições são bem-vindas. Comece com CONTRIBUTING.md, siga o Código de Conduta e leia Governança de Contribuidores para regras de revisão e merge.

Abra uma issue ou PR rascunho para mudanças substanciais e execute npm run ci antes de solicitar revisão. Todas as mudanças de código devem ser revisadas por um mantenedor/proprietário de código antes do merge. O branch protegido main exige aprovação de mantenedor, gates de qualidade aprovados e conversas de PR resolvidas.

Fluxos de Trabalho Comuns

Harness de repositório para agentes:

otito harness . --out .otito/harness.md
otito map . --json

Descoberta local, indexação, catálogo e pesquisa:

otito discover ~/projects --depth 2
otito index ~/projects --discover
otito catalog
otito search "submit rsvp"

Contexto de agente consciente da tarefa:

otito context "add a new MCP tool" --path . --json
otito context "add a new MCP tool" --path . --out .otito/context-pack.md

Harness de revisão de PR:

otito pr . --base origin/main --out .otito/pr-review.md
otito pr . --number 123 --comment

Gate de merge (gate é o comando canônico v2; pass / pass-pr permanecem como aliases legados):

otito gate . --base origin/main          # local gate (no GitHub)
otito gate . --staged --base origin/main # staged-path evidence, suitable for pre-commit hooks
otito gate . --staged --run-validation   # run the base-committed validation plan against the exact staged tree
otito gate . --base origin/main --request "update the greeting" --min-convergence 80
otito converge "update the greeting" --path . --base HEAD --staged --json # exact change-subject receipt
otito gate --pr 123 --path .             # GitHub PR gate via gh

No modo de estágio, evidências de caminho alterado, risco, segredo e convergência usam a árvore de índice Git exata. A análise de fonte de assunto exato transmite blobs Git brutos e falha de forma fechada acima de 5.000 arquivos de origem ou 64 MiB. --run-validation adicionalmente executa apenas um plano versionado de otito.gate.json no commit base selecionado contra uma cópia isolada dessa árvore de estágio. Ele registra comandos, resultados de saída e hashes de saída em um recibo de validação separado; nunca registra saída bruta. As formas de script de gerenciador de pacotes suportadas incluem invocações diretas e run para npm, pnpm, Yarn, Bun e comandos encapsulados por Corepack. A identidade do script de base selecionada é fixada, então um manifesto de estágio não pode substituí-los por um no-op. Outros comandos comprometidos na base permanecem comandos de política válidos; adicionar uma nova forma de script de gerenciador de pacotes exige a mesma semântica de fixação e cobertura de regressão. A validação começa com um ambiente limpo e home isolado; apenas variáveis explicitamente permitidas passam. O instantâneo de origem é exato, enquanto um diretório node_modules local vinculado é explicitamente relatado como não atestado neste primeiro incremento. As verificações de lançamento e analisador opcionais ainda inspecionam a árvore de trabalho e permanecem fora desse recibo.

Crie a política no branch base protegido antes de pedir ao gate para executá-la:

{
  "version": 1,
  "validation": {
    "environment": { "allow": ["TEST_DATABASE_URL"] },
    "commands": [{ "id": "unit", "command": "npm test", "timeoutSeconds": 300 }]
  }
}

environment.allow é opcional. Use-o apenas para as variáveis específicas que um plano de validação protegido exige; os valores nunca são registrados no recibo.

Contexto de produto multi-repo:

otito workspace ../web ../api --out .otito/workspace.md
otito workspace-gate ../web ../api --base origin/main --request "ship Audience Studio preview" --out .otito/workspace-gate.md

workspace-gate cria um recibo pai em dois ou mais repositórios de estágio. Ele vincula a identidade exata da base, pai e árvore de estágio de cada repositório, o escopo de arquivos alterados, verificações de gate local e qualquer recibo de validação. Todos os repositórios devem ter um assunto de estágio antes que o recibo pai seja emitido.

Bootstrap do GitHub Actions:

otito init /path/to/target-repo

Revisão local do Ollama:

otito harness . --out .otito/harness.md

{
  echo "Use this repo harness to explain the project and suggest the next best engineering task."
  echo
  cat .otito/harness.md
} | ollama run qwen3:8b --think false --hidethinking --nowordwrap

Revisão de PR local do Ollama:

otito pr . --base origin/main --out .otito/pr-review.md

{
  echo "Review this PR context. Focus on bugs, missing tests, and risky changes."
  echo
  cat .otito/pr-review.md
} | ollama run qwen3:8b --think false --hidethinking --nowordwrap

Comandos

`doctor`

Verifica o runtime local e ferramentas externas opcionais.

otito doctor --json

`install` / `i`

Imprime comandos de instalação e status binário atual. De um checkout local, --global executa npm install -g .; --link executa npm link.

otito install
otito i
otito install --global
otito install --json

Após a instalação, use otito como o comando.

`repo <path>`

Inspeciona a forma do repo: arquivos, metadados de pacote, linguagens, gerenciadores de pacotes, scripts, entrypoints prováveis, metadados git e diretórios pesados em ignorados.

otito repo . --json

Repositórios Git são escaneados através de git ls-files --cached --others --exclude-standard para que arquivos ignorados não poluam o contexto do harness. Diretórios simples recorrem ao walker embutido.

`discover <root...>`

Descobre raízes de repositório sob um ou mais diretórios locais sem indexá-los.

otito discover ~/projects --depth 2
otito discover . --json

A descoberta para em diretórios com marcadores de repo comuns, como package.json, .git, pyproject.toml, go.mod, Cargo.toml e Package.swift.

`index <repo...>`

Gera índices externos por usuário e adiciona repositórios ao catálogo local. Os repositórios inspecionados não são modificados.

otito index .
otito index ~/projects --discover
otito index . --catalog /tmp/otito-catalog.json --json

O caminho padrão do catálogo é ~/.otito/catalog.json. Defina OTITO_CATALOG ou passe --catalog para usar um arquivo diferente.

`catalog`

Lista repositórios atualmente indexados no catálogo local.

otito catalog
otito catalog --json

`search <query>`

Pesquisa repositórios locais indexados por caminho, domínio, tipo, rota, caminho de controlador, imports, exports e símbolos.

otito search "events controller"
otito search "submit rsvp" --limit 10
otito search "api client" --offline --json

Por padrão, a pesquisa atualiza os índices do repo quando as impressões digitais mudam. Use --offline para ler apenas os índices externos armazenados.

`context <query>`

Gera um pacote de contexto de mecanismo local para uma tarefa. O pacote inclui intenção inferida, arquivos primários, arquivos relacionados, testes correspondentes, padrões de implementação, comandos de validação, conflitos, evidência de origem e estimativas de token.

otito context "add a new MCP tool" --path . --json
otito context "add a new CLI command" --path . --out .otito/context-pack.md

Use isso antes de entregar trabalho a um agente de codificação. É determinístico e local-first: depende de índices de repo, mapas de código, relacionamentos de import, testes e comandos de harness em vez de um modelo externo.

`obsidian <repo>`

Exporta um vault Markdown compatível com Obsidian a partir do mapa do repositório. O vault inclui uma nota inicial navegável, arquivos e entrypoints do repositório, um índice de evidências e notas opcionais de contexto e impacto específicas da tarefa.

otito obsidian . --query "add a new MCP tool" --out .otito/obsidian

O diretório de saída padrão é .otito/obsidian. O vault é uma projeção legível da evidência do Otito; ele não substitui gates exatos de árvore de estágio, CI hospedado, CODEOWNERS ou revisão humana.

`harness <path>`

Gera um harness de repo com comandos de configuração, scripts de validação, scripts de runtime, comandos de contexto, áreas de foco e uso estimado de tokens de contexto.

otito harness . --out .otito/harness.md
otito harness . --json

Use isso como o primeiro artefato que um agente ou fluxo de trabalho de CI lê antes de tocar no código.

`init <path>`

Estrutura o otito em outro repositório.

otito init /path/to/target-repo
otito init /path/to/target-repo --force
otito init /path/to/target-repo --no-workflow
otito init /path/to/target-repo --tool-repo BASHBOP/otito --tool-ref main

Arquivos gerados:

.otito/README.md
.github/workflows/otito-ci.yml

O fluxo de trabalho gerado executa em pull requests e pushes de commit. Execuções de pull request geram o relatório, enviam um artefato e criam ou atualizam um comentário fixo de PR. Execuções de push geram e enviam o artefato do relatório sem comentar.

`structure <path>`

Executa code-structure contra arquivos TypeScript.

otito structure . --pattern "app/**/*.tsx" --out .otito/structure.html

Se code-structure estiver ausente, o comando retorna uma dica de instalação em vez de falhar misteriosamente. Se não estiver instalado globalmente, mas npx estiver disponível, o otito pode executá-lo através de npx --yes code-structure.

`deps <package>`

Usa opensrc path <package> para resolver a origem da dependência e opcionalmente pesquisá-la.

otito deps zod --query parse --limit 20

`report <path>`

Gera um relatório de desenvolvedor compartilhável.

otito report .
otito report . --out .otito/report.md
otito report . --json

A saída padrão é formatada para leitura em terminal e termina com uso estimado de token. Use --out para o artefato Markdown ou --json para dados estruturados.

`workspace <repo...>`

Gera um relatório de nível de produto em repos relacionados.

otito workspace /path/to/web /path/to/api --out .otito/workspace.md
otito workspace /path/to/web /path/to/api --json

`pr <path>`

Gera um pacote de contexto de revisão de PR a partir de metadados de diff git local, classificação de mapa de código, alvos de revisão, prompts de revisão direcionados, sinalizadores de risco, comandos de verificação sugeridos, tokens estimados e comentários opcionais de PR do GitHub.

otito pr . --base origin/main --out .otito/pr-review.md
otito pr . --number 123 --comment

Sinalizadores úteis:

--base <ref>: comparar de uma ref base específica. Padrão para base de PR, upstream, origin/main ou main.
--head <ref>: comparar a uma ref head específica. Padrão para HEAD.
--number <n>: enriquecer com metadados gh pr view e comentários de revisão.
--github: pedir a gh para inferir o PR do branch atual.
--comment: criar ou atualizar um comentário fixo de PR do GitHub usando gh.

GitHub Actions

Este repo inclui .github/workflows/otito-ci.yml. O fluxo de trabalho instala dependências, executa npm run ci e então gera contexto de revisão de PR ou push como um artefato enviado. Use otito init /path/to/target-repo para estruturar um fluxo de trabalho de revisão do Otito em outro repositório.

`mcp`

Inicia um servidor MCP stdio expondo o otito como ferramentas chamáveis por agente. Consultas de mapa de repo MCP usam um cache externo por usuário com impressão digital de arquivo, atualizam quando os arquivos mudam e nunca escrevem no repositório inspecionado.

O servidor é publicado no Registro MCP como io.github.BASHBOP/otito.

otito mcp

Ao conectá-lo a um host MCP (Claude Desktop, Claude Code, Codex CLI, Cursor, etc.):

{
  "mcpServers": {
    "otito": {
      "command": "npx",
      "args": ["-y", "@bashbop/otito", "mcp"]
    }
  }
}

Se você preferir um binário instalado globalmente:

{
  "mcpServers": {
    "otito": {
      "command": "otito",
      "args": ["mcp"]
    }
  }
}

Ollama pode fornecer o modelo local, mas não chama ferramentas MCP por si só. Para usar o otito através de MCP com um modelo local, use um cliente de agente compatível com MCP que suporte Ollama como provedor de modelo e configure o servidor otito acima.

Òtítọ́ expõe 13 ferramentas MCP para inspeção de repositório, contexto, impacto, revisão e evidência de merge.

Ferramenta	Propósito
`repo_inspect`	Inspecionar forma do repositório, scripts, gerenciadores de pacotes, entrypoints e estado git
`repo_map`	Mapa de código JSON compacto, filtrável por `domain`, `kind` e `route`
`repo_index`	Gerar índices externos + entradas de catálogo; `dryRun:true` descobre somente leitura
`repo_search`	Pesquisar o catálogo; omita `query` para retornar a listagem do catálogo
`context_pack`	Construir um pacote de contexto ciente de tarefa
`change_impact`	Classificar arquivos mais prováveis de possuir uma solicitação de mudança em inglês simples
`agent_experience`	Pontuar Experiência de Agente (AX 0–100): capacidade de mudança, contenção, guardrails, clareza
`convergence_score`	Pontuar intenção vs. execução (0–100) com um recibo exato de assunto de mudança
`review_context`	Contexto de revisão de diff/comentário (sem veredito)
`review_gate`	Gate de merge PASS/WARN/FAIL: local sem `pr`, gate de PR do GitHub com `pr`
`review_verdict`	Veredito composto: impacto + contexto_de_revisão + gate_de_revisão
`workspace_report`	Relatório de nível de produto em múltiplos repos
`repo_harness`	Comandos de configuração, validação, runtime e contexto para um harness de agente ou CI

`matrix`

Imprime a matriz de avaliação de ferramentas para Greploop, code-structure, opensrc, Daytona e Harnss.

`agent-tools`

Imprime metadados JSON ou Markdown derivados do catálogo canônico de ferramentas MCP, mantendo integrações CLI e MCP alinhadas.

Estratégia

Envolva primeiro. Meça a dor. Construa apenas as peças ausentes.

Isso mantém o projeto útil rapidamente, deixando espaço para substituir adaptadores fracos por implementações próprias depois.

Parte da cadeia de ferramentas

otito é uma das quatro ferramentas que formam uma camada de confiança determinística para desenvolvimento assistido por IA. Cada uma usa análise estática para responder a uma pergunta que as pessoas continuam entregando a um LLM.

otito (esta ferramenta), para contexto: o que essa mudança realmente toca?
tieline, para contratos: o front end e o back end pararam silenciosamente de concordar?
bouncer, para conformidade: você poderia defender isso para a Ofcom?
aiglare, para governança: onde o modelo pode fazer algo que você não pode desfazer?

Mais em segunolumbe.com. análise estática, nunca o modelo.

Otito

Documentação

Òtítọ́

Fluxo de trabalho de agente confiável

Documentação

Início Rápido

Exemplos de Uso

otito vs alternativas

Gates de Qualidade

Verificações de desempenho

Contribuindo

Fluxos de Trabalho Comuns

Comandos

doctor

install / i

repo <path>

discover <root...>

index <repo...>

catalog

search <query>

context <query>

obsidian <repo>

harness <path>

init <path>

structure <path>

deps <package>

report <path>

workspace <repo...>

pr <path>

GitHub Actions

mcp

matrix

agent-tools

Estratégia

Parte da cadeia de ferramentas

`doctor`

`install` / `i`

`repo <path>`

`discover <root...>`

`index <repo...>`

`catalog`

`search <query>`

`context <query>`

`obsidian <repo>`

`harness <path>`

`init <path>`

`structure <path>`

`deps <package>`

`report <path>`

`workspace <repo...>`

`pr <path>`

`mcp`

`matrix`

`agent-tools`