bug(settings): View Preferences parity — viewing filter and tray limit missing, page-size range wrong (G35)

[Adron]

Summary

Settings ▸ Preferences shipped 2026-08-16 with three of the five documented View Preferences, and one of the three it does ship has a range the web cannot represent.

The documented pane (/help/settings, re-read 2026-09-07)

Setting	Documented range / values	macOS today
Messages per page	10 to 30	🐞 5...100 step 5 (PreferencesView.swift:57)
Viewing preference	My Messages / All Messages / Followers Only / Following Only	❌ absent
Show link previews	on / off	✅ shipped (and now backed by real previews)
Notification tray limit	10 to 40, default 20	❌ absent

Also in the same family, under Message settings: Default message visibility ✅ (shipped, PR #34) and Advanced post settings — verify the latter is present and actually controls the composer's gear affordance the way the web describes.

Why the page-size range is a real bug, not a nit

PreferencesView lets a user save 5 or 100. The web control offers 10–30, so a value saved from macOS may be unrepresentable there, and the server's own validation is unverified at those extremes. Narrow the native control to the documented range and clamp on load so an already-saved out-of-range value is corrected rather than re-sent.

viewingPreference — the one with a dependency

UserDTO.viewingPreference is decoded (UserDTO.swift:89) and deliberately excluded from UserSettings, so the timeline currently ignores a filter the account may already have set on the web. Live probe on the test account returns "viewingPreference":"all_messages", which pins the wire vocabulary for at least one value — probe the other three by setting them on the web and re-reading GET /api/user rather than guessing the snake_case forms.

⚠️ Interaction with the following feed. Following Only cannot be honoured until the backend feed exists (P1-G — re-verified broken 2026-09-05: ?scope=following returns the identical unfiltered page). Until then the picker must either omit that option or select it and show the existing "coming soon" state honestly. Decide which in the PR, do not ship a silently-wrong feed.

Division of labor

Kit

• Confirm notificationTrayLimit and viewingPreference are both accepted by PATCH /api/user/update (the verb fixed in PR fix(api): correct seven live-verb defects and repoint the GitHub issue routes #24) and that omitting them still never clobbers them.

Domain

• Add viewingPreference (typed enum + raw-string escape hatch) and notificationTrayLimit to UserSettings and its mapper.
• Clamp messagesPerPage to 10...30 and notificationTrayLimit to 10...40 on both read and write.
• Wire viewingPreference into MessagesService.timeline so the account's stored filter drives the default scope, with the .following short-circuit preserved until P1-G lands.

App

• PreferencesView: correct the stepper range; add the viewing-preference picker and the tray-limit stepper.
• NotificationsService already reads a tray limit — connect the new setting to it (nothing sets it today).
• The timeline's All/Mine/Following picker and the stored preference must not fight: decide whether the picker is a session override or writes the preference back, and document the choice in the view model.

Tests

• happy — each of the four viewing preferences round-trips
• invalid — an unrecognised viewingPreference string falls back to All rather than throwing
• upstream-failure — PATCH rejects → the pane restores the prior values and surfaces the error
• boundary — 9/10/30/31 for page size and 9/10/40/41 for the tray limit

Acceptance criteria

• No value savable from macOS is unrepresentable on the web.
• An account whose viewing preference was set on the web sees that filter honoured on launch in macOS.
• Full E2E gate green.

Notes

work-consolidation.md tracks this as G35. Size S.

[Adron]

Shipped in PR #73, merged to dev as 01bc1a9 — the missing Viewing filter and notification tray limit, the corrected 10...30 page-size range (it shipped as 5...100 step 5, able to save values the web's control cannot represent), and the already-present "Show advanced post options" toggle now actually driving the composer's gear (G35).

New ViewingPreference has four typed cases plus an .other(String) escape hatch that round-trips an unrecognised token instead of silently rewriting the account. UserSettings clamps both integers on read and write, so an account still holding a legacy value is corrected rather than re-sent.

One follow-up is tracked separately: GET /api/notifications?scope=tray returns unread-only where the web bell shows the last N regardless of read state.

Closed as part of the 2026-09-13 tracker reconciliation.