Diary: replace the broken numbered pager with scroll-driven batch loading

[steilerDev]

As a homeowner browsing my construction diary, I want older entries to load automatically as I scroll so that I can move through my history in one continuous timeline instead of operating a numbered pager that does not work.

Parent Epic: none (EPIC-13 Construction Diary is closed; filed standalone — see the diary cluster note below)
Priority: Should Have

---

Problem

Two user-reported defects on the diary page (/diary), both rooted in the hand-rolled pagination on that page:

1. The pager does not work. Clicking "Next" / "Previous" has no effect. On mobile nothing visibly happens at all; on desktop the page smooth-scrolls to the top but the list stays on page 1. Editing ?page= in the address bar by hand does work, because that is a full page load.
2. There is no way to choose how many entries are shown per page. The page size is fixed and not exposed anywhere in the UI.

The user's decision is not to repair the pager but to replace it: "could we rework this, such that we don't have static page numbers, but are dynamically loading items in as the user scrolls."

Root cause (already investigated — do not re-investigate)

All in client/src/pages/DiaryPage/DiaryPage.tsx:

• handlePageChange (~line 222) writes page into the URL via setSearchParams, then calls window.scrollTo({ top: 0, behavior: 'smooth' }).
• The debounced-search sync effect (~lines 70–83) lists searchParams in its dependency array. Any searchParams change re-runs it, and once past the first render (isFirstSearchSyncRef.current is false) it unconditionally executes newParams.set('page', '1'); setSearchParams(newParams).
• Therefore every pager click is immediately reverted to page 1, while the smooth scroll still runs — exactly the reported desktop symptom. On mobile the scroll is a no-op, so "nothing happens".
• Manually entering a ?page= URL works because it is a full remount: isFirstSearchSyncRef is re-initialised to true, so the reset effect is skipped on that first pass.
• pageSize is hardcoded to 25 at line 43 — this is why there is no per-page control.

Expected behaviour

The numbered pager is replaced by continuous ("infinite") scroll loading:

• The diary page loads a first batch of entries and renders them in the existing date-grouped timeline.
• As the user scrolls toward the bottom of the list, the next batch is fetched and appended below the entries already shown; the reading position does not jump.
• Loading a batch shows a clear loading affordance at the bottom of the list, not a full-page loading state that blanks the already-loaded entries.
• When there are no more entries, the list says so and stops issuing requests.
• Changing any filter (mode, types, date range, drafts toggle) or the search query resets the timeline to a fresh first batch.
• A failed batch shows an error at the bottom of the list with a retry action; entries already loaded remain on screen.
• An explicit, keyboard-reachable "Load more" control remains available alongside the automatic loading.

Assumptions (flagged — challenge before implementing if any is wrong)

1. The numbered pager is removed entirely — the prev/next buttons, the "Page X of Y" indicator, and the ?page= URL parameter all go away.
2. No page-size selector is added. Problem (2) above is considered resolved by the rework: with entries loading continuously there is nothing for the user to size. Page size becomes an internal batch size, not a user-facing setting.
3. Filter and search state stays in the URL exactly as it is today (q, dateFrom, dateTo, filterMode, types, status). Only page leaves the URL. Changing a filter resets the list to the first batch.
4. The total entry count in the header subtitle is retained ("N entries"), and continues to reflect the total matching the current filters — not the number currently loaded.
5. Per CLAUDE.md's Component Reuse Policy, the scroll-loading mechanism is built as a reusable shared component and/or hook under client/src/components/ or client/src/hooks/ — not as a one-off inside DiaryPage. Other list views must be able to adopt it later. Note: no IntersectionObserver usage exists anywhere in client/src/ today, so this is new shared infrastructure.
6. No backend change is expected. GET /api/diary-entries already returns pagination.totalPages / totalItems and accepts page + pageSize, so batches can be requested by incrementing the page internally. If the architect finds a stability problem with offset paging over a list that can gain entries while being scrolled, that is a legitimate escalation — flag it rather than silently changing the contract.
7. The "Load more" button is an accessibility fallback and the retry affordance — not a substitute for auto-loading. Auto-loading on scroll is the primary path; both must work.

