@codragraph/cli 1.6.4 → 2.1.0

package/skills/codragraph-project-switcher.md

@@ -0,0 +1,116 @@
+---
+name: codragraph-project-switcher
+description: "Use when the user works across many parallel projects and needs to switch context, find which repo a symbol is in, list all indexed projects, or run a query against a specific repo without ambiguity. Examples: \"what projects am I working on\", \"switch to repo X\", \"which of my repos has function Y\", \"list my repositories\""
+---
+
+# Multi-Project / Vibecoding Context Switcher
+
+## When to Use
+
+- "What projects do I have indexed?"
+- "Switch to my `<project>` repo for this query."
+- "Which of my repos has the `<symbol>` function?"
+- "Run this query across all my repos."
+- Solo dev juggling 4+ side projects with different agents
+- Picking up a project after weeks away
+
+## Why CodraGraph helps here
+
+CodraGraph maintains a global registry of every indexed repo at
+`~/.codragraph/registry.json`. Every MCP tool accepts a `repo` parameter
+to disambiguate. So switching context isn't "open a new editor / cd into
+the project / re-orient your agent" — it's just passing `repo: "<name>"`
+to the next call. Combine with **groups** (multiple repos that share
+contracts) and you get cross-repo queries with one call.
+
+## Workflow
+
+```
+1. List every indexed repo:
+   codragraph_list_repos({})
+   → name, path, file count, last analyze time
+
+2. (Optional) List groups (sets of related repos):
+   codragraph_group_list({})
+   → group name + member repos
+
+3. Query against a specific repo:
+   codragraph_query({repo: "<name>", query: "<concept>"})
+   → answers come from that repo only
+
+4. Find which repo has a symbol you remember:
+   For each repo from list_repos:
+     codragraph_query({repo: "<name>", query: "<remembered name>"})
+   → first hit identifies the repo
+
+5. For cross-repo questions (group-mode):
+   codragraph_query({repo: "@<group>", query: "<concept>"})
+   → fans out across every group member, RRF-merges results
+```
+
+> If `list_repos` returns nothing, the user has no indexed projects yet.
+> Run `codragraph analyze` in each project once to register them.
+
+## Checklist
+
+```
+- [ ] list_repos to see what's indexed
+- [ ] group_list to see related-repo groups
+- [ ] Pick the right repo (or group) for the question
+- [ ] Pass repo: "<name>" or repo: "@<group>" to subsequent calls
+- [ ] If a project isn't indexed yet, suggest the user run analyze in it
+- [ ] Mention staleness ("repo X last indexed 12 days ago — re-analyze?")
+```
+
+## Multi-Project Patterns
+
+| Situation | What to do |
+| --- | --- |
+| Switching from one solo project to another | `list_repos` → pick → all subsequent tools take `repo: "<name>"` |
+| "Did I solve this in another repo?" | `query` over each repo, look for matching symbols |
+| Shared library used by multiple repos | Define a group (group.yaml); use `repo: "@<group>"` |
+| Resuming a project after weeks | Check staleness (`list_repos` last-indexed timestamps); re-analyze if old |
+
+## Example: "Switch me to my SaaS side project and find the auth code"
+
+```
+1. codragraph_list_repos({})
+   → 4 indexed repos:
+     - codragraph (~/code/codragraph, 4325 symbols, indexed 2 hours ago)
+     - my-saas (~/projects/my-saas, 1180 symbols, indexed 3 days ago)
+     - portfolio (~/code/portfolio, 240 symbols, indexed 2 weeks ago)
+     - data-eda (~/notebooks/data-eda, 95 symbols, indexed 1 month ago)
+
+2. codragraph_query({repo: "my-saas", query: "authentication login session"})
+   → top 5 symbols in my-saas, none in other repos
+
+3. codragraph_context({repo: "my-saas", name: "validateSession"})
+   → callers: requireAuth, refreshToken (both in my-saas)
+
+4. (Optional) Reminder: my-saas was indexed 3 days ago — fine for navigation
+   but if I just made commits, run `cd ~/projects/my-saas && codragraph analyze`
+   to refresh.
+
+Switched. Subsequent queries default to my-saas now.
+```
+
+## Output Format
+
+```markdown
+## Project Switch: → `<repo>`
+
+### Available projects
+1. **<repo-1>** — N symbols, last indexed Xh ago
+2. **<repo-2>** — M symbols, last indexed Yd ago (stale?)
+3. ...
+
+### Active for this conversation
+`<chosen-repo>` (path: `<path>`).
+
+### Staleness note
+Last indexed `<duration>` ago. Re-analyze if recent commits matter.
+
+### Quick links
+- `query` already scoped to this repo
+- For cross-repo: pass `repo: "@<group>"` instead
+```

