style(design): apply Minimal Dark Mode design system\n\n- Switched to complete Dark Mode (OLED-friendly)\n- Established standard color palette matching modern technical aesthetics\n- Changed font to Plus Jakarta Sans for increased legibility\n- Enforced dark mode as default in App.tsx\n- Fixed several React cascading render (setState in useEffect) warnings

openspec/changes/refactor-db-drizzle/design.md

@@ -1,35 +1,35 @@
-## Context
-Current SQLite access mainly relies on native `better-sqlite3` APIs, without unified typing and runtime validation strategy. This raises maintenance cost and regression risk. Introducing Drizzle ORM aims to improve type safety and maintainability while preserving existing behavior and compatibility.
-
-## Goals / Non-Goals
-- Goals:
-  - Provide structured schema and type inference
-  - Unify DB access and validation patterns, reducing `any/as`
-  - Preserve WAL, `busy_timeout`, transactions, and compatibility logic
-- Non-Goals:
-  - Do not change existing database schema
-  - Do not introduce a new database engine or remote storage
-
-## Decisions
-- Decision: Adopt Drizzle ORM while keeping `better-sqlite3` as the driver.
-- Decision: Keep runtime validation and compatibility logic for external IDE DB (`ItemTable`).
-- Decision: Migrate in order: internal DB first, external DB second.
-
-## Alternatives Considered
-- Continue with `better-sqlite3 + Zod`: limited type-safety gains and higher long-term maintenance cost.
-- Prisma: heavyweight footprint and higher Electron integration cost.
-
-## Risks / Trade-offs
-- Packaging compatibility risk (Electron + native module ABI): requires cross-platform validation.
-- Temporary complexity increase while dual stacks coexist during migration.
-- Drizzle provides static typing only; runtime validation is still required to avoid dirty data.
-
-## Migration Plan
-1. Define Drizzle schema (`accounts`/`settings`/`ItemTable`).
-2. Migrate `cloudHandler.ts` (internal DB).
-3. Migrate `database/handler.ts` (external IDE DB).
-4. Update unit tests and mocks.
-5. Run cross-platform smoke verification.
-
-## Open Questions
-- Loose compatibility mode is confirmed; stronger runtime schema is not introduced for now.
+## Context
+Current SQLite access mainly relies on native `better-sqlite3` APIs, without unified typing and runtime validation strategy. This raises maintenance cost and regression risk. Introducing Drizzle ORM aims to improve type safety and maintainability while preserving existing behavior and compatibility.
+
+## Goals / Non-Goals
+- Goals:
+  - Provide structured schema and type inference
+  - Unify DB access and validation patterns, reducing `any/as`
+  - Preserve WAL, `busy_timeout`, transactions, and compatibility logic
+- Non-Goals:
+  - Do not change existing database schema
+  - Do not introduce a new database engine or remote storage
+
+## Decisions
+- Decision: Adopt Drizzle ORM while keeping `better-sqlite3` as the driver.
+- Decision: Keep runtime validation and compatibility logic for external IDE DB (`ItemTable`).
+- Decision: Migrate in order: internal DB first, external DB second.
+
+## Alternatives Considered
+- Continue with `better-sqlite3 + Zod`: limited type-safety gains and higher long-term maintenance cost.
+- Prisma: heavyweight footprint and higher Electron integration cost.
+
+## Risks / Trade-offs
+- Packaging compatibility risk (Electron + native module ABI): requires cross-platform validation.
+- Temporary complexity increase while dual stacks coexist during migration.
+- Drizzle provides static typing only; runtime validation is still required to avoid dirty data.
+
+## Migration Plan
+1. Define Drizzle schema (`accounts`/`settings`/`ItemTable`).
+2. Migrate `cloudHandler.ts` (internal DB).
+3. Migrate `database/handler.ts` (external IDE DB).
+4. Update unit tests and mocks.
+5. Run cross-platform smoke verification.
+
+## Open Questions
+- Loose compatibility mode is confirmed; stronger runtime schema is not introduced for now.