feat: task reminders

[mancinux]

resolves #4551

[sourcery-ai]

Hey - I've found 1 issue, and left some high level feedback:

• In the React Reminders/ReminderRow UI, reminder items use the array index as the React key, which can lead to subtle UI bugs when adding/removing rows; consider using a stable identifier on reminders instead.
• The cron worker for assignments now always sends emails regardless of workday, which changes previous behavior; double-check that this is intentional and that any now-unused is_workday?/0 logic or dependencies are cleaned up.
• Reminder normalization logic (e.g., normalizeReminder* in the frontend vs. validation in Operately.Tasks.Reminder) is split across layers; consider consolidating more of this into shared helpers to reduce the chance of divergence between client and server behavior.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- In the React `Reminders`/`ReminderRow` UI, reminder items use the array index as the React `key`, which can lead to subtle UI bugs when adding/removing rows; consider using a stable identifier on reminders instead.
- The cron worker for assignments now always sends emails regardless of workday, which changes previous behavior; double-check that this is intentional and that any now-unused `is_workday?/0` logic or dependencies are cleaned up.
- Reminder normalization logic (e.g., `normalizeReminder*` in the frontend vs. validation in `Operately.Tasks.Reminder`) is split across layers; consider consolidating more of this into shared helpers to reduce the chance of divergence between client and server behavior.

## Individual Comments

### Comment 1
<location path="turboui/src/TaskPage/Sidebar.tsx" line_range="206-215" />
<code_context>
+  return { type: "on_date", days: null, date: defaultReminderDate() };
+}
+
+function normalizeReminder(reminder: TaskPage.Reminder, dueDate: TaskPage.ContentState["dueDate"]): TaskPage.Reminder {
+  const type = dueDate ? reminder.type : reminder.type === "on_date" ? reminder.type : "on_date";
+
+  switch (type) {
+    case "before_due":
+      return { ...reminder, type, days: normalizeReminderDays(reminder.days), date: null };
+
+    case "on_date":
+      return { ...reminder, type, days: null, date: normalizeReminderDate(reminder.date) };
+
+    case "due_day":
+    case "overdue":
+      return { ...reminder, type, days: null, date: null };
+  }
+}
</code_context>
<issue_to_address>
**question (bug_risk):** Normalizing reminders when due date is missing may silently change user intent without clear feedback.

When `dueDate` is falsy, `normalizeReminder` coerces any non-`"on_date"` reminder to `"on_date"`. A `"before_due"` or `"due_day"` reminder created while a due date exists will silently change semantics once the due date is removed, and the user will later see a different type than they chose. If this is intentional, consider making the UI explicit that relative reminders require a due date (e.g., remove/reset them instead of converting). Otherwise, you could reject invalid combinations server-side or preserve the original type and only disable those options until a due date is set again.
</issue_to_address>

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}