The dishwasher is a sequence, not a checkbox.
Running it and emptying it are different jobs. The product needed to connect them.
A list can hold “run the dishwasher” and “empty the dishwasher” without understanding the relationship between them. The second task still depends on something happening first. That relationship was what I wanted to build.
The existing flow started by asking for a source chore. I wanted someone to define the sequence directly: the first task, the second task, perhaps a third, and the condition that connects them.
See the original requestInside the screen
Start with the task that starts the sequence.
The original editor makes the first chore and its repetition explicit. That is different from the delay before the next chore.
Select a detail
Every 3 days after completion belongs to the recurring sequence. It should not be confused with how long to wait before another step becomes available.
Run Dishwasher is a task someone can recognise. The next step can depend on it, rather than becoming another disconnected checkbox.
Original May development capture. The lower screen is crowded; this crop is a reading aid, not a corrected interface.
The original request31 May 2026 · excerpt
when you are building linked chains, it should ask both the tasks and if there are 3 task ability to add third
Excerpted from the development conversation. Punctuation is lightly edited; the surrounding story is an edited retrospective.
01
The delay is attached to a relationship.
The two hour delay in the builder is easy to mistake for another schedule field. It is actually an instruction about what happens after a particular event. That is different from telling the first task to recur every week. If those concepts share an ambiguous label, someone can configure the right numbers in the wrong places and still get a sequence that feels broken.
I asked the AI to build both tasks in the same flow because the dependency is easiest to understand while the jobs are visible together. The second task needs a predecessor before its timing has meaning. An optional third step follows the same idea. The interface should let someone describe the work in order, then persist that order as real links rather than just placing three cards beside each other.
02
A link needs an event and a delay
“After this task” is incomplete. After it is completed? After someone rescues it? After it is skipped? The builder made that condition explicit and paired it with a delay in hours.
The delay belongs to the transition between tasks. It is different from the recurring cadence of the starter task. Keeping those concepts separate makes it possible to explain why a follow up becomes due when it does.
Inside the screen
Completed, rescued, or skipped?
The trigger controls expose a product question that a simple checklist would hide: which event should actually release the next step?
Select a detail
Completed, Rescued, and Skipped are separate choices. I want their meanings to survive in the rule, rather than treating every way of closing a task as equivalent.
The delay label runs into the lower boundary here. I would inspect scrolling and the fixed actions before presenting this version as effortless to configure.
Original May editor capture. The delay controls are crowded near the bottom of the view.
03
The later screen exposes two clocks at once.
The September development capture puts the delay between steps and the repetition of the whole chain in separate places. That is a useful evolution to inspect alongside the original May captures. The visual line connects the steps. The repeat control describes when the sequence comes around again. The screen can now explain why there are two different timing decisions without requiring the person to know the planner’s terminology.
The saved May screenshot also preserves a cramped area around the trigger and delay. I want that visible because it says something real about the work: the sequence existed before every edge of its presentation was resolved. My next check would follow a completed starter into the waiting state of its successor, then into readiness after the delay. A screenshot demonstrates the controls. The event sequence demonstrates whether the product honours them.
The recurrence of a sequence is different from the delay between its steps. I return to that question in Monthly should mean a month after it was last done.
Inside the screen
Two clocks, shown separately.
The later editor gives the delay between steps and the repeat interval their own places in the sequence.
Select a detail
The explanatory line sits above the step structure. That proximity matters because the relationship is less familiar than the individual task fields.
The 2h marker belongs to the connection between tasks. It answers when the next action can start after the triggering event.
The 7d marker describes another clock. I want a reader to distinguish this recurrence from the short delay without knowing our internal implementation vocabulary.
September application development preview with empty demo steps. It shows the controls, not a completed household setup.
Where this chapter landed
What changed.
A dedicated chain builder and ordered backend creation were implemented, including an optional third task, trigger choices, and delays.
Added while revisiting this story · September 2026
The thinking behind the detail.
Research notes to take these decisions further. These sources were reviewed for this retrospective.
Group the relationship, too
W3C describes grouping as a way to make related controls understandable. In a chain builder, the predecessor, trigger, and delay need shared context, while the cadence of the whole sequence remains a distinct decision.