rowan + salsa incremental validation architecture

[avrabe]

Context

Rivet's current validation pipeline is a single-pass sequential process: parse YAML → build store → build link graph → validate. Every change requires a full recomputation. As Rivet scales to support cross-repo validation of 75+ repos (Eclipse SCORE scale), conditional validation rules, and change impact analysis, this architecture becomes a bottleneck.

The spar project (pulseengine/spar) already uses rowan for lossless CST and salsa for incremental computation. The same architecture powers rust-analyzer.

Design

Layer 1: rowan CSTs for new parsers

• StarlarkLanguage with ~30 SyntaxKind variants for MODULE.bazel subset
• Hand-written lexer + recursive descent parser emitting rowan GreenNode
• Lossless CST with full span info for diagnostic-quality error reporting
• Error recovery — partial parses still produce usable CST

Layer 2: salsa database for validation pipeline

• Incremental query groups: parse_artifacts → artifact_store → link_graph → evaluate_conditional_rules → validate
• File change invalidates only affected queries via salsa dependency tracking
• Conditional rules (if status == approved then field required) become tracked queries
• Impact analysis is free: "what salsa queries get invalidated" = "what artifacts are affected"

Layer 3: LSP readiness

• salsa database IS the language server backend
• Diagnostics have rowan spans → LSP Diagnostic with exact source locations
• Foundation for commercial VS Code extension

Rivet artifacts

• REQ-028, REQ-029
• DD-023, DD-024
• FEAT-046, FEAT-047, FEAT-048

References

• spar architecture: pulseengine/spar (rowan + salsa)
• rust-analyzer architecture: same pattern
• Conditional validation: introduce advanced local checks eclipse-score/docs-as-code#180
• Change impact: docs: Add versioned links eclipse-score/docs-as-code#314