sequel-duckdb 0.1.0 → 0.2.1

data/.kiro/specs/sequel-duckdb-adapter/design.md

@@ -105,6 +105,7 @@ end
 **Purpose:** Main database class that handles connections, transactions, and schema operations, following sequel-hexspace structure.
 
 **Key Methods for Mock Database Compatibility:**
+
 ```ruby
 # lib/sequel/adapters/duckdb.rb
 class Sequel::DuckDB::Database < Sequel::Database
@@ -191,6 +192,7 @@ end
 **Purpose:** SQL generation and query execution, fully compatible with Sequel's mock database testing, following sequel-hexspace structure.
 
 **Key Methods for SQL Generation Testing:**
+
 ```ruby
 # lib/sequel/adapters/duckdb.rb
 class Sequel::DuckDB::Dataset < Sequel::Dataset
@@ -423,6 +425,7 @@ test/
 ### Test Categories and Requirements
 
 1. **SQL Generation Tests (Unit Tests)**:
+
    - Use Sequel's mock database functionality
    - Test every SQL generation method
    - Verify correct SQL syntax and structure
@@ -430,6 +433,7 @@ test/
    - Must be fast and not require database connections
 
 2. **Integration Tests**:
+
    - Use real DuckDB in-memory databases
    - Test actual database operations
    - Verify data persistence and retrieval
@@ -437,6 +441,7 @@ test/
    - Test transaction behavior
 
 3. **Schema Tests**:
+
    - Test table creation, modification, and deletion
    - Test index operations
    - Test schema introspection accuracy
@@ -444,6 +449,7 @@ test/
    - Test various DuckDB-specific schema features
 
 4. **Type Conversion Tests**:
+
    - Test Ruby ↔ DuckDB type mapping for all supported types
    - Test edge cases and null handling
    - Test precision and scale for numeric types
@@ -451,6 +457,7 @@ test/
    - Test binary data and text encoding
 
 5. **Error Handling Tests**:
+
    - Test proper Sequel exception mapping
    - Test connection failure scenarios
    - Test SQL syntax error handling
@@ -539,4 +546,4 @@ sequel-duckdb/
 | DuckDB      | >= 0.8.0             |
 | Ruby-DuckDB | >= 0.8.0             |
 
-This design ensures the adapter follows Sequel's established patterns while providing full DuckDB functionality and maintaining compatibility with Sequel's testing framework and mock database support.
+This design ensures the adapter follows Sequel's established patterns while providing full DuckDB functionality and maintaining compatibility with Sequel's testing framework and mock database support.

data/.kiro/specs/sequel-duckdb-adapter/requirements.md

@@ -158,15 +158,15 @@ This document outlines the requirements for building a complete Ruby Sequel data
 
 #### Acceptance Criteria
 
-1. WHEN any code is implemented THEN the system SHALL have tests written BEFORE the implementation (Test-Driven Development)
-2. WHEN SQL generation methods are implemented THEN the system SHALL have unit tests verifying correct SQL output following sequel-hexspace test structure
-3. WHEN database operations are implemented THEN the system SHALL have integration tests using actual DuckDB databases
-4. WHEN data type conversions are implemented THEN the system SHALL have tests covering all supported type mappings
-5. WHEN schema introspection is implemented THEN the system SHALL have tests verifying correct metadata retrieval
-6. WHEN transaction handling is implemented THEN the system SHALL have tests covering commit, rollback, and error scenarios
-7. WHEN error conditions occur THEN the system SHALL have tests verifying proper exception handling
-8. WHEN performance-critical operations are implemented THEN the system SHALL have benchmarks to prevent regressions
-9. WHEN test structure is organized THEN the system SHALL mirror sequel-hexspace test organization with test/all.rb, test/spec_helper.rb, test/database_test.rb, test/dataset_test.rb, test/schema_test.rb, test/prepared_statement_test.rb, test/sql_test.rb, and test/type_test.rb
+01. WHEN any code is implemented THEN the system SHALL have tests written BEFORE the implementation (Test-Driven Development)
+02. WHEN SQL generation methods are implemented THEN the system SHALL have unit tests verifying correct SQL output following sequel-hexspace test structure
+03. WHEN database operations are implemented THEN the system SHALL have integration tests using actual DuckDB databases
+04. WHEN data type conversions are implemented THEN the system SHALL have tests covering all supported type mappings
+05. WHEN schema introspection is implemented THEN the system SHALL have tests verifying correct metadata retrieval
+06. WHEN transaction handling is implemented THEN the system SHALL have tests covering commit, rollback, and error scenarios
+07. WHEN error conditions occur THEN the system SHALL have tests verifying proper exception handling
+08. WHEN performance-critical operations are implemented THEN the system SHALL have benchmarks to prevent regressions
+09. WHEN test structure is organized THEN the system SHALL mirror sequel-hexspace test organization with test/all.rb, test/spec_helper.rb, test/database_test.rb, test/dataset_test.rb, test/schema_test.rb, test/prepared_statement_test.rb, test/sql_test.rb, and test/type_test.rb
 10. WHEN mock database testing is needed THEN the system SHALL use Sequel's mock database functionality for SQL generation testing
 11. WHEN integration testing is needed THEN the system SHALL use actual DuckDB in-memory databases for connection and operation testing
 12. WHEN test coverage is measured THEN the system SHALL achieve 100% coverage of all implemented functionality
