eleven / ocho Public

ios+mac: a Threads list — every thread in this chat, freshest first (#1494)

* core: every thread in a chat, derived once and pinned by a vector

Paul: "there's no way to see a list of threads — it's hard to find a thread
if I miss clicking the notification." The web grew a ▤ Threads list for
that (#1491); this is the shared half the native apps build theirs on.

ChatFeedModel.threadListItems(_:) is the Swift twin of chat.js's
threadListItems: one row per thread ROOT, membership through
threadRootID(of:) — the same read the "N Replies" tally makes, so a row's
count and its root's tally can never disagree — ordered by each thread's
LAST message, because the list answers "where is the conversation", not
"which root is newest". A thread whose root has scrolled out of the loaded
window keeps its row, headed by the snapshot its flagged replies carry;
a converted chain, whose replies quote something that isn't the root, is
headed by nothing rather than by the wrong message.

The ordering comparator both threadItems and threadListItems needed is now
one function (feedPrecedes) instead of two copies of the same rule, so a
thread's rows and the list's order can't drift apart.

The list re-derives in `messages`'s didSet as `threadListRows`, assigned
only when it actually changed — the native form of the web's
threadListSignature repaint gate, and what lets the containers ask "does
this chat have a thread?" without walking the window per menu.

Vectors, not parallel hand-written tests: nine sequence vectors in
test/event-vectors/chat.json gain expected_thread_list, and both suites
read it — the web's in test/event-vectors.test.mjs, Swift's in
ReplyThreadVectorTests. They cover the empty case (an inline quote chain
lists nothing), the unloaded root, every conversion shape, and the
ordering rule: convert_conflicting_claims_oldest_wins puts the OLDER
root's row first, because its thread holds the newer message.

NO unread dot, deliberately — the same call the web made. Read state here
is per CHAT and nothing else, and opening a chat advances that watermark
past every thread reply in it, so a dot derived from it would read "all
caught up" the instant you glanced at the chat — the very lie this list
exists to fix.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EXy6kzmYE9rChy3KgciJvZ
🤖 Generated with [Claude Code](https://claude.com/claude-code)

* ios: a Threads row in the chat kebab, opening this chat's threads

The list itself is ReplyThreadListView in LChatCore, shared with the Mac so
the rows, their wording and their accessible names are the same on both —
author, the line you recognise the thread by, and its tally through
replyCountLabel, the one string a thread's size is ever written in (so a
row, the root's bubble and the thread header always agree, pluralised and
locale-grouped). A converted chain whose root has paged out says "The
original message isn't available" rather than showing a blank line, which
is what the thread view says in exactly that case.

Where it goes: the chat's ⋯ kebab, under the Chat/Interface pickers and
above the management verbs — a view switch belongs with the view switches
(and the project's rule is kebab rows, never bar tabs). The row is there
exactly while the chat HAS a thread, so a chat where nobody has used
"Reply in thread" is untouched, and one someone else starts mid-conversation
surfaces the row without a reload.

A sheet, not a dock: the iPhone has no room for a second column, and a
tapped row opens the thread where a tally tap does — the docked pane on
iPad, the lifted overlay on iPhone — so the list is the transient index you
come out of, the same shape Media, Links & Docs has.

Accessibility: rows are buttons named for what they DO ("Open thread,
4 Replies, James: …") with both visible strings carried through verbatim,
so voice control still matches the words on screen; ≥34pt targets that fill
on press; and at the accessibility type sizes the tally moves under the
line rather than being squeezed off it.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EXy6kzmYE9rChy3KgciJvZ
🤖 Generated with [Claude Code](https://claude.com/claude-code)

* mac: the Threads list borrows the thread pane's dock

Same list, same shared view (ReplyThreadListView), as a flush 340pt right
column — the same slot the docked thread pane uses, because there is only
one right dock and the two are never both up. Opening a thread from a row
therefore hands the dock straight to that thread, which is what you came
for anyway.

Where it goes: the header's ⋯ kebab, first, above the management verbs —
the Mac has no ▤ Views menu, so this is where a "views" section starts.
Memory and the bot views the web already lists have a home there when they
land natively. The row observes the chat's own model, so it appears with
the chat's first thread and goes with its last.

The list only BORROWS the dock. A thread open behind it keeps its
half-typed reply, its staged files and its in-flight edit — that state
lives on the feed view, not on the pane — so closing the list hands the
pane back with the caret where the reader left it. (The web's panel evicts
the thread outright, because its pane composer dies with the DOM node; we
don't have to.)

The header is painted a view up from the dock, so the row's request crosses
on MacAppState the way a search hit's jump does: one-shot, consumed by the
feed it names, since every visited space stays mounted.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EXy6kzmYE9rChy3KgciJvZ
🤖 Generated with [Claude Code](https://claude.com/claude-code)

* docs: the Threads list's icon, and where it isn't drawn

Both new kebab rows go in the mapping table, with the platform split spelled
out: the web's ▤ menu and the iOS ⋯ menu draw ICON_THREAD /
bubble.left.and.bubble.right, while the Mac header kebab is text-only rows
by construction — the same reason "Convert to thread" maps nowhere there.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EXy6kzmYE9rChy3KgciJvZ
🤖 Generated with [Claude Code](https://claude.com/claude-code)

* mac+core: closing the list never leaves the caret nowhere

Two small follow-ons to the slice:

closeThreadList hands focus back explicitly — to the thread pane's composer
when a thread was open behind the list (where the reader left it), else to
the channel bar. Both gated on the pane being on screen, the same isActive
guard every focus claim in this file wears: every visited space stays
mounted, and a parked one must never take first responder from the visible
one.

And the row's tally takes its width before the line does, so a long snippet
truncates rather than squeezing the number off the row — the line already
expands to fill, so the spacer between them was doing nothing.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EXy6kzmYE9rChy3KgciJvZ
🤖 Generated with [Claude Code](https://claude.com/claude-code)

* mac: the list lays OVER the pane, owns the caret, and can't strand its request

Review of the slice turned up five real faults, all here:

**The request could go permanently dead.** The chat header is drawn in
states where NativeFeedView is NOT mounted — a group in Interface mode,
every app thread's pane — so a Threads click there had no consumer, and
because the channel carried a bare chat id, the NEXT click wrote the same
value, onChange saw no change, and the row was inert for that chat for the
rest of the session. The channel now carries a tick (so a repeat is always a
change) and, like consumeJump, drains on appear too — a click made while the
conversation was hidden opens the list when it comes back, rather than being
swallowed.

**Covering the pane by replacing it lost the draft's formatting.** The slice
claimed an open thread keeps its half-typed reply while you look something
up, and that was only half true: paneDraft/paneStaged live on this view, but
the composer's bold/italic runs, caret and undo stack live in its own text
storage, which dies with the unmounted view — the reply would come back
plain, caret at the end. So the list now lays OVER the pane instead of
replacing it, and the covered pane leaves the accessibility tree.

**The list had no focus, so Escape was dead.** Opened over a thread, focus
fell to the window; opened over the channel, the composer's own Escape
(cancel reply) won. It's now the focus owner while it's up, so .onExitCommand
lands where the reader expects, and the covered composer can't keep first
responder underneath.

**A row for the already-open thread returned the dock without the caret** —
openThread's same-root guard left before the focus restore.

**And a stray Sparkle pin** had crept into LChatCore's Package.resolved,
which declares no such dependency.

Also: the web-side vector assertion for the repaint gate was tautological
(it compared a signature with a shallow copy of itself, which can never
differ). It now moves `last`, which the row never shows, and asserts NO
repaint; then moves count/name/snippet and asserts one. And the divergence
that exposed — the web's signature omits rootLoaded, which the row does show
— is written down beside ThreadListRow as the web-side follow-up it is; this
change stays scoped to native.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EXy6kzmYE9rChy3KgciJvZ
🤖 Generated with [Claude Code](https://claude.com/claude-code)

* mac: one right column, and no ring around the threads list

Two things Paul caught testing the list on the Mac.

The 340pt column is focusable so Escape reaches it rather than the
composer it covers — but focusable() also asks macOS to ring it, and it
outlined the whole column in blue. An index is not a control: the ring
belongs on the rows, which are real buttons and keep theirs, so the
container's is disabled.

And the list and the thread pane were separate branches of the layout,
so opening a thread from a row removed one column and inserted another
— between them the feed reflowed out to full width and back, which read
as the pane shrinking and restoring under the animation. They are one
container now, holding whichever is up: the column never leaves, only
its contents cross-fade.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EXy6kzmYE9rChy3KgciJvZ

* mac: a thread opening into a standing column is a cross-fade, not a mount

Paul's repro was exact: the shrink only happened opening a thread from
the list when NO pane was there yet, and again after closing and
reopening one — never when switching threads with the pane already up.
That difference is the pane's first mount.

Inserted inside a withAnimation, SwiftUI animates the new subtree's own
geometry — the composer measuring its field, the scroll view taking its
size — so the pane grew into place instead of simply appearing. Two
changes: both children of the column carry an explicit .opacity
transition, so a swap is a fade and never interpolates size; and the
root is set WITHOUT animation when the column is already standing,
since the fade is the whole transition there. The column arriving from
nothing still animates, which is the one case that should.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EXy6kzmYE9rChy3KgciJvZ

---------

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>