krz/hutch

  1# Roadmap
  2
  3Planned work for Hutch, ordered by dependency. Feature gaps below were
  4identified by diffing the GraphQL schema dumps in `Docs/API` against actual
  5call sites in the Swift source.
  6
  7See [SCOPE.md](SCOPE.md) for features that are intentionally out of scope.
  8
  9## SourceHut API traps
 10
 11Things the schema does not tell you, each of which has already cost real time.
 12
 13- **`Thread.updated` is not the thread's activity.** It is the root email's
 14  insert time and never advances when a reply arrives, despite the name and
 15  despite the schema describing `MailingList.threads` as ordered "most recently
 16  bumped". sr.ht returns `updated` seven seconds after `root.date` on a thread
 17  carrying four replies. Anything built on it silently treats thread creation as
 18  activity. Use `MailingList.emails`, which is reverse-chronological arrival
 19  data — see `MailingListActivity`. Prefer `Email.received` over `Email.date`:
 20  `received` is server-side and non-null, `date` comes from the sender's header
 21  and is neither.
 22- **The schema dumps in `Docs/API` are partial.** They were captured with an
 23  introspection query that omits `inputFields` and `enumValues`, so they cannot
 24  answer what a mutation's input looks like or what an enum accepts — both come
 25  back as empty arrays rather than as an error. For input shapes and enum cases,
 26  read the real SDL instead:
 27  `git clone --depth 1 https://git.sr.ht/~sircmpwn/<service>.sr.ht` and look at
 28  `api/graph/schema.graphqls`. Regenerating the dumps with a full introspection
 29  query would remove the trap.
 30
 31## Phase 0: Unblock CI — done (v3.5.0)
 32
 33Nothing downstream is trustworthy until the build badge means something.
 34
 35- ~~Fix `repo-structure-check` in `builds/swift-ci.yml`~~. It asserted
 36  `test -d "website"`, but `website/` was removed in `24c8bc6` (2026-04-10), so
 37  the check had failed since then.
 38- ~~Add a macOS CI job that runs `xcodebuild test`~~. builds.sr.ht has no macOS
 39  image and its maintainer has ruled them out, so `xcodebuild` cannot run there.
 40  The test plan now runs on the GitHub mirror via `.github/workflows/test.yml`;
 41  builds.sr.ht keeps secret scanning and structure checks.
 42
 43Turning the gate on first required making the suite green. All 214 tests had
 44been running only on demand in Xcode, and ten had rotted:
 45
 46- The `Hutch` scheme referenced `container:HutchTests` without the
 47  `.xctestplan` extension, so `xcodebuild test -scheme Hutch` — the path the
 48  README sends contributors down — could not run at all.
 49- Five were test-side rot: uppercase GraphQL enum rawValues asserted as
 50  lowercase, an ordering expectation predating `sortBuildItemsForTriage`,
 51  `request.httpBody` read inside a `URLProtocol` (always nil; the body lives on
 52  `httpBodyStream`), an incident fixture contradicting its own RSS input, and an
 53  image assertion that treated the correct `&amp;` attribute encoding as a bug.
 54- Three were real bugs the suite had been right about all along: repository
 55  descriptions could not be cleared (a nil subscript assignment drops the key
 56  instead of sending JSON null), `serviceNotProvisioned` was unreachable behind
 57  a broader `no such` match, and code spans rendered their contents as live
 58  markup.
 59- One was neither. `keepsDistinctThreadsDistinctByRootMessageID` asserted that
 60  two same-subject threads get distinct `id`s, and `eff81f3` obliged by keying
 61  `id` on the root Message-ID. The commit message claims this fixed an
 62  `Identifiable` collision; it did not, because `deduplicateThreads` merges
 63  same-subject threads into one summary before anything renders, so the
 64  collision is unreachable. The test constructed summaries by hand and skipped
 65  that step. The change is harmless and separating identity from grouping reads
 66  better, but the stated reason was wrong.
 67
 68## Phase 1: Close the write gaps — done (v3.6.0)
 69
 70Small, independently shippable mutations that already existed in the API but
 71were never called. Each removes a "why can't I do this here?" moment.
 72
 73- ~~`updateTicket`~~ — edit a ticket's subject and body after creation.
 74- ~~`deleteTicket`~~ — delete a ticket, behind a confirmation.
 75- ~~`ticketSubscribe` / `ticketUnsubscribe`, `trackerSubscribe` /
 76  `trackerUnsubscribe`~~ — `Ticket.subscription` and `Tracker.subscription` are
 77  null when not subscribed, so both toggles reflect real server state.
 78- ~~`mailingListUnsubscribe`~~ — see the caveat below.
 79- ~~`updatePreferences`~~ (todo.sr.ht and lists.sr.ht) — `notifySelf` and
 80  `copySelf`, surfaced as an Email section in Settings.
 81
 82`mailingListSubscribe` is deliberately not wired up. `MailingList` has no
 83`subscription` field, unlike `Ticket` and `Tracker`, so per-list state is only
 84knowable from the `subscriptions` query — which by definition lists what the
 85user is already subscribed to. Subscribing needs a list the user is *not*
 86subscribed to, and sr.ht exposes no discovery API to find one (see
 87[SCOPE.md](SCOPE.md) on hub.sr.ht). Revisit if hub.sr.ht ever gains an API, or
 88alongside Phase 2, which surfaces lists through patchsets.
 89
 90### Refactors folded in
 91
 92- ~~Collapse `SRHTClient`'s duplicated request paths~~. Extracted
 93  `makeAuthorizedRequest`, `send`, and `encodedGraphQLBody`; `executeMultipart`
 94  became the single-file case of `executeMultipartFiles`. The `#if DEBUG`
 95  logging block went from five copies to one. 938 lines to 569.
 96- ~~Unify the two `executeCached` overloads~~. The memory-only overload and
 97  `executeAndCache` turned out to be dead — all 38 call sites already used the
 98  TTL-aware path — so both were removed rather than merged. `responseCache`
 99  remains as the in-memory layer behind `cachedPayload`.
