Otito

Òtítọ́

Los modelos generan el cambio. Otito demuestra si es seguro fusionarlo.

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

El bucle genérico de agentes (prompts, reintentos, enrutamiento de herramientas, edición de archivos) se está convirtiendo en infraestructura. Los modelos de frontera ya planifican, buscan en repositorios, usan herramientas y se recuperan de errores. Los proveedores de modelos están empaquetando entornos nativos con herramientas de archivos y ejecución en sandbox. Competir ahí es una apuesta perdedora.

Lo que sigue siendo estratégicamente importante es el marco de confianza: contexto preciso del repositorio, límites de permisos y sandbox, validación exacta contra el código modificado, políticas sensibles al riesgo, CODEOWNERS y aprobación humana, recibos reproducibles y evidencia independiente que el modelo no puede otorgarse a sí mismo. Los modelos más potentes aumentan esa necesidad, porque los equipos les permitirán cambiar más código con menos supervisión.

Òtítọ́ es esa capa de confianza independiente. Es local-first, determinista y agnóstica al modelo: descubre repositorios, construye índices locales, genera contexto consciente de la tarea antes de que un agente edite, puntúa cuánto toca realmente un cambio y controla la preparación para la fusión. Funciona igual cada vez, sin servidor, sin cuenta y sin que el código salga de la máquina. No compite con Codex, Claude Code, Gemini, Cursor ni con los futuros entornos nativos. Se integra con ellos y sigue funcionando mientras los modelos cambian por debajo.

Flujo de trabajo de agente confiable

Nuevo en v1.9.2: otito ahora está listado en mcpservers.org.

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

Otito ayuda al agente a comprender y acotar una tarea antes de editar, y luego le da al mantenedor evidencia para decidir si confiar en el resultado. Un control local aprobado nunca es una aprobación automática de fusión: el CI alojado, la revisión de GitHub, CODEOWNERS y la decisión humana de lanzamiento siguen siendo autoridades separadas.

No intenta reemplazar los entornos nativos de agentes, opensrc, code-structure, Daytona ni Harnss. Ofrece a desarrolladores y agentes de codificación una única CLI que puede:

Los controles de fusión deterministas son el núcleo diferenciado. Este es el punto de control con intervención humana que un modelo no puede calificar por sí mismo:

• puntuar la preparación para la fusión de cambios locales y pull requests con una única herramienta review_gate (gate en la CLI)
• ejecutar un plan de validación protegido contra el árbol de cambios exacto y conservar un recibo acotado de sus resultados
• vincular cambios web, de API y de contratos compartidos en un único recibo de espacio de trabajo
• resolver CODEOWNERS para los revisores requeridos y mostrar advertencias de decisiones de propietarios
• verificar las expectativas de protección de rama y los controles requeridos antes de la fusión
• generar contexto de revisión de PR accionable a partir de diffs de git y comentarios opcionales de GitHub
• probar continuamente el control local contra un control válido confirmado y un corpus de cambios adversos con otito eval --gate-effectiveness

El contexto local-first alimenta los controles:

• inspeccionar un repositorio
• descubrir e indexar repositorios locales
• mantener un catálogo local y buscar en él
• generar paquetes de contexto conscientes de la tarea antes de que un agente planifique o edite
• generar mapas de código JSON-first respaldados por AST para agentes
• generar un entorno de configuración/validación/ejecución para un repositorio
• producir informes en Markdown o JSON
• estimar el tamaño de tokens de contexto para artefactos generados
• ejecutar un servidor MCP para hosts de agentes con una caché de índice por usuario persistente que nunca ensucia un repositorio inspeccionado
• exponer metadatos de herramientas simples y amigables para agentes
• verificar la disponibilidad de herramientas
• generar HTML de estructura TypeScript mediante code-structure
• buscar en el código fuente de dependencias mediante opensrc

Documentación

El sitio MkDocs publicado es una guía práctica de descubrimiento y entrega:

• Inicio
• Resumen Ejecutivo
• Fundamento de Contexto
• Flujos de Trabajo MCP y de Agentes
• Gobernanza de Contribuidores
• Preparación para el Lanzamiento
• Demostración de la Capa de Confianza
• Bucle Operativo Constructor-Fundador
• Tesis del Entorno y Experiencia del Agente
• Integración de Tutoriales (Codespaces)
• Tesis de Convergencia y Puntuación
• Panel de Uso y Rendimiento
• Tesis de Determinismo y Límite del Entorno
• Tesis de Doble Modo y Pila Complementaria
• Tesis de Determinismo de Prompts y Trampa de Configuración
• Tesis del Marco de Confianza y Bucle de Productos Básicos
• Integración con Herdr
• Tesis de Código Limpio y el Archivo de Propietario Más Pequeño
• Método de Evaluación y Corpus de Efectividad de Controles
• Glosario

