AST-aware governance
Understand what a code change affects, why it needs review, and what to check before merging.
- 1Map the change
Read the diff and supplied symbol index to connect functions to callers.
- 2Apply fixed rules
Check sensitive paths, public interfaces and related test updates first.
- 3Classify uncertainty
Jev selects a fixed label. Low confidence goes to a human.
- 4Review the evidence
Use the recommendation and linked hunks. No merge or test is executed.
Proposed change
Start with the seeded auth change or paste your own diff. “Analyze changes” runs local static checks; “Classify with Jev” sends only the relevant structured context.
What does “AST-aware” mean here?
An abstract syntax tree represents code as named structures such as functions, parameters and imports. This prototype uses a lightweight parser plus your manifest, not a full compiler or a live repository checkout.
The manifest lists known symbols (named code units), callers (code that uses them), and test mappings. Missing information stays unknown; the app does not discover your whole repository.
Demo story: createUser gains organizationId. The registration caller is updated, the invitation job is unchanged, and no tests are updated. Expect human review.
Try Run mock demo for a complete walkthrough without API calls.
Both the selected-label probability and confidence must meet this threshold. A higher score never overrides a policy finding.
Governance decision
Follow the change through the codebase
Analyze a diff to see symbols, callers, activated policy and test scope.