bug(Prime/wave-status): inconsistent wave_flight_plan shape — object vs bare array — breaks wave-status CLI

[bakeb7j0]

Summary

Prime(pre-wave) wrote flights["wave-3"] = {"flights": [...]} (object-wrapped) while wave-1 and wave-2 were written as bare arrays. The wave-status CLI then throws 'str' object has no attribute 'get' when it tries to iterate the wrapped variant.

This is the same shape issue documented in memory lesson_wave_flight_plan_schema.md: sdlc-server's wave_flight_plan tool expects a bare array; the Prime prompt sometimes writes the wrapped {"flights": [...]} object instead. Result: wave-status reads back an inconsistent state and crashes.

Resolution options:

1. Tighten the Prime(pre-wave) prompt to specify the bare-array shape verbatim with examples.
2. Make wave_flight_plan schema accept both shapes (wrapped + bare).
3. Add validation at the wave-status CLI that surfaces a clear error before the AttributeError.

Severity: medium — silent mid-campaign corruption; recovery requires hand-editing flights.json.

Origin: Reported by sibling-campaign agent. @Scryer to expand on which flight specifically had the wrapped shape (which Prime invocation), and pick between the three resolutions above.

Implementation Steps

TBD — @Scryer to expand.

Test Procedures

TBD — regression test: write a wrapped-shape flights["wave-X"] to flights.json, assert wave-status surfaces a typed error rather than AttributeError.

Acceptance Criteria

• Either Prime prompt mandates bare-array shape with a verbatim example, OR schema accepts both shapes
• wave-status CLI surfaces clear errors on shape mismatch instead of AttributeError
• Regression coverage on the wrapped-vs-bare case

Dependencies

• Memory lesson_wave_flight_plan_schema.md (existing documentation of the issue)

Metadata

Severity: severity::major (silent corruption + downstream crash)
Origin: sibling-campaign tracker. @Scryer owns expansion.