@@ -199,4 +199,4 @@ This document outlines the requirements for building a complete Ruby Sequel data
 5. WHEN the gem is packaged THEN the system SHALL follow Ruby gem conventions with standard structure (Gemfile, Rakefile, .rubocop.yml)
 6. WHEN dependencies are specified THEN the system SHALL use ruby-duckdb gem exclusively for database connections with appropriate version constraints
 7. WHEN Ruby versions are supported THEN the system SHALL maintain compatibility with Ruby 3.1+ as specified in the technology requirements
-8. WHEN file structure is organized THEN the system SHALL place adapter logic in lib/sequel/adapters/duckdb.rb and shared functionality in lib/sequel/adapters/shared/duckdb.rb following sequel-hexspace conventions exactly
+8. WHEN file structure is organized THEN the system SHALL place adapter logic in lib/sequel/adapters/duckdb.rb and shared functionality in lib/sequel/adapters/shared/duckdb.rb following sequel-hexspace conventions exactly

data/.kiro/specs/sequel-duckdb-adapter/tasks.md

@@ -1,19 +1,23 @@
 # Implementation Plan
 
 - [x] 1. Set up project structure following sequel-hexspace pattern
+
   - Create lib/sequel/adapters/duckdb.rb for main Database and Dataset classes
   - Create lib/sequel/adapters/shared/duckdb.rb for DatabaseMethods and DatasetMethods modules
   - Set up proper require structure and module organization
   - _Requirements: 10.3, 13.8_
 
 - [x] 2. Implement basic connection management in shared module
+
   - [x] 2.1 Create DatabaseMethods module with connection handling
+
     - Implement connect method for file and in-memory databases
     - Implement disconnect_connection and valid_connection? methods
     - Add proper error handling for connection failures
     - _Requirements: 1.1, 1.2, 1.4, 1.6_
 
   - [x] 2.2 Create Database class with adapter registration
+
     - Define Sequel::DuckDB::Database class including DatabaseMethods
     - Set adapter scheme to :duckdb
     - Implement dataset_class_default method
@@ -21,13 +25,16 @@
     - _Requirements: 1.1, 10.2, 13.1_
 
   - [x] 2.3 Fix adapter registration (CRITICAL BUG)
+
     - Fix incorrect adapter registration in lib/sequel/adapters/duckdb.rb
     - Change from `Sequel::Database.set_shared_adapter_scheme :duckdb, self` to proper registration
     - Use `Database.adapter_scheme :duckdb, DuckDB::Database` pattern
     - _Requirements: 1.1, 13.1_
 
 - [x] 3. Set up comprehensive test infrastructure (CRITICAL - TDD REQUIREMENT)
+
   - [x] 3.1 Create test infrastructure following sequel-hexspace pattern
+
     - Create test/all.rb test runner
     - Create test/spec_helper.rb with test configuration and DuckDB setup
     - Set up test database helpers and utilities for both mock and real DuckDB testing
@@ -35,6 +42,7 @@
     - _Requirements: 11.8, 10.4, 13.1_
 
   - [x] 3.2 Create core test files with initial structure
+
     - Create test/database_test.rb for connection and basic functionality tests
     - Create test/dataset_test.rb for comprehensive SQL generation testing
     - Create test/schema_test.rb for schema operations and introspection
@@ -43,7 +51,9 @@
     - _Requirements: 11.1, 11.2, 11.4, 11.3_
 
 - [x] 4. Implement basic SQL generation in shared module (TDD - TESTS FIRST)
