The data-classification extract/validate/check workflow has completed its
staged mission; only the code-generation pipeline remains in use.
- package.json: replace extract/validate/validate:gen/check:duplicates/all
with an echo notice; keep generate and generate:* intact
- rename the four retired scripts with a DO-NOT-USE- prefix (git mv)
- README: document the deprecation via a global notice, a status column on
the command table, renamed file references, and historical-section markers
Move all renderer source from src/renderer/src/* up one level to
src/renderer/*, removing the redundant nested src directory.
- Update path aliases (@renderer, @types, @logger, @data) and TanStack
Router paths in electron.vite.config.ts; update tsconfig.{json,web,node}
path mappings and include globs.
- Fix Vite root-relative script paths in the 8 renderer HTML entries.
- Update cross-process relative imports in main/preload (language,
apiServer models, preload index) to drop the /src segment.
- Switch renderer test imports of the logger mock to the @test-mocks alias.
- Update hardcoded renderer paths in scripts and their fixtures, lint
configs (eslint/oxlint/biome), CODEOWNERS, docs, and the data-classify tool.
- Convert deep (../../+) relative imports within the renderer to the
@renderer alias (69 files, 108 imports); keep single-level relatives.
- Fix doc links broken by the move and correct one pre-existing broken
link in naming-conventions.md.
packages/shared was never a real pnpm workspace package (no package.json); it was referenced only through the @shared TypeScript path alias. Relocate it under src/ via git mv (143 files, detected as pure renames).
Repoint the @shared alias and include globs to src/shared across electron.vite.config.ts, tsconfig.{json,node,web}.json and vitest.config.ts; update scripts/check-custom-exts.ts, scripts/update-languages.ts, the eslint.config.mjs generated-file globs, the data-classify generator output targets, .github/CODEOWNERS path rules, and CLAUDE.md/docs/source-comment references.
The @shared alias name is unchanged, so all 1403 @shared/* import sites resolve without modification. Verified with typecheck:node, typecheck:web and the full test suite (700 files, 9739 tests passing).
Boot config used to live at `userData/boot-config.json`, which is wrong
in two ways:
1. Chicken-and-egg: BootConfig is meant to hold settings that must be
read *before* the app data directory is determined (e.g. a future
`app.custom_data_dir` key). A file that decides where data lives
cannot itself live inside that data.
2. Real timing bug: `src/main/index.ts` imports the bootConfig module
(which constructs BootConfigService and calls `app.getPath('userData')`
immediately) before importing `./bootstrap`, where `initAppDataDir()`
actually rewrites the userData path. In packaged mode with a custom
`appDataPath`, BootConfigService was reading from the default Electron
userData rather than the user-configured one.
Move the file to `~/.cherrystudio/boot-config.json`, aligning with the
existing `HOME_CHERRY_DIR` pattern already used by `src/main/utils/init.ts`.
This is the same directory used by the legacy v1 `config/config.json`,
which BootConfig will eventually replace entirely.
No data migration is performed: existing users have at most a single
`disable_hardware_acceleration` boolean and will fall back to defaults
on first launch with the new location.
Test mock infrastructure (`tests/main.setup.ts` already mocks
`os.homedir()` to `/mock/home`) needed no changes — only the test path
constant was updated.
Signed-off-by: fullex <0xfullex@gmail.com>
### What this PR does
Before this PR:
The v2 migration system only supports ElectronStore and Redux as data
sources for preference migration. Dexie IndexedDB `settings` table (a
simple KV store used by the renderer for translate settings, pinned
models, etc.) has no migration path.
After this PR:
- Adds `DexieSettingsReader` that pre-loads the Dexie `settings` table
into memory for synchronous KV access, consistent with
`ElectronStoreReader` and `ReduxStateReader`
- Extends `MigrationContext` with a `dexieSettings` data source (makes
`createMigrationContext` async to pre-load the table)
- `PreferencesMigrator` now reads from `'dexie-settings'` source for
both simple and complex mappings
- `DEXIE_SETTINGS_MAPPINGS` is auto-generated into
`PreferencesMappings.ts` from `classification.json`'s new
`dexieSettings` section
- All generator scripts (`generate-migration.js`,
`generate-preferences.js`, `classificationUtils.js`) support
`dexieSettings` as a data source with priority-based deduplication
### Why we need it and why it was done in this way
The following tradeoffs were made:
- `DEXIE_SETTINGS_MAPPINGS` is integrated into `PreferencesMappings.ts`
(not a separate file) to keep all preference mapping exports in one
auto-generated file and simplify imports.
- `dexieSettings` priority is set to 2 (same as `localStorage`, below
`redux` at 3). If the same `targetKey` exists in both `redux` and
`dexieSettings`, redux wins — this is intentional since redux data is
typically more up-to-date.
- Dynamic keys (`image://`, `mcp:provider:*`) are explicitly excluded
from this path. They will be handled by dedicated migrators in future
PRs.
The following alternatives were considered:
- Generating a separate `DexieSettingsMappings.ts` file — rejected in
favor of consolidating all mappings into one file for simpler imports
and unified statistics.
Links to places where the discussion took place:
https://github.com/CherryHQ/cherry-studio/issues/10162
### Breaking changes
None.
### Special notes for your reviewer
- The `classification.json` `dexieSettings.settings` array is currently
empty (skeleton only). Actual key classifications will be added in
follow-up PRs.
- The architecture supports dynamic keys via
`DexieSettingsReader.keys()` prefix filtering, but dynamic key migrators
are out of scope for this PR.
- Source identifier in `PreferencesMigrator` uses `'dexie-settings'`
(with hyphen) to distinguish from the Dexie export reader
(`dexieExport`) used by `ChatMigrator`.
### Checklist
- [x] PR: The PR description is expressive enough and will help future
contributors
- [x] Code: [Write code that humans can
understand](https://en.wikiquote.org/wiki/Martin_Fowler#code-for-humans)
and [Keep it simple](https://en.wikipedia.org/wiki/KISS_principle)
- [x] Refactor: You have [left the code cleaner than you found it (Boy
Scout
Rule)](https://learning.oreilly.com/library/view/97-things-every/9780596809515/ch08.html)
- [ ] Upgrade: Impact of this change on upgrade flows was considered and
addressed if required
- [ ] Documentation: A [user-guide update](https://docs.cherry-ai.com)
was considered and is present (link) or not required. Check this only
when the PR introduces or changes a user-facing feature or behavior.
- [ ] Self-review: I have reviewed my own code (e.g., via
[`/gh-pr-review`](/.claude/skills/gh-pr-review/SKILL.md), `gh pr diff`,
or GitHub UI) before requesting review from others
### Release note
```release-note
NONE
```
---------
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
- Revised the documentation to clarify the purpose of target-key-definitions.json.
- Added detailed explanations for two main scenarios: complex migrations and pure additions for v2 features.
- Included examples for defining new preferences and highlighted the differences between complex migrations and pure additions.
- Suggested best practices for maintaining clarity in the description field.
Added detailed descriptions for the `targetKey` values associated with classified items in the README. Clarified the conditions under which items are migrated or excluded from the new system, improving documentation for better understanding of classification decisions.
Add infrastructure for complex preference migrations that support:
- Object splitting (1→N): One source object splits into multiple keys
- Multi-source merging (N→1): Multiple sources merge into targets
- Value calculation/transformation with pure functions
- Conditional mapping based on source values
New files:
- ComplexPreferenceMappings.ts: Mapping definitions and interfaces
- PreferenceTransformers.ts: Utility functions for transformations
- target-key-definitions.json: Target key override definitions
- Tests for both modules (43 tests total)
Modified:
- PreferencesMigrator.ts: Integrated complex mapping processing
with strict conflict detection
- generate-preferences.js: Merge classification.json with
target-key-definitions.json
- README.md: Updated documentation
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
- Add data-classify tools for data inventory extraction and code generation
- Include consolidated Chinese documentation (README.md)
- Update generated file path references
This temporary directory will be removed after V2 refactor is complete.
