sequel-duckdb 0.1.0 → 0.2.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: eb4c8565280c6828b7fd8122ca87de1867da66e4cc5c7f4b640a0b34ee1880ac
-  data.tar.gz: c415c11256156a1b21e6b5f02268e2f22a786f3ce240e17596d6ba0e61f5a460
+  metadata.gz: 4767efb050303f1b91acddbbe01fd263d1230bb02e1747c013728856d4ceb1b2
+  data.tar.gz: d266f8c0f5169da511c887cc8902d1b288b66c0e67459a1a21873378991d2e58
 SHA512:
-  metadata.gz: d282d7015f97c66fa0a9581552be9ff189b07dbf7678dca94a8990070d42f66335f2359056ca9fbeed4e8b1a89da1afc03884a0ba8994ecda23fc9e1282d5048
-  data.tar.gz: 237ea21f9f3a6d2d148b85e9f4f0338864efe2055b426c5a169ff2d2e3775f54f91957a10e061869066c414921abfc1fd0ae15c375090573e9bd1aa38575b7fd
+  metadata.gz: 19448226d83feefa1708018c918af2f94178ebc5b888ea116b59e11cd7f24f151843544b064030bb81701825516c3e0aebab70301ee4dbd79922b43d6c4db436
+  data.tar.gz: a1d751a3e64769fdad344fec138a29860568acf5d9930b972b2893fc4008c25cd5fc5798ab93a20192fc8f5563d3fa5bfade189affb75a1c8b51aa6efdc93b93

data/.beads/.beads-credential-key

@@ -0,0 +1 @@
+�:I>����G��O�FԤ�L1	s<j�,

data/.beads/.gitignore

@@ -0,0 +1,66 @@
+# Dolt database (managed by Dolt, not git)
+dolt/
+dolt-access.lock
+
+# Runtime files
+bd.sock
+bd.sock.startlock
+sync-state.json
+last-touched
+.exclusive-lock
+
+# Daemon runtime (lock, log, pid)
+daemon.*
+
+# Interactions log (runtime, not versioned)
+interactions.jsonl
+
+# Push state (runtime, per-machine)
+push-state.json
+
+# Lock files (various runtime locks)
+*.lock
+
+# Local version tracking (prevents upgrade notification spam after git ops)
+.local_version
+
+# Worktree redirect file (contains relative path to main repo's .beads/)
+# Must not be committed as paths would be wrong in other clones
+redirect
+
+# Sync state (local-only, per-machine)
+# These files are machine-specific and should not be shared across clones
+.sync.lock
+export-state/
+
+# Ephemeral store (SQLite - wisps/molecules, intentionally not versioned)
+ephemeral.sqlite3
+ephemeral.sqlite3-journal
+ephemeral.sqlite3-wal
+ephemeral.sqlite3-shm
+
+# Dolt server management (auto-started by bd)
+dolt-server.pid
+dolt-server.log
+dolt-server.lock
+dolt-server.port
+
+# Corrupt backup directories (created by bd doctor --fix recovery)
+*.corrupt.backup/
+
+# Backup data (auto-exported JSONL, local-only)
+backup/
+
+# Legacy files (from pre-Dolt versions)
+*.db
+*.db?*
+*.db-journal
+*.db-wal
+*.db-shm
+db.sqlite
+bd.db
+# NOTE: Do NOT add negation patterns here.
+# They would override fork protection in .git/info/exclude.
+# Config files (metadata.json, config.yaml) are tracked by git by default
+# since no pattern above ignores them.
+.beads-credential-key

data/.beads/README.md