Out of scope

• The DataTable-based list pages (Invoices, Work Items, Household Items, Vendors). They use the shared DataTable with its table-state reducer and are not affected by this defect. Adopting the new scroll mechanism there is a separate future decision.
• Adding a page-size selector anywhere (see assumption 2).
• Changing diary filtering, search semantics, entry grouping, or the diary entry cards themselves.
• Backend pagination contract changes (see assumption 6).

Acceptance Criteria

Initial load

• 1. Given diary entries exist and no filters are applied, When I open /diary, Then the first batch of entries is rendered in the existing date-grouped timeline and no numbered pager, "Page X of Y" indicator, or prev/next buttons appear anywhere on the page.
• 2. Given the diary page has loaded, When I inspect the page header, Then the subtitle shows the total number of entries matching the current filters (not the number currently loaded).

Scroll-driven loading

• 3. Given more entries exist than are currently loaded, When I scroll toward the bottom of the list, Then the next batch is requested automatically and appended below the entries already shown.
• 4. Given a batch is being appended, When it renders, Then the entries already on screen stay mounted and my scroll position is not reset to the top and does not jump.
• 5. Given a batch request is in flight, When I look at the bottom of the list, Then a loading affordance is visible there and the already-loaded entries remain visible (no full-page loading state replacing the list).
• 6. Given a batch request is in flight, When further scroll events fire before it resolves, Then no additional request for the same batch is issued (no concurrent or duplicate requests for one batch).

End of list

• 7. Given all matching entries have been loaded, When I scroll to the bottom, Then an end-of-list message is shown and no further requests are made, however far I keep scrolling.
• 8. Given the filters match fewer entries than one batch, When the page loads, Then all entries are shown, the end-of-list state is reached immediately, and no second request is made.
• 9. Given no entries match the current filters, When the page loads, Then the existing empty state is shown and no end-of-list message or "Load more" control is rendered.

Filter and search reset

• 10. Given several batches are loaded, When I change any filter (mode, types, date from/to, drafts toggle), Then the timeline resets to a fresh first batch for the new filters, previously loaded entries for the old filters are discarded, and the header total updates.
• 11. Given several batches are loaded, When I type a new search query and the debounce elapses, Then the timeline resets to a fresh first batch for that query and the URL retains the search/filter parameters as it does today.
• 12. Given any filter or search change, When the URL updates, Then it contains no page parameter.

Error and retry

• 13. Given one or more batches are loaded, When a subsequent batch request fails, Then an error message with a retry action is shown at the bottom of the list and every already-loaded entry remains on screen.
• 14. Given a batch has failed, When I activate retry, Then the same batch is re-requested and, on success, appended in the correct position with no duplicated and no skipped entries.
• 15. Given a batch has failed, When I keep scrolling without activating retry, Then no automatic re-request loop occurs.

Accessibility

• 16. Given the diary page is loaded and more entries exist, When I navigate with the keyboard only, Then I can reach a visible "Load more" control and activating it loads the next batch — without needing to scroll with a pointer.
• 17. Given I use a screen reader, When a new batch is appended, Then a polite live-region announcement states that new entries were loaded and how many.
• 18. Given I use a screen reader, When the end of the list is reached, Then that fact is announced/exposed rather than being conveyed by visual position alone.
• 19. Given the "Load more" control and the retry control, When they receive keyboard focus, Then a visible focus indicator is rendered in both light and dark mode.

Legacy URLs

• 20. Given an old bookmark of the form /diary?page=3 (optionally with other filter params), When I open it, Then the page loads normally from the first batch, the other filter params are still honoured, no error is shown, and the stale page parameter does not affect what is loaded.

Reuse and viewports