Léelo en:

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

Inicio Rápido

Los mapas de código usan el compilador de TypeScript para JS/TS y extractores de lenguaje dedicados para Go, C#, Python, Java, Ruby y Rust (consulta src/lib/code-map/ast-languages.js). Las herramientas externas opcionales solo se necesitan para la búsqueda de código fuente de dependencias y los informes de estructura HTML.

Instala el paquete publicado desde npm:

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

También puedes ejecutar un comando sin instalación global:

npx -y @bashbop/otito doctor

Para desarrollo desde el código fuente:

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

La versión actual está disponible a través de npm, GitHub Releases y el Registro MCP como io.github.BASHBOP/otito.

Ejecuta Otito como capa de confianza dentro de un espacio de trabajo de agente Herdr:

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

El plugin de Herdr usa la CLI otito instalada de forma independiente. Herdr posee los terminales de agente persistentes y los worktrees; Otito posee el contexto, el impacto, la revisión y la evidencia de control determinista.

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

Herramientas externas opcionales:

npm install -g opensrc code-structure

Luego:

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

Ejemplos de Uso

Objetivo	Comando	Salida
Inspeccionar un repositorio	otito repo . --json	Datos del repositorio, scripts, lenguajes, puntos de entrada y estado de git
Construir un mapa de código	otito map . --json	Archivos fuente, dominios, imports, exports, símbolos y rutas
Preparar contexto de tarea	otito context "add a new MCP tool" --path .	Archivos principales, archivos relacionados, pruebas, patrones y comandos de validación
Generar un entorno de agente	otito harness . --out .otito/harness.md	Comandos de configuración, validación, ejecución y contexto
Controlar un cambio exacto en stage	otito gate . --staged --run-validation	Resultados de validación versionados vinculados al árbol Git en stage
Controlar un cambio de producto	otito workspace-gate ../web ../api --request "ship change"	Un recibo único en repositorios en stage
Revisar cambios locales	otito pr . --base origin/main --out .otito/pr-review.md	Archivos modificados, prompts de riesgo, objetivos de revisión y sugerencias de prueba
Indexar proyectos locales	otito index ~/projects --discover	Índices externos por usuario más un catálogo local
Buscar repositorios indexados	otito search "events controller"	Coincidencias clasificadas en rutas, dominios, rutas de acceso, imports, exports y símbolos
Ejecutar el servidor MCP	otito mcp	Servidor MCP stdio que expone las herramientas de otito
Rastrear uso y rendimiento	otito dashboard	HTML autocontenido desde un registro de uso local opcional (desactivado por defecto)
Ayudar a mejorar Otito	otito telemetry share on	Activa por separado un evento de uso anónimo mínimo; sin prompts, rutas, datos de repositorio ni contenido fuente

Para Codex, Claude Desktop, VS Code, Cursor, Gemini CLI, Kimi Code, orientación de transferencia a Grok y fragmentos genéricos de clientes stdio, consulta Flujos de Trabajo MCP y de Agentes.

otito frente a alternativas

Enfoque	Fortalezas	Dónde difiere otito
Contexto de Sourcegraph / Cody	Búsqueda de código alojada potente y contexto basado en embeddings en toda la organización	otito es local-first y determinista: sin servidor, sin cuenta, sin que el código salga de la máquina, y la misma consulta siempre produce el mismo paquete
Archivos CLAUDE.md / reglas escritos a mano	Orientación curada y rica en intención	El contexto escrito a mano queda obsoleto; otito regenera el contexto desde el código real (símbolos, imports, rutas, pruebas) en cada ejecución y complementa un CLAUDE.md breve
grep / ripgrep	Coincidencia de texto rápida y universal	otito clasifica archivos completos por intención de tarea en rutas, símbolos, exports y pruebas, y luego añade patrones y comandos de validación. El resultado es un paquete de contexto, no una lista de líneas coincidentes

Controles de Calidad

Usa el control completo antes de abrir un pull request o publicar un lanzamiento:

npm run ci

El control ejecuta:

