Closing the Old Loop
Focura already treats short interruptions kindly. If you close the lid mid-timer and come back soon, the timer resumes from where it froze — no penalty, no reset, just continuity.
That behavior becomes uncomfortable when the interruption is no longer short.
The Situation
Picture this: you configure a six-session work run. You get through two sessions, close the lid, and walk away for the rest of the day. The next morning, you open your laptop. The app is still holding yesterday's unfinished timer.
For a brief moment, you feel it: I didn't finish this. Then you dismiss the thought and start your day — except now you have to decide what to do with the old run before you can begin a new one.
That small re-entry cost is exactly what Focura exists to reduce.
Two Valid Needs in Tension
The root tension here isn't technical — it's about what users need after different kinds of gaps.
Short gaps deserve continuity. A meeting, a commute between rooms, an accidental lid close — these are normal interruptions. The work run is still alive in your mental context. Resuming from the frozen timer is useful and expected.
Long gaps deserve a clean slate. After several hours — or overnight — you've almost certainly context-switched. Returning to an old timer that picks up mid-session can feel sticky, or even accusatory: you left this unfinished. For ADHD users especially, that stale state becomes another re-entry barrier.
The design should avoid both extremes: don't abandon work too eagerly, but don't preserve stale state indefinitely.
The Principle
Default continuity should be forgiving, not sticky. A work run should survive short interruptions. After a long inactive gap, Focura should assume you've context-switched — and close the old loop instead of reopening yesterday's timer.
Why On by Default
We could have done nothing and let users manually close old runs. But stale in-progress state is likely more harmful than quietly closing an old work run. Focura can preserve whatever was completed, show a recap when there's something to show, and let you start fresh.
That outcome is gentler than forcing you to manually unwind yesterday's unfinished run before beginning today.
Some users intentionally park a work run for a long break and want strict continuity — a suspended state they expect to return to hours later. So the feature is configurable. Turning it off gives you "never auto-end" behavior.
Choosing the Right Threshold
Focura measures inactivity through system sleep — the same signal it already uses to freeze and resume timers. On a laptop, this is almost always a lid close. The threshold clock starts when the machine sleeps and is checked when it wakes.
A calendar-day boundary — midnight — feels arbitrary and misbehaves at the edges. A user who wraps up at 11:45 pm and returns at 12:05 am shouldn't be treated differently from someone who steps away for those same twenty minutes at noon.
An inactivity threshold handles overnight gaps, long lunches, and long same-day context switches consistently.
The default threshold is three hours. Long enough to not interrupt a deep focus run or an extended break. Short enough to prevent stale next-morning recovery in most cases. Users can adjust it from one to twelve hours in single-hour steps.
Framing: Cleanup, Not Failure
Copy matters as much as logic. The wrong phrasing reframes a neutral automatic action as evidence you didn't finish what you started.
The rule: frame this as cleanup, not failure.
Previous work run closed after inactivity.
Not:
~~Your session was abandoned.~~
~~Your timer expired while away.~~
The auto-end is the app doing its job — maintaining a clean starting point for the next time you sit down. It should never read as judgment.
Where This Lives
The setting lives in Settings under Inactivity Behavior, with a toggle and a duration slider. When disabled, the slider disappears. When re-enabled, it restores the last selected duration, falling back to three hours.
The setting label: End after inactivity — short, neutral, no unnecessary drama.