Files
Martin Vogel 453b21e680 ci(codeql): PR scan per language inside PR CI, full scan on main
Bring CodeQL back to pull requests as jobs of PR CI itself (needed by
ci-ok, no polling), narrowed to first-party code, while push to main,
the weekly run, the dry run and the release keep the full scan.

- codeql.yml: one leg per language (c-cpp, javascript-typescript,
  python, actions), scope in .github/codeql/codeql-config.yml. The full
  scan traces the whole build, vendored C included. The PR scan
  (light: true) analyses each selected language's whole first-party
  scope; c-cpp compiles the third-party objects before tracing
  (scripts/build.sh --vendored-only) and then traces the first-party
  build plus the vendored files the PR changes (--reuse-vendored
  --retrace-from, make -W). Diff-informed analysis (codeql-action
  v4.38.1, forced on for PR calls) only restricts reported alerts.
  The alert check moves into each leg and reads the analysed ref.
  Push and PR runs cancel superseded runs per language; dispatched
  runs never cancel. Compiler cache off so every compile is traced.
- pr.yml: a codeql job runs the legs of the selected codeql-* lanes;
  ci-ok needs it.
- select-lanes.sh: codeql-cpp/-js/-py/-actions lanes, selected by a
  change in their scope (any C/C++ incl. vendored; JS/TS, Python and
  workflows inside the config's paths minus paths-ignore) and by every
  full run (undeterminable diff, workflows, build, CodeQL machinery).
  --codeql-scope LANGUAGE prints a list's in-scope paths.
- codeql-retrace-vendored.sh: the vendored C files a PR changes (empty,
  never narrowing, when the diff cannot be determined).
- Makefile.cbm: cbm-third-party builds the vendored prod objects only.
- tests: the gate contract pins the new layout; the selector contract
  pins that a C change always selects the C scan, an undeterminable
  diff selects every language, and a vendored-only change retraces
  exactly the changed vendored files. Selector fixtures, ci-ok's job
  map, the replay's codeql-action failures (lane codeql-cpp) and the
  interface probes follow.

Signed-off-by: Martin Vogel <martin.vogel.tech@gmail.com>
2026-10-20 23:09:09 +02:00

8.8 KiB

Maintainers

This document defines how maintainer responsibility, review routing, and operational authority work in this project.

codebase-memory-mcp is currently a user-owned repository. Because GitHub teams are not available here, all delegated ownership is expressed with individual GitHub handles.

Authority Model

Role Scope Authority in this project
Project owner Entire repository Final roadmap, security, release, workflow, and merge authority.
Release operator Dry-run and release preparation Prepares release notes, runs checklists, and operates delegated dry runs. Release publication remains owner-gated.
Area reviewer One technical area Reviews, tests, reproduces, and recommends merge for that area. Approval is advisory until the project owner approves.
Triage collaborator Issues and discussions Labels, deduplicates, reproduces, and requests information. This role has no merge or release authority.

The binding rule is intentionally simple: all pull requests require @DeusData approval before merge. MAINTAINERS.md routes review; it does not override .github/CODEOWNERS.

Project Owner

Handle Responsibilities
@DeusData Final authority for merge decisions, releases, security handling, CI policy, repository settings, and maintainer promotion.

Area Review Map

Review requests follow this map. Entries marked TBD are currently unassigned review areas for future co-maintainers.

Area Paths Advisory reviewers Owner gate
MCP protocol and tool surface src/mcp/, tests/test_mcp.c TBD @DeusData
CLI, install, update, editor integration src/cli/, src/git/, install.sh, install.ps1, tests/test_cli.c TBD @DeusData
Indexing pipeline and graph construction src/pipeline/, src/discover/, src/watcher/, tests/test_pipeline.c, tests/test_incremental.c TBD @DeusData
Language extraction and LSP resolution internal/cbm/, tools/, tests/test_*_lsp.c, tests/test_extraction.c, tests/test_grammar_*.c TBD @DeusData
Store, query, and graph buffers src/store/, src/cypher/, src/graph_buffer/, src/simhash/, src/semantic/, tests/test_store_*.c, tests/test_cypher.c TBD @DeusData
Foundation/runtime portability src/foundation/, vendored/, tests/test_* foundation coverage TBD @DeusData
Graph UI backend and frontend src/ui/, graph-ui/, tests/test_ui.c, tests/test_httpd.c TBD @DeusData
Tests, repro, smoke, and soak infrastructure tests/, tests/repro/, test-infrastructure/, scripts/test.sh, scripts/smoke-test.sh, scripts/soak-test.sh TBD @DeusData
Packaging and distribution pkg/, install.sh, install.ps1, server.json, glama.json, flake.nix, flake.lock, THIRD_PARTY.md, scripts/gen-third-party-notices.sh, scripts/gen-ui-licenses.py, release archive contents TBD @DeusData
Security and supply chain SECURITY.md, docs/SECURITY-DISCLOSURE.md, scripts/security-*, scripts/*license*, scripts/*allowlist*, .github/workflows/codeql.yml, .github/workflows/scorecard.yml @DeusData only initially @DeusData
CI and release operations .github/workflows/, scripts/ci/, Makefile.cbm @DeusData only initially @DeusData
Governance and contribution policy .github/CODEOWNERS, MAINTAINERS.md, CONTRIBUTING.md, CODE_OF_CONDUCT.md, DCO, LICENSE, .github/pull_request_template.md, issue templates @DeusData only initially @DeusData

Operational Authority

Operational authority is stricter than code review authority.

Operation Current authority Project rule
PR validation (pr.yml, DCO, PR CodeQL scan) Automatic Anyone may trigger it by opening or updating a PR. Required checks must pass.
Dry run (dry-run.yml) @DeusData Delegated release operators may run dry runs after promotion. Dry-run delegation does not imply release authority.
Smoke/soak/repro manual runs @DeusData Area reviewers may operate these runs when delegated for diagnosis. Results are advisory.
Release workflow (release.yml) @DeusData only Owner-only until a release operator is explicitly promoted. Publishing, replacing releases, and tag movement remain owner-gated.
Package registry publishing @DeusData only Owner-only initially because registry credentials and public packages are irreversible operational surfaces.
Security advisory handling @DeusData only Do not delegate across advisories. Keep private reports isolated.
Workflow, ruleset, CODEOWNERS, and branch protection changes @DeusData only Owner-only because these define authority itself.

Release Preparation Checklist

Release preparation is a checklist-driven operation. A release is not ready until each required gate is green or explicitly waived by the project owner in the release notes.

  • dry-run.yml completes successfully with the release candidate commit.
  • Local performance benchmarks are run on the release operator's machine using the release candidate binary and CLI indexing, not test-only shortcuts.
  • scripts/benchmark-index.sh records results for the Linux kernel and for at least one large open-source project per supported Hybrid LSP family.
  • Benchmark results are compared against the previous release's benchmark logs using the same machine class, same repository revisions, same indexing mode, and same benchmark script when available.
  • Indexing time must not materially regress compared with the previous release. An unexplained slowdown greater than 15% on the same benchmark input is a release blocker until investigated or explicitly owner-waived.
  • Node and edge counts must not materially diverge from the previous release unless the release intentionally changes extraction behavior. Unexpected graph-size shifts require investigation before publishing.
  • Benchmark logs, repository revisions, binary version, machine details, and release decision are retained with the release preparation notes.

The current Hybrid LSP release benchmark matrix is:

LSP family Required large OSS benchmark
C / C++ Linux kernel
Go Kubernetes
Python CPython or Django
TypeScript / JavaScript / JSX / TSX TypeScript or VS Code
PHP Laravel framework
C# Roslyn
Java Spring Framework or Elasticsearch
Kotlin Kotlin compiler or Ktor
Rust Rust compiler

The matrix may be updated by PR as the project evolves, but every supported Hybrid LSP family keeps at least one large OSS indexing benchmark before a release is published.

Repository access follows the same authority model:

  • Triage is the default collaborator role for issue-only delegation.
  • Write access is reserved for collaborators whose operational access has been approved by @DeusData.
  • Release authority is separate from code review authority.
  • Protected branches, required code-owner review, required status checks, and protected release environments are part of the project control model where GitHub supports them.

Promotion Path

Promotion is gradual, explicit, and reversible.

Stage Requirements Capabilities
Trusted contributor Focused PRs, clean DCO, responsive review cycles. No elevated access.
Triage collaborator Consistent issue reproduction and respectful scope control. Issue triage and review requests.
Area reviewer Sustained, technically accurate reviews in one area. Advisory review listing in this file.
Release operator Proven reliability on dry runs, packaging, and release checklists. May run delegated dry runs and prepare releases.
Full maintainer Long-term trust across code, security, release, and governance. Only after explicit owner decision and updated policy.

Maintainer promotions are recorded in this file. Binding authority changes are recorded in .github/CODEOWNERS and repository settings.

High-Risk Change Rules

These changes always require project-owner review, even if an area reviewer approves:

  • MCP tool behavior, tool outputs, or protocol capabilities.
  • New process execution, shell invocation, network access, or file access.
  • CI, release, package publishing, installer, or updater changes.
  • Vendored dependency changes, generated grammar changes, or license policy.
  • Security disclosure process, advisories, allowlists, and audit scripts.
  • Repository governance, branch protection, CODEOWNERS, or maintainer roles.

Review Expectations

  • Keep PRs scoped to one issue or one logical change.
  • Reproduce bugs with a failing test before fixing.
  • Treat area-reviewer approval as a technical recommendation, not final merge authority.
  • Do not self-approve high-risk changes.
  • Resolve conflicts of interest by asking another reviewer and the owner.