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:
1 parent
b80531f8a8
commit
bac7b5591e
738 files changed
+138513
-138123
No files matched your search
@@ -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
|
||||
@@ -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).
|
||||
Reference in new issue
Block a user