fix: split live Activity groups at auto-compression

[Michaelyklam]

Thinking Path

• Auto-compression card mid-turn should close current live Activity group #2404 reports a narrow live-timeline boundary bug introduced by the recent Activity grouping fixes.
• Consecutive tools should stay grouped, but auto-compression is a visible context/timeline boundary like an interim assistant progress note.
• The current live Activity group was still marked as current when the compression card rendered, so a later tool could attach to the pre-compression group.
• The safest fix is to leave the rendered group in place, clear only its current-marker, and let the next tool create a fresh Activity group.

What Changed

• Added a closeCurrentLiveActivityGroup() helper in static/ui.js that clears data-live-activity-current from the current live Activity burst.
• appendLiveCompressionCard() now closes the current Activity burst before inserting/replacing the live compression card.
• Added source-level regression coverage ensuring compression cards split live Activity bursts while preserving the existing tool-start behavior.
• Added a release-note entry under [Unreleased].

Why It Matters

• Auto-compression changes the model context mid-turn and should be visible as a real timeline boundary.
• Post-compression tools now render under a separate Activity row instead of visually joining the pre-compression tool burst.
• The change stays narrow: ordinary consecutive tools still share one Activity group unless a real boundary event occurs.

Verification

• env -u HERMES_CONFIG_PATH -u HERMES_WEBUI_HOST /home/michael/.hermes/hermes-agent/venv/bin/python -m pytest tests/test_ui_tool_call_cleanup.py -q — 21 passed
• node --check static/ui.js
• git diff --check

Risks / Follow-ups

• This is a source-level UI regression fix; no visual media is attached because the affected state is a transient mid-stream DOM boundary.
• If future compression events gain multiple simultaneous card types, they should use the same boundary helper before rendering.

Closes #2404

Model Used

AI-assisted change with repository inspection, targeted editing, and shell-based test verification.

[nesquena-hermes]

