The goto-bus/setup-zig action repository is no longer available.
Replaced with direct installation from ziglang.org official releases.

Changes:
- Download Zig 0.13.0 from official releases
- Install to /opt/zig and symlink to /usr/local/bin
- Verify installation with 'zig version'

This fixes the GitHub Actions workflow error:
'Unable to resolve action goto-bus/setup-zig, repository not found'

Ref: PR #131

Problem: The download script used uname to detect platform, but in CI
cross-compilation environments, uname returns the runner's actual
platform, not the target platform.

Solution: Prioritize GOOS/GOARCH environment variables over uname.

Changes:
- Check GOOS/GOARCH environment variables first
- Fall back to uname if not set (for local development)
- Add proper conversion:
  - darwin → macos
  - amd64 → x86_64
  - arm64 → aarch64

Test cases:
✓ GOOS=darwin GOARCH=amd64 → OS=macos ARCH=x86_64
✓ GOOS=linux GOARCH=arm64 → OS=linux ARCH=aarch64

This fixes GitHub Actions build error:
"ls: .lib/libvec0.a: No such file or directory"

Ref: PR #131

Problem: go generate was skipping sqlite_vec_internal.go because it
has a //go:build sqlite_vec constraint, but the go generate command
did not include the -tags sqlite_vec flag.

Solution: Add -tags sqlite_vec to go generate command.

This ensures that the download_sqlite_vec.sh script is executed
during CI, allowing the static library to be downloaded for each
target platform.

Fixes CI error:
"ls: .lib/libvec0.a: No such file or directory"

Ref: PR #131

Problem: go generate was not executing the download script reliably
in CI environments, even with -tags sqlite_vec.

Root cause: Files with //go:build constraints may not be processed
correctly by go generate in all CI configurations.

Solution: Call the download script directly with bash.

This approach is more reliable and gives better visibility into
what'\''s happening during the download process.

Ref: PR #131

Problem: shasum -a requires an algorithm number (e.g., 256), but the
workflow had 'shasum -a  ' with two spaces and no algorithm.

Error:
"Value \"divinesense-darwin-amd64\" invalid for option a
(integer number expected)"

Solution: Change 'shasum -a  ' to 'shasum -a 256'

This fixes the checksum creation step for macOS builds.

Ref: PR #131

Problem: Zig cross-compiler cannot find sqlite3.h header file when
building for Linux targets.

Error:
"fatal error: 'sqlite3.h' file not found"

Root cause:
- sqlite-vec static library (libvec0.a) depends on SQLite headers
- Zig needs sqlite3.h for CGO compilation
- macOS runner has system SQLite headers, but Linux cross-compilation
  does not

Solution:
1. Download SQLite amalgamation (sqlite3.h + sqlite3.c) from sqlite.org
2. Copy to store/db/sqlite/.lib/ directory
3. Add -Istore/db/sqlite/.lib to Zig compiler flags
4. Set CGO_CFLAGS and CGO_LDFLAGS for proper linking

This allows Zig to find required headers during cross-compilation.

Ref: PR #131

SQLite + sqlite-vec is now an optional feature that can be enabled
via Make parameters or separate Dockerfiles.

## Local Development

**PostgreSQL (default)**:
  make start

**SQLite + sqlite-vec**:
  make start-sqlite-vec

**Direct parameter**:
  SQLITE_VEC=true make run

## Docker Deployment

**PostgreSQL**:
  docker build -f docker/Dockerfile -t divinesense:postgres .
  docker compose -f docker/compose/prod.yml up -d
  make docker-prod-up

**SQLite + sqlite-vec**:
  docker build -f docker/Dockerfile.sqlite-vec -t divinesense:sqlite-vec .
  docker compose -f docker/compose/sqlite-vec.yml up -d
  make docker-sqlite-vec-up

## Changes

- **Makefile**: Add SQLITE_VEC parameter (default: false)
  - When true: sets DRIVER=sqlite, DSN=divinesense.db, BUILD_TAGS=-tags sqlite_vec
  - Add start-sqlite-vec target
  - Add docker-sqlite-vec-* targets for Docker Compose

- **scripts/dev.sh**: Detect SQLITE_VEC environment variable
  - Set DIVINESENSE_DRIVER=sqlite when SQLITE_VEC=true
  - Automatically configure DSN for SQLite

- **docker/Dockerfile.sqlite-vec**: New Dockerfile for SQLite builds
  - Downloads sqlite-vec static library during build
  - Enables CGO for compilation
  - Includes runtime dependencies (libsqlite3-0)

- **docker/compose/sqlite-vec.yml**: Docker Compose for SQLite
  - Single-container deployment (no PostgreSQL)
  - Volume for SQLite database file
  - Environment variable configuration

