ios client for sourcehut. swiftui. http://git.krz.sh/krz/hutch.git/atom?h=v3.8.2 2026-07-16T16:17:45+00:00 2026-07-16T16:17:45+00:00 Christian Cleberg hello@cleberg.net 2026-07-16T16:17:45+00:00 urn:sha1:f3c70e04148c57dcafead89b4e02b83e5f5635f8 SearchHutchIntent's route-to-Lookup stopgap and the absent OpenSavedSearchIntent are both gated on a global search/persistence layer Hutch lacks. Promote both to ROADMAP § "App Intent gaps" and replace the inline TODOs with plain references, clearing those two S1135 issues without losing the design intent. 2026-07-16T15:18:40+00:00 Christian Cleberg hello@cleberg.net 2026-07-16T15:18:40+00:00 urn:sha1:e93972f39150e5e590e49aaf46a369c463277c30 - S1871: merge the identical .home / .recentActivity deep-link cases in RootView — recent activity is a section of Home, not its own screen. - S1186: comment the two intentionally-empty Cancel buttons (PatchsetDetailView, TicketDetailView) and the empty URLProtocol stopLoading override in APICacheTests. - S108: comment the expected-miss catch block in APICacheTests. - S1172: rename the unused url parameter in mimeType(for:) to _. - S4624: extract the nested template literal in the deep-link builders (background.js, content.js) to a pathSegment variable. Left as Won't Fix, with reasons: the 35 hardcoded-URI warnings (a one-forge client and its literal-URL tests), executeCached's 8 params (38 call sites, no benefit), the forceRefresh S1172 pair (fixed as a real bug instead), S1481 on ArtifactsView (false positive — $vm.error is used), and S7785 (top-level await would break a classic content script). 2026-07-16T15:18:27+00:00 Christian Cleberg hello@cleberg.net 2026-07-16T15:18:27+00:00 urn:sha1:9834b780b24a1dd617fa761155712920159f3d8d It sat at Hutch/Hutch/App/AccountSession.swift, one level too deep. The target is a PBXFileSystemSynchronizedRootGroup rooted at Hutch/, so the file compiled by path with no pbxproj reference; moving it beside the rest of App/ needs no project-file change. Also removed the emptied Hutch/Hutch tree and the stray empty Hutch/HutchTests dir. 2026-07-16T05:42:38+00:00 Christian Cleberg hello@cleberg.net 2026-07-16T05:42:38+00:00 urn:sha1:77cd5b5e56ec054b451a6165162fef655873a5d6 Opening a mailing list from More → Projects still blanked. The cause was not in handleTabNavigation: the row called openMailingList and then dismiss(), so a path rebuild and a pop of this very view raced each other. Projects already lives in the More tab, so there is nothing to navigate to — push MailingListDetailView directly, which also lands back on the project rather than on Mailing Lists. Sources and trackers keep routing, because they really do land in other tabs. The upload controls did nothing. Two .confirmationDialog modifiers on one view leave one silently dead, and this view already had one for delete, so the tag picker never presented. It is a Menu now, which also puts the tags one tap away instead of two. The ticket activity feed is removed. todo.sr.ht's root events resolver joins event.participant_id, which references participant(id), against participant.user_id — different id spaces — so it returns an empty list for every user. The rows exist; that join cannot find them. Ticket.events is unaffected because it filters on ticket_id, which is why ticket timelines work. No client can fix this, and a screen that is permanently empty while blaming the token's scopes is worse than no screen. Recorded in SCOPE.md with the query. 2026-07-16T05:29:34+00:00 Christian Cleberg hello@cleberg.net 2026-07-16T05:29:34+00:00 urn:sha1:6898bc3fc00decee7224895ea75908daf0f97f59 Three problems from manual testing. Opening a mailing list from More → Projects showed a blank screen, while the same tap on a project pinned to Home worked. handleTabNavigation reset the target path and appended to it two Task.yields later. When the target tab is already on screen — Projects lives under More — the reset starts an animated pop of the view the user is standing on and the appends land mid-animation. From Home the tab actually changes, so the More stack is quiescent and the appends land cleanly. Each case now builds its path and assigns it once, so SwiftUI gets a single diff with nothing to race. Destructive swipe actions made the row vanish and spring back while the confirmation was still up. role: .destructive makes SwiftUI perform the row removal on activation, which allowsFullSwipe: false does not prevent — the report was a tap, not a full swipe. These buttons only record pending state and wait for an answer, so they are plain buttons tinted red instead. Six sites: the two added here, plus trackers, pastes, and tracker ACLs and labels, which had the same flicker already. The artifacts upload control was invisible. It was declared as a toolbar item from a view that is a segment inside RepositoryDetailView's tab switch rather than its own navigation destination, so it never reached the navigation bar. It is a row in the list now, and also an action on the empty state — the overlay covers the list, and a repository with no artifacts is precisely the one that needs uploading. 2026-07-16T05:00:52+00:00 Christian Cleberg hello@cleberg.net 2026-07-16T05:00:52+00:00 urn:sha1:8ee93a6a6a0e771b687d1f48a59fb896ae0456e5 todo.sr.ht's root events query returns what the authenticated user is subscribed to or implicated in, newest first, across every tracker including ones they do not own. It was never called, so the only way to notice a reply was to open the ticket. Reuses EventChange, which already decodes todo's polymorphic EventDetail for ticket timelines, so the same inline fragments describe both surfaces. Rows push straight to the ticket. events is nullable and comes back null when the token lacks the EVENTS scope, so that case reports a scope problem rather than an empty feed, which would read as "nothing has happened". Paginates rather than fetching everything: an active account's history is unbounded and the top of it is the whole point. archiveMessage, the other half of this roadmap item, is not here. It is marked @internal in the schema and inaccessible, like revokePersonalAccessToken already recorded in SCOPE.md. 2026-07-16T03:38:55+00:00 Christian Cleberg hello@cleberg.net 2026-07-16T03:38:22+00:00 urn:sha1:3611d941247a7163fce9c61d8f75a81ddedd90b7 An absent view record read as unread, so on first sign-in every thread a list had ever carried was unread. On a busy list that is thousands of threads the user never intended to read, inflating the Home dashboard, the needs-attention snapshot, and the widget with a number that means nothing. Record a baseline when an account is activated: mail that predates it is read, mail after it is not. activate() is the single funnel for launch validation, account switching, and adding an account, so one call covers every sign-in path. Accounts that already carry read state have been in use, so they get a distantPast baseline and keep every unread thread they had — upgrading must not silently mark a real backlog as read. markUnread now records an explicit distantPast marker instead of deleting the entry. Deleting would drop the thread back to the baseline rule, so marking an old thread unread would appear to do nothing. 2026-07-16T00:31:17+00:00 Christian Cleberg hello@cleberg.net 2026-07-16T00:31:17+00:00 urn:sha1:eff81f34bb51ecc6e0aa5d831567db2cea0527a9 InboxThreadSummary.id returned threadGroupingKey, which is listRID plus the subject with Re:/Fwd: stripped. Two unrelated threads on one list sharing a subject therefore shared an id — common on sourcehut, where "[PATCH] test" is an ordinary subject — which collides under Identifiable in every list that renders these summaries. Key id on the root Message-ID, which is unique per thread, and leave threadGroupingKey subject-based so replies still collapse into one conversation. Read state moves to threadGroupingKey at each call site. It was already keyed on that string via id, so persisted keys are unchanged and marking a conversation read still covers the whole subject group, matching how HomeViewModel already builds the key for isUnread. 2026-05-14T18:27:41+00:00 Christian Cleberg hello@cleberg.net 2026-05-14T18:18:55+00:00 urn:sha1:51b2eb0e6296734960f37cebd40fee34a1f261f9 - add read-only App Intents for core Hutch workflows - route intents through the existing Hutch navigation/deep-link model - expose Work Queue, Recent Activity, System Status, pinned resources, projects, failed builds, assigned tickets, saved searches, and search where supported - keep App Intents non-mutating for the initial implementation - preserve existing widget, Safari extension, and hutch:// routing behavior References: https://todo.sr.ht/~ccleberg/hutch/71 2026-05-14T17:41:55+00:00 Christian Cleberg hello@cleberg.net 2026-05-14T17:41:55+00:00 urn:sha1:0d61e05e98f6f020722ee4d43f024c1da348d2a9