Spread in-flight touch ages by how long a task has been open

Keeps every non-designated row inside the fortnight while putting real
values in the 7-to-14-day band, so the dashboard's nested >7d / >14d / >30d
tiles read 6 / 3 / 2 rather than 3 / 3 / 2.

Also corrects the fan-out comment after #72: the reason a seeded assignment
does not fan out is the loader's own skipTriggers, not an unbound trigger.

Claude-Session: https://claude.ai/code/session_01SqkTcrxUFci7nqXdbBSe2p

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Author: os-warren

src/data/demo-assignments.ts

@@ -9,23 +9,28 @@ import { NOW, TODAY } from './demo-history.js';
  * The two assignments, and the tasks their fan-out would have produced.
  *
  * ⚠️ **The fan-out tasks are seeded directly, and that is not a shortcut.**
- * `assignment.flow.ts` is a `record_change` flow, and booting this app prints
- * `record_change triggers are not bound`. The flow therefore does not fire — on
- * a seeded assignment or on one created by hand in the UI. Seeding an
- * assignment and waiting for its children would leave the Assignments screen
- * showing two rows with `task_count: 0` and nothing to open, which is exactly
- * the "renders an empty screen" failure this card exists to prevent.
+ * `assignment.flow.ts` is a `record_change` flow, and the seed loader writes
+ * with `SEED_OPTIONS = { isSystem: true, skipTriggers: true, seedReplay: true }`.
+ * `skipTriggers` suppresses record-change AUTOMATION — that is its whole job —
+ * so a seeded assignment never fans out, and it never will, however the
+ * trigger plugins are wired. (#72 has since bound `record_change`, so the flow
+ * does fire for an assignment created by hand in the UI. That does not change
+ * anything here: it is the SEED path that is exempt.) Seeding an assignment
+ * and waiting for its children would leave the Assignments screen showing two
+ * rows with `task_count: 0` and nothing to open, which is exactly the "renders
+ * an empty screen" failure this card exists to prevent.
  *
  * So the rows below are written to be **byte-identical to what
  * `assignment.flow.ts` would have created**, field for field: `subject` copied
  * from the assignment, `owner` the assignee, `business_unit` denormalised from
  * the owner, `assignment` the parent, `source: 'assigned'`, `visible_from`
  * equal to `due_date` (an assignment has no lead time to spread), `status:
  * 'open'` at creation — and NO `period_key`, because an assignment has no
- * period and the dispatch identity index does not apply to it. When the
- * trigger binding is fixed, the flow's own idempotency guard (it looks for an
- * existing task on `(assignment, owner)` before creating one) sees these rows
- * and creates nothing, so the seed and the flow do not fight.
+ * period and the dispatch identity index does not apply to it. If one of these
+ * assignments is ever re-saved by hand and the flow does fire, its own
+ * idempotency guard (it looks for an existing task on `(assignment, owner)`
+ * before creating one) sees these rows and creates nothing, so the seed and
+ * the flow do not fight.
  *
  * The statuses below are then moved on from `open` by hand, because "mixed
  * completion" is the thing an assignment is worth looking at for.

src/data/demo-history.ts

@@ -171,6 +171,9 @@ const LATE_MOST_RECENT: Readonly<Record<string, 'open' | 'in_progress'>> = {
   'Calibration verification — Lab 1': 'open',
 };
 
+/** How long ago each actively-chased late row was last touched. */
+const CHASED_DAYS_AGO = [2, 6, 10] as const;
+
 /** Untouched since dispatch as well as late — the fourth Late row above. */
 const STALLED_LATE = 'Calibration verification — Lab 1';
 
@@ -244,6 +247,31 @@ for (const [duty, series] of byDuty) {
 const inFlightKey = (duty: string): string | undefined =>
   byDuty.get(duty)?.find((draft) => !isPast(draft))?.period_key;
 
+/**
+ * How long ago a task that is still moving was last touched.
+ *
+ * Two constraints, and the interesting one is the second:
+ *
+ *  1. **Never before the task was dispatched.** A row cannot have been worked
+ *     on before it existed. This clamps the whole band for a freshly
+ *     dispatched monthly.
+ *  2. **Never 14 days or more.** Anything that old lands in "Not moving", and
+ *     which rows stagnate is a decision this fixture makes deliberately —
+ *     see {@link STALLED_IN_FLIGHT} — not a side effect of a spread.
+ *
+ * Between those, the age is spread by how long the task has BEEN open rather
+ * than uniformly. A task dispatched five months ago and still being worked was
+ * realistically last touched a week or two back; one dispatched on Monday was
+ * touched this week. A uniform spread collapses to "everything was touched in
+ * the last few days" once constraint 1 clamps it, which makes the dashboard's
+ * nested >7d / >14d / >30d buckets read identically and look broken.
+ */
+const touchedDaysAgo = (draft: TaskDraft, dispatched: Date, index: number): number => {
+  const openFor = Math.floor((NOW.getTime() - dispatched.getTime()) / DAY);
+  if (openFor >= 14) return 8 + (index % 5);
+  return Math.max(0, Math.min(index % 6, openFor));
+};
+
 /**
  * Decide what actually happened to one dispatched task.
  *
@@ -268,10 +296,15 @@ const resolveDraft = (draft: TaskDraft, index: number): SeededTask => {
     return withNote({
       ...draft,
       status: LATE_MOST_RECENT[draft.duty]!,
+      // Chased, but at different tempos — 2, 6 and 10 days. A month-overdue
+      // task that was last touched yesterday, every time, is not what being
+      // chased looks like; and spreading these across the fortnight is what
+      // puts anything at all in the dashboard's 7-to-14-day band, which would
+      // otherwise be empty and make its >7d and >14d tiles read identically.
       last_update_at:
         draft.duty === STALLED_LATE
           ? untouchedSinceDispatch
-          : iso(new Date(NOW.getTime() - ((index % 9) + 1) * DAY)),
+          : iso(new Date(NOW.getTime() - CHASED_DAYS_AGO[index % CHASED_DAYS_AGO.length]! * DAY)),
     });
   }
   if (isMostRecentPast && draft.duty === SKIPPED_MOST_RECENT) {
@@ -307,12 +340,7 @@ const resolveDraft = (draft: TaskDraft, index: number): SeededTask => {
   return withNote({
     ...draft,
     status: isInFlightHead && IN_PROGRESS_IN_FLIGHT.includes(draft.duty) ? 'in_progress' : 'open',
-    // Not stalled ⇒ touched inside the fortnight, spread across it so the
-    // Recent-activity timeline reads as a stream rather than one boot-time
-    // spike. Never earlier than the day the task was dispatched.
-    last_update_at: stalled
-      ? untouchedSinceDispatch
-      : iso(new Date(Math.max(NOW.getTime() - (index % 13) * DAY, dispatched.getTime()))),
+    last_update_at: stalled ? untouchedSinceDispatch : iso(new Date(NOW.getTime() - touchedDaysAgo(draft, dispatched, index) * DAY)),
   });
 };