When does this apply?
If a student is added to a second session in the same period (cohort) they may be double-booked, and we want the person adding them to be able to address that.
If they are added to another session on the same day, we also still assume the person adding them to the new pod may want to address that.
Proposal
We have a small toast that pops up on each addition. It can be unclear — the link sits on the rotation name rather than the remove action — and hard to address multiple moves or complex situations.
A better system might be a review step. Required before saving.
Examples — pick a scenario
Five things still open. The defaults below are the strongest read of the PM feedback — change any of them and the review re-renders.
Today
Proposed
Today
Proposed
Today
Proposed
Today
Proposed
Today
Proposed
Modelled to scale, from source. The editor is min(1040px, 96vw) at max-height: 90vh on a rgba(11,42,74,.45) scrim. A rotation column is min-width: 320px inside a 664px board area, so only two fit per row and a third wraps to its own row at its 600px cap. The roster sits flush against the columns — the board row has no gap — and its handle overlaps the board rather than sitting beside it. The roster itself is the real 340px panel as it stands after #1586. The footer label is whatever that entry really uses: Save in View all pods, Done in the single-session editor.
Done / Save is held, not hidden. While an overlap is unreviewed it is unselectable and says why on hover or focus. Finish marks the review seen — the control turns green and the primary goes live. Cancel discards only what you selected during that opening and leaves it unreviewed. Adding a new overlap re-arms it.
Re-opening puts anything new on top. Cards you have already seen sit at the end, collapsed; any card can be opened or closed. The Undo add control reverses your own addition rather than touching anybody else’s session — it withdraws their overlap and cancels the removals you couldn't see — removals from sessions on this board stay staged, because you can undo those yourself.
How an overlap is labelled
Glyph, fill and colour are the marker grammar already decided for #1001 — nothing new here.
Colour is the pod builder's existing rotationBarColor, and the 1.6px ring is the bar hue itself — a ruling that accepts a fainter ring to keep the match exact. No session times — period, rotation and pod are the distinctions people use. A tutor sees the same glyphs and the same rows; only a host name they aren't permitted to see is withheld.
Alternative ideas
Same review and same counter, but Save never blocks — the yellow button is only an invitation. Lighter, but it can be clicked past without ever being read, which is the complaint we started from.
Overlaps accrue in a panel inside the editor instead of behind a button. Nothing to discover and no second layer, but it eats height in a dense editor and stops scaling at about three students.
Drawn and dropped, not untried: the board stays visible while you decide, but 340px forces a locked row’s reason onto its own line, and the panel is collapsed or absent on first paint in view all pods — so the control would have to live somewhere else anyway. Recoverable if the modal proves too heavy.
Toast still fires per addition for the immediate "who", with the review as the place to actually resolve. Safest against the current design, at the cost of two signals for one event.