## Summary Phase 1 of the Knowledge Graph Indexer is directly linked to progress in the One Parser. Phase 1 for the One Parser represents capturing Definition nodes and Import nodes. On the indexer side, Definition/Import nodes must be linked to each other via relationships like `CLASS_TO_MODULE`, or to structural nodes defined in the indexer, Like `FileNode` or `DirectoryNode`. Here is a summary of all relationships captured in Phase 1: * Directory -\> child files/subdirectories * File -\> definitions it contains * File -\> symbols it imports * Definition -\> sub-definitions it contains (e.g. nested functions, methods in a class) ## Problems to Solve - **Language-Agnostic Indexing API**: Right now, the indexer is designed to create Ruby knowledge graphs only. The design of the indexer should be agnostic to language specific details e.g relationship mapping, and should instead have an explicit contract/API for where it _permits_ language-specific linking tasks. See https://gitlab.com/gitlab-org/rust/knowledge-graph/-/issues/47 - **Broad Language Support**: Support for all languages that have completed Definition/Import captures in the One Parser. This includes: Python, JS/TS, C#, Kotlin, Java. - **Robust Benchmarking**: Phase 1 needs measurements for performance/memory usage for both indexing and re-indexing against all major operating systems, and against different machine configurations (low/high resources). See https://gitlab.com/gitlab-org/rust/knowledge-graph/-/issues/6 - **Rigorous Testing of Realtime Re-indexing**: Re-indexing now works [E2E](https://gitlab.com/groups/gitlab-org/rust/-/epics/1), but still requires both benchmarking, correctness validation, and some preliminary design work to support future phases, like references.