feat(lang): rename concept_comparison to definition (v0.3.2)

Renames the `concept_comparison` keyword to `definition` across the
entire codebase for better readability and conciseness.

Changes:
- Tree-sitter grammar: `concept_comparison` node → `definition`
- Tree-sitter queries: highlights, outline, and indents updated
- Zed extension highlights.scm updated to match
- Lexer: `Token::ConceptComparison` → `Token::Definition`
- Parser: `ConceptComparisonDecl` rule → `DefinitionDecl`
- AST: `Declaration::ConceptComparison` → `Declaration::Definition`,
  `ConceptComparisonDecl` struct → `DefinitionDecl`
- All Rust source files updated (validate, names, convert, references,
  semantic_tokens, symbols, code_actions, hover, completion)
- `validate_concept_comparison_patterns` → `validate_definition_patterns`
- Example file and test corpus updated
- Spec docs: created SBIR-v0.3.2-SPEC.md, updated TYPE-SYSTEM.md,
  README.md, SBIR-CHANGELOG.md, SBIR-v0.3.1-SPEC.md

docs/README.md

@@ -51,7 +51,7 @@ Storybook v0.3 introduces a **compile-time type system** for stronger validation
 
 - **`species`** - Define base archetypes with default fields that characters inherit
 - **`concept` / `sub_concept`** - Algebraic data types with dot notation (`sub_concept Cup.Size { Small, Medium, Large }`)
-- **`concept_comparison`** - Compile-time pattern matching over concept variants
+- **`definition`** - Compile-time pattern matching over concept variants
 - **Template species inheritance** - Templates extend species for layered defaults (`template Person: Human { ... }`)
 - **Life arc field requirements** - `life_arc Career requires { skill: Number }` validates fields at compile time
 

docs/SBIR-CHANGELOG.md

@@ -11,6 +11,19 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ---
 
+## [0.3.2] - 2026-02-23
+
+### Changed
+
+**Keyword Rename:**
+- The `concept_comparison` keyword has been renamed to `definition`
+  - Old: `concept_comparison SkillLevel { ... }`
+  - New: `definition SkillLevel { ... }`
+  - No binary format changes required - this is a source-level rename only
+  - The Rust AST type `ConceptComparisonDecl` is renamed to `DefinitionDecl`
+
+---
+
 ## [0.2.0] - 2026-02-13
 
 ### Added

docs/SBIR-v0.3.1-SPEC.md

@@ -58,7 +58,7 @@ The Storybook Intermediate Representation (SBIR) is a binary format that represe
 3. **Life Arc Field Requirements** - Life arcs can declare required fields with type annotations
 
 **Breaking changes:**
-- TYPES section now populated with concept, sub_concept, and concept_comparison definitions
+- TYPES section now populated with concept, sub_concept, and definition declarations
 - Value discriminants renamed: Int→Number, Float→Decimal, String→Text, Bool→Boolean
 - Expression discriminants renamed: IntLit→NumberLit, FloatLit→DecimalLit, StringLit→TextLit, BoolLit→BooleanLit
 - TEMPLATES section extended with species_base field
@@ -385,7 +385,7 @@ concept Cup
 sub_concept Cup.Type { Small, Medium, Large }
 sub_concept Cup.Material { weight: 100, fragile: true }
 
