Migration

Shared rules

Store records in .migration/ at the project root, named YYYY-MM-DD-short-title.md.
pending/ contains outstanding execution, recovery, or verification.
completed/ contains permanent history of verified final outcomes with no outstanding work.
Follow the template hierarchy: concise change summary, then grouped operational details in short bullets. Omit empty or inapplicable fields, instructions, extra sections, and repeated information.
Include only details that define the change, affect execution, recovery, or verification, or explain the outcome.
State decisions as standalone facts. Exclude conversation history, speaker attribution, assistant narration, and drafting commentary.
Never include secret values, credentials, or filesystem paths in records. Identify targets and resources by stable logical names.
Resolve questions from code, records, and target state. Ask the user only for information or decisions that cannot be established independently.

Inspect the relevant implementation and existing records. Defer migration implementation until Execute.
Read and follow the Pending template to create a record or update the existing entry for the same migration.
Delete an obsolete pending record only if execution never started.
If an obsolete migration has started, preserve its history, establish the revised intended state and remaining work for every affected target, and finish through Execute.