This reference maps user questions to supported CodeGraph commands. It does not document every
class under src/analysis/ as a public SDK. Internal engines can change while a supported CLI,
REST, or MCP contract remains stable.
Choose a workflow
| Question | Starting point | Result to inspect |
|---|---|---|
| What changed, and what should a reviewer check? | python -m src.cli review --help |
Findings and review evidence for the selected diff. |
| What can this change affect? | python -m src.cli impact --help |
Dependency and blast-radius evidence. |
| Which security hypotheses are supported by the CPG? | python -m src.cli hypothesis --help |
Confirmed, rejected, and inconclusive hypotheses. |
| Where does a structural pattern occur? | python -m src.cli patterns --help |
Matches for the selected pattern and scope. |
| Which threats apply to the system boundary? | python -m src.cli threat-model --help |
Threat-model findings and mitigations. |
| Which dependency risks are present? | python -m src.cli sbom audit --help |
Software-composition findings for the current inputs. |
Run the command’s --help in the installed revision before automating flags. Availability through
MCP or REST depends on the active profile and current runtime registration.
Supported analysis surfaces
Review and change impact
python -m src.cli review combines change context with review-oriented analyzers. Use
python -m src.cli impact when the question is specifically about affected symbols, dependencies,
and regression scope. Neither result is a release approval: bind important conclusions to the
examined Git revision and preserve the supporting paths or findings.
See Code review for task-level guidance. Use the live impact
help for its positional method name and optional depth, database, and output fields.
Security analysis
python -m src.cli hypothesis evaluates vulnerability hypotheses against a CPG.
python -m src.cli threat-model addresses the broader system and trust boundary.
python -m src.cli sbom audit addresses components and dependencies. These are complementary evidence
sources; a clean result from one does not imply that the others passed.
See Hypothesis system, threat modeling, and SCA/SBOM.
Structural pattern search
python -m src.cli patterns is the supported starting point for reusable structural queries. A
match shows that the query found evidence in the selected scope; a missing match can also reflect
an incomplete CPG, unsupported language construct, exclusion, or stale project context.
See Pattern Search for setup and interpretation.
Internal engines
Some analysis components support other workflows but have no standalone user contract:
| Component | Internal boundary | Public use |
|---|---|---|
| Clone detection | src/analysis/graph_core/clone_detector.py |
No standalone CLI, API, or MCP surface; consume it through a supported analysis workflow. |
| Symbolic execution | src/analysis/dataflow/taint_support/symbolic_execution.py |
No standalone surface; it assists taint-path feasibility checks. |
| Control- and data-flow helpers | src/analysis/controlflow/ and src/analysis/dataflow/ |
Implementation details behind review and security features. |
| Autofix helpers | src/analysis/autofix/ |
Do not apply generated changes without diff review and tests. |
These paths help maintainers diagnose behavior. Third-party integrations use the documented public interfaces; internal classes, constructors, and return types may change with the implementation.
Evidence and limits
Analysis quality depends on the indexed revision, language coverage, project scope, configuration, and graph freshness. Record those inputs with any decision based on a finding.
- A finding enters the exploitability and business-impact review.
- An empty result records the configured scope and revision; review coverage and runtime context before recording the security decision.
- Generated fixes require normal code review, tests, security review, and revision binding.
- Direct DuckDB queries are a maintainer diagnostic boundary. Use the documented user interfaces for normal workflows.
- Live runtime discovery outranks static tool lists and screenshots.
For release decisions, combine analysis with acceptance tests and the accountable review, AppSec, QA, traceability, runtime, documentation, and financial-control lanes required by the task.
Verify an analysis result
Record the project, commit, command, configuration, and graph timestamp before interpreting the output. Inspect at least one finding back to its source location and confirm that the reported language and path coverage match the intended scope. After a change, rerun the same bounded command against a refreshed graph and compare finding identities rather than raw counts.
An empty finding list is meaningful only when parsing and graph coverage completed successfully. If coverage is partial or freshness is unknown, record the result as incomplete instead of clean.
Related guides
Use the scenario guide when you know the goal but not the command. For setup problems, consult troubleshooting. For agent-driven analysis, discover the active surface with the MCP operator guide.