@@ -0,0 +1,85 @@
+# Beads - AI-Native Issue Tracking
+
+Welcome to Beads! This repository uses **Beads** for issue tracking - a modern, AI-native tool designed to live directly in your codebase alongside your code.
+
+## What is Beads?
+
+Beads is issue tracking that lives in your repo, making it perfect for AI coding agents and developers who want their issues close to their code. No web UI required - everything works through the CLI and integrates seamlessly with git.
+
+**Learn more:** [github.com/steveyegge/beads](https://github.com/steveyegge/beads)
+
+## Quick Start
+
+### Essential Commands
+
+```bash
+# Create new issues
+bd create "Add user authentication"
+
+# View all issues
+bd list
+
+# View issue details
+bd show <issue-id>
+
+# Update issue status
+bd update <issue-id> --claim
+bd update <issue-id> --status done
+
+# Sync with Dolt remote
+bd dolt push
+```
+
+### Working with Issues
+
+Issues in Beads are:
+
+- **Git-native**: Stored in Dolt database with version control and branching
+- **AI-friendly**: CLI-first design works perfectly with AI coding agents
+- **Branch-aware**: Issues can follow your branch workflow
+- **Always in sync**: Auto-syncs with your commits
+
+## Why Beads?
+
+✨ **AI-Native Design**
+
+- Built specifically for AI-assisted development workflows
+- CLI-first interface works seamlessly with AI coding agents
+- No context switching to web UIs
+
+🚀 **Developer Focused**
+
+- Issues live in your repo, right next to your code
+- Works offline, syncs when you push
+- Fast, lightweight, and stays out of your way
+
+🔧 **Git Integration**
+
+- Automatic sync with git commits
+- Branch-aware issue tracking
+- Dolt-native three-way merge resolution
+
+## Get Started with Beads
+
+Try Beads in your own projects:
+
+```bash
+# Install Beads
+curl -sSL https://raw.githubusercontent.com/steveyegge/beads/main/scripts/install.sh | bash
+
+# Initialize in your repo
+bd init
+
+# Create your first issue
+bd create "Try out Beads"
+```
+
+## Learn More
+
+- **Documentation**: [github.com/steveyegge/beads/docs](https://github.com/steveyegge/beads/tree/main/docs)
+- **Quick Start Guide**: Run `bd quickstart`
+- **Examples**: [github.com/steveyegge/beads/examples](https://github.com/steveyegge/beads/tree/main/examples)
+
+______________________________________________________________________
+
+*Beads: Issue tracking that moves at the speed of thought* ⚡

data/.beads/config.yaml

@@ -0,0 +1,56 @@
+# Beads Configuration File
+# This file configures default behavior for all bd commands in this repository
+# All settings can also be set via environment variables (BD_* prefix)
+# or overridden with command-line flags
+
+# Issue prefix for this repository (used by bd init)
+# If not set, bd init will auto-detect from directory name
+# Example: issue-prefix: "myproject" creates issues like "myproject-1", "myproject-2", etc.
+# issue-prefix: ""
+
+# Use no-db mode: JSONL-only, no Dolt database
+# When true, bd will use .beads/issues.jsonl as the source of truth
+# no-db: false
+
+# Enable JSON output by default
+# json: false
+
+# Feedback title formatting for mutating commands (create/update/close/dep/edit)
+# 0 = hide titles, N > 0 = truncate to N characters
+# output:
+#   title-length: 255
+
+# Default actor for audit trails (overridden by BD_ACTOR or --actor)
+# actor: ""
+
+# Export events (audit trail) to .beads/events.jsonl on each flush/sync
+# When enabled, new events are appended incrementally using a high-water mark.
+# Use 'bd export --events' to trigger manually regardless of this setting.
+# events-export: false
+
+# Multi-repo configuration (experimental - bd-307)
+# Allows hydrating from multiple repositories and routing writes to the correct database
+# repos:
+#   primary: "."  # Primary repo (where this database lives)
+#   additional:   # Additional repos to hydrate from (read-only)
+#     - ~/beads-planning  # Personal planning repo
+#     - ~/work-planning   # Work planning repo
+
+# JSONL backup (periodic export for off-machine recovery)
+# Auto-enabled when a git remote exists. Override explicitly:
+# backup:
+#   enabled: false     # Disable auto-backup entirely
+#   interval: 15m      # Minimum time between auto-exports
+#   git-push: false    # Disable git push (export locally only)
+#   git-repo: ""       # Separate git repo for backups (default: project repo)
+
+# Integration settings (access with 'bd config get/set')
+# These are stored in the database, not in this file:
+# - jira.url
+# - jira.project
+# - linear.url
+# - linear.api-key
+# - github.org
+# - github.repo
+
+sync.remote: "git+ssh://git@github.com/outcomesinsights/sequel-duckdb.git"

data/.beads/hooks/post-checkout

@@ -0,0 +1,24 @@
+#!/usr/bin/env sh
+# --- BEGIN BEADS INTEGRATION v0.61.0 ---
+# This section is managed by beads. Do not remove these markers.
+if command -v bd >/dev/null 2>&1; then
+  export BD_GIT_HOOK=1
+  _bd_timeout=${BEADS_HOOK_TIMEOUT:-30}
+  if command -v timeout >/dev/null 2>&1; then
+    timeout "$_bd_timeout" bd hooks run post-checkout "$@"
+    _bd_exit=$?
+    if [ $_bd_exit -eq 124 ]; then
+      echo >&2 "beads: hook 'post-checkout' timed out after ${_bd_timeout}s — continuing without beads"
+      _bd_exit=0
+    fi
+  else
+    bd hooks run post-checkout "$@"
+    _bd_exit=$?
+  fi
+  if [ $_bd_exit -eq 3 ]; then
+    echo >&2 "beads: database not initialized — skipping hook 'post-checkout'"
+    _bd_exit=0
+  fi
+  if [ $_bd_exit -ne 0 ]; then exit $_bd_exit; fi
+fi
+# --- END BEADS INTEGRATION v0.61.0 ---

data/.beads/hooks/post-merge

@@ -0,0 +1,24 @@
+#!/usr/bin/env sh
+# --- BEGIN BEADS INTEGRATION v0.61.0 ---
+# This section is managed by beads. Do not remove these markers.
+if command -v bd >/dev/null 2>&1; then
+  export BD_GIT_HOOK=1
+  _bd_timeout=${BEADS_HOOK_TIMEOUT:-30}
+  if command -v timeout >/dev/null 2>&1; then
+    timeout "$_bd_timeout" bd hooks run post-merge "$@"
+    _bd_exit=$?
+    if [ $_bd_exit -eq 124 ]; then
+      echo >&2 "beads: hook 'post-merge' timed out after ${_bd_timeout}s — continuing without beads"
+      _bd_exit=0
+    fi
+  else
+    bd hooks run post-merge "$@"
+    _bd_exit=$?
+  fi
+  if [ $_bd_exit -eq 3 ]; then
+    echo >&2 "beads: database not initialized — skipping hook 'post-merge'"
+    _bd_exit=0
+  fi
+  if [ $_bd_exit -ne 0 ]; then exit $_bd_exit; fi
+fi
+# --- END BEADS INTEGRATION v0.61.0 ---

data/.beads/hooks/pre-commit

@@ -0,0 +1,24 @@
+#!/usr/bin/env sh
+# --- BEGIN BEADS INTEGRATION v0.61.0 ---
+# This section is managed by beads. Do not remove these markers.
+if command -v bd >/dev/null 2>&1; then
+  export BD_GIT_HOOK=1
+  _bd_timeout=${BEADS_HOOK_TIMEOUT:-30}
+  if command -v timeout >/dev/null 2>&1; then
+    timeout "$_bd_timeout" bd hooks run pre-commit "$@"
+    _bd_exit=$?
+    if [ $_bd_exit -eq 124 ]; then
+      echo >&2 "beads: hook 'pre-commit' timed out after ${_bd_timeout}s — continuing without beads"
+      _bd_exit=0
+    fi
+  else
+    bd hooks run pre-commit "$@"
+    _bd_exit=$?
+  fi
+  if [ $_bd_exit -eq 3 ]; then
+    echo >&2 "beads: database not initialized — skipping hook 'pre-commit'"
+    _bd_exit=0
+  fi
+  if [ $_bd_exit -ne 0 ]; then exit $_bd_exit; fi
+fi
+# --- END BEADS INTEGRATION v0.61.0 ---

data/.beads/hooks/pre-push

@@ -0,0 +1,24 @@
+#!/usr/bin/env sh
+# --- BEGIN BEADS INTEGRATION v0.61.0 ---
+# This section is managed by beads. Do not remove these markers.
+if command -v bd >/dev/null 2>&1; then
+  export BD_GIT_HOOK=1
+  _bd_timeout=${BEADS_HOOK_TIMEOUT:-30}
+  if command -v timeout >/dev/null 2>&1; then
+    timeout "$_bd_timeout" bd hooks run pre-push "$@"
+    _bd_exit=$?
+    if [ $_bd_exit -eq 124 ]; then
+      echo >&2 "beads: hook 'pre-push' timed out after ${_bd_timeout}s — continuing without beads"
+      _bd_exit=0
+    fi
+  else
+    bd hooks run pre-push "$@"
+    _bd_exit=$?
+  fi
+  if [ $_bd_exit -eq 3 ]; then
+    echo >&2 "beads: database not initialized — skipping hook 'pre-push'"
+    _bd_exit=0
+  fi
+  if [ $_bd_exit -ne 0 ]; then exit $_bd_exit; fi
+fi
+# --- END BEADS INTEGRATION v0.61.0 ---

data/.beads/hooks/prepare-commit-msg

@@ -0,0 +1,24 @@
+#!/usr/bin/env sh
+# --- BEGIN BEADS INTEGRATION v0.61.0 ---
+# This section is managed by beads. Do not remove these markers.
+if command -v bd >/dev/null 2>&1; then
+  export BD_GIT_HOOK=1
+  _bd_timeout=${BEADS_HOOK_TIMEOUT:-30}
+  if command -v timeout >/dev/null 2>&1; then
+    timeout "$_bd_timeout" bd hooks run prepare-commit-msg "$@"
+    _bd_exit=$?
+    if [ $_bd_exit -eq 124 ]; then
+      echo >&2 "beads: hook 'prepare-commit-msg' timed out after ${_bd_timeout}s — continuing without beads"
+      _bd_exit=0
+    fi
+  else
+    bd hooks run prepare-commit-msg "$@"
+    _bd_exit=$?
+  fi
+  if [ $_bd_exit -eq 3 ]; then
+    echo >&2 "beads: database not initialized — skipping hook 'prepare-commit-msg'"
+    _bd_exit=0
+  fi
+  if [ $_bd_exit -ne 0 ]; then exit $_bd_exit; fi
+fi
+# --- END BEADS INTEGRATION v0.61.0 ---

data/.beads/metadata.json

@@ -0,0 +1,7 @@
+{
+  "database": "dolt",
+  "backend": "dolt",
+  "dolt_mode": "embedded",
+  "dolt_server_host": "127.0.0.1",
+  "project_id": "5883e5bf-a919-4ca8-b7ee-d1cb7e08dfa5"
+}

data/.kiro/specs/advanced-sql-features-implementation/design.md

@@ -5,11 +5,13 @@
 Most advanced SQL features are already implemented. This focuses on verification, testing, and minor enhancements.
 
 **Status:**
+
 - JOIN USING, recursive CTEs, set operations, error handling: ✅ Implemented
 - Window functions: ✅ Basic support exists
 - DuckDB configuration: ✅ Basic PRAGMA support exists
 
 **Remaining Work:**
+
 - Test window functions with actual DuckDB
 - Test advanced expressions (arrays, JSON)
 - Add user-friendly configuration methods
@@ -21,4 +23,4 @@ Most advanced SQL features are already implemented. This focuses on verification
 2. **Add convenience methods** - User-friendly configuration interface
 3. **Integration testing** - Test with actual DuckDB databases
 
-This is primarily testing and verification, not new feature implementation.
+This is primarily testing and verification, not new feature implementation.

data/.kiro/specs/advanced-sql-features-implementation/requirements.md

@@ -40,4 +40,4 @@ Most advanced SQL features are already implemented. This focuses on remaining ve
 #### Acceptance Criteria
 
 1. WHEN I run tests THEN all advanced features SHALL work with actual DuckDB databases
-2. WHEN errors occur THEN they SHALL be properly mapped to Sequel exceptions
+2. WHEN errors occur THEN they SHALL be properly mapped to Sequel exceptions

data/.kiro/specs/advanced-sql-features-implementation/tasks.md

@@ -3,22 +3,26 @@
 Most advanced SQL features are already implemented. Remaining tasks based on current code analysis:
 
 - [x] 1. Test window functions
+
   - ~~Add tests to `test/dataset_test.rb` for ROW_NUMBER, RANK, DENSE_RANK~~ ✅ Already implemented
   - ~~Test LAG/LEAD functions with offset and default parameters~~ ✅ Already implemented
   - _Requirements: 1.1, 1.2_
 
 - [x] 2. Test advanced expressions
+
   - Add tests to `test/sql_test.rb` for DuckDB array syntax `[1, 2, 3]`
   - Test JSON functions like `json_extract`
   - _Requirements: 2.1, 2.2_
 
 - [x] 3. Add configuration convenience methods
+
   - Add `set_pragma(key, value)` method to `DatabaseMethods` (user-friendly wrapper)
   - Add `configure_duckdb(options)` method for batch configuration
   - Add tests to `test/database_test.rb`
   - _Requirements: 3.1, 3.2_
 
 - [x] 4. Integration testing
+
   - ~~Add integration tests to existing test files using actual DuckDB databases~~ ✅ Already implemented
   - ~~Test that all advanced features work together correctly~~ ✅ Already implemented
-  - _Requirements: 4.1, 4.2_
+  - _Requirements: 4.1, 4.2_

data/.kiro/specs/duckdb-sql-syntax-compatibility/design.md

@@ -162,6 +162,7 @@ Use existing Sequel error handling patterns. No special error handling needed fo
 ## Testing Strategy
 
 ### 1. SQL Generation Unit Tests
+
 - Test all SQL generation methods using Sequel's mock database functionality
 - Verify exact SQL syntax matches expected Sequel patterns
 - Test LIKE clauses generate clean SQL without ESCAPE clauses
@@ -171,12 +172,14 @@ Use existing Sequel error handling patterns. No special error handling needed fo
 - Test subquery column references use standard SQL format
 
 ### 2. Integration Tests
+
 - Ensure actual database operations work correctly with generated SQL
 - Verify functional correctness alongside syntactic correctness
 - Test correlated subqueries with proper column references
 - Test complex queries with multiple SQL generation features
 
 ### 3. Test Infrastructure Consistency
+
 - Fix SQL test infrastructure to use proper dataset creation
 - Ensure tests expect standard SQL syntax consistently
 - Maintain comprehensive test coverage for all SQL generation patterns
@@ -185,41 +188,50 @@ Use existing Sequel error handling patterns. No special error handling needed fo
 ## Design Decisions and Rationales
 
 ### 1. Fix Adapter SQL Generation
+
 **Decision**: Fix the root cause SQL generation issues in the adapter
 **Rationale**: The adapter is generating non-standard SQL that doesn't follow Sequel conventions. Tests are correct to expect standard SQL.
 
 ### 2. Targeted Method Overrides
+
 **Decision**: Override specific SQL generation methods in DatasetMethods
 **Rationale**: Surgical fixes to specific issues without disrupting the overall adapter architecture.
 
 ### 3. Standard SQL Compliance
+
 **Decision**: Generate SQL that follows standard SQL and Sequel conventions
 **Rationale**: Ensures compatibility with existing Sequel patterns and makes the adapter more predictable.
 
 ### 4. Maintain Test Coverage
+
 **Decision**: Keep all existing tests, fix the adapter to make them pass
 **Rationale**: Tests are validating correct behavior; the adapter should conform to expected patterns.
 
 ## Implementation Phases
 
 ### Phase 1: Fix LIKE and Complex Expression Generation
+
 - Override `complex_expression_sql_append` to fix LIKE, ILIKE, and regex generation
 - Add proper parentheses to all complex expressions
 - Remove unwanted ESCAPE clauses from LIKE statements
 
 ### Phase 2: Fix Table Alias Generation
+
 - Override table alias methods to use standard `AS` syntax
 - Ensure aliases work correctly in JOIN operations
 
 ### Phase 3: Fix Qualified Column References
+
 - Override qualified identifier methods to use dot notation
 - Ensure subqueries use proper column references
 
 ### Phase 4: Fix SQL Test Infrastructure
+
 - Fix dataset creation issues in SQL tests
 - Ensure tests use proper mock datasets
 
 ### Phase 5: Verification and Documentation
+
 - Run all tests to ensure they pass with fixed adapter
 - Document the SQL generation patterns used by the adapter
 - Create comprehensive documentation of DuckDB-specific SQL patterns
@@ -228,6 +240,7 @@ Use existing Sequel error handling patterns. No special error handling needed fo
 ## Documentation Strategy
 
 ### SQL Pattern Documentation
+
 To address Requirement 7, the adapter will include comprehensive documentation of SQL generation patterns:
 
 **Location**: `API_DOCUMENTATION.md` and inline code comments
@@ -239,6 +252,7 @@ To address Requirement 7, the adapter will include comprehensive documentation o
 5. **DuckDB-Specific Optimizations**: Document any DuckDB-specific SQL optimizations used
 
 **Example Documentation Structure**:
+
 ```ruby
 # SQL Generation Patterns for DuckDB Adapter
 #
@@ -255,4 +269,4 @@ To address Requirement 7, the adapter will include comprehensive documentation o
 #   Output: users.id
 ```
 
-This design fixes the root causes of the SQL generation issues rather than working around them, resulting in a more robust and standards-compliant adapter.
+This design fixes the root causes of the SQL generation issues rather than working around them, resulting in a more robust and standards-compliant adapter.

data/.kiro/specs/duckdb-sql-syntax-compatibility/requirements.md

@@ -81,4 +81,4 @@ This specification addresses SQL generation issues in the sequel-duckdb adapter
 1. WHEN the adapter generates specific SQL patterns THEN they SHALL be documented
 2. WHEN SQL generation differs from other Sequel adapters THEN the differences SHALL be explained
 3. WHEN DuckDB-specific optimizations are used THEN they SHALL be documented with examples
-4. WHEN SQL generation patterns change THEN documentation SHALL be updated accordingly
+4. WHEN SQL generation patterns change THEN documentation SHALL be updated accordingly

data/.kiro/specs/duckdb-sql-syntax-compatibility/tasks.md

@@ -1,6 +1,7 @@
 # Implementation Plan
 
 - [x] 1. Identify failing tests and analyze DuckDB SQL generation
+
   - Run existing test suite to identify tests failing due to SQL syntax differences
   - Analyze what SQL the adapter currently generates vs what tests expect
   - Document the specific DuckDB syntax patterns that are being generated
@@ -8,6 +9,7 @@
   - _Requirements: 7.1, 7.2_
 
 - [x] 2. Fix LIKE clause ESCAPE handling in adapter
+
   - Current issue: LIKE generates `(name LIKE '%John%' ESCAPE '\')` instead of `(name LIKE '%John%')`
   - Override LIKE handling in `complex_expression_sql_append` to remove ESCAPE clause
   - Ensure LIKE clauses generate clean `(name LIKE '%John%')` without ESCAPE clause
@@ -15,6 +17,7 @@
   - _Requirements: 1.1, 1.2, 1.4_
 
 - [x] 3. Fix parentheses in complex expression SQL generation
+
   - Current issue: ILIKE generates `UPPER(name) LIKE UPPER('%john%')` without outer parentheses
   - Current issue: Regex generates `name ~ 'pattern'` without outer parentheses
   - Update `complex_expression_sql_append` to add proper parentheses around expressions
@@ -24,11 +27,13 @@
   - _Requirements: 1.3, 5.1, 5.2, 5.3, 5.4_
 
 - [x] 4. ~~Fix table alias syntax to use AS instead of triple underscore~~ (REMOVED - Not a core Sequel feature)
+
   - The `table___alias` syntax is not a core Sequel feature and requires an extension
   - Removed implementation and tests as this is not standard Sequel functionality
   - Standard Sequel table aliases use `.as()` method: `db[:users].as(:u)`
 
 - [x] 5. Fix qualified column references to use dot notation
+
   - Current issue: Qualified columns generate `users__id` instead of `users.id`
   - Override qualified identifier handling to generate proper dot notation
   - Implement `qualified_identifier_sql_append` method to use dot notation
@@ -37,6 +42,7 @@
   - _Requirements: 4.1, 4.2, 4.3, 4.4, 6.1, 6.2, 6.3, 6.4_
 
 - [x] 6. Fix SQL test infrastructure issues
+
   - Current issue: SQL tests failing with dataset type assertion errors (`Expected #<Sequel::Dataset::_Subclass>`)
   - Fix `SqlTest` class to use proper dataset creation instead of mock subclasses
   - Update SQL generation tests to work with actual DuckDB adapter behavior
@@ -45,6 +51,7 @@
   - _Requirements: 6.1, 6.2_
 
 - [x] 7. Fix recursive CTE SQL generation
+
   - Current issue: `WITH RECURSIVE` generates incorrect SQL without RECURSIVE keyword
   - Implement proper recursive CTE handling in dataset methods
   - Ensure recursive CTEs generate `WITH RECURSIVE` syntax correctly
@@ -52,6 +59,7 @@
   - _Requirements: 5.1, 5.2, 5.3, 5.4_
 
 - [x] 8. Fix JOIN USING clause generation
+
   - Current issue: `JOIN USING` clause not generating USING syntax correctly
   - Implement proper USING clause handling in JOIN operations
   - Ensure JOIN USING generates correct `INNER JOIN table USING (column)` syntax
@@ -59,6 +67,7 @@
   - _Requirements: 4.1, 4.2, 4.3, 4.4_
 
 - [x] 9. Fix regex functionality integration
+
   - Current issue: Regex matching returning 0 results instead of expected matches
   - Debug regex operator implementation in complex_expression_sql_append
   - Ensure regex patterns work correctly with DuckDB's regex syntax
@@ -66,6 +75,7 @@
   - _Requirements: 1.3, 5.1, 5.2, 5.3, 5.4_
 
 - [x] 10. Fix model integration issues
+
   - Current issue: Model tests failing with type mapping and update detection
   - Fix time type mapping (currently returning :datetime instead of :time)
   - Fix model update detection to properly track changed fields
@@ -73,6 +83,7 @@
   - _Requirements: 2.1, 2.2, 2.3, 2.4_
 
 - [x] 11. Fix table creation and schema issues
+
   - Current issue: Tests failing because tables don't exist during SQL execution
   - Ensure proper table creation in test setup for integration tests
   - Fix primary key handling for tables without explicit primary keys
@@ -80,6 +91,7 @@
   - _Requirements: 3.1, 3.2, 3.3, 3.4_
 
 - [x] 12. Verify all tests pass with consistent DuckDB SQL generation
+
   - Run complete test suite to ensure all SQL generation tests pass
   - Verify that adapter generates consistent, predictable SQL for DuckDB
   - Test integration scenarios to ensure functional correctness
@@ -87,6 +99,7 @@
   - _Requirements: 6.1, 6.2, 6.3, 6.4_
 
 - [x] 13. Document DuckDB-specific SQL syntax patterns
+
   - Document the specific SQL syntax that the adapter generates for DuckDB
   - Provide examples of DuckDB SQL patterns used by the adapter
   - Explain why certain DuckDB syntax choices were made

data/.kiro/specs/edge-cases-and-validation-fixes/requirements.md

@@ -29,4 +29,4 @@ The sequel-duckdb adapter currently provides:
 
 No additional edge case or validation requirements have been identified that would add meaningful value to the adapter. The current implementation provides robust handling of edge cases appropriate for a production database adapter.
 
-This specification is considered complete with no outstanding requirements.
+This specification is considered complete with no outstanding requirements.

data/.kiro/specs/integration-test-database-setup/requirements.md

@@ -114,4 +114,4 @@ This specification addresses database schema and setup issues in integration tes
 1. WHEN using test helpers THEN they SHALL work with the established database schema
 2. WHEN creating test data THEN helpers SHALL use the standardized fixtures
 3. WHEN verifying results THEN helpers SHALL understand the test database structure
-4. WHEN cleaning up THEN helpers SHALL properly reset database state
+4. WHEN cleaning up THEN helpers SHALL properly reset database state