Jump to the next segment needing attention

ViewOptionsDropdown、src/components/InterlinearNavContext.tsx の InterlinearNav.navigate、フォーカス要求の接続箇所、そして src/utils/suggestion-engine.ts の deriveTokenSuggestion から始めます。useInterlinearizerBookData から読み込まれた書籍データを再利用し、述語を #117 と整合させます。選択したナビゲーションモードが、一覧にある前進、後退、境界、フォーカス、述語の一貫性に関する動作を満たし、見つけやすいメニュー項目があることが完了の条件です。

There is no way to find where the work is. Navigation today is by reference (BookChapterControl in src/components/controls/ScriptureNavControls.tsx) or by scrolling, so a half-glossed book is walked by eye. Every other affordance we have — the catalog (#186), per-book counts (#117) — tells you what is unfinished; none of them takes you there.

Two targets, not one

"Unapproved" covers two populations that want different affordances:

1. A pending suggestion — a token with no approved link whose form hits the pool (deriveTokenSuggestion, src/utils/suggestion-engine.ts:129-158). A review queue: everything here is one keystroke from done, and this is the natural companion to bulk approval.
2. An unanalyzed word — a word token with no approved link and no pool match. A work queue: nothing here can be accepted, it has to be typed.

A single "next unapproved" conflates them and lands the user on whichever comes first, which is the wrong tool half the time — hunting for typing work while being stopped every third verse by an accept-able suggestion, or the reverse. Recommend two directions of one command family (or one command with a mode in ViewOptionsDropdown), and pick the default deliberately.

Third candidate population, to decide on: a token whose approved analysis has gone stale because the baseline text moved under it (#139, #136, #156). Those verses need attention more urgently than either of the above, and nothing surfaces them today. If staleness detection lands first, this command should be the thing that navigates to it.

Seams to reuse

• InterlinearNav.navigate(ref, origin) (src/components/InterlinearNavContext.tsx:120) — moves the reference, classified internal so the segment window skips its recenter fade for a target already on screen.
• requestFocusToken(tokenRef) / consumeFocusRequest(bookCode) (:172, :189) — the focus seam #193 already uses for jump-to-usage. Reuse it; do not add a second way to focus a token.
• The scan itself is a pure pass over the loaded book's segments against the same resolved-analysis state the renderer reads. Both halves exist; nothing new is needed in the store.

Share the predicate with #117. "Segment contains a pending suggestion" and "segment contains an unanalyzed word" are the same predicates #117's per-book approved/suggested counts need, aggregated instead of searched. Write them once, in one place, or the count and the jump will disagree.

Design questions to settle

• The book boundary. Only the current book is loaded — useInterlinearizerBookData fetches one BookUSJ (src/hooks/useInterlinearizerBookData.ts:55-58). Crossing into the next book is a fetch, a re-tokenize, and the cross-book fade curtain (FadePhase, RECENTER_FADE_MS), which is heavy for a key the user may hold down. Recommend stopping at the end of the book for v1 with an explicit "nothing further in this book", and treating "next book with work" as a separate, deliberate action (naturally #117's view, which already knows which books have unfinished work without loading them).
• Scroll-group coupling. navigate writes through the host scroll-group ref, so every hop drags the Paratext editor and any other linked window along, and rapid hopping spams the group. Decide whether these hops write through at all — the view already exposes a ScrollGroupSelector, so "linked" is the user's stated intent, but a review sweep is arguably a local movement.
• Direction and wrap. Forward and backward both, and decide wrap-around vs. stop-at-end. Wrapping silently makes "am I done?" unanswerable; stopping makes it the answer.
• What counts as a segment. The unit is the segment, not the verse (custom boundaries, SegmentationDelta), and verse-0 superscription segments are real segments here (#223, #125). Punctuation tokens (TokenType) never count.
• Discoverability. The value is in the keyboard. Needs a menu entry in contributions/menus.json with localized strings even if the keystroke is the real interface — same discoverability problem as #155.

Behaviors to test

1. From a segment with pending suggestions, the command lands on the next qualifying segment, not the current one.
2. Segments with only approved tokens are skipped.
3. The suggestion-mode and unanalyzed-mode commands land on different segments when both populations exist between the cursor and the end of the chapter.
4. At the last qualifying segment in the book, the command reports that and does not navigate (per the boundary decision).
5. The landing focuses a token in the target segment via the existing focus-request seam, and the request is dropped if navigation leaves that book.
6. A backward jump from the first qualifying segment behaves as the wrap decision specifies.
7. The predicate driving the jump agrees with the count #117 reports for the same book.

Related

#117 (shares the predicate), #193 (shares the focus seam), #139 (would add a third target population). Pairs with #254 — a review sweep is "jump to the next verse with suggestions, approve them all, repeat".