Ready for independent review (fixes #2404, the deferred follow-up from stage-370 Opus advisor on #2390).

7-line client-side fix. When auto-compression fires mid-turn between two tool bursts — with no intervening interim_assistant event to act as a timeline boundary — the post-compression tool used to attach to the pre-compression Activity row. This PR adds a closeCurrentLiveActivityGroup() helper that clears the data-live-activity-current marker on the open group before the compression card renders, so the next tool start opens a fresh Activity row.

Note: I separately filed an in-house PR #2410 with the same fix shape during the stuck-PR sweep before discovering this contributor PR. Michaelyklam's named-helper factoring here is the cleaner implementation — going to close my #2410 and credit @Michaelyklam. This is the version that should ship.

Should batch with #2406 + #2407 into a follow-on stage after reviews land.

[nesquena]

Review — end-to-end ✅ (clean APPROVE — note: parallel-built duplicate of #2410)

What this ships

8-line client-side fix for issue #2404 (auto-compression mid-turn should be a timeline boundary that closes the current live Activity group). Same root cause as the just-approved #2410 — a maintainer-built fix that landed at almost the same time. Both fixes are functionally correct; merging either will close #2404. Maintainer decides which one to land.

Surfaces touched: static/ui.js (+8: 4-line helper closeCurrentLiveActivityGroup() + 1-line call from appendLiveCompressionCard), tests/test_ui_tool_call_cleanup.py (+13), CHANGELOG.md (+4). CI green on 3.11/3.12/3.13.

Traced against upstream hermes-agent

No cross-tool surface — data-live-activity-current is a webui-only DOM marker attribute. Never serialized to config.yaml, session schema, or the agent loop. Pure client-side DOM contract.

End-to-end trace

• ensureActivityGroup(inner, opts) at static/ui.js:4683-4720 sets both data-live-tool-call-group="1" AND data-live-activity-current="1" on creating a live group (lines 4706-4707). Its selector at line 4688 matches [data-live-tool-call-group="1"][data-live-activity-current="1"] to reuse the open live group.
• New helper at static/ui.js:4721-4727 — closeCurrentLiveActivityGroup() selects on $('liveAssistantTurn') and removes data-live-activity-current from any matching tool-call-group. Same selector-and-remove pattern as _closeCurrentLiveActivityGroup() in static/messages.js:1108-1115 (used for interim_assistant boundary).
• appendLiveCompressionCard(state) at static/ui.js:4837 now calls closeCurrentLiveActivityGroup() immediately after resolving the inner block (line 4855), BEFORE creating the compression card node.
• Next tool start → ensureActivityGroup selector no longer matches the now-closed pre-comp group → creates a fresh group.

Other audit — things that are correct already

Security

• Pure DOM attribute removal. No HTML insertion, no string interpolation. Selectors are static literals.

Selector precision

• Same double-attribute matcher ([data-live-tool-call-group="1"][data-live-activity-current="1"]) as the writer and as the interim-assistant boundary in messages.js. Won't accidentally close non-live or already-closed groups.

Helper extraction quality

• The named helper closeCurrentLiveActivityGroup() mirrors the symmetric helper _closeCurrentLiveActivityGroup() in static/messages.js:1108-1115. Reads cleanly at the call site. If future timeline boundaries (e.g. mid-turn approval flow) need the same close, the helper is reusable without inlining.
• The helper has no underscore prefix while the messages.js counterpart does (_closeCurrentLiveActivityGroup). Minor naming inconsistency — see notes below.

Idempotency

• forEach over querySelectorAll is safe against zero matches (no-op). Repeated calls land in zero matches after the first removes the attribute.

Compatibility with #2410

• Both PRs end up doing the same querySelectorAll/forEach/removeAttribute against the same selector. The DOM contract is identical post-merge. If both are merged in sequence, the second will get a merge conflict on appendLiveCompressionCard since both modify the same function body.

Behavioural harness

Same harness as for #2410, exercising the helper-extraction variant of this PR:

group[0] live=false tools=[pre-0, pre-1, pre-2]   ← pre-comp group, sealed
group[1] live=true  tools=[post-0]                ← fresh post-comp group

✓ HARNESS CONFIRMS FIX (helper variant)

Edge-case trace

Scenario	Expected	Actual
Tools → compression → tool	2 distinct groups	✅ harness
Compression with no prior live group	helper finds no match → no-op	✅ guarded if(!turn) return
Two compression events back-to-back	second closeCurrentLive... is no-op	✅ idempotent
Non-live activity group	unaffected (selector doesn't match)	✅ double-attribute
Cross-tool: CLI / agent affected	unaffected (DOM-only)	✅

Tests

• PR-targeted: 1/1 pass (test_live_compression_card_splits_current_tool_activity_burst).
• CI: 3.11/3.12/3.13 all green.
• Behavioural harness: pre/post-fix DOM contract verified (2 distinct groups, correct tool partition).

Minor observations (non-blocking)

1. Duplicate of #2410 (which I just approved separately). #2410 is a maintainer-built variant that inlines the same selector+remove logic directly in appendLiveCompressionCard() and has a more comprehensive 3-test regression suite (close-call present, selector exact, ordering BEFORE insert, writer-side drift catch). #2408's helper extraction is arguably cleaner architecturally (matches the existing _closeCurrentLiveActivityGroup shape from messages.js), but its test coverage is thinner. The maintainer should pick one — both are functionally equivalent and will both close #2404. If #2410 is preferred, this PR can be closed with thanks; if #2408 is preferred (the helper extraction is more idiomatic), #2410 should be closed. They will merge-conflict if both land.
2. Naming inconsistency with messages.js. The helper here is closeCurrentLiveActivityGroup (no leading underscore) while the sibling in messages.js:1108 is _closeCurrentLiveActivityGroup (with underscore, file-internal convention). Both are file-internal; would be slightly cleaner to use the same convention. Not blocking.
3. Test coverage is one assertion across three matcher strings. #2410's 3-test suite explicitly pins the BEFORE-insert ordering and writer-side drift. If this PR is the one that merges, consider adopting those two regression pins as a follow-up — they catch real classes of future drift.
4. No JS-level DOM test — same observation as on #2410. Static string-grep is the codebase pattern; my Node harness compensates by exercising the real DOM contract.

Recommendation

Approved. Functionally correct; mirrors the existing _closeCurrentLiveActivityGroup pattern from messages.js. The duplicate-PR situation is for the maintainer to resolve — both #2408 and #2410 close #2404 identically.

✅ Parked at approval — ready for the release agent's merge/tag pipeline (after they decide between #2408 and #2410).

[nesquena-hermes]

Shipped via stage-372 / PR #2414 / v0.51.79 (Release BC). Attribution preserved in the squashed stage commit and the v0.51.79 CHANGELOG entry. Thank you!