feat: Add toggleable session lineage indicators setting

[JKJameson]

Summary

Adds a Show session lineage indicators toggle to the Settings panel (default: on). When disabled, both the git-branch icon (forked sessions) and the N segments count are hidden from the session list sidebar — without requiring a page reload.

Changes

File	Change
api/config.py	Added lineage_indicators True default
static/index.html	Checkbox UI placed after Sidebar density
static/boot.js	Initializes window._lineageIndicators from server settings on boot
static/panels.js	Reads, applies, and saves the preference; calls renderSessionListFromCache() after apply so the sidebar updates immediately
static/sessions.js	Guards branch indicator and segment count with window._lineageIndicators !== false
static/i18n.js	Label and description translated across all 9 locales (en, ja, ru, es, de, zh, zh-TW, pt, ko)
tests	Fix 2 assertions broken by the guarded segmentCount expression

Technical Notes

• The setting is persisted via the existing /api/settings POST mechanism
• window._lineageIndicators mirrors the pattern used by _showTokenUsage, _showTps, _sidebarDensity etc. — initialized at boot, updated on save
• The sidebar re-renders immediately on save (no reload required)

---

Model used: MiniMax (MiniMax-M2.7, via Nous Research / Hermes Agent)

---

Screenshots

Before (Default Behaviour, remains the default with option checked by default)

---

After (Unchecked)

[nesquena-hermes]

Summary

Reading the diff against origin/master plus static/sessions.js, static/panels.js, and static/boot.js, this is a clean opt-out toggle for the sidebar lineage chrome (#465 git-branch indicator + segment-count badge). The wiring is symmetric across all the usual surfaces — settings default in api/config.py:3901, boot reads it into window._lineageIndicators at static/boot.js:1385, autosave + save flows in static/panels.js both round-trip through _applySavedSettingsUi, and the render guard at static/sessions.js:2594 / 2628 short-circuits both indicators on false.

Code reference

static/sessions.js:2628 (segment-count guard):

const segmentCount=window._lineageIndicators!==false?_sessionSegmentCount(s):0;
const lineageSegments=Array.isArray(s._lineage_segments)?s._lineage_segments.filter(seg=>seg&&seg.session_id&&seg.session_id!==s.session_id):[];
const canExpandLineageSegments=Boolean(lineageKey&&segmentCount>1&&lineageSegments.length>0);

Reading carefully — setting segmentCount = 0 when the toggle is off is a nice touch because it cascades through canExpandLineageSegments (requires segmentCount > 1) and the later if(segmentCount>0&&window._lineageIndicators!==false) guard. The expand caret + the expanded-segments rendering all stay off as a single conditional, no chance of an orphan caret hanging beside a hidden count.

Hot-apply path looks right

The renderSessionListFromCache() call appended to _applySavedSettingsUi at static/panels.js:5793 is the piece that makes "without requiring a page reload" actually work. Before the toggle: the indicator/count were unconditional, so flipping the saved setting would only take effect on next render. The added re-render makes the change visible immediately when settings save completes. Good.

One small nit: the comment on line 5792 reads // Re-render session list so lineage indicators show/hide immediately (#...) — placeholder issue number. Not blocking, but worth filling in with (#2072) or the actual issue ref before merge.

i18n coverage

9 locales (en, ja, ru, es, de, zh, zh-Hant, pt, ko) all get both settings_label_lineage_indicators and settings_desc_lineage_indicators. Translation quality looks fine for the ones I can sanity-check (zh, de, es). No locale parity warning will fire from a future test_*_locale_parity test because every key is present in every block.

If/when #2067 (Italian) merges, that PR will need to add the two new keys — but that's a normal merge-conflict housekeeping issue, not a problem with this PR.

Test coverage

tests/test_session_lineage_collapse.py:331 now pins the exact new guard string:

assert "const segmentCount=window._lineageIndicators!==false?_sessionSegmentCount(s):0;" in js

That catches any accidental regression of the guard back to the unconditional form. The git-branch indicator guard at static/sessions.js:2594 doesn't have a matching string assertion — worth a one-line addition if you want symmetric coverage:

assert "if(s.parent_session_id&&window._lineageIndicators!==false){" in js

Optional, not blocking.

The test_workspace_blank_page_fix.py:69 bump from < 1000 to < 1100 chars is a small consequence of adding one more setting to the boot-settings application block; that test is structural and the relaxation is reasonable.

CI

Three Python versions green. Pure additive, no backend behavior changed, no security surface.

Verdict

LGTM. Worth getting the comment placeholder filled in ((#...) → (#2072)) but otherwise ready to merge. The "default on, opt-out via Settings" shape preserves the v0.51.x lineage UX as the default for current users while giving people who don't want the visual noise a one-click off switch.

[nesquena-hermes]

Thanks @JKJameson — this looks structurally sound (per-pref toggle, no reload required, default-on so the existing UX is unchanged). Before I queue this for merge, can you drop 1280px and 390px screenshots of the sidebar showing:

1. Default state (toggle ON) — git-branch icon + "N segments" count visible for a forked session and a compressed session.
2. Toggle OFF state — same two sessions, both indicators hidden.
3. The Settings panel — where the new "Show session lineage indicators" checkbox lives, so we can confirm placement-after-Sidebar-density reads cleanly.

Mobile width matters because the lineage segments count was originally added partly to densify the mobile sidebar — want to make sure the toggle-off state doesn't leave awkward empty space on small viewports.

Once those land I'll route this through the UX gate. The implementation diff itself is fine.

[nesquena-hermes]

Re-ping for screenshots — UX gate

Hey @JKJameson, this PR is structurally sound and ready to ship as soon as we have the screenshots requested on May 11:

1. Default state (toggle ON) — git-branch icon + "N segments" count visible for a forked session and a compressed session.
2. Toggle OFF state — same two sessions, indicators hidden.

1280px (desktop) and 390px (mobile) viewports for each state, so 4 screenshots total. Once these land in the PR body or a comment, we'll send through the UX gate and merge.

If you're no longer interested in driving this through, no worries — just leave a comment and we can close gracefully.

[nesquena-hermes]

Stuck-PR sweep — closing as superseded

Thanks for this PR, @JKJameson — the design call was sound (give users a way to hide the lineage badges from the sidebar). But while this PR was waiting on screenshots, the same UX goal got shipped via a different mechanism that's now live on master.

Where the feature now lives

Settings → Sidebar density: compact (default) vs detailed. The detailed mode shows lineage indicators (segment count + forked-from chain); compact hides all of that. Implemented in:

• static/sessions.js:2967 — const showLineageMetadata=density==='detailed'; gates the segment count, lineage segments, and the forked-from-fetch path
• static/panels.js:6261 — window._sidebarDensity read from settings
• api/config.py:4042 — "sidebar_density": "compact" default + validation set

The lineageIndicators toggle this PR proposed essentially duplicates that gating from a different control. Two settings for the same outcome would be more confusing than one — and the density control covers more chrome (not just lineage) so it's the more general primitive.

Why I'm closing rather than salvaging

The diff here is well-built (clean opt-out toggle, persists correctly, no reload required), but every observable behavior change it introduces — hiding segment count + branch chrome — is already achieved by setting sidebar_density: compact (which is also the default). There's nothing for the salvage workflow to extract that isn't already in master.

If there's a specific case where the density-based gating doesn't capture what you wanted (e.g. you want segment count in compact mode but not branch chrome, or vice versa), please open a fresh issue describing the case and we can split the gating into two controls.

Closing now to keep the stuck-PR list honest. Thanks for the work and patience.