Triple-C/container/mission-control/.claude/skills/init-project/migrations.md

Init-Project Migrations

When /init-project runs, it checks for legacy directory layouts from earlier versions of Flight Control and offers to migrate them. Migrations are idempotent — they only apply when the old layout is detected and the new layout doesn't yet exist.

Migration Registry

001 — Rename .flight-ops/ to .flightops/

Early versions of Flight Control used .flight-ops/ (with a hyphen). The current convention is .flightops/ (no hyphen).

Detection (returns true if migration is needed):

[[ -d "{target-project}/.flight-ops" && ! -d "{target-project}/.flightops" ]]

Actions:

1. Rename the directory:

   mv "{target-project}/.flight-ops" "{target-project}/.flightops"
   

2. Update .gitignore if it references the old name:

   sed -i 's/\.flight-ops/\.flightops/g' "{target-project}/.gitignore"
   

User message:

Renaming .flight-ops/ → .flightops/ (updated naming convention)

---

002 — Rename phases/ to agent-crews/

Early versions stored crew definitions in .flightops/phases/. The current convention is .flightops/agent-crews/.

Detection (returns true if migration is needed):

[[ -d "{target-project}/.flightops/phases" && ! -d "{target-project}/.flightops/agent-crews" ]]

Note: This runs after migration 001, so it checks the post-rename .flightops/ path.

Actions:

1. Rename the subdirectory:

   mv "{target-project}/.flightops/phases" "{target-project}/.flightops/agent-crews"
   

User message:

Renaming phases/ → agent-crews/ (updated naming convention)

---

003 — Update lifecycle states to unified model

Flight Control now uses a unified lifecycle for both flights and legs: planning → ready → in-flight → landed → completed (or aborted). This replaces the old divergent states:

• Flights: diverted → aborted; added completed after landed
• Legs: queued → planning; review → landed; blocked → aborted; added ready and completed

Detection (returns true if migration is needed):

grep -rql 'queued\|diverted\|blocked\|review.*completed' "{target-project}/.flightops/ARTIFACTS.md" 2>/dev/null

Note: This runs after migrations 001 and 002, so it checks the post-rename .flightops/ path.

Actions:

1. Update state definitions in ARTIFACTS.md:

   • Replace flight status line: planning | ready | in-flight | landed | diverted → planning | ready | in-flight | landed | completed | aborted
   • Replace leg status line: queued | in-flight | review | completed | blocked → planning | ready | in-flight | landed | completed | aborted
   • Replace flight state tracking: planning → ready → in-flight → landed (or diverted) → planning → ready → in-flight → landed → completed (or aborted)
   • Replace leg state tracking: queued → in-flight → review → completed (or blocked) → planning → ready → in-flight → landed → completed (or aborted)
   • Replace landed | diverted → landed | aborted in debrief templates
   • Replace landed/diverted → landed/aborted in debrief templates
   • Replace completed | in-flight | blocked → completed | landed | in-flight | aborted in flight log templates

2. Update existing artifact files in the project (if any):

   • In flight artifacts: replace **Status**: diverted → **Status**: aborted
   • In leg artifacts: replace **Status**: queued → **Status**: planning, **Status**: review → **Status**: landed, **Status**: blocked → **Status**: aborted
   • In flight log entries: replace **Status**: blocked → **Status**: aborted

   Find artifacts using the locations defined in ARTIFACTS.md (typically missions/ directory for file-based projects).

User message:

Updating lifecycle states to unified model: flights and legs now share planning → ready → in-flight → landed → completed (or aborted)

---

Adding Future Migrations

To add a new migration:

1. Assign the next sequential ID (e.g., 003)
2. Write a Detection check that returns true only when the migration is needed and false if already applied (idempotent)
3. List the Actions to perform — prefer mv over copy-and-delete to preserve file contents and git history
4. Write a short User message shown during the migration summary
5. Consider ordering — if the migration depends on a previous one having run, note that in the detection section
6. Keep migrations non-destructive: rename and update references, never delete user content