LifeosUpgrade: detect-only migrations halt the run with 'apply not implemented' instead of skip-with-notice

[dactylmedia]

Observed on v6.0.5.

Repro: bun LIFEOS/TOOLS/LifeosUpgrade.ts --dry-run exits 0 and lists pending migrations (in our case m-005 "LIFEOS/MEMORY/ in .gitignore" and m-007 "pre-push hook syncs USER-data repo"). Running the real apply then does:

Already applied: 5/7
-> Applying m-005: Phase G - LIFEOS/MEMORY/ in .gitignore
  x m-005 failed: m-005 apply not implemented - modify .gitignore in source PR rather than via tool.
Migration halted. Partial state may exist. Review error and re-run after remediation.

Problem: m-005/m-007 are detect-only BY DESIGN (their apply deliberately throws; remediation is manual or belongs to a future Phase G session). But the runner treats the throw as a migration FAILURE and halts with a scary "Partial state may exist" message, even though nothing failed and nothing is partial. Any migration listed after a detect-only one is unreachable. On installs where ~/.claude is not (yet) a git repo, these two will pend forever, so every future upgrade run halts at m-005 before reaching real migrations.

Suggestion: give migrations an explicit detectOnly: true flag. The runner reports them as "manual remediation required" (with the remediation text), skips them, continues to later migrations, and exits 0 with a notice - reserving non-zero + "halted" for genuine apply failures.

[danielmiessler]

Good catch and a clean writeup. This exact shape landed in source on 2026-07-21 — migrations now carry an explicit detectOnly flag, and the runner reports them as "manual remediation required," skips them, and continues to later migrations instead of halting. Ships in the next release. Thanks for the precise repro.