package/skills/codragraph-security-audit.md

@@ -0,0 +1,144 @@
+---
+name: codragraph-security-audit
+description: "Use for security-focused codebase audits — finding auth bypass paths, missing input validation, secrets in code, untrusted-input flow, and routes that skip auth middleware. Examples: \"security audit\", \"find auth bypass\", \"unvalidated input\", \"untrusted data flow\", \"missing authentication\""
+---
+
+# Security Audit with CodraGraph
+
+## When to Use
+
+- "Audit auth coverage — which routes skip the auth middleware?"
+- "Find input that flows from request to SQL/template/exec without validation."
+- "Find hardcoded secrets / credentials in source."
+- "Trace untrusted-input flow for `<endpoint>`."
+- Pre-release security pass on a PR-heavy week.
+
+## Why CodraGraph helps here
+
+Static-analysis tools find pattern matches; CodraGraph adds the
+**call-graph**, so you can answer "*which* request handlers reach this
+unsafe sink?" rather than just "this sink is unsafe somewhere." Combined
+with `query` for sensitive identifier strings and `cypher` for structural
+filters, you can build an audit that's far more targeted than grep.
+
+## Workflow
+
+```
+1. Identify the boundary symbols:
+   codragraph_query({query: "request handler route controller"})
+   → all entry points where untrusted input arrives
+
+2. Identify the dangerous sinks:
+   codragraph_query({query: "exec spawn eval query raw_sql innerHTML"})
+   → places where untrusted input becomes harmful
+
+3. For each (handler → sink) pair, walk the call graph:
+   codragraph_impact({target: "<sink>", direction: "upstream"})
+   → which handlers REACH this sink?
+
+4. For each path, look for a validator on the way:
+   codragraph_context({name: "<handler>"})
+   → is `validate / sanitize / escape / parse` called between handler and sink?
+   → if not: candidate vulnerability
+
+5. Cross-check against secrets:
+   codragraph_cypher({query: "MATCH (n) WHERE n.body =~ '.*(?i)(api[_-]?key|secret|password|token)[ ]*=[ ]*[\\'\"][a-zA-Z0-9]{16,}.*' RETURN n"})
+   → suspicious literals that look like real keys
+```
+
+## Audit Patterns
+
+| Pattern | What to look for | CodraGraph approach |
+|---|---|---|
+| Auth bypass | Routes not wrapped by `requireAuth` middleware | `query` for routes; check `context` for middleware in callers |
+| SQL injection | Raw query string built from request input | `query` SQL literals → `impact` upstream → flag handlers |
+| XSS | Untrusted input rendered without escape | `query` `innerHTML` / `dangerouslySetInnerHTML` → impact upstream |
+| Command injection | `exec` / `spawn` with concatenated input | `query` exec/spawn → impact upstream → check for shell escape |
+| Open redirect | Redirect URL from request | `query` `redirect` / `Location:` → trace input source |
+| Hardcoded secrets | API keys in source | `cypher` regex over `n.body` |
+| Missing CSRF | State-changing routes without CSRF middleware | `query` POST / PUT / DELETE handlers → check middleware chain |
+
+## Why "missing validator" is a great query
+
+The graph cleanly shows the call path: `handler → … → sink`. Validators
+appear in that chain or they don't. If `validateInput` / `sanitize` /
+`escape` is NOT in the path between a handler and a sink, that's a
+*provable* gap, not a guess.
+
+```
+codragraph_cypher({query: `
+  // Find handler→sink paths that don't pass through ANY validator
+  MATCH path = (handler {label: 'Function'})-[:CALLS*1..6]->(sink {label: 'Function'})
+  WHERE handler.isEntryPoint = true
+    AND sink.name IN ['exec', 'query', 'innerHTML', 'eval']
+    AND NONE(n IN nodes(path) WHERE n.name STARTS WITH 'validate'
+                                  OR n.name STARTS WITH 'sanitize'
+                                  OR n.name STARTS WITH 'escape')
+  RETURN handler.name, sink.name, length(path) AS hops
+  ORDER BY hops ASC
+`})
+```
+
+## Checklist
+
+```
+- [ ] Listed entry-point handlers (query for "handler"/"route"/"controller")
+- [ ] Listed dangerous sinks (exec/query/eval/innerHTML/raw)
+- [ ] Built handler→sink table; flagged paths missing validators
+- [ ] Cypher scan for hardcoded-secret literal patterns
+- [ ] codragraph_context on each flagged handler — confirm coverage / propose fix
+- [ ] Document findings as severity-tagged report
+```
+
+## Example: "Audit which routes skip our requireAuth middleware"
+
+```
+1. codragraph_query({query: "Express router get post put delete handler"})
+   → 28 route handlers across 6 router files
+
+2. For each handler, codragraph_context({name: "<handler>"}):
+   → check that callers include `requireAuth` (a known middleware function)
+
+3. codragraph_cypher({
+     query: `MATCH (handler {isEntryPoint: true})-[:CALLS]->()
+              WHERE NOT EXISTS {
+                MATCH (handler)<-[:CALLS]-(mw {name: 'requireAuth'})
+              }
+              RETURN handler.name, handler.filePath`
+   })
+   → 4 handlers have no requireAuth caller:
+     - publicHealthCheck (intentional ✓)
+     - signup, login (intentional ✓ — these CREATE auth)
+     - debugDumpUser ⚠ (NOT intentional — leaks user data)
+
+4. Findings report:
+   - HIGH: debugDumpUser at src/routes/debug.ts:42
+     reaches db.query → returns full user record. No auth.
+     Fix: wrap with requireAuth or remove from production builds.
+```
+
+## Output Format
+
+```markdown
+## Security Audit: <scope>
+
+### Summary
+- N handlers audited
+- M handler→sink paths inspected
+- K validator-missing paths flagged
+- Severity: 1 HIGH, 2 MEDIUM, 0 CRITICAL
+
+### Findings
+
+#### HIGH — debugDumpUser at src/routes/debug.ts:42
+- Reachable without `requireAuth`
+- Calls `db.query` with no input validation
+- Returns full user record
+- **Fix:** wrap with auth middleware OR strip from production builds
+
+#### MEDIUM — …
+
+### Hardcoded-secret scan
+- 0 high-confidence matches
+- 1 false-positive: example token in test fixture
+```

