[0xb007ab1e]

ADRs in a per-project sidecar DB, untouched by reindex

Fixes the silent loss of an ADR across a reindex. On main an ADR lives in the graph DB's project_summaries, which a reindex (format-change / forced-full / watcher startup) rebuilds or unlinks — so a decision written before or during publication is lost. The earlier lock-based approach narrowed the race but conflicted with the no-sleeps/no-timeout rules; this is the structural fix the reviewers steered toward (Alternative 1).

Design

• Per-project sidecar "<db>.adr.db" (its own SQLite file beside the graph DB), opened READWRITE|CREATE with busy_timeout=10000 + WAL, read/written by manage_adr. Index publication never writes ADRs — there is nothing to capture or re-apply, and no lock.
• One-time migration (adr_copy_legacy_once): an existing project_summaries ADR moves into the sidecar atomically under a single BEGIN IMMEDIATE (marker check + copy + marker insert), before any unlink/publish in the format-change and forced-full routes — preserve-and-abort on failure. A half-created sidecar falls back to the legacy row.
• Reads never write: query stores open the sidecar READONLY when it exists, else read the legacy row without creating anything.
• delete_project removes "<db>.adr.db" (+ -wal/-shm/-journal); a full cbm_remove_indexes wipe removes sidecars too.
• Artifact round-trip: export injects the sidecar's ADR into the exported graph DB; import restores it into the local sidecar when the local has no row for the project — cbm_store_adr_restore_from_graph_if_absent, ungated by the migrate marker, INSERT OR IGNORE so a local ADR is never clobbered (closes the round-4 edge case: a teammate who already indexed, marked sidecar, no ADR, still receives the artifact's ADR).
• Index scans exclude .adr.db centrally in cbm_is_project_index_db (all MCP loops + the CLI's cbm_list_indexes/count_db_indexes).

Tests

Full + delta route: an ADR written between the start of a reindex and publish survives; legacy row migrates before a forced-full/format-change with no prior read; half-created-sidecar fallback; delete_project removes the sidecar; artifact round-trip keeps the ADR; import restores into a marked-but-empty local sidecar without clobbering a local one.

Rebase note

Rebased onto current main (the branch had gone 619 commits stale). Conflicts resolved in store.c, pipeline.c, pipeline_incremental.c, mcp.c, README.md, and the memory-core baseline; the .adr.db index-scan exclusion was folded into the now-central cbm_is_project_index_db, and the delta publish reconciled with main's new doc-candidate dump_and_persist signature. memory-core baselines ratcheted to measured (pipeline.c 129, pipeline_incremental.c 130). Focused ADR suites (store_arch / artifact / pipeline / mcp) pass locally under ASan/UBSan; the network-gated incremental fixtures run in CI.

🤖 Generated with Claude Code

[github-actions]

Thanks for opening this — it has been seen, and it is queued.

This note is automated, but it is not a brush-off: it exists so you know where your PR stands instead of having to guess from silence.

Current review status: working through a backlog. 0.9.1-rc.1 is out, so the release freeze that held reviews is over — but it left a large queue of open pull requests behind it, and we are reading through them oldest-first. The background is in discussion #1144.

What that means for this PR, concretely:

• It will not be closed for inactivity. No stale bot touches pull requests here.
• It may still sit a while before a human reads it. That is on us, not on you.
• Older PRs are read first, so a recent one is not being skipped — it is behind a queue.

Things that will genuinely speed it up whenever review does happen:

• Keep it rebased on main — the tree is moving quickly right now, and a conflicting branch cannot be reviewed as the diff you intended.
• Get CI green, or say which failures you believe are pre-existing.
• Keep the change to one claim. Bundled features and refactors get split before they get merged, which costs you a round trip.
• Every commit needs a sign-off (git commit -s) — CI enforces DCO.

If this fixes a bug, a reproduction we can run is worth more than a description of the symptom.

Thanks for contributing, and sorry in advance for the wait.

[DeusData]

Thank you for #2314 and #2315. Silently losing an ADR is exactly the kind of bug nobody notices until the decision record is gone, and your root-cause write-up (a shared project_summaries row, early capture and late swap, in-process guards only) is precise. We appreciate the honest risk section too.

We'd like to go with the direction you named as Alternative 1: a separate per-project ADR store that a reindex never replaces. Here is why we prefer it over the lock:

• It removes the race instead of narrowing it. When the ADR doesn't live in the file a reindex regenerates, there is no capture, re-read or re-apply to keep in step, and no lock to coordinate across processes.
• The lock as written conflicts with two of our standing rules. We don't put sleeps or polling waits into the code, and we don't let a timeout decide an outcome. The 10 ms retry loop, with its 30 s fail-open, does both: a slow peer silently brings the data loss back.
• The re-apply happens after the swap. For a moment the published DB shows the stale ADR, and if the re-apply write fails, the rescued ADR is lost with only a log line. An ADR deleted during the reindex would also come back from the early capture.

What we'd look for in the reworked PR:

1. ADRs stored in their own file beside the project DB (your <project>.adr.db naming is fine), read and written by manage_adr, and never touched by index publication.
2. A one-time migration: an existing ADR in project_summaries moves to the new store the first time it is read or written, and the old row is no longer used as the source of truth. Existing indexes must keep their ADRs without a reindex.
3. delete_project removes the ADR store with the project, or keeps it deliberately and says so. Please pick one and document it.
4. Tests: an ADR written between the start of a reindex and its publish survives (your hook-based test adapts directly); an ADR created before upgrading is migrated and still readable after a reindex; delete behaves as documented.
5. The early-capture and re-apply code in the pipeline can then go away, which makes publication simpler.

If you'd rather not take on the larger change, tell us and we will pick it up ourselves, crediting your analysis and test. Either way, thank you. This was a careful find.

[0xb007ab1e]

Reworked to Alternative 1 as you asked — thanks for the precise review; agreed on removing the race rather than narrowing it, and on the no-sleep/no-timeout rules.

• ADRs now live in a per-project <graph_db>.adr.db sidecar, read/written by cbm_store_adr_* (lazily-opened, cached connection), and never touched by index publication. No lock, no sleeps/polling, no timeout deciding an outcome. A :memory: store keeps ADRs in the graph DB (never file-swapped, so no race there).
• One-time migration: the first ADR read/write copies any legacy project_summaries row from the graph DB into the sidecar (INSERT OR IGNORE), so an index built before this change keeps its ADR with no reindex.
• delete_project now removes the sidecar (<db>.adr.db + its -wal/-shm/-journal) with the project — documented in the handler.
• The early-capture/re-apply is gone: capture_existing_adr, the saved_adr field, the generation.adr_content plumbing, the publish-time re-apply, and the test-only fail-capture hook. The reindex-delete path only unlinks the graph DB + -wal/-shm/-journal (cbm_remove_db_sidecars); .adr.db is a different file and is left intact — publication is simpler, as you noted.
• adr_update_sections' BEGIN IMMEDIATE read-modify-write now runs on the ADR connection, so its write lock actually covers the get/store.

Tests (file-based): an ADR seeded in the legacy project_summaries row is migrated on first read and survives a full reindex; an ADR write creates the sidecar, leaves the graph DB's project_summaries empty, and unlinking the sidecar removes the ADR. The existing #516 survive-reindex and incremental-preserve-ADR tests now validate the sidecar unchanged; the obsolete capture-failure test (and its hook) are removed.

Built clean under -Werror; pipeline (289) and store_arch mcp mcp_mutation_guard index_format (409) suites green locally. One caveat: I only have clang-format-19 locally (CI pins 20) — git clang-format shows my changed lines clean, but if CI's 20 reformats anything, point me at it and I'll match it.

[DeusData]

Thank you, @0xb007ab1e, for such a fast and thorough rework. You took the structural fix from your own "Alternatives" section, and the result is much simpler: publication no longer writes ADRs at all, the capture and re-apply machinery and its fail-capture hook are gone, and BEGIN IMMEDIATE now runs on the connection it is meant to protect. That is exactly the direction we hoped for.

A few things before we can merge, each with the reason:

1. Migrate before a rebuild can destroy the legacy row. Migration currently runs lazily, on the first ADR read or write. But the format-change route (pipeline.c around 1749-1758) and the forced-full route (around 1770-1775) unlink the old generation, and a full rebuild publishes a fresh project_summaries. On an upgrade whose first action is a full reindex (a format bump, a forced full, or the watcher's startup reindex), the ADR is therefore lost before anything copies it. Could you migrate the legacy row into the sidecar at the start of routing, whenever an existing generation is present and before any unlink or publish, and preserve and abort if that fails? A done-marker in the sidecar (for example an adr_meta row) would make the migration truly one-time. Today it re-runs on every new connection and could bring back a deleted ADR from a delta-cloned legacy row.
2. Lock behaviour of the sidecar. Please open it the way the graph store is opened, with PRAGMA busy_timeout = 10000 and journal_mode = WAL (the bare sqlite3_open in store.c around 9694). Without them, a second process's write fails immediately with SQLITE_BUSY, and a read during a commit reports "no ADR". That is precisely the cross-process case this PR exists for.
3. Reads must not write. Query-only stores also carry db_path, so manage_adr get, index_repository's adr_present and GET /api/adr currently create <db>.adr.db. On a read-only cache, a legacy ADR that used to be readable now errors out. For reads, please open the sidecar SQLITE_OPEN_READONLY if it exists, and otherwise read the legacy row from the graph DB without migrating.
4. Path helper. Please build the sidecar path through cbm_path_for_file_api with a 4096-byte buffer, like store_open_internal. On Windows that adds the long-path \\?\ prefix; without it, a long cache path opens the graph but not the ADR.
5. Memory-core gate. store.c goes from 358 to 359 raw allocator sites against a baseline of 358, so make -f Makefile.cbm lint-memory-core will fail. adr_db_path is written but never read, so dropping the field and its free fixes it. Lowering the baselines for pipeline.c (to 129) and pipeline_incremental.c (to 134) in the same change is welcome.
6. The ADR should travel with the exported artifact. The team-shared .codebase-memory/graph.db.zst used to carry the ADR in project_summaries, so a teammate's first index started with the team's decisions. With the sidecar that silently stops. Please carry it across: write the sidecar's ADR into the exported DB, and restore it into the sidecar on import when no local ADR exists.
7. Tests. Please add:
   • (a) an ADR written from a pipeline test hook between the start of the reindex and publication survives, on both the full and the delta route;
   • (b) the upgrade order: seed a legacy row, run a forced-full or format-change reindex with no ADR read first, then read the ADR;
   • (c) delete_project through the MCP handler removes <db>.adr.db and its -wal/-shm/-journal, and a re-indexed project of the same name starts with no ADR;
   • (d) the artifact round trip keeps the ADR.
8. Docs and description. Please mention in the delete_project tool description and in the README that deleting a project also deletes its ADR, and update the PR description to the sidecar design. It still describes the lock and compat_fs.c.

A smaller note, not a blocker: the sidecar name ends in .db, so the CLI's cbm_list_indexes / count_db_indexes count it as an index. A one-line exclusion there would help.

Thanks again. The hard part is done, and this is close.

[0xb007ab1e]

Round 2 pushed — thank you for the precise, itemized review. All eight plus the minor:

1. Migrate before a rebuild. New cbm_store_adr_migrate_once runs at the start of both delete routes in pipeline.c (format-change and forced-full), before the cbm_unlink, and preserve-and-aborts (ABORT_PRESERVE_DB) on failure. It is one-time via an adr_meta migrated marker in the sidecar, so it never re-runs or resurrects a deleted row. Good catch on the delta-clone case. One extra subtlety I hit: routing's db_path is a staging path, so migration now targets the final path (staging suffix stripped) — otherwise the ADR landed in a discarded stage's sidecar; there's a test for it.
2. Lock behaviour. Sidecar opens via sqlite3_open_v2(RW|CREATE) + PRAGMA busy_timeout=10000 + journal_mode=WAL, matching the graph store (SQLite's own lock wait, no hand-rolled poll).
3. Reads must not write. cbm_store_adr_get reads the cached RW handle if one is open, else opens the sidecar SQLITE_OPEN_READONLY when the file exists, else reads the legacy graph row without creating anything. A query-only cache is never mutated.
4. Path helper. Sidecar path is built through cbm_path_for_file_api with a 4096-byte buffer.
5. Memory-core gate. Dropped the write-only adr_db_path field → store.c back to 358; lowered pipeline_incremental.c 144→134 and pipeline.c 134→131 (not 129 — migrate-before-delete adds two free(db_path) abort-branch sites; still down). lint-memory-core passes.
6. ADR travels with the export. cbm_artifact_export fetches the ADR from the sidecar (read-only) and injects it into the snapshot's project_summaries before compression; cbm_artifact_import restores it into the destination sidecar via migrate_once (INSERT OR IGNORE — never clobbers a local ADR).
7. Tests. pipeline_adr_written_during_reindex_survives (hook mid-reindex), pipeline_adr_legacy_migrates_before_forced_reindex (upgrade order, no prior read), tool_delete_project_removes_adr_sidecar (via the MCP handler; same-name re-index has no ADR), artifact_export_roundtrip_keeps_adr.
8. Docs. delete_project tool description + README note that deleting a project deletes its ADR. Minor: cbm_list_indexes/count_db_indexes now exclude *.adr.db.

Verified locally: -Werror clean, lint-memory-core passes, pipeline 289, store_arch mcp mcp_mutation_guard index_format artifact 475 (+4 skipped). Still only clang-format-19 here (CI pins 20) — git clang-format shows my changed lines clean; flag anything CI's 20 reformats and I'll match it.

[DeusData]

Thank you for round 2, @0xb007ab1e. This is a careful, thorough rework:

• Moving ADRs into the per-project sidecar removes the race rather than narrowing it, and deleting the capture and re-apply machinery made publication noticeably simpler.
• Reusing stage_root_length for the staging-to-final derivation was the right call. It recognises only the exact minted .stage.XXXXXX basename, so a real path containing .stage. is safe.
• You brought the memory-core baselines down in pipeline.c and pipeline_incremental.c while keeping store.c at 358. Appreciated.

Items 2, 3, 4, 5, 7c, 7d and 8 are done. A few small things before we merge:

1. The migrate-before-delete step fails open (pipeline.c around 1728-1731). cbm_store_open_path_query returns NULL for open failures as well as for a missing file, and on this route the final generation is known to exist. So if (!mig) return true; can let a rebuild publish over a legacy ADR it never moved. Suggested: if (!mig) return !cbm_file_exists(final_path);.
2. A deleted ADR can come back through the artifact. After migration, the legacy project_summaries row stays in the graph DB, and incremental and closure-repair clones keep carrying it. VACUUM INTO copies it into the snapshot. When the sidecar has no ADR, nothing is injected, the stale row ships, and a teammate's import restores it. Suggested: in snapshot_inject_adr, always DELETE FROM project_summaries first, then insert only when an ADR exists.
3. Make the one-time migration atomic (store.c around 9673-9768). Please wrap the marker check, the legacy copy and the marker insert in one BEGIN IMMEDIATE … COMMIT. Otherwise two processes migrating at once can re-copy a row the other just deleted. It would also help if cbm_store_adr_get fell back to the legacy graph row when the sidecar exists but has no migrated marker, so a half-created sidecar never hides an ADR.
4. Tests.
   • Please add the delta / closure-repair variant of the ADR-written-mid-reindex test.
   • Pin the route in both new pipeline tests with cbm_pipeline_incremental_test_last_route() (FORCED_FULL, and CLOSURE_REPAIR for the delta one), so they stay bound to their routes if routing changes.
   • The preserve-and-abort path on migration failure lost its test when the old hook went away. Putting a directory at <db>.adr.db should make it fail deterministically with no hook: assert CBM_PIPELINE_ABORT_PRESERVE_DB and that the old generation is intact.

Nits, take them or leave them:

• Give the read-only sidecar handle the same 10 s busy timeout.
• adr_sidecar_path should compare (size_t)n >= raw_sz rather than against an (int) cast.
• In delete_project, remove the sidecar only once the graph DB unlink has succeeded, and size adr_path like path plus the suffix.
• is_project_db_file (mcp.c) and the cross-repo cache scan could skip *.adr.db the way the CLI listing now does.
• In the PR body, "migrated on first access" now means "on first write or before the next rebuild".

Thanks again. This is close, and the design is exactly where we wanted it.

[0xb007ab1e]

Round 3 pushed — thank you again for the depth here.

Correctness

1. Fail-open fixed. adr_migrate_before_delete now returns !cbm_file_exists(final_path) when the query open returns NULL, so a real open failure preserves-and-aborts instead of publishing over an un-migrated ADR.
2. No resurrection via the artifact. snapshot_inject_adr always DELETE FROM project_summaries first and inserts only when an ADR is present, so a no-ADR export ships an empty table and a lingering legacy row can't ride along.
3. Atomic migration + half-created fallback. adr_copy_legacy_once wraps the marker check, copy, and marker insert in one BEGIN IMMEDIATE … COMMIT (re-checking the marker under the lock; ROLLBACK→ERR on failure). cbm_store_adr_get now, when the sidecar exists but is unmarked, falls back to the legacy graph row so a half-created sidecar never hides an ADR.

Tests

• Both survival tests are route-pinned (FORCED_FULL and CLOSURE_REPAIR) via cbm_pipeline_incremental_test_last_route().
• pipeline_adr_migrate_failure_preserves_generation: a directory at <db>.adr.db fails migration deterministically (no hook) → asserts CBM_PIPELINE_ABORT_PRESERVE_DB and an unchanged node count.
• Extra edge regressions I added while hardening: an export with a deleted ADR does not resurrect the legacy row on import; an import does not clobber a local ADR (INSERT OR IGNORE); and a half-created sidecar falls back to the legacy row.

Nits — all applied: the read-only handle gets the 10 s busy timeout; adr_sidecar_path compares (size_t)n >= raw_sz; delete_project removes the sidecar only after the graph unlink succeeds and sizes the buffer as the graph path plus the suffix; is_project_db_file skips *.adr.db. PR description updated to "migrated on first write or before the next rebuild."

Verified locally: -Werror clean, lint-memory-core passes, and the ADR/sidecar suites (store_arch, pipeline, mcp, artifact) pass with zero failures under ASan/UBSan. (The monolithic make test also surfaces pre-existing LSAN leaks in the unrelated test_extraction/test_parallel spill suites — untouched by this PR and absent from every ADR/sidecar path.)

If any other maintainers or contributors want to weigh in on the sidecar approach, the migration ordering, or edges I might have missed, I'd welcome the input — happy to adjust.

[DeusData]

Thank you, @0xb007ab1e. Round 4 closes every item we raised, and in the way we'd have written it ourselves: the fail-closed open, the DELETE-first snapshot, one BEGIN IMMEDIATE covering marker, copy and marker insert, and a fallback so a half-created sidecar never hides an ADR. The directory at <db>.adr.db is a neat, hook-free way to make migration fail deterministically, and pinning both survival tests to their routes means they can't silently turn into full rebuilds.

One edge case is left, in import. The restore goes through cbm_store_adr_migrate_once, which does nothing once the local sidecar is marked, and any earlier rebuild or ADR write sets that marker. So a teammate who has already indexed the project and has no local ADR gets nothing from the artifact's ADR (your artifact_import_does_not_clobber_local_adr comment notes this too). On main, import replaced the whole DB, so the shared ADR always came through.

We'd like import to copy the artifact's ADR into the sidecar whenever the local sidecar has no row for the project, while still never overwriting a local one. A test would pin it: index the destination first (marked, no ADR), import an artifact carrying ADR "A", and expect "A". Everything else is ready. Thanks again for sticking with this through four rounds; the sidecar design came out clean.

[0xb007ab1e]

Done — thank you, that was the right call.

Import no longer relies on the marker-gated migrate-once. It now uses a new cbm_store_adr_restore_from_graph_if_absent: it copies the artifact's ADR from the imported graph DB's project_summaries into the sidecar with INSERT OR IGNORE — so a project the sidecar has no row for is filled, a local ADR is never overwritten, and it runs regardless of the migrated marker. So a teammate who already indexed the project (marked sidecar, no ADR) now receives the shared decision record, matching main's whole-DB-replace behavior. store.c factors the row copy into adr_copy_rows, shared by the one-time legacy migration and the ungated restore.

Test as you specified — artifact_import_restores_adr_when_local_absent: index the destination first (marked sidecar, ADR absent), import an artifact carrying ADR "A", expect "A". The existing no-clobber and fresh-roundtrip tests still pass, plus a :memory: no-op unit for the new entry point.

Verified locally: -Werror clean, lint-memory-core passes, ADR/sidecar suites (store_arch, pipeline, mcp, artifact) 455 passed / 0 failed under ASan/UBSan.

[DeusData]

Thank you, @0xb007ab1e. Round 5 is exactly the policy we asked for, and it verified cleanly on macOS: 1,375 tests pass merged with current main, lint-ci and the ratchet are clean, and both policy tests go red without their fix. We were ready to approve, but CI found one real Windows problem.

On windows-latest (run 36416318776, test-windows 2/2), both new import tests fail:

level=error msg=artifact.import err=rename_to_cache
FAIL tests/test_artifact.c:312: cbm_artifact_import(g_repo, import_db) == -1, expected 0 == 0
FAIL tests/test_artifact.c:356: cbm_artifact_import(g_repo, import_db) == -1, expected 0 == 0

Our reading: both tests import while the destination graph DB still exists (and may still be open). Windows refuses to rename over an existing or open file, so rename_to_cache fails there, while POSIX rename replaces it silently. In production, try_artifact_bootstrap (src/mcp/mcp.c) only imports when the graph DB file is missing. So the realistic shape is: an existing sidecar with the marker set, and no graph DB.

The smallest fix is probably in the tests: close any store handle and remove the destination graph DB before calling cbm_artifact_import. That keeps the sidecar and its marker, so the "marker already set" case is still covered. If you think import should also work over an existing DB, that would be a production change and we should talk about it first.

Once Windows is green, we'll approve and merge. The three small nits from our verification (a silent failed restore in artifact.c, a misplaced doc comment in store.c, a dead marker insert) we'll handle ourselves in a follow-up, so please don't spend a round on them. Thanks again for sticking with this one.

[0xb007ab1e]

Fixed — thanks for the precise diagnosis, that was exactly it.

Both new import tests now remove the destination graph DB (and its -wal/-shm/-journal) before calling cbm_artifact_import, while leaving the sidecar and its migrated marker in place. That matches production — try_artifact_bootstrap only imports when the graph DB is missing — so the rename no longer targets an existing file, which is what windows-latest rejected. The "marker already set, no local ADR" case the tests exist to cover is unchanged.

No production change — I agree import over an existing DB isn't the right shape, so I kept it test-only. Verified locally: -Werror clean, the artifact suite passes (artifact_import_restores_adr_when_local_absent and artifact_import_does_not_clobber_local_adr both green). Over to Windows CI.

Thanks for handling the three nits in a follow-up.

[0xb007ab1e]

Gentle check-in, no rush. The Windows fix (232730c) is green now — the PR workflow passed including test-windows, and DCO + CodeQL SAST are green — so from your last note ("once Windows is green, we'll approve and merge") I think this is ready whenever it's convenient.

Is there anything else you'd like me to address before approval? Happy to adjust. And thanks again for the thorough reviews — the sidecar design is much better for them.

[0xb007ab1e]

Rebased onto main (was behind by a batch of merges, so the PR had gone conflicted). Force-pushed 7b3c0f59.

Only one real conflict, in src/cli/cli.c: main refactored the .db detection into cbm_is_project_index_db(), so I folded the ADR-sidecar exclusion onto that helper at the list/count sites (the remove-all path keeps helper-only, so it still cleans up sidecars). range-diff confirms that plus the README's auto-picked async line are the only deltas from the version you last reviewed — every store/pipeline/artifact/test hunk reapplied cleanly.

Local validation on the rebased head:

• build -Werror clean, lint-memory-core clean
• all 13 ADR sidecar tests pass under ASan/UBSan, 0 leaks / 0 UBSan / 0 FAIL
• full suite: the only failures are the pre-existing environment-dependent test_cli install/uninstall cases — identical set on a clean main build here (0 rebase-introduced), so nothing new from this change

Should be mergeable once the review's cleared whenever it's convenient. Thanks again for the reviews.

[DeusData]

Thanks for addressing the Windows import-test setup and for the subsequent rebase. I have read the green-Windows update and your follow-up. Rechecking the revised head and making the landing decision are now maintainer-side steps; no additional contributor work is requested here.

[0xb007ab1e]

Rebased onto current main (the branch had gone 619 commits stale) and re-pushed as 001fbe26.

The round-4 edge case (import must restore the artifact's ADR into a marked-but-empty local sidecar) was already addressed in this commit: import calls cbm_store_adr_restore_from_graph_if_absent (ungated by the migrate marker, INSERT OR IGNORE), pinned by artifact_import_restores_adr_when_local_absent and artifact_import_does_not_clobber_local_adr.

Conflict resolution of note: main had centralized the index-file filter into cbm_is_project_index_db, so the .adr.db exclusion now lives there (covering the MCP scan loops + the CLI's cbm_list_indexes/count_db_indexes — the earlier CLI note), and the per-site helpers were dropped; cbm_remove_indexes still removes sidecars on a full wipe. The delta publish was reconciled with main's new doc-candidate dump_and_persist signature. memory-core baselines ratcheted to measured (pipeline.c 129, pipeline_incremental.c 130).

Focused ADR suites pass locally under ASan/UBSan (store_arch/artifact: round-4 + sidecar; pipeline: full+delta reindex-survival + migration; mcp: delete-sidecar). The network-gated incremental fixtures run in CI.

[DeusData]

Thank you for the October 22 refresh and for spelling out the marked-but-empty import case, centralized sidecar exclusion, and preservation tests. The revised head is now waiting on our review; no repeat rebase is requested. Sorry for the delay—I’ll follow up soon.

[DeusData]

Thanks again, @0xb007ab1e. Main moved under this branch (four of the files you touch changed upstream), so we merged current main into your branch with a plain signed-off merge commit (8cfefa6). There were no conflicts and your commits are unchanged; this just lets CI re-validate the combination. If you push again, please pull first so the merge commit is kept. We will merge once the required checks are green.

[DeusData]

Thanks again, @0xb007ab1e. The checks on your branch came back green, but another change touching tests/test_pipeline.c landed on main after that run started, so to keep the green honest we merged current main into your branch once more (one signed-off merge commit, d07f6d6; your change is untouched). We will merge as soon as the required checks are green on it. Please pull before pushing again.

[DeusData]

Thanks again, @0xb007ab1e. Several other pull requests landed on main this evening, including changes in files this one also touches, so we merged current main into your branch once more (one signed-off merge commit, 04cb937; your changes are untouched). That keeps the required checks honest against today's tree; we will merge once they are green. Please pull before pushing again.

[DeusData]

Thank you for your patience, @0xb007ab1e. CI went green on this branch, but tonight's merges on main touched src/mcp/mcp.c, src/pipeline/pipeline_incremental.c and their tests, which this pull request also changes, so that green no longer covered today's main. We merged current main into the branch once more (one merge commit, 791e378; your changes are untouched) and will merge once the fresh checks are green. Please pull before pushing again.

[DeusData]

Thank you for your patience, @0xb007ab1e. This evening #2305 landed on main and added new tests in tests/test_pipeline.c at the same spot as yours, so the files conflicted. We merged current main into your branch (one merge commit, 8fae39e) and kept both sets of tests unchanged; the rest of your change is untouched. We will merge once the fresh checks are green; please pull before pushing again.

[DeusData]

Sorry, @0xb007ab1e, our merge of main earlier this evening broke the build of tests/test_pipeline.c on this branch. Both sides had added tests at the same spot, and joining them lost a few closing lines, so one test function was left open. dda8f8a rebuilds the file as main plus exactly your changes to it (the diff against main is identical to your own change), and it compiles cleanly with the full test flags. Nothing else changed. Please pull before pushing again.

[DeusData]

Thank you for your patience, @0xb007ab1e. A pull request that merged into main a few minutes ago (#2290) changes src/cli/cli.c, which this pull request also changes, so the CI run in progress here could no longer vouch for today's main. We merged current main into your branch once more (one merge commit, b66ac84; it merged cleanly and your own change is untouched) and started a fresh run. We will merge once the required checks are green. Please pull before pushing again.

[DeusData]

Thank you for your patience, @0xb007ab1e. A pull request that merged into main a few minutes ago (#2769) changes src/pipeline/pipeline.c, which this pull request also changes, so the CI run in progress here could no longer vouch for today's main. We merged current main into your branch once more (one merge commit, 0947903; it merged cleanly and your own change is untouched) and started a fresh run. We will merge once the required checks are green. Please pull before pushing again.

[DeusData]

Thank you for your patience, @0xb007ab1e. A pull request that merged into main a few minutes ago (#2600) changes src/mcp/mcp.c, which this pull request also changes, so the CI run in progress here could no longer vouch for today's main. We merged current main into your branch once more (one merge commit, 9f70764; it merged cleanly and your own change is untouched) and started a fresh run. We will merge once the required checks are green. Please pull before pushing again.

[DeusData]

Thank you for your patience, @0xb007ab1e. A pull request that merged into main tonight (#2601) changes src/pipeline/pipeline_incremental.c, which this pull request also changes, so CI on this branch could no longer vouch for today's main. We merged current main into your branch once more (one merge commit, 218123b; it merged cleanly and your own change is untouched) and started a fresh run. We will merge once the required checks are green. Please pull before pushing again.

[DeusData]

Thank you for your patience, @0xb007ab1e. Main has moved since the last CI run on this branch, and some of the new commits change src/cli/cli.c, src/mcp/mcp.c and src/pipeline/pipeline_incremental.c, which this pull request also changes, so that run can no longer vouch for today's main. Separately, the Windows leg of that run hit our 15-minute per-suite limit on a slow runner while every test was passing; that is a runner-speed issue on our side, not your change. We merged current main into your branch (one merge commit, 359bd2f; it merged cleanly and your own change is untouched) and started a fresh run. We will merge once the required checks are green. Please pull before pushing again.