Code review
How the review works
Rubric code-v0.3. Fixed rules applied to files read as text, with every finding showing where it came from.
Principles
- Nothing runs. The repository archive is read in memory as text. Nothing is installed, built, executed or written to disk.
- No AI reads your code. Scoring and findings come from fixed rules and database lookups. Explanations are written in advance.
- Evidence first. A finding shows the rule, the file and the line. Pattern rules are labelled as detected by rule, and heuristics are labelled as needing a person to confirm.
- Missing data is never a penalty and never a pass. A check that cannot run is left out and listed under what the review cannot see.
Areas and weights
| Area | Weight | What is checked |
|---|---|---|
| Secrets and key exposure | 22 | Specific token formats, committed environment files, secret-looking values and keys exposed to the browser. The secret itself is never stored or shown. |
| Dependencies | 20 | Exact versions from lockfiles checked against the OSV vulnerability database, supported runtime versions declared in the repository, lockfile presence and loose version pins. |
| Code and database security | 20 | Known risky patterns (injection, XSS, disabled TLS checks, open CORS), routes that change data with no visible auth check (a heuristic), and database access rules: Supabase row-level security and Firebase security rules read from the repository. |
| Bugs and code that will not run | 20 | Files that do not parse, imports of files or packages that do not exist (including capitalisation that works on a Mac but fails on Linux), Next.js files that cannot build, unresolved merge conflicts, placeholder code and addresses that only work on the author's machine. Found by reading the code, not by running it, so logic bugs that only appear at run time are not covered. |
| Project hygiene | 10 | Automated checks (CI), tests, ignore rules for environment files, undocumented environment variables, committed build output and very large files. |
| Code quality signals | 8 | Error handling, type escapes, debug leftovers, TODO density, unused dependencies and very large files. These are measured counts, not judgements about design. |
Rules
- The headline is the weighted average of the areas that could be scored. A critical finding caps it at 50, and two or more high-priority findings cap it at 70.
- Dependencies are checked only for exact versions found in lockfiles, using the open OSV database. Runtime end-of-life dates come from endoflife.date (snapshot 2026-10-16).
- Database security is read from files in the repository: Supabase row-level security from SQL migrations, and Firebase rules from the rules files. Anything changed only in the Supabase or Firebase dashboard is not visible, and the report says so.
- Bug checks parse every JavaScript and TypeScript file with a real parser, then check imports against the files and packages that exist. Capitalisation mismatches are reported because they work on macOS and Windows but fail on Linux, which most hosts use. These checks read code; they do not run it, so they find what will break a build, not logic errors that only appear at run time.
- Deep pattern rules cover JavaScript and TypeScript, Python and PHP; syntax and import checks cover JavaScript and TypeScript. Other languages get the secret, dependency and project checks only.
Privacy and access
- Access: a GitHub App with read-only access to file contents and basic repository details. You choose which repositories to share. Each review gets a token limited to one repository that expires within an hour and is never stored.
- Who can review what: every review checks with GitHub that you can access that repository through the installation.
- Your sign-in: your short-lived GitHub sign-in is kept in an encrypted cookie on your device, never in our database, and cleared when you disconnect.
- What we store: findings, file paths, line numbers, the commit identifier and the repository name, in a private report. Never source code, never a secret value.
- Retention: reports are deleted after 30 days, when you delete one, or when the App is removed from the account or repository.
- Your choices: to see or delete anything, or to raise a concern, email contact@zovintra.com. We are Zovintra Private Limited, Sirohi, Rajasthan, India. Our general privacy policy also applies.
Limits
This is an automated initial assessment based on public information at one point in time. It is not a code audit, penetration test or security certification. Pattern matches can flag safe code and miss real problems. A senior engineer can verify the findings and cover what a static review cannot see.