- **docs/dev-guides/SQLITE_VEC_USAGE.md**: Complete usage guide
  - Local development instructions
  - Docker deployment examples
  - Cross-compilation guide
  - Troubleshooting section

This keeps PostgreSQL as the default (recommended for production) while
making SQLite + sqlite-vec easily accessible for development and
lightweight deployments.

Ref: PR #131

Problem: ensure-sqlite-vec was using 'go generate' which is unreliable
and failed to download the static library.

Error:
"clang: error: no such file or directory:
  '/Users/.../store/db/sqlite/.lib/libvec0.a'"

Solution: Call download_sqlite_vec.sh directly instead of go generate.

This matches the fix we applied to the CI workflow earlier.

Ref: PR #131

Problem: make start-sqlite-vec was still starting PostgreSQL container,
which is unnecessary and causes confusion.

Solution: Modify cmd_start() and cmd_stop() to skip PostgreSQL when
SQLITE_VEC=true.

Changes:
- cmd_start(): Check SQLITE_VEC before starting PostgreSQL
- cmd_stop(): Check SQLITE_VEC before stopping PostgreSQL
- Show database type in startup message

This makes SQLite mode truly standalone without requiring PostgreSQL.

Ref: PR #131

Problem: Frontend calls AIService.ListBlocks which fails in SQLite mode
with "AIBlock not supported in SQLite" error.

Root cause: AIBlock is the new unified conversation model from main branch.
PostgreSQL driver has full implementation, but SQLite driver only has
stub methods returning errors.

Temporary fix: Return empty list for ListAIBlocks to prevent frontend
errors while maintaining functionality.

Current SQLite implementation uses AIConversation instead of AIBlock.
Full AIBlock support for SQLite is tracked as a future task.

This allows sqlite-vec mode to function normally without crashing the
frontend on AIBlock API calls.

Note: Other AIBlock methods (Create, Update, Delete, etc.) still return
errors as they are not critical for basic functionality.

Ref: PR #131

- Remove duplicate .gitignore entry for SQLite-Vec static library
- Restore package filtering in ci-backend (exclude plugin/cron and proto)

These changes address issues found during code review:
1. Duplicate store/db/sqlite/.lib/ entries in .gitignore
2. ci-backend was testing all packages including problematic ones

Refs #131

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

The goto-bus/setup-zig action repository is no longer available.
Replaced with direct installation from ziglang.org official releases.

Changes:
- Download Zig 0.13.0 from official releases
- Install to /opt/zig and symlink to /usr/local/bin
- Verify installation with 'zig version'

This fixes the GitHub Actions workflow error:
'Unable to resolve action goto-bus/setup-zig, repository not found'

Ref: PR #131

Problem: The download script used uname to detect platform, but in CI
cross-compilation environments, uname returns the runner's actual
platform, not the target platform.

Solution: Prioritize GOOS/GOARCH environment variables over uname.

Changes:
- Check GOOS/GOARCH environment variables first
- Fall back to uname if not set (for local development)
- Add proper conversion:
  - darwin → macos
  - amd64 → x86_64
  - arm64 → aarch64

Test cases:
✓ GOOS=darwin GOARCH=amd64 → OS=macos ARCH=x86_64
✓ GOOS=linux GOARCH=arm64 → OS=linux ARCH=aarch64

This fixes GitHub Actions build error:
"ls: .lib/libvec0.a: No such file or directory"

Ref: PR #131

Problem: go generate was skipping sqlite_vec_internal.go because it
has a //go:build sqlite_vec constraint, but the go generate command
did not include the -tags sqlite_vec flag.

Solution: Add -tags sqlite_vec to go generate command.

This ensures that the download_sqlite_vec.sh script is executed
during CI, allowing the static library to be downloaded for each
target platform.

Fixes CI error:
"ls: .lib/libvec0.a: No such file or directory"

Ref: PR #131

Problem: go generate was not executing the download script reliably
in CI environments, even with -tags sqlite_vec.

Root cause: Files with //go:build constraints may not be processed
correctly by go generate in all CI configurations.

Solution: Call the download script directly with bash.

This approach is more reliable and gives better visibility into
what'\''s happening during the download process.

Ref: PR #131

Problem: shasum -a requires an algorithm number (e.g., 256), but the
workflow had 'shasum -a  ' with two spaces and no algorithm.

Error:
"Value \"divinesense-darwin-amd64\" invalid for option a
(integer number expected)"

Solution: Change 'shasum -a  ' to 'shasum -a 256'

This fixes the checksum creation step for macOS builds.

Ref: PR #131

Problem: Zig cross-compiler cannot find sqlite3.h header file when
building for Linux targets.

Error:
"fatal error: 'sqlite3.h' file not found"

