max / goingson

Opt tasks into field merge, deriving completed_at at every status write tasks is the table field merge is for: 29 synced columns, so two devices editing the same one is the uncommon case, and plain LWW discards a whole edit (and stashes it) for touching a row it never contested. Re-ran the enumeration of every UPDATE tasks site. Three findings, all now recorded at the declaration: - actual_minutes is a counter (time_session_repo.rs increments it in place). Declared, so a conflict that moved it on both sides falls back to LWW-and-stash instead of silently keeping one device's total. - completed_at is derived from status. Declared as a dependent pair, because the app cannot fix this on its own: a device that starts a task leaves completed_at at its base value, so it is never a change to contest, and a column-by-column merge keeps the other device's completion time whichever way status falls. Verified against the real resolver before relying on it. - urgency is derived too and is deliberately NOT grouped. Grouping it would drag most of the row in and leave nothing to merge; it is a sort score rather than a claim about the task, recomputed on the next write, and a remote apply already overwrites it under plain LWW today. delete() and start() now derive completed_at rather than setting status alone, so deleting a completed task no longer leaves it carrying the completion time of a status it lost. Written as a CASE rather than update()'s read-modify-write: the new status is fixed at both sites, so SQL can do the derivation, and one statement has no window for a concurrent complete() to land between a read and a write. The manifest test freezes the opt-in set and both declarations, so adding a table means editing the list deliberately rather than a refactor doing it quietly. Cargo.lock: synckit-client 0.6.0 -> 0.7.0, plus cargo pruning windows-* entries the current graph no longer requires.