Artifact bootstrap is a no-op across clone paths (project name derived from absolute repo path)

[moofone]

Artifact bootstrap is a no-op across clone paths (project name is derived from the absolute repo path)

Problem

cbm_project_name_from_path derives the project name from the full normalized repo path. Two clones of the same repository at different paths therefore get different project names.

The shared artifact DB (.codebase-memory/graph.db.zst) is keyed by the exporter's project name. When a teammate bootstraps from it (try_artifact_bootstrap in src/mcp/mcp.c), the imported DB contains rows only under the exporter's project, so the importer:

• finds 0 file_hashes rows for their own project name → classify_files sees everything as new → full re-parse;
• bootstrap reconciliation (fix(artifact): reconcile imported hashes against git on bootstrap (1/3) #868) restamps 0 rows for the same reason.

In other words, artifact bootstrap currently only helps when the importing machine uses the same absolute repo path as the exporter — which is rarely true across teammates. This was discovered while benchmarking #867 (see "Explicitly deferred" there).

Scope

Pre-existing and independent of the #868/#869/#870 stack — those PRs make bootstrap cheap when the project names line up (same path, CI caches, container images with fixed paths). This issue tracks making the team-sharing case work too.

Possible directions (not prescriptive)

1. Key the artifact by a path-independent identity (e.g. repo basename + first-commit hash), and map it to the local project name at import.
2. Rewrite the project column during cbm_artifact_import (the importer knows its own project name at import time).
3. Store the exporter's project name in artifact.json and translate on read.

(2) looks smallest: import already byte-copies into a fresh cache DB, so an UPDATE ... SET project = ? over the copied rows right after the copy is contained and needs no schema/metadata changes.

Refs #867. Happy to take this on as a follow-up PR once the #868–#870 stack settles, if the direction above (or another you prefer) sounds right.

[DeusData]

Thanks for splitting this out from #867. Triage: artifact bootstrap correctness/performance bug under #593.

The path-derived project-name coupling does make the team-sharing case much weaker than intended. The smallest-looking direction is importer-side project-name translation after copying the artifact DB, but review should verify it cannot corrupt multi-project artifacts or stale metadata. Happy to track this separately from the #868-#870 stack.

[tenderfabric]

We encountered this independently while testing a build-once, reuse-on-another-machine workflow. An artifact exported at path A and imported at path B retains the exporter's path-derived project identity, so the importing project cannot address its rows.

Importer-side project-name translation after copying the artifact database looks like the appropriate fix. Would you welcome a focused PR from current main addressing #885?

Proposed scope and tests:

1. Export at path A, import at path B, and verify project-scoped rows are translated to the importing project identity.
2. Verify every affected project-scoped table and artifact metadata field remains internally consistent.
3. Verify a multi-project artifact cannot have unrelated projects renamed or corrupted.
4. Verify ambiguous, missing, or stale identity metadata fails conservatively without modifying the imported database.

We understand this addresses project identity only; cold-clone reuse performance remains separately governed by #867 and the #868–#870 work. Should this be implemented independently against current main, or wait for that stack to settle?

DCO-signed, single issue, and within the project's PR-size guidance. Happy to fit this under the #593 triage however you prefer.