• 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

La cobertura actualmente controla archivos fuente al 70% de líneas, 60% de ramas y 75% de funciones. Los artefactos generados bajo .otito/ son ignorados por git, linting y formato; guarda informes duraderos allí en lugar de confirmarlos.

La evaluación de ejecución del entorno solo ejecuta comandos verificados de instalación, prueba, typecheck y compilación contra fixtures confirmados. Desactiva los scripts de ciclo de vida de instalación, aplica tiempos de espera y nunca ejecuta comandos inferidos de un repositorio de cliente.

La evaluación de efectividad de controles crea repositorios Git aislados desde una base confirmada, aplica directorios o parches de cambios revisados e invoca el control local real en stage. Su línea base demuestra que un cambio válido se permite y que seis cambios conocidos como defectuosos se bloquean por sus razones codificadas. No puede ejecutar comandos proporcionados por el corpus ni inspeccionar un repositorio de cliente.

Comprobaciones de rendimiento

Ejecuta el benchmark de la CLI al cambiar el inicio, el escaneo de repositorios o el comportamiento de mapas de código:

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

Mide las rutas ligeras version y help más una ejecución completa de context. Los tiempos incluyen el inicio de Node y la ejecución de comandos. Compara resultados en la misma máquina y checkout; el benchmark informa mediciones pero no impone umbrales dependientes de la máquina en CI.

otito sigue Versionado Semántico. Los pull requests deben identificar si son cambios sin impacto de versión, patch, minor o major; los mantenedores aplican la versión final del paquete durante el lanzamiento.

Para trabajo más largo en la capa de confianza, usa el Bucle Operativo Constructor-Fundador para mantener cada sesión vinculada al contexto, cambios enfocados, controles visibles, decisiones humanas y evidencia duradera.

Contribuciones

Las contribuciones son bienvenidas. Comienza con CONTRIBUTING.md, sigue el Código de Conducta y lee Gobernanza de Contribuidores para las reglas de revisión y fusión.

Abre un issue o un PR borrador para cambios sustanciales y ejecuta npm run ci antes de solicitar revisión. Todos los cambios de código deben ser revisados por un mantenedor/propietario de código antes de la fusión. La rama protegida main requiere aprobación del mantenedor, controles de calidad aprobados y conversaciones de PR resueltas.

Flujos de Trabajo Comunes

Entorno de repositorio para agentes:

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

Descubrimiento local, indexación, catálogo y búsqueda:

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

Contexto de agente consciente de la tarea:

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

Entorno de revisión de PR:

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

Control de fusión (gate es el comando canónico v2; pass / pass-pr siguen siendo alias heredados):

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

En modo por etapas, la evidencia de rutas modificadas, riesgo, secretos y convergencia utiliza el árbol de índice exacto de Git. El análisis de fuente de asunto exacto transmite blobs crudos de Git y falla de forma cerrada por encima de 5,000 archivos fuente o 64 MiB. --run-validation además ejecuta solo un plan versionado de otito.gate.json en el commit base seleccionado contra una copia aislada de ese árbol por etapas. Registra comandos, resultados de salida y hashes de salida en un recibo de validación separado; nunca registra salida cruda. Las formas de script de administrador de paquetes compatibles incluyen invocaciones directas y de run para npm, pnpm, Yarn, Bun y comandos envueltos por Corepack. Su identidad de script de base seleccionada está fijada, por lo que un manifiesto por etapas no puede reemplazarlos con un no-op. Otros comandos comprometidos en la base siguen siendo comandos de política válidos; agregar una nueva forma de script de administrador de paquetes requiere la misma semántica de fijación y cobertura de regresión. La validación comienza con un entorno depurado y un hogar aislado; solo las variables explícitamente permitidas pasan. La instantánea de fuente es exacta, mientras que un directorio local vinculado de node_modules se reporta explícitamente como no atestiguado en este primer incremento. Los análisis de lanzamiento y de analizador opcional aún inspeccionan el árbol de trabajo y permanecen fuera de ese recibo.

Cree la política en la rama base protegida antes de pedirle a la puerta que la ejecute:

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

environment.allow es opcional. Úselo solo para las variables específicas que requiere un plan de validación protegido; los valores nunca se registran en el recibo.

Contexto de producto multi-repositorio:

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 crea un recibo principal único en dos o más repositorios por etapas. Vincula la identidad exacta de base, padre y árbol por etapas de cada repositorio, el alcance de archivos modificados, las verificaciones de puerta local y cualquier recibo de validación. Todos los repositorios deben tener un asunto por etapas antes de que se emita el recibo principal.