• 21. Given the Component Reuse Policy, When the mechanism is implemented, Then the scroll-loading logic lives in a reusable shared component and/or hook under client/src/components/ or client/src/hooks/, with DiaryPage as its consumer — no scroll-observer logic implemented inline in DiaryPage.tsx.
• 22. Given the desktop, tablet, and mobile viewports, When I repeat criteria 3, 4, 7, 10, and 16 on each, Then the behaviour holds on all three; in particular, on mobile the interaction that previously "did nothing" now loads further entries.
• 23. Given the reworked page, When it renders in dark mode, Then the loading, end-of-list, error, and "Load more" states all use design tokens and are legible.

UAT Scenarios

UAT-1 — Continuous scrolling replaces the broken pager
Given I have more than one batch of diary entries
When I open the diary page and scroll down to the bottom repeatedly
Then older entries keep appearing beneath the ones I was reading, my place in the list is never lost, and I never see page numbers or next/previous buttons.

UAT-2 — Mobile, the originally reported symptom
Given I am on a phone-sized viewport with more than one batch of entries
When I scroll to the bottom of the diary list
Then more entries load (previously nothing happened at all).

UAT-3 — Reaching the end
Given I keep scrolling until the oldest entry is shown
When I continue to scroll
Then I see a clear "no more entries" indication and the app stops trying to load anything further.

UAT-4 — Filtering resets the list
Given I have scrolled through several batches
When I switch the filter mode, change the date range, or type a search term
Then the list starts again from the newest matching entry and the entry count in the header matches the new filter.

UAT-5 — Recovering from a failed load
Given I have several batches loaded and the next batch fails (e.g. the connection drops)
When I see the error at the bottom of the list and press retry after reconnecting
Then the entries I had already read are still there and the next batch loads and appends correctly, with no duplicates.

UAT-6 — Keyboard-only use
Given I navigate the diary page using only the keyboard
When I tab to the "Load more" control and press Enter
Then the next batch loads and I can continue reading — I am never forced to scroll with a pointer.

UAT-7 — Old bookmark
Given I have an old bookmark pointing at /diary?page=3
When I open it
Then the diary opens normally at the top of the list with no error.

Notes

• Filed standalone: the natural parent (EPIC-13, Construction Diary) is closed and there is no open epic covering diary work. This is another entry in the standalone diary cluster — when a diary v2 epic is opened, link this issue to it.
• This issue replaces a UX mechanism and closes out the underlying defect; it is labelled user-story rather than bug for that reason. It is not "done" until the reported pager symptoms are gone, which criterion 22 pins explicitly.
• Existing pager i18n keys (pagination.previous, pagination.next, pagination.pageInfo in the diary namespace) become unused on this page — remove them if nothing else consumes them, and note that new keys for the loading, end-of-list, error/retry, and "Load more" states need translating.
• Existing E2E selectors data-testid="prev-page-button" / data-testid="next-page-button" on the diary page disappear with the pager; any E2E test referencing them must be updated rather than deleted wholesale — the coverage they represented (paging to older entries) moves to the scroll flow.

[steilerDev]

[ux-designer]

Visual Specification — Scroll-driven batch loading (replaces the diary pager)

Read wiki/Style-Guide.md, client/src/styles/tokens.css, client/src/styles/shared.module.css, the current client/src/pages/DiaryPage/DiaryPage.tsx / .module.css, and the existing Skeleton/Spinner/FormError/EmptyState components before writing this. Two corrections to the story text as written, flagged up front so implementers don't chase the wrong target:

