refactor(data): migrate QuickPhrase to Prompt with version management

[zhangjiadi225]

What this PR does

Before this PR:

• Quick phrases stored in Dexie (IndexedDB) with no version history
• No way to compare or rollback prompt changes
• Unused template variable definition system (variables field) added complexity

After this PR:

• Prompts stored in SQLite via Drizzle ORM with automatic version management
• Content changes auto-create version snapshots; rollback supported
• Quick panel supports version sub-menu for multi-version prompts
• Removed unused variables system, keeping only ${var} syntax in content

Why we need it and why it was done in this way

The following tradeoffs were made:

• Rollback creates a new version (append-only history) rather than reverting — ensures no history is ever lost
• Version selection in quick panel is temporary (doesn't change currentVersion) — keeps version management in settings page

The following alternatives were considered:

• Eager loading versions for all prompts — rejected in favor of lazy loading for performance

Breaking changes

Data migration from Dexie quick_phrases to SQLite prompt table runs automatically via PromptMigrator.

Checklist

• PR: The PR description is expressive enough
• Code: Write code that humans can understand and Keep it simple
• Refactor: Boy Scout Rule followed
• Documentation: Not required (internal data layer change)
• Self-review

Release note

Migrated Quick Phrases to Prompt Management system with automatic version history, rollback support, and version selection in the quick panel.

[DeJeune]

Note

This comment was translated by Claude.

Add unit tests for the key migrator

---

Original Content

关键的migrator加一下单元测试

[SiinXu]

Nice work on the migration and version management! A few things before detailed review:

Question: Variable design

The old QuickPhrase had a variables field (unused), and the current ${var} syntax in content is inserted as-is with no runtime substitution. Since this PR is redesigning the Prompt data model:

Have you considered the variable substitution story? How should ${var} placeholders work going forward?

Want to make sure the data model accounts for this before we merge.

Initial code observations

• Transaction safety: create(), update(), rollback(), and reorder() in PromptService are not wrapped in db.transaction() — risk of data inconsistency. The migrator correctly uses transactions, service methods should too.
• UNIQUE constraint: The composite index on prompt_version(promptId, version) should be uniqueIndex() to enforce version uniqueness at DB level.
• Nullable columns: currentVersion and sortOrder should have .notNull() constraints.

[zhangjiadi225]

[!NOTE] This comment was translated by Claude.

Thanks for the detailed reply! **Variable substitution**: Agreed — variable management should be designed as an independent global module, not tied to Prompts. The current `` syntax is just a simple design for this stage. Going forward, the variable system should serve as shared infrastructure across the entire application — Prompts, Agent system prompts, MCP configs, and other areas could all reference the same global variables with type constraints and usage history. **Code fixes**: Great catches. Will fix all three issues and push shortly. — Di Ge

…

--- <details> <summary>Original Content</summary> Thanks for the detailed reply! **Variable substitution**: Agreed — variable management should be designed as an independent global module, not tied to Prompts. The current `` syntax is just a simple design for this stage. Going forward, the variable system should serve as shared infrastructure across the entire application — Prompts, Agent system prompts, MCP configs, and other areas could all reference the same global variables with type constraints and usage history. **Code fixes**: Great catches. Will fix all three issues and push shortly. ...迪哥 ***@***.*** </details>