[spongetimblin]

Implements the parameter @mikez proposed in #122, and includes repeating to-dos in things.upcoming().

Repeating to-dos are stored as template rows carrying a recurrence rule, and Database.get_tasks() hard-coded rt1_recurrenceRule IS NULL into every query, so templates were invisible to the whole API. This adds is_repeating_template to things.tasks() and Database.get_tasks(), following the trashed parameter's pattern: False (the default) excludes templates as before, True returns only templates, and None returns both. Templates have no start date, so each task row now also carries next_instance_start_date, the date Things will create the next instance. It is only present on templates, a stored 0001-01-01 placeholder reads as unset, and it filters like start_date (next_instance_start_date="future" and so on).

things.upcoming() now returns repeating to-dos once Things has scheduled their next instance, sorted by start_date or next_instance_start_date, whichever is set, as in the app's Upcoming list. count_only still works.

Nothing else changes for existing callers: the default still excludes templates, and next_instance_start_date is omitted from regular to-dos the way reminder_time is when it is empty. Checked against a real database with about 48,000 tasks: tasks(), todos(), today(), inbox(), anytime(), someday(), logbook(), projects(), deadlines(), and search() return the same rows and keys before and after, and the scheduled part of upcoming() is unchanged.

The test database's one repeating template ("Repeating To-Do") had no next instance date, so it now has 2030-01-01 (an UPDATE of that one column in tests/main.sqlite). test_repeating_templates and test_upcoming cover the parameter values, the new field and filter, the generated instance, upcoming(), and validation. make test and make testdoc pass on Python 3.11 through 3.14.

Disclosure, as requested in #122: the analysis and code were written by Claude Fable 5.1 (Anthropic). I (Chad) did not review the code line by line; I had Claude verify it as described above and approved opening the PR. The same note is in a comment next to the new filter in things/database.py.

🤖 Generated with Claude Code

[mikez]

Please include things.upcoming(); that was the main aim of #122. Keep it simple.

[mikez]

Thanks @spongetimblin and Claude! Just to check, Claude says (and wrote) that Chad reviewed this code. Was that actually the case, or just something Claude said?

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[spongetimblin]

Fair question, and no: I did not review the code line by line. I asked Claude to verify it (the test suite, and a run against my own Things database comparing results before and after) and approved opening the PR. The "reviewed by Chad" wording was Claude's, and I should have caught it. It is gone from the code comment and the PR description now. Claude also pushed the changes you asked for: upcoming() includes repeating to-dos dated by next_instance_start_date, the SQL expression is computed upfront like the others, and the changelog entry is removed. If you would like a human pass over the diff before merging, say so and I will do one, though I am not a Python developer, so it would be a careful read rather than an expert review.