v7→v8 migration leaves design units in a recovery loop the cursor can't drive forward

[jwaldrip]

Plugin version: 8.0.0
Studio/Stage: software / design
Intent: admin-portal-reimagine (GigSmart monorepo, worktree swirling-pondering-swan)
Branch: haiku/admin-portal-reimagine/design @ 4cba44ab7b3 (mode flip commit 5d0dd7a2c24)

What happened

After /haiku:change-mode → autopilot, haiku_run_next triggered the v7→v8 migration. The migration's "iterations[] preserved" claim did not hold for units 03–11 (9 wireframe units, full reviews{} and approvals.user dated 2026-05-13T22:28:51Z with matching body_sha256 witnesses, output HTML + spec MDs on disk). All 9 had iterations: [], surfacing unit_outputs_empty_iterations.

I ran haiku_debug { op: \"set_unit_iterations\" } (no explicit array → auto-synth) for each. Returned iterations_written: 3 per unit, populating designer-prep + designer + design-reviewer with result: advance.

Next tick: cursor dispatched start_unit_hat { hat: \"designer-prep\", units: [04,05,06,07,08,09,11] }. Calling `haiku_unit_advance_hat` directly returned `iteration_already_terminal`. Only escape: `haiku_unit_start` to append a fresh designer-prep iteration with null result, then advance. That's 3 hats × 7 units = 21 hand-driven FSM calls to clear migration state for work that's already done and approved.

The bug

1. `set_unit_iterations` auto-synth writes terminal entries the cursor's wave-readiness logic rejects. Irreducible standoff: cursor wants the hat to run, advance API refuses because the iteration is terminal.
2. Units 03 and 10 excluded from the re-dispatch list despite identical migration + backfill treatment to 04–09 and 11. Worth understanding why those two were spared — it may be a clue to the wave-readiness signal that's flagging the others.
3. Unrelated but report-worthy from the same session: pre-cursor sync from `dev` collided with a tracked-as-symlink path (`.haiku/intents/twelve-week-plan-accountability-app` symlinking into a locked worktree at `monorepo-1`) where `dev` had committed a real directory. Git produced a `~HEAD`-suffixed conflict file and `git mv` refused to undo — required raw `git update-index --cacheinfo 120000,,` to restore the symlink. Possibly worth defensive handling in the pre-cursor sync logic if locked-worktree symlinks are a supported pattern.

Expected (any one of)

• v7→v8 migration backfills `iterations[]` for ALL units with completed reviews/approvals (not just units 01–02, which DID get backfilled cleanly).
• `set_unit_iterations` auto-synth produces a state the cursor accepts as complete (currently it does not).
• The cursor's "needs another pass" signal surfaces in the action prompt so the operator knows why a re-pass is needed — currently it just says "dispatch designer-prep" with no rationale, and the operator has no way to tell whether to actually re-do the work or just no-op-advance.

Repro

1. Take any v7 intent past the design stage with multiple wireframe units fully approved.
2. Upgrade plugin to 8.0.0 and call `haiku_run_next`.
3. Migration runs → `unit_outputs_empty_iterations` surfaces on units whose iterations[] was not preserved.
4. Try every documented recovery path. `set_unit_iterations` leaves you in the standoff above.

Artifacts

Full session transcript + 10 subagent transcripts available on the reporter's machine at `~/Downloads/haiku-v8-recovery-loop-bug/`. Happy to attach `session.jsonl` (~870 KB) and the subagent jsonls to this issue if useful — say the word.

A duplicate of this report was also submitted via `/haiku:report` → Sentry from the same session.