eleven / ocho Public

web+native: Reply and threads are two separate verbs — nothing joins a thread by accident (#1490)

* web: Reply and threads are two separate verbs

Plain Reply and "Reply in thread" now do genuinely different things, and
neither leaks into the other.

`replyTarget` served both, root-resolving EVERY reply — so replying to a
reply silently joined (or invented) a thread nobody had opened. It splits
into two pure, exported, Node-tested helpers:

- `quoteTarget(m)` — the exact message clicked, no walk, no flag. Plain
  Reply everywhere (hover strip, picker, sheet, swipe, ⌘R) uses it, so a
  reply-to-a-reply stacks inline in the feed.
- `threadTarget(msgs, m)` — the root of the thread `m` is already in, or
  `m` itself when it's in none (that message becomes the new thread's
  root). "Reply in thread", the pane composer's fixedReply and the
  jump-into-thread fallback use it. The `thread: true` wire flag is still
  added only at the compose seam.

Thread membership is now exactly the wire flag plus a direct pointer
(`threadRootOf`) — `rootRef`'s transitive chain walk is gone. So:
`threadItems` is a root plus its flagged replies; the "N Replies" tally
counts thread replies ONLY; and an inline reply's quote card carries no
thread link and jumps to the message it quotes (the pre-thread behaviour)
instead of opening a thread.

Event vectors updated deliberately — they are the spec, not a snapshot:
`reply_thread_grouping` (an inline chain is no longer a thread; root 100
tallies 1, not 4), `reply_in_thread_targets_root` renamed to
`reply_in_thread_continues_the_thread`, notes on `message_with_reply` /
`message_in_thread` / `thread_reply_root_unloaded`, and a new
`inline_reply_chain_is_not_a_thread` proving a chain of three produces no
thread and no tally. New keys `expected_thread_items` and
`expected_reply_targets` (quote + thread) are checked by both suites.

Existing history carries no `thread` flag, so every reply in it is a plain
inline quote: today's tallies disappear and those chains stay in the feed,
which is the intended transition.

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

* core: quoteTarget / threadTarget — a thread is the flag, not a chain

The native twins of the web split. `ChatFeedModel.replyTarget` becomes
`quoteTarget(for:)` (the exact message, for plain Reply) and
`threadTarget(in:for:)` (the thread's root, or the message itself when it
is in no thread, for "Reply in Thread").

`threadRootID(of:)` replaces the hop-capped chain walk: a message belongs
to a thread iff its `replyTo` carries `thread: true`, and the root is the
id it points at. `threadRoots`, `threadItems`, `threadReplyRef`,
`mainFeedItems` and `refreshReplyCounts` all read that one predicate, so
the tally counts thread replies only and an inline chain folds into no
thread.

MessageBubble's quote card follows the same fork: a thread reply's card
opens its thread (the only way it renders in the feed is with its root
paged out, so that IS the way back), a plain reply's card jumps to the
message it quotes.

ReplyThreadVectorTests rewritten around the new contract, and now drives
both sequence vectors (reply_thread_grouping and the new
inline_reply_chain_is_not_a_thread) from chat.json — grouping, tallies,
feed visibility, expected_thread_items and expected_reply_targets — so web
and native are pinned to byte-identical expectations.

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

* mac+ios: the two reply verbs on the native surfaces

startReply stages `quoteTarget` (the exact bubble tapped) and
replyInThread resolves `threadTarget`, matching the web. jumpIntoThread
resolves its root through `ChatFeedModel.threadRootID(of:)` rather than
falling back to any quoted id.

Both containers gain the web's overlay guard: while the lifted thread view
is open, a Reply on one of its bubbles stages the thread's root WITH the
flag instead of quoting that bubble into the transcript. iOS already
routed the overlay's own menus that way (threadMessageActions); this is
the belt on startReply itself, and on the Mac it also fixes an existing
gap — its overlay bubbles use the plain feed menu, so a Reply there used
to send an unflagged reply to the root, landing outside the thread.

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

* web+native: a quote card that can't reach its target says so, and pages back for it

Review finding on #1490. With no history carrying the thread flag, EVERY
historical reply is now a plain reply — so the plain quote card's jump is the
default path, and on a cold-opened chat its target is usually older than the
loaded page. All three platforms then did nothing at all: web scrollToMessage
returned on a DOM miss, Mac jump(to:) and iOS jumpAndWave guarded on
`model.messages.first(where:)`. A dead control.

Now the jump pages history back for its target and lands on it, generalising
the walk the thread view already had:

- web: `pageInRoot`'s loop becomes `pageBackTo(sid, stillWanted)`, returning
  found / gone / capped; `revealMessage` drives it for a jump, reached through
  the mount registry as `threads.get(id).reveal(sid)`. Same loadingOlder /
  exhausted guards and the same 5-page cap.