• There is no --breakpoint-* token family in tokens.css. Breakpoints in this codebase are raw px values inlined per media query (CSS custom properties cannot be used inside @media conditions at all — that's a CSS spec limitation, not an oversight here). The diary component tree's existing convention is @media (max-width: 767px) for mobile and, where a tablet tier is needed, @media (min-width: 768px) and (max-width: 1023px) (see DiaryEntryForm.module.css). This spec follows that convention: mobile ≤767px, tablet 768–1023px, desktop ≥1024px.
• The current "initial load" state is not a skeleton. DiaryPage.tsx line 270 renders shared.loading — a centered text string ("Loading entries...") — not the Skeleton component. See item 3 below.

---

Component Reuse Audit

UI Element	Shared Component	Props/Variant	Notes
Append-in-flight indicator	Spinner	size="md" color="muted"	New usage; see item 2 for why Spinner over Skeleton here
Initial full-page loading	(unchanged) shared.loading	—	Existing plain text state; out of scope, do not touch
Batch-failure banner	FormError	variant="banner"	Reused as-is; gives role="alert" for free
Load more / Retry button	shared.btnSecondary	—	Same visual weight as the removed pager buttons
Empty state (0 entries)	(unchanged, pre-existing gap)	—	See item 7 — flagged, not fixed here

New shared component required: client/src/components/InfiniteScrollFooter/InfiniteScrollFooter.tsx (+ .module.css) — no existing component covers "sentinel + append-status footer for a scrolling list," and per assumption 5 this must be reusable, not diary-specific. Full visual contract below.

New shared hook required: client/src/hooks/useInfiniteScroll.ts — no IntersectionObserver usage exists anywhere in client/src/ today (confirmed). This is behavioral, not visual, so its exact TypeScript signature is the frontend-developer's/architect's call, but the visual component's props are shaped around the state machine below so I'm naming it here for coherence: status: 'idle' | 'loading' | 'error' | 'done', a sentinelRef, and loadMore() / retry() callbacks. Do not let observer/scroll logic live inside DiaryPage.tsx (AC21) or inside the visual component — the component only renders what the hook tells it.

---

1. Sentinel / trigger zone

• The sentinel is a 0-dimension, aria-hidden="true" <div> rendered as the first child inside InfiniteScrollFooter, i.e. it sits directly after the last DiaryDateGroup in .timeline and immediately above the visible footer content (spinner/button/error/end-message row).
• Trigger distance: use IntersectionObserver's rootMargin, not a hand-rolled scroll-position calculation — a scroll-offset onscroll handler is exactly the class of bug this issue is replacing (the old code's problem was reset logic, but hand-rolled scroll math is fragile against mobile momentum-scroll in the same way). Set rootMargin: '0px 0px 600px 0px' — a single constant, uniform across all three breakpoints. This is a JS constant (IntersectionObserver options are not CSS), so it is intentionally not a design token; name it something like INFINITE_SCROLL_LOOKAHEAD_PX = 600 in the hook so it's a single tunable value.
• Rationale for 600px and for using IntersectionObserver at all: mobile momentum scroll (a single finger-fling) can cover several hundred pixels between paint frames, which is why the original bug's mobile symptom was "nothing happens" — a scroll-position check that only samples on discrete scroll events can miss the trigger point entirely. IntersectionObserver doesn't sample scroll position at all; it fires the instant the sentinel crosses the (expanded) root, regardless of how fast the fling was. 600px gives roughly 2–3 diary-card-heights of lead time on desktop for a network round trip to resolve before the user physically reaches the fetch boundary, and is generous enough on short mobile viewports to start the fetch well before the visible bottom.

2. Loading state for an appended batch

• Use Spinner, not Skeleton, for this state. Justification: Skeleton approximates content with fixed-line placeholders, which works when the incoming content has a roughly known, uniform shape (that's why it's right for the initial load — see item 3). Diary entry cards are highly heterogeneous in height (materials lists, photo counts, signatures, 1–3 line clamped bodies, automatic vs. manual card variants with different footers) — any fixed-height skeleton block would either overshoot or undershoot the real batch's height, producing a second, more jarring layout jump exactly where AC4 requires none. A compact, fixed-height spinner row never resizes when replaced by real content above it — the entries above it grow, which is expected content growth, not layout shift of the loading affordance itself.
• Rendered inside InfiniteScrollFooter when status === 'loading': <Spinner size="md" color="muted" label={t('infiniteScroll.loadingMoreAriaLabel')} /> plus visible text t('infiniteScroll.loadingMore') ("Loading more entries…"), laid out as a horizontal flex row, centered, gap: var(--spacing-2).
• Container sizing: min-height: var(--spacing-12) (48px) on the footer's status row across all four states (loading / error / done / ready-with-button) so switching between them doesn't itself cause a height jump in the footer — only the entries list above grows, which is the intended, expected motion.
• No skeleton "rows" — a single spinner + label is the entire affordance. There is nothing else to specify per-row because there are no rows.

