Make the configuration migration idempotent
Running the migration twice wraps an already migrated call again. Recognize new syntax and preserve it.
- Focused work estimate
- 2h + prerequisites
- Priority in the scenario
- Medium
- Engineering practice
- Refactoring · Idempotency
Estimated field mix
- Compiler and language tooling80%
- Developer tooling20%
Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence.
Review it, then add it to your workspace.
The board opens an editable draft; nothing is saved until you confirm it. Sign-in and workspace permissions apply, and Demo boards remain ephemeral.
Project context
Fictional package Laurel replaces configure(name, options) with configure({name, options}). Build synthetic TypeScript-like AST fixtures or use the repository's installed parser; source is analyzed, never executed.
Setup prerequisites
- Create synthetic supported and ambiguous call-site fixtures.
- Define the exact old/new API contract and a dedicated output directory.
Preceding work
Complete these dependencies, or supply their agreed outputs before taking this ticket.
- CMIGR-101 · Identify deprecated configuration imports by resolved binding
- CMIGR-102 · Exclude comments and string literals from configuration migration candidates
- CMIGR-103 · Report ambiguous configuration calls for manual review
- CMIGR-104 · Transform the supported configuration call shape without reordering evaluation
- CMIGR-105 · Preserve configuration-call comments during transformation
Acceptance criteria
- Second run produces no diff
- Mixed old/new files transform eligible old calls
- Unrelated object arguments remain unchanged
Implementation constraints
- Idempotence is checked on printed source as well as AST.
Verification to include
- Run twice on migrated fixture
- Run on mixed file
Deliverables
- Idempotency cases and migration guard
Rollout and recovery
Stop repeated application if the second run changes output.
Value of the work
For the engineer: Practice conservative automated refactoring and reviewable uncertainty.
For the team: Inspect whether migration automation reduces repetitive work without silent semantic changes.
Evidence boundaries
Outcome Evidence: Tests, patches, and runbooks are requested deliverables. They become Outcome Evidence only through a qualified Mission and immutable Evidence IDs.
Ownership Evidence: Independent adaptation must be observed under a declared verification policy and cite immutable Evidence IDs. Completing a planning ticket establishes no Ownership Evidence.