Enhancement ideas from private ReminderKit API exploration

[BRO3886]

While fixing #22 / #26 I introspected the private ReminderKit.framework extensively to find the URL attachment write path. The same framework exposes a bunch of Reminders.app features that EventKit doesn't, which could become rem features. All of these would need the same runtime-introspection bridge approach as the URL attachment fix (guarded by respondsToSelector: / isKindOfClass: with EventKit fallback where possible).

Capabilities discovered

Image and file attachments

REMReminderAttachmentContextChangeItem has:

• addImageAttachmentWithURL:width:height:error: — attach a local image file
• addImageAttachmentWithData:uti:width:height: — attach image bytes directly
• addFileAttachmentWithURL:error: — attach any file
• addFileAttachmentWithData:uti: — attach file bytes
• imageAttachments / fileAttachments — enumerate them

Would let rem add --attach /path/to/photo.jpg actually drop a photo into a reminder the way you can in Reminders.app. Classes: REMImageAttachment, REMFileAttachment.

Hashtags / tags

Reminders.app supports #tag syntax in titles that become real first-class tag objects. Classes: REMHashtag, REMHashtagLabel, REMReminderHashtagContext, REMReminderHashtagContextChangeItem. Would let rem list --tag work or rem add "review PR #work #urgent" become a real filter.

Assignments (shared list sharees)

REMAssignment, REMSharee, REMReminderAssignmentContext. Lets you assign a reminder to another person on a shared list. Could power rem assign <id> <sharee> for shared grocery lists.

Subtasks

REMReminderSubtaskContext, REMReminderSubtaskContextChangeItem, and addReminderWithTitle:toReminderSubtaskContextChangeItem: on REMSaveRequest. Reminders.app supports nested subtasks — rem currently has no subtask concept. Would enable rem add "Parent" --parent <id> or a subtask subcommand.

Templates

REMReminder has template support (seen as addTemplateWithName:configuration:toAccountChangeItem: on REMSaveRequest). Reminders.app lets you save a list as a reusable template. Could power rem template save/apply.

Custom smart lists

REMSmartList, REMSmartListCustomContext, addCustomSmartListWithName:toAccountChangeItem:. These are the user-defined smart filters (e.g., "everything tagged #work due this week"). Currently rem has no concept of saved smart lists.

Due-date delta alerts

REMReminderDueDateDeltaAlertContext + REMDueDateDeltaInterval. Different from regular alarms — these are the "notify N hours/days/weeks before" settings that show up in the Reminders.app alert picker as presets. Could power more ergonomic alarm setting.

Grocery list intelligence

REMGrocerySuggestions, REMGrocerySuggestedSection, REMFamilyChecklistSharedGroceryList. Reminders.app's grocery list auto-categorizes items (Produce, Dairy, etc.) and has family-shared grocery list support. Specialized but interesting if you use it.

Location-based reminders

Not new — EventKit exposes EKStructuredLocation publicly — but REMAlarmLocationTrigger and REMAlarmVehicleTrigger show the full set of trigger types. Vehicle triggers (arriving/leaving a CarPlay-connected car) are Reminders.app-only.

Due-date-delta-interval and recurrence

REMRecurrenceRule exists alongside EventKit's public EKRecurrenceRule. It's the same data model but exposes additional fields the public API hides. Not a priority since recurrence already works via EventKit, but worth knowing if we hit limitations.

Change tracking / sync observation

REMChangeSet, REMChangeTracking, REMChangeTransaction, REMChangeTrackingState. go-eventkit already has WatchChanges for EKEventStoreChangedNotification, but REMChangeSet gives per-object-type change deltas (inserts / updates / deletes), which is richer than a generic "something changed" signal. Could power a rem watch command that streams structured change events.

Priority suggestion

If any of these get picked up, the most user-visible wins are probably:

1. Image attachments — "attach a photo to a grocery item" is a real use case
2. Hashtags — Reminders.app users already tag with #, rem should respect that
3. Subtasks — currently there's no way to express reminder hierarchies

The rest are nice-to-haves. All would follow the same pattern as the URL fix: feature-detect via respondsToSelector:, guard with isKindOfClass:, fall back gracefully when the private API isn't available.

Risk note

Every feature built on this private API is one macOS release away from breaking. The URL fix is worth the risk because the alternative (writing to the orphaned public EKCalendarItem.URL) is flatly wrong. For speculative features, the cost/benefit is worse — consider each one's fallback story. Mitigation: all bridge calls through respondsToSelector: / graceful no-op, plus a single test per feature that just checks the classes exist on the current OS so we get early warning of breakage in CI.