hutch.git, branch v3.8.0

chore: remove the artifacts debug probe

2026-07-16T06:21:33+00:00

It did its job: tags=1 confirmed the menu was disabled by its own tags check while the explanation sat unreachable inside it.

fix: deleted repositories linger until the cache expires

2026-07-16T06:16:39+00:00

Deleting a repository left it on the list, and pulling to refresh did not shift it. Two independent reasons, both cache-related. deleteRepository never invalidated anything. Creation invalidates the repositories and home prefixes; deletion was written without it, so the list and Home kept serving a repository that no longer exists. And forceRefresh only ever reached the build statuses — its own doc comment says so — while the repository list itself was pinned to useCache: true. So a pull to refresh re-served the same cache it already had. fetchPage already takes useCache and falls through to an uncached fetch; it was simply never told.

fix: download artifacts through the API instead of handing them to Safari

2026-07-16T06:06:46+00:00

Tapping download opened Artifact.url in the browser, which answered with "Authorization header is required". That URL is not a web page: git.sr.ht resolves it to /query/artifact//, which demands a bearer token. Safari has none and no way to get one, so the download could never have worked — this predates the upload work. Fetch it with the client that already holds the token and hand the user the file through a share sheet. fetchData mirrors fetchText, including its host guard, so an authenticated request still cannot be aimed anywhere but *.sr.ht over https. Also guards zero-byte uploads. sr.ht streams into S3, which rejects a zero-part multipart completion with "MalformedXML: UnknownError" — an error that says nothing about the cause and cost a round of testing to identify. Empty files are now refused by name before the request is made.

fix: make artifact upload actually fire, and show it when it fails

2026-07-16T05:54:59+00:00

Picking a file did nothing. The fileImporter's isPresented binding was derived from uploadTargetRef and nilled it on dismissal, but dismissal happens before the completion runs — so the completion read nil and returned without uploading. Presentation state and payload state cannot be the same state. A plain isImporting bool drives presentation now; the tag survives in uploadTargetRef until the completion consumes it. The upload menu was also disabled when the repository has no tags, while the explanation for that state lived inside the menu — unreachable exactly when it applies, so the tap died with no reason given. sr.ht requires revspec to match a tag, so having none is a real state worth explaining rather than hiding. Failures were invisible too. uploadArtifact and deleteArtifact set error, but the overlay only renders it when the list is empty, so a rejection on a repository that already has artifacts — a duplicate filename is the likely one, since sr.ht requires filenames to be unique per repository — set an error nobody saw. The tab carries an error banner now.

fix: push mailing lists locally, fix upload menu, drop the events feed

2026-07-16T05:42:38+00:00

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.

fix: blank mailing list from Projects, swipe flicker, hidden upload

2026-07-16T05:29:34+00:00

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.

fix: stop destructive swipes animating rows out before confirmation

2026-07-16T05:18:53+00:00

Swiping to delete made the row vanish and then spring back while the confirmation was still on screen. A destructive swipe action left to full-swipe performs itself on the gesture and animates the row away, but these actions only set pending state and wait for an answer, so the row returned when the data had not changed. allowsFullSwipe: false, which PasteListView already uses for exactly this confirm-then-delete shape. Both new swipes had the same omission.

chore: bump to 3.8.0 and record Phase 3 API features

2026-07-16T05:03:06+00:00

MARKETING_VERSION 3.7.0 -> 3.8.0, build 89 -> 90. SCOPE.md gains the items that did not survive contact with the API: archiveMessage and mailingListSubscribe are blocked, while webhooks, shareSecret, and build groups are reachable but declined on judgement. The reasoning is recorded so they do not get re-proposed as gaps. ROADMAP.md notes that Phase 3 is several releases rather than one, with the measured size of each.

feat: add a ticket activity feed

2026-07-16T05:00:52+00:00

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.

feat: create, edit, and delete mailing lists

2026-07-16T04:58:26+00:00

createMailingList, updateMailingList, and deleteMailingList existed in the API but were never called, so lists could only be read. Editing needed a read first. InboxMailingListReference carries only id/rid/name/owner, so a settings sheet seeded from it would have offered an empty description and Public visibility, and saving would have blanked the real description and quietly changed who can see the list. The sheet now reads the current values and refuses to save until it has them. Clearing a description sends an explicit null via updateValue rather than a nil subscript assignment, which would drop the key and leave the old text in place. permitMime and rejectMime are left untouched rather than sent empty, which would wipe the list's mime filters. Edit and delete are gated on ownership: the subscriptions query that builds this view returns lists the user follows, which is not the same as lists they own. Non-owners keep the unsubscribe action instead. Deleting destroys the archive for everyone, so the confirmation says exactly that.