Arranque de GitHub Actions:

otito init /path/to/target-repo

Revisión local de 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

Revisión de PR local de 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 el entorno de ejecución local y las herramientas externas opcionales.

otito doctor --json

install / i

Imprime comandos de instalación y estado actual del binario. Desde un checkout local, --global ejecuta npm install -g .; --link ejecuta npm link.

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

Después de la instalación, use otito como el comando.

repo <path>

Inspecciona la forma del repositorio: archivos, metadatos de paquetes, lenguajes, administradores de paquetes, scripts, puntos de entrada probables, metadatos de git y directorios con muchos ignorados.

otito repo . --json

Los repositorios de Git se escanean a través de git ls-files --cached --others --exclude-standard para que los archivos ignorados no contaminen el contexto del arnés. Los directorios simples recurren al caminante integrado.

discover <root...>

Descubre raíces de repositorios bajo uno o más directorios locales sin indexarlos.

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

El descubrimiento se detiene en directorios con marcadores comunes de repositorio como package.json, .git, pyproject.toml, go.mod, Cargo.toml y Package.swift.

index <repo...>

Genera índices externos por usuario y agrega repositorios al catálogo local. Los repositorios inspeccionados no se modifican.

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

La ruta predeterminada del catálogo es ~/.otito/catalog.json. Establezca OTITO_CATALOG o pase --catalog para usar un archivo diferente.

catalog

Lista los repositorios actualmente indexados en el catálogo local.

otito catalog
otito catalog --json

search <query>

Busca repositorios locales indexados por ruta, dominio, tipo, ruta de controlador, rutas de controlador, importaciones, exportaciones y símbolos.

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

Por defecto, la búsqueda actualiza los índices de repositorio cuando cambian las huellas digitales. Use --offline para leer solo los índices externos almacenados.

context <query>

Genera un paquete de contexto de motor local para una tarea. El paquete incluye intención inferida, archivos primarios, archivos relacionados, pruebas coincidentes, patrones de implementación, comandos de validación, conflictos, evidencia de fuente y estimaciones de tokens.

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

Use esto antes de entregar trabajo a un agente de codificación. Es determinista y local-primero: se basa en índices de repositorio, mapas de código, relaciones de importación, pruebas y comandos de arnés en lugar de un modelo externo.

obsidian <repo>

Exporta un vault de Markdown compatible con Obsidian desde el mapa del repositorio. El vault incluye una nota de inicio navegable, archivos y puntos de entrada del repositorio, un índice de evidencia y notas opcionales de contexto de tarea e impacto.

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

El directorio de salida predeterminado es .otito/obsidian. El vault es una proyección legible de la evidencia de Otito; no reemplaza las puertas exactas de árbol por etapas, CI alojado, CODEOWNERS o revisión humana.

harness <path>

Genera un arnés de repositorio con comandos de configuración, scripts de validación, scripts de ejecución, comandos de contexto, áreas de enfoque y uso estimado de tokens de contexto.

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

Use esto como el primer artefacto que un agente o flujo de trabajo de CI lea antes de tocar código.

init <path>

Andamia otito en otro repositorio.

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

Archivos generados:

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

El flujo de trabajo generado se ejecuta en solicitudes de extracción y envíos de confirmación. Las ejecuciones de solicitudes de extracción generan el informe, suben un artefacto y crean o actualizan un comentario fijo de PR. Las ejecuciones de envío generan y suben el artefacto del informe sin comentar.

structure <path>

Ejecuta code-structure contra archivos TypeScript.

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

Si code-structure falta, el comando devuelve una sugerencia de instalación en lugar de fallar misteriosamente. Si no está instalado globalmente pero npx está disponible, otito puede ejecutarlo a través de npx --yes code-structure.

deps <package>

Usa opensrc path <package> para resolver la fuente de dependencias y opcionalmente buscarla.

otito deps zod --query parse --limit 20

report <path>

Genera un informe de desarrollador compartible.

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

La salida predeterminada está formateada para lectura en terminal y termina con el uso estimado de tokens. Use --out para el artefacto Markdown o --json para datos estructurados.

workspace <repo...>

Genera un informe a nivel de producto en repositorios relacionados.

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

pr <path>