+
   - [x] 4.1 Write tests for core SQL generation methods
+
     - Write comprehensive tests for select_sql method using mock database
     - Write tests for insert_sql method with various parameter combinations
     - Write tests for update_sql method with WHERE clauses
@@ -52,6 +62,7 @@
     - _Requirements: 2.1, 2.2, 2.3, 2.4, 11.1, 11.2_
 
   - [x] 4.2 Implement DatasetMethods module with core SQL generation
+
     - Implement select_sql method for basic SELECT statements
     - Implement insert_sql method for INSERT operations
     - Implement update_sql method for UPDATE operations
@@ -60,19 +71,23 @@
     - _Requirements: 2.1, 2.2, 2.3, 2.4_
 
   - [x] 4.3 Write tests for Dataset class functionality
+
     - Write tests for fetch_rows method using real DuckDB in-memory database
     - Write tests for DuckDB capability flags (window functions, CTE support, etc.)
     - Write integration tests for basic query execution
     - _Requirements: 2.1, 6.1, 6.2, 11.3_
 
   - [x] 4.4 Implement Dataset class with shared functionality
+
     - Implement fetch_rows method for query execution
     - Add DuckDB capability flags (window functions, CTE support, etc.)
     - Ensure proper integration with DatabaseMethods
     - _Requirements: 2.1, 6.1, 6.2_
 
 - [x] 5. Implement data type handling and literal conversion (TDD - TESTS FIRST)
+
   - [x] 5.1 Write tests for literal conversion methods
+
     - Write tests for literal_string_append with string escaping scenarios
     - Write tests for literal_date, literal_datetime, literal_time methods
     - Write tests for literal_boolean method with true/false values
@@ -80,6 +95,7 @@
     - _Requirements: 3.1, 3.2, 3.3, 3.4, 3.5, 3.6, 3.8, 11.4_
 
   - [x] 5.2 Add literal conversion methods to DatasetMethods
+
     - Implement literal_string_append for string escaping
     - Implement literal_date, literal_datetime, literal_time methods
     - Implement literal_boolean method for boolean values
@@ -87,19 +103,23 @@
     - _Requirements: 3.1, 3.2, 3.3, 3.4, 3.5, 3.6, 3.8_
 
   - [x] 5.3 Write tests for binary data and numeric type support
+
     - Write tests for BLOB type mapping for binary data
     - Write tests for integer and float type handling
     - Write tests for Ruby to DuckDB type conversion edge cases
     - _Requirements: 3.2, 3.3, 3.9, 11.4_
 
   - [x] 5.4 Add binary data and numeric type support
+
     - Implement BLOB type mapping for binary data
     - Add proper integer and float type handling
     - Ensure proper Ruby to DuckDB type conversion
     - _Requirements: 3.2, 3.3, 3.9_
 
 - [-] 6. Implement schema introspection in DatabaseMethods (TDD - TESTS FIRST)
+
   - [x] 6.1 Write tests for schema introspection methods
+
     - Write tests for schema_parse_tables method for table listing
     - Write tests for schema_parse_table method for column information
     - Write tests for schema_parse_indexes method for index introspection
@@ -107,6 +127,7 @@
     - _Requirements: 4.1, 4.2, 4.3, 4.4, 4.5, 4.6, 11.5_
 
   - [x] 6.2 Add table and schema discovery methods
+
     - Implement schema_parse_tables method for table listing
     - Implement schema_parse_table method for column information
     - Implement schema_parse_indexes method for index introspection
@@ -114,6 +135,7 @@
     - _Requirements: 4.1, 4.2, 4.3, 4.4, 4.5, 4.6_
 
   - [x] 6.3 Write tests for schema metadata methods
+
     - Write tests for tables method using schema_parse_tables
     - Write tests for schema method using schema_parse_table
     - Write tests for indexes method using schema_parse_indexes
@@ -121,6 +143,7 @@
     - _Requirements: 4.7, 4.8, 11.5_
 
   - [x] 6.4 Add schema metadata methods
+
     - Implement tables method using schema_parse_tables
     - Implement schema method using schema_parse_table
     - Implement indexes method using schema_parse_indexes
@@ -128,7 +151,9 @@
     - _Requirements: 4.7, 4.8_
 
 - [-] 7. Implement transaction support in DatabaseMethods
+
   - [x] 7.1 Add basic transaction methods