3. Initial load

Unchanged, out of scope. Confirmed against the current code: initial load already shows shared.loading (centered text, min-height: 400px, color: var(--color-text-muted), font-size: var(--font-size-base)) while isLoading is true, replacing the entire content area including the filter results — this stays exactly as-is for the first batch of a fresh filter set (AC1, AC10, AC11 "resets to a fresh first batch"). Do not introduce Skeleton here as part of this story — that would be a scope-creep visual change to an already-working, unrelated state. If a future story wants to upgrade this to Skeleton-based loading, that's a separate visual spec.

4. End-of-list treatment

• Rendered inside InfiniteScrollFooter when status === 'done', replacing the button/spinner row entirely (the Load More button unmounts — see item 6).
• Visual: centered text row, border-top: 1px solid var(--color-border) (separates it from the last entry card above, echoing the divider language used elsewhere for list-terminal states), padding: var(--spacing-6) var(--spacing-3), color: var(--color-text-muted), font-size: var(--font-size-sm) — token values match shared.emptyState / shared.loading for family consistency even though this isn't literally those classes (a slim footer row, not a full content-replacing block).
• New i18n keys, English only, diary namespace, new infiniteScroll object:

"infiniteScroll": {
  "loadingMore": "Loading more entries…",
  "loadingMoreAriaLabel": "Loading more diary entries",
  "loadMoreButton": "Load more",
  "retryButton": "Retry",
  "errorMessage": "Failed to load more entries.",
  "endOfList": "You've reached the end — no more entries to load.",
  "batchAppendedAnnouncement": "{{count}} more entries loaded",
  "batchAppendedAndEndAnnouncement": "{{count}} more entries loaded. You've reached the end.",
  "endOfListAnnouncement": "You've reached the end — no more entries to load."
}

Translator handles German; these are the English source keys only.

• Cleanup note for the frontend-developer: diary.pagination.previous / diary.pagination.next / diary.pagination.pageInfo become unused once the pager is removed — confirmed via repo-wide grep that nothing outside DiaryPage.tsx references the diary namespace's pagination.* keys (the other dataTable.pagination.* keys belong to a different component/namespace and are unaffected). Remove the three diary.pagination.* keys from client/src/i18n/en/diary.json (and the German mirror) rather than leaving them dangling.

5. Error + retry

