{
  "markdown": "# Òtítọ́\n\n**Models generate the change. Otito proves whether it is safe to merge.**\n\n[![CI](https://img.shields.io/github/actions/workflow/status/BASHBOP/otito/otito-ci.yml?style=flat-square&label=CI)](https://github.com/BASHBOP/otito/actions/workflows/otito-ci.yml) [![npm](https://img.shields.io/npm/v/@bashbop/otito?style=flat-square)](https://www.npmjs.com/package/@bashbop/otito) [![license: MIT](https://img.shields.io/badge/license-MIT-blue?style=flat-square)](LICENSE) [![node](https://img.shields.io/badge/node-%E2%89%A518.18-339933?style=flat-square)](https://nodejs.org/) [![Listed on mcpservers.org](https://mcpservers.org/badge.svg)](https://mcpservers.org/servers/bashbop/otito)\n\n![otito demo](otito-demo.gif)\n\n![otito](assets/otito-design-print.svg)\n\n```text\n  ___ _____ ___ _____ ___\n / _ \\_   _|_ _|_   _/ _ \\\n| | | || |  | |  | || | | |\n| |_| || |  | |  | || |_| |\n \\___/ |_| |___| |_| \\___/\n```\n\nThe generic agent loop (prompting, retries, tool routing, file editing) is becoming infrastructure. Frontier models already plan, search repositories, use tools, and recover from mistakes. Model vendors are packaging native harnesses with file tools and sandbox execution. Competing there is a losing bet.\n\nWhat remains strategically important is the **trust harness**: accurate repository context, permission and sandbox boundaries, exact validation against the changed code, risk-sensitive policies, CODEOWNERS and human approval, reproducible receipts, and independent evidence the model cannot award itself. Stronger models increase that need, because teams will let them change more code with less supervision.\n\n**Òtítọ́** is that independent trust layer. It is local-first, deterministic, and model-agnostic: it discovers repositories, builds local indexes, generates task-aware context before an agent edits, scores how much a change actually touches, and gates merge readiness. It works the same way every time, with no server, no account, and no code leaving the machine. It does not compete with Codex, Claude Code, Gemini, Cursor, or future native harnesses. It integrates with them, and keeps working as models change underneath it.\n\n## Trusted agent workflow\n\n> **New in v1.9.2:** otito is now listed on [mcpservers.org](https://mcpservers.org/servers/bashbop/otito).\n\n```text\nRequest -> context -> scoped change -> exact validation -> review evidence -> human decision\n```\n\nOtito helps the agent understand and bound a task before editing, then gives the maintainer evidence to decide whether to trust the result. A passing local gate is never an automatic merge approval: hosted CI, GitHub review, CODEOWNERS, and the human release decision remain separate authorities.\n\nIt does not try to replace native agent harnesses, `opensrc`, `code-structure`, Daytona, or Harnss. It gives developers and coding agents a single CLI that can:\n\nDeterministic merge gates are the differentiated core. This is the human-in-the-loop checkpoint that a model cannot grade for itself:\n\n- score merge readiness for local changes and pull requests with one `review_gate` tool (`gate` on the CLI)\n- execute a protected validation plan against the exact staged tree and retain a bounded receipt of its outcomes\n- bind staged web, API, and shared-contract changes into one workspace receipt\n- resolve CODEOWNERS to required reviewers and surface owner-decision warnings\n- check branch-protection expectations and required checks before merge\n- generate actionable PR review context from git diffs and optional GitHub comments\n- continuously prove the local gate against a committed valid control and adversarial change corpus with `otito eval --gate-effectiveness`\n\nLocal-first context feeds the gates:\n\n- inspect a repository\n- discover and index local repositories\n- maintain a local catalog and search across it\n- generate task-aware context packets before an agent plans or edits\n- generate AST-backed JSON-first code maps for agents\n- generate a setup/validation/runtime harness for a repo\n- produce Markdown or JSON reports\n- estimate context-token size for generated artifacts\n- run an MCP server for agent hosts with a persisted per-user index cache that never dirties an inspected repository\n- expose simple agent-friendly tool metadata\n- check tool availability\n- generate TypeScript structure HTML through `code-structure`\n- search dependency source through `opensrc`\n\n## Documentation\n\nThe published MkDocs site is a practical discovery and delivery guide:\n\n- [Home](docs/index.md)\n- [Executive Summary](docs/EXECUTIVE-SUMMARY.md)\n- [Context Foundation](docs/01-context-foundation/README.md)\n- [MCP and Agent Workflows](docs/02-mcp-agent-workflows/README.md)\n- [Contributor Governance](docs/03-contributor-governance/README.md)\n- [Release Readiness](docs/04-release-readiness/README.md)\n- [Trust-Layer Demo](docs/05-trust-layer-demo/README.md)\n- [Builder-Founder Operating Loop](docs/06-builder-founder-operating-loop/README.md)\n- [Harness Thesis & Agent Experience](docs/07-harness-thesis/README.md)\n- [Tutorials Integration (Codespaces)](docs/08-tutorials-integration/README.md)\n- [Convergence Thesis & Score](docs/09-convergence-thesis/README.md)\n- [Usage & Performance Dashboard](docs/10-usage-dashboard/README.md)\n- [Determinism Thesis & Harness Boundary](docs/11-determinism-thesis/README.md)\n- [Dual-Mode Thesis & Complementary Stack](docs/12-dual-mode-thesis/README.md)\n- [Prompt Determinism Thesis & Settings Trap](docs/13-prompt-determinism-thesis/README.md)\n- [Trust Harness Thesis & Commodity Loop](docs/14-trust-harness-thesis/README.md)\n- [Herdr Integration](docs/15-herdr-integration/README.md)\n- [Clean Code Thesis & the Smallest Owner File](docs/16-clean-code-thesis/README.md)\n- [Evaluation Method and Gate-Effectiveness Corpus](docs/EVALS.md)\n- [Glossary](docs/GLOSSARY.md)\n\nRead it at:\n\n```text\nhttps://bashbop.github.io/otito/\n```\n\n## Quick Start\n\nCode maps use the TypeScript compiler for JS/TS and dedicated language extractors for Go, C#, Python, Java, Ruby, and Rust (see `src/lib/code-map/ast-languages.js`). Optional external tools are only needed for dependency-source lookup and HTML structure reports.\n\nInstall the published package from npm:\n\n```bash\nnpm install -g @bashbop/otito\notito doctor\notito index ~/projects --discover\notito context \"add a new MCP tool\" --path .\n```\n\nYou can also run a command without a global install:\n\n```bash\nnpx -y @bashbop/otito doctor\n```\n\nFor source development:\n\n```bash\ngit clone https://github.com/BASHBOP/otito.git\ncd otito\nnpm ci\nnpm run ci\nnode src/cli.js doctor\n```\n\nThe current release is available through [npm](https://www.npmjs.com/package/@bashbop/otito), [GitHub Releases](https://github.com/BASHBOP/otito/releases), and the MCP Registry as `io.github.BASHBOP/otito`.\n\nRun Otito as the trust layer inside a Herdr agent workspace:\n\n```bash\nherdr plugin install BASHBOP/otito/integrations/herdr\nherdr plugin pane open --plugin bashbop.otito --entrypoint trust-status\n```\n\nThe Herdr plugin uses the independently installed `otito` CLI. Herdr owns persistent agent terminals and worktrees; Otito owns context, impact, review, and deterministic gate evidence.\n\n```bash\notito repo . --json\notito discover ~/projects --depth 2 --json\notito index ~/projects --discover\notito catalog\notito search \"events controller\"\notito context \"add a new MCP tool\" --path .\notito impact . \"add a new MCP tool\" --top 12\notito ax . \"add a new MCP tool\"\notito map . --json\notito harness . --out .otito/harness.md\notito pr . --base origin/main --out .otito/pr-review.md\notito review . --request \"add a new MCP tool\" --base origin/main\notito gate . --staged --base origin/main\notito gate . --staged --run-validation\notito mcp\notito report . --out .otito/report.md\notito workspace /path/to/web /path/to/api --out .otito/workspace.md\notito workspace-gate /path/to/web /path/to/api --request \"ship the product change\" --out .otito/workspace-gate.md\n```\n\nOptional external tools:\n\n```bash\nnpm install -g opensrc code-structure\n```\n\nThen:\n\n```bash\notito deps zod --query parse\notito structure . --out .otito/structure.html\n```\n\n## Usage Examples\n\n| Goal | Command | Output |\n| --- | --- | --- |\n| Inspect one repo | `otito repo . --json` | Repo facts, scripts, languages, entrypoints, and git state |\n| Build a code map | `otito map . --json` | Source files, domains, imports, exports, symbols, and routes |\n| Prepare task context | `otito context \"add a new MCP tool\" --path .` | Primary files, related files, tests, patterns, and validation commands |\n| Generate an agent harness | `otito harness . --out .otito/harness.md` | Setup, validation, runtime, and context commands |\n| Gate an exact staged change | `otito gate . --staged --run-validation` | Versioned validation outcomes bound to the staged Git tree |\n| Gate a product change | `otito workspace-gate ../web ../api --request \"ship change\"` | One receipt across staged repositories |\n| Review local changes | `otito pr . --base origin/main --out .otito/pr-review.md` | Changed files, risk prompts, review targets, and test hints |\n| Index local projects | `otito index ~/projects --discover` | External per-user indexes plus a local catalog |\n| Search indexed repos | `otito search \"events controller\"` | Ranked matches across paths, domains, routes, imports, exports, and symbols |\n| Run the MCP server | `otito mcp` | Stdio MCP server exposing otito tools |\n| Track usage & performance | `otito dashboard` | Self-contained HTML from an opt-in local usage log (off by default) |\n| Help improve Otito | `otito telemetry share on` | Separately opt into a minimal anonymous usage event; no prompts, paths, repo data, or source content |\n\nFor Codex, Claude Desktop, VS Code, Cursor, Gemini CLI, Kimi Code, Grok handoff guidance, and generic stdio client snippets, see [MCP and Agent Workflows](docs/02-mcp-agent-workflows/README.md).\n\n## otito vs alternatives\n\n| Approach | Strengths | Where otito differs |\n| --- | --- | --- |\n| Sourcegraph / Cody context | Powerful hosted code search and embedding-based context across an org | otito is local-first and deterministic: no server, no account, no code leaves the machine, and the same query always yields the same packet |\n| Hand-written `CLAUDE.md` / rules files | Curated, intent-rich guidance | Hand-written context goes stale; otito regenerates context from the actual code (symbols, imports, routes, tests) on every run and complements a short `CLAUDE.md` |\n| `grep` / `ripgrep` | Fast, universal text matching | otito ranks whole files by task intent across paths, symbols, exports, and tests, then adds patterns and validation commands. The result is a context packet, not a list of matching lines |\n\n## Quality Gates\n\nUse the full gate before opening a pull request or publishing a release:\n\n```bash\nnpm run ci\n```\n\nThe gate runs:\n\n- `npm run format:check`\n- `npm run lint`\n- `npm run typecheck`\n- `npm run version:check`\n- `npm test`\n- `npm run test:coverage`\n- `npm run eval:accuracy`\n- `npm run eval:harness`\n- `npm run eval:gate`\n- `npm run audit`\n- `npm run smoke`\n\nCoverage currently gates source files at 70% lines, 60% branches, and 75% functions. Generated artifacts under `.otito/` are ignored by git, linting, and formatting; keep durable reports there instead of committing them.\n\nThe harness execution evaluation runs only vetted install, test, typecheck, and build commands against committed fixtures. It disables install lifecycle scripts, applies timeouts, and never executes inferred commands from a customer repository.\n\nThe gate-effectiveness evaluation creates isolated Git repositories from a committed base, applies reviewed change directories or patches, and invokes the real staged local gate. Its baseline proves one valid change is allowed and six known-bad changes are blocked for their encoded reasons. It cannot execute corpus-supplied commands or inspect a customer repository.\n\n### Performance checks\n\nRun the CLI benchmark when changing startup, repository scanning, or code-map behavior:\n\n```bash\nnpm run benchmark:cli -- --iterations 5\nnpm run benchmark:cli -- --iterations 5 --json\n```\n\nIt measures the lightweight `version` and `help` paths plus a full `context` run. Timings include Node startup and command execution. Compare results on the same machine and checkout; the benchmark reports measurements but does not enforce machine-dependent thresholds in CI.\n\notito follows Semantic Versioning. Pull requests should identify whether they are no-version-impact, patch, minor, or major changes; maintainers apply the final package version during release.\n\nFor longer trust-layer work, use the [Builder-Founder Operating Loop](docs/06-builder-founder-operating-loop/README.md) to keep every session tied to context, focused changes, visible gates, human decisions, and durable evidence.\n\n## Contributing\n\nContributions are welcome. Start with [CONTRIBUTING.md](CONTRIBUTING.md), follow the [Code of Conduct](CODE_OF_CONDUCT.md), and read [Contributor Governance](docs/03-contributor-governance/README.md) for review and merge rules.\n\nOpen an issue or draft PR for substantial changes, and run `npm run ci` before requesting review. All code changes must be reviewed by a maintainer/code owner before merge. The protected `main` branch requires maintainer approval, passing quality gates, and resolved PR conversations.\n\n## Common Workflows\n\nAgent repo harness:\n\n```bash\notito harness . --out .otito/harness.md\notito map . --json\n```\n\nLocal discovery, indexing, catalog, and search:\n\n```bash\notito discover ~/projects --depth 2\notito index ~/projects --discover\notito catalog\notito search \"submit rsvp\"\n```\n\nTask-aware agent context:\n\n```bash\notito context \"add a new MCP tool\" --path . --json\notito context \"add a new MCP tool\" --path . --out .otito/context-pack.md\n```\n\nPR review harness:\n\n```bash\notito pr . --base origin/main --out .otito/pr-review.md\notito pr . --number 123 --comment\n```\n\nMerge gate (`gate` is the canonical v2 command; `pass` / `pass-pr` remain as legacy aliases):\n\n```bash\notito gate . --base origin/main          # local gate (no GitHub)\notito gate . --staged --base origin/main # staged-path evidence, suitable for pre-commit hooks\notito gate . --staged --run-validation   # run the base-committed validation plan against the exact staged tree\notito gate . --base origin/main --request \"update the greeting\" --min-convergence 80\notito converge \"update the greeting\" --path . --base HEAD --staged --json # exact change-subject receipt\notito gate --pr 123 --path .             # GitHub PR gate via gh\n```\n\nIn staged mode, changed-path, risk, secret and convergence evidence use the exact Git index tree. Exact-subject source analysis streams raw Git blobs and fails closed above 5,000 source files or 64 MiB. `--run-validation` additionally executes only a versioned plan from `otito.gate.json` in the selected base commit against an isolated copy of that staged tree. It records commands, exit outcomes and output hashes in a separate validation receipt; it never records raw output. Supported package-manager script forms include direct and `run` invocations for npm, pnpm, Yarn, Bun, and Corepack-wrapped commands. Their selected-base script identity is pinned, so a staged manifest cannot replace them with a no-op. Other base-committed commands remain valid policy commands; adding a new package-manager script form requires the same pinning semantics and regression coverage. Validation starts with a scrubbed environment and isolated home; only explicitly allowlisted variables pass through. The source snapshot is exact, while a linked local `node_modules` directory is explicitly reported as **not attested** in this first increment. Release and optional analyzer checks still inspect the working tree and remain outside that receipt.\n\nCreate the policy in the protected base branch before asking the gate to execute it:\n\n```json\n{\n  \"version\": 1,\n  \"validation\": {\n    \"environment\": { \"allow\": [\"TEST_DATABASE_URL\"] },\n    \"commands\": [{ \"id\": \"unit\", \"command\": \"npm test\", \"timeoutSeconds\": 300 }]\n  }\n}\n```\n\n`environment.allow` is optional. Use it only for the specific variables a protected validation plan requires; values are never recorded in the receipt.\n\nMulti-repo product context:\n\n```bash\notito workspace ../web ../api --out .otito/workspace.md\notito workspace-gate ../web ../api --base origin/main --request \"ship Audience Studio preview\" --out .otito/workspace-gate.md\n```\n\n`workspace-gate` creates one parent receipt across two or more staged repositories. It binds each repository's exact base, parent and staged-tree identity, changed-file scope, local-gate checks, and any validation receipt. All repositories must have a staged subject before the parent receipt is issued.\n\nGitHub Actions bootstrap:\n\n```bash\notito init /path/to/target-repo\n```\n\nLocal Ollama review:\n\n```bash\notito harness . --out .otito/harness.md\n\n{\n  echo \"Use this repo harness to explain the project and suggest the next best engineering task.\"\n  echo\n  cat .otito/harness.md\n} | ollama run qwen3:8b --think false --hidethinking --nowordwrap\n```\n\nLocal Ollama PR review:\n\n```bash\notito pr . --base origin/main --out .otito/pr-review.md\n\n{\n  echo \"Review this PR context. Focus on bugs, missing tests, and risky changes.\"\n  echo\n  cat .otito/pr-review.md\n} | ollama run qwen3:8b --think false --hidethinking --nowordwrap\n```\n\n## Commands\n\n### `doctor`\n\nChecks the local runtime and optional external tools.\n\n```bash\notito doctor --json\n```\n\n### `install` / `i`\n\nPrints install commands and current binary status. From a local checkout, `--global` runs `npm install -g .`; `--link` runs `npm link`.\n\n```bash\notito install\notito i\notito install --global\notito install --json\n```\n\nAfter installation, use `otito` as the command.\n\n### `repo <path>`\n\nInspects repo shape: files, package metadata, languages, package managers, scripts, likely entrypoints, git metadata, and ignored-heavy directories.\n\n```bash\notito repo . --json\n```\n\nGit repositories are scanned through `git ls-files --cached --others --exclude-standard` so ignored files do not pollute harness context. Plain directories fall back to the built-in walker.\n\n### `discover <root...>`\n\nDiscovers repository roots under one or more local directories without indexing them.\n\n```bash\notito discover ~/projects --depth 2\notito discover . --json\n```\n\nDiscovery stops at directories with common repo markers such as `package.json`, `.git`, `pyproject.toml`, `go.mod`, `Cargo.toml`, and `Package.swift`.\n\n### `index <repo...>`\n\nGenerates per-user external indexes and adds repositories to the local catalog. The inspected repositories are not modified.\n\n```bash\notito index .\notito index ~/projects --discover\notito index . --catalog /tmp/otito-catalog.json --json\n```\n\nThe default catalog path is `~/.otito/catalog.json`. Set `OTITO_CATALOG` or pass `--catalog` to use a different file.\n\n### `catalog`\n\nLists repositories currently indexed in the local catalog.\n\n```bash\notito catalog\notito catalog --json\n```\n\n### `search <query>`\n\nSearches indexed local repositories by path, domain, kind, route, controller path, imports, exports, and symbols.\n\n```bash\notito search \"events controller\"\notito search \"submit rsvp\" --limit 10\notito search \"api client\" --offline --json\n```\n\nBy default, search refreshes repo indexes when fingerprints change. Use `--offline` to read only the stored external indexes.\n\n### `context <query>`\n\nGenerates a local context-engine packet for a task. The packet includes inferred intent, primary files, related files, matching tests, implementation patterns, validation commands, conflicts, source evidence, and token estimates.\n\n```bash\notito context \"add a new MCP tool\" --path . --json\notito context \"add a new CLI command\" --path . --out .otito/context-pack.md\n```\n\nUse this before handing work to a coding agent. It is deterministic and local-first: it relies on repo indexes, code maps, import relationships, tests, and harness commands rather than an external model.\n\n### `obsidian <repo>`\n\nExports an Obsidian-compatible Markdown vault from the repository map. The vault includes a navigable home note, repository files and entrypoints, an evidence index, and optional task-specific context and impact notes.\n\n```bash\notito obsidian . --query \"add a new MCP tool\" --out .otito/obsidian\n```\n\nThe default output directory is `.otito/obsidian`. The vault is a readable projection of Otito evidence; it does not replace exact staged-tree gates, hosted CI, CODEOWNERS, or human review.\n\n### `harness <path>`\n\nGenerates a repo harness with setup commands, validation scripts, runtime scripts, context commands, focus areas, and estimated context-token usage.\n\n```bash\notito harness . --out .otito/harness.md\notito harness . --json\n```\n\nUse this as the first artifact an agent or CI workflow reads before touching code.\n\n### `init <path>`\n\nScaffolds otito into another repository.\n\n```bash\notito init /path/to/target-repo\notito init /path/to/target-repo --force\notito init /path/to/target-repo --no-workflow\notito init /path/to/target-repo --tool-repo BASHBOP/otito --tool-ref main\n```\n\nGenerated files:\n\n- `.otito/README.md`\n- `.github/workflows/otito-ci.yml`\n\nThe generated workflow runs on pull requests and commit pushes. Pull request runs generate the report, upload an artifact, and create or update a sticky PR comment. Push runs generate and upload the report artifact without commenting.\n\n### `structure <path>`\n\nRuns `code-structure` against TypeScript files.\n\n```bash\notito structure . --pattern \"app/**/*.tsx\" --out .otito/structure.html\n```\n\nIf `code-structure` is missing, the command returns an install hint instead of failing mysteriously. If it is not installed globally but `npx` is available, otito can run it through `npx --yes code-structure`.\n\n### `deps <package>`\n\nUses `opensrc path <package>` to resolve dependency source and optionally search it.\n\n```bash\notito deps zod --query parse --limit 20\n```\n\n### `report <path>`\n\nGenerates a shareable developer report.\n\n```bash\notito report .\notito report . --out .otito/report.md\notito report . --json\n```\n\nThe default output is formatted for terminal reading and ends with estimated token usage. Use `--out` for the Markdown artifact or `--json` for structured data.\n\n### `workspace <repo...>`\n\nGenerates one product-level report across related repos.\n\n```bash\notito workspace /path/to/web /path/to/api --out .otito/workspace.md\notito workspace /path/to/web /path/to/api --json\n```\n\n### `pr <path>`\n\nGenerates a PR review context pack from local git diff metadata, code-map classification, review targets, targeted review prompts, risk flags, suggested verification commands, estimated tokens, and optional GitHub PR comments.\n\n```bash\notito pr . --base origin/main --out .otito/pr-review.md\notito pr . --number 123 --comment\n```\n\nUseful flags:\n\n- `--base <ref>`: compare from a specific base ref. Defaults to PR base, upstream, `origin/main`, or `main`.\n- `--head <ref>`: compare to a specific head ref. Defaults to `HEAD`.\n- `--number <n>`: enrich with `gh pr view` metadata and review comments.\n- `--github`: ask `gh` to infer the PR from the current branch.\n- `--comment`: create or update a sticky GitHub PR comment using `gh`.\n\n### GitHub Actions\n\nThis repo includes `.github/workflows/otito-ci.yml`. The workflow installs dependencies, runs `npm run ci`, then generates PR or push review context as an uploaded artifact. Use `otito init /path/to/target-repo` to scaffold an Otito review workflow into another repository.\n\n### `mcp`\n\nStarts a stdio MCP server exposing otito as agent-callable tools. MCP repo-map lookups use an external per-user cache with a file fingerprint, refresh when files change, and never write into the inspected repository.\n\nThe server is published in the MCP Registry as `io.github.BASHBOP/otito`.\n\n```bash\notito mcp\n```\n\nWhen wiring it into an MCP host (Claude Desktop, Claude Code, Codex CLI, Cursor, etc.):\n\n```json\n{\n  \"mcpServers\": {\n    \"otito\": {\n      \"command\": \"npx\",\n      \"args\": [\"-y\", \"@bashbop/otito\", \"mcp\"]\n    }\n  }\n}\n```\n\nIf you prefer a globally installed binary:\n\n```json\n{\n  \"mcpServers\": {\n    \"otito\": {\n      \"command\": \"otito\",\n      \"args\": [\"mcp\"]\n    }\n  }\n}\n```\n\nOllama can provide the local model, but it does not call MCP tools by itself. To use otito through MCP with a local model, use an MCP-capable agent client that supports Ollama as the model provider and configure the `otito` server above.\n\nÒtítọ́ exposes **13** MCP tools for repository inspection, context, impact, review, and merge evidence.\n\n| Tool                | Purpose                                                                            |\n| ------------------- | ---------------------------------------------------------------------------------- |\n| `repo_inspect`      | Inspect repository shape, scripts, package managers, entrypoints, and git state    |\n| `repo_map`          | Compact JSON code map, filterable by `domain`, `kind`, and `route`                 |\n| `repo_index`        | Generate external indexes + catalog entries; `dryRun:true` discovers read-only     |\n| `repo_search`       | Search the catalog; omit `query` to return the catalog listing                     |\n| `context_pack`      | Build a task-aware context packet                                                  |\n| `change_impact`     | Rank files most likely to own a plain-English change request                       |\n| `agent_experience`  | Score Agent Experience (AX 0–100): changeability, containment, guardrails, clarity |\n| `convergence_score` | Score intent vs. execution (0–100) with an exact change-subject receipt            |\n| `review_context`    | Diff/comment review context (no verdict)                                           |\n| `review_gate`       | PASS/WARN/FAIL merge gate: local without `pr`, GitHub PR gate with `pr`            |\n| `review_verdict`    | Composite verdict: impact + review_context + review_gate                           |\n| `workspace_report`  | Product-level report across multiple repos                                         |\n| `repo_harness`      | Setup, validation, runtime, and context commands for an agent or CI harness        |\n\n### `matrix`\n\nPrints the tool evaluation matrix for Greploop, `code-structure`, `opensrc`, Daytona, and Harnss.\n\n### `agent-tools`\n\nPrints JSON or Markdown metadata derived from the canonical MCP tool catalog, keeping CLI and MCP integrations aligned.\n\n## Strategy\n\nWrap first. Measure pain. Build only the missing pieces.\n\nThis keeps the project useful quickly while leaving room to replace weak adapters with owned implementations later.\n\n---\n\n## Part of the toolchain\n\n**otito** is one of four tools that form a deterministic trust layer for AI-assisted development. Each uses static analysis to answer a question people keep handing to an LLM.\n\n- **otito** (this tool), for context: what does this change actually touch?\n- [tieline](https://www.npmjs.com/package/@bashbop/tieline), for contracts: did the front end and back end quietly stop agreeing?\n- [bouncer](https://www.npmjs.com/package/@bashbop/bouncer), for compliance: could you defend this to Ofcom?\n- [aiglare](https://www.npmjs.com/package/@bashbop/aiglare), for governance: where can the model do something you can't undo?\n\nMore at [segunolumbe.com](https://segunolumbe.com). _static analysis, never the model._\n",
  "bytes": 27380,
  "sha": "e01907e3a5079f7451d7844494826a2ba2c90699f8e2c68a90dfef0ca0d67908",
  "repo_slug": "bashbop/otito",
  "fonte": "repo",
  "truncated": false,
  "api": "https://agentalog.com/api/listings/mcp_io_github_bashbop_otito_3f0d2c45/readme"
}