+
     - Implement transaction block handling
     - Add automatic commit on successful completion
     - Add automatic rollback on exceptions
@@ -136,13 +161,16 @@
     - _Requirements: 5.1, 5.2, 5.3, 5.4_
 
   - [x] 6.2 Add advanced transaction features
+
     - Implement savepoint support if available in DuckDB
     - Add transaction isolation level support
     - Implement manual transaction control for autocommit mode
     - _Requirements: 5.5, 5.6, 5.7_
 
 - [x] 8. Implement advanced SQL generation features
+
   - [x] 8.1 Add complex query support to DatasetMethods
+
     - Implement proper WHERE clause generation
     - Add ORDER BY, LIMIT, and OFFSET support
     - Implement GROUP BY and HAVING clause generation
@@ -150,6 +178,7 @@
     - _Requirements: 6.4, 6.5, 6.6, 6.7, 6.8, 6.9_
 
   - [x] 8.2 Add DuckDB-specific SQL features
+
     - Implement window function support
     - Add Common Table Expression (CTE) support
     - Implement subquery generation
@@ -157,7 +186,9 @@
     - _Requirements: 2.6, 2.7, 2.8_
 
 - [x] 9. Implement SQL execution methods in DatabaseMethods
+
   - [x] 9.1 Add core SQL execution methods
+
     - Implement execute method with connection synchronization
     - Implement execute_insert and execute_update methods
     - Add execute_statement private method for actual SQL execution
@@ -165,13 +196,16 @@
     - _Requirements: 2.1, 2.2, 2.3, 2.4_
 
   - [x] 9.2 Add dataset operation support
+
     - Implement count, first, and all methods in DatasetMethods
     - Add proper result set handling and conversion
     - Implement streaming result support where possible
     - _Requirements: 6.1, 6.2, 6.3, 9.5_
 
 - [-] 10. Implement error handling and logging
+
   - [x] 10.1 Add error mapping in DatabaseMethods
+
     - Implement database_error_classes method
     - Add database_exception_sqlstate method for SQL state extraction
     - Map DuckDB errors to appropriate Sequel exceptions
@@ -179,6 +213,7 @@
     - _Requirements: 8.1, 8.2, 8.3, 8.7_
 
   - [x] 9.2 Add logging and debugging support
+
     - Implement SQL query logging using Sequel's logging mechanism
     - Add timing information for slow operations
     - Implement connection pooling error handling
@@ -186,7 +221,9 @@
     - _Requirements: 8.4, 8.5, 8.6, 9.6_
 
 - [x] 11. Implement performance optimizations
+
   - [x] 11.1 Add efficient result fetching
+
     - Optimize fetch_rows method for large result sets
     - Implement prepared statement support if beneficial
     - Add bulk insert optimization methods
@@ -194,16 +231,17 @@
     - _Requirements: 9.1, 9.2, 9.3, 9.4_
 
   - [x] 10.2 Add memory and query optimizations
+
     - Implement streaming result options for memory efficiency
     - Add index-aware query generation
     - Optimize for DuckDB's columnar storage advantages
     - Implement parallel query execution support
     - _Requirements: 9.5, 9.7_
 
-
-
 - [x] 12. Implement Sequel::Model integration support
+
   - [x] 12.1 Add model compatibility methods
+
     - Ensure automatic schema introspection works with models
     - Implement proper INSERT statement generation for model creation
     - Add UPDATE statement generation for model updates
@@ -211,13 +249,16 @@
     - _Requirements: 7.1, 7.2, 7.3, 7.4_
 
   - [x] 12.2 Add association and validation support
+
     - Implement foreign key relationship handling for associations
     - Ensure model validations work correctly with DuckDB constraints
     - Add model callback support during DuckDB operations
     - _Requirements: 7.5, 7.6, 7.7_
 
 - [x] 13. Create documentation and examples
+
   - [x] 13.1 Write comprehensive README
+
     - Create usage examples with connection strings
     - Add sample code for common operations
     - Document DuckDB-specific features and optimizations
@@ -225,6 +266,7 @@
     - _Requirements: 12.1, 12.2, 12.5_
 
   - [x] 13.2 Add API documentation and migration examples
+
     - Generate complete YARD documentation for all public methods
     - Create Sequel migration examples for DuckDB
     - Document performance tuning techniques
@@ -232,7 +274,9 @@
     - _Requirements: 12.2, 12.3, 12.4, 12.6_
 
 - [x] 14. Final integration and compatibility verification
