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.8.2 | Home system status moved to a title-bar status badge | Small UI relocation, no new surface |
146| v3.9.0 | "What's cooking" ingest; doc truth-up; deploy keys | Ships one feature, corrects the map |
147| v3.10.0 | hub.sr.ht writes: projects, discovery, `mailingListSubscribe` | Provisional — gated on what v3.9.0 finds |
148| v3.11.0 | Accessibility | Independent, device-verified |
149| v4.0.0 | Localization *with* translations | The only true re-presentation |
150| — | Swift 6 language mode; cache reads | Internal; ride along, no tag |
151
152Ordering is by dependency, not size. v3.9.0 leads because it is the only item
153that corrects the others' inputs: the ingest's real output is a `SCOPE.md` that
154is true, and v3.10.0 rests entirely on one unverified sentence in a blog post.
155Do not commit v3.10.0's number until the SDL has been read — the bucket may turn
156out to be empty, which is the point of sequencing it second.
157
158`KeychainHelper` is deliberately unbucketed; see the SonarCloud hotspots below.
159
160### API features — done (v3.8.0)
161
162- ~~`uploadArtifact` / `deleteArtifact`~~ — artifacts were read-only.
163- ~~`auditLog` (meta.sr.ht)~~ — surfaced under the tokens in Profile.
164- ~~Mailing list creation and settings~~ (`createMailingList`,
165  `updateMailingList`, `deleteMailingList`).
166
167Three of the six planned. The other three did not survive contact:
168
169- `archiveMessage` is `@internal` and inaccessible.
170- The `events` feed was built, then removed: todo.sr.ht's root `events` resolver
171  joins `event.participant_id` against `participant.user_id`, which are
172  different id spaces, so it returns an empty list for everyone. See
173  [SCOPE.md](SCOPE.md).
174- Webhook management, `shareSecret`, and build groups are reachable but declined
175  on judgement — see [SCOPE.md](SCOPE.md) for the reasoning, so they do not get
176  re-proposed.
177
178### Localization — v4.0.0, and only with translations
179
180The project sets `LOCALIZATION_PREFERS_STRING_CATALOGS = YES` but ships no
181string catalog, so every user-facing string is hardcoded English. Roughly 634
182literals: 239 `Text(`, 150 `Label(`, 117 `Button(`, 77 `Section(`, 51
183`navigationTitle(`.
184
185Worth knowing before starting: a catalog containing only English changes nothing
186for users until translations exist. It is groundwork, and it is the largest diff
187in the roadmap — it touches nearly every view, with the regression risk that
188implies.
189
190That combination is why this is bucketed at v4.0.0 *bundled with at least one
191real translation*, rather than shipped alone. An English-only catalog would earn
192the major number on regression risk while delivering nothing — the wrong trade.
193Hold the catalog until a translation lands. If it ever ships unbundled, it is
194groundwork and belongs in a quiet minor, not a 4.0.
195
196### Accessibility — v3.11.0
197
198Labels and hints appear in 17 of 89 view files. Mechanical and low-risk, but it
199cannot be verified from a build — it needs VoiceOver driven on a device.
200Independent of every other bucket, so it can move if a device pass is convenient.
201
202### SonarCloud backlog — done in code (v3.8.1)
203
204The live count is **53 issues / 10 rules**, not the 51 / 5 an earlier pass
205recorded — a reminder that this section rots like everything else, so query the
206API before budgeting. **0 bugs, 0 vulnerabilities**; everything is a code smell
207or hotspot. What the code side of v3.8.1 actually did:
208
209Fixed (`e93972f`):
210
211- **`swift:S1871`** — `RootView` had byte-identical `.home` / `.recentActivity`
212  deep-link cases. Merged; recent activity is a *section* of Home, not a screen,
213  so both correctly land on the Home tab.
214- **3× `swift:S1186` (empty closure/function, CRITICAL)** — two are
215  `Button("Cancel", role: .cancel) {}` (dialog dismissal needs no body); the
216  third is an empty `URLProtocol.stopLoading()` override in a test. All three now
217  carry a nested comment. Note the earlier claim that "all three are Cancel
218  buttons" was wrong — only two are.
219- **`swift:S108`** — the expected-miss `catch` in `APICacheTests` is commented.
220- **`swift:S1172`** — the unused `url` in `mimeType(for:)` is now `_`.
221- **2× `javascript:S4624`** — the nested template literal in the deep-link
222  builders (`background.js`, `content.js`) is extracted to a `pathSegment` var.
223
224Fixed as a real bug instead (`65412ee`), not silenced:
225
226- **2× `swift:S1172` on `forceRefresh`** — `HomeViewModel.loadProjects` and
227  `loadSystemStatusSnapshot` took the flag and dropped it, so dashboard
228  pull-to-refresh returned cached projects and status. This is the trap named at
229  the top of this file. `ProjectsListView` carried the same defect via its own
230  `.refreshable`. Both fixed at the root in `ProjectService.fetchProjects`.
231
232Won't Fix, with reasons (resolve in SonarCloud's web UI, not in code):
233
234- **35× `swift:S1075` (hardcoded URI)** — 28 in `SourceHutWebDeepLinkMapperTests`,
235  the rest in `HutchDeepLinkURLs`. A deep-link mapper's tests exist to assert
236  literal URLs, and a one-forge client has fixed endpoints. "Fixing" them makes
237  the code worse.
238- **`swift:S107`** — `executeCached` has 8 params across **38 call sites**. A
239  param object would rewrite the hottest networking method for no behaviour or
240  correctness gain against an arbitrary 7-param line. Not worth the regression
241  surface.
242- **`swift:S1481`** — `ArtifactsView`'s `@Bindable var vm` is flagged unused, but
243  `$vm.error` is used at line 134; Sonar's Swift analyzer misses the projected
244  value. False positive — removing it breaks the build.
245- **`javascript:S7785`** — prefers top-level `await` for `injectBannerIfEnabled()`,
246  but `content.js` is a classic content script, not a module. Top-level `await`
247  would be a syntax error. Not applicable.
248- **5× `swift:S1135`** — TODO comments (INFO). The two in `HutchIntents` named
249  real gaps and are now promoted to "App Intent gaps" below, with the inline
250  `TODO`s replaced by plain references — so those two clear. The remaining three
251  (`DeepLink`, `NotificationPreferencesViewModel` ×2) stay until addressed.
252
253The 3 hotspots are the part actually worth thought:
254
255- `KeychainHelper:33` and `:80` (**HIGH**) — the token is stored
256  `kSecAttrAccessibleWhenUnlockedThisDeviceOnly` with no
257  `SecAccessControl`, so it does not require biometric or passcode
258  authentication to read. That is a genuine product decision — should a stolen,
259  unlocked phone hand over a sr.ht token? — not a lint nit. **Unbucketed on
260  purpose:** adding `SecAccessControl` changes what a user must do to read their
261  own token, so it needs a decision first. If the answer is yes, it is a minor
262  bump of its own — a visible auth change should not hide inside a feature
263  release.
264- `ReadmeView:1922` (**LOW**) — unrestricted WebView navigation. Probably a false
265  positive: `isAllowedReadmeNavigationURL` enforces a scheme allowlist. Verify,
266  then annotate.
267
268Query it with:
269`https://sonarcloud.io/api/issues/search?componentKeys=zerolabsco_hutch&resolved=false`
270
271This was scoped as a patch on the assumption nothing executes differently — and
272that mostly held: the cosmetic fixes are comments, a merge, and a rename. The one
273exception earns the release its own line: the `forceRefresh` fix changes what
274pull-to-refresh does, so it needs a manual pass on a device before v3.8.1 ships,
275not just a green suite.
276
277### Ingest "What's cooking on SourceHut?" — v3.9.0
278
279sr.ht posts a quarterly update to `~sircmpwn/sr.ht-announce`, mirrored at
280<https://sourcehut.org/blog/>. Nothing in Hutch tracks it, so the API grows and
281this repo's assumptions quietly rot. Read each quarter's post, diff it against
282`Docs/API`, `SCOPE.md`, and the call sites, and file what changed.
283
284That this is worth doing is already proven: **`SCOPE.md` claims pronouns are
285"not in GraphQL schema", while `AppState` queries `pronouns` and
286`UserProfileView` displays them.** sr.ht shipped it, the doc never caught up,
287and it has been discouraging work that is in fact already done.
288
289[Q2 2026](https://sourcehut.org/blog/2026-05-28-whats-cooking-q2-2026/) alone
290flags two openings:
291
292- **hub.sr.ht gained a writable GraphQL API** for managing projects and project
293  resources. Hutch's projects are read-only, and `SCOPE.md` still rules out
294  discovery on the grounds that hub has no public API. Both claims need
295  rechecking — this may also unblock `mailingListSubscribe`, which Phase 1 left
296  out for exactly that reason.
297- **git.sr.ht deploy keys are complete** (`createDeployKey` / `deleteDeployKey`
298  are in the SDL). Hutch never calls them.
299
300Start from Q1 2026 forward — that is roughly when the current `Docs/API` dumps
301were captured.
302
303Research does not ship, so v3.9.0 pairs the ingest with **deploy keys** — the one
304self-contained feature it has already surfaced and that the SDL confirms exists.
305That gives the release something a user can see. Everything else the ingest turns
306up gets filed, not built, and hub.sr.ht gets its own bucket below.
307
308### hub.sr.ht writes — v3.10.0, provisional
309
310Everything here rests on a single sentence in the Q2 2026 post: that hub.sr.ht
311gained a writable GraphQL API. If true, three things unblock at once —
312project writes (Hutch's projects are read-only), discovery (which `SCOPE.md`
313rules out on the grounds hub has no public API), and `mailingListSubscribe`,
314which Phase 1 declined for exactly that reason.
315
316All three live or die on the same unverified claim, which is why this is
317sequenced after the ingest rather than planned now. Read
318`api/graph/schema.graphqls` in `hub.sr.ht` before committing the version number.
319The bucket may be empty.
320
321### App Intent gaps — unscheduled
322
323Two App Intents in `HutchIntents.swift` are placeholders for features Hutch does
324not have yet. Both are gated on the same missing capability — a global
325search/persistence layer — so neither is schedulable until that lands. (These
326were the two `swift:S1135` TODOs; promoted here so the code carries a reference
327rather than a bare `TODO`.)
328
329- **Global content search.** `SearchHutchIntent` accepts a query but routes to
330  the Lookup screen — sourcehut entity resolution — because Hutch has no
331  full-text search across tickets, repos, and lists. Its own description says
332  "Opens Hutch lookup with a search query." When a real search exists, repoint
333  the `.search` route in `SearchHutchIntent.route`.
334- **`OpenSavedSearchIntent`.** Saved searches are per-tracker only
335  (`TicketSavedFilterStore`, `ScopedSearchHistoryStore`); there is no global
336  saved-search store for an intent to open. Add the intent once global
337  saved-search persistence exists.
338
339### Swift 6 language mode — no release of its own
340
341The project builds in Swift 5 language mode with
342`SWIFT_DEFAULT_ACTOR_ISOLATION = MainActor`. Moving to Swift 6 is blocked on
343concurrency diagnostics that are warnings today and errors there:
344
345- `APICacheTests` and `BundleUserAgentTests` call main-actor-isolated
346  initialisers and properties from nonisolated contexts, and `await` a few
347  expressions without marking them. Roughly 20 warnings, all in tests.
348- Response types are implicitly `@MainActor` under the default isolation, so
349  their `Decodable` conformances are too. Decoding one from a nonisolated
350  context — an `async let` over a raw `client.execute`, say — warns now and
351  fails then. The pattern that avoids it is `async let` over `@MainActor`
352  methods, as in `HomeViewModel.loadDashboard` and
353  `NotificationPreferencesViewModel.load`.
354
355### Cache reads that bypass the client — no release of its own
356
357`BuildListViewModel`, `RepositoryListViewModel`, and `PasteService` still read
358`client.responseCache` directly, each falling back across two different cache
359keys. That predates `APICacheKeys` and should be folded into `cachedPayload`,
360which already consults the persistent cache before the memory layer.
361
362Like Swift 6 above, this is internal and rides along with whatever release
363already touches that area. Neither justifies a tag.
364
365## Housekeeping
366
367- ~~`Hutch/Hutch/App/AccountSession.swift` sits in a stray nested directory;
368  `Hutch/HutchTests/` is empty.~~ Done (v3.8.1, `9834b78`). Moved beside the rest
369  of `App/`; both stray dirs removed. No pbxproj change — the target is a
370  synchronized root group, so the file compiled by path all along.