-concept_comparison CupDefaults for Cup matching Cup.Type {
+definition CupDefaults for Cup matching Cup.Type {
     Small { capacity: 200 }
     Medium { capacity: 350 }
     Large { capacity: 500 }
@@ -1051,7 +1051,7 @@ enumerations used primarily for calendar patterns and simple value sets.
 - Value/expression type renames aligned with Storybook language terminology
 
 **Breaking Changes:**
-- TYPES section (Section 3) now populated with concept, sub_concept, and concept_comparison definitions
+- TYPES section (Section 3) now populated with concept, sub_concept, and definition declarations
 - Value discriminant names changed: Int→Number, Float→Decimal, String→Text, Bool→Boolean (wire format unchanged)
 - Expression discriminant names changed: IntLit→NumberLit, FloatLit→DecimalLit, StringLit→TextLit, BoolLit→BooleanLit (wire format unchanged)
 - TEMPLATES section: added `species_base: Option<StringRef>` field before `strict`

docs/TYPE-SYSTEM.md

@@ -21,7 +21,7 @@ The Storybook type system is a **declarative, pure functional DSL** for defining
 - **`character`/`institution`/`location`**: Typed value instances
 - **`concept`**: Base type declarations for pattern matching
 - **`sub_concept`**: Enumerated and typed subtypes (tagged union members)
-- **`concept_comparison`**: Compile-time pattern matching over subtype combinations
+- **`definition`**: Compile-time pattern matching over subtype combinations
 - **`action`**: Signature declarations for runtime-implemented operations
 
 This system enables static validation of entity relationships, behavior conditions, and data structures while maintaining readability for narrative design.
@@ -415,7 +415,7 @@ concept Vendor
 **When to use:**
 - When you need a type that will have multiple variants or aspects
 - To create type-safe enumerations through `sub_concept`
-- As a base for compile-time pattern matching via `concept_comparison`
+- As a base for compile-time pattern matching via `definition`
 
 ---
 
@@ -530,13 +530,13 @@ Sub_concepts are **tagged union members**, not inheritance:
 
 ---
 
-### `concept_comparison` - Compile-time Pattern Matching
+### `definition` - Compile-time Pattern Matching
 
-A `concept_comparison` performs compile-time pattern matching over combinations of sub_concept values, mapping them to derived variant names.
+A `definition` performs compile-time pattern matching over combinations of sub_concept values, mapping them to derived variant names.
 
 **Syntax:**
 ```storybook
-concept_comparison ComparisonName {
+definition ComparisonName {
     VariantName1: {
         SubConceptName1: condition1,
         SubConceptName2: condition2,
@@ -570,7 +570,7 @@ sub_concept Cup.Color {
     Red, Blue, Green
 }
 
-concept_comparison CustomerNumbererestInCups {
+definition CustomerNumbererestInCups {
     Numbererested: {
         Cup.Size: any,  // Any size
         Cup.Type: Cup.Type is Glass or Cup.Type is Plastic,  // Only Glass or Plastic
@@ -655,7 +655,7 @@ serve(CupColor.Red)
 
 **Compile-time:**
 - Sub_concept field types must be identifiers (not value types)
-- Pattern matching in `concept_comparison` is validated
+- Pattern matching in `definition` is validated
 - Type references must resolve to declared concepts
 
 **Runtime:**
@@ -677,7 +677,7 @@ sub_concept VendorInventory {
     Cup: any         // any value of type Cup (includes all CupSize, CupType, CupColor)
 }
 
-concept_comparison Example {
+definition Example {
     AllCups: {
         CupSize: any,    // matches Small, Medium, Large
         CupType: any,    // matches Ceramic, Glass, Plastic
@@ -710,7 +710,7 @@ concept_comparison Example {
 - Fields reference other concepts or need flexibility (`any`)
 - You want record-like types within the concept system
 
-### When to use `concept_comparison`
+### When to use `definition`
 - You need to map combinations of sub_concepts to outcomes
 - Complex conditional logic benefits from compile-time validation
 - Behavior trees need type-safe decision points
@@ -747,7 +747,7 @@ sub_concept Food.Freshness {
     Spoiled
 }
 
-concept_comparison FoodQuality {
+definition FoodQuality {
     Excellent: {
         Food.Type: any,
         Food.Freshness: Food.Freshness is Fresh
@@ -1699,7 +1699,7 @@ The runtime must maintain **state consistency** by validating life arc condition
 
 ## Future Considerations
 
-- **Exhaustiveness checking**: Ensure all variant combinations are covered in concept_comparisons
+- **Exhaustiveness checking**: Ensure all variant combinations are covered in definitions
 - **Default variants**: Support for catch-all patterns in comparisons
 - **Type inference**: Automatic parent concept detection beyond prefix matching
 - **Generic concepts**: Parameterized types for reusable patterns