Root cause:
- sqlite-vec static library (libvec0.a) depends on SQLite headers
- Zig needs sqlite3.h for CGO compilation
- macOS runner has system SQLite headers, but Linux cross-compilation
  does not

Solution:
1. Download SQLite amalgamation (sqlite3.h + sqlite3.c) from sqlite.org
2. Copy to store/db/sqlite/.lib/ directory
3. Add -Istore/db/sqlite/.lib to Zig compiler flags
4. Set CGO_CFLAGS and CGO_LDFLAGS for proper linking

This allows Zig to find required headers during cross-compilation.

Ref: PR #131

SQLite + sqlite-vec is now an optional feature that can be enabled
via Make parameters or separate Dockerfiles.

## Local Development

**PostgreSQL (default)**:
  make start

**SQLite + sqlite-vec**:
  make start-sqlite-vec

**Direct parameter**:
  SQLITE_VEC=true make run

## Docker Deployment

**PostgreSQL**:
  docker build -f docker/Dockerfile -t divinesense:postgres .
  docker compose -f docker/compose/prod.yml up -d
  make docker-prod-up

**SQLite + sqlite-vec**:
  docker build -f docker/Dockerfile.sqlite-vec -t divinesense:sqlite-vec .
  docker compose -f docker/compose/sqlite-vec.yml up -d
  make docker-sqlite-vec-up

## Changes

- **Makefile**: Add SQLITE_VEC parameter (default: false)
  - When true: sets DRIVER=sqlite, DSN=divinesense.db, BUILD_TAGS=-tags sqlite_vec
  - Add start-sqlite-vec target
  - Add docker-sqlite-vec-* targets for Docker Compose

- **scripts/dev.sh**: Detect SQLITE_VEC environment variable
  - Set DIVINESENSE_DRIVER=sqlite when SQLITE_VEC=true
  - Automatically configure DSN for SQLite

- **docker/Dockerfile.sqlite-vec**: New Dockerfile for SQLite builds
  - Downloads sqlite-vec static library during build
  - Enables CGO for compilation
  - Includes runtime dependencies (libsqlite3-0)

- **docker/compose/sqlite-vec.yml**: Docker Compose for SQLite
  - Single-container deployment (no PostgreSQL)
  - Volume for SQLite database file
  - Environment variable configuration

- **docs/dev-guides/SQLITE_VEC_USAGE.md**: Complete usage guide
  - Local development instructions
  - Docker deployment examples
  - Cross-compilation guide
  - Troubleshooting section

This keeps PostgreSQL as the default (recommended for production) while
making SQLite + sqlite-vec easily accessible for development and
lightweight deployments.

Ref: PR #131

Problem: ensure-sqlite-vec was using 'go generate' which is unreliable
and failed to download the static library.

Error:
"clang: error: no such file or directory:
  '/Users/.../store/db/sqlite/.lib/libvec0.a'"

Solution: Call download_sqlite_vec.sh directly instead of go generate.

This matches the fix we applied to the CI workflow earlier.

Ref: PR #131

Problem: make start-sqlite-vec was still starting PostgreSQL container,
which is unnecessary and causes confusion.

Solution: Modify cmd_start() and cmd_stop() to skip PostgreSQL when
SQLITE_VEC=true.

Changes:
- cmd_start(): Check SQLITE_VEC before starting PostgreSQL
- cmd_stop(): Check SQLITE_VEC before stopping PostgreSQL
- Show database type in startup message

This makes SQLite mode truly standalone without requiring PostgreSQL.

Ref: PR #131

Problem: Frontend calls AIService.ListBlocks which fails in SQLite mode
with "AIBlock not supported in SQLite" error.

Root cause: AIBlock is the new unified conversation model from main branch.
PostgreSQL driver has full implementation, but SQLite driver only has
stub methods returning errors.

Temporary fix: Return empty list for ListAIBlocks to prevent frontend
errors while maintaining functionality.

Current SQLite implementation uses AIConversation instead of AIBlock.
Full AIBlock support for SQLite is tracked as a future task.

This allows sqlite-vec mode to function normally without crashing the
frontend on AIBlock API calls.

Note: Other AIBlock methods (Create, Update, Delete, etc.) still return
errors as they are not critical for basic functionality.

Ref: PR #131

- Remove duplicate .gitignore entry for SQLite-Vec static library
- Restore package filtering in ci-backend (exclude plugin/cron and proto)

These changes address issues found during code review:
1. Duplicate store/db/sqlite/.lib/ entries in .gitignore
2. ci-backend was testing all packages including problematic ones

Refs #131

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

- Delete ai_conversation.go (AIConversation is PostgreSQL-only)
- Add AIConversation stub methods to sqlite.go
- Add missing time package import
- Update SQLite support policy to align with main branch

AI features like conversation persistence (AIBlock/AIConversation)
require PostgreSQL. SQLite users should use PostgreSQL for full AI support.