+
   - [x] 14.1 Verify Sequel conventions compliance
+
     - Ensure adapter follows Sequel's standard exception hierarchy
     - Verify configuration options follow Sequel patterns
     - Test compatibility with Ruby 3.1+ requirements
@@ -240,8 +284,9 @@
     - _Requirements: 13.2, 13.3, 13.4, 13.5, 13.7_
 
   - [x] 14.2 Complete end-to-end testing
+
     - Run comprehensive test suite with real DuckDB databases
     - Verify all SQL generation produces valid DuckDB syntax
     - Test performance with large datasets
     - Validate memory usage and connection handling
-    - _Requirements: 11.7, 9.1, 9.4, 9.5_
+    - _Requirements: 11.7, 9.1, 9.4, 9.5_

data/.kiro/specs/sql-expression-handling-fix/design.md

@@ -32,6 +32,7 @@ Following Sequel's adapter pattern, the fix will be implemented in the `DatasetM
 **Location**: `Sequel::DuckDB::DatasetMethods` module
 
 **Interface**:
+
 ```ruby
 def literal_append(sql, v)
   case v
@@ -59,18 +60,21 @@ end
 ### Type Handling Components
 
 #### 1. LiteralString Handler
+
 - **Purpose**: Process `Sequel.lit()` expressions as raw SQL following Sequel core pattern
 - **Behavior**: Append string content directly without quoting (`sql << v`)
 - **Input**: `Sequel::LiteralString` objects (subclass of `String`)
 - **Output**: Raw SQL string appended to query
 
 #### 2. Regular String Handler
+
 - **Purpose**: Process regular Ruby strings with appropriate encoding handling
 - **Behavior**: Apply existing binary/text string logic
 - **Input**: Regular `String` objects (excluding `LiteralString`)
 - **Output**: Properly quoted and escaped string literals
 
 #### 3. Parent Class Delegation
+
 - **Purpose**: Handle all other data types including `SQL::Function`
 - **Behavior**: Delegate to parent class implementation (which already works correctly)
 - **Input**: All other Ruby/Sequel objects including `SQL::Expression` subclasses
@@ -79,12 +83,15 @@ end
 ### Integration Points
 
 #### Dataset Class Integration
+
 The enhanced `literal_append` method integrates with:
+
 - **SQL Generation Pipeline**: Core Sequel SQL building process
 - **Query Context Handling**: SELECT, WHERE, ORDER BY, GROUP BY, HAVING clauses
 - **Expression Composition**: Nested and complex expressions
 
 #### Sequel Framework Integration
+
 - **Parent Class Delegation**: Leverages existing Sequel functionality
 - **Type System Compatibility**: Works with Sequel's expression type hierarchy
 - **Error Handling**: Integrates with Sequel's error reporting system
@@ -94,6 +101,7 @@ The enhanced `literal_append` method integrates with:
 ### Input Data Types
 
 #### Sequel::LiteralString
+
 ```ruby
 # Created by: Sequel.lit("YEAR(created_at)")
 # Properties:
@@ -103,6 +111,7 @@ The enhanced `literal_append` method integrates with:
 ```
 
 #### Sequel::SQL::Function
+
 ```ruby
 # Created by: Sequel.function(:count, :*)
 # Properties:
@@ -112,6 +121,7 @@ The enhanced `literal_append` method integrates with:
 ```
 
 #### Regular Data Types
+
 ```ruby
 # String, Integer, Float, Date, Time, etc.
 # Properties:
@@ -123,6 +133,7 @@ The enhanced `literal_append` method integrates with:
 ### Output Data Model
 
 #### SQL String Buffer
+
 - **Type**: String (mutable)
 - **Content**: Accumulated SQL query text
 - **Modification**: Appended to by `literal_append`
@@ -132,16 +143,19 @@ The enhanced `literal_append` method integrates with:
 ### Error Categories
 
 #### 1. Unsupported Expression Types
+
 - **Scenario**: Unknown SQL expression object encountered
 - **Response**: Clear error message with object type information
 - **Error Type**: `Sequel::Error` or subclass
 
 #### 2. Expression Rendering Failures
+
 - **Scenario**: Function or expression rendering fails
 - **Response**: Context-aware error with failing expression details
 - **Error Type**: `Sequel::DatabaseError`
 
 #### 3. SQL Generation Failures
