[Medium] Scanner orchestration is duplicated in multiple registries

[coderabbitai]

Description

Span categories are manually maintained in at least two places: the scanner and the CST cursor map. This duplication creates maintenance overhead and increases the risk of these registries falling out of sync.

Priority

Medium

Details

Locations:

• src/parser/span_scanner.rs:22 – Scanner registry
• src/parser/cst_builder/tree.rs:13 – CST cursor map

Current state:

• Statement/span categories are defined and maintained separately in multiple locations
• Scanner calls, non-rule exclusions, and CST node wiring are manually coordinated
• Changes to category definitions must be applied in multiple places

Impact

• Maintenance burden: Category changes require updates in multiple registries
• Drift risk: Registries can fall out of sync, causing parsing or CST-building inconsistencies
• Code duplication: Violates DRY principle
• Coordination overhead: Developers must remember to update all locations when adding or modifying categories

Actionable Fix

Define one central statement-category registry and derive scanner calls, non-rule exclusions, and CST node wiring from it.

Approach:

1. Create a central registry/enum for statement categories
2. Derive scanner dispatch logic from the central registry
3. Derive non-rule exclusion lists from the central registry
4. Derive CST node wiring from the central registry
5. Remove manual duplication from existing locations

Benefits:

• Single source of truth for statement categories
• Automatic consistency across scanner and CST builder
• Easier to add or modify categories
• Reduces maintenance overhead
• Eliminates synchronisation risk

References

• PR: Add ADR: parser crate split for multi-consumer use #212
• Requested by @leynos

Requested by

@leynos

[traycerai]

Warning

Rate limit exceeded. Please try after 513197 seconds.