Refs #131

PR #131 should only support vector search (semantic retrieval) for SQLite.
Other AI features (conversation persistence, episodic memory, user
preferences, metrics) require PostgreSQL.

Changes:
- Remove episodic_memory.go and agent_metrics.go
- Add stub methods returning "not supported" errors
- Simplify V0.54.0__add_ai_support.sql (only memo_embedding table)
- Update LATEST.sql (remove AI-specific tables)
- Update BACKEND_DB.md to clarify SQLite limitations

Users requiring full AI features (AIBlock, episodic memory, etc.)
must use PostgreSQL with pgvector extension.

Refs #131

- Update PR description to focus on vector search only
- Update SQLITE_VEC_USAGE_GUIDE.md with:
  - Clear function scope (current vs future)
  - Dependency change explanation (modernc.org/sqlite -> mattn/go-sqlite3)
  - Link to Issue #134 for full roadmap
- Update migration files with:
  - DROP TABLE statements for deprecated ai_conversation/ai_message
  - Notes about breaking changes and future PRs
- Update LATEST.sql with AI support policy header

This clarifies that SQLite only supports vector search (Phase 1),
with other AI features planned in subsequent PRs.

Refs #131, #134

Fixes #135

Root cause:
- sqlite_extension.go and sqlite_vec_loader.go use CGO-only APIs
  (sqlite3.SQLiteConn.LoadExtension)
- Docker builds use CGO_ENABLED=0 for static compilation
- These files were being compiled in non-CGO environment, causing:
  "LoadExtension undefined (type *sqlite3.SQLiteConn has no field or method)"

Solution:
Use build tags to separate CGO and non-CGO implementations:

1. sqlite_extension.go: !sqlite_vec && cgo
   - CGO environment: Load extension from dynamic library (.so/.dylib)
   - Non-CGO: Skip this file

2. sqlite_vec_loader.go: !sqlite_vec && cgo
   - CGO environment: Try multiple extension paths
   - Non-CGO: Skip this file

3. sqlite_extension_stub.go: !sqlite_vec && !cgo (NEW)
   - Non-CGO environment: Return error (use Go fallback)
   - CGO: Skip this file

Build matrix:
+------------+------------+----------------------+
| sqlite_vec | CGO       | Implementation        |
+------------+------------+----------------------+
| false      | true      | Dynamic loader       |
| false      | false     | Stub (Go fallback)   |
| true       | N/A       | Static linking       |
+------------+------------+----------------------+

Verification:
- ✅ CGO_ENABLED=0 build successful (Docker static build)
- ✅ CGO_ENABLED=1 build successful (standard build)
- ✅ sqlite-vec extension loads correctly (18 functions)
- ✅ Local testing passed
- ✅ No regression in existing functionality

Impact:
- Docker images can now build successfully
- Non-CGO builds use Go fallback for vector search
- CGO builds maintain full sqlite-vec support

Refs #135
Refs #131

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>

Fixes #135

Root cause:
- sqlite_extension.go and sqlite_vec_loader.go use CGO-only APIs
  (sqlite3.SQLiteConn.LoadExtension)
- Docker builds use CGO_ENABLED=0 for static compilation
- These files were being compiled in non-CGO environment, causing:
  "LoadExtension undefined (type *sqlite3.SQLiteConn has no field or method)"

Solution:
Use build tags to separate CGO and non-CGO implementations:

1. sqlite_extension.go: !sqlite_vec && cgo
   - CGO environment: Load extension from dynamic library (.so/.dylib)
   - Non-CGO: Skip this file

2. sqlite_vec_loader.go: !sqlite_vec && cgo
   - CGO environment: Try multiple extension paths
   - Non-CGO: Skip this file

3. sqlite_extension_stub.go: !sqlite_vec && !cgo (NEW)
   - Non-CGO environment: Return error (use Go fallback)
   - CGO: Skip this file

Build matrix:
+------------+------------+----------------------+
| sqlite_vec | CGO       | Implementation        |
+------------+------------+----------------------+
| false      | true      | Dynamic loader       |
| false      | false     | Stub (Go fallback)   |
| true       | N/A       | Static linking       |
+------------+------------+----------------------+

Verification:
- ✅ CGO_ENABLED=0 build successful (Docker static build)
- ✅ CGO_ENABLED=1 build successful (standard build)
- ✅ sqlite-vec extension loads correctly (18 functions)
- ✅ Local testing passed
- ✅ No regression in existing functionality

Impact:
- Docker images can now build successfully
- Non-CGO builds use Go fallback for vector search
- CGO builds maintain full sqlite-vec support

Refs #135
Refs #131

Co-authored-by: Claude Sonnet 4.5 <noreply@anthropic.com>