• On a failed batch request, status becomes 'error'. Already-loaded entries stay mounted — this is purely an additive change to the footer, no re-render of .timeline.
• Render <FormError message={t('infiniteScroll.errorMessage')} /> (banner variant — default) inside InfiniteScrollFooter, above the button row. This gets role="alert" for free, so screen readers announce the failure immediately without needing the shared announcementRef live region (that region is reserved for polite success/end-of-list announcements — see item 9; don't route the error through it too, that would double-announce).
• The button directly beneath FormError relabels to Retry — see item 6, this is the same DOM node as the "Load more" button, not a second button.
• No automatic retry loop (AC15). While status === 'error', the sentinel stays in the DOM (so a future successful retry can re-arm auto-loading) but the hook must not re-trigger loadMore() from intersection events while in the error state — only an explicit retry() call (i.e., the button) clears the error and re-issues the same batch request. Scrolling past the sentinel again while errored must be a no-op.

6. The "Load more" fallback button

• Single persistent <button type="button" className={shared.btnSecondary}> — never unmounted while hasMore could still be true. Its label and disabled state change with status, but it stays the same DOM node across state transitions so a keyboard user's focus is never dropped mid-interaction:
  • status === 'idle' (ready, no fetch in flight): enabled, label t('infiniteScroll.loadMoreButton') ("Load more").
  • status === 'loading': disabled, label swaps to an inline <Spinner size="sm" color="muted" /> + t('infiniteScroll.loadingMore') text inside the button itself — do not hide/remove the button on click, disable it in place. This is the standard accessible pattern for a just-clicked action button (focus was already on it at the moment of activation) and it also visually reads as "you clicked this, it's working," which the separate spinner row (item 2) reinforces below/around it.
  • status === 'error': enabled, label swaps to t('infiniteScroll.retryButton') ("Retry").
  • status === 'done': button unmounts entirely, replaced by the end-of-list row (item 4). Note for the a11y section (item 9): this is the one state where the button's DOM node genuinely disappears; that's expected browser-default focus loss from a successful action, not "stealing" focus.
• Placement: inside InfiniteScrollFooter, below the sentinel, centered within the same 900px-max-width column as .timeline (.page in DiaryPage.module.css already constrains width — the footer sits inside that same flow, no separate width override needed).
• Sizing: desktop/tablet — auto width, centered via flex, comfortable click target (shared.btnSecondary's existing padding already clears 44px height at --font-size-sm + --spacing-2-5 vertical padding — verify against the rendered box, don't assume). Mobile (≤767px, matching the existing .createButton/.exportButton pattern in DiaryPage.module.css): width: 100%, min-height: 44px.
• Relationship to the sentinel (assumption 7 is explicit that this is not a hidden fallback): the button is visible at all times whenever hasMore is true, concurrently with the auto-loading sentinel — not conditionally rendered only when JS/observer support is absent. A keyboard-only user can reach and activate it without ever triggering the observer (satisfies AC16 independent of scroll). Both paths call the exact same loadMore() function from the hook, so there is exactly one code path for "fetch the next batch," eliminating any chance of the button and the observer racing each other into a duplicate request (AC6 also requires the hook to guard against concurrent in-flight duplicates regardless of which trigger fired).

7. Empty state

Confirmed unaffected — AC9. When entries.length === 0 after the first (only) batch, the page returns before rendering .timeline or InfiniteScrollFooter at all (matches current early-return structure at DiaryPage.tsx lines 272–287) — no end-of-list message, no Load More button, no sentinel.

Flagged, non-blocking, out of scope for this story: the current empty state does not use the shared EmptyState component — it hand-rolls <div className={shared.emptyState} style={{ display: 'flex', ... }}> with inline style props. Per CLAUDE.md's Component Reuse Policy this should be <EmptyState message={t('empty.title')} action={{ label: t('empty.createButton'), href: '/diary/new' }} /> (icon omitted per the Style Guide's "filter returned no results vs. resource doesn't exist yet" distinction — actually this is closer to the "doesn't exist yet" case since it's a true zero-entries state, so an icon may be appropriate; that's a product-owner/content call, not mine to make unilaterally). Inline style props also bypass Stylelint's token enforcement entirely since it only scans .css/.module.css files. This is pre-existing debt, not introduced by this story, and AC9 only requires the behavior stay unaffected — I'm flagging it so it's a recorded, intentional deferral rather than a silent gap. Recommend a follow-up ticket.

8. Responsive behaviour

• Desktop (≥1024px) / Tablet (768–1023px): InfiniteScrollFooter content is centered in the same 900px column as the rest of .page. Button auto-width. Spinner row and end-of-list row both centered, no layout differences between these two tiers for this component — the diary page doesn't currently split tablet from desktop anywhere in DiaryPage.module.css, only mobile-vs-not, so don't introduce a tablet-specific branch here unless testing surfaces a real need.
• Mobile (≤767px): button goes full-width with min-height: 44px (matches .createButton/.exportButton). Spinner row and end-of-list row padding drop to the mobile scale already used in DiaryPage.module.css's @media (max-width: 767px) block (var(--spacing-4) instead of var(--spacing-6) where the desktop rule uses --spacing-6).
• Touch/momentum scroll: this is where the original bug was most visible (AC22, UAT-2), so be explicit in implementation review: the fix is entirely in using IntersectionObserver with the generous rootMargin from item 1 rather than any scroll-event math — there is no separate "mobile trigger distance," the same 600px rootMargin constant applies uniformly. Do not scale rootMargin down for mobile "to save requests" — a smaller lookahead on the exact viewport class that showed the original symptom would be counterproductive.