package/skills/codragraph-sql-tracing.md

@@ -0,0 +1,122 @@
+---
+name: codragraph-sql-tracing
+description: "Use when finding where SQL queries are constructed in code, tracing which functions execute a given query, auditing query patterns, or finding the call sites of a stored procedure. Examples: \"where is this SELECT defined\", \"who calls this query\", \"find all SQL in the auth module\", \"trace this stored procedure call\""
+---
+
+# SQL Query Tracing with CodraGraph
+
+## When to Use
+
+- "Where is the query for `<table>` constructed?"
+- "Which functions execute `<sql snippet>`?"
+- "Find all SQL string literals in `<area>`."
+- Auditing query patterns (N+1, missing indexes, etc.) before optimization
+- Tracing a stored-procedure call from production logs back to the caller
+
+## Why CodraGraph helps here
+
+SQL queries are usually plain string literals — the language-server knows
+nothing about them, but `query` over the index plus `cypher` against the
+graph can find them, and `context` / `impact` can trace who calls the
+enclosing function. This works equally well for raw SQL strings, query
+builders (Knex, SQLAlchemy, Diesel), and ORM-generated queries that
+include a recognizable identifier.
+
+## Workflow
+
+```
+1. codragraph_query({query: "SELECT FROM <table>"})
+   OR
+   codragraph_query({query: "<unique substring of the SQL>"})
+   → symbols whose body contains the SQL fragment
+
+2. For each candidate function:
+   codragraph_context({name: "<function>"})
+   → see who calls it (the actual query-execution site)
+
+3. codragraph_impact({target: "<function>", direction: "upstream"})
+   → blast radius: every caller of the SQL-executing function
+
+4. For ORM / query-builder users:
+   codragraph_query({query: "<table>.find OR <table>.where"})
+   → find ORM calls that compile to SQL touching the table
+
+5. Categorize: reads vs writes, hot paths vs cold paths
+```
+
+> CodraGraph indexes the *source* of the query, not the *executed* SQL.
+> Dynamically built queries (`f"SELECT * FROM {table}"`) require both a
+> string-literal search AND a check on the variable's binding via `context`.
+
+## Checklist
+
+```
+- [ ] query for the SQL substring or table name
+- [ ] context on each candidate function
+- [ ] impact upstream on the executor → who calls it from the application
+- [ ] Filter for ORM call patterns separately if relevant
+- [ ] Group results: read paths vs write paths, hot vs cold paths
+- [ ] Flag any query with no test reach (cross-ref with codragraph-test-coverage)
+```
+
+## SQL Patterns to Search
+
+| Pattern | Search query |
+| --- | --- |
+| Raw string SELECT | `"SELECT FROM users"` (with table name) |
+| Query builder (Knex) | `.from('users').where` |
+| ORM (SQLAlchemy) | `session.query(User)` |
+| Stored procedure call | `CALL sp_name` or `EXEC sp_name` |
+| Migration | `CREATE TABLE` / `ALTER TABLE` |
+
+## Example: "Find every place we read from the `audit_log` table"
+
+```
+1. codragraph_query({query: "FROM audit_log"})
+   → 5 symbols:
+     - getAuditByUser (src/admin/audit.ts)
+     - getAuditByAction (src/admin/audit.ts)
+     - exportAuditCSV (src/admin/audit.ts)
+     - countRecentAuditEntries (src/dashboard/health.ts)
+     - debugAuditDump (src/scripts/debug.ts)
+
+2. codragraph_query({query: "auditLog.find OR auditLog.where"})
+   → 0 (we're using raw SQL, not an ORM)
+
+3. codragraph_context({name: "getAuditByUser"})
+   → callers: AuditController.show, AuditController.export
+   → callees: db.query, parseAuditRow
+
+4. codragraph_impact({target: "getAuditByUser", direction: "upstream"})
+   → d=1: AuditController.show (admin UI), AuditController.export (CSV download)
+   → d=2: AdminRouter (HTTP layer)
+
+Findings: 5 read sites in 3 files. All go through AuditController. The
+debug script reads with no auth — flag for review.
+
+5. Cross-reference with codragraph-test-coverage:
+   - getAuditByUser: covered by AuditController.test
+   - debugAuditDump: NO TESTS, NO AUTH ⚠
+```
+
+## Output Format
+
+```markdown
+## SQL Trace: `audit_log` (reads)
+
+### Read sites
+| Function | File | Caller chain | Test reach |
+|----------|------|--------------|------------|
+| getAuditByUser | src/admin/audit.ts | Controller → Router | ✓ |
+| getAuditByAction | src/admin/audit.ts | Controller → Router | ✓ |
+| exportAuditCSV | src/admin/audit.ts | Controller → Router | ✗ |
+| countRecentAuditEntries | src/dashboard/health.ts | HealthCheck → cron | ✗ |
+| debugAuditDump | src/scripts/debug.ts | (no auth?) ⚠ | ✗ |
+
+### Hot path
+`AuditController` is the gateway for 3 of 5 read sites. Optimizations
+that route through it benefit the most.
+
+### Risks
+- `debugAuditDump` has no auth and no tests. Investigate.
+```

