[FR]: relative date math for scheduled/due fields in step inputs

[kmaustral]

This relates to TaskNotes Workflows.

Feature Description

Feature request: relative date math for scheduled/due fields in step inputs

Summary

task.create, task.reschedule, and task.setScheduled currently expose scheduled/due as a literal date field (date picker) in the workflow editor. There's no way to set these fields to a date computed relative to another point in time, such as "N days after this workflow runs" or "N days after the trigger task's completion date."

Use case

A recurring task ("board meeting," 2nd Tuesday monthly) should spawn a follow-up task ("compile minutes") scheduled a fixed offset after each completion, e.g. 2 days later. Because the trigger date shifts every month (not a fixed calendar date), the offset has to be computed at run time rather than hardcoded.

Current limitation

• task.query supports date math in where clause values via { fn: dateAdd, value: { fn: today }, amount: N, unit: day }, but this is scoped to query filtering only.
• Step inputs (task.create, task.reschedule, task.setScheduled) only accept the reference tokens {{today}}, {{now}}, {{trigger.after.*}}, {{steps.*}}, {{item.*}} — none of which support arithmetic.
• There is no step type dedicated to computing a derived date value that could be referenced by a later step.

Proposed solutions (any of these would resolve it)

1. Extend the reference/template resolver to support the same dateAdd-style function objects already used in task.query, but for any field value in any step input — e.g. scheduled: { fn: dateAdd, value: "{{trigger.after.dateModified}}", amount: 2, unit: day }.
2. Add relative-offset fields directly to task.reschedule/task.setScheduled — e.g. an amount + unit + relativeTo (today / trigger completion date / an existing task field) input mode, alongside the existing literal date picker.
3. Add a dedicated date.compute step type that takes a base date and an offset and outputs a value under {{steps.stepId.date}}, referenceable by any later step's date field.

Option 2 fits the existing step-catalog pattern most naturally (task.reschedule already implies "move this date," so a relative mode there seems like the least surprising addition), but any of the three would unblock this class of workflow.

Context

This came up building a "create task N days after a recurring task's completion" workflow — a common enough pattern (compliance follow-ups, minutes after meetings, review cycles after milestones) that it seems worth first-class support rather than requiring an external webhook receiver to do the date arithmetic.