fix(day): hide tracking bar once a work period has any end, even a future one

Pressing Stop with a future custom time (or editing times to declare a
future end) previously kept the Stop/Start-subtask bar visible, since
Planned-Stop WorkPeriods were treated as still live per ADR 0009. There is
no data-model way to tell that apart from "already stopped, with a
projected end", so findActiveTracking now only counts a fully open
WorkPeriod (end === null) as active. Documented in ADR 0012.

Author: te-ce

docs/adr/0012-planned-stop-not-live-for-tracking-bar.md

@@ -0,0 +1,64 @@
+# ADR 0012: Planned-Stop WorkPeriods Are Not "Live" for the Tracking Bar
+
+## Status
+
+Accepted
+
+## Context
+
+ADR 0009 classifies a WorkPeriod whose `end` is a future HH:MM as a
+Planned-Stop WorkPeriod, and states it "is treated as live-tracked until
+`end` passes". `findActiveTracking` (`src/features/day/dayStreamModel.ts`)
+implemented this literally: it fell back to `findActivePeriod`, which
+returns a Planned-Stop WorkPeriod when there is no fully open one.
+
+A future `end` can be written in two ways that are indistinguishable
+afterward: pressing "Stop work" with a custom future time in
+`TimeNowField`, or editing an open period's times directly and setting its
+end to a future value. Either way, the tracking bar (`ActiveTrackingRow`)
+stayed visible with "■ Stop work" and "▶ Start subtask" — because the
+period still looked "live" by ADR 0009's rule. For the Stop-button case in
+particular this reads as a bug: the user just pressed Stop, there is no
+open WorkPeriod (`end !== null`), yet the UI still offers to stop tracking.
+
+There is no data-model hook to tell the two paths apart after the fact —
+both just leave a WorkPeriod with a future `end`. Fixing the Stop-button
+case without also changing the edit-times case is not possible without a
+new field (the Option A that ADR 0009 already rejected), so both now
+behave the same way.
+
+## Decision
+
+`findActiveTracking` now only treats a fully open WorkPeriod (`end ===
+null`) as the currently-tracked session. A Planned-Stop WorkPeriod no
+longer counts as active for this purpose. Once any WorkPeriod's `end` is
+set — whether by pressing Stop or by editing times to declare a future
+end — the tracking bar falls back to `NotTrackingRow`/`LogPastWorkRow`
+immediately, even if that end is still in the future.
+
+This only changes what counts as "active tracking" for the bar and for
+`DayStats.runningSince`/`lastStop`. It does not touch `isPlannedStop`,
+`findPlannedStopPeriod`, `findActivePeriod`, or `derivePlannedStopState` in
+`src/shared/worktime.ts` — the countdown-to-planned-stop badge/tray display
+and the projected-worked-hours totals (`BalanceRows`, `OvertimeBar`,
+`MonthProgressMeter`, `DayTotalsPanel`) still treat a declared future stop
+as something to project towards. Those features describe what the rest of
+the day is expected to look like; they don't need the Stop/Start-subtask
+controls to stay on screen to do that.
+
+## Consequences
+
+- ✅ Pressing Stop, or editing times to declare a future end, ends live
+  tracking in the UI, matching the invariant that no open WorkPeriod means
+  no "what's running" bar.
+- ❌ There is no way, with today's data model, to keep the bar live for "I'm
+  still working, planning to leave later" while hiding it for "I already
+  stopped, with a future timestamp" — both produce the same `end` value.
+  Reintroducing the former would need a separate field (ADR 0009's Option
+  A).
+- ✅ Countdown and projected-total features (ADR 0009) are unaffected — they
+  read `end` directly via `worktime.ts`, not through `findActiveTracking`.
+- ❌ ADR 0009's "treated as live-tracked" language no longer holds for the
+  tracking bar specifically; it now only describes the projection-facing
+  helpers in `worktime.ts`. Readers of ADR 0009 should cross-reference this
+  ADR for that narrower scope.

src/features/day/DayTimeline.test.tsx

@@ -280,7 +280,7 @@ describe('DayTimeline', () => {
     })
   })
 
