36 lines
2.1 KiB
Markdown
36 lines
2.1 KiB
Markdown
# Autoresearch: tauri-chat-active-history
|
|
|
|
## Objective
|
|
Fix the desktop chat flow so sending a message with no selected chat creates and selects the new chat immediately, keeps the live generation attached to that new chat, and preserves message history when revisiting generated chats.
|
|
|
|
## Metrics
|
|
- **Primary**: `chat_history_score` (%, higher is better)
|
|
- **Secondary**: `app_send_flow_passed`, `chat_switch_abort_guard_passed`, `frontend_tests_passed`, `frontend_build_passed`
|
|
|
|
## How to Run
|
|
`./autoresearch.sh` - outputs `METRIC name=number` lines.
|
|
|
|
## Files in Scope
|
|
- `tauri-app/src/components/ChatView.tsx` - active chat selection, request lifecycle, and message reload behavior.
|
|
- `tauri-app/src/components/ChatView.test.tsx` - request-race and chat switching regressions.
|
|
- `tauri-app/src/App.test.tsx` - app-level send/create/select/history regression coverage.
|
|
- `autoresearch.md` - current objective and experiment notes.
|
|
- `autoresearch.sh` - focused verification harness for this segment.
|
|
- `autoresearch.jsonl` - experiment ledger.
|
|
- `autoresearch-dashboard.md` - current segment dashboard.
|
|
- `experiments/worklog.md` - narrative log of runs and lessons.
|
|
|
|
## Off Limits
|
|
- Rust backend/runtime crates for this bug.
|
|
- Runtime settings/model-library code unrelated to chat creation/history.
|
|
|
|
## Constraints
|
|
- Keep saved-chat switching protection: switching to another chat while a previous request is still running must still abort the stale request.
|
|
- Do not regress the standard saved-chat load path.
|
|
- Keep verification frontend-only unless a new cross-layer dependency appears.
|
|
|
|
## What's Been Tried
|
|
- The first saved-chat regression fix aborted every in-flight request on any `chatId` change. That protected switching to another saved chat, but it also canceled the request that had just created a brand-new chat (`null -> newChatId`).
|
|
- The correct distinction is between switching away to a different chat vs. transitioning into the same chat that originated the still-running request.
|
|
- The kept direction is to track the pending request chat id and only abort/reset transient UI when the user truly leaves that pending chat.
|