A Task Count Cannot Tell You Who Is Free

A task should know about the calendar. Building that connection exposed a more precise problem: five assigned tasks can be lighter than one badly timed errand.

A household task list cannot see that on its own. It can count assignments and overdue items. It cannot tell whether someone has back-to-back meetings, whether another person is already near the store, or whether the only free hour belongs to the person who handled everything yesterday.

Sivella needed task suggestions that respected time and workload together.

Equal counts can still be unfair

Dividing ten tasks into five and five looks balanced. The tasks may require very different amounts of time, energy, travel, and emotional effort.

One person may receive five small chores they can finish at home. The other gets a vendor call, a repair appointment, school paperwork, and two errands during a busy workday.

Sivella’s division model tracks more than the number of tasks. A task can carry estimated time, energy, cost, due date, type, and current owner. The system can use that information to identify an overloaded member or find a better reassignment candidate.

Calendar availability adds another constraint: can the person do it when it needs to happen?

Work calendars contribute one narrow fact

Households need to work around employer calendars without reading the meetings inside them. Sivella connects with read-only scopes and stores free or busy blocks. A block can say that Aditya is unavailable from 2 to 4. It does not need the meeting title, client name, participants, or notes.

This boundary lets the scheduling system find free windows while protecting work information from other household members and from the assistant’s context.

The product records calendar access and supports disconnecting the provider. Google, Outlook, Apple, and CalDAV follow the same household-facing availability model.

Unknown time is not free time

Missing calendar coverage creates a subtle bug. If the system has no information for a person, it may be tempted to treat the whole day as open.

Sivella keeps “unknown” separate from “free.” A member with no connected calendar can still receive a suggestion, but the product should not present that suggestion with the confidence of a verified free window.

This distinction matters for trust. A household assistant that repeatedly assigns errands during meetings becomes another source of coordination work.

Scheduling belongs to the current owner

When Sivella places a task, it records a start and end time. It also checks for conflicts with other scheduled household tasks.

Reassigning the task clears the old placement. The new owner may have a different calendar and a different useful window. Keeping the old slot would make the task look scheduled even though the reason for that time no longer applies.

The product can then suggest a new time for the new owner.

Suggestions need reasons

“Assigned to Priya” can feel arbitrary. “Priya is free after 5 and has the lighter evening” gives the household something it can evaluate.

Sivella returns availability and workload signals with owner suggestions. The household can accept, reject, or change the assignment. The system helps make the tradeoff visible without deciding that efficiency outweighs every social consideration.

Historical assignment patterns can reproduce an unfair household arrangement. Pure randomness ignores capacity. Asking the household to reason from scratch every time preserves the mental load the product is meant to reduce.

Explanations and overrides give the household a workable middle path.

What the connection changed

Task management usually stops after recording what and who. Household coordination also needs when.

The useful unit is a task that fits somewhere in a real day and has an owner who can reasonably carry it. Sivella now combines task load, energy, and calendar coverage to make that suggestion.

The household still knows more than the model. Someone may be ill, commuting, or unwilling to take a particular chore. Sivella’s job is to remove avoidable reconstruction and give the family a better starting point.

Building with AI: I designed the scheduling and privacy rules, then used AI to write much of the service, serializer, and test code. One update path changed owner_id directly and skipped the service method that cleared the old schedule. The fix moved that rule into a pre_save invariant, after which I repeated the owner change through the service, serializer, and assistant paths.

The rules beneath the suggestion

The feature was not accepted on the strength of a suggestion card. The backend contract had to preserve five invariants:

1. suggest_time cannot return an elapsed window;
2. place_task cannot schedule into the past or double-book an owner;
3. a suggested owner must be free for the task's actual interval, not merely somewhere on that date;
4. changing owner_id clears scheduled_start and scheduled_end because the old slot was validated for someone else;
5. reading household availability emits the correct audit event without exposing meeting contents.

One review found a real bypass: the serializer allowed a plain PATCH to change owner, while the scheduling fields were read-only. That route skipped the service method that cleared the slot. A pre_save invariant now clears placement on any owner change, regardless of which API path performs it.

I exercised availability, task placement, division, and assistant behavior together because the bug lived between those areas. The important result was practical: a suggestion fit the proposed owner's real free window, and reassignment no longer carried a stale booking across people.

The protection now sits below the card that displays the suggestion. Model and service invariants clear invalid placement, availability reads expose only free or busy time, and concurrent scheduling checks prevent two reasonable-looking requests from creating an impossible day.