[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.

[mikez]

@spongetimblin Much appreciate the clarity here. I'll take a careful look at the code as soon as I get around to it. From the first skimming of it, it looks like Fable did a good job.

[mikez]

pr152-review-notes.md

@spongetimblin Took a close look together with Claude. Looks great from a correctness point of view; in the above markdown are consistency comments. The aim is to keep the code similar to other code around it. I think Claude should easily be able to make those changes if you feed the markdown to it.

Thank you again. 😊🙏

[spongetimblin]

Thank you for the careful notes, and for writing them up so clearly. Every one of them made the code easier to read.

All five sections are applied in 9d34853. The placeholder check now lives in null_if_unset_thingsdate() in the helpers, with the cutoff written as 0002-01-01 and a doctest; the column constant, the filter dict and its lookup, and the validation list follow their neighbours; the long filter line is precomputed like project_filter; the disclosure comment and the docstring line continuation are gone; and upcoming() has your docstring, the deadlines fix, and sorts by (date, today_index, index). Small deviation: mypy still flags the .get() when # type: ignore sits on the opening line, so it is on the argument line instead.

On the order: on a real database with 251 upcoming rows the sort is total (no missing today_index or index) and the scheduled subset is unchanged, but it was not compared against the app's visual order, so that part rests on the finding in #122. make test, make testdoc, and make lint pass; mypy and vulture are clean.

Thanks again for the warm welcome. It has been a good first experience contributing here. 😊

🤖 Changes made by Claude Code