package/skills/codragraph-supply-chain-audit.md

@@ -0,0 +1,153 @@
+---
+name: codragraph-supply-chain-audit
+description: "Use to audit external dependency risk — which packages does the codebase actually use, where are the deepest integration points (a single dep used across N modules is high-blast-radius), what would break if a dep was removed. Examples: \"audit dependencies\", \"supply chain risk\", \"what would break if I drop X\", \"deep dep usage\", \"vendor in or replace\""
+---
+
+# Supply Chain / Dependency Audit with CodraGraph
+
+## When to Use
+
+- "Which deps are used the most?"
+- "What would actually break if I removed `<package>`?"
+- "Find deps imported in only 1-2 places (cheap to replace)."
+- "Which deps are deeply integrated and risky to change?"
+- "Pre-vendor audit: should I vendor `<dep>` to lock the version?"
+- "Post-CVE: which of our code paths reach this vulnerable function?"
+
+## Why CodraGraph helps here
+
+`npm ls` / `pip list` / `go.sum` tell you which packages are *installed*.
+CodraGraph tells you where they're *imported and called* — which is the
+real measure of how integrated a dep is. Pair with `impact` for "what
+breaks if this dep changes" and you have a much sharper risk picture
+than pure dependency-tree analysis.
+
+## Workflow
+
+```
+1. List external dependency import sites:
+   codragraph_cypher({query: `
+     MATCH (n)-[:IMPORTS]->(dep)
+     WHERE dep.isExternal = true OR dep.id STARTS WITH 'package:'
+     RETURN dep.id, dep.name, count(DISTINCT n) AS importers
+     ORDER BY importers DESC
+   `})
+   → per-package import counts
+
+2. For each high-import package, find which symbols call into it:
+   codragraph_cypher({query: `
+     MATCH (caller)-[:CALLS]->(target)
+     WHERE target.filePath CONTAINS 'node_modules/<pkg>'
+        OR target.id STARTS WITH 'package:<pkg>:'
+     RETURN caller.name, caller.filePath, count(*) AS calls
+     ORDER BY calls DESC
+   `})
+   → per-package call sites; high-call-site = deeply integrated
+
+3. Identify shallow deps (cheap-to-replace):
+   - 1-2 importers → easy to swap out
+   - usage limited to one cluster → bounded blast radius
+
+4. Identify deep deps (high replacement cost):
+   - imported across many clusters → cross-cutting
+   - referenced in critical processes → request-path criticality
+
+5. CVE-specific: given a vulnerable function name from the advisory,
+   find which of YOUR symbols reach it:
+   codragraph_impact({target: "<vulnerableFn>", direction: "upstream"})
+   → only paths through this function are actually exposed
+```
+
+## Risk categorization
+
+| Category | Signal | Action |
+|---|---|---|
+| **Trivial** | 1-2 importers, one cluster | Easy to replace; consider native impl |
+| **Local** | Many importers in 1-2 clusters | Wrap behind a façade for future swap |
+| **Cross-cutting** | Importers spread across most clusters | Treat as core infra; vendor if licensing allows |
+| **Critical** | In every request-path process | Pin version, monitor CVEs, plan migration before EOL |
+| **Vulnerable now** | Reachable code path to a known-CVE function | Patch / replace ASAP |
+
+## CVE response workflow
+
+```
+1. CVE published: "<package> <vulnerable-fn> allows X"
+
+2. Quick check: do we even reach the vulnerable function?
+   codragraph_query({query: "<vulnerable-fn>"})
+   → list of call sites in YOUR code
+
+3. For each call site, walk upstream:
+   codragraph_impact({target: "<our-caller>", direction: "upstream"})
+   → which entry points / processes reach the vulnerable code
+
+4. If 0 reachable paths → not exposed. Patch when convenient.
+5. If reachable from request-path → patch ASAP, communicate scope.
+6. If reachable from internal-only paths → patch in the next maintenance window.
+```
+
+## Checklist
+
+```
+- [ ] Cypher: per-package importer + caller counts
+- [ ] Categorize each top-N package: trivial / local / cross-cutting / critical
+- [ ] For deep deps: identify a façade boundary if one exists / propose one
+- [ ] CVE list cross-check: any current advisories against our deps?
+- [ ] For each open advisory: codragraph_impact on the vulnerable function
+- [ ] Output: ranked deps with risk tier + replaceability cost
+```
+
+## Example: "Should I replace lodash with native?"
+
+```
+1. codragraph_cypher for lodash imports:
+   → 47 importers across all 8 clusters
+   → Cross-cutting category.
+
+2. codragraph_cypher for lodash calls:
+   → top-called: _.get (78), _.isEmpty (54), _.cloneDeep (32),
+     _.debounce (12), 25 other functions ≤ 5 calls each
+
+3. Replacement cost analysis:
+   - _.get → optional chaining `?.` (47 sites)
+   - _.isEmpty → custom helper (3 lines)
+   - _.cloneDeep → structuredClone() (Node 17+)
+   - _.debounce → keep (lodash version is well-tuned, native lacks)
+   - 25 long-tail functions → ~75 individual replacement decisions
+
+4. Decision matrix:
+   - High-frequency simple ones: easy native swap (saves 70%% of bundle hit)
+   - _.debounce: keep lodash for this one (or use a 50-line single-purpose dep)
+   - Long-tail: case-by-case during routine refactors
+
+5. Migration plan:
+   - Phase 1: replace _.get / _.isEmpty / _.cloneDeep (top 3 = ~200 call sites)
+   - Phase 2: revisit long-tail in next major refactor
+   - Phase 3: keep lodash only if _.debounce's replacement isn't ready
+```
+
+## Output Format
+
+```markdown
+## Supply Chain Audit: <scope>
+
+### Top deps by integration depth
+| Package | Importers | Call sites | Clusters touched | Tier |
+|---|--:|--:|--:|---|
+| react | 142 | 380 | 4 | critical |
+| lodash | 47 | 220 | 8 | cross-cutting |
+| date-fns | 12 | 45 | 3 | local |
+| classnames | 4 | 9 | 2 | local |
+| md5 | 1 | 1 | 1 | trivial |
+
+### Replacement candidates
+- `md5` — 1 call site, ~5 lines of native crypto. Trivial removal.
+- `lodash` — replace top 3 functions for 70%% of usage; keep for `_.debounce`.
+
+### CVE exposure
+- 0 active advisories matching code paths reachable from request handlers.
+
+### Recommended next step
+1. Drop `md5` (5-line PR).
+2. Phase-1 lodash slim-down (~200 sites; can be incremental).
+```

