Parent issue: Part of #89
Problem
The design intentionally reserves the term Metroid for the dialectical probe { m1, m2, c }. However, the codebase still contains residual references to "Metroid neighbor"/"Metroid subgraph" (especially in tests and comments), which can cause confusion and lead to incorrect assumptions during future development.
Goal
Confirm that the proximity graph is consistently referred to as "semantic neighbor" everywhere, and that the only remaining uses of "Metroid" are in the dialectical probe implementation (cortex/MetroidBuilder.ts and related query logic).
Acceptance Criteria
- No source or test file uses the term "Metroid" to describe the neighbor graph.
- No types, variables, methods, or object store names contain "Metroid" except for the dialectical probe concept.
- Tests are updated to use the new naming where applicable.
- The codebase compiles and tests pass.
Notes
This is primarily a naming and documentation cleanup task, but it’s critical for preventing future architectural confusion.
Parent issue: Part of #89
Problem
The design intentionally reserves the term Metroid for the dialectical probe
{ m1, m2, c }. However, the codebase still contains residual references to "Metroid neighbor"/"Metroid subgraph" (especially in tests and comments), which can cause confusion and lead to incorrect assumptions during future development.Goal
Confirm that the proximity graph is consistently referred to as "semantic neighbor" everywhere, and that the only remaining uses of "Metroid" are in the dialectical probe implementation (
cortex/MetroidBuilder.tsand related query logic).Acceptance Criteria
Notes
This is primarily a naming and documentation cleanup task, but it’s critical for preventing future architectural confusion.