feat(dashboard): agentic conversation tracking with live transcript view

[hartmark]

Summary

• Every agentic chat request now gets a conversation id (X-ConversationId response header). OmniRoute detects when a follow-up request continues the same conversation via fingerprint + bounded prefix-hash matching, with a strict-growth invariant (turns.length <= candidate.lastMessageCount → reject) to prevent false merges between independent single-shot requests that happen to share identical opening content.
• /dashboard/logs: new toggleable Conversation column.
• /dashboard/logs/timeline: requests sharing a conversation id share a timeline lane, connected by an arrow, with a configurable lane-reuse window.
• Request detail panel: new Full Conversation transcript, rendered above the raw SSE event stream, with:
  • Markdown rendering (reusing the existing MarkdownMessage component)
  • Per-turn timestamps
  • Turn-relative view (only turns up to the one you opened, with a "view next message" link that scrolls the panel into view)
  • Click-any-turn-to-open-its-own-log navigation
  • Live auto-refresh with an auto-follow toggle (default on, matching the event stream's existing autoscroll pattern) that rebuilds the transcript in real time from the in-flight SSE chunk buffer while a request is still streaming — not just after it completes
  • Auto-scroll-to-bottom as the live turn grows
• New /dashboard/conversations page listing only conversations with 2+ turns.
• Configurable auto-refresh intervals on both the timeline and conversations list pages.

Also fixes along the way

• RequestTimeline.tsx hardcoded debugEnabled={false} and emailsVisible={false} on the shared detail panel instead of reading the same server-side setting / store state RequestLoggerV2.tsx already used — meaning the timeline view never showed SSE/stream-chunk events or respected email-masking, regardless of the actual setting.
• Request detail panel and conversations list are now responsive on mobile (the panel previously needed horizontal panning to reach its own close button, due to a non-wrapping header combined with a CSS overflow-x/overflow-y interaction quirk).
• docs/security/AGENTROUTER_WAF.md was missing required frontmatter, breaking the Next.js/fumadocs build entirely — pre-existing on release/v3.8.50 (landed in fix(agentrouter): retry on 400 content-blocked + burst guard #9323), unrelated to this feature, fixed here because it blocked building this branch for deploy verification.

Test plan

• npm run typecheck:core — clean
• npm run lint — clean
• npm run test:unit — 27109 passed; the only 18 failures present are confirmed pre-existing on release/v3.8.50 (reproduced identically against the clean base commit in a throwaway verification worktree, unrelated to this branch — model-routing/gpt-5.5/gpt-5.6, vscode-token-routes, ServiceSupervisor, npm-pack, monaco-editor)
• npm run test:vitest — 291/291 passed
• New unit tests: conversationTracker.test.ts, agenticConversations.test.ts, multiRowConversation.test.ts, request-timeline-lane-allocation.test.ts (including a regression test for the strict-growth invariant, added after live testing surfaced two independent byte-identical single-message requests incorrectly merging into one conversation)
• Live-verified end-to-end on a throwaway omniroute-beta container across several rounds: multi-turn conversation tracking, turn-relative transcript truncation, click-navigation between turns, and — via direct curl polling of /api/logs/{id} mid-stream — confirmed the transcript genuinely grows turn-by-turn while a request is still actively streaming (not just after completion)
• Deployed to omniroute-dev (rebased onto latest release/v3.8.50): health check passes, DB migration applied cleanly, new routes smoke-checked (proper 401 without auth, no 500s)

[hartmark]

Marking as draft — found a couple of real bugs during further live verification on the dashboard (the conversations list appears empty and the timeline detail view only shows a single turn for a multi-turn conversation). Investigating now, will mark ready again once fixed.

[hartmark]

Found and fixed two real bugs during live verification on omniroute-dev:

1. Conversations list was empty / detail view only showed 1 turn — root cause: conversation continuation never actually worked for real agentic CLI traffic. computeFingerprintHash/hashTurnsBounded anchored identity partly on the system message's text, but real coding-agent CLIs (Claude Code, opencode, etc.) commonly regenerate the system prompt on every request with live context (timestamp, cwd, git status...). That volatility alone broke continuation detection — confirmed live: 28 consecutive requests from one real, growing session, each recorded as its own turn_count=1 conversation. Fixed by excluding the system message from both the fingerprint and the prefix-hash continuation check. New regression test reproduces the exact scenario.

Note: this doesn't retroactively fix already-logged conversations from before the deploy — only new traffic going forward will track correctly.

2. (#9315) Provider Response panel stale for long streams — the summary was reconstructed from the (capped, truncation-dropping) raw event array instead of computed incrementally as chunks arrive. Fixed by making the per-format summary builders available as incremental reducers fed on every push(), regardless of storage truncation.

Both TDD-verified (failing test → fix → passing), full test:unit/test:vitest suites clean (only the same 18 pre-existing, independently-confirmed-unrelated failures), rebuilt and redeployed to omniroute-dev.

Marking ready for review.

[hartmark]

Rebased onto the latest release/v3.8.50 and did a full pass over the branch. Summary:

Rebase/merge

• Incorporated your recent syncs on this branch (the release/v3.8.50 merges + docs/quality fixes).
• Merged the current release/v3.8.50 tip (134 commits ahead of the last sync) — resolved 6 real conflicts (file-size baseline numbers, 5 i18n files where I took upstream's version since this branch never touched them).

Bugs found and fixed along the way (not scope creep — all blocked verification or were surfaced directly by the merge):

1. Migration version collision: release/v3.8.50 independently added 135_migrate_model_capability_max_token.sql, colliding with this branch's own 135_agentic_conversations.sql. Renumbered this branch's two conversation-tracking migrations to a contiguous 136/137 (first tried 137/138, which left an unexplained sequence gap that check-migration-numbering.test.ts correctly caught — fixed to be contiguous).
2. Real upstream bug, not mine: open-sse/handlers/chatCore.ts calls mergeResponseToolNameMap() but never imports it from ./chatCore/passthroughToolNames.ts — a ReferenceError on every request reaching that line. Verified byte-identical to release/v3.8.50's own current tip (not a merge artifact), so it's a live bug on the release branch itself. One-line fix; it was single-handedly responsible for ~20+ of the test failures I first saw across unrelated test files (AgentRouter, chatCore, vision-bridge, etc. all route through this code path).
3. Stale node_modules: the merge bumped better-sqlite3 and added an allowScripts config in package.json, but this worktree's hard-linked node_modules was stale relative to the new lockfile — every npm consistency check (e.g. npm pack) was trying to reconcile it and hanging for minutes on this repo's overrides conflict graph. Ran npm install to resync; committed the resulting tiny lockfile metadata fix.

Test/quality status (all green after the above fixes):

• npm run typecheck:core — clean
• npm run lint (full suppressions-aware run) — clean
• npm run test:unit (all parts: main + dashboard + serial) — clean except 29 failures + 1 excluded slow test, all verified via git diff release/v3.8.50 HEAD -- <file> to be byte-identical to release/v3.8.50's own tip (both the test files and the source they exercise) — i.e. pre-existing on the release branch itself, unrelated to this PR (env-sensitive checks: i18n locale completeness, .env.example sync, a couple of vision/combo tests). The one excluded test (tests/unit/mcp-published-files-closure-3578.test.ts) does a real npm pack --dry-run that hits the same slow overrides-conflict resolution mentioned above — also confirmed pre-existing.
• npm run test:vitest — clean (292/292; the one file that looked flaky, tieredRotation.test.ts, was host-load timeouts on my end, confirmed passing 11/11 once node_modules was fixed).
• check:file-size, check:any-budget:t11, check:docs-sync — clean (added a new baseline entry documenting this session's growth + the merge's inherited pre-existing drift).

Everything's pushed to feat/agentic-conversation-tracking. Let me know if you'd like the mergeResponseToolNameMap fix split out separately since it's not actually part of this feature.

[hartmark]

The base branch (`release/v3.8.50`) moved again (22 more commits) and re-introduced conflicts — resolved and pushed.

New conflicts (6): file-size baseline numbers, an i18n file (took upstream's, untouched by this branch), `localDb.ts` (both sides purely additive re-exports — kept both), `SetupWizard.tsx` (upstream independently fixed the same unescaped-entity issue I'd fixed earlier — took theirs), and `catalog-order-contract.test.ts` (upstream added a slightly different fix for the same `as any` issue I'd already cleaned up — kept mine, simpler).

More serious finding: this pull also revealed that upstream's own `release/v3.8.50` currently has two pairs of migration files colliding on the same version number (`135_auto_restart_adopted.sql` vs `135_migrate_model_capability_max_token.sql`, and `136_dario_fallback_backend.sql` vs `136_radar_cache_settings.sql` — confirmed via `git ls-tree` against your tip directly, unrelated to this PR). Unlike my first migration-numbering fix, this one isn't just a test-gate warning — `migrationRunner.ts` hard-throws on any duplicate version, so getDbInstance() fails outright for every test and request against the merged tree. Resolved by keeping Dario's original numbers (chronologically first, PR #8523) and renumbering the two later collisions (`migrate_model_capability_max_token`->139, `radar_cache_settings`->140), updating the one test that reads a migration file by hardcoded path. This PR's own two migrations stayed at 137/138.

Re-verified: `check-migration-numbering.test.ts` (15/15), full typecheck, file-size/any-budget/docs-sync gates, and every DB-touching test this PR added or fixed (agenticConversations, conversationTracker, conversations-tree-route-seq-param, catalog-order-contract, model-capability-overrides) — all green. PR now shows `mergeable: true`.

You may want to flag the Dario/radar/model-capability migration collision to whoever owns those PRs — it's a real bug on `release/v3.8.50` independent of this branch, and any other open PR based on that branch will hit the same hard failure until it's fixed at the source.

[hartmark]

Small scope-creep addition on top of this PR: 66a2515 fixes an unrelated dev-mode bug I hit while live-testing the conversation tracking feature on a phone.

Symptom: a phone browser tab got stuck in an endless refresh loop (content flickering/resetting every ~1.5s, no visible white-flash reload) hitting the dev server. A private/incognito tab on the same phone/URL did not loop, which pointed at stored browser state rather than anything server-side.

Root cause: PwaRegister.tsx correctly skips registering a new service worker outside production, but never unregisters an old one. That phone had previously loaded a production build of this origin, so a leftover service worker was still intercepting every navigation/asset fetch. It would occasionally serve a stale cached JS chunk that didn't match the currently running dev server, which trips Next's dev-client chunk-mismatch auto-reload — and since the stale worker never goes away on its own, that repeats forever.

Fix: PwaRegister now actively unregisters any existing service worker registrations and clears their caches whenever NODE_ENV !== "production", instead of just no-op'ing. Covered by tests/unit/PwaRegister.test.tsx (dev-mode cleanup path + prod registration path). Confirmed live: after the fix + a clean reload, the phone's dev-mode HMR fast-refresh works normally (verified with a throwaway visible text edit that hot-updated on the phone with no reload loop).

Flagging as scope creep since it's unrelated to conversation tracking — happy to split into its own PR if preferred, but it's small (one component + one test) and was blocking my own live verification of this feature.

[hartmark]

Pushed a merge + 3 more commits:

• Merged latest upstream/release/v3.8.50 (6 new commits, Gemini thought_signature replay fix — unrelated area, clean merge, no conflicts).
• 4350a38 — prev/next conversation nav (chevron buttons in the conversation modal, mirrors the request-detail view's pattern) + a live streaming turn preview: the transcript now shows the reply as it's actively generating (/api/conversations exposes the in-flight request's own id via activeCallLogId, since call_logs only gets its row on completion and the existing lastCallLogId always lagged one request behind mid-stream).
• dac6260 — real bug found while live-testing on a large edit/apply_patch-style tool call: conversationTracker.ts sliced a tool call's raw JSON arguments at a fixed 8000-char offset, which for any call over that size landed mid-string and stored invalid JSON. The UI's parse-and-render fallback then showed the raw, still-escaped text verbatim — looked exactly like a JSON-escaping bug, was actually a truncation bug. buildTextPreview now parses first and caps oversized string values, so a truncated payload is always valid JSON. Confirmed live: 3 stored previews on omniroute-dev were sitting at exactly 8000 chars with Unterminated string in JSON. Also fixed JsonViewer's string rendering to preserve line breaks. Unrelated hygiene fix found in the same file: two literal NUL bytes (pre-existing, not from this session) where template-literal spaces belonged.
• 7b1f353 — bumped CHAT_LOG_ARRAY_TAIL_ITEMS default 24 → 128. Traced a "why didn't OpenClaw process this tool call" question and found our own request logging was truncating a 47-tool array down to the last 24, silently dropping the actually-called tool's declaration from every log — real agentic CLIs with several MCP servers routinely exceed 24 tools.

Heads up on CI: npm run lint will show 3 no-explicit-any errors in tests/unit/vertex-functioncall-id-3440.test.ts — confirmed byte-identical to upstream's own tip (came in via the merge), the file's eslint-suppressions.json entry is frozen at count: 2 but upstream's own commit added a third any without bumping it. Inherited base-red (release/v3.8.50 is already flagged red in #9298 for unrelated reasons), not something introduced here — leaving it for upstream/the base-red drain rather than patching suppressions from this branch.

All new/changed code: typecheck clean, lint clean, relevant unit tests passing (conversationTracker: 21/21, new activeCallLogId route test: 2/2, chatcore-log-truncation + env-doc-sync: 19/19), env/docs sync check passes.

[hartmark]

One more, found via live dashboard use + a wire-level pcap cross-check (`032a3d2f7`):

Bug: `open-sse/utils/stream.ts`'s `providerPayloadCollector` (the dashboard's "Provider Response" panel) was keyed on `sourceFormat` (the CLIENT's wire format) instead of `targetFormat` (the PROVIDER's — this function's own `@param` doc says so explicitly: `targetFormat - Provider format`, `sourceFormat - Client format`). Whenever a request translates between two different formats — e.g. a Responses-API client routed to a plain-OpenAI-chat-completions upstream (the common OpenClaw/opencode-zen shape) — the reducer picked for `sourceFormat` could never recognize the provider's actual raw event shape, so it stayed stuck at its empty initial state. Dashboard symptom: "Provider Response" permanently shows `output: []` while "Client Response" (built from separately-accumulated state, unaffected) correctly shows full content — reads as if the two panels simply disagree about the same request.

How it was caught: while debugging an unrelated OpenClaw silent-turn issue, captured the raw Caddy↔omniroute-dev bytes with `scripts/sre/tcp-close-analyzer.py` (merged upstream in #8208) and cross-referenced against the dashboard log for the same request id — confirmed the actual wire response was complete and correct, isolating this to a pure logging/summary bug, not a wire-format bug.

Fix is mode-aware: TRANSLATE mode now uses `targetFormat`; PASSTHROUGH mode keeps `sourceFormat`, since passthrough has no separate provider/client format split (nothing gets translated there, and the real passthrough caller `createPassthroughStreamWithLogger` doesn't even pass `targetFormat`).

New regression test reproduces the exact live scenario (Responses-API source, OpenAI target, real `chat.completion.chunk` deltas) — confirmed it fails with the old `sourceFormat`-keyed code (reproducing the live `output: []`-style symptom) and passes with the fix. All 94 tests across the touched stream/logging test files pass; typecheck/lint clean on the actual project gates (`typecheck:core`, suppressions-aware `lint`).

[diegosouzapw]

Thank you for this substantial contribution. After analysis, this is being marked as [defer] — it introduces a large new subsystem (agentic conversation tracking, +9639 lines) that would benefit from a design RFC/discussion first to align with the project's architecture before merging piecemeal. The work is captured in the backlog via the defer label. Please open a discussion or RFC if you'd like to drive the design conversation.

[hartmark]

Rebased onto the latest release/v3.8.50 tip (61014aec5 → now 8fc4023f9, ~231 commits of drift). Summary:

• 34 commits → 20 after dropping ones already landed upstream separately (Git auto-detected empty patches).
• Conflicts resolved: ~40 i18n message files (3-way merge preferring non-placeholder translations), several config/quality/file-size-baseline.json re-baselines (took upstream's current values — they've moved independently many times), a couple of genuine code conflicts (import supersets, additive array entries, stale test fixtures already matching upstream's own independent fix for the same bug class).
• Fixed a real pre-existing bug found while validating: tests/unit/agenticConversations.test.ts / conversationTracker.test.ts used static imports after a process.env.DATA_DIR override — ES modules evaluate imported modules before the entry file's own top-level code, so the override silently missed and tests wrote to the real host DB instead of an isolated temp dir. Switched to dynamic imports.
• Fixed a real gap in this PR's own providerPayload summary fix (caught by this PR's own new regression test): the translate/passthrough fallback path never stamped object: "chat.completion" on the synthesized summary.
• Updated KNOWN_GAPS in scripts/check/check-migration-numbering.mjs — migrations 143/144 are no longer gaps now that this PR fills them.

npm run test:unit (~19k tests completed before a runner limit), npm run test:vitest (355/355), typecheck, and lint all clean except pre-existing base-red failures (confirmed identical on a pristine upstream/release/v3.8.50 checkout).

⚠️ base-red inherited: #9985

[hartmark]

Superseded by #10047 — same feature, rebased onto the current release/v3.8.50 tip and cleaned up (23 commits → 14). The dropped commits were all fixes for bugs that were pre-existing on release/v3.8.50 itself and have since been independently resolved upstream (verified against the current tip before dropping each one); two other genuinely-standalone fixes were already split out as #10037 and #10038. See #10047's description for the full commit-by-commit breakdown.

Closing this one in favor of #10047.