CodeGraph helps a team connect a product task to requirements, code, checks and a release decision. This section covers the platform’s purpose, a useful first task and work with AI, then helps with connections and analysis.
Purpose and a first scenario
Why use CodeGraph alongside Git, an issue tracker and CI?
Those systems hold code, tasks and run results. Accepting a change requires connecting them: which requirement was implemented, which revision was tested, who reviewed a risk and what remains unchecked. CodeGraph keeps these connections and role results available as a task moves between people and agents.
Git, the tracker and CI keep their primary records. Available integrations depend on the installation. Start with one repository and a task from the scenario guide. The platform architecture overview explains the overall model in Russian.
How does CodeGraph relate to an agent that writes code?
A compatible agent performs actions. CodeGraph adds task context, responsibilities, the allowed work scope and a connection between results and checks. Digital employees represent product, development, architecture, security and QA roles. People set goals, access and acceptance conditions.
The team can see a prepared change separately from a missing review. An accepted handoff confirms the next role’s responsibility. Actual automated execution and its results are verified separately.
Why use a code graph when working with AI?
A code property graph (CPG) connects program symbols, calls and dependencies. For a method change, CodeGraph can investigate direct and transitive callers, including those in other files. These relationships help assemble task context and identify code to check.
For example, a team changes how a service calculates a limit. Impact analysis identifies callers of the method being changed. The developer uses that result to inspect related calls and choose regression tests. Structural pattern search helps find similar constructs to consider during the change. The analysis capability map and pattern search guide explain these tasks.
For questions about data propagation, open the dataflow guide. To check a vulnerability hypothesis, use the hypothesis system, which connects a hypothesis to its verification result and code evidence. The team gets concrete relationships and source positions to discuss, and the agent gets context for its next action.
What can a small pilot demonstrate?
Choose a task with an observable result: investigate change impact, check a security risk or connect a requirement to code and acceptance. Record the starting time costs and evaluation rules, run the scenario and compare results. One concrete scenario helps identify where the team saves time and gets a clearer result.
The analysis capability map helps choose a check. Read the hypothesis guide for code risks or the code review guide for a change. Measure the effect in your team; compare time spent investigating the task, preparing the change and checking the result.
Use the pilot benchmark to compare 5–10 tasks. The guide shows how to set baselines and success criteria, collect measurements, and generate a report recommending the next step for CodeGraph adoption.
Getting started
Where should I begin?
For an existing CodeGraph instance, follow the quick start: sign in, get project access, import a repository, check the graph and run a first task. To deploy a new instance, use the installation guide.
How do I update the CPG and review PRs or MRs automatically?
Connect your Git provider’s webhook: GitHub, GitLab, GitVerse or SourceCraft. These guides explain how to map a repository to a project, configure push and PR/MR events, and verify the graph update and review result. This connects two team tasks: keeping analysis context current and checking a change while it is under review.
How do I schedule audits and configure architecture control?
Configure an audit schedule with a cadence, time zone, service account and missed-run policy. Verify the first run in the job history and inspect its saved report.
Use the architecture control guide to describe components and allowed dependencies, choose rules and connect checks to CPG updates. This makes agreed component boundaries checkable against code changes.
Do I need every service for local exploration?
No. Start only the interfaces required by your task. A CLI analysis and an authenticated dashboard exercise have different dependencies. If startup fails, use the current troubleshooting guide to identify the required services and check their status.
Projects and graph freshness
Why must I select a project?
Project scope determines repository context, CPG location, authorization, memory, and evidence binding. The identifier selects the project. The server determines access from the authenticated request and resolves the allowed project context.
Why is a result empty or different from the source tree?
Confirm that the expected revision was indexed, the language is supported, exclusions are correct, and project synchronization is current. An empty query can mean “not found,” but it can also mean stale context, incomplete graph coverage, or a scope mismatch.
Analysis and evidence
Which analysis command should I use?
Use the analysis capability map: review for change-oriented findings, impact
for blast radius, patterns for structural search, hypothesis for CPG-backed security hypotheses,
threat-model for trust boundaries, and sbom for software composition and dependency analysis (SCA). Set up the CLI using the CLI guide. Run python -m src.cli --help and the selected subcommand’s --help before scripting it.
How do analysis results support a release decision?
Save the analysis result with the exact code revision and check scope. In a governed task, CodeGraph connects it to acceptance, review, AppSec, QA, documentation, traceability, runtime and financial-control evidence. The team can then see which release checks are complete and which remain to be performed.
Can CodeGraph apply generated fixes automatically?
Some workflows can propose or prepare changes. Treat generated changes like any other patch: inspect the diff, run focused and regression tests, review security impact, and keep rollback information. A suggestion enters the review and approval workflow before repository mutation or publication.
MCP and digital employees
Why is an MCP tool absent?
Tool visibility depends on the running server, active profile, owner policy, and client connection. Follow the MCP operator guide and inspect the live client catalog. The tool list identifies available names and schemas. A successful call confirms that specific tool works in the current profile and project context.
How should structured MCP arguments be passed?
Pass native arrays and objects, not JSON encoded inside strings. Use the identifiers and scope fields declared by the tool schema. Project, namespace, story and task scope are required only where the schema and operation contract require them. A lightweight service task can have no story. Do not pass raw database paths through agent-facing tools; the runtime resolves storage from the authorized project context.
What do digital employees authorize?
Each role performs its part of the work within the project access and agreed task scope. See governed digital employees for roles, task capsules, handoffs, and closure. Human approval applies only to its exact signed transition and scope.
Security and data handling
Can repository data be sent to an external LLM?
Only when the deployment’s policy, provider configuration, and data classification allow it. Review LLM security guide before enabling a provider. Keep secrets out of prompts, logs, command arguments, fixtures, and public documentation.
Is direct DuckDB access a supported integration?
Use project-scoped CLI, REST, MCP, ACP, or GoCPG interfaces for integrations. Choose the interface for your task: REST for an application, MCP or ACP for an agent, CLI for automation, or GoCPG for graph operations. Select the project or its CPG as described in that interface’s guide. See the REST API reference for request examples and the MCP operator guide to connect an agent.
Where should I report a suspected vulnerability?
Do not publish exploit details or secrets in a public issue. Email hello@codegraph.ru with the affected revision, description, impact assessment, and a minimal safe reproduction. Preserve relevant logs without credentials.
Failures and recovery
What information makes a useful support report?
Include the installed revision, operating system, interface, exact command or request shape, project scope, expected behavior, observed error, and a secret-free log excerpt. State whether the failure is reproducible and whether project context is fresh.
Should I retry a failed governed action with a different task ID?
Check the existing task status and the reason for failure first. If a result is already saved, continue from it. If execution was interrupted, follow the recovery instructions for that operation. Keeping the task ID connects the retry to the original task and its previous results.
Where do I look next?
Use troubleshooting for known operational symptoms, the scenario guide for task routing, and live CLI or MCP discovery for the installed contract. Current source and observed runtime behavior outrank archived examples.