-  it('keeps tracking when the end is set to a time still in the future', async () => {
+  it('stops tracking when the end is set to a time still in the future', async () => {
     // Given work running since 09:00
     const { repo } = setup([period('a', '09:00', null, 'Work')])
     const future = '23:59'
@@ -290,11 +290,11 @@ describe('DayTimeline', () => {
     fireEvent.change(screen.getByLabelText(/work period 1 end/i), { target: { value: future } })
     await userEvent.click(screen.getByRole('button', { name: /^save$/i }))
 
-    // Then the planned end is stored and work is still being tracked
+    // Then the planned end is stored, but there is no open WorkPeriod anymore
     await vi.waitFor(async () => {
       expect((await getWindows(repo))[0]?.end).toBe(future)
     })
-    expect(await screen.findByRole('button', { name: /stop work/i })).toBeInTheDocument()
+    expect(screen.queryByRole('button', { name: /stop work/i })).not.toBeInTheDocument()
   })
 
   it('changes the main category of a work period', async () => {

src/features/day/DayTimeline.tsx

@@ -90,7 +90,7 @@ export function DayTimeline(props: DayTimelineProps) {
   const mutations = useWorkPeriodMutations(repository)
   const stream = buildDayStream(windows, now, dayOptions)
   const stats = deriveDayStats(windows, now, dayOptions)
-  const active = findActiveTracking(windows, now, dayOptions)
+  const active = findActiveTracking(windows, now)
   const categories = getAllCategories(customCategories, categoryOrder)
   const [loggingFor, setLoggingFor] = useState<string | null>(null)
   const [deleting, setDeleting] = useState<PendingDelete | null>(null)

src/features/day/dayStreamModel.test.ts

@@ -76,25 +76,14 @@ describe('findActiveTracking', () => {
     expect(active).toMatchObject({ category: '_GUILDS', since: '13:50', elapsed: 0.5 })
   })
 
-  it('still counts a Planned-Stop WorkPeriod as running', () => {
-    // Given a WorkPeriod declared to run until 18:00
+  it('does not count a Planned-Stop WorkPeriod as running', () => {
+    // Given a WorkPeriod declared to stop at 18:00
     const windows = [period('13:00', '18:00')]
 
-    // When it is 14:00
+    // When it is 14:00, before that declared stop
     const active = findActiveTracking(windows, '14:00')
 
-    // Then work is still being tracked
-    expect(active).toMatchObject({ category: '_COREMEDIA', since: '13:00', elapsed: 1 })
-  })
-
-  it('does not read a past day’s finished WorkPeriod as a planned stop', () => {
-    // Given a day that is not today, holding a period that ended at 17:00
-    const windows = [period('09:00', '17:00')]
-
-    // When it is 14:00 on the wall clock but the viewed day is over
-    const active = findActiveTracking(windows, '14:00', { isToday: false })
-
-    // Then nothing is being tracked
+    // Then nothing is being tracked — the declared stop already closed it
     expect(active).toBeUndefined()
   })
 

src/features/day/dayStreamModel.ts

@@ -1,5 +1,5 @@
 import type { WorkPeriod, WorkPeriodSubtask } from '../../infra/repositories/types'
-import { calculateWorkedHours, elapsedHours, findActivePeriod, parseMinutes } from '../../shared/worktime'
+import { calculateWorkedHours, elapsedHours, parseMinutes } from '../../shared/worktime'
 import { findBreaks, type DayBreak } from './dayBreaks'
 import { deriveSegments, type DaySegment } from './daySegments'
 import { isLiveSubtask } from './workPeriodShared'
@@ -17,19 +17,17 @@ export interface ActiveTracking {
 }
 
 export interface DayOptions {
-  /** A Planned-Stop WorkPeriod only counts as running on today's day (ADR 0009). */
+  /** A Planned-Stop WorkPeriod's projected segment only renders on today's day (ADR 0009). */
   isToday?: boolean
 }
 
-export function findActiveTracking(
-  windows: WorkPeriod[],
-  now: string,
-  { isToday = true }: DayOptions = {},
-): ActiveTracking | undefined {
+export function findActiveTracking(windows: WorkPeriod[], now: string): ActiveTracking | undefined {
   const ordered = orderedPeriods(windows)
-  // Per ADR 0006 the latest open WorkPeriod is the current session; on today a
-  // Planned-Stop WorkPeriod counts as running too (ADR 0009).
-  const period = ordered.findLast((w) => w.end === null) ?? (isToday ? findActivePeriod(ordered, now) : undefined)
+  // Per ADR 0006 the latest open WorkPeriod is the current session. A
+  // Planned-Stop WorkPeriod (ADR 0009) is not: it already has a declared
+  // stop, so the tracking bar and "what's running" state treat it as done
+  // (ADR 0012).
+  const period = ordered.findLast((w) => w.end === null)
   if (!period) return undefined
   const subtask = period.subtasks.find(isLiveSubtask)
   const since = subtask?.startedAt ?? period.start
@@ -127,7 +125,7 @@ export function deriveDayStats(windows: WorkPeriod[], now: string, options: DayO
   const breaks = findBreaks(windows)
   const breakHours = breaks.reduce((sum, b) => sum + b.hours, 0)
   const worked = calculateWorkedHours(windows, options.isToday === false ? undefined : now)
-  const active = findActiveTracking(windows, now, options)
+  const active = findActiveTracking(windows, now)
 
   return {
     worked,