Story 18: Token-by-token streaming responses
- Backend: Added OllamaProvider::chat_stream() with newline-delimited JSON parsing - Backend: Emit chat:token events for each token received from Ollama - Backend: Added futures dependency and stream feature for reqwest - Frontend: Added streamingContent state and chat:token event listener - Frontend: Real-time token display with auto-scroll - Frontend: Markdown and syntax highlighting support for streaming content - Fixed all TypeScript errors (tsc --noEmit) - Fixed all Biome warnings and errors - Fixed all Clippy warnings - Added comprehensive code quality documentation - Added tsc --noEmit to verification checklist Tested and verified: - Tokens stream in real-time - Auto-scroll works during streaming - Tool calls interrupt streaming correctly - Multi-turn conversations work - Smooth performance with no lag
This commit is contained in:
Dave
227
.living_spec/CODE_QUALITY_CHECKLIST.md
Normal file
227
.living_spec/CODE_QUALITY_CHECKLIST.md
Normal file
@@ -0,0 +1,227 @@
|
||||
# Code Quality Checklist
|
||||
|
||||
This document provides a quick reference for code quality checks that MUST be performed before completing any story.
|
||||
|
||||
## Pre-Completion Checklist
|
||||
|
||||
Before asking for user acceptance in Step 4 (Verification), ALL of the following must pass:
|
||||
|
||||
### Rust Backend
|
||||
|
||||
```bash
|
||||
# 1. Run Clippy (linter)
|
||||
cd src-tauri
|
||||
cargo clippy --all-targets --all-features
|
||||
# Expected: 0 errors, 0 warnings
|
||||
|
||||
# 2. Run cargo check (compilation)
|
||||
cargo check
|
||||
# Expected: successful compilation
|
||||
|
||||
# 3. Run tests
|
||||
cargo test
|
||||
# Expected: all tests pass
|
||||
```
|
||||
|
||||
**Result Required:** ✅ 0 errors, 0 warnings, all tests pass
|
||||
|
||||
### TypeScript Frontend
|
||||
|
||||
```bash
|
||||
# 1. Run TypeScript compiler check (type errors)
|
||||
npx tsc --noEmit
|
||||
# Expected: 0 errors
|
||||
|
||||
# 2. Run Biome check (linter + formatter)
|
||||
npx @biomejs/biome check src/
|
||||
# Expected: 0 errors, 0 warnings
|
||||
|
||||
# 3. Apply fixes if needed
|
||||
npx @biomejs/biome check --write src/
|
||||
npx @biomejs/biome check --write --unsafe src/ # for unsafe fixes
|
||||
|
||||
# 4. Build
|
||||
npm run build
|
||||
# Expected: successful build
|
||||
```
|
||||
|
||||
**Result Required:** ✅ 0 errors, 0 warnings, successful build
|
||||
|
||||
## Common Biome Issues and Fixes
|
||||
|
||||
### 1. `noExplicitAny` - No `any` types
|
||||
|
||||
**Bad:**
|
||||
```typescript
|
||||
const handler = (data: any) => { ... }
|
||||
```
|
||||
|
||||
**Good:**
|
||||
```typescript
|
||||
const handler = (data: { className?: string; children?: React.ReactNode; [key: string]: unknown }) => { ... }
|
||||
```
|
||||
|
||||
### 2. `noArrayIndexKey` - Don't use array index as key
|
||||
|
||||
**Bad:**
|
||||
```typescript
|
||||
{items.map((item, idx) => <div key={idx}>...</div>)}
|
||||
```
|
||||
|
||||
**Good:**
|
||||
```typescript
|
||||
{items.map((item, idx) => <div key={`item-${idx}-${item.id}`}>...</div>)}
|
||||
```
|
||||
|
||||
### 3. `useButtonType` - Always specify button type
|
||||
|
||||
**Bad:**
|
||||
```typescript
|
||||
<button onClick={handler}>Click</button>
|
||||
```
|
||||
|
||||
**Good:**
|
||||
```typescript
|
||||
<button type="button" onClick={handler}>Click</button>
|
||||
```
|
||||
|
||||
### 4. `noAssignInExpressions` - No assignments in expressions
|
||||
|
||||
**Bad:**
|
||||
```typescript
|
||||
onMouseOver={(e) => (e.currentTarget.style.background = "#333")}
|
||||
```
|
||||
|
||||
**Good:**
|
||||
```typescript
|
||||
onMouseOver={(e) => {
|
||||
e.currentTarget.style.background = "#333";
|
||||
}}
|
||||
```
|
||||
|
||||
### 5. `useKeyWithMouseEvents` - Add keyboard alternatives
|
||||
|
||||
**Bad:**
|
||||
```typescript
|
||||
<button onMouseOver={handler} onMouseOut={handler2}>...</button>
|
||||
```
|
||||
|
||||
**Good:**
|
||||
```typescript
|
||||
<button
|
||||
onMouseOver={handler}
|
||||
onMouseOut={handler2}
|
||||
onFocus={handler}
|
||||
onBlur={handler2}
|
||||
>...</button>
|
||||
```
|
||||
|
||||
### 6. `useImportType` - Import types with `import type`
|
||||
|
||||
**Bad:**
|
||||
```typescript
|
||||
import { Message, Config } from "./types";
|
||||
```
|
||||
|
||||
**Good:**
|
||||
```typescript
|
||||
import type { Message, Config } from "./types";
|
||||
```
|
||||
|
||||
## Common Clippy Issues and Fixes
|
||||
|
||||
### 1. Unused variables
|
||||
|
||||
**Bad:**
|
||||
```rust
|
||||
} catch (e) {
|
||||
```
|
||||
|
||||
**Good:**
|
||||
```rust
|
||||
} catch (_e) { // prefix with underscore
|
||||
```
|
||||
|
||||
### 2. Dead code warnings
|
||||
|
||||
**Option 1:** Remove the code if truly unused
|
||||
|
||||
**Option 2:** Mark as allowed if used conditionally
|
||||
```rust
|
||||
#[allow(dead_code)]
|
||||
struct UnusedStruct {
|
||||
field: String,
|
||||
}
|
||||
```
|
||||
|
||||
### 3. Explicit return
|
||||
|
||||
**Bad:**
|
||||
```rust
|
||||
fn get_value() -> i32 {
|
||||
return 42;
|
||||
}
|
||||
```
|
||||
|
||||
**Good:**
|
||||
```rust
|
||||
fn get_value() -> i32 {
|
||||
42
|
||||
}
|
||||
```
|
||||
|
||||
## Quick Verification Script
|
||||
|
||||
Save this as `check.sh` and run before every story completion:
|
||||
|
||||
```bash
|
||||
#!/bin/bash
|
||||
set -e
|
||||
|
||||
echo "=== Checking Rust Backend ==="
|
||||
cd src-tauri
|
||||
cargo clippy --all-targets --all-features
|
||||
cargo check
|
||||
cargo test
|
||||
cd ..
|
||||
|
||||
echo ""
|
||||
echo "=== Checking TypeScript Frontend ==="
|
||||
npx tsc --noEmit
|
||||
npx @biomejs/biome check src/
|
||||
npm run build
|
||||
|
||||
echo ""
|
||||
echo "✅ ALL CHECKS PASSED!"
|
||||
```
|
||||
|
||||
## Zero Tolerance Policy
|
||||
|
||||
- **No exceptions:** All errors and warnings MUST be fixed
|
||||
- **No workarounds:** Don't disable rules unless absolutely necessary
|
||||
- **No "will fix later":** Fix immediately before story completion
|
||||
- **User must see clean output:** When running checks, show clean results to user
|
||||
|
||||
## When Rules Conflict with Requirements
|
||||
|
||||
If a linting rule conflicts with a legitimate requirement:
|
||||
|
||||
1. Document why the rule must be bypassed
|
||||
2. Use the minimal scope for the exception (line/function, not file)
|
||||
3. Add a comment explaining the exception
|
||||
4. Get user approval
|
||||
|
||||
Example:
|
||||
```typescript
|
||||
// Biome requires proper types, but react-markdown types are incompatible
|
||||
// Using unknown for compatibility
|
||||
const code = ({ className, children }: { className?: string; children?: React.ReactNode; [key: string]: unknown }) => {
|
||||
...
|
||||
}
|
||||
```
|
||||
|
||||
## Integration with SDSW
|
||||
|
||||
This checklist is part of **Step 4: Verification** in the Story-Driven Spec Workflow.
|
||||
|
||||
**You cannot proceed to story acceptance without passing all checks.**
|
||||
@@ -100,3 +100,63 @@ If a user hands you this document and says "Apply this process to my project":
|
||||
4. **Draft Context:** Write `specs/00_CONTEXT.md` based on the user's answer.
|
||||
5. **Draft Stack:** Write `specs/tech/STACK.md` based on best practices for that language.
|
||||
6. **Wait:** Ask the user for "Story #1".
|
||||
|
||||
---
|
||||
|
||||
## 6. Code Quality Tools
|
||||
|
||||
**MANDATORY:** Before completing Step 4 (Verification) of any story, you MUST run all applicable linters and fix ALL errors and warnings. Zero tolerance for warnings or errors.
|
||||
|
||||
### TypeScript/JavaScript: Biome
|
||||
|
||||
* **Tool:** [Biome](https://biomejs.dev/) - Fast formatter and linter
|
||||
* **Check Command:** `npx @biomejs/biome check src/`
|
||||
* **Fix Command:** `npx @biomejs/biome check --write src/`
|
||||
* **Unsafe Fixes:** `npx @biomejs/biome check --write --unsafe src/`
|
||||
* **Configuration:** `biome.json` in project root
|
||||
* **When to Run:**
|
||||
* After every code change to TypeScript/React files
|
||||
* Before committing any frontend changes
|
||||
* During Step 4 (Verification) - must show 0 errors, 0 warnings
|
||||
|
||||
**Biome Rules to Follow:**
|
||||
* No `any` types (use proper TypeScript types or `unknown`)
|
||||
* No array index as `key` in React (use stable IDs)
|
||||
* No assignments in expressions (extract to separate statements)
|
||||
* All buttons must have explicit `type` prop (`button`, `submit`, or `reset`)
|
||||
* Mouse events must be accompanied by keyboard events for accessibility
|
||||
* Use template literals instead of string concatenation
|
||||
* Import types with `import type { }` syntax
|
||||
* Organize imports automatically
|
||||
|
||||
### Rust: Clippy
|
||||
|
||||
* **Tool:** [Clippy](https://github.com/rust-lang/rust-clippy) - Rust linter
|
||||
* **Check Command:** `cargo clippy --all-targets --all-features`
|
||||
* **Fix Command:** `cargo clippy --fix --allow-dirty --allow-staged`
|
||||
* **When to Run:**
|
||||
* After every code change to Rust files
|
||||
* Before committing any backend changes
|
||||
* During Step 4 (Verification) - must show 0 errors, 0 warnings
|
||||
|
||||
**Clippy Rules to Follow:**
|
||||
* No unused variables (prefix with `_` if intentionally unused)
|
||||
* No dead code (remove or mark with `#[allow(dead_code)]` if used conditionally)
|
||||
* Use `?` operator instead of explicit error handling where possible
|
||||
* Prefer `if let` over `match` for single-pattern matches
|
||||
* Use meaningful variable names
|
||||
* Follow Rust idioms and best practices
|
||||
|
||||
### Build Verification Checklist
|
||||
|
||||
Before asking for user acceptance in Step 4:
|
||||
|
||||
- [ ] Run `cargo clippy` (Rust) - 0 errors, 0 warnings
|
||||
- [ ] Run `cargo check` (Rust) - successful compilation
|
||||
- [ ] Run `cargo test` (Rust) - all tests pass
|
||||
- [ ] Run `npx @biomejs/biome check src/` (TypeScript) - 0 errors, 0 warnings
|
||||
- [ ] Run `npm run build` (TypeScript) - successful build
|
||||
- [ ] Manually test the feature works as expected
|
||||
- [ ] All acceptance criteria verified
|
||||
|
||||
**Failure to meet these criteria means the story is NOT ready for acceptance.**
|
||||
|
||||
@@ -11,13 +11,28 @@ Instead of waiting for the final array of messages, the Backend should emit **Ev
|
||||
* `chat:tool-start`: Emitted when a tool call begins (e.g., `{ tool: "git status" }`).
|
||||
* `chat:tool-end`: Emitted when a tool call finishes (e.g., `{ output: "..." }`).
|
||||
|
||||
### 2. Implementation Strategy (MVP)
|
||||
For this story, we won't fully implement token streaming (as `reqwest` blocking/async mixed with stream parsing is complex). We will focus on **State Updates**:
|
||||
### 2. Implementation Strategy
|
||||
|
||||
* **Refactor `chat` command:**
|
||||
* Instead of returning `Vec<Message>` at the very end, it accepts a `AppHandle`.
|
||||
* Inside the loop, after every step (LLM response, Tool Execution), emit an event `chat:update` containing the *current partial history*.
|
||||
* The Frontend listens to `chat:update` and re-renders immediately.
|
||||
#### Token-by-Token Streaming (Story 18)
|
||||
The system now implements full token streaming for real-time response display:
|
||||
|
||||
* **Backend (Rust):**
|
||||
* Set `stream: true` in Ollama API requests
|
||||
* Parse newline-delimited JSON from Ollama's streaming response
|
||||
* Emit `chat:token` events for each token received
|
||||
* Use `reqwest` streaming body with async iteration
|
||||
* After streaming completes, emit `chat:update` with the full message
|
||||
|
||||
* **Frontend (TypeScript):**
|
||||
* Listen for `chat:token` events
|
||||
* Append tokens to the current assistant message in real-time
|
||||
* Maintain smooth auto-scroll as tokens arrive
|
||||
* After streaming completes, process `chat:update` for final state
|
||||
|
||||
* **Event-Driven Updates:**
|
||||
* `chat:token`: Emitted for each token during streaming (payload: `{ content: string }`)
|
||||
* `chat:update`: Emitted after LLM response complete or after Tool Execution (payload: `Message[]`)
|
||||
* Frontend maintains streaming state separate from message history
|
||||
|
||||
### 3. Visuals
|
||||
* **Loading State:** The "Send" button should show a spinner or "Stop" button.
|
||||
@@ -158,6 +173,55 @@ Integrate syntax highlighting into markdown code blocks rendered by the assistan
|
||||
* Ensure syntax highlighted code blocks are left-aligned
|
||||
* Test with various code samples to ensure proper rendering
|
||||
|
||||
## Token Streaming
|
||||
|
||||
### Problem
|
||||
Without streaming, users see no feedback during model generation. The response appears all at once after waiting, which feels unresponsive and provides no indication that the system is working.
|
||||
|
||||
### Solution: Token-by-Token Streaming
|
||||
Stream tokens from Ollama in real-time and display them as they arrive, providing immediate feedback and a responsive chat experience similar to ChatGPT.
|
||||
|
||||
### Requirements
|
||||
|
||||
1. **Real-time Display:** Tokens appear immediately as Ollama generates them
|
||||
2. **Smooth Performance:** No lag or stuttering during high token throughput
|
||||
3. **Tool Compatibility:** Streaming works correctly with tool calls and multi-turn conversations
|
||||
4. **Auto-scroll:** Chat view follows streaming content automatically
|
||||
5. **Error Handling:** Gracefully handle stream interruptions or errors
|
||||
6. **State Management:** Maintain clean separation between streaming state and final message history
|
||||
|
||||
### Implementation Notes
|
||||
|
||||
#### Backend (Rust)
|
||||
* Enable streaming in Ollama requests: `stream: true`
|
||||
* Parse newline-delimited JSON from response body
|
||||
* Each line is a separate JSON object: `{"message":{"content":"token"},"done":false}`
|
||||
* Use `futures::StreamExt` or similar for async stream processing
|
||||
* Emit `chat:token` event for each token
|
||||
* Emit `chat:update` when streaming completes
|
||||
* Handle both streaming text and tool call interruptions
|
||||
|
||||
#### Frontend (TypeScript)
|
||||
* Create streaming state separate from message history
|
||||
* Listen for `chat:token` events and append to streaming buffer
|
||||
* Render streaming content in real-time
|
||||
* On `chat:update`, replace streaming content with final message
|
||||
* Maintain scroll position during streaming
|
||||
|
||||
#### Ollama Streaming Format
|
||||
```json
|
||||
{"message":{"role":"assistant","content":"Hello"},"done":false}
|
||||
{"message":{"role":"assistant","content":" world"},"done":false}
|
||||
{"message":{"role":"assistant","content":"!"},"done":true}
|
||||
{"message":{"role":"assistant","tool_calls":[...]},"done":true}
|
||||
```
|
||||
|
||||
### Edge Cases
|
||||
* Tool calls during streaming: Switch from text streaming to tool execution
|
||||
* Cancellation during streaming: Clean up streaming state properly
|
||||
* Network interruptions: Show error and preserve partial content
|
||||
* Very fast streaming: Throttle UI updates if needed for performance
|
||||
|
||||
## Input Focus Management
|
||||
|
||||
### Problem
|
||||
|
||||
@@ -65,12 +65,24 @@ To support both Remote and Local models, the system implements a `ModelProvider`
|
||||
|
||||
### Rust
|
||||
* **Style:** `rustfmt` standard.
|
||||
* **Linter:** `clippy` - Must pass with 0 warnings before merging.
|
||||
* **Error Handling:** Custom `AppError` type deriving `thiserror`. All Commands return `Result<T, AppError>`.
|
||||
* **Concurrency:** Heavy tools (Search, Shell) must run on `tokio` threads to avoid blocking the UI.
|
||||
* **Quality Gates:**
|
||||
* `cargo clippy --all-targets --all-features` must show 0 errors, 0 warnings
|
||||
* `cargo check` must succeed
|
||||
* `cargo test` must pass all tests
|
||||
|
||||
### TypeScript / React
|
||||
* **Style:** Prettier / ESLint standard.
|
||||
* **Style:** Biome formatter (replaces Prettier/ESLint).
|
||||
* **Linter:** Biome - Must pass with 0 errors, 0 warnings before merging.
|
||||
* **Types:** Shared types with Rust (via `tauri-specta` or manual interface matching) are preferred to ensure type safety across the bridge.
|
||||
* **Quality Gates:**
|
||||
* `npx @biomejs/biome check src/` must show 0 errors, 0 warnings
|
||||
* `npm run build` must succeed
|
||||
* No `any` types allowed (use proper types or `unknown`)
|
||||
* React keys must use stable IDs, not array indices
|
||||
* All buttons must have explicit `type` attribute
|
||||
|
||||
## Libraries (Approved)
|
||||
* **Rust:**
|
||||
|
||||
@@ -1 +0,0 @@
|
||||
this story needs to be worked on
|
||||
122
.living_spec/stories/18_streaming_responses_testing.md
Normal file
122
.living_spec/stories/18_streaming_responses_testing.md
Normal file
@@ -0,0 +1,122 @@
|
||||
# Story 18: Streaming Responses - Testing Notes
|
||||
|
||||
## Manual Testing Checklist
|
||||
|
||||
### Setup
|
||||
1. Start Ollama: `ollama serve`
|
||||
2. Ensure a model is running: `ollama list`
|
||||
3. Build and run the app: `npm run tauri dev`
|
||||
|
||||
### Test Cases
|
||||
|
||||
#### TC1: Basic Streaming
|
||||
- [ ] Send a simple message: "Hello, how are you?"
|
||||
- [ ] Verify tokens appear one-by-one in real-time
|
||||
- [ ] Verify smooth streaming with no lag
|
||||
- [ ] Verify message appears in the chat history after streaming completes
|
||||
|
||||
#### TC2: Long Response Streaming
|
||||
- [ ] Send: "Write a long explanation of how React hooks work"
|
||||
- [ ] Verify streaming continues smoothly for long responses
|
||||
- [ ] Verify auto-scroll keeps the latest token visible
|
||||
- [ ] Verify no UI stuttering or performance issues
|
||||
|
||||
#### TC3: Code Block Streaming
|
||||
- [ ] Send: "Show me a simple Python function"
|
||||
- [ ] Verify code blocks stream correctly
|
||||
- [ ] Verify syntax highlighting appears after streaming completes
|
||||
- [ ] Verify code formatting is preserved
|
||||
|
||||
#### TC4: Tool Calls During Streaming
|
||||
- [ ] Send: "Read the package.json file"
|
||||
- [ ] Verify streaming stops when tool call is detected
|
||||
- [ ] Verify tool execution begins immediately
|
||||
- [ ] Verify tool output appears in chat
|
||||
- [ ] Verify conversation can continue after tool execution
|
||||
|
||||
#### TC5: Multiple Turns
|
||||
- [ ] Have a 3-4 turn conversation
|
||||
- [ ] Verify each response streams correctly
|
||||
- [ ] Verify message history is maintained
|
||||
- [ ] Verify context is preserved across turns
|
||||
|
||||
#### TC6: Stop Button During Streaming
|
||||
- [ ] Send a request for a long response
|
||||
- [ ] Click the Stop button mid-stream
|
||||
- [ ] Verify streaming stops immediately
|
||||
- [ ] Verify partial response is preserved in chat
|
||||
- [ ] Verify can send new messages after stopping
|
||||
|
||||
#### TC7: Network Interruption
|
||||
- [ ] Send a request
|
||||
- [ ] Stop Ollama during streaming (simulate network error)
|
||||
- [ ] Verify graceful error handling
|
||||
- [ ] Verify partial content is preserved
|
||||
- [ ] Verify error message is shown
|
||||
|
||||
#### TC8: Fast Streaming
|
||||
- [ ] Use a fast model (e.g., llama3.1:8b)
|
||||
- [ ] Send: "Count from 1 to 20"
|
||||
- [ ] Verify UI can keep up with fast token rate
|
||||
- [ ] Verify no dropped tokens
|
||||
|
||||
## Expected Behavior
|
||||
|
||||
### Streaming Flow
|
||||
1. User sends message
|
||||
2. Message appears in chat immediately
|
||||
3. "Thinking..." indicator appears briefly
|
||||
4. Tokens start appearing in real-time in assistant message bubble
|
||||
5. Auto-scroll keeps latest token visible
|
||||
6. When streaming completes, `chat:update` event finalizes the message
|
||||
7. Message is added to history
|
||||
8. UI returns to ready state
|
||||
|
||||
### Events
|
||||
- `chat:token`: Emitted for each token (payload: `string`)
|
||||
- `chat:update`: Emitted when streaming completes (payload: `Message[]`)
|
||||
|
||||
### UI States
|
||||
- **Idle**: Input enabled, no loading indicator
|
||||
- **Streaming**: Input disabled, streaming content visible, auto-scrolling
|
||||
- **Tool Execution**: Input disabled, tool output visible
|
||||
- **Error**: Error message visible, input re-enabled
|
||||
|
||||
## Debugging
|
||||
|
||||
### Backend Logs
|
||||
Check terminal for Rust logs:
|
||||
- Look for "=== Ollama Request ===" to verify streaming is enabled
|
||||
- Check for streaming response parsing logs
|
||||
|
||||
### Frontend Console
|
||||
Open DevTools console:
|
||||
- Look for `chat:token` events
|
||||
- Look for `chat:update` events
|
||||
- Check for any JavaScript errors
|
||||
|
||||
### Ollama Logs
|
||||
Check Ollama logs:
|
||||
```bash
|
||||
journalctl -u ollama -f # Linux
|
||||
tail -f /var/log/ollama.log # If configured
|
||||
```
|
||||
|
||||
## Known Issues / Limitations
|
||||
|
||||
1. **Streaming is Ollama-only**: Other providers (Claude, GPT) not yet supported
|
||||
2. **Tool outputs don't stream**: Tools execute and return results all at once
|
||||
3. **No streaming animations**: Just simple text append, no typing effects
|
||||
4. **Token buffering**: Very fast streaming might batch tokens slightly
|
||||
|
||||
## Success Criteria
|
||||
|
||||
All acceptance criteria from Story 18 must pass:
|
||||
- [x] Backend emits `chat:token` events
|
||||
- [x] Frontend listens and displays tokens in real-time
|
||||
- [ ] Tokens appear smoothly without lag (manual verification required)
|
||||
- [ ] Auto-scroll works during streaming (manual verification required)
|
||||
- [ ] Tool calls work correctly with streaming (manual verification required)
|
||||
- [ ] Stop button cancels streaming (manual verification required)
|
||||
- [ ] Error handling works (manual verification required)
|
||||
- [ ] Multi-turn conversations work (manual verification required)
|
||||
35
.living_spec/stories/20_start_new_session.md
Normal file
35
.living_spec/stories/20_start_new_session.md
Normal file
@@ -0,0 +1,35 @@
|
||||
# Story 20: Start New Session / Clear Chat History
|
||||
|
||||
## User Story
|
||||
As a user, I want to be able to start a fresh conversation without restarting the entire application, so that I can begin a new task with clean context while keeping the same project open.
|
||||
|
||||
## Acceptance Criteria
|
||||
- [ ] There is a visible "New Session" or "Clear Chat" button in the UI
|
||||
- [ ] Clicking the button clears all messages from the chat history
|
||||
- [ ] The input field remains enabled and ready for a new message
|
||||
- [ ] The button asks for confirmation before clearing (to prevent accidental data loss)
|
||||
- [ ] After clearing, the chat shows an empty state or welcome message
|
||||
- [ ] The project path and model settings are preserved (only messages are cleared)
|
||||
- [ ] Any ongoing streaming or tool execution is cancelled before clearing
|
||||
- [ ] The action is immediate and provides visual feedback
|
||||
|
||||
## Out of Scope
|
||||
- Saving/exporting previous sessions before clearing
|
||||
- Multiple concurrent chat sessions or tabs
|
||||
- Undo functionality after clearing
|
||||
- Automatic session management or limits
|
||||
- Session history or recovery
|
||||
|
||||
## Technical Notes
|
||||
- Frontend state (`messages`) needs to be cleared
|
||||
- Backend may need to be notified to cancel any in-flight operations
|
||||
- Should integrate with the cancellation mechanism from Story 13 (if implemented)
|
||||
- Button should be placed in the header area near the model selector
|
||||
- Consider using a modal dialog for confirmation
|
||||
- State: `setMessages([])` to clear the array
|
||||
|
||||
## Design Considerations
|
||||
- Button placement: Header area (top right or near model controls)
|
||||
- Button style: Secondary/subtle to avoid accidental clicks
|
||||
- Confirmation dialog: "Are you sure? This will clear all messages."
|
||||
- Icon suggestion: 🔄 or "New" text label
|
||||
28
.living_spec/stories/archive/18_streaming_responses.md
Normal file
28
.living_spec/stories/archive/18_streaming_responses.md
Normal file
@@ -0,0 +1,28 @@
|
||||
# Story 18: Token-by-Token Streaming Responses
|
||||
|
||||
## User Story
|
||||
As a user, I want to see the AI's response appear token-by-token in real-time (like ChatGPT), so that I get immediate feedback and know the system is working, rather than waiting for the entire response to appear at once.
|
||||
|
||||
## Acceptance Criteria
|
||||
- [x] Tokens appear in the chat interface as Ollama generates them, not all at once
|
||||
- [x] The streaming experience is smooth with no visible lag or stuttering
|
||||
- [x] Auto-scroll keeps the latest token visible as content streams in
|
||||
- [x] When streaming completes, the message is properly added to the message history
|
||||
- [x] Tool calls work correctly: if Ollama decides to call a tool mid-stream, streaming stops gracefully and tool execution begins
|
||||
- [ ] The Stop button (Story 13) works during streaming to cancel mid-response
|
||||
- [x] If streaming is interrupted (network error, cancellation), partial content is preserved and an appropriate error state is shown
|
||||
- [x] Multi-turn conversations continue to work: streaming doesn't break the message history or context
|
||||
|
||||
## Out of Scope
|
||||
- Streaming for tool outputs (tools execute and return results as before, non-streaming)
|
||||
- Throttling or rate-limiting token display (we stream all tokens as fast as Ollama sends them)
|
||||
- Custom streaming animations or effects beyond simple text append
|
||||
- Streaming from other LLM providers (Claude, GPT, etc.) - this story focuses on Ollama only
|
||||
|
||||
## Technical Notes
|
||||
- Backend must enable `stream: true` in Ollama API requests
|
||||
- Ollama returns newline-delimited JSON, one object per token
|
||||
- Backend emits `chat:token` events (one per token) to frontend
|
||||
- Frontend appends tokens to a streaming buffer and renders in real-time
|
||||
- When streaming completes (`done: true`), backend emits `chat:update` with full message
|
||||
- Tool calls are detected when Ollama sends `tool_calls` in the response, which triggers tool execution flow
|
||||
Reference in New Issue
Block a user