Saga Dashboard · Passive / standing states · issue #654 · phase 3

Standing-state warnings — how to surface them

Some conditions aren't caused by an action you just took — the data is already in a state that needs cleanup (a pod with no tutor, students left in no pod after a roster sync). These must be findable when you're not looking at them, without re-nagging every time you open the screen. That's a different job from the toasts — here are the ways to do it.

The distinction

Active moment vs. passive standing state

The same condition has two lives. Treat them differently — same underlying issue, different delivery.

Active — you just caused it

at the moment of the action · loud
Maya Ellis is also in another pod this period — remove from ?✕
A toast, right where you're working. Covered by the other two boards.

Passive — it's just… like that

open the screen tomorrow · quiet, findable
Pod 3 has no tutor assigned. ✕
Shown only when you're in its context — never re-toasted on every open.
The rule that active toasts can't express: a standing state must not fire a fresh interruption each time you open the screen. Once acknowledged it stays counted but quiet until it's actually resolved — and conditions that arise with no user action at all (roster sync) only ever have this passive life.
Delivery A — the wayfinding trail

Amber count-badges lead you to the exact spotrecommended core

The badge starts on the program, carries into Program Configuration, lands on whichever step is in trouble (People / Schedule / Groups — several can be at once), then points at the exact row. Counts roll up so you find it from the top without knowing where it is; the detail (or a toast) shows only when you arrive.

Program pickerLincoln High5
→
EnterProgram config5
→
The step in trouble DetailsPeople 2Schedule 1Groups 2Review
→
Exact row + a toast there
Groups → Cohort 202 · Pod 3 has no tutor.
Schedule → Period 4 has no meeting times.

The trail narrows by level. Program 5 = 2 People + 1 Schedule + 2 Groups; each step badge drills to its exact point — an unassigned section (People), a period with no times (Schedule), a tutorless pod or pod-less students (Groups) — where the detail appears. The detail is a signal, not another dot (see the collision note below).

Delivery B — a notification bell

One place that lists everything outstandingcomplement / alternative

A bell in the top bar with a count; open it for the full list, each row jumping to where the issue lives. Good for "how much is outstanding" at a glance; weaker at pulling you in while you work.

Lincoln High School ▾🔔5
5 things need attention
People · Section 3B not assigned to a Period Fix →
People · Section 5A not assigned to a Period Fix →
Schedule · Period 4 has no meeting times Fix →
Groups · 202 Pod 3 has no tutor Fix →
Groups · Roster 3 students aren't in a pod Fix →

Best paired with the trail: the bell answers "is there anything?" and "how much?"; the trail answers "where?" and walks you there. Recommendation is both — bell for magnitude, trail for wayfinding.

The marker itself

Amber, and mind the dots we already use

Red loses contrast on our chrome and reads as an error; amber says "needs attention" and stands apart from danger-red. The real trap: we already use a dot to mean "this person is in another pod." Putting an attention dot on that same surface is dot-on-dot.

Amber dot leaf only

Cohort 202

Smallest footprint. Fine at a tiny leaf — but no magnitude, and collides where occupancy dots live.

Amber count-badge recommend

Groups3

Carries the fan-out count; unmistakably "attention", not occupancy. Lives on nav chrome, not inside the board.

The collision to avoid

Board today uses"in another pod"

Inside the pod board, don't stack an attention dot on the occupancy dot — surface the issue there as the toast/detail instead.

Rule of thumb: attention count-badge on nav chrome (program · step · cohort row — no dots there) → arrive → the issue shows as a signal/detail, never another dot on the dotted board.

What lives here (auto-arising states)

The standing states this covers — spread across the config steps

They can appear with no action to hang a toast on, so passive delivery is the only way they're seen (plus an active toast at the moment, if a user did cause it). Different steps hold different ones:

PEOPLE  Section 3B isn't assigned to a Period. ✕
SCHEDULE  Period 4 has no meeting times. ✕
GROUPS  Pod 3 has no tutor assigned. ✕
GROUPS  3 students aren't in a pod yet. ✕

People: a section not assigned to a Period · Schedule: a period with no times · Groups: a tutorless pod (#343) or pod-less students (#461). All quiet, dismissible-until-resolved, reached via the trail/bell. Any active warning also becomes one of these once dismissed-but-unresolved.

Open questions for you

1. Trail, bell, or both? — recommendation: both (bell = magnitude, trail = wayfinding).
2. Marker form — amber count-badge on nav chrome (recommended) vs plain dot; confirm amber over red.
3. When does the detail show? — only in-context (recommended), or also a persistent inline banner on the page (risk: the nag).
4. Dismiss semantics — dismiss = "I've seen it, keep it counted" vs "hide until it changes"? It must never fully disappear while unresolved.