Before you change code, check what uses it

The saved React example asks:

kin refs getToStringValue --kind calls

That text output was saved on September 7, 2026, using Kin v0.7.3 on macOS arm64. Its Kin commit is 72f1cfba717b5fde8a7d6de261526a6c99a422e9; the React source is pinned at 9b7a0d4029ee31f84446383b6530075f423e9904.

The result groups call sites under eight functions:

Those groups matter. One function may call the target more than once, so the number of caller functions and the number of call sites are different things.

You can inspect the underlying source without installing Kin. This Python 3 script downloads only the three public source files at that fixed React revision and prints lines containing the call expression. It does not execute the downloaded JavaScript or write files.

import re
import urllib.request

base = (
    "https://raw.githubusercontent.com/facebook/react/"
    "9b7a0d4029ee31f84446383b6530075f423e9904/"
    "packages/react-dom-bindings/src/client/"
)

for name in (
    "ReactDOMInput.js",
    "ReactDOMSelect.js",
    "ReactDOMTextarea.js",
):
    source = urllib.request.urlopen(base + name).read().decode()
    print(name)
    for line_no, line in enumerate(source.splitlines(), 1):
        if re.search(r"\bgetToStringValue\s*\(", line):
            print(f"  {line_no}: {line.strip()}")

For these files, the source check prints these line numbers:

ReactDOMInput.js:    133, 135, 136, 149, 170, 172, 175, 216,
                    258, 260, 277, 278, 373, 375
ReactDOMSelect.js:   90, 194
ReactDOMTextarea.js: 73, 87, 130, 168

Compare them with the call sites on the recorded result. Then open the surrounding functions. For example, ReactDOMInput.js at the pinned revision lets you inspect the calls inside updateInput, rather than treating a matching line as sufficient explanation.

This is an independent source check. Text matching alone does not establish the meaning of every relationship, discover every indirect call, or prove that changing the target is safe. An editor or language server can also provide useful evidence here. The point is to make a recorded answer inspectable.

There is another important boundary: the example uses a snapshot with one commit, not React's full history. It cannot answer historical questions about how those connections changed. It also does not establish how a fresh installation will prepare the full React repository today. Repeating that workflow requires its own preparation and runtime evidence. This is one saved answer, not a speed benchmark or a promise of complete coverage.

A useful next test should include a case the tool handles poorly. An interface, callback or generated boundary could expose a missing connection that a straightforward call does not. The result should distinguish a relationship it found from an area it could not resolve.