ワンクリックで
migration-scripts
// Use when writing or reviewing database/config migration scripts or migration registries. Enforces frozen-snapshot migrations, safe registration, and lean import boundaries.
// Use when writing or reviewing database/config migration scripts or migration registries. Enforces frozen-snapshot migrations, safe registration, and lean import boundaries.
Test browser extensions in real browsers using built artifacts, Edge + Playwright automation, runtime-message triggering, DOM debugging, and truthful screenshot capture.
Create a pull request, optionally for the issue provided as argument
Prepare all work before creating a pull request, optionally for the issue provided as argument
| name | migration-scripts |
| description | Use when writing or reviewing database/config migration scripts or migration registries. Enforces frozen-snapshot migrations, safe registration, and lean import boundaries. |
| metadata | {"author":"read-frog","version":"1.1.0"} |
Migration scripts must NEVER import or reference:
any for migration input/output)createXxx()Why: The codebase evolves. A migration written today references code that may change tomorrow. When that constant changes, the migration silently breaks — it now migrates to the new shape, not the shape that existed when the migration was written.
In this repo, config migration registries should auto-discover migration files from src/utils/config/migration-scripts/v*-to-v*.ts (for example via import.meta.glob), and the registry must:
fromVersion and toVersion from the filenamev001-to-v003Do not silently map only the target version and assume filenames are correct.
Do not let generic config read helpers or content-script paths import migration registries unless they really perform migration.
Prefer to isolate migration-aware reads/writes into dedicated modules for import/sync/restore flows, so normal runtime paths do not bundle all migration scripts unnecessarily.
src/)anyfrom -> to continuity and duplicate targets