feat: Schema Linting Engine for naming conventions, missing indexes, and cross-dialect consistency

[Lazialize]

Problem

The current strata validate checks structural integrity of schemas (foreign key references, duplicate ENUM values, etc.), but does not enforce quality rules such as naming conventions, missing indexes, or cross-dialect type consistency. In large projects, naming inconsistencies and performance risks are easily overlooked.

Proposed Solution

Extend SchemaValidatorService with a linting layer. Add a lint category to the existing validation (errors/warnings) system, accessible via strata validate --lint or a dedicated strata lint command.

Lint Rules to Implement

Rule ID	Category	Description
naming/table-case	Naming	Table names must be snake_case
naming/column-case	Naming	Column names must be snake_case
naming/index-prefix	Naming	Index names must have idx_ prefix
perf/fk-index	Performance	Foreign key columns must have an index
safety/nullable-fk	Safety	Warn on nullable foreign key columns
safety/ambiguous-default	Safety	Nullable columns should have explicit default values
consistency/cross-dialect-type	Consistency	Suggest dialect-agnostic alternatives for DialectSpecific types

Implementation Plan

1. New module: Create src/db/src/services/schema_linter/

   • mod.rs — SchemaLinterService (rule registration and execution)
   • naming_rules.rs — Naming convention rules
   • performance_rules.rs — Performance rules (FK index checks)
   • safety_rules.rs — Safety rules
   • consistency_rules.rs — Consistency rules

2. Rule interface: Trait-based design for extensibility

   pub trait LintRule {
       fn id(&self) -> &str;
       fn severity(&self) -> LintSeverity; // Error, Warning, Info
       fn check(&self, schema: &Schema, dialect: &Dialect) -> Vec<LintDiagnostic>;
   }

3. Configuration: Add a lint section to .strata.yaml for enabling/disabling rules and adjusting severity

   lint:
     rules:
       naming/table-case: warn
       perf/fk-index: error
       safety/nullable-fk: off

4. CLI integration: Add --lint flag to strata validate, or create a strata lint subcommand

5. Output: Extend the existing ValidationResult to include lint diagnostics in both text and JSON output

Files Affected

• src/db/src/services/schema_linter/ (new)
• src/core/src/core/config.rs — Add lint configuration
• src/cli/src/cli/commands/validate.rs — Display lint results
• src/cli/src/cli/cli.rs — Add CLI arguments

Alternatives Considered

• External tool integration: Considered integrating with external linters like eslint, but domain knowledge (dialects, constraints) makes a built-in solution more appropriate
• YAML Schema validation only: JSON Schema can check naming conventions, but cannot express semantic rules like FK index checks

Additional Context

• The existing SchemaValidatorService has 8 modular sub-validators, so the linting layer can follow the same pattern
• Corresponds to the "Schema Linting" section in ROADMAP.md