roam-code

repository·main·Indexed 19 days ago

https://github.com/cranot/roam-code

A local codebase intelligence layer for AI coding agents providing structural repo maps, change-safety gates, and MCP security receipts. It focuses on local analysis with zero API keys and no source-code egress to ensure code changes are safe and mergeable. Features include a composite Agent Quality Score (AQS) for evaluation, a plugin system for extending framework profiles and language extractors, and tools like `roam health` and `roam preflight` for risk and blast radius analysis.

Tokens
93.4K
Snippets
242
Records
396
Agent score
67%

What's inside roam-code

  1. What is roam-code?

    main

    roam-code is a local codebase intelligence layer designed for AI coding agents. It provides local graph facts (symbols, calls, imports, git history, etc.) to help agents understand the impact of changes before they occur.

    Key Characteristics

    • Credential-free: No accounts, API keys, or cloud logins required.
    • Local-first: Source parsing, indexing, and evidence generation stay on your machine. It does not upload source code or telemetry automatically.
    • Tamper-evident ChangeEvidence: Generates signed, HMAC-chained packets that document who acted, what context was read, what changed, and what was verified.
    • Dependency-aware: Uses a SQLite-backed graph of symbols across 28 languages rather than simple string matching (like grep).
    • MCP Security: Every MCP response is scrubbed for secrets and gated against the active mode (read_only, safe_edit, migration, or autonomous_pr).
  2. Overview of roam commands

    main

    Roam v13.10.0 provides 284 commands (including 277 canonical commands and aliases) organized into 7 functional categories. Many of these commands are available as MCP (Model Context Protocol) tools, allowing AI agents to interact with the codebase.

    Commands are categorized as follows:

    • Getting Started: Initial setup, configuration, and onboarding.
    • Daily Workflow: Tools for active development, PR analysis, and agent planning.
    • Codebase Health: Metrics for complexity, debt, and code quality.
    • Architecture: Analysis of structural patterns, coupling, and graph relationships.
    • Exploration: Searching, tracing, and navigating the codebase.
    • Reports & CI: Automated checks for drift, security, and compliance.
    • Refactoring: Tools for cleaning up code, managing imports, and planning changes.
  3. Use example workflow templates for day-to-day Roam usage

    main

    Roam provides small operational templates designed to shape day-to-day usage in repositories, issues, PR descriptions, or team runbooks. These are lighter alternatives to full audit or service reports and are intended to be copied directly into your workflow.

    Available Templates

    FileUse Case
    agent-change-packet.mdUse as an Issue or PR template for AI-assisted code changes. It forces agents to collect Roam context, preflight evidence, blast radius, tests, and post-edit proof before requesting review.
    pre-commit-stale-refs.yamlA local pre-commit hook to gate broken markdown links, HTML hrefs, backtick paths, and anchors.
    post-merge-stale-refs.shA Git hook for refreshing stale-reference baselines after a merge.
    .roam-rules.ymlExample architecture rules for roam pr-analyze (e.g., banning specific imports, calls, base classes, or decorators).
    smells.suppress.ymlAn allowlist for roam smells findings (W658).
    .roamignore-findingsA rule-based allowlist for roam math, over-fetch, missing-index, or auth-gaps findings (W706).
    suppressions.jsonA per-finding-hash allowlist for roam suppress (W691).
    .roam-suppressions.ymlA triage allowlist for roam triage (W692).
  4. Understand the four caller metrics in roam-code

    main

    roam-code provides different ways to count how many callers a symbol has. Because each command answers a different question (e.g., counting every textual occurrence vs. counting unique upstream symbols), the numbers will vary.

    Crucial for Consumers: When processing JSON output from roam commands, always check the caller_metric_definition string before comparing counts. This label identifies which of the four metrics was used.

    The Four Metrics

    MetricDefinitionBest Use Case
    raw_edge_rowsEvery row in edges where target_id is the symbol. Preserves per-file multiplicity and counts each edge kind separately.Use when you need to know the total number of textual or structural call sites (e.g., "How many times is this function mentioned?"). This is usually the largest number.
    direct_in_degreeDistinct upstream symbols (one row per unique source). Uses the precomputed graph_metrics.in_degree column.Use for graph-theoretic in-degree (e.g., "How many unique symbols call this?"). This is the standard metric for roam fan and roam symbol.
    distinct_caller_tuplesDistinct (source_symbol, scope) tuples after filtering out test files and deduping by (qualified_name, path, edge_kind).Use when you want the "production-only" headline number (e.g., what roam uses reports).
    transitive_upstream_bfsA multi-hop Breadth-First Search over edges.kind IN ('call','reference'). Counts every symbol that can reach the target within N hops.Use for assessing blast radius or ranking root-cause suspects in roam diagnose. This can be larger than direct counts because it includes indirect dependencies.

    Granularity (Finest to Coarsest): raw_edge_rows > distinct_caller_tuples > direct_in_degree > transitive_upstream_bfs.

  5. Inspect agent context and analysis via PR bundles

    main

    To understand what context an agent read before making code changes (answering "did the agent look before it leapt?"), inspect the JSON files located in .roam/pr-bundles/<run_id>.json.

    Key fields to examine:

    • context_read.commands_run: Analysis commands executed (e.g., roam preflight, roam impact, roam describe).
    • context_read.symbols_inspected: Symbols the agent analyzed.
    • context_read.files_inspected: Files the agent inspected.

    You can use jq or python -m json.tool to inspect these files.

    {
      "intent": "Add idempotency key to /charge endpoint",
      "context_read": {
        "commands_run": [
          "roam preflight charge_handler",
          "roam impact charge_handler",
          "roam describe payment_gateway"
        ],
        "symbols_inspected": ["charge_handler", "PaymentGateway.charge", "IdempotencyStore"],
        "files_inspected": ["src/api/charge.py", "src/payments/gateway.py"]
      },
      "affected_symbols": [
        {"name": "charge_handler", "file": "src/api/charge.py", "blast_radius": 11}
      ]
    }
  6. Understand the roam-code security model and tier responsibilities

    main

    roam-code operates as a Server tier in the MCP runtime-security stack. It does not act as a Gateway (which handles cross-server policy and audit aggregation) or a Host (which handles human-in-the-loop approval). Instead, roam-code provides the authoritative evidence and coarse-grained controls that Gateways (like Interlock, Lasso, or Portkey) consume to enforce security.

    The four tiers of MCP security:

    1. Spec: Owns identity, scope-consent, and the _meta envelope.
    2. Host: Owns interactive human approval (e.g., Claude Desktop).
    3. Server (roam-code): Owns coarse read-only/write flags, the 4-mode policy substrate, tool description integrity, and structured evidence emission (decision receipts and HMAC-chained run ledgers).
    4. Gateway: Owns cross-server policy, audit aggregation, shadow-mode rollout, semantic response scanning, and tenant isolation.
  7. Understand the PR Replay report structure

    main

    A PR Replay report (generated by Roam Code v13.4+) follows a specific schema to answer the 'eight evidence questions' required for agentic assurance. The report sections map to these questions:

    QuestionReport SectionDescription
    Q1: Who acted?ActorsIdentifies the actors and their Run IDs.
    Q2: What authority?AuthoritiesDetails the authority used and the operating Mode.
    Q3: What context read?(Referenced)Context read from pr-bundle.context_read[] (not a body section).
    Q4: What changed?Scope / Changed subjectsDetails symbols, files, and the diff hash.
    Q5: What could break?FindingsA rollup of findings per detector and confidence level.
    Q6: What policy?Authorities / Suggested Review configurationMaps findings to policy decisions and suggested rules.
    Q7: What verified it?TestsSummary of required vs. run tests and their status.
    Q8: Who accepted risk?Approvals and accepted risksRecords of approvals and accepted risks.

    Important: If certain data (like Q3 context or Q8 human approvals) is not available from the upstream producer, the report will explicitly list these under Evidence limitations using the reason producer_not_available.

  8. Manage MCP tool presets

    main

    Roam organizes its 244 tools into selectable presets to manage complexity and scope.

    Available Presets

    • core: The default preset (17 tools).
    • review
    • refactor
    • debug
    • architecture
    • compliance
    • compile-curated
    • full: Includes all available tools.

    Switching Presets

    1. At Startup: Use the ROAM_MCP_PRESET environment variable (e.g., ROAM_MCP_PRESET=full roam mcp).
    2. Mid-Session: If you are already running a session with a limited preset (like core), you can call the roam_expand_toolset tool to widen the available toolset without restarting the server.
  9. Analyze planned Roam Review (GitHub App) data flow

    main

    Roam Review is a planned hosted GitHub App designed for automated PR analysis. Its lifecycle is:

    1. Trigger: A GitHub webhook (HMAC-SHA-256 signed) triggers the process on PR open/push.
    2. Sandbox: An ephemeral, network-restricted sandbox container starts. The repository is cloned into this sandbox.
    3. In-Memory Analysis: The command roam pr-analyze --json --rules .roam/rules.yml --audit-trail runs in-process and in-memory.
    4. Feedback: A single sticky markdown comment is posted to the PR via the GitHub App installation token.
    5. Destruction: The sandbox container and working copy are destroyed.
    6. Retention: Only the verdict envelope (JSON metadata, no source bodies), an append-only audit-trail, and scrubbed operational logs are retained in an encrypted-at-rest store.

    Failure Handling:

    • Crashes: Containers are terminated immediately; no crash dumps or core files are persisted.
    • Error Tracking: Stack traces sent to Sentry are stripped of source content (no function bodies, comments, or literals) and file paths are truncated to repo-relative.
    • Timeouts: If analysis exceeds the wallclock budget (default 5 minutes), the sandbox is terminated and a timeout message is posted to the PR.
    roam pr-analyze --json --rules .roam/rules.yml --audit-trail
  10. Understand L1 transfer performance metrics

    main

    In roam-code benchmarks, L1 transfer performance is measured by how effectively the engine routes generic, repo-agnostic prompts to specific files using only symbol resolution (without explicit symbol names in the prompt).

    Key metrics include:

    • l1_route_rate_pct: The percentage of prompts that successfully routed to an L1 target. This metric is highly dependent on the specific prompt corpus used.
    • l1_probe / 60: The raw count of successful L1 hits out of a 60-prompt sweep.
    • procedure_distribution: The breakdown of how prompts are classified into different routing procedures (e.g., structural_blast, structural_callers, freeform_explore).
    • compile p50/p95 ms: The compilation time latency. Performance (speed and cost) does not degrade when running against foreign repositories compared to the home repository.
  11. Review what is and is not in scope for PR Replay

    main

    In Scope

    • Replay of the current roam detector set against the agreed commit range.
    • Aggregated detector-class breakdown of high-impact patterns.
    • Per-PR ranking of findings by severity (high $\rightarrow$ medium).
    • Recommended CI gates based on finding patterns.
    • A live walk-through call and Markdown/PDF deliverables.
    • Deep Tier Only: A written 90-day remediation plan with concrete roam commands and integration snippets.

    Out of Scope

    • Semantic correctness review: Checking if the code logic is correct (use tools like CodeRabbit, Greptile, or Qodo for this).
    • Security audit: This is not a third-party penetration test; it surfaces structural risks (clones, layer violations) rather than exploit paths.
    • Performance profiling: No benchmark runs are included.
    • Pre-merge review: This covers merged history only. For in-flight PRs, use the free CLI or subscribe to Roam Review.
  12. Manage verification exceptions with `.roam-suppressions.yml`

    main

    When a finding is a false positive or an intentional exception, you can record it in .roam-suppressions.yml.

    Key Properties:

    • Symbol-keyed: Suppressions are keyed by the code symbol, allowing them to survive refactors that change line numbers.
    • Manual only: Automatic hook corrections cannot alter suppressions, policies, or baselines.