- native: `ChatFeedModel.pageBack(to:) -> JumpReach` in LChatCore (8 pages,
  matching the Mac's existing consumeJump walk), driven by `reveal(_:)` in
  both containers.

Bounded, always: at most cap iterations, and each one returns or must make
progress — target found, the loaded window starting BELOW the target (pages
are contiguous, so it was deleted), `exhausted`, or an unmoved oldest id. The
native walk waits out loadOlder's own cooldown once before giving up; the web
walk waits out an in-flight scroll-back before starting, since both re-anchor
scrollTop against their own pre-prepend height. Neither can recurse: a `found`
means the message is loaded, so the retried jump takes a loaded path.

When it can't reach the message the reader is told, inline and never floating:
a new `.chatapp-feed-note` on web and the shared `FeedNoteBar` (mounted via
.safeAreaInset) on Mac and iOS. Two answers, because they differ: "isn't
available any more" (deleted / start of history) vs "further back than this
jump reaches — keep scrolling up for it". One wording for all three, pinned on
both sides — `jumpReachNote` in chat.js and `ChatFeedModel.jumpReachNote`,
each tested against the other's exact strings.

Also from the review:

- Stale comments corrected: `paintQuoteThreadLink`'s header still claimed an
  inline quote card "has always opened its whole thread" (the behaviour this
  branch removes, contradicting threadLinkCount 20 lines up), and Message's
  replyCount / threadRootID / threadReplyCount docs still described resolved
  roots, chased chains and "anything that isn't a reply".
- `Message.threadRootID` keeps a comment saying why it stays: no container
  reads it (they call the static), but it's the native twin of the web's
  `replyRoot` — which IS read, for data-reply-to — and what the vectors'
  expected_threads.roots asserts against here.
- The Mac overlay guard is described honestly now: `threadDocked` is a
  constant true there, so it's a belt for the parked overlay path, not a bug
  that was live. iOS's is a second guard alongside threadMessageActions.
- ReplyThreadVectorTests derives its sequence-vector list from the JSON
  (every entry with expected_threads) instead of hardcoding two names, so a
  new vector can't pass on web and skip natively.

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

* web+native: the reveal actually lands, and a failed fetch stops meaning "deleted"

Three findings on 965898f7.

1. The landing was yanked straight back to the bottom, so the fix didn't work
   in the case it exists for. Every page pageBackTo folds re-renders the feed,
   and render() decides "was at bottom" BEFORE the prepend — so from the bottom
   of a busy chat each page started a follow glide. A registered glide both
   writes scrollTop every frame (an auto-behaviour write cancels an in-flight
   smooth scroll) and makes feedNearBottom answer "at bottom" regardless of
   geometry, so every later render re-armed it. The iteration that finds the
   target returns in the same synchronous turn as the last prepend, so the
   glide had never stepped and was always live: the note flashed, the feed
   never moved. Reduce Motion ON hid it — that path jumps instead of gliding.

   revealMessage now calls a new exported feedCancelGlide(feed) and clears
   feedAtBottom before flashMessage, so the ResizeObserver's re-pin bails too
   (clearing the note is itself a resize). A Node test pins the mechanism: a
   registered glide claims "at bottom" against contrary geometry, cancelling
   releases the claim, and an already-scheduled step is inert afterwards.

2. A failed history fetch told the reader the message was deleted.
   chatAppLoadOlder swallowed every error and returned 0; pageBackTo read 0 as
   end-of-history, latched `exhausted` for the whole mount and answered "gone".
   One offline blip or a 502 mid-deploy became a permanent "isn't available any
   more", with scroll-back dead until remount and the retry answering instantly
   without touching the network. loadOlder now returns -1 for a failed fetch
   (non-ok status, throw, bad JSON) and 0 only when the SERVER says history
   ends. The distinction is a pure, exported, Node-tested pageResult(n) →
   page|end|error, used by both the walk and the scroll-back handler: only
   "end" latches `exhausted` or answers "gone"; "error" is retryable ("capped").

3. Two of the three native jump routes were still silent no-ops. Mac
   consumeJump and iOS runPendingJump kept their own hand-rolled 8-page walks
   ending in a bare return, so a search hit or notification tap that couldn't
   be reached did nothing while web explained. Both now just call
   jump/jumpAndWave, which pages back through reveal() — the walk exists once,
   and all three entry points behave alike.

Also:
- A different target now supersedes an in-flight walk instead of being dropped
  (the old comment described only the same-target case).
- try/finally around the walk and around each loadOlder: a rejecting host used
  to latch loadingOlder, revealSid and the sticky note forever — latent only
  because chatAppLoadOlder swallowed everything, which (2) stops it doing.
- a11y: the role="status" node is no longer display:none between updates (it
  collapses via :empty), so a live-region update is announced from a node that
  was already in the accessibility tree.
- Native pageBack no longer burns a guaranteed-no-op loadOlder plus a 550ms
  sleep on every page after the first (loadOlder re-arms its cooldown in a
  defer): the wait is taken up front from the second pass on, saving ~4s on a
  full walk, with the first pass still retrying once in case the reader had
  just scroll-loaded.
- Reach pinned: web PAGE_BACK_CAP 5 -> 8 to match ChatFeedModel.jumpPageCap.
  Both fetch the server's 100-row default page, so one jump reaches ~800
  messages everywhere and the same message can't answer "capped" on web and
  land on native.

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

---------

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