feat(web): add stepwise session preview controls

[techotaku39]

Summary

• Replace the terminal Show less action with separate collapse and expand controls for session previews.
• Move each group one preview-sized batch in either direction while preserving the configured preview limit as the minimum.
• Show the actual number affected by the next action, with leading up/down arrow icons and localized English and Chinese labels.
• Add helper and interaction coverage for initial, partially expanded, fully expanded, and collapsed states.

Problem

The paginated session preview introduced in #903 can reveal older sessions one batch at a time, but it can only collapse directly back to the initial preview after the whole group is expanded. For long session groups, users should also be able to step backward one batch at a time without losing their current browsing position.

This is a follow-up to #901 and #903.

Testing

• bun typecheck
• bun run --cwd web test src/components/SessionList.test.ts src/components/SessionList.directory-action.test.tsx (2 files, 52 tests)
• bun run --cwd web test -- --maxWorkers=4 (188 files, 1,648 tests)
• bun run build:web
• bun run --cwd hub generate:embedded-web-assets
• bun run build:hub
• git diff --check
• Manual verification on the local test deployment for the initial, partially expanded, and fully expanded layouts

AI disclosure

Implementation and tests were assisted by OpenAI Codex (GPT-5.6).

[github-actions]

Findings

• [Major] Collapse can be offered at the preview floor and do nothing — getVisibleSessionPreview intentionally keeps every session with a pending request, so it can return more rows than the configured limit. The new check treats that required-row overflow as an expanded preview. With limit 2 and three pending sessions, “Collapse 1” appears, but showFewerSessions computes 2 → 2 and the rendered rows do not change. Evidence: web/src/components/SessionList.tsx:1329.

  Suggested fix:

  const currentLimit = Math.min(getGroupVisibleCount(group), group.sessions.length)
  const previousLimit = getPreviousSessionVisibleCount(currentLimit, sessionPreviewLimit)
  const previousSessions = getVisibleSessionPreview(group.sessions, {
      selectedSessionId,
      limit: previousLimit,
  })
  const collapseCount = visibleGroupSessions.length - previousSessions.length
  const canShowFewerSessions = previousLimit < currentLimit && collapseCount > 0

Summary

• Review mode: initial
• One major correctness issue in the new collapse eligibility/count logic.

Testing

• Not run (automation; PR code was not executed). CI was pending at review time.
• Add an interaction case with a preview limit of 2 and at least three sessions with pendingRequestsCount > 0; verify no no-op collapse control appears at the floor, and any displayed collapse count matches the rows actually removed.

HAPI Bot

[github-actions]

[MAJOR] Collapse state must use the reveal cap, not rendered-row overflow

getVisibleSessionPreview keeps all sessions with pending requests, so the returned array can exceed sessionPreviewLimit even when this group has never been expanded. For example, with a limit of 2 and three pending sessions, this condition renders “Collapse 1”; clicking it makes showFewerSessions compute 2 → 2, so no rows change and the same button remains.

Compute the previous cap and compare the previews so the control appears only when it has an actual effect:

const currentLimit = Math.min(getGroupVisibleCount(group), group.sessions.length)
const previousLimit = getPreviousSessionVisibleCount(currentLimit, sessionPreviewLimit)
const previousSessions = getVisibleSessionPreview(group.sessions, {
    selectedSessionId,
    limit: previousLimit,
})
const collapseCount = visibleGroupSessions.length - previousSessions.length
const canShowFewerSessions = previousLimit < currentLimit && collapseCount > 0

Please cover the required-session overflow case in the interaction test.

[github-actions]

Findings

• [Major] Expand can report a batch but reveal fewer sessions—or none — getVisibleSessionPreview keeps pending/selected sessions visible beyond the stored cap, while the new label still derives from total hidden rows. With preview limit 2 and five pending sessions in an eight-session group, the UI renders five rows and says “Expand 2”; the handler advances the cap from 2 to 4, so the rendered preview remains five rows and the click has no visible effect. Evidence: web/src/components/SessionList.tsx:1340.

  Suggested fix:

  const currentCap = Math.min(
      prev.get(group.key) ?? sessionPreviewLimit,
      group.sessions.length
  )
  const currentVisibleCount = getVisibleSessionPreview(group.sessions, {
      selectedSessionId,
      limit: currentCap
  }).length
  next.set(group.key, getNextSessionVisibleCount(
      Math.max(currentCap, currentVisibleCount),
      sessionPreviewLimit,
      group.sessions.length
  ))

Summary

• Review mode: follow-up after new commits
• The prior no-op collapse finding is addressed; one major correctness issue remains in the corresponding expansion path.

Testing

• Not run (automation; PR code was not executed). The GitHub Test check was still in progress at review time.
• Add an interaction case with preview limit 2, at least five forced-visible pending/selected sessions, and additional hidden sessions; verify one Expand click reveals exactly the displayed count.

HAPI Bot

[github-actions]

[MAJOR] Base expansion on the rendered preview, not only the stored cap

getVisibleSessionPreview can render more rows than currentLimit because pending and selected sessions are mandatory. The new expandCount still assumes the next cap increment will reveal min(previewLimit, hiddenSessionCount) rows. For example, limit 2 + five pending sessions + eight total sessions renders five rows, labels the action “Expand 2”, then showMoreSessions advances 2 → 4 and renders the same five rows. The new four-session regression test masks this because only one row is hidden.

Normalize the expansion baseline to the actual rendered count inside showMoreSessions; then the existing label matches the real delta:

const currentCap = Math.min(
    prev.get(group.key) ?? sessionPreviewLimit,
    group.sessions.length
)
const currentVisibleCount = getVisibleSessionPreview(group.sessions, {
    selectedSessionId,
    limit: currentCap
}).length
next.set(group.key, getNextSessionVisibleCount(
    Math.max(currentCap, currentVisibleCount),
    sessionPreviewLimit,
    group.sessions.length
))

Please cover a group where forced-visible rows exceed both the preview floor and the next stored cap.

[github-actions]

Findings

• No Blocker, Major, Minor, or Nit findings above the 80% confidence threshold.

Summary

• Review mode: follow-up after new commits
• The latest commit addresses the previously reported forced-visible-session expansion no-op by basing the next cap on the rendered count. Full current diff reviewed; no new attributable issues found.
• Residual risk: interaction coverage does not rerender an expanded group while pending or selected required sessions change live.

Testing

• Not run (automation; PR code was not executed).

HAPI Bot