Consider hiding or softening the 'X segments' badge in the session sidebar

[franksong2702]

Problem

The session list sidebar currently shows an "X segments" badge next to sessions that have been compressed or merged. For example, a single session row may show "20 segments".

This information can be useful, but the word "segments" is not a concept most users are likely to recognize. In the main session list, it can make the sidebar feel more technical than necessary:

1. Unclear user meaning - Users may not know what "segments" means or whether they need to take action.
2. Advanced/debug-oriented detail - The count appears to describe the internal compaction or lineage structure rather than a normal session action.
3. Sidebar density - The session list already has titles, timestamps, and state indicators, so extra metadata should probably be reserved for information users commonly scan.
4. Expandable lineage behavior may need more context - Clicking the badge exposes historical compressed sessions. That may be valuable for debugging or inspection, but it is not obviously part of the default browsing flow.

Background

This feature was introduced in PR #1906 (shipped in v0.51.26 via release PR #1917). A UX feedback comment was left on that PR (#1906 comment) after the PR had already been auto-closed, so it may have been easy to miss.

Possible Direction

Consider making the segment/lineage information less prominent in the default sidebar. A few possible options:

• Hide the "X segments" badge by default and keep it available in an advanced/debug mode.
• Rename the label to something more user-facing if it should remain visible.
• Move lineage details into a session detail view or inspector instead of showing them inline in the main session list.
• Keep the current behavior only when a developer/debug setting is enabled.

The goal is not necessarily to remove the underlying feature. It may just fit better as an advanced inspection affordance rather than default sidebar metadata.

Relation to PR #2072

PR #2072 appears to add a useful opt-out setting for session lineage indicators. That would address the mechanism for hiding the badge when users do not want it.

This issue is meant to track the remaining UX question: whether the segment/lineage information should be visible by default in the primary sidebar, and whether the terminology should be more user-facing if it remains visible.

Code References

• static/sessions.js lines 2105-2130 (_sessionSegmentCount, _lineageReportNeedsFetch)
• static/sessions.js lines 2789-2825 (badge rendering in renderSessionListFromCache)
• api/routes.py line 1612 (_compression_segment_count in metadata)

Impact

• Makes the session list easier to scan for regular users.
• Reduces exposure of implementation-oriented terminology in the primary UI.
• Preserves the possibility of keeping lineage information available for advanced/debug workflows.

[nesquena-hermes]

Thanks for the detailed report and the file:line citations — they line up with what's actually in the tree. Reading static/sessions.js:2105-2113 (_sessionSegmentCount) and static/sessions.js:2789-2825 (the badge render block inside the sidebar renderSessionListFromCache path):

function _sessionSegmentCount(s){
  if(!s) return 0;
  const counts=[];
  if(typeof s._lineage_collapsed_count==='number') counts.push(s._lineage_collapsed_count);
  if(typeof s._compression_segment_count==='number') counts.push(s._compression_segment_count);
  if(Array.isArray(s._lineage_segments)) counts.push(s._lineage_segments.length);
  const count=Math.max(0,...counts.map(n=>Number.isFinite(n)?n:0));
  return count>1?count:0;
}

And the render at 2796-2802:

if(segmentCount>0){
  const segmentCountEl=document.createElement('span');
  segmentCountEl.className='session-lineage-count'+(canExpandLineageSegments?' expandable':'');
  const segmentLabel=t('session_meta_segments', segmentCount);
  segmentCountEl.textContent=segmentLabel;
  ...
}

This is exactly what you describe — a count surfaced unconditionally next to titles in the sidebar, with no setting to suppress it.

Existing PR addresses this

PR #2072 ("feat: Add toggleable session lineage indicators setting", currently hold label) implements almost exactly what you propose:

• Adds a lineage_indicators server-side default in api/config.py (defaults to on today).
• Adds a "Show session lineage indicators" checkbox in Settings.
• Boot-time hydration via window._lineageIndicators in static/boot.js (mirrors the _sidebarDensity pattern).
• Guards both the git-branch fork icon and the segment count in static/sessions.js behind window._lineageIndicators !== false.
• Calls renderSessionListFromCache() on apply so the change is immediate without page reload.
• i18n across the 9 supported locales for the label/description.

The two open questions from your write-up that PR #2072 does not decide are exactly the ones holding it back:

1. Default state — your strongest argument is "this is a technical detail, no user mental model exists." That implies the default should be OFF, with debug users opting in. PR feat: Add toggleable session lineage indicators setting #2072 as written defaults to ON, which preserves the v0.51.26 behavior and treats the setting as a hide-when-noisy escape valve.

2. Whether the lineage expand/collapse UI also belongs under the same toggle — your report suggests both should be hidden. PR feat: Add toggleable session lineage indicators setting #2072 hides both the segment badge AND the branch icon when toggled off, but it does not hide the lineage expand/collapse interaction surface itself; clicking still works if you find an expandable row another way.

Suggested path forward

The "X segments" badge has documented friction across two reports now: the comment on the original PR #1906 you cite, and this issue. The argument for default-off is strong on first principles — backend lineage state shouldn't telegraph itself into the sidebar without an actionable user mental model. The counter-argument is regression risk: v0.51.26 users may have started relying on the badge for navigation between compressed segments.

A reasonable middle ground if PR #2072 ships:

• Default the new setting to ON to avoid a silent v0.51.x → next behavior change for existing users.
• Add a one-time tooltip on first sidebar render that mentions the setting exists, so users who find it noisy can find the toggle.
• File a separate UX issue tracking whether the default should flip to OFF in a future major release (with appropriate CHANGELOG / release-notes coverage).

The harsher option — remove the badge outright as you propose — is also defensible but more disruptive. The compressed-session lineage is real functionality and some users may be relying on the expand/collapse interaction to navigate it.

Note for the maintainer review

I'd recommend not closing this issue when PR #2072 merges — the underlying "default should change" question is separate from the "setting should exist" question. If PR #2072 ships with default=on, this issue is the natural place to discuss whether the default should flip to off in the next major version.

[Michaelyklam]

This looks covered on current master by #2175 and the later compact-density cleanup in #2219:

• the English badge copy is now N prior turn(s) instead of N segments;
• compact sidebar density no longer shows the lineage badge/expandable segment rows by default;
• regression coverage in tests/test_session_lineage_collapse.py now forbids the old segments wording in the English badge.

I think this can be closed unless someone still wants a broader lineage-details redesign beyond the softened/default-hidden sidebar copy.