Yuvomi

Added

• The tasks module keeps a history of what was completed (#791). Ticking a task off was a state, not an event: a task carried done, and nothing recorded when that happened or who did it. So the four questions in the thread - what did I finish today, what yesterday, when was this chore last done, and who did it - had no answer anywhere, and the reason was not a missing view but data that was never written down.

  There is now a third view beside List and Board. It shows occurrences rather than tasks, grouped by day, newest first, with the member who ticked it off and the time. Search, filters, grouping and bulk select disappear there, because they all ask about tasks - a status filter over a list of completions would be a choice that cannot change anything. Tapping an entry opens its task. A recurring task additionally shows Last completed in its detail view, across the whole repetition chain rather than just the instance currently open - which is precisely the “when was this last done” case, and the one a single completed_at column could not have answered: a completed recurring task spawns a follow-up instance, so its history is spread over a chain of rows.

  The entry carries no copy of the task. No title, no category, no member name, and above all no copy of the visibility level. Both read paths join the task and apply the same visibility rule as every other task list, so a task set to private after the fact disappears from the history too. A snapshot would have kept giving away what was just locked away. The price for that single truth is deliberate: deleting a task deletes its completions with it.

  It records who ticked it off, which is not necessarily who it was assigned to. The rewards ledger decides that differently on purpose - points go to the assignees and can be shared, because they are a merit. A completion is an occurrence: it happens once, through one click. Subtasks are never recorded, since a checklist item is part of its parent instruction, and filing a task away is not a status change (#688) and writes nothing either.

  The history starts empty, and says so. Recording begins with this release; what a household ticked off before it was never written down, and the empty state explains that instead of claiming nothing was ever done.

  Paging uses a (completed_at, id) cursor rather than an offset: a bulk action puts several completions in the same second, and an offset would skip a row that arrived while somebody was paging. There is no date range in the query, because which calendar day an instant belongs to is a question for the display timezone - a server taking a from day would have to keep a second clock for it.

  One boundary is stated rather than inherited: the inbound CalDAV sync writes the status straight into the row, so ticking a mirrored task off in Apple Reminders does not reach the history. That run has no acting person - it uses the household’s credentials, not a member’s - which is the same reason the reward ledger has the same gap.

Fixed

• The automated pull request review went silent and left four runs in a row without a finding (#865). It was not blocked and it did not crash: the review plugin works almost entirely through subagents, and those now start asynchronously. In an interactive session the notification that an agent finished arrives as a new turn. A CI run has no next turn - the main session says “I’ll wait for both background agents” and is done, so it dies together with its agents before any finding exists. Every one of the four result objects carried that same sentence, with turn counts of 5, 56 and 7, which is why re-running never helped: the cause is structural, not flaky.

  The prompt now tells the review to run its agents synchronously. A guard (test:claude-review-workflow) holds that instruction, along with the three earlier conditions that each cost several attempts to find - --comment, Skill and Task in the allowed tools, and write permission on pull requests. Each of them is invisible when reading the file and produces the same symptom: a review that runs and says nothing.

  Worth knowing while this is on its way: a pull request that touches the review workflow makes the action skip itself, so this fix cannot be measured in its own pull request. It has to land on main first.