100
101Known follow-up: three view models still read `client.responseCache` directly.
102Tracked under Phase 3.
103
104## Phase 2: Patchsets — done (v3.7.0)
105
106The flagship gap. Sending and reviewing patches over email is the SourceHut
107contribution model, and Hutch had no reference to `patchset` anywhere.
108
109Scoped as review-and-triage, not submission:
110
111- ~~Patchset list per mailing list~~ — see the caveat below.
112- ~~Patchset detail~~: cover letter, per-patch diffs (via the existing
113  `DiffView`), checks, and the version / superseded-by chain.
114- ~~Status transitions via `updatePatchset`~~.
115
116Two schema facts shaped the result, and are worth knowing before extending this:
117
118- **`MailingList` has no `patchsets` field.** A list's patchsets cannot be
119  queried directly; they are reachable only through thread roots. The existing
120  threads query now also selects `root.patchset`, so the Patches tab costs no
121  extra request — but it also means patchsets cannot be filtered by status
122  server-side, and only patchsets whose thread appears in the current page are
123  listed.
124- **`Patch` carries no diff.** It has only `index`, `count`, `version`,
125  `prefix`, `subject`, and `trailers`. The diff exists solely inside the email
126  body, so it is recovered with `InboxThreadUtilities.segmentMessageBody` — the
127  same splitter the inbox thread view uses.
128
129Patch *submission* remains out of reach: it is a `git send-email` flow, not a
130GraphQL mutation. Treat that boundary as explicit rather than half-building it.
131
132## Phase 3: Polish and reach
133
134Unlike Phases 1 and 2, this is not one shippable thing. It is several, and they
135are sized very differently — measure before committing to one.
136
137### Release plan
138
139Hutch is an app with a `MARKETING_VERSION`, not a library with an API contract,
140so "breaking change" does not apply. These buckets track *user-visible scale*.
141
142| Version | Contents | Why here |
143| --- | --- | --- |
144| v3.8.1 | SonarCloud triage; housekeeping | No behaviour change at all |
145| v3.9.0 | "What's cooking" ingest; doc truth-up; deploy keys | Ships one feature, corrects the map |
146| v3.10.0 | hub.sr.ht writes: projects, discovery, `mailingListSubscribe` | Provisional — gated on what v3.9.0 finds |
147| v3.11.0 | Accessibility | Independent, device-verified |
148| v4.0.0 | Localization *with* translations | The only true re-presentation |
149| — | Swift 6 language mode; cache reads | Internal; ride along, no tag |
150
151Ordering is by dependency, not size. v3.9.0 leads because it is the only item
152that corrects the others' inputs: the ingest's real output is a `SCOPE.md` that
153is true, and v3.10.0 rests entirely on one unverified sentence in a blog post.
154Do not commit v3.10.0's number until the SDL has been read — the bucket may turn
155out to be empty, which is the point of sequencing it second.
156
157`KeychainHelper` is deliberately unbucketed; see the SonarCloud hotspots below.
158
159### API features — done (v3.8.0)
160
161- ~~`uploadArtifact` / `deleteArtifact`~~ — artifacts were read-only.
162- ~~`auditLog` (meta.sr.ht)~~ — surfaced under the tokens in Profile.
163- ~~Mailing list creation and settings~~ (`createMailingList`,
164  `updateMailingList`, `deleteMailingList`).
165
166Three of the six planned. The other three did not survive contact:
167
168- `archiveMessage` is `@internal` and inaccessible.
169- The `events` feed was built, then removed: todo.sr.ht's root `events` resolver
170  joins `event.participant_id` against `participant.user_id`, which are
171  different id spaces, so it returns an empty list for everyone. See
172  [SCOPE.md](SCOPE.md).
173- Webhook management, `shareSecret`, and build groups are reachable but declined
174  on judgement — see [SCOPE.md](SCOPE.md) for the reasoning, so they do not get
175  re-proposed.
176
177### Localization — v4.0.0, and only with translations
178
179The project sets `LOCALIZATION_PREFERS_STRING_CATALOGS = YES` but ships no
180string catalog, so every user-facing string is hardcoded English. Roughly 634
181literals: 239 `Text(`, 150 `Label(`, 117 `Button(`, 77 `Section(`, 51
182`navigationTitle(`.
183
184Worth knowing before starting: a catalog containing only English changes nothing
185for users until translations exist. It is groundwork, and it is the largest diff
186in the roadmap — it touches nearly every view, with the regression risk that
187implies.
188
189That combination is why this is bucketed at v4.0.0 *bundled with at least one
190real translation*, rather than shipped alone. An English-only catalog would earn
191the major number on regression risk while delivering nothing — the wrong trade.
192Hold the catalog until a translation lands. If it ever ships unbundled, it is
193groundwork and belongs in a quiet minor, not a 4.0.
194
195### Accessibility — v3.11.0
196
197Labels and hints appear in 17 of 89 view files. Mechanical and low-risk, but it
198cannot be verified from a build — it needs VoiceOver driven on a device.
199Independent of every other bucket, so it can move if a device pass is convenient.
200
201### SonarCloud backlog — done in code (v3.8.1)
202
203The live count is **53 issues / 10 rules**, not the 51 / 5 an earlier pass
204recorded — a reminder that this section rots like everything else, so query the
205API before budgeting. **0 bugs, 0 vulnerabilities**; everything is a code smell
206or hotspot. What the code side of v3.8.1 actually did:
207
208Fixed (`e93972f`):
209
210- **`swift:S1871`** — `RootView` had byte-identical `.home` / `.recentActivity`
211  deep-link cases. Merged; recent activity is a *section* of Home, not a screen,
212  so both correctly land on the Home tab.
213- **3× `swift:S1186` (empty closure/function, CRITICAL)** — two are
214  `Button("Cancel", role: .cancel) {}` (dialog dismissal needs no body); the
215  third is an empty `URLProtocol.stopLoading()` override in a test. All three now
216  carry a nested comment. Note the earlier claim that "all three are Cancel
217  buttons" was wrong — only two are.
218- **`swift:S108`** — the expected-miss `catch` in `APICacheTests` is commented.
219- **`swift:S1172`** — the unused `url` in `mimeType(for:)` is now `_`.
220- **2× `javascript:S4624`** — the nested template literal in the deep-link
221  builders (`background.js`, `content.js`) is extracted to a `pathSegment` var.
222
223Fixed as a real bug instead (`65412ee`), not silenced:
224
225- **2× `swift:S1172` on `forceRefresh`** — `HomeViewModel.loadProjects` and
226  `loadSystemStatusSnapshot` took the flag and dropped it, so dashboard
227  pull-to-refresh returned cached projects and status. This is the trap named at
228  the top of this file. `ProjectsListView` carried the same defect via its own
229  `.refreshable`. Both fixed at the root in `ProjectService.fetchProjects`.
230
231Won't Fix, with reasons (resolve in SonarCloud's web UI, not in code):
232
233- **35× `swift:S1075` (hardcoded URI)** — 28 in `SourceHutWebDeepLinkMapperTests`,
234  the rest in `HutchDeepLinkURLs`. A deep-link mapper's tests exist to assert
235  literal URLs, and a one-forge client has fixed endpoints. "Fixing" them makes
236  the code worse.
237- **`swift:S107`** — `executeCached` has 8 params across **38 call sites**. A
238  param object would rewrite the hottest networking method for no behaviour or
239  correctness gain against an arbitrary 7-param line. Not worth the regression
240  surface.
241- **`swift:S1481`** — `ArtifactsView`'s `@Bindable var vm` is flagged unused, but
242  `$vm.error` is used at line 134; Sonar's Swift analyzer misses the projected
243  value. False positive — removing it breaks the build.
244- **`javascript:S7785`** — prefers top-level `await` for `injectBannerIfEnabled()`,
245  but `content.js` is a classic content script, not a module. Top-level `await`
246  would be a syntax error. Not applicable.
247- **5× `swift:S1135`** — TODO comments (INFO). The two in `HutchIntents` named
248  real gaps and are now promoted to "App Intent gaps" below, with the inline
249  `TODO`s replaced by plain references — so those two clear. The remaining three
250  (`DeepLink`, `NotificationPreferencesViewModel` ×2) stay until addressed.
251
252The 3 hotspots are the part actually worth thought:
253
254- `KeychainHelper:33` and `:80` (**HIGH**) — the token is stored
255  `kSecAttrAccessibleWhenUnlockedThisDeviceOnly` with no
256  `SecAccessControl`, so it does not require biometric or passcode
257  authentication to read. That is a genuine product decision — should a stolen,
258  unlocked phone hand over a sr.ht token? — not a lint nit. **Unbucketed on
259  purpose:** adding `SecAccessControl` changes what a user must do to read their
260  own token, so it needs a decision first. If the answer is yes, it is a minor
261  bump of its own — a visible auth change should not hide inside a feature
262  release.
263- `ReadmeView:1922` (**LOW**) — unrestricted WebView navigation. Probably a false
264  positive: `isAllowedReadmeNavigationURL` enforces a scheme allowlist. Verify,
265  then annotate.
266
267Query it with:
268`https://sonarcloud.io/api/issues/search?componentKeys=zerolabsco_hutch&resolved=false`
269
270This was scoped as a patch on the assumption nothing executes differently — and
271that mostly held: the cosmetic fixes are comments, a merge, and a rename. The one
272exception earns the release its own line: the `forceRefresh` fix changes what
273pull-to-refresh does, so it needs a manual pass on a device before v3.8.1 ships,
274not just a green suite.
275
276### Ingest "What's cooking on SourceHut?" — v3.9.0
277
278sr.ht posts a quarterly update to `~sircmpwn/sr.ht-announce`, mirrored at
279<https://sourcehut.org/blog/>. Nothing in Hutch tracks it, so the API grows and
280this repo's assumptions quietly rot. Read each quarter's post, diff it against
281`Docs/API`, `SCOPE.md`, and the call sites, and file what changed.
282
283That this is worth doing is already proven: **`SCOPE.md` claims pronouns are
284"not in GraphQL schema", while `AppState` queries `pronouns` and
285`UserProfileView` displays them.** sr.ht shipped it, the doc never caught up,
286and it has been discouraging work that is in fact already done.
287
288[Q2 2026](https://sourcehut.org/blog/2026-05-28-whats-cooking-q2-2026/) alone
289flags two openings:
290
291- **hub.sr.ht gained a writable GraphQL API** for managing projects and project
292  resources. Hutch's projects are read-only, and `SCOPE.md` still rules out
293  discovery on the grounds that hub has no public API. Both claims need
294  rechecking — this may also unblock `mailingListSubscribe`, which Phase 1 left
295  out for exactly that reason.
296- **git.sr.ht deploy keys are complete** (`createDeployKey` / `deleteDeployKey`
297  are in the SDL). Hutch never calls them.
298
299Start from Q1 2026 forward — that is roughly when the current `Docs/API` dumps
300were captured.
301
302Research does not ship, so v3.9.0 pairs the ingest with **deploy keys** — the one
303self-contained feature it has already surfaced and that the SDL confirms exists.
304That gives the release something a user can see. Everything else the ingest turns
305up gets filed, not built, and hub.sr.ht gets its own bucket below.
306
307### hub.sr.ht writes — v3.10.0, provisional
308
309Everything here rests on a single sentence in the Q2 2026 post: that hub.sr.ht
310gained a writable GraphQL API. If true, three things unblock at once —
311project writes (Hutch's projects are read-only), discovery (which `SCOPE.md`
312rules out on the grounds hub has no public API), and `mailingListSubscribe`,
313which Phase 1 declined for exactly that reason.
314
315All three live or die on the same unverified claim, which is why this is
316sequenced after the ingest rather than planned now. Read
317`api/graph/schema.graphqls` in `hub.sr.ht` before committing the version number.
318The bucket may be empty.
319
320### App Intent gaps — unscheduled
321
322Two App Intents in `HutchIntents.swift` are placeholders for features Hutch does
323not have yet. Both are gated on the same missing capability — a global
324search/persistence layer — so neither is schedulable until that lands. (These
325were the two `swift:S1135` TODOs; promoted here so the code carries a reference
326rather than a bare `TODO`.)
327
328- **Global content search.** `SearchHutchIntent` accepts a query but routes to
329  the Lookup screen — sourcehut entity resolution — because Hutch has no
330  full-text search across tickets, repos, and lists. Its own description says
331  "Opens Hutch lookup with a search query." When a real search exists, repoint
332  the `.search` route in `SearchHutchIntent.route`.
333- **`OpenSavedSearchIntent`.** Saved searches are per-tracker only
334  (`TicketSavedFilterStore`, `ScopedSearchHistoryStore`); there is no global
335  saved-search store for an intent to open. Add the intent once global
336  saved-search persistence exists.
337
338### Swift 6 language mode — no release of its own
339
340The project builds in Swift 5 language mode with
341`SWIFT_DEFAULT_ACTOR_ISOLATION = MainActor`. Moving to Swift 6 is blocked on
342concurrency diagnostics that are warnings today and errors there:
343
344- `APICacheTests` and `BundleUserAgentTests` call main-actor-isolated
345  initialisers and properties from nonisolated contexts, and `await` a few
346  expressions without marking them. Roughly 20 warnings, all in tests.
347- Response types are implicitly `@MainActor` under the default isolation, so
348  their `Decodable` conformances are too. Decoding one from a nonisolated
349  context — an `async let` over a raw `client.execute`, say — warns now and
350  fails then. The pattern that avoids it is `async let` over `@MainActor`
351  methods, as in `HomeViewModel.loadDashboard` and
352  `NotificationPreferencesViewModel.load`.
353
354### Cache reads that bypass the client — no release of its own
355
356`BuildListViewModel`, `RepositoryListViewModel`, and `PasteService` still read
357`client.responseCache` directly, each falling back across two different cache
358keys. That predates `APICacheKeys` and should be folded into `cachedPayload`,
359which already consults the persistent cache before the memory layer.
360
361Like Swift 6 above, this is internal and rides along with whatever release
362already touches that area. Neither justifies a tag.
363
364## Housekeeping
365
366- ~~`Hutch/Hutch/App/AccountSession.swift` sits in a stray nested directory;
367  `Hutch/HutchTests/` is empty.~~ Done (v3.8.1, `9834b78`). Moved beside the rest
368  of `App/`; both stray dirs removed. No pbxproj change — the target is a
369  synchronized root group, so the file compiled by path all along.