+
 - **Scenario**: Overall SQL generation fails due to expression issues
 - **Response**: Categorized error with query context
 - **Error Type**: `Sequel::DatabaseError`
@@ -179,18 +193,21 @@ end
 ### Test Categories
 
 #### 1. Unit Tests - SQL Generation
+
 - **Framework**: Sequel mock database
 - **Purpose**: Test SQL generation without database connections
 - **Coverage**: All expression types and combinations
 - **Location**: `test/sql_test.rb`
 
 #### 2. Integration Tests - Database Operations
+
 - **Framework**: Real DuckDB in-memory databases
 - **Purpose**: End-to-end expression functionality
 - **Coverage**: Query execution with expressions
 - **Location**: `test/dataset_test.rb`
 
 #### 3. Regression Tests
+
 - **Purpose**: Ensure backward compatibility
 - **Coverage**: Existing functionality continues working
 - **Location**: Multiple test files
@@ -198,12 +215,14 @@ end
 ### Test Implementation Approach
 
 #### Test-Driven Development
+
 1. **Write failing tests** for each expression type
 2. **Implement minimal fix** to make tests pass
 3. **Refactor** while maintaining green tests
 4. **Add edge case tests** and handle them
 
 #### Test Structure
+
 ```ruby
 def test_literal_string_handling
   # Test Sequel.lit() expressions
@@ -225,6 +244,7 @@ end
 ```
 
 ### Coverage Requirements
+
 - **100% line coverage** for new `literal_append` method
 - **Branch coverage** for all case statements
 - **Edge case coverage** for error conditions
@@ -233,9 +253,11 @@ end
 ## Design Decisions and Rationales
 
 ### Decision 1: Follow Sequel Core Pattern Exactly
+
 **Rationale**: Sequel core already has the correct pattern for handling `LiteralString` as a special case of `String`. Following this established pattern ensures compatibility and maintainability.
 
 **Evidence**: Sequel core's `literal_append` method in `/sequel/dataset/sql.rb` shows the exact pattern:
+
 ```ruby
 when String
   case v
@@ -249,31 +271,39 @@ when String
 ```
 
 ### Decision 2: Minimal Modification Approach
+
 **Rationale**: The current implementation already works correctly for most types. Only the `LiteralString` handling is missing, so we add the minimal necessary check.
 
 **Alternatives Considered**:
