Make the tool import existing ADR docs in a repository

[rikbosch]

What problem does this solve?

Most repositories contain existing ADR documentation that might be of interest codebase-memory.

Proposed solution

It would be nice if the initial project onboarding would import those docs as well.

Alternatives considered

No response

Confirmations

• I searched existing issues and this is not a duplicate.

[DeusData]

Thanks so much for this, @rikbosch 🙏 It fits naturally with the existing manage_adr tool, which already stores ADRs in the graph; we just don't bootstrap from what's already on disk yet. For a first cut we'd detect a conventional ADR location (docs/adr/, adr/, or MADR style NNNN_*.md filenames) and import them so get_architecture and manage_adr surface them.

Two quick questions: (1) auto detect, or a config key like adr_path? (2) one time import on first index, or keep them in sync via the watcher? If you have a preferred ADR tool (MADR or log4brains), let us know which to target first. PRs very welcome!

[rikbosch]

Maybe a combination? Scavenge most user paths line docs/adr or other known paths like **/adr/*.md?

I'd keep them in sync just like the rest of the code. The adr documents should be immutable, but they can be superseded by newer adr documents.

[DeusData]

This overlaps heavily with #507, which proposes the broader MADR multi-record support — including importing existing ADR records already present in a repo. Marking this duplicate and consolidating the discussion under #507 so the "import existing docs" piece is tracked as part of that work. Leaving this open for visibility for now. Thanks for raising it.

[DeusData]

Re-checked this under the stricter duplicate rule we are using now: this is related to #507, but it is not a 100% duplicate.

#507 is the broader Markdown/MADR support track. This issue is specifically about importing existing ADR documents during onboarding/indexing, so I am keeping it open as a distinct acceptance criterion and removing the duplicate label. We should still implement it in coordination with #507.