9. Accessibility

• aria-busy: set aria-busy={status === 'loading'} on the existing role="feed" .timeline container (both for the initial load and for batch appends — for the initial load this is aria-busy={isLoading} since the timeline isn't rendered at all yet during that phase... actually since .timeline doesn't render until !isLoading, aria-busy on it is only meaningful for the append case; that's fine, it's the ARIA feed pattern's documented use — "busy" describes the feed while it's fetching more of its own content, which is exactly the append case).
• Live region: reuse the existing announcementRef div (role="status" aria-live="polite" aria-atomic="true") already in DiaryPage.tsx — do not add a second live region; two simultaneous role="status" nodes is a common, avoidable screen-reader double-announcement bug.
  • On successful append with more remaining: t('infiniteScroll.batchAppendedAnnouncement', { count: newItems.length }) → "12 more entries loaded."
  • On successful append that also exhausts the list: t('infiniteScroll.batchAppendedAndEndAnnouncement', { count: newItems.length }) (single combined utterance — don't fire two separate announcements back to back, they can clip each other in some screen readers).
  • Initial load keeps its current, unchanged announcement text ("Loaded {N} entries") — the distinct append phrasing lets a screen reader user tell "first load" from "more appeared" apart, which they can't do from identical text.
  • The FormError banner's own role="alert" handles the error case (item 5) — don't also route errors through announcementRef.
• Focus management: appending a batch must never call .focus() on anything, and must never call window.scrollTo(...) or scrollIntoView(...) in any form — smooth or instant. This is a full removal, not a reduced-motion-gated softening, of the exact window.scrollTo({ top: 0, behavior: 'smooth' }) call the root-cause section identifies at the old handlePageChange (line 226) — infinite scroll has no equivalent "jump to top" moment at all. The one exception already specified in item 6: when status flips to 'done', the Load More button unmounts and focus falls to document.body per ordinary browser default — that's an inherent consequence of removing a focused element after a successful user-initiated action, not the app "stealing" focus, and is acceptable.
• Keyboard reachability: the Load More/Retry button is a plain, always-rendered (until 'done') tab stop at the natural end of the DOM — no tabindex overrides, no visually-hidden-until-hover tricks. It must be reachable by Tab alone with no scrolling required (AC16), which falls out naturally from it not being inside a scroll-clipped or overflow:hidden container.
• prefers-reduced-motion: three things to check, none of them new patterns — all already established elsewhere in this codebase:
  1. Spinner's rotation already has a reduced-motion guard (Spinner.module.css: animation removed, static opacity: 0.5 fallback) — nothing to add, just don't bypass it by re-implementing the spinner inline.
  2. If InfiniteScrollFooter adds any transition (e.g. a fade when swapping between loading/error/done rows), wrap it in the positive-guard form used by the Photo Annotator pattern: @media (prefers-reduced-motion: no-preference) { .footerRow { transition: opacity var(--transition-normal); } } — not a negative override.
  3. Confirm in code review that no scrollIntoView/scrollTo call exists anywhere in the new hook or component — per the focus-management note above this isn't a "reduce motion" concern, it's a "doesn't exist at all" requirement, but reviewers should treat any resurfacing of scroll-to-position logic as a regression back toward the original bug regardless of what triggers it.

10. Dark mode

Every new visual value routes through an existing semantic token already verified dark-mode-correct elsewhere in the app — no new tokens needed:

Element	Token(s)
Loading row text	var(--color-text-muted), var(--font-size-sm)
Spinner	color="muted" → var(--color-text-muted) (via Spinner's internal COLOR_MAP)
End-of-list divider	border-top: 1px solid var(--color-border)
End-of-list text	var(--color-text-muted), var(--font-size-sm)
Error banner	FormError banner variant → var(--color-danger-bg) / var(--color-danger-border) / var(--color-danger-active) (unchanged, already dark-correct)
Load more / Retry button	shared.btnSecondary → var(--color-bg-tertiary) / var(--color-text-secondary) / var(--color-border-strong), hover var(--color-bg-hover), focus var(--shadow-focus) (unchanged, already dark-correct)
Footer container spacing	var(--spacing-4) / var(--spacing-6) / var(--spacing-3) / var(--spacing-12) per item 2/4/8

No hardcoded hex/px/rgba anywhere in the new .module.css — npm run lint's Stylelint step will catch any regression, but flag it in review regardless since this is new-component surface area, not a diff against existing rules.

---

Summary for implementers

• New shared hook: client/src/hooks/useInfiniteScroll.ts — owns IntersectionObserver, the idle|loading|error|done state machine, in-flight dedupe, and the 600px rootMargin constant. Generic over item type so future list views (see the issue's "Reuse" note) can adopt it without diary-specific coupling.
• New shared component: client/src/components/InfiniteScrollFooter/InfiniteScrollFooter.tsx + .module.css — purely presentational, driven by status/hasMore/onLoadMore/onRetry props, renders the sentinel + one of (spinner row / error banner + button / end-of-list row / ready button).
• DiaryPage.tsx: replace the Pagination block (lines 306–331) and the currentPage/totalPages/pageSize-as-URL-param wiring with a consumer of the new hook; drop the ?page= URL param handling (AC12, AC20) while keeping q/dateFrom/dateTo/filterMode/types/status exactly as-is (assumption 3); remove handlePageChange and its window.scrollTo call entirely.
• i18n: add the infiniteScroll block above to client/src/i18n/en/diary.json; remove the three now-dead pagination.* keys from the same file (and the German mirror, translator's task).
• E2E: data-testid="prev-page-button" / data-testid="next-page-button" disappear — not my area, flagging per the issue's own note for e2e-test-engineer.

[steilerDev]

[product-owner]

Duplicate-check result + one factual correction (2026-09-04)

A request came in to file this work as a new issue (reported as: "Diary page navigation is broken, direct links work but the 'next' and 'previous' button don't [work]. Instead of static pagination, can we not load the rows on the fly?"). No new issue was created — this one already covers it in full, including the same diagnosed root cause (the debounced-search-sync effect at ~lines 70–83 of DiaryPage.tsx listing searchParams, which useSearchParams() re-identifies on every URL change, unconditionally re-running newParams.set('page', '1')), the same product decision (replace the pager with scroll-driven loading rather than repair it), and every acceptance criterion asked for:

Requested coverage	Already covered by
Scroll near bottom auto-loads and appends, with a visible loading indicator	AC 3, 5
No duplicate or missing entries across page boundaries	AC 6, 14
Existing filters (search, date range, type, status) keep working; changing one resets to the first page	AC 10, 11
Keyboard-reachable non-scroll "Load more" — not scroll detection alone	AC 16, 19 (plus AC 17, 18 for screen-reader announcement)
Underlying stale-effect bug is fixed, validated through the new mechanism	AC 22 (explicitly re-runs the mobile symptom that previously did nothing)

Correction to assumption 6. The body said the endpoint is GET /api/diary. It is GET /api/diary-entries — registered at that prefix in server/src/app.ts:268 and called as /diary-entries?… in client/src/lib/diaryApi.ts:43. The body has been edited in place to say GET /api/diary-entries. No acceptance criterion was touched and no AC numbering changed — the edit is that endpoint path only. Everything else about assumption 6 stands: the endpoint already accepts page + pageSize and returns pagination.totalPages / totalItems, so no API contract change is expected, and an offset-paging stability concern remains a legitimate escalation rather than a silent contract change.

No other change to scope, priority (Should Have), or board status (In Progress).