+
 - Complete rewrite of literal_append (rejected - unnecessary and risky)
 - Separate method for LiteralString (rejected - doesn't follow Sequel patterns)
 
 ### Decision 3: No Changes to Function Handling
+
 **Rationale**: Testing revealed that `SQL::Function` objects already work correctly through parent class delegation. The issue is specifically with `LiteralString` objects being treated as regular strings.
 
 **Evidence**:
+
 - `db[:test].select(Sequel.function(:count, :*)).sql` produces correct `"SELECT count(*) FROM test"`
 - `db[:test].select(Sequel.lit('YEAR(created_at)')).sql` incorrectly produces `"SELECT 'YEAR(created_at)' FROM test"`
 
 ### Decision 4: Preserve Existing Time/DateTime/Binary Handling
+
 **Rationale**: The current implementation correctly handles `Time`, `DateTime`, and binary string encoding. These should remain unchanged.
 
 **Benefits**:
+
 - Maintains backward compatibility for existing functionality
 - Focuses fix on the specific problem area
 - Reduces risk of regression in working features
 
 ### Decision 5: Integration in DatasetMethods Module
+
 **Rationale**: Following the established sequel-duckdb pattern where shared functionality is implemented in modules and included in main classes.
 
 **Benefits**:
+
 - Consistent with existing codebase architecture
 - Allows for easy testing and maintenance
 - Follows Sequel adapter conventions
@@ -281,18 +311,21 @@ when String
 ## Implementation Phases
 
 ### Phase 1: Fix LiteralString Handling
+
 - Modify existing `literal_append` method to check for `LiteralString` before regular `String`
 - Add comprehensive unit tests for `LiteralString` handling
 - Verify existing functionality remains intact
 
 ### Phase 2: Comprehensive Testing
+
 - Add integration tests with real database operations
 - Test all SQL clause contexts (SELECT, WHERE, ORDER BY, etc.)
 - Add regression tests to ensure no existing functionality breaks
 
 ### Phase 3: Edge Cases and Error Handling
+
 - Test complex nested expressions
 - Verify error handling for malformed expressions
 - Performance verification with existing benchmarks
 
-This design provides a focused, low-risk solution that addresses the core SQL expression handling issues while maintaining full backward compatibility and following established Sequel adapter patterns.
+This design provides a focused, low-risk solution that addresses the core SQL expression handling issues while maintaining full backward compatibility and following established Sequel adapter patterns.

data/.kiro/specs/sql-expression-handling-fix/requirements.md

@@ -83,4 +83,4 @@ This specification addresses critical SQL expression handling issues in the sequ
 
 1. WHEN an unsupported expression type is encountered THEN a clear error message SHALL be provided
 2. WHEN expression rendering fails THEN the error SHALL include context about the failing expression
-3. WHEN SQL generation fails due to expression issues THEN the error SHALL be properly categorized as a DatabaseError
+3. WHEN SQL generation fails due to expression issues THEN the error SHALL be properly categorized as a DatabaseError

data/.kiro/specs/sql-expression-handling-fix/tasks.md

@@ -1,6 +1,7 @@
 # Implementation Plan
 
 - [x] 1. Write tests for LiteralString handling
+
   - Add test in `test/sql_test.rb` to verify `Sequel.lit()` expressions are not quoted
   - Test LiteralString in SELECT clause: `db[:test].select(Sequel.lit('YEAR(created_at)')).sql`
   - Test LiteralString in WHERE clause: `db[:test].where(Sequel.lit('age > 18')).sql`
@@ -9,6 +10,7 @@
   - _Requirements: 1.1, 1.2, 4.1, 6.1_
 
 - [x] 2. Fix literal_append method to handle LiteralString
+
   - Modify existing `literal_append` method in `lib/sequel/adapters/shared/duckdb.rb`
   - Add `LiteralString` check as special case of `String` following Sequel core pattern
   - Change `when String` to nested case with `when LiteralString` that does `sql << v`
@@ -16,6 +18,7 @@
   - _Requirements: 1.1, 4.1, 4.2, 4.4, 6.1_
 
 - [x] 3. Add integration test with real database
+
   - Add test in `test/dataset_test.rb` using real DuckDB database
   - Test that LiteralString expressions actually execute correctly
   - Verify no regression in existing database operations

data/.kiro/specs/test-infrastructure-improvements/requirements.md

@@ -103,4 +103,4 @@ This specification addresses test infrastructure issues in the sequel-duckdb ada
 1. WHEN new functionality is added THEN corresponding tests SHALL be required
 2. WHEN tests are removed THEN coverage impact SHALL be evaluated
 3. WHEN test coverage is measured THEN it SHALL include both unit and integration tests
-4. WHEN coverage gaps are identified THEN they SHALL be prioritized for additional testing
+4. WHEN coverage gaps are identified THEN they SHALL be prioritized for additional testing

data/.kiro/steering/product.md

@@ -3,6 +3,7 @@
 sequel-duckdb is a Ruby gem that provides a complete database adapter for the Sequel toolkit to work with DuckDB. This gem enables Ruby applications to connect to and interact with DuckDB databases through Sequel's comprehensive ORM and database abstraction interface.
 
 ## Key Features
+
 - Full DuckDB database adapter for Sequel
 - Ruby 3.1+ compatibility
 - Complete SQL generation and query support
@@ -10,13 +11,16 @@ sequel-duckdb is a Ruby gem that provides a complete database adapter for the Se
 - Comprehensive test coverage for all SQL operations
 
 ## Reference Projects
+
 - **jeremyevans/sequel**: Official Sequel repository for coding conventions
 - **sequel-hexspace**: Secondary reference for adapter structure
 - **sequel_impala**: Tertiary reference for implementation patterns
 
 ## Target Users
+
 - Ruby developers using Sequel ORM
 - Applications requiring DuckDB integration
 
 ## Implementation Approach
-This project follows the proven patterns from existing Sequel adapters, with implementation order guided by git history analysis of reference projects. All development is designed to be AI-agent friendly with thorough documentation and incremental implementation.
+
+This project follows the proven patterns from existing Sequel adapters, with implementation order guided by git history analysis of reference projects. All development is designed to be AI-agent friendly with thorough documentation and incremental implementation.

data/.kiro/steering/structure.md

@@ -85,4 +85,4 @@ lib/
 - Mirror sequel-hexspace test organization exactly
 - Test all SQL generation comprehensively
 - Include integration tests with actual DuckDB instances
-- Follow TDD methodology throughout development
+- Follow TDD methodology throughout development