The previous run's app job waited for a macOS runner and was cancelled before it started. Its core library and backend builds are reused.
[claude-test:ios] [ci-backend]
That menu opens over the server address's QR code, where OCR can miss its "yes" (run 39242250150 failed its setup three times on it), so the smoke test finds the menu's first item, which repeats the field's value and reads well, and clicks the row under it. The check that the role is now yes stays.
[claude-test:desktop] [ci-backend]
After the merge of master, compiling :common:compileKotlinDesktop failed with "Not enough memory to run compilation" (run 39237291485): the Kotlin compiler daemon takes gradle.properties' 2 GB heap. The app job's two Gradle calls pass kotlin.daemon.jvmargs=-Xmx4g; the runner has 15 GB. gradle.properties, which the app builds use, is unchanged.
[claude-test:desktop] [ci-backend]
Starts the scripted test and the Claude sessions on iOS with the backend, for the merge of master and the review fixes. Desktop's run of 8a9628bd9 covers its side.
[claude-test:ios] [ci-backend]
The artifact carrying the app job's stopped test backend to the Claude job holds its databases and server keys, which anyone signed in to GitHub can download for the day it is kept. The READMEs now say so, what someone could do with it, and why encrypting it isn't possible under the Claude job's one-secret rule.
Review R1-1, run 008-dirsearch-known-chats
[app-ci:ios] [ci-backend]
Master moved code in files the iOS and Kotlin specs link to by line (Kotlin ChatListView.kt by 29 lines and others); two references from this run's slices also had a stale line column or link text.
Review R1-3, run 008-dirsearch-known-chats
It drew by hand what ChatInfoImage draws for a group (its image, or the group's icon), which the Kotlin row uses too.
Review R1-2, run 008-dirsearch-known-chats
The app is built in the app job with that job's backend's directory address in DIRECTORY_SERVICE_LINK, and since master moved Claude into its own job, that job started a new backend with another address. The app job now uploads its stopped backend's work dir (without the binaries), and the Claude job restarts it with a new backend.sh resume: the same servers' keys and databases, so the same addresses. The relay, directory, names server and contacts start through the functions start uses, split out of it. The iOS Claude job's smoke test also gets BACKEND_DIR, as the app job's does.
[claude-test] [ci-backend]
Master changed ProfileImage's iconName: String to icon: Image (#7767's merge brought it in). The Directory and Names rows and New chat's group row still passed iconName, which no longer compiles; they pass Image(systemName:) as master's own callers do.
After joining ci_channel, the scripted search case checks in both layouts that searching its name shows the note "All results on this page are already in your chats" and no Directory row, and that a search the local list doesn't match shows ci_channel as a chat row that opens it, not "#ci_channel" with "Join channel"; New chat shows it as a contact-style row. The Claude search test's part C expects the same.
Run: 008-dirsearch-known-chats, slice 5
[claude-test] [ci-backend]
After joining ci_cards, the smoke test expects the note "All results on this page are already in your chats" for its name, and, in both layouts and in New chat, that a search the local list doesn't match shows ci_cards as its chat row, which opens the channel, not "#ci_cards" with "Join channel". The plan gets U4 and W12 and the new U2, the prompt describes known entries and the note, and the Claude scope runs the changed cases (Haiku 5.5, 300 turns, 3 USD).
Run: 008-dirsearch-known-chats, slice 4
As on iOS: a directory result whose link resolves to a chat the screen doesn't list is drawn with that screen's chat row, which opens it, instead of "Join group" / "Join channel": ChatListNavLinkView in the chat list, ContactListNavLinkView (now with a group branch) in New chat. When every result of the last page is a chat already shown, the Directory part says "All results on this page are already in your chats" above "Show more".
Run: 008-dirsearch-known-chats, slice 3
A directory result whose link resolves to a chat the screen doesn't list is drawn with that screen's chat row, which opens it, instead of "Join group" / "Join channel": the chat list's row there, a contact-style row in New chat (ContactListNavLink gets a group case). When every result of the last page is a chat already shown, the Directory part says "All results on this page are already in your chats" above "Show more", instead of showing the header and "Show more" alone.
Run: 008-dirsearch-known-chats, slice 2
The Directory part will draw known chats with the chat list's own row, so its two modifier chains (iOS 16+, iOS 15) move unchanged into chatListNavLink(_:), and the list's two ForEach branches become one. The iOS 16 offset moves from the ForEach to each row, which SwiftUI applies the same way.
Run: 008-dirsearch-known-chats, slice 1
Desktop always lists the chat open in the right pane, so with ci_channel open its Directory row was rightly hidden and step C.3 had nothing to click (run 39001925386). Also runs the iOS names session again: that run's backend stopped when the directory could not connect to a channel's link.
[claude-test] [ci-backend]
One-hand: the names setup, N1-N11, the New chat cases with names and the full search in both lists, checking that a row opened from goes away; N11 uses #cinews_weekly so the top bar's N1 still finds cinews unopened. Top bar: N1, N4 and the full search on the chat list.
[claude-test] [ci-backend]
A session found no role pickers on the names server it added, so no name resolved and the names cases were blocked (run 38993332306); a later session added the server twice.
The same change as on iOS: the rows without a local chat look it up again when a connection started from one ends, so a group or channel opened from its row is no longer listed twice until the next search.
A result's local chat was looked up only when the search ran, so a group or channel opened from its row stayed listed twice, as the chat and as the row, until the next search (a test run joined cinews_digest from the Directory part and saw both). The rows without a chat look it up again when a connection started from one ends.
ci_channel's description matches "seed", so the list showed it and the step's premise was wrong; a name narrows the list instead. Desktop keeps the open chat in the filtered list, so "No chats found" can't be required while a chat is open (run 38994540038).
Part C joins a channel from its Directory row, then checks that the joined chat is not listed again by the directory when the local list shows it, that it is when the list doesn't, the empty result, an unregistered name, and that only the Search key resolves names. The session gets 120 turns for it.
[claude-test:desktop] [ci-backend]
One-hand: the names setup, N1-N11, the New chat cases with names, the full search in both lists, G3 again, and whether a row stays next to the chat opened from it; top bar: N1, N4 and the full search on the chat list.
[claude-test:ios] [ci-backend]
D15 said the search bar is above the onboarding pages, which holds only with the top bar; W4 assumed a contact matches. A session tapped the pencil for G3 after the held search had already failed (app log), so the prompt asks for the action as the next command.
One-hand: the chat list, directory results, de-duplication, New chat and regression cases; top bar: the cases this layout draws differently. The names cases run in a separate session.
[claude-test] [ci-backend]
With the test backend, the Claude job builds the app against the test directory, sets it up at the chat list and gives Claude the online search test; without it, the onboarding path stays.
With the test backend, the app is built against the test directory's address, and the smoke test runs a new search case: after the backend case's checks, in both layouts, "Search in Directory" and the full search with a SimpleX name, and with the toolbar at the bottom the full search in the New chat sheet.
A fresh client sends the directory the search the app sends and follows the cursor to the last page: each result must arrive once with its whole image, over at least two pages. The message search stays.
The Claude sessions run the online search plan again: the cases, what each session covers per layout, the prompt's directory search, names and report sections, and the session's start state after the smoke test's searches.
With the test backend, the app is built against the test directory's address, and the smoke test goes on to search it: the Directory header above the results and their avatars in both layouts, the chat list's cards shown while typing and hidden under the results once the profile has a conversation, and "Show more" disabled while its page loads.
A fresh client sends the directory the search the app sends, and must find ci_group and ci_channel; then "ci seed" and "ci avatar" are followed page by page into seed.md, with each page's entries and size against maxServiceBodyLength. The message search stays. The seeded entries name the cases they serve again.
The branch name was part of the jq program text, so a branch named to close the string could select an artifact from a fork or another branch. Same fix as the desktop lookup.
A client started with -s gives that server every role, names included, only to the users that exist when it starts, so the name probe's first connect plan on a new database failed with NO_NAME_SERVERS (run 38904976359). The user is now created by a plain run first, as every other peer is and as desktop's backend does.
