The board is a lens that tightens as plans firm up

A standalone calendar is just a UI layer; the harder path was making the board a direct view of the underlying batch records.

Runs flow through four states: Tentative, Confirmed, In Progress, and Completed. Rather than treating status as a mere display label, it drives the system rules:

• Tentative runs are lightweight. Before confirmation, a run is a tentative plan that only appears on the board. It moves freely and carries a clash flag. The tradeoff is that the board can't hold generic sticky notes—even a placeholder is a real plan with a name and dates, created in one step.
• Confirmation creates the record. Confirming the run is the exact moment real vessel instances are generated. It runs as a wizard showing what it is about to create—never a silent click.
• Confirmed runs warn, but never block. From then on, the board is simply a view of the record. Move a card, and the batch record moves. Moving a confirmed run shows a specific warning naming the clash but offers a "Move anyway" option—labs are messy, so nothing is ever blocked.

(Note: I pushed back on a requested "Soft hold" status when it became clear it offered no functional difference from "Tentative," keeping the mental model lean.)

Availability on the board, not in a panel

Leave, holidays, and half-days sit in a strip aligned to the board's days. Leave turns red when it overlaps assigned work. In the next iteration, selecting a run filters the strip to its specific people and equipment; dragging greys out unavailable days and exposes the earliest possible start.

Templates and copies keep the timing

Previously, templates stored no dates, so every step landed on day one. Now, both paths share one rule: saving a template or copying a run records each step's offset from the run's start, along with its duration. Creating from a template or copying a run then places every step on the new dates automatically.