Code-Intel Onboarding — New Repo

Code-Intel Onboarding — New Repo

Recipe for onboarding a new repo — e.g. the future id-132 client OKF bundle repo — into the cross-repo code-intelligence stack: GitNexus (call graph + cross-repo group), ccc (semantic code search), MemPalace (memory). Written from the canonical + docs-site wiring; repeat verbatim for each new member repo.

Prerequisites: repo cloned locally (sibling under ~/Documents/development/ by convention); npx gitnexus runnable; ccc CLI; MemPalace plugin/CLI.

1. Register + analyze in GitNexus

From the new repo’s root:

npx gitnexus analyze

First run registers the repo in ~/.gitnexus/registry.json, writes .gitnexus/ (including the project-local runner run.cjs), and generates the CLAUDE.md / AGENTS.md gitnexus block. On npm 11.x, if npx crashes during install (node.target is null), install once with npm i -g gitnexus then run gitnexus analyze (GitNexus issue #1939).

Verify: npx gitnexus list shows the repo with a registry name — note it, the group step needs it.

2. Add to the canonical-platform group + sync all members

The group lives at ~/.gitnexus/groups/canonical-platform/group.yaml (current members: app → canonical, docs → knowledge-hub-docs-site). From any indexed repo root (runner path relative to that repo):

node .gitnexus/run.cjs group add canonical-platform <groupPath> <registryName>  # e.g. okf <name from step 1>
node .gitnexus/run.cjs group sync canonical-platform    # rebuilds contracts.json over ALL member repos
node .gitnexus/run.cjs group status canonical-platform  # every repo must show OK

STALE rows mean that repo’s index is behind HEAD — re-run analyze in that repo, then group sync again. MCP equivalents: gitnexus group_list / group_sync({name: "canonical-platform"}). Cross-repo queries afterwards: group query canonical-platform "<concept>" and group impact canonical-platform --repo <groupPath> --target <symbol>.

3. ccc index

From the new repo’s root:

ccc init    # only if "Not in an initialized project directory"
ccc index

Refresh later with ccc index (or ccc search --refresh) after significant code changes. Optional: configure concept guides in .cocoindex_code/guides.yml before indexing (see the ccc skill).

4. MemPalace mine — pinned wing

Pin the wing explicitly — do not rely on the default (source-directory name), so the repo’s memories land in one stable wing regardless of checkout path:

mempalace_mine({ source: "<abs repo path>", wing: "<pinned-wing>", dry_run: true })   # inspect first
mempalace_mine({ source: "<abs repo path>", wing: "<pinned-wing>" })                  # then write

CLI: run mempalace instructions mine for the version-correct command shape.

Caveats:

• Check mempalace_status responds before mining — as of 02/07/2026 the MCP server was down (-32002); do not mine until it is back.
• Upstream #1665: mempalace_search with a wing filter errors (HNSW↔sqlite drift) — search WITHOUT the wing filter and filter results client-side. The pinned wing is for filing provenance, not for search filtering.

5. Repo-local CLAUDE.md

gitnexus analyze auto-writes the block between the gitnexus:start/gitnexus:end markers. Add a short hand-maintained section OUTSIDE those markers (so re-analysis does not overwrite it) covering: the registered repo name and the MUST-pass repo: param for MCP calls, the canonical-platform group commands, and — for prose-heavy repos — the scoping of impact/detect-changes discipline to code surfaces only. Mirror the docs-site CLAUDE.md “GitNexus — Code Intelligence (hand-maintained)” section.