Apply configuration migration files with stale-input protection
A developer edits a file after preview and apply overwrites it. Compare the original digest before replacement.
- Focused work estimate
- 3h + prerequisites
- Priority in the scenario
- High
- Engineering practice
- Concurrency · Filesystem
Estimated field mix
- Developer tooling50%
- Compiler and language tooling30%
- Storage systems20%
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
- CMIGR-106 · Make the configuration migration idempotent
- CMIGR-107 · Reject overlapping configuration source edits before writing
- CMIGR-108 · Preview configuration migration changes before applying them
Acceptance criteria
- Matching source applies
- Changed source is rejected
- Failed replacement preserves recoverable original
Implementation constraints
- Restrict writes to the explicit fixture root.
Verification to include
- Apply unchanged preview
- Modify file before apply
Deliverables
- Guarded writer and failure cases
Rollout and recovery
Restore preserved original only after checking target identity.
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.