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

This commit is contained in:
Gemini Nexus Bot committed 2026-04-28 03:49:34 -03:00
1 parent b80531f8a8
commit bac7b5591e
738 files changed
+138513 -138123

No files matched your search

+35 -35
View File
@@ -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.
@@ -1,17 +1,17 @@
# Change: Refactor SQLite Access with Drizzle ORM
## Why
Current `better-sqlite3` usage relies heavily on `any/as`, lacks unified typing and runtime validation, and increases long-term maintenance cost. Introducing Drizzle ORM provides structured schema definitions and more consistent type constraints.
## What Changes
- Introduce Drizzle ORM and define schema for the internal database.
- Incrementally migrate read/write paths in `cloudHandler` and `database/handler`.
- Preserve existing WAL, `busy_timeout`, and transaction behavior to avoid regressions.
- Keep runtime validation and compatibility logic for the external IDE DB (`ItemTable`).
## Impact
- Affected code: `src/ipc/database/cloudHandler.ts`, `src/ipc/database/handler.ts`, tests, and DB utility layer
- Affected behavior: data-access typing and runtime validation approach changes (regression validation required)
# Change: Refactor SQLite Access with Drizzle ORM
## Why
Current `better-sqlite3` usage relies heavily on `any/as`, lacks unified typing and runtime validation, and increases long-term maintenance cost. Introducing Drizzle ORM provides structured schema definitions and more consistent type constraints.
## What Changes
- Introduce Drizzle ORM and define schema for the internal database.
- Incrementally migrate read/write paths in `cloudHandler` and `database/handler`.
- Preserve existing WAL, `busy_timeout`, and transaction behavior to avoid regressions.
- Keep runtime validation and compatibility logic for the external IDE DB (`ItemTable`).
## Impact
- Affected code: `src/ipc/database/cloudHandler.ts`, `src/ipc/database/handler.ts`, tests, and DB utility layer
- Affected behavior: data-access typing and runtime validation approach changes (regression validation required)
@@ -1,21 +1,21 @@
## ADDED Requirements
### Requirement: Use Drizzle ORM for Internal Database
The system SHALL use Drizzle ORM to access the internal database (`cloud_accounts.db`) and provide type constraints through schema.
#### Scenario: Read cloud account list
- **WHEN** the system reads the `accounts` table
- **THEN** returned data SHALL match Drizzle schema types
### Requirement: Keep Compatibility and Validation for External IDE Database
The system SHALL preserve compatibility logic and runtime validation when accessing the external IDE database (`ItemTable`).
#### Scenario: Read ItemTable key
- **WHEN** reading a specific key from `ItemTable`
- **THEN** data that fails validation SHALL be logged as warning and skipped
### Requirement: Maintain Database Connection Stability
The system SHALL preserve existing WAL, `busy_timeout`, and transaction strategies to avoid migration regressions.
#### Scenario: Transactional write consistency
- **WHEN** executing write operations
- **THEN** related updates SHALL be committed within the same transaction
## ADDED Requirements
### Requirement: Use Drizzle ORM for Internal Database
The system SHALL use Drizzle ORM to access the internal database (`cloud_accounts.db`) and provide type constraints through schema.
#### Scenario: Read cloud account list
- **WHEN** the system reads the `accounts` table
- **THEN** returned data SHALL match Drizzle schema types
### Requirement: Keep Compatibility and Validation for External IDE Database
The system SHALL preserve compatibility logic and runtime validation when accessing the external IDE database (`ItemTable`).
#### Scenario: Read ItemTable key
- **WHEN** reading a specific key from `ItemTable`
- **THEN** data that fails validation SHALL be logged as warning and skipped
### Requirement: Maintain Database Connection Stability
The system SHALL preserve existing WAL, `busy_timeout`, and transaction strategies to avoid migration regressions.
#### Scenario: Transactional write consistency
- **WHEN** executing write operations
- **THEN** related updates SHALL be committed within the same transaction
+19 -19
View File
@@ -1,19 +1,19 @@
## 1. Scope and Migration Confirmation
- [x] 1.1 Confirm migration scope (internal DB vs external IDE DB).
- [x] 1.2 Confirm Drizzle driver choice (keep `better-sqlite3`).
- [x] 1.3 Confirm no changes to existing database schema.
## 2. Design and Preparation
- [x] 2.1 Build Drizzle schema (`accounts`/`settings`/`ItemTable`).
- [x] 2.2 Define connection initialization and pragma strategy (WAL, `busy_timeout`).
- [x] 2.3 Define runtime validation strategy (external IDE DB, loose compatibility).
## 3. Implementation
- [x] 3.1 Migrate read/write paths in `cloudHandler.ts`.
- [x] 3.2 Migrate read/write paths in `database/handler.ts`.
- [x] 3.3 Preserve existing transaction and retry semantics.
## 4. Testing and Verification
- [x] 4.1 Update unit tests and mocks.
- [ ] 4.2 Run regression checks for account backup/restore and injection flow.
- [ ] 4.3 Complete cross-platform smoke verification (Win/macOS/Linux).
## 1. Scope and Migration Confirmation
- [x] 1.1 Confirm migration scope (internal DB vs external IDE DB).
- [x] 1.2 Confirm Drizzle driver choice (keep `better-sqlite3`).
- [x] 1.3 Confirm no changes to existing database schema.
## 2. Design and Preparation
- [x] 2.1 Build Drizzle schema (`accounts`/`settings`/`ItemTable`).
- [x] 2.2 Define connection initialization and pragma strategy (WAL, `busy_timeout`).
- [x] 2.3 Define runtime validation strategy (external IDE DB, loose compatibility).
## 3. Implementation
- [x] 3.1 Migrate read/write paths in `cloudHandler.ts`.
- [x] 3.2 Migrate read/write paths in `database/handler.ts`.
- [x] 3.3 Preserve existing transaction and retry semantics.
## 4. Testing and Verification
- [x] 4.1 Update unit tests and mocks.
- [ ] 4.2 Run regression checks for account backup/restore and injection flow.
- [ ] 4.3 Complete cross-platform smoke verification (Win/macOS/Linux).