Genera un paquete de contexto de revisión de PR a partir de metadatos de diff git local, clasificación de mapa de código, objetivos de revisión, indicaciones de revisión dirigidas, banderas de riesgo, comandos de verificación sugeridos, tokens estimados y comentarios opcionales de PR de GitHub.

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

Banderas útiles:

• --base <ref>: comparar desde una ref base específica. El valor predeterminado es la base de PR, upstream, origin/main o main.
• --head <ref>: comparar con una ref head específica. El valor predeterminado es HEAD.
• --number <n>: enriquecer con metadatos de gh pr view y comentarios de revisión.
• --github: pedir a gh que infiera el PR desde la rama actual.
• --comment: crear o actualizar un comentario fijo de PR de GitHub usando gh.

GitHub Actions

Este repositorio incluye .github/workflows/otito-ci.yml. El flujo de trabajo instala dependencias, ejecuta npm run ci y luego genera contexto de revisión de PR o envío como un artefacto subido. Use otito init /path/to/target-repo para andamiar un flujo de trabajo de revisión de Otito en otro repositorio.

mcp

Inicia un servidor MCP stdio que expone otito como herramientas llamables por agentes. Las búsquedas de mapa de repositorio MCP usan un caché externo por usuario con una huella digital de archivo, se actualizan cuando los archivos cambian y nunca escriben en el repositorio inspeccionado.

El servidor está publicado en el Registro MCP como io.github.BASHBOP/otito.

otito mcp

Al conectarlo a un host MCP (Claude Desktop, Claude Code, Codex CLI, Cursor, etc.):

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

Si prefiere un binario instalado globalmente:

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

Ollama puede proporcionar el modelo local, pero no llama a herramientas MCP por sí mismo. Para usar otito a través de MCP con un modelo local, use un cliente de agente compatible con MCP que admita Ollama como proveedor de modelos y configure el servidor otito anterior.

Òtítọ́ expone 13 herramientas MCP para inspección de repositorios, contexto, impacto, revisión y evidencia de fusión.

Herramienta	Propósito
repo_inspect	Inspeccionar forma del repositorio, scripts, administradores de paquetes, puntos de entrada y estado de git
repo_map	Mapa de código JSON compacto, filtrable por domain, kind y route
repo_index	Generar índices externos + entradas de catálogo; dryRun:true descubre solo lectura
repo_search	Buscar el catálogo; omita query para devolver el listado del catálogo
context_pack	Construir un paquete de contexto consciente de tareas
change_impact	Clasificar archivos con mayor probabilidad de ser dueños de una solicitud de cambio en inglés simple
agent_experience	Puntuar experiencia de agente (AX 0–100): capacidad de cambio, contención, salvaguardas, claridad
convergence_score	Puntuar intención vs. ejecución (0–100) con un recibo exacto de asunto de cambio
review_context	Contexto de revisión de diff/comentarios (sin veredicto)
review_gate	Puerta de fusión PASS/WARN/FAIL: local sin pr, puerta de PR de GitHub con pr
review_verdict	Veredicto compuesto: impacto + contexto_de_revisión + puerta_de_revisión
workspace_report	Informe a nivel de producto en múltiples repositorios
repo_harness	Comandos de configuración, validación, ejecución y contexto para un arnés de agente o CI

matrix

Imprime la matriz de evaluación de herramientas para Greploop, code-structure, opensrc, Daytona y Harnss.

agent-tools

Imprime metadatos JSON o Markdown derivados del catálogo canónico de herramientas MCP, manteniendo alineadas las integraciones CLI y MCP.

Estrategia

Envuelva primero. Mida el dolor. Construya solo las piezas faltantes.

Esto mantiene el proyecto útil rápidamente mientras deja espacio para reemplazar adaptadores débiles con implementaciones propias más adelante.

---

Parte de la cadena de herramientas

otito es una de cuatro herramientas que forman una capa de confianza determinista para el desarrollo asistido por IA. Cada una usa análisis estático para responder una pregunta que la gente sigue entregando a un LLM.

• otito (esta herramienta), para contexto: ¿qué toca realmente este cambio?
• tieline, para contratos: ¿el front end y el back end dejaron de estar de acuerdo silenciosamente?
• bouncer, para cumplimiento: ¿podría defender esto ante Ofcom?
• aiglare, para gobernanza: ¿dónde puede el modelo hacer algo que no pueda deshacer?

Más en segunolumbe.com. análisis estático, nunca el modelo.