[01] Product
From a diff to what to test.
Graphentra reads a pull request, traces what the change can reach, attaches a path to every surface it reports, and says what to test.
[02] The idea
Follow the structure, not every room.
When a building inspector signs off a change to a load-bearing wall, they do not re-inspect every room. They follow the structure to the rooms it holds up, and they write down anything they could not see behind the plaster.
Graphentra does that for a code change. It follows the dependency graph from what changed to the screens, endpoints and flows that depend on it, and it lists what it could not trace.
[03] How it works
Read. Trace. Prove. Say what to test.
Four steps from a diff to a checklist. Same diff, same answer, and every claim comes with its path.
-
The Git diff is mapped to the exact symbols that changed, using the TypeScript compiler and type checker. Not regex, not embeddings.
- Symbol-level, not file-level
- Compiler-grade parsing
- From changed functions to their callers Built · prototype
-
The dependency graph is walked backwards from each changed symbol to its callers, components, routes and API endpoints.
- Callers to routes and endpoints
- Every hop recorded
- From changed functions to their callers Built · prototype
- Surfaces inside the hashed evidence In development
-
Every affected surface carries its path, a confidence tier (proven, likely or unknown) and whether an existing test reaches it. What cannot be traced is listed as unknown, never silently dropped.
- A path for every claim
- Unknown stays visible
- A proof path for every affected surface In development
- Proven, likely and unknown confidence tiers In development
- Mapping to existing tests In development
-
A ranked, plain-English QA checklist. An LLM may narrate it. It never changes the evidence.
- Ranked for QA
- Narration is optional
- QA checklist written from the evidence Built · prototype
- A complete report that needs no LLM In development
Read from the diff
- 1 function changed ·
validateToken() - Signature unchanged
- Behaviour changed · audience check added
- verifyOtp() OTP login /login/otp Direct
- passwordLogin() Password login /login Shared
- sessionMiddleware Guardian access /guardian/children Indirect
- loadPermissions() Not traced dynamic import Unknown
4 surfaces listed · 3 reached by a traced path · 1 not traced
- OTP login validateToken → verifyOtp → /login/otp Tracing… Proven
- Password login validateToken → passwordLogin → /login Tracing… Proven
- Guardian access validateToken → sessionMiddleware → /guardian/children Tracing… Proven
- Dynamic permissions validateToken → loadPermissions → dynamic import Tracing… Unknown
Test reach · Guardian access
No existing test reaches it, and the ticket does not mention it.
- 1 Guardian access First Guardian access: check access after login and after session expiry. No test reaches this surface, and the ticket does not mention it.
- 2 OTP login No. 2 OTP login: check valid, invalid and expired codes.
- 3 Password login No. 3 Password login: check that a valid login still creates a working session.
- 4 Dynamic permissions Manual Dynamic permissions: not traced. Check role-based access by hand.
The limit of proof. Proof applies to the paths Graphentra reports. No path found is not proof of safety.
[04] The pull request check
One check, six parts.
The check your team would see on a pull request. Every part is drawn from the evidence file below.
- GitHub Action with a sticky PR comment and check In development
- Mapping to existing tests In development
- Useful, Noise and Missed feedback In development
Graphentra Impact PR #482 evidence a91f…c3 (reproducible)
Change: validateToken() in auth/token.ts, body change (audience check added)
| Surface | Confidence | In ticket? | Test reaches it? |
|---|---|---|---|
| Proven | Yes | Yes | |
| Proof path proven
OTP login calls the updated token validator. Check valid, invalid and expired codes. Tests that reach it | |||
| Proven | No | Yes | |
| Proof path proven
Password login uses the same token validator. Check that a valid login still creates a working session. Tests that reach it | |||
| Proven | No | No manual check | |
| Proof path proven
Guardian access relies on session middleware that uses the updated validator. Check access after login and after session expiry. Tests that reach it None found. | |||
| Unknown | No | Not applicable: the path is not traced not traced | |
| Proof path unknown
Permissions are loaded with a dynamic import, so the path beyond it cannot be traced. It is reported as unknown, not assumed safe. Tests that reach it Cannot be answered: the path is not traced. | |||
Was this useful? Useful Noise Missed something
QA checklist, ranked
- Guardian access: check access after login and after session expiry. No test reaches this surface, and the ticket does not mention it.
- OTP login: check valid, invalid and expired codes.
- Password login: check that a valid login still creates a working session.
- Dynamic permissions: not traced. Check role-based access by hand.
-
Reach In development
The surfaces the change can reach, named the way the people who test name them.
-
Proof In development
The path from the changed function to each surface. Open any row to read it.
-
Confidence In development
Proven, likely or unknown, shown with a label and a line style: solid for proven, dashed for unknown.
-
Test gap In development
Whether an existing test reaches the surface. If none does, the row says manual check.
-
Honesty In development
What could not be traced stays on the list as unknown. It is never dropped and never assumed safe.
-
Feedback In development
One click to say whether the check was useful, noise, or missed something.
[05] The evidence file
Plain JSON you can check in.
The check is a view of an evidence file. The file is content-hashed, so the same repository content, diff and engine version give byte-identical evidence.
- Content-hashed evidence file Built · prototype
- Surfaces inside the hashed evidence In development
{
"contentIdentity": "a91f…c3",
"outcome": "completed",
"changedEntities": [
{
"symbol": "validateToken",
"file": "auth/token.ts",
"change": "body"
}
],
"impacts": [
{
"surface": "/guardian/children",
"confidence": "proven",
"inTicket": false,
"testReaches": false,
"path": [
"validateToken",
"sessionMiddleware",
"/guardian/children"
]
},
{
"surface": "dynamic import",
"confidence": "unknown",
"reason": "dynamic import in loadPermissions(); not traced",
"path": [
"validateToken",
"loadPermissions",
"dynamic import"
]
}
],
"limitations": [
"Dynamic dispatch, reflection and runtime-only wiring are reported as unknown."
]
}[06] For coding agents
Give your agent something to check against.
A coding agent can ask what an edit reaches before it makes the edit, and again afterwards.
- MCP server for coding agents In development
-
impact_ofWhat a function or file can reach. Ask before an edit. -
affected_surfacesThe surfaces a diff can reach. Ask after an edit. -
explain_pathThe path from a change to one surface, step by step. -
tests_to_runThe existing tests that reach a change.
agent Task: reject tokens whose audience claim does not match.
calls impact_of ("validateToken")
Reaches 3 surfaces with proof paths. 1 path could not be traced.
/login/otp proven
/login proven
/guardian/children proven
dynamic import unknown , not traced
agent Editing auth/token.ts.
calls affected_surfaces ("HEAD~1..HEAD")
Same 3 surfaces. /guardian/children: no test reaches it.
agent Adding a note to the PR: check /guardian/children by hand.
[07] Supported stack
Narrow on purpose, and stated plainly.
The MVP targets one stack well. Anything outside it is listed as not supported yet.
Targeted for the MVP
Support for each is in development and not yet certified. A heuristic map of these frameworks exists in the prototype.
- TypeScript and TSX with React (and React Router) In development
- Next.js In development
- Express In development
- NestJS In development
- A single repository or a simple workspace In development
One repository, or a simple npm or pnpm workspace.
- GitHub In development
Pull request comment and check on GitHub.
Not supported yet
Limitations, listed so you do not have to find them out.
- Other languages Not yet
Python is planned after the MVP.
- Vue and Angular Not yet
Not on the MVP path.
- GitLab and Bitbucket Not yet
GitHub only for now.
- Cross-repository analysis Not yet
One repository, or a simple workspace, at a time.
- Running tests Not yet
Graphentra lists the tests that reach a change. It does not run them yet.