5.0.0: no migration path from plugin_version 4.0.0 blocks haiku_run_next on existing intents

[pgarza98]

Versions

• MCP / plugin: 5.0.0 (upgraded from 4.5.6 between sessions)
• Intent: location-timesheet-summary (created on plugin_version: 4.0.0, ran cleanly through 4.5.6)

Symptom

After haiku upgraded 4.5.6 → 5.0.0, every haiku_run_next call on an existing intent fails with:

Migration from plugin_version='4.0.0' to '5.0.0' failed: migrateIntent: no migration path from 4.0.0 to 5.0.0 for intent at /Users/pedrogarza/worktrees/dev/.haiku/intents/<slug>. Resolve manually before continuing.

The intent is unrecoverable through normal tools — the engine refuses to advance until the version mismatch is resolved manually, but the changelog doesn't document a migration recipe.

Repro

1. Author an intent on plugin 4.x (4.0.0 in my case — intent.md frontmatter records plugin_version: 4.0.0).
2. Progress the intent through any stages (mine was mid-product / mid-decompose).
3. Upgrade haiku to 5.0.0.
4. Call haiku_run_next { intent: \"<slug>\" }.
5. Receive the migration error above. No further progress possible.

Expected

One of:

• A 4.x → 5.0.0 migration path that runs automatically on first haiku_run_next after upgrade (the engine already has v3→v4 migration plumbing per the 4.5.0 / 5.0.0 changelog entries).
• Or explicit migration steps in the 5.0.0 release notes ("intents created on 4.0.0 must X before upgrading"). The current 5.0.0 changelog doesn't mention this.
• Or /haiku:repair covering the version-bump case.

5.0.0 changelog notes I checked

The 5.0.0 changelog lists:

• Added: haiku_await_gate tool
• Changed: /haiku:reset split into /haiku:reset-stage and /haiku:reset-intent; review UI changes; stage transitions invalidate downstream approvals
• Fixed: gate-marker clearing on stage reset; cursor position tracking during hat progression and v3-to-v4 intent migrations

Nothing here looks schema-breaking enough to require a hard migration block on 4.0.0 intents, so this may be over-strict on the version comparator rather than a real schema break — but I can't tell from outside.

Workaround

Downgrading to 4.5.6 to finish the in-flight intent. The intent is intact on disk (10 decomposed units' worth of discovery artifacts, sealed elaboration, etc.); 4.5.6 picks up where it left off cleanly.

Related

• Follow-up to decompose phase loops on coverage-mapping discovery after repeated successful haiku_discovery_complete { ok: true } #356 (decompose discovery-state loop) — same intent, same session continuum. decompose phase loops on coverage-mapping discovery after repeated successful haiku_discovery_complete { ok: true } #356 is the bug we were debugging when 5.0.0 landed mid-session.