Renderizado do repositório de origem, preservando títulos, exemplos, código, tabelas, links e imagens.
Upgrading EmDash
Use upgrade-emdash to resolve the selected npm release tag, update every direct EmDash package, refresh the EmDash skills, and create the project-specific work order. The updater does not edit application code, apply database migrations, or deploy.
Prepare the work order
Run from the project root:
npx upgrade-emdash@latest --dry-run
npx upgrade-emdash@latestUse --to <tag> for another npm dist-tag such as next or beta. --to does not accept a version. Use --yes to accept the updater prompt in a non-interactive environment, --json for a machine-readable dry-run, and --cwd <path> when the project root is elsewhere.
The updater writes .emdash/UPGRADE.md. Read that file after the command finishes. It contains the complete authored changelog entries crossed by the direct packages in this project, with generated dependency-bump entries removed, plus the exact core migration delta found after installation.
Complete the upgrade
- Inspect the existing project and its uncommitted changes. Preserve unrelated work.
- Assess every release entry in
.emdash/UPGRADE.mdagainst the project. Apply required source and configuration changes. Do not adopt a new feature when the project does not use the affected surface. - Run the repository's relevant format, tests, typecheck, and build commands.
- Run the migration status command from the work order and report the target database and pending migrations.
- When the work order lists added core migrations, the status command reports an earlier pending migration, or a release entry requires a data-changing project action, follow the work order's backup procedure before starting or deploying the upgraded application.
- Ask before applying a migration to a database, deploying, or making any other remote change unless the user explicitly included that action in the request.
- After authorized migration and deployment work, run the migration check and verify the affected site paths.
Treat core migrations as forward-only. A package update with no added or pending migrations does not require an upgrade-specific recovery point. Before an authorized database-changing step, require a restorable database backup created with Backups and recovery, a separate media backup, the relevant encryption keys, and the same build artifact for migration and deployment. A JSON backup is not a recovery point. Roll back by restoring the matching database and application artifact together, not by running migration down() functions or deleting migration records.
