How to Contribute to DeusData codebase-memory-mcp: A Complete Guide for C Developers

Fork the repository, run scripts/build.sh and scripts/test.sh, then submit signed-off commits following the conventional-commit style outlined in CONTRIBUTING.md.

The DeusData codebase-memory-mcp repository is a high-performance, pure-C knowledge-graph engine that indexes codebases using vendored tree-sitter grammars and exposes functionality via an MCP (Model Context Protocol) server. If you want to contribute to DeusData codebase-memory-mcp, you will work with a layered architecture spanning memory management, AST parsing, multi-pass indexing, and SQLite persistence. This guide walks you through the repository structure, build system, and submission standards using concrete examples from the source code.

Understanding the Repository Architecture

Before modifying code, map your change to the correct architectural layer. The project organizes logic into seven distinct layers that separate concerns from raw memory allocation to JSON-RPC server implementation.

Foundation Layer

The foundation layer provides low-level utilities used throughout the codebase. In src/foundation/arena.c, you will find the arena allocator that manages memory for graph nodes, while src/foundation/ also contains hash tables and platform abstractions. Changes here require extreme caution because they affect every subsequent module.

Discovery and Language Extraction

The discovery layer handles Git repository scanning and language detection. The entry point is src/discover/discover.c, which parses .gitignore patterns and identifies source files. Language-specific logic resides in internal/cbm/lang_specs.c, where 64 bundled tree-sitter grammars are registered. To add or fix language support, you must update both the language spec and the corresponding AST walker in src/pipeline/pass_definitions.c.

Pipeline Processing

The pipeline layer executes multi-pass indexing through specialized passes. Key files include src/pipeline/pass_definitions.c for symbol discovery, src/pipeline/pass_semantic.c for type resolution, and src/pipeline/pass_infrascan.c for infrastructure scanning (Dockerfiles, Helm charts, etc.). Each pass registers itself in the main pipeline controller, allowing the system to build definitions, calls, imports, and HTTP route relationships sequentially.

Storage and MCP Interface

The store layer (src/store/store.c) persists the graph to SQLite with FTS5 full-text indexing. The MCP server (src/mcp/mcp.c) exposes 15 JSON-RPC 2.0 tools that external agents use to search, trace, and visualize architecture. When you add new query capabilities, you modify the store layer first, then expose them through the MCP tool dispatch table in src/mcp/mcp.c.

Setting Up Your Development Environment

You need a C compiler, make, and zlib installed. Optional dependencies include Node.js 22+ if you plan to work on the React/Three.js 3D graph viewer in graph-ui/package.json.

Clone and build the project using the provided scripts:

git clone https://github.com/DeusData/codebase-memory-mcp.git
cd codebase-memory-mcp
scripts/build.sh

The build script compiles the binary to build/c/codebase-memory-mcp. Verify your environment by running the test suite, which compiles with AddressSanitizer (ASan) and UndefinedBehaviorSanitizer (UBSan):

scripts/test.sh

This executes approximately 2,040 test cases across unit and integration modules.

The Contribution Workflow

Follow the ten-step process defined in CONTRIBUTING.md to ensure your pull request passes automated checks and code review:

1. Fork and branch – Create a feature branch from main using conventional-commit prefixes (feat/, fix/, docs/).
2. Commit with sign-off – Use git commit -s to satisfy the Developer Certificate of Origin (DCO) requirement.
3. Follow conventional commits – Format messages as type(scope): description (e.g., feat(pipeline): add Rust generic resolution).
4. Run quality gates – Execute scripts/lint.sh for clang-tidy, cppcheck, and clang-format validation.
5. Security audit – Run make -f Makefile.cbm security before pushing.
6. Reference issues – Link your PR to a pre-opened issue describing the bug or feature.
7. Push and create PR – CI automatically runs the full test matrix; maintainers review changes touching public APIs or indexing logic.

Adding Language Support or New Passes

To extend the engine for a new language or infrastructure pattern, modify the specification in internal/cbm/lang_specs.c, then implement the extraction logic in the appropriate src/pipeline/ file.

For example, to add a Helm chart detector in src/pipeline/pass_infrascan.c:

/* src/pipeline/pass_infrascan.c */
static bool cbm_is_helm_chart(const char *path) {
    return ends_with(path, ".helm.yaml");
}

/* Register in pipeline.c */
register_pass("helm_scan", cbm_is_helm_chart, extract_helm_chart);

Add a corresponding regression test in tests/test_pipeline.c:

TEST(infra_is_helm_chart) {
    ASSERT_TRUE(cbm_is_helm_chart("deployment.helm.yaml"));
    ASSERT_FALSE(cbm_is_helm_chart("main.c"));
}

Run scripts/test.sh to verify the new logic against the sanitizer-enabled build.

Testing and Quality Assurance

All contributions must pass the automated test harness and static analysis. The project enforces zero-tolerance for memory leaks or undefined behavior in the core engine.

• Unit tests – Add TEST(your_feature) blocks in tests/test_pipeline.c or create new test files in tests/.
• Sanitizers – The build system automatically injects ASan and UBSan flags when you use scripts/build.sh or scripts/test.sh.
• Linting – Use scripts/lint.sh to catch style violations and potential bugs before submission.
• Security – Run make -f Makefile.cbm security to execute security audit scripts on the codebase.

Summary

• DeusData codebase-memory-mcp is organized into seven distinct layers, from foundation allocators to the MCP server interface.
• Key files for contributors include internal/cbm/lang_specs.c for language definitions, src/pipeline/pass_definitions.c for indexing logic, and src/mcp/mcp.c for the server API.
• Build and test using scripts/build.sh and scripts/test.sh, which enforce AddressSanitizer and UndefinedBehaviorSanitizer compliance.
• Submission requirements include DCO sign-off (git commit -s), conventional commit formatting, and passing scripts/lint.sh and make -f Makefile.cbm security checks.

Frequently Asked Questions

What programming languages are used in DeusData codebase-memory-mcp?

The core engine is written in C for performance and memory safety, utilizing arena allocation and hash tables found in src/foundation/arena.c. The optional 3D graph user interface is built with React and Three.js as specified in graph-ui/package.json, requiring Node.js 22 or later.

How do I add support for a new programming language to the indexer?

Edit the language specification table in internal/cbm/lang_specs.c to register the tree-sitter grammar, then modify the relevant pass file in src/pipeline/ (such as pass_semantic.c) to handle AST extraction for that language. Finally, add a regression test in tests/test_pipeline.c and verify with scripts/test.sh.

What are the commit message requirements for contributing?

You must use conventional-commit style (e.g., feat(store): add FTS5 ranking boost) and include a Developer Certificate of Origin sign-off by using git commit -s. This is enforced by CI to ensure license compliance.

Which tests should I run before submitting a pull request?

Execute scripts/test.sh to run the full suite of approximately 2,040 tests with AddressSanitizer and UndefinedBehaviorSanitizer enabled. Additionally, run scripts/lint.sh for static analysis and make -f Makefile.cbm security for security auditing to ensure your contribution meets repository standards.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}