open-sse/translator/response/openai-responses.ts, src/shared/components/RequestLoggerV2.tsx,
src/sse/handlers/chat.ts, and src/shared/components/RequestTimeline.tsx crossed their
frozen caps from this session's fixes (escape-state persistence, Previous/Next
boundary resync, onNavigateToLog removal). See the new
_rebaseline_2026_08_06_9439_no_forking_redesign_and_fixes entry for the
per-file breakdown and test coverage.
Background list polling intentionally pauses while a request's detail
modal is open, so hitting the edge of the in-memory sorted list didn't mean
there was really nothing newer/older — it just meant the client hadn't
fetched requests that landed in the background yet. handlePrev/handleNext
now resync the list once at that boundary and let a follow-up effect decide
whether to navigate or actually close, instead of assuming the boundary is
real.
Also removes onNavigateToLog from RequestLoggerV2/RequestTimeline's calls
into RequestLoggerDetail — that prop no longer exists after the detail
panel's cross-row next-turn navigation was removed in the prior commit.
RequestLoggerDetail's Conversation Context section now renders only the
currently-viewed request's own buildRequestTurns/buildResponseTurns output
directly, instead of reconstructing a cross-row transcript from prior
requests sharing a session_tag. A single request's own body already is its
full context; the operator asked for this after the multi-row reconstruction
made indentation grow unboundedly (superseded by conversationTracker.ts's
no-forking redesign). Deletes multiRowConversation.ts and its test — dead
code once the panel no longer walks prior rows. Kept live-streaming updates
for an active request (extractPartialAssistantText now also accumulates
delta.reasoning_content, so the panel keeps visibly progressing during a
reasoning-only streaming phase) and added a liveRefresh toggle + scroll-to-
bottom control mirroring StreamSection's existing pattern.
Fixes a real, universal data-loss bug found while investigating why tool
calls looked different between the detail panel and the conversation tree
view: turnsFromOpenAiMessages (conversationNormalizer.ts) only handled
role-based Chat Completions messages. Real Responses API traffic (OpenClaw)
sends bare {type:"function_call"}/{type:"function_call_output"}/
{type:"reasoning"} items with NO role field at all, so they were silently
dropped — every tool call in a Responses API conversation vanished from the
Conversation Context panel. Now handled explicitly before the role-based
branches.
Also fixes a Dark Reader (browser extension) false-positive hydration
warning on OmniRouteLogo's SVG lines (suppressHydrationWarning — the
extension injects data-darkreader-inline-stroke before React hydrates), and
adds break-words to MarkdownMessage so long unspaced runs (raw JSON, ids)
wrap instead of overflowing a narrower container like the conversation
modal. ChatBubble's onClick doc comment updated to reflect it's no longer
multiRowConversation-specific.
requestLogger.ts's cloneBoundedForLog had its own hardcoded depth cap of 6,
independent of the existing configurable getChatLogMaxDepth(). A typical
Chat Completions response body's responseBody.choices[0].message.tool_calls[0].function
sits at exactly depth 6, so every logged tool call's function field
(name+arguments) was silently replaced with the literal string "[MaxDepth]"
before ever being stored — corrupting the data, not just how it renders.
Bumped the shared default 6->20 and switched requestLogger.ts to read it
instead of using its own literal.
escapeJsonStringValues() reset its inString/pendingEscape state on every
call instead of carrying it forward per tool-call index, so a raw newline
byte (or an already-escaped \n) split across two delta chunks got corrupted
in transit — the model's own output was correctly escaped, OmniRoute broke
it. Root-caused via a dispatched investigation into real OpenClaw traffic
that looked like model-generation quality but wasn't.
Fix: escapeJsonStringValues now takes and mutates a persistent per-call
state object (JsonStringEscapeState), keyed per tool-call index in the
translator's init state and cleared when a tool call is superseded.
Every conversation is now a single straight line: when a request's turn
history diverges from what's on file (real OpenClaw traffic edits/
duplicates turns to keep provider-side prompt caches warm), the diverging
history mints its own independent conversation instead of forking a branch
inside the old one. Distinguished via anchorHasChild — whether the
reconnect anchor already has a recorded child.
Also fixes the actual production-blocking bug this surfaced: real agentic
traffic is full of byte-identical repeated turns (tool-polling loop output,
heartbeat acks — one real conversation had 28 duplicates of a single turn).
findReconnectMatch used to return on the first candidate anchor found for a
repeated turn's content hash — in practice the oldest, stalest occurrence —
whose recorded next-turn differs from the current request, so it looked
like a divergence on every single request instead of ever reconnecting.
Now every candidate anchor is evaluated and the one that verifiably extends
furthest wins (ties break toward the anchor with no recorded child).
Dashboard: /dashboard/conversations lists conversations by actual turn-node
count instead of request-touch count (a freshly-forked conversation can
carry hundreds of turns from a single insert but start at turn_count=1,
which wrongly excluded it from the old turn_count>=2 filter). The
conversation view loads the last 20 turns with a "Load more" button,
scrolls to bottom on open and stays pinned there via a ResizeObserver while
large/late-settling content keeps growing (a single requestAnimationFrame
undershoots for a page containing multi-KB tool-output turns), and resyncs
its "Goto latest request"/summary fields from the background list poll so
they don't go stale while the modal stays open (keyed off the id, not the
whole row object, so the poll-for-new-turns interval isn't reset every
tick by that resync).
X-ConversationId threading: chat.ts now passes the request's own
correlationId into resolveConversationId so new turn-chain nodes can be
tagged with a request identifier that exists before the call_logs row
itself does. usageHistory's in-memory pending-request state (byModel/
byAccount/details/pendingById) is reused across Next.js dev HMR module
re-evaluations via a globalThis singleton (same pattern as db/core.ts),
so a live poll against a request that started before a hot-reload doesn't
silently lose its partialAssistantText/isActive tracking.
The #7786 squash accidentally committed its worktree copy
(.claude/worktrees/feat-7786/**, since untracked) and leaked probe tests
(repro-8522/probe-9033/repro-8956 — each now green via #9355/#9385/#9354)
plus a stray changelog.d/fixes/9159-fix.plan.md describing an UNMERGED fix
(would fabricate a changelog entry at release time — removed; #9159's own
PR ships its fragment).
This restores the PR's actual deliverable at the right paths: the
management-auth terminology guide (now with the required MDX frontmatter),
its docs test (3/3 green) and its changelog fragment.
A Next.js standalone build writes a synthetic .build/next/package.json
({"type":"commonjs"}) that lacks a "name" field. The resolveProjectRoot()
walk-up was stopping at this marker instead of continuing to the real repo
root, making PROJECT_ROOT point at .build/next where no .git exists, which
caused the source-mode validation to report "Not a git repository."
Fix: only accept a package.json as a project-root marker when its parsed
content has a non-empty "name" field. Keep .git as a hard marker.
Add isValidPackageMarker() helper for testability.
Co-authored-by: diegosouzapw <diegosouzapw@users.noreply.github.com>
The 2026-08-05 TS7 rebaseline wrote 5000 measured WITHOUT the suppressions
file, but the PR gate (quality.yml lint:json + quality:collect) measures WITH
suppressions applied and reads 0 - so require-tighten failed every code PR
with delta 5000 > slack. Measured 0 on the pure tip ed122b2caf after the
stale-suppression prune (#9509). TS7 debt remains tracked in
config/quality/eslint-suppressions.json; any NEW warning outside it is an
immediate red, which is the policy.
release/v3.8.50 fails its own "No new ESLint warnings" gate right now,
independent of what any PR changes. Measured directly: a worktree
checked out at the current tip alone, no PR merged in, exits 2 with
"There are suppressions left that do not occur anymore." Cross-checked
against two unrelated open PRs (#9499, #9497) hitting the identical
failure, ruling out anything content-specific.
The mass-freeze commit that regenerated config/quality/eslint-suppressions.json
for the TypeScript 7 migration left one entry pointing at a violation
that no longer exists: src/lib/usage/providerLimits.ts no longer
triggers no-restricted-imports, but the suppression entry for it does.
ESLint's own suppression bookkeeping treats an unmatched entry as a
hard failure, separate from and in addition to real unsuppressed
errors.
--prune-suppressions removes exactly that one entry. It also drops the
informal "_comment" key documenting the freeze's origin, since ESLint's
suppression writer only round-trips file-keyed entries it manages
itself -- that context is not lost, it is still readable at the
mass-freeze commit (6b0e11e37) in git history.
This is one of two independent problems behind the same gate failure,
not the whole fix. Two files (tests/unit/issue-9407-gemini-web-validation-false-positive.test.ts,
tests/unit/v1-models-auth-leak-9320.test.ts) carry real, currently
unsuppressed no-explicit-any errors with no entry covering them at
all -- pruning cannot add what was never there. #9484 fixes those at
the source. Verified here that after this change alone, the gate
moves from exit 2 (stale suppressions) to the ordinary exit 1 those
two remaining errors cause -- both this and #9484 need to land before
the gate is green again.
Signed-off-by: Minxi Hou <houminxi@gmail.com>
Co-authored-by: Diego Rodrigues de Sa e Souza <diegosouza.pw@gmail.com>
Missing title/version/lastUpdated frontmatter broke the production build
(fumadocs-mdx requires title on every docs/**/*.md file).
Co-authored-by: diegosouzapw <diegosouzapw@users.noreply.github.com>
* fix(tests): clear the two base-reds on release/v3.8.50
Both sat on the release itself and turned every open PR red as soon as it
merged the release, independently of the PR's own content.
- tests/snapshots/provider/translate-path.json: #9064 (b0501642dd) added the
code-execution-2025-08-25 and skills-2025-10-02 beta flags to the Anthropic
header but did not regenerate the golden. provider-translate-path-golden
failed on the bare release tip — 2 pass / 1 fail with zero PRs boarded.
Regenerated; the diff is 24 lines, all the same header in 6 variants.
- tests/unit/v1-models-auth-leak-9320.test.ts:83: shipped a (k: any) in a file
new enough that eslint-suppressions.json does not cover it. With
@typescript-eslint/no-explicit-any as error under tests/, that one cast
failed 'No new ESLint warnings' for every PR. The callback parameter infers
correctly, so the cast was redundant.
Verified on the fix branch: eslint exit 0, typecheck:core exit 0, and both
test files green (5/5).
* fix(tests): drop a third unsuppressed any (gemini-web validation test)
A full-repo lint on this branch surfaced one more file in the same class:
tests/unit/issue-9407-gemini-web-validation-false-positive.test.ts:50 casts
(executor as any).testConnection. The file entered the release at f1ea77fd04
(23:28), newer than the frozen eslint-suppressions.json, so the cast is not
covered — and it alone kept 'No new ESLint warnings' red on this very PR.
testConnection is a declared public method on GeminiWebExecutor
(open-sse/executors/gemini-web.ts:359), so the cast was redundant rather than
load-bearing; removed outright.
eslint exit 0, typecheck:core exit 0, 15/15 across the three touched tests.
- Updated the quality baseline to set eslintWarnings value to 5000, reflecting the migration to TypeScript 7 and the new warning thresholds.
- Modified the test masking allowlist to account for removed tests and sources, ensuring proper tracking of deprecated features.
- Enhanced ESLint configuration to ignore additional directories containing non-source files.
- Removed the .npmignore file as its contents are now managed in package.json.
- Adjusted KimiWeb model configuration to correctly map K3 to the K2D5 scenario, reflecting changes in the underlying logic.
- Updated artifact packing policy to prevent nested node_modules from being published, ensuring a leaner package size.
- Added tests to verify the exclusion of node_modules from published artifacts and to ensure the integrity of the package.json files array.
Acquire admission once after API-key policy, preserve lazy raw-request snapshots, and bind lease settlement to JSON, SSE, abort, deadline, and failure lifecycles. Expose a low-cardinality health summary and preserve non-SSE Ollama errors unchanged.
Add bounded weighted admission with fair queuing, deadline and cancellation handling, exact lease accounting, and a default-shadow runtime. Keep asynchronous resource-pressure shedding as an independent safety fuse and bound request feature estimation.
Return a typed HTTP 504 for OmniRoute's per-target timer, keep fallback active, and classify the local timeout as request-scoped so it cannot degrade provider connection health.
Closed#9183 in favor of this branch at the operator's request. Folds in
the exact PR diff (verified byte-identical via `gh pr diff 9183`, applied
cleanly with `git apply`):
- Fixed output_index collisions between reasoning/message/tool-call items
in Responses API streaming, which caused clients to ignore tool calls.
- Fixed a race in chunk processing where tool calls and finish signals
were lost when they arrived in the same chunk as reasoning/text content.
- Enabled full processing of multi-choice chunks (previously truncated to
a single choice).
- Added reasoning_content capture/replay for DeepSeek-based models
(big-pickle), keyed off the real position in the next turn's replayed
messages array instead of a hardcoded index 0 — prevents history
corruption that caused models to lose context and stop prematurely.
- Added big-pickle to models recognized for native textual reasoning tags
so <think> blocks convert to reasoning items correctly.
- Improved Responses-to-Chat translation to group reasoning, content, and
tool calls into a single assistant turn, as strict OpenAI-compatible
upstreams require.
- Added a descriptive placeholder for encrypted Responses API reasoning
blocks so downgraded Chat API requests keep context.
Test plan:
- All 82 tests across reasoning-cache.test.ts, translator-helper-branches.test.ts,
translator-request-openai-responses.test.ts, and the 3 new test files
(responses-api-truncation.test.ts, responses-replay-fixes.test.ts,
responses-request-translation.test.ts) pass
- npm run typecheck:core — clean
- npm run check:file-size — chatCore.ts (5024->5032) and
translator/response/openai-responses.ts (1174->1180) rebaselined,
both cohesive additions at the two reasoning-cache capture call sites and
the turn-grouping fix; tests/unit/reasoning-cache.test.ts rebaselined at
1035 (crosses the 1000-line new-file test cap, entirely this fold's diff)
lint-staged's prettier pass on the prior commit reformatted a pre-existing
multi-line ternary (title attribute) past the 100-char print width,
growing the file 1256->1260 lines with no functional change. CI's
check:file-size gate caught the drift (frozen cap can only shrink).
The 8KB cap on logged request/response bodies (open-sse/handlers/chatCore/
logTruncation.ts::truncateForLog()) was hardcoded — trivially exceeded by
any real multi-turn agentic conversation, meaning the dashboard's "Full
Conversation" panel could only ever show a placeholder instead of the
actual messages for nearly every logged row of any conversation with real
substance.
- Added CHAT_LOG_MAX_BODY_KB env var (src/lib/logEnv.ts::
getChatLogMaxBodyBytes()), default 1024 KB (1MB) — a 128x bump from the
old hardcoded 8KB — following the same configurable-limit pattern as the
sibling CHAT_LOG_TEXT_LIMIT/CHAT_LOG_ARRAY_TAIL_ITEMS/etc. vars.
- Documented in .env.example and docs/reference/ENVIRONMENT.md (both
required — tests/unit/issue-7793-env-doc-sync-repro.test.ts and
check-env-doc-sync.test.ts enforce this pairing).
Found and fixed a real bug while wiring this up: estimateSize.ts's
estimateSizeFast() had its own hardcoded 256KB early-exit optimization
("stop walking once bytes clearly exceeds the caller's threshold"), so it
could never report a size above ~256KB regardless of the object's true
size — meaning any caller threshold configured above 256KB (like the new
1MB default) was silently unreachable; every payload would look "under
threshold" and truncation would never fire, letting arbitrarily large
bodies through unbounded (the opposite of intended, and a real memory-
protection regression). Fixed by giving estimateSizeFast() a parameterized
earlyExitAt (default unchanged at 262144, so isSmallEnoughForSemanticCache's
existing behavior is untouched), with truncateForLog() now passing its own
configured getChatLogMaxBodyBytes() value through.
Also adds a "Conversation" field to the request detail panel's metadata
grid (last, after "Combo"), showing the request's conversation id
(sessionTag) for quick reference/copy.
Test plan:
- New TDD tests for both fixes (Responses API messageCount capture — from
the previous commit — and the estimateSizeFast earlyExitAt parameter),
confirmed failing before each fix and passing after
- Bumped the two truncateForLog test fixtures that were sized against the
old 8KB threshold so they still genuinely exceed the new ~1MB default
- npm run typecheck:core / npm run lint / npm run check:file-size — clean
- npm run test:unit — 27132 tests, same 4 pre-existing/unrelated failures
as the last confirmed-clean run (no new regressions) — including the two
env/doc-sync contract tests that initially caught the missing
CHAT_LOG_MAX_BODY_KB documentation, now fixed
- npm run test:vitest — 291/291 passed
- Rebuilt and redeployed to omniroute-dev
Follow-up to the earlier truncated-request-body transcript fix, found by
re-checking the live dashboard: a specific /v1/responses request still
showed nothing for its own turn even though its body genuinely was
truncated by logTruncation.ts's truncateForLog().
Root cause (two parts):
1. truncateForLog() only counted messages[] (Chat Completions) and
contents[] (Gemini) — never input[] (Responses API) — so a truncated
Responses API request's summary carried NO count field at all.
2. buildMultiRowConversation()'s earlier fix defaulted an unknown count to
0, which silently produced "0 new turns" instead of surfacing that the
count was simply unavailable — same end symptom as the original bug
(nothing shown) despite the row being genuinely truncated.
Fixes:
- logTruncation.ts now also sets messageCount for input[] bodies (root
fix, only helps requests logged from here forward).
- multiRowConversation.ts now distinguishes "known count" (existing
specific "N messages not shown" placeholder + correct bookkeeping) from
"unknown count" (a generic placeholder, since we can't safely diff
against previousTotal without a real number) — needed for the
already-persisted historical data on omniroute-dev that will never
retroactively get a messageCount.
Test plan:
- New TDD tests for both gaps (Responses API count capture in
logTruncation, unknown-count placeholder in multiRowConversation),
confirmed failing before each fix and passing after
- npm run typecheck:core / npm run lint / npm run check:file-size — clean
- npm run test:unit — 27223 tests, same 4 pre-existing/unrelated failures
as the last confirmed-clean run (no new regressions)
- npm run test:vitest — 291/291 passed
- Rebuilt and redeployed to omniroute-dev
vulnCount 10->22 (osv-scanner, measured in PR #9439's own CI run). Not a
dependency change from this PR — `git diff upstream/release/v3.8.50 HEAD --
package.json package-lock.json` is empty, neither file was touched anywhere
in this branch. This is the documented "CVE variance" scenario from
_osv_flip_blocking_2026_06_16_v3827: newly-disclosed CVEs in already-present
transitive dependencies accumulated on release/v3.8.50 (the vuln ratchet
apparently doesn't run on every direct commit to the release branch, same
gap already documented for check:file-size) and only surfaced here because
this PR's rebase pulled in the current release tip. Re-baselined per that
entry's own prescribed remedy; follow-up dependency-bump PR should re-tighten
once the specific advisories are enumerated with osv-scanner installed.
CI failures on PR #9439:
1. Migration version collision: upstream/release/v3.8.50 landed
134_proxy_logs_egress_ip.sql (#9291) after this branch's original rebase,
colliding with this branch's own 134_agentic_conversations.sql. Renamed
to 135_agentic_conversations.sql (re-rebased onto the current tip first).
2. check:file-size: rebaselined the files this PR's own feature growth pushed
over their frozen/cap thresholds (RequestLoggerDetail.tsx, RequestTimeline.tsx,
RequestLoggerV2.tsx, chat.ts, chatCore.ts — see the new
_rebaseline_2026_08_04_9439 entry for the itemized justification) plus
open-sse/executors/base.ts, which was already over its own frozen baseline
on release/v3.8.50 independent of this branch (confirmed via `git diff
upstream/release/v3.8.50 HEAD -- open-sse/executors/base.ts` — empty).
3. A third real bug, found by re-checking the live dashboard after the
previous round's fixes: a request with a long real conversation chain
showed only its own response in the "Full Conversation" panel. Root
cause: open-sse/handlers/chatCore/logTruncation.ts's truncateForLog()
replaces any request body over ~8KB with a bare {_truncated,
_originalBytes, messageCount, ...} summary, dropping messages/input
entirely — the norm, not the exception, for any conversation with real
substance. buildRequestTurns() legitimately found nothing to parse, so
the transcript silently rendered only that row's response, and (more
subtly) every subsequent row's delta-slicing bookkeeping was computed
against the wrong running total (0 instead of the row's real turn
count), which would have corrupted the rest of the reconstruction too
for any longer chain built on top of a truncated row.
Fix: buildMultiRowConversation now detects a truncated request body via
its messageCount field, uses that count for delta bookkeeping instead of
silently treating it as zero, and renders one explicit placeholder turn
("N messages not shown — the request body was too large to log")
instead of just disappearing.
Test plan:
- New regression tests for the truncation case (single truncated row, and
a truncated row followed by a real row to verify bookkeeping stays
correct)
- npm run check:migration-numbering / check:file-size — clean
- npm run typecheck:core / npm run lint — clean
- npm run test:unit — 27086 tests, only 4 failures remain (down from 18 —
2 were fixed by the newer upstream commits pulled in by this re-rebase),
all independently pre-existing/unrelated (ServiceSupervisor timing,
monaco-editor path, npm-pack)
- npm run test:vitest — 291/291 passed
Two independent bugs found during further live verification of the
conversation-tracking feature:
1. (#9315) The dashboard's "Provider Response" panel showed a stale,
incomplete snapshot for long streamed responses. Root cause:
open-sse/utils/stream.ts reconstructed the summary from
buildStreamSummaryFromEvents(providerPayloadCollector.getEvents(), ...)
— but getEvents() only returns whatever survived the collector's
maxEvents/maxBytes cap, so once a stream exceeded it (easy with a
reasoning + tool-calling model), everything after the cutoff (final
finish_reason, tool_calls, rest of reasoning_content, usage) was
silently dropped from the reconstruction, even though the client
actually received the correct, complete response.
Fix: streamPayloadCollector.ts's per-format summary builders
(buildOpenAISummary/buildResponsesSummary/buildClaudeSummary/
buildGeminiSummary) are now also available as incremental reducers
(createXReducer: ingest one chunk at a time, finalize at the end).
createStructuredSSECollector accepts a format + fallbackModel and feeds
the reducer on every push() — including chunks that get dropped from
the retained event array once the cap is hit — via a new getSummary()
method. stream.ts's 3 call sites now use collector.getSummary() instead
of reconstructing from the (possibly truncated) getEvents().
2. Conversation continuation never actually worked for real agentic CLI
traffic. Root cause: computeFingerprintHash/hashTurnsBounded anchored
conversation identity partly on the system message's text — but real
coding-agent CLIs (Claude Code, opencode, etc.) commonly regenerate the
system prompt on every single request with live context (timestamp,
cwd, git status...). That volatility alone broke both the fingerprint
bucket lookup and the prefix-hash continuation check, so every request
minted a brand new conversation id even though apiKeyId/model/toolNames
and the actual user/assistant history were an unbroken, growing
continuation. Confirmed live: 28 consecutive requests from one real,
growing session, each recorded as its own turn_count=1 conversation —
which is also why /dashboard/conversations appeared empty (nothing ever
reached turn_count >= 2) and why an individual timeline/log entry only
ever showed a single turn.
Fix: both computeFingerprintHash's identity anchor and
hashTurnsBounded's head/tail projection now exclude the system message
entirely, so a regenerated-every-turn system prompt can no longer break
continuation detection. New regression test reproduces the exact
scenario (system prompt differs each turn, everything else constant)
and confirms the second request is now recognized as a continuation.
Also fixed while touching hashTurnsBounded: an accidental stray control
character (SOH, 0x01) in the internal join() separator — cosmetic (any
consistent separator produces a valid hash) but worth cleaning up since it
was already being edited; no stored data depended on the old format since
the continuation bug meant turn_count never reached 2 in production.
Test plan:
- New TDD regression tests for both bugs (stream-payload-collector.test.ts,
conversationTracker.test.ts), confirmed failing before the fix and
passing after
- npm run typecheck:core / npm run lint — clean
- npm run test:unit — 26983 tests, 18 failures, all independently confirmed
pre-existing on release/v3.8.50 (reproduced identically against the
clean base commit)
- npm run test:vitest — 291/291 passed
- Rebuilt and redeployed to omniroute-dev; health check + DB migration
verified
Missing title/version/lastUpdated frontmatter broke the Next.js/fumadocs
build entirely (Turbopack: "invalid frontmatter... expected string, received
undefined"), pre-existing on release/v3.8.50 as of #9323 and unrelated to
this branch's feature work — discovered because it blocked building this
branch's image for deploy.
The new "Conversations" sidebar entry and "Conversation" logs column needed
their Vietnamese strings (Vietnamese is the reference locale requiring full
translation, no __MISSING__ placeholders) and the sidebar structure
assertions needed the new item added to their expected lists.
Every agentic chat request now gets a conversation id (X-ConversationId
response header), and OmniRoute detects when a follow-up request continues
the same conversation via fingerprint + bounded prefix-hash matching, with a
strict-growth invariant to prevent false merges between independent
single-shot requests.
Dashboard changes:
- /dashboard/logs: toggleable Conversation column
- /dashboard/logs/timeline: same-conversation requests share a timeline lane,
connected by an arrow, with a configurable lane-reuse window
- Request detail panel: new "Full Conversation" transcript above the raw SSE
event stream, with Markdown rendering, per-turn timestamps, turn-relative
view (only turns up to the one you opened, with a jump-to-next link),
click-any-turn-to-open-its-log navigation, and live auto-refresh (with an
auto-follow toggle, matching the event stream's autoscroll pattern) that
rebuilds the transcript in real time from the in-flight SSE chunk buffer
while a request is still streaming
- New /dashboard/conversations page listing only conversations with 2+ turns
- Configurable auto-refresh intervals on both the timeline and conversations
list pages
Also fixes a pre-existing bug where the timeline view never showed SSE/
stream-chunk events or respected email-masking, because RequestTimeline.tsx
hardcoded debugEnabled/emailsVisible instead of reading the same
server-side/store state RequestLoggerV2.tsx already used, and makes the
request detail panel and conversations list responsive on mobile.