package/skills/codragraph-test-coverage.md

@@ -0,0 +1,97 @@
+---
+name: codragraph-test-coverage
+description: "Use when the user wants to find untested code paths, audit test coverage gaps, identify functions or execution flows that have no test reach, or assess whether a refactor needs new tests. Examples: \"what isn't tested\", \"test coverage gaps\", \"which flows have no tests\", \"do I need a test for X\""
+---
+
+# Test Coverage Audit with CodraGraph
+
+## When to Use
+
+- "What's not tested in this codebase?"
+- "Which execution flows have no test coverage?"
+- "Are there tests that cover X?"
+- "Do I need to add a test for this function?"
+- Auditing coverage before a release / freeze
+- Justifying a "needs more tests" review comment with evidence
+
+## Why CodraGraph helps here
+
+Line-coverage tools (jest --coverage, c8, pytest-cov) tell you *which lines
+ran*. They don't tell you *which call paths an agent / engineer should be
+worried about*. CodraGraph's `impact({includeTests: true})` walks the call
+graph and lists every test that transitively reaches a symbol — direct or
+indirect — so you can prove a flow is exercised, or prove it isn't.
+
+## Workflow
+
+```
+1. codragraph_query({query: "<area you care about>"})        → find candidate symbols
+2. For each non-trivial symbol:
+   codragraph_impact({target: "<symbol>", direction: "upstream", includeTests: true})
+   → returns: callers + tests that transitively reach this symbol
+3. READ codragraph://repo/{name}/processes
+   → list every execution flow
+4. For each flow, codragraph_impact on the flow's entry point with includeTests: true
+   → flows with 0 tests = real gaps
+5. Summarize: which symbols and flows have no test reach
+```
+
+> If "Index is stale" → run `npx @codragraph/cli analyze` first.
+
+## Checklist
+
+```
+- [ ] List candidate symbols (query) or take from a recent diff (detect_changes)
+- [ ] Run impact({includeTests: true}) on each
+- [ ] Note symbols where the test list is empty
+- [ ] Cross-reference with processes — flows with no test coverage are the real risk
+- [ ] Report: gaps + the cheapest test that would close each gap (entry point)
+- [ ] If reviewing a PR: limit to symbols changed in the PR
+```
+
+## Example: "What's not tested in the auth area?"
+
+```
+1. codragraph_query({query: "auth validation login session"})
+   → 14 symbols across 6 files
+
+2. codragraph_impact({target: "validateSession", direction: "upstream", includeTests: true})
+   → callers: requireAuth, refreshToken
+   → tests: 0 (no test reaches validateSession)
+   ⚠ GAP
+
+3. codragraph_impact({target: "hashPassword", direction: "upstream", includeTests: true})
+   → tests: hashPassword.test.ts [direct], auth.integration.test.ts [via signup]
+   ✓ covered
+
+4. READ codragraph://repo/CodraGraph/processes
+   → 3 auth flows: SignupFlow, LoginFlow, PasswordResetFlow
+
+5. codragraph_impact for each flow's entry point with includeTests: true
+   → SignupFlow: covered (3 tests)
+   → LoginFlow: covered (2 tests)
+   → PasswordResetFlow: NO TESTS ⚠
+
+Findings:
+- 2 untested gaps: validateSession (symbol), PasswordResetFlow (entire flow)
+- Cheapest fix: one integration test calling resetPassword end-to-end would
+  close both gaps simultaneously (it's the entry point for the flow that
+  also calls validateSession).
+```
+
+## Output Format
+
+```markdown
+## Test Coverage Audit: <scope>
+
+### Gaps (no test reach)
+- **[symbol]** `validateSession` — called by 2 functions, no transitive test
+- **[flow]** `PasswordResetFlow` — entire flow untested
+
+### Covered (for reference)
+- `hashPassword` — direct + integration test
+
+### Suggested fixes
+1. Add integration test for `resetPassword` → covers PasswordResetFlow + validateSession
+2. ...
+```

package/vendor/tree-sitter-proto/bindings/node/index.js

@@ -1,7 +1,7 @@
-const root = require("path").join(__dirname, "..", "..");
+const root = require('path').join(__dirname, '..', '..');
 
-module.exports = require("node-gyp-build")(root);
+module.exports = require('node-gyp-build')(root);
 
 try {
-  module.exports.nodeTypeInfo = require("../../src/node-types.json");
+  module.exports.nodeTypeInfo = require('../../src/node-types.json');
 } catch (_) {}

package/vendor/tree-sitter-proto/src/node-types.json

@@ -1142,4 +1142,4 @@
     "type": "}",
     "named": false
   }
-]
+]