Flows 01–04 cover the rep's primary daily gestures (mark done · drill to account · list↔map · record-note). Flows 05–09 are the variants and edge cases: done-at-top as a side-by-side comparison, swipe gestures, end-of-day carry-over, add-to-list from account detail, and reorder mode. Flow 10 is a per-list_type behavior comparison panel showing why one done-state rule doesn't fit. Phone outlines stripped to the bone — read each row left-to-right. Yellow circles = tap targets; dashed borders = modal sheets; black pills = toasts.
Single status-dot tap. Row strikes through where it sits — no jump to a "done" zone. Toast offers undo for 4s. Eye stays with the route.
List does not scroll. List does not reorder. The done item stays where it sits because the route is the spatial truth — moving it would disorient the rep.
Status-dot tap target is small (~9px visual, 36px hit area). Whole-row tap is reserved for drill-down (Flow 2). Conflict if hit areas overlap — keep dot's hit area generous but not eat the row tap.
Behavior diverges by list_type: day = stay in place forever. follow_ups / steady = collapse to a "Completed (N)" group at bottom (route order doesn't apply). Two rules, predictable per list.
Row tap opens detail as a sheet over Today — bottom nav stays Home, no tab switch. Composer stacks over the sheet. Dismiss returns to Today, scroll position preserved.
Sheets, not tab-switch. Tapping an account row never moves the bottom nav to Accounts tab. The rep is doing the day's work — context preserved.
Sheet stacking is OK at depth 2 (account → composer). Going deeper (composer → photo picker → camera) starts to feel like a trap. If a third sheet is needed, push it as a tab-replacement screen from inside the second sheet, with explicit Back.
For contact-typed rows ("Call Pat Reilly"), the sheet is a contact-detail with the same shape; the "Call" CTA is the most prominent action inside. The row body never auto-dials — too easy to misfire while driving.
Map is a tab-replacement, not a sheet — needs full screen height. Bottom nav stays. Tapping a stop pin opens the same account sheet pattern as Flow 2, layered on the map.
Map is full-screen, not a sheet. A pannable map under a draggable sheet creates gesture conflicts (sheet handle vs map pan). Full-screen map + sheet on top is cleanest — sheet drag wins, map pan engages outside the sheet.
"Last viewed" pin highlight is the trail of breadcrumbs back. Without it, after dismissing the sheet the rep loses the spatial anchor of "what was I just looking at?"
"Get directions" inside the sheet exits to Apple/Google Maps. Coming back, app should restore Map view at same zoom — NOT auto-recompute "what's next." Smart-restart is a chat-agent job, post-v1.
Middle nav button = record. The currently-visible item becomes implicit context, surfaced as a chip with × to clear. Implicit context with explicit override.
Implicit context resolution rule needs to be deterministic. "Currently visible" is fuzzy. Better: the topmost item in the visible viewport, or the item the rep last interacted with (tapped/swiped). Pick one and document.
What if no item is visible (rep is on the lists index, or settings)? The chip simply isn't there — the note is unattached, can be filed later. Don't fall back to "the last tab they were on."
The × on the chip is critical. Without it, the rep can't override and we'll get bug reports of "I recorded a note about Bayside but it attached to Acme." The override must be obvious and one-tap.
The pattern you originally floated. Done items pin to the top of the list section; default scroll lands at the first pending item. Shown for direct comparison with Flow 01 — same data, different rendering rule.
Animation cost. Watch Frame B → C: the row physically jumps ~165px upward past 4 rows it didn't visit. Scroll has to compensate to keep "first pending" anchored, otherwise the screen jolts. One feature, two coupled animations.
Spatial confusion in geographic lists. If the rep is at Falls Forge and marks it done, the row leaving the geographic position and joining a "history" block above breaks the route mental model. Acceptable for non-route lists; bad for day lists.
Default-scroll restoration on every view. Returning from a sheet (Flow 2) must re-anchor scroll to "first pending," which is now in a different position than when you left. Doable but a fragile coupling.
If you want this: ship it for follow_ups and steady only. Day lists keep Flow 01's done-in-place. Same primitive, list_type-driven rendering rule. (See Flow 10.)
Right-swipe = mark done (positive direction, conventional). Left-swipe = action menu (Note · Call · Skip · Defer). Faster than tap-dot for power users; tap-dot stays for first-timers.
Threshold tuning matters more than the gesture itself. Too sensitive and the rep marks done while scrolling. Too stiff and the gesture feels broken. iOS Mail uses ~50% of row width for full commit; ~20% to peek. Steal that.
"Call" only shows for contact-typed members. For account-typed, the menu is Note · Skip · Defer · Move (no Call). The row knows what its FK is and renders the right action set.
Conflict with horizontal scroll: none, since these lists don't scroll horizontally. But concept-C-style "step number on left" rows need to ensure the swipe-right reveal doesn't cover the step number visually.
End-of-day prompt: roll the not-done items into a new day list (or onto an existing one). Their explicit ask. Uses parent_list so the chain back to the original is preserved.
parent_list points back at the original Tuesday list.Avoid infinite carry-over. If an item has been carried 3 times, the EOD pill should escalate: "Carry again, or drop?" Otherwise leftovers ride forever and rot the data.
Day-already-exists rule. If the rep targets a date that already has a day list with overlapping geographic scope, prompt to merge instead of creating a parallel list.
Original list's status. Tuesday's list isn't archived just because items left it — it shows "9 done · 3 carried to Thu" in its summary. Manager reconciliation (the agent job already in dev/active/) needs to count carry-overs as legitimate completion paths, not losses.
The other primary creation path you specified. Rep is browsing accounts (or just finished a visit), pulls up an account, adds it to one of their lists. Lives in the Accounts tab, surfaces all rep-owned lists.
Picker eligibility: rep-owned, non-archived, non-day-list-in-the-past, type allows accounts. Don't show day lists scheduled for today if it's already 4pm — adding now is just confusion.
Manager-curated list visibility: a manager's master list with the rep as assignee — show it? Tap-to-add affects the rep's child slice, not the master. Confirm whether reps can pull additions onto a manager's list at all.
Multi-add via account list: from Accounts index, multi-select 5 accounts → "Add to list" → same picker sheet, batch add. Don't ship Flow 8 without thinking about this — single-add via detail and bulk-add via index need to share the picker.
Long-press = context menu (Apple Reminders pattern), not direct reorder. "Reorder list" lives inside the menu and enters a dedicated mode with handles + "Done" button. Discoverable + safe vs route overwrites.
position + flips list to "manual" ordering.Manual override warning: when reordering a route-based day list, show a banner first: "Reordering will replace auto-route. Re-optimize anytime from the menu." Stops the rep from accidentally making the day worse.
Long-press hit-target conflict with iOS-system text-selection on the row's name. Disable text selection inside .item-lo at the platform level.
"Move to list…" is the menu item that bridges to Flow 8's picker sheet. One picker, two entry points. Don't fork it.
The same "marked done" tap, rendered three different ways depending on list_type. Why one rule doesn't fit: route-based lists need spatial preservation; task piles need a clean "completed" archive; activity-typed members are derived state and can simply leave.
Activity.status — closing the activity removes the row. The dotted ghost shows where it was for ~3s, then gone.This is one feature, three render strategies. Driven entirely by list_type — no per-list config. The model already has the field, no migration needed.
Activity-typed members in steady/day lists: still derived from Activity.status, so even in a day list, an activity-typed member that gets closed externally (rep marks the activity done from the activity detail screen) needs to update the row. Per the design doc this is a signal — confirm scope.
"Completed (N)" collapse state defaults to expanded. Hide nothing the rep just did; require an explicit collapse to tuck it away. Collapse state is per-rep-per-list, persists across sessions.