GUI updates and misc fixes for the Cancel cutoff

README.md

@@ -49,21 +49,26 @@ of every "finished" status:
 - **Active Orders**: status is in `ACTIVE_STATUSES` (default just
   `Created`) - the only tickets that represent real work still to do.
 - **Cancelled**: status is in `CANCELLED_STATUSES` (default `Cancelled`)
-  - its own tab so it doesn't clutter Active, but still reviewable
-  anytime. Any transition into this status also triggers a **popup**
-  right after the import that caused it (not one that was already
-  cancelled).
+  **and it was cancelled today**. A ticket cancelled on a prior day
+  falls through to Done instead - this tab is meant to be reviewed
+  same-day and then filed away, not accumulate forever. Any transition
+  into Cancelled also triggers a **popup** right after the import that
+  caused it. Cancelled rows show in **red text** (rather than a
+  background tint) wherever they appear, including if one later ages
+  out into Done - it's still useful to see at a glance that a Done-tab
+  row got there via cancellation rather than fulfillment.
 - **Done**: everything else, automatically. This is deliberate - rather
   than maintaining a list of every status that means "finished"
   (`Waiting For Return`, `Device Return Not Needed`, and whatever your
   JIRA automation adds next, like `1st Contact Attempt`), only the
-  couple of statuses that mean "not done yet" are named. Anything that
-  isn't Created or Cancelled lands on Done with zero config changes
+  couple of statuses that mean "not done yet" (or "cancelled today")
+  are named. Anything else lands on Done with zero config changes
   needed when your workflow adds another downstream status later.
 
 This is a filter, not a physical move - it's the same `orders` table,
-split by current status every time the view refreshes, so nothing to
-reconcile if a status ever changes back.
+split by current status (and, for Cancelled, `cancelled_at`) every time
+the view refreshes, so nothing to reconcile if a status ever changes
+back.
 
 Within Done, the two fulfilled statuses (`FULFILLED_STATUS_WITH_RETURN`
 / `FULFILLED_STATUS_WITHOUT_RETURN`, defaulting to `Waiting For Return`
@@ -86,13 +91,29 @@ done today, just at different points in the day.
 ## Intake cutoff tracking
 
 `INTAKE_CUTOFF_TIME` (default `15:30`, i.e. 3:30 PM) flags any ticket
-created after that time on its arrival day with a **Past Cutoff** "Yes"
-in the table, and the Dashboard shows how many of today's tickets
-arrived past cutoff. Since a cutoff ticket is known to spill into
-tomorrow the moment it arrives, it also counts toward **Carryover**
-immediately - not just once the date actually rolls over - unless it
-still gets fulfilled the same day despite arriving late, in which case
-it correctly drops out of both.
+created after that time on its arrival day with a checkmark in the
+**Past Cutoff** column, and the Dashboard shows how many of today's
+tickets arrived past cutoff. This flag expires at midnight - it means
+"came in too late for today's window," not a permanent marker, so a
+ticket that arrived late yesterday shows no checkmark today (it's
+Carryover now, a different, already-tracked concept). While it's still
+showing, it also counts toward **Carryover** immediately - not just
+once the date actually rolls over - unless it still gets fulfilled the
+same day despite arriving late, in which case it correctly drops out
+of both.
+
+## Table layout
+
+Left to right: Company, Ticket #, Status, SKUs, Summary, Outgoing
+Tracking, Return Tracking, Uploaded, Past Cutoff, Created. Columns
+auto-size to their content on load and stay individually resizable by
+dragging (not force-stretched to equal widths) - the last column
+stretches to fill any remaining space. **Uploaded** shows a checkmark
+once a ticket has been successfully sent via the emergency "Send to
+ShipStation" action's **API** path specifically - the CSV export path
+intentionally doesn't set this, since exporting a file isn't the same
+as it actually being imported into ShipStation, and the app has no way
+to confirm that manual step happened.
 
 ## How tracking numbers get pulled and matched