Your agent guesses.
Your runtime knows.

Ask it anything

Every method, annotated with what actually ran through it.

Grep for .call and you get ten thousand hits: every service object, proc and middleware in your app and its gems, with nothing to say which ones this line reaches. The recording has the answer: the receivers that actually showed up here, with their types and how often. Each tool is one question, asked of the same recording. A few of them:

Anything else? Ask the hosted graph directly in Cypher. See all the tools →

Example 2 · what doubles hide

Every unit green. The seam never ran for real.

A lying stub is one double. Zoom out and the same blind spot covers whole boundaries, test first or test after. Checkout's spec stubs the gateway and the gateway's spec tests itself: every line is covered, and no example ever runs the real Checkout calling the real PaymentGateway. Coverage counts lines, not collaborations.

Runtime Analysis maps the recorded call graph onto your pyramid and names the boundaries only ever crossed through a double. Record production too and they're ranked by real traffic. Then it scaffolds the test that crosses one for real.

The same gap, on whichever surface you're working: your agent, your editor, the command line.

testing_pyramid(stubbed_only: true)
→ { stubbed_only: 212,
  boundaries: [
    { call: "Checkout#call",
      to: "PaymentGateway#charge",
      stubbed: 3, real: 0,
      prod: 8204 },
    { call: "Report#build",
      to: "Invoice#total",
      stubbed: 2, real: 0,
      prod: 4102 }
  ] }

def call
  gateway.charge(amount)
    ⤷ stubbed in 3 specs · never real
end

$ ra testing_pyramid --stubbed-only

212 boundaries · only crossed via doubles

Checkout#call → PaymentGateway#charge
  3 stubbed · 0 real · 8,204 prod
Report#build → Invoice#total
  2 stubbed · 0 real · 4,102 prod

Then it writes the test that crosses the seam, from a real run: --scaffold on the CLI, the editor's quick-fix, or your agent generating it from the structured boundary.

$ ra testing_pyramid --scaffold Checkout#call
# setup taken from a real run (how_to_reach)
RSpec.describe Checkout do
  it "charges the gateway" do
    gateway  = PaymentGateway.new(account:, rate_table:)
    checkout = Checkout.new(cart:, gateway:)
    expect { checkout.call }.to change(gateway, :charged?).to(true)
  end
end

Where you ask

In your agent, your editor, your terminal and CI.

Curriculum#unlocked_for from one recording: queried by your agent, shown in your editor, printed on the command line, and enforced in CI.

observed_shape(
  "Curriculum#unlocked_for",
  as: "return"
)
→ {
  return:   { class: Array,
    responds: [select, each, any?] },
  element:  { class: Book,
    responds: [unlocked?, id, title] },
  examples: 12,
  prod_runs: 3181
}

def unlock_next
  = curriculum.unlocked_for(student)
  ⤷ Array<Book> · #unlocked? #id #title

$ ra observed_shape \
    Curriculum#unlocked_for

return   → #select #each #any?  Array
element  → #unlocked? #id #title  Book
· from 12 spec examples
  and 3,181 production runs

▸ ra check --since origin/main

✗ verify_mock · Curriculum#unlocked_for
  stub returns   Array<Symbol>
  real runs      Array<Book> → #unlocked? #id #title
  ↳ 1 false positive introduced

Error: Process completed with exit code 1

↳ PRO posted to the PR as a review comment

An MCP tool your agent can call, plus a Claude Code hook that checks every spec it writes. A lying mock gets caught in the same edit that introduced it.

What the agent runs over MCP is a plain command too. Run ra verify_mock in your suite, or ra check on a diff as a CI gate, and a lying mock fails the build instead of merging.

$ ra verify_mock enrollment_spec.rb

✗ stub Curriculum#unlocked_for is a false positive
  your stub returns   [:geometry]            Array<Symbol>
  the real one        returns an Array whose
                      elements receive #unlocked?, #id
                      in curriculum_spec.rb (12 examples)
                      and 3,181 production runs
  a Symbol responds to neither

↳ PRO real types responding to {#unlocked?, #id}:
    Book · SampleBook · ArchivedBook     across your app
    → swap one in, or generate a verified fake from its contract

↳ and the bug it hid:
  unlock_next returned :geometry for a student who
  hasn't finished its prerequisite — a locked book leaked

Test first

You write the test first. Good: your suite is the recording.

The class you're about to write doesn't exist yet, but everything it collaborates with does, and earlier cycles' tests already ran that code for real. Mock Gateway in Checkout's spec and Gateway's own spec still runs the real thing, so every double has a real recording to be checked against.

The test-first walkthrough →

No tests yet

No tests yet? Record the app instead.

Most tools need a test before they can tell you anything. Runtime Analysis records whatever runs, so point it at your app in development, staging or production and code with no specs still shows up. The more a path runs, the more we know about it, with or without a test.

On a module with zero specs you still get the real callers, the class shapes of what each method takes and returns, and a flag when a change breaks a contract the code has always honoured. When you're ready to pin it down, it scaffolds a characterization test from an actual run, so the first test isn't a guess.

$ ra observe app/billing/proration.rb   # no specs in sight

Proration#amount  seen in 41,900 production calls
  callers   Checkout#call · Invoice#total · Api::QuotesController
  returns   responds to #cents, #currency        (Money)
  raised    ArgumentError on 18 calls where amount was negative

# no test covers this path
  scaffold a characterization test from the recorded run:
  $ ra scaffold Proration#amount

The evidence is the traffic. A path that runs ten thousand times in production is described by those ten thousand runs, whether or not anyone wrote a test for it.

Safe to leave on in production. Under load it drops records and counts them rather than blocking your app, so the recording is honestly incomplete, never silently wrong. A bug in the tracer degrades tracing, never your app.