Expose repeating to-dos when the public API supports recurrence

[almirsarajcic]

Problem

Basecamp supports repeating to-dos in the product UI, but the public To-dos API and the CLI do not expose the recurrence rule. This prevents agents and scripts from creating, inspecting, or updating a native repeating to-do.

The current CLI surface only offers the ordinary fields:

basecamp todos create ... --due YYYY-MM-DD
basecamp todos update ... --due ... --starts-on ...

Verified behavior

Using Basecamp CLI 0.9.1 against the public API, I posted a disposable to-do with a due date plus the same recurrence-shaped fields documented for Schedule entries:

{
  "content": "API recurrence probe — safe to trash",
  "due_on": "2026-09-16",
  "recurrence_schedule": { "frequency": "every_week" },
  "recurs_until": "2026-10-15"
}

The API returned 201 Created, but silently discarded recurrence_schedule and recurs_until. The response and a subsequent read contained only the ordinary to-do fields and due date. The disposable record was then trashed.

This matches the published API reference:

• Basecamp Help documents native recurring to-dos and their primary/occurrence model: https://5.basecamp-help.com/article/1077-to-dos#recurring-to-dos
• The To-dos API documents only content, description, assignees/subscribers, notify, due_on, and starts_on for create/update: https://github.com/basecamp/bc-api/blob/master/sections/todos.md
• The Schedule entries API separately documents recurrence_schedule and recurs_until: https://github.com/basecamp/bc-api/blob/master/sections/schedule_entries.md

The CLI therefore has no supported to-do field or endpoint to wire a repeat flag to.

API contract needed

CLI support needs a public API contract that can:

1. Create a repeating primary to-do with an initial due_on, recurrence rule, and optional end date.
2. Read the recurrence rule and distinguish the primary to-do from generated occurrences.
3. Update the primary rule for future occurrences without rewriting completed or past instances.
4. Stop recurrence while preserving existing occurrences.
5. Return validation errors instead of silently ignoring an invalid or unsupported recurrence field.

Reusing the Schedule entry naming would keep the API consistent if the underlying model permits it, but the product's primary/occurrence semantics may need a dedicated representation.

Once the public API and SDK expose that contract, I can follow up with CLI support along these lines:

basecamp todos create "Run payroll" --due 2026-09-25 --repeat every-month [--recurs-until YYYY-MM-DD]
basecamp todos show <primary-or-occurrence> --json
basecamp todos update <primary> --repeat ... | --no-repeat

That CLI change would include validation, structured JSON output, agent-skill documentation, and tests. Until the contract is available, the CLI should not call an undocumented web endpoint or map repeating to-dos to Schedule entries.