# Hodios paste pack: Migration
Everything in Migration from Hodios, the open prompt library by Hermes IDE: 8 entries, catalog 2026.1003.0.
Every entry is dedicated to the public domain under CC0 1.0. Copy, change and share them freely, no attribution needed.
Browse and search the library at https://hermes-ide.com/prompts
## How to use
Find an entry below and copy the text inside its block into ChatGPT, claude.ai or any chat. Replace each [PLACEHOLDER] with your own material. Personas, rules and styles work best as custom instructions or project instructions.
## Contents
- Migration
- [Migrate JavaScript to TypeScript](#migrate-javascript-to-typescript) (prompt)
- [Plan a breaking API version change](#migrate-api-version) (prompt)
- [Plan a cloud migration](#plan-cloud-migration) (prompt)
- [Plan a database engine migration](#migrate-database-engine) (prompt)
- [Plan a monorepo migration](#plan-monorepo-migration) (prompt)
- [Plan an incremental migration](#plan-incremental-migration) (prompt)
- [Plan extracting a service from a monolith](#plan-monolith-extraction) (prompt)
- [Upgrade a major dependency](#upgrade-major-dependency) (prompt)
---
## Migrate JavaScript to TypeScript
`migrate-javascript-to-typescript` · prompt · Migration · https://hermes-ide.com/prompts/migrate-javascript-to-typescript
Plans and carries out an incremental JavaScript-to-TypeScript migration with config, file order, typed boundaries and a strictness ratchet. Use to move a JS codebase without a freeze.
````markdown
Big-bang TypeScript migrations stall: hundreds of files renamed at once, `any` sprinkled everywhere to get the build green, behaviour changes hidden in "type fixes", and a strict mode that is never turned on. Migrations that finish are incremental. JavaScript and TypeScript coexist, the most valuable boundaries are typed first, each batch is small and reviewable, and a CI guard makes the type safety only ever go up.
Migrate [REPO_AREA] to TypeScript, targeting strict type checking.
Phase 1, plan (no file changes yet):
1. Inspect the build: bundler or compiler, Babel or SWC usage, test runner, linter, module system (ESM or CommonJS), Node version, path aliases, and any existing JSDoc types or `.d.ts` files. Run the build and tests and record the baseline results.
2. Propose the `tsconfig.json`: `allowJs` on and `checkJs` off to start, `noEmit` if a bundler compiles, `module` and `moduleResolution` matching the runtime (`NodeNext` for Node, `Bundler` for bundled apps), `isolatedModules`, `skipLibCheck`, and the target. Wire type checking into CI and the test runner.
3. Order the conversion: shared types and module boundaries first (API clients, data models, configuration, the most-imported utilities), then leaf modules up the dependency graph. Group files into batches of about 10 to 20 that can each merge on their own.
4. Define the strictness ratchet. For strict: turn on `strict` early and track each suppression (`any`, `@ts-expect-error`) with a count that CI only allows to go down. For loose: turn on `noImplicitAny` and `strictNullChecks` per directory as batches finish, and stop there.
5. List untyped dependencies and whether `@types` packages exist; plan small local declaration files for the rest.
Stop after Phase 1 and wait for approval.
Phase 2, after approval:
6. Convert one batch at a time, starting with the first: rename each file with `git mv` so history follows, then add types derived from how the code is actually used (parameters, return types of exported functions, shared shapes as named types), using existing JSDoc as a starting point. Use `unknown` rather than `any` at external inputs and narrow it with runtime validation, and change no runtime behaviour.
7. After each batch, run the type checker, the tests and the linter, and report the real results. Fix the types, not the behaviour.
- Never mix behaviour changes into a conversion batch. If typing reveals a bug, record it under Bugs found and leave the behaviour as it is, unless the user asks you to fix it.
- Do not silence errors with `any` without counting it in the ratchet and adding a `// TODO(types): reason` comment. Use `@ts-expect-error` with a reason instead of `@ts-ignore`, and do not use non-null assertions only to silence errors.
- Keep module paths and public exports stable so callers outside the migrated area keep working.
- Prefer inferred types over annotations that repeat what the compiler already knows.
- Do only what was asked. If you notice something else worth changing, mention it in one line at the end instead of changing it.
- Keep the change as small as it can be while still being correct.
- Before saying the work is done, run the check that proves it (tests, build, type check or the command the user gave) and report the real result.
- If you could not run a check, say so plainly and say which one.
## Current state
Build, modules, test runner, file counts, and existing types.
## Config
The `tsconfig.json` and the build, test and CI changes, as diffs.
## Conversion order
A table: batch, files, why this order, estimated effort.
## Strictness ratchet
Flags by stage, the suppression budget, and the CI guard.
## Progress
(Phase 2 only) Table: batch, files, type check result, tests result, lint result, against the baseline.
## Escape hatches
(Phase 2 only) Bullets: `path:line` — `any` or `@ts-expect-error` — reason. Or "None".
## Bugs found
(Phase 2 only) Bullets: `path:line` — the bug — how it would surface. Not fixed. Or "None".
## Risks
Bullets: build tooling, runtime differences, and team habits to watch.
````
---
## Plan a breaking API version change
`migrate-api-version` · prompt · Migration · https://hermes-ide.com/prompts/migrate-api-version
Plans a breaking API version change with a deprecation timeline, compatibility shims, a client migration guide and adoption telemetry. Use before changing anything clients rely on.
````markdown
Breaking an API costs every client time and trust, so the best breaking change is the one avoided: additive fields, accepting both old and new forms, expand-then-contract. When a break is necessary, it succeeds when there is one implementation behind a translation layer, a published timeline with machine-readable deprecation signals, telemetry that shows exactly who still uses the old behaviour, and a migration guide good enough that clients can upgrade without opening a support ticket.
Plan this API change.
Current API:
[CURRENT_API]
Changes wanted:
[CHANGES]
1. Classify each change as breaking or non-breaking. Breaking includes removed or renamed fields and endpoints, type or format changes, new required inputs, stricter validation, changed defaults, changed status or error codes, changed pagination, ordering or semantics, and authentication changes.
2. For each breaking change, look for a non-breaking route first: add the new field beside the old one, accept both inputs, or put the new behaviour behind an opt-in. Only what remains needs a new version.
3. Versioning: follow the scheme already in use (URL path, header, media type or dated versions). Bundle the remaining breaks into one version rather than several.
4. Compatibility layer: keep one implementation and translate old requests and responses at the edge, so the old version costs little to keep. Say which changes cannot be translated.
5. Timeline: announcement, the new version available, deprecation signals on old-version responses (the `Deprecation` and `Sunset` HTTP headers plus a link to the guide), brownouts (short scheduled failures to surface forgotten clients), and the sunset date. Size the window to the slowest client: mobile apps and partner integrations need far longer than internal services.
6. Telemetry: usage by version, endpoint and client identity, plus use of the specific fields or behaviours being removed. Set adoption targets for each milestone and a plan for contacting the clients who lag behind.
7. Write the client migration guide: for each change, before and after examples of requests and responses, the code change, how to test, and the dates.
- Do not invent clients or usage numbers. If clients are unknown, make adding telemetry the first milestone and give no sunset date until data exists.
- Never move the sunset date earlier once announced.
- Write the guide for the client developer: plain language and examples, no internal reasoning.
- Do only what was asked. If you notice something else worth changing, mention it in one line at the end instead of changing it.
- Keep the change as small as it can be while still being correct.
## Change classification
A table: change, breaking (yes/no), who it affects, why.
## Avoid the break
For each breaking change, the non-breaking alternative or why there is none.
## Versioning
The decision and the version identifier.
## Compatibility layer
What is translated, where, and what cannot be.
## Timeline
A table: milestone, timing relative to announcement, what happens, communication.
## Telemetry
Metrics, dimensions, dashboards and adoption targets.
## Client migration guide
A ready-to-publish draft.
## Risks
Bullets with mitigations.
````
---
## Plan a cloud migration
`plan-cloud-migration` · prompt · Migration · https://hermes-ide.com/prompts/plan-cloud-migration
Plans moving workloads from on-premises or another cloud, classifying each with the 6 Rs and ordering waves by dependency and risk, with cutover, rollback and cost checks.
````markdown
Cloud migrations overrun for the same reasons: an inventory that misses the dependencies (a nightly job on a forgotten server, a hard-coded IP, a shared database), latency-sensitive pairs split across the data centre and the cloud for months, every workload treated as "lift and shift" or every workload treated as a rewrite, no landing zone ready before wave one, cutovers with no tested rollback, and a cloud bill nobody modelled. The standard frame is the "6 Rs" for each workload: rehost (lift and shift), replatform (lift and reshape, such as moving to a managed database), repurchase (replace with SaaS), refactor or re-architect, retire, and retain (keep where it is for now); AWS adds a seventh, relocate, for moving virtualised estates as-is. Waves are ordered by dependencies and risk: start with low-risk workloads that build the team's skills and the platform, and move tightly coupled groups together.
Plan the migration of this estate to [TARGET_CLOUD].
[INVENTORY]
1. Check the inventory for gaps that block planning: missing owners, dependencies, data sizes, criticality or licensing. List them, and continue with labelled assumptions; if the inventory is too thin to plan at all, ask for the minimum fields and stop.
2. Classify each workload with one of the Rs and a one-line reason. Prefer retire for anything with no clear owner or usage evidence (to be confirmed), retain for workloads blocked by licensing, hardware or compliance, rehost when the deadline dominates, replatform when a managed service removes real operational work, and refactor only where there is a business case beyond the move. Flag licences that may not transfer (for example per-core database or OS licences) for checking.
3. Map dependencies: which workloads call which, share databases or file systems, or depend on on-premises services (directory, DNS, mainframe, file shares). Identify groups that must move together because of latency or chatty traffic, and the hybrid connectivity needed in the meantime (VPN or dedicated interconnect, DNS, identity).
4. Plan waves: wave 0 for the landing zone (accounts or subscriptions, networking, identity, security baselines, logging, backup, cost tagging) and a pilot; then waves ordered by dependency groups, rising risk and criticality, with the most critical systems after the team has done several cutovers. Give each wave its workloads, R, rough duration, entry criteria and exit criteria. Fit the waves to the timeline and say plainly if it is not realistic.
5. For each wave, define cutover and rollback: data migration method (replication, backup and restore, offline transfer for large volumes, with the transfer time calculated from data size and bandwidth), the freeze window, the cutover steps, validation checks, the go or no-go criteria, how traffic switches (DNS with lowered TTLs ahead of time, load balancer weights), and the rollback trigger, steps and point of no return.
6. Add cost checks: what to estimate before each wave with the provider's pricing calculator (compute right-sized from measured utilisation rather than on-premises allocation, storage, data transfer and egress, licensing, the period of running both environments in parallel), and post-migration checks to compare actual against estimate.
7. List prerequisites and organisational work: skills and training, runbooks, monitoring in the new environment, security and compliance sign-offs, and decommissioning of old hardware and contracts.
- Do not invent prices, instance types, service limits or data sizes. Show how to estimate them and mark every number you did not get as an assumption.
- Do not recommend refactoring a workload just because it is moving; tie every refactor to a stated benefit.
- Do not split tightly coupled, latency-sensitive workloads across environments without stating the latency risk and the mitigation.
- Use [TARGET_CLOUD]'s own service names where you are confident of them; otherwise describe the service generically.
- Separate what you verified from what you inferred. Mark inferences as such.
- When you do not know, say "I don't know" once and state what would settle it.
## Summary
Number of workloads per R, number of waves, the critical path and whether the timeline is realistic, in at most 6 lines.
## Workload decisions
Table: workload, owner, R, reason, target service, data size, criticality, notes.
## Dependency map
A Mermaid flowchart of the main dependencies and move-together groups, then the hybrid connectivity needed.
## Waves
Table: wave, workloads, duration, entry criteria, exit criteria.
## Cutover and rollback
Per wave: data method with transfer-time arithmetic, cutover steps, validation, go or no-go criteria, rollback trigger and point of no return.
## Cost checks
Checklist before and after each wave.
## Prerequisites
Checklist.
## Risks and open questions
Numbered, each with an owner and what it affects.
````
---
## Plan a database engine migration
`migrate-database-engine` · prompt · Migration · https://hermes-ide.com/prompts/migrate-database-engine
Plans a move between database engines, such as MySQL to Postgres, covering incompatibilities, data copy, cutover, verification and rollback. Use before committing to a migration date.
````markdown
Engine migrations rarely fail on the bulk copy. They fail on semantics that differ quietly: case-insensitive comparisons that become case-sensitive, zero dates and unsigned integers with no equivalent, sequences not reset after the load, different default isolation levels, query plans that change for the worst queries, and a cutover with no tested way back. A credible plan finds those differences before the copy and makes the cutover boring.
Plan a migration from [SOURCE] to [TARGET].
Data size and write rate:
Downtime budget:
1. If the data size or downtime budget is blank, or you do not have the schema, ask for them under "Inputs needed" and write the rest of the plan with each dependent choice labelled as an assumption. Ask also for the features in use (stored procedures, triggers, full-text search, JSON, spatial), the application stack and ORM, and the top queries by load.
2. Audit incompatibilities for this pair of engines: data types (booleans, unsigned integers, date and time zones, zero dates, enums, text and binary sizes), character sets and collations including case sensitivity, auto-increment versus identity or sequences, NULL versus empty-string handling, SQL dialect (upsert, limit, group-by strictness, quoting, functions), procedures and triggers, full-text search, JSON operators, default transaction isolation and locking behaviour, and implicit casts.
3. Choose the copy approach from size and downtime: an offline dump and load when the window allows; otherwise a bulk load followed by change data capture to stay in sync until cutover. Name candidate tools and why. Avoid application dual-writes unless you explain how consistency is guaranteed.
4. Phase the work: schema conversion, a test load, application changes behind a switch, performance testing of the top queries on the target, a rehearsal of the full cutover, then production.
5. Write the cutover runbook: stop or freeze writes, drain replication lag to zero, verify, reset sequences, switch connections, smoke test, decision point. Give each step an owner role and duration, and compare the total to the downtime budget.
6. Verification: row counts per table, checksums per chunk on normalised values, sampled row comparison, and application-level comparison of read results.
7. Rollback: how to return to the source after writes have landed on the target (reverse replication or a replay plan), the triggers for rolling back, and the deadline after which you roll forward instead.
- Be specific to [SOURCE] and [TARGET]. Do not list incompatibilities that do not apply to this pair.
- Do not invent table names or sizes. Use the information given and label assumptions.
- A cutover without a rehearsed rollback is a risk to state plainly, not a footnote.
- Separate what you verified from what you inferred. Mark inferences as such.
- When you do not know, say "I don't know" once and state what would settle it.
## Summary
Approach, expected downtime, and the top three risks.
## Inputs needed
Bullets, or "None".
## Incompatibilities
A table: area, behaviour in the source, behaviour in the target, action.
## Approach
The copy method and tools, and why.
## Phases
A table: phase, work, exit criteria.
## Cutover runbook
Numbered steps with owner role and duration, plus the go or no-go checks.
## Verification
The checks and their pass criteria.
## Rollback
The mechanism, triggers and deadline.
## Risks
Bullets with mitigations.
````
---
## Plan a monorepo migration
`plan-monorepo-migration` · prompt · Migration · https://hermes-ide.com/prompts/plan-monorepo-migration
Plans moving several repositories into a monorepo, covering history preservation, build tooling, CI, code ownership and a staged rollout. Use before consolidating repositories.
````markdown
A monorepo pays off when code that changes together lives together: atomic cross-project changes, one dependency version per library, shared tooling. It costs build and CI work: without affected-only builds and caching, every pull request runs everything and the team blames the monorepo. Migrations fail when history is squashed and blame is lost, when CI is ported job by job without change detection, when release processes that assumed one repo per artifact break silently, and when everything moves in one weekend. A good plan checks the decision, moves one repository at a time and keeps the old repositories read-only until the new path is proven.
Plan the migration of these repositories:
[REPOS]
1. **Decision check.** In a few bullets, say whether the repositories share enough change, dependencies and ownership to justify a monorepo, and name any repository that should stay out (different access needs, open source with an external community, very large binaries, a separate compliance boundary). If the input lacks what you need to judge, say so.
2. **Target layout.** A directory tree (`apps/`, `packages/` or `services/`, `libs/`, `tools/`), naming conventions, and how internal dependencies are referenced (workspace protocol, path dependencies) instead of published versions.
3. **Tooling.** Recommend the build tool from the languages, size and preference, with the reason and what it must provide: a project graph, affected-only builds and tests, local and remote caching, and task pipelines. Show the root configuration skeleton.
4. **History.** Preserve history by importing each repository into its subdirectory (for example with `git filter-repo --to-subdirectory-filter` and a merge with `--allow-unrelated-histories`), keep or prefix tags, and handle large files and secrets found in history before import. Say how `git log --follow` and blame will work afterwards.
5. **CI and releases.** Path-based or graph-based change detection, required checks per project, cache strategy, and a CI time budget. For releases: per-project versioning and tags, changelog generation, and how each artifact's existing release pipeline is pointed at its subdirectory.
6. **Ownership.** CODEOWNERS per directory, branch protection, and review rules for shared libraries.
7. **Rollout.** Order the repositories (start with the one with the fewest dependents or the most cross-repo changes, say which and why), a pilot, a freeze window per repository, the cutover steps, redirects (archive the old repository with a pointer in its README, move open pull requests and issues), and rollback while the old repository is still intact.
8. Name risks with mitigation, and the metrics that show success (CI time per pull request, cross-project change lead time).
- Commands that rewrite history only ever run on fresh clones; say so next to them. Never on the original repositories.
- Do not recommend a tool feature you are not sure exists; describe the capability and say "check the tool's documentation".
- Do not invent repository sizes, team names or dependency versions.
- Keep each rollout step reversible until the old repository is archived.
- Separate what you verified from what you inferred. Mark inferences as such.
- When you do not know, say "I don't know" once and state what would settle it.
## Decision check
Bullets, ending with go, go with exclusions, or reconsider.
## Target layout
A tree in a fenced block, plus conventions.
## Tooling
Recommendation, reasons, root config skeleton.
## History
Numbered commands per repository, with the fresh-clone warning.
## CI and releases
Bullets and a pipeline sketch.
## Ownership
A CODEOWNERS sketch and rules.
## Rollout
A table: phase, repositories, steps, exit criteria, rollback.
## Risks
A table: risk, likelihood, mitigation.
## Open questions
Numbered.
````
---
## Plan an incremental migration
`plan-incremental-migration` · prompt · Migration · https://hermes-ide.com/prompts/plan-incremental-migration
Plans a framework, platform or system migration as small reversible phases using the strangler fig pattern, with data strategy, verification and rollback per phase. Use instead of a big-bang rewrite.
````markdown
Big-bang migrations freeze feature work, pile up risk until a single cutover, and are hard to undo. Incremental migrations move one slice at a time behind a seam, run old and new side by side where needed, and keep every step shippable and reversible. The plan has to make each step's verification and rollback explicit, because that is where migrations actually fail.
Plan the migration from [CURRENT] to [TARGET].
1. Goal: state why the migration is happening, the definition of done (including when the old system is switched off), and the non-goals.
2. Current state: inventory the parts to move (modules, endpoints, jobs, data stores, integrations), how they depend on each other, and who owns them. If you can read the repository, build this from the code; otherwise use the context and mark gaps.
3. Approach: choose the seam technique for each part and say why: routing proxy (strangler fig), branch by abstraction, adapter or anti-corruption layer, or parallel run with result comparison. Say when a full rewrite of a part is cheaper, and why.
4. Phases: order the slices so the first one is thin, end to end and low risk but teaches the most. For each phase give entry criteria, the work, how it is verified (tests, shadow traffic, comparing outputs, metrics), how it is rolled back, and exit criteria.
5. Data: plan any data move with expand and contract steps (add new, dual write or backfill, verify, switch reads, remove old), how consistency is checked, and the point after which rollback needs a data fix.
6. Decommissioning: what gets deleted and when, so the old system does not live forever.
- Every phase must leave production working and be reversible. Call out any one-way step explicitly, with what makes it safe.
- No big-bang cutover unless the part is small enough that a rollback is cheap; justify it when you choose one.
- Do not invent system sizes, traffic or dates. Use the numbers given and mark assumptions.
- Keep feature work possible during the migration, or say plainly when it must pause and for how long.
- Separate what you verified from what you inferred. Mark inferences as such.
- When you do not know, say "I don't know" once and state what would settle it.
## Goal and definition of done
## Current state
Bullets or a small table, with gaps marked.
## Approach
Per part: technique — reason.
## Phases
Numbered. Each: goal — entry criteria — work — verification — rollback — exit criteria.
## Data
Expand and contract steps, consistency checks, point of no easy return.
## Risks and open questions
Numbered: risk or question — what it affects — mitigation or who answers it.
````
---
## Plan extracting a service from a monolith
`plan-monolith-extraction` · prompt · Migration · https://hermes-ide.com/prompts/plan-monolith-extraction
Plans extracting one capability from a monolith with the strangler-fig pattern, covering seams, data ownership, traffic shifting and rollback at every step. Use before splitting a service out.
````markdown
Most extractions that go wrong end as a distributed monolith: a new service that still shares the old database, makes chatty synchronous calls back into the monolith, and must deploy in lockstep with it. The strangler-fig pattern avoids this by first carving a clean seam inside the monolith, then moving ownership of the data, then shifting traffic gradually with a rollback at every step. The hardest part is almost always the data, not the code.
Plan extracting this capability:
[CAPABILITY]
from this monolith:
[MONOLITH]
1. Should you extract? Weigh the stated motivation (independent deploys, team autonomy, scaling or isolation needs) against the cost (network calls, consistency, operations, on-call). If a modular boundary inside the monolith would solve the problem, say so plainly and give the plan anyway, so the team can decide.
2. Map the current state: code entry points, inbound callers, outbound dependencies, and the tables the capability writes, reads, and shares with other modules. Where the description is not enough, list what to find in the code under Open questions.
3. Define the target boundary: the service's API or events, which calls become asynchronous, and the consistency each caller gets.
4. Plan data ownership: which tables move, a single writer for every table at every phase, how other modules that read these tables switch to the API or to events, and how data stays in sync during transition (change data capture or a transactional outbox). Replace cross-boundary transactions with sagas or compensating actions where needed.
5. Phase the work, each phase shippable and reversible:
- Build a seam inside the monolith (branch by abstraction) and route all access through it.
- Stand up the service behind a routing facade, running in shadow mode with results compared.
- Move reads, then writes, by percentage or by tenant.
- Move data ownership, then remove the old code and tables.
6. For each phase, give exit criteria and the rollback.
7. List operational readiness: monitoring and SLOs, on-call ownership, contract tests, versioning, and runbooks.
- Never leave two writers on the same table across the boundary, and never share a database between the monolith and the new service as the end state.
- Avoid a big-bang cutover. Every traffic shift must be adjustable in minutes.
- Use only the facts given; mark assumptions about code and data as assumptions.
- Separate what you verified from what you inferred. Mark inferences as such.
- When you do not know, say "I don't know" once and state what would settle it.
## Should you extract
A recommendation (extract, modularise first, or do not extract) with the reasoning.
## Current state
Callers, dependencies and tables, plus a Mermaid diagram.
## Target boundary
API or event contracts in outline, and the consistency model.
## Data ownership
A table: table, current writers, current readers, owner after migration, sync method during transition.
## Phases
A table: phase, change, exit criteria, rollback.
## Traffic shifting
Mechanism, increments, metrics compared, and abort conditions.
## Risks
Bullets, including the distributed-monolith traps specific to this capability.
## Open questions
What to confirm in the code or with the teams.
````
---
## Upgrade a major dependency
`upgrade-major-dependency` · prompt · Migration · https://hermes-ide.com/prompts/upgrade-major-dependency
Upgrades a library or framework across major versions using the official migration notes, fixes what breaks, and proves the result with before-and-after checks. Use for any breaking upgrade.
````markdown
Major upgrades fail in two ways: breaking changes that nobody noticed until production, and "fixes" that silence the compiler or the tests instead of adapting the code. Model memory of a library's breaking changes is often out of date, so the upgrade must follow the official release notes, and success must be shown by the same checks passing before and after.
Upgrade [DEPENDENCY] to the latest stable release.
1. Find the current version in the manifest and lockfile, every place the code uses the dependency, and the packages that depend on it or must move with it (plugins, type packages, peer dependencies).
2. Get the official changelog or migration guide for every major version between the current and the target. Fetch it if you can; otherwise ask the user to paste it and stop until they do. Do not rely on memory for the list of breaking changes.
3. Run the project's build, type check, linter and tests before changing anything, and record the results as the baseline. Find the commands in the repo's scripts or docs.
4. Match each breaking change against the code and list the ones that apply, with the affected files.
5. Upgrade with the project's package manager, one major version at a time when several are skipped, together with the packages that must move with it. Use the official codemod when one exists, then review its output.
6. Fix compile errors first, then failing tests, then deprecation warnings that the target version turns into errors.
7. Run the same checks as the baseline and compare.
- Upgrade only what this upgrade requires. No unrelated version bumps, refactors or formatting.
- Never edit the lockfile by hand; let the package manager write it.
- Do not silence problems: no new `any` casts, ignore comments, disabled lint rules, skipped tests or pinned sub-dependencies to work around a breaking change.
- If a breaking change has no safe equivalent, or a behaviour change needs a product decision, stop and ask.
- Fix the behaviour, not the test. Never special-case test inputs, weaken assertions or skip tests to make a check pass.
- If a test looks wrong, explain why and ask before changing it.
- Before saying the work is done, run the check that proves it (tests, build, type check or the command the user gave) and report the real result.
- If you could not run a check, say so plainly and say which one.
- Do only what was asked. If you notice something else worth changing, mention it in one line at the end instead of changing it.
- Keep the change as small as it can be while still being correct.
## Summary
One line: from version, to version, and whether all checks pass.
## Breaking changes that applied
Table: change (with a link or reference to the release notes), affected files, how it was fixed.
## Changes made
Bullets, grouped by file or area.
## Verification
Table: check, command, before, after.
## Follow-ups
Deprecations left for later, behaviour changes to watch in production, and anything you could not verify.
````