agentgui 1.0.105 → 1.0.107

package/.prd

@@ -1,228 +0,0 @@
-# PRD: Real-time Streaming Architecture & HTML Response Rendering
-
-## Vision
-Transform agentgui from a "save-on-complete" model to a "stream-as-it-happens" model where:
-1. Real-time stream chunks are persisted to DB immediately as they arrive
-2. Client views always pull from persisted chunks (not ephemeral process output)
-3. Conversation state survives page refresh and multi-tab viewing
-4. Agent thoughts/responses rendered as beautiful semantic HTML (not JSON)
-5. System remains the same whether viewing live stream or historical conversation
-
-## Critical Problems Being Solved
-
-### Problem 1: Conversation State Loss on Refresh
-**Current**: Viewing live execution → refresh page → conversation disappears
-**Why**: Stream chunks exist only in memory during execution, saved as single JSON when done
-**Solution**: Persist each chunk to DB immediately as it arrives from stream
-
-### Problem 2: Dual View Inconsistency
-**Current**: Same conversation looks different when live vs after completion
-**Why**: Live view shows individual streaming blocks, complete view shows condensed JSON
-**Solution**: Single source of truth = DB chunks. No special handling for "done" state
-
-### Problem 3: No Multi-Tab Support
-**Current**: Can't view same conversation in two browser tabs simultaneously
-**Why**: No persistent state, live process is ephemeral
-**Solution**: DB persistence means any tab can view same chunks at any time
-
-### Problem 4: HTML Output Not Distinguished from Files
-**Current**: System prompt says "output HTML" but unclear if it means response HTML or file writes
-**Why**: Ambiguous instruction in system prompt
-**Solution**: Make explicit: Agent HTML responses ≠ file operations. Only HTML rendering for display
-
-### Problem 5: Process Completion Creates Artifacts
-**Current**: When execution finishes, entire thing re-saved as JSON blob
-**Why**: Current architecture treats completion as "finalize and persist"
-**Solution**: No special completion action. Streaming simply stops. DB already has everything.
-
-## Architecture Changes Required
-
-### 1. Stream Chunk Persistence (Core Change)
-**Current Flow**:
-```
-Claude → Stream Event → In-Memory Buffer → On Complete: Save JSON → DB
-```
-
-**New Flow**:
-```
-Claude → Stream Event → Process → Save Chunk → DB → WebSocket to Clients
-```
-
-**Implementation**:
-- Each `streaming_progress` event creates DB chunk immediately
-- Each chunk has: `id`, `sessionId`, `conversationId`, `sequence`, `type`, `data`, `created_at`
-- No buffering, no aggregation, no re-saving on completion
-- Chunks table schema must support variable size chunks (BLOB or TEXT)
-
-### 2. Client Rendering from DB Only
-**Current**: Client renders from WebSocket stream events
-**New**: Client renders from DB chunks via polling/WebSocket
-**Benefit**: Same render path whether data is fresh or historical
-
-**Implementation**:
-- Add endpoint: `GET /api/conversations/:id/chunks?since=<timestamp>`
-- Returns chunks in order (sequence number)
-- Client polls every 100ms for new chunks
-- WebSocket optimization: only notify "new chunk available", don't send chunk data
-- Client always fetches from DB to keep rendering consistent
-
-### 3. HTML Response Rendering (System Prompt Change)
-**Current System Prompt**:
-```
-"Always write your responses in ripple-ui enhanced HTML"
-```
-
-**Problem**: Unclear if this is for file output or response rendering
-**Solution**: Make explicit instruction:
-```
-For user-facing responses and thoughts: Always use semantic HTML with ripple-ui components
-Do not treat this as file creation. HTML is for rendering in the UI, not saving to disk.
-Block types (text, code, thinking, etc) in your message should render as beautiful semantic HTML
-File operations (Read, Write, Edit) are separate - create actual files on disk when needed
-Distinguish clearly: HTML response rendering ≠ file write operations
-```
-
-### 4. Conversation URL State (Client Change)
-**Current**: Conversations loaded from session, URL doesn't track state
-**New**: URL contains conversation ID and session ID for deep linking
-
-**Implementation**:
-- Route: `/gm/?conversation=<conversationId>&session=<sessionId>`
-- Page refresh loads same conversation from URL
-- Each conversation maintains scroll position in localStorage
-- Deep linking enables multi-tab viewing
-
-### 5. Remove Post-Execution JSON Consolidation (Deletion)
-**Current**: When execution completes, entire response saved as consolidated JSON
-**New**: No action on completion. Stream already persisted.
-
-**Implementation**:
-- Delete code in `server.js` that creates final JSON blob on streaming_complete
-- Keep the `streaming_complete` event for UI notifications ("Finished!")
-- All message data comes from persisted chunks, not from completion blob
-
-## Status: ✅ ALL WORK COMPLETE
-
-**All 6 waves successfully executed, verified, and deployed.**
-
-### Completed Deliverables
-- ✅ Wave 1: Database schema with chunks table and indexes
-- ✅ Wave 2: Backend stream persistence with exponential backoff retry logic
-- ✅ Wave 3: Client chunk fetching with 100ms polling
-- ✅ Wave 4: URL state management and multi-tab support
-- ✅ Wave 5: Expanded SYSTEM_PROMPT with clear HTML/file distinction
-- ✅ Wave 6: Comprehensive verification (7/7 tests passed)
-
-### Verification Results
-- ✓ Conversation persistence across refresh
-- ✓ Multi-tab viewing with synchronized content
-- ✓ Streaming chunks rendering consistency
-- ✓ URL deep linking and parameter validation
-- ✓ Data loss prevention (continuous sequences)
-- ✓ Error recovery (chunks integrity maintained)
-- ✓ System prompt clarity (HTML vs file operations)
-
-### All Changes Committed and Pushed
-- Branch: origin/main
-- 6 commits successfully pushed
-- Working tree clean
-- Production ready
-
-## Data Model
-
-### New: chunks table
-```sql
-CREATE TABLE chunks (
-  id TEXT PRIMARY KEY,
-  sessionId TEXT NOT NULL,
-  conversationId TEXT NOT NULL,
-  sequence INTEGER NOT NULL,
-  type TEXT NOT NULL, -- "text", "code", "thinking", "tool_use", "tool_result", "bash", "system", "image"
-  data BLOB NOT NULL, -- full block data as JSON
-  created_at INTEGER NOT NULL,
-  FOREIGN KEY (sessionId) REFERENCES sessions(id),
-  FOREIGN KEY (conversationId) REFERENCES conversations(id)
-);
-
-CREATE INDEX idx_chunks_session ON chunks(sessionId, sequence);
-CREATE INDEX idx_chunks_conversation ON chunks(conversationId, sequence);
-CREATE UNIQUE INDEX idx_chunks_unique ON chunks(sessionId, sequence);
-```
-
-### Modified: messages table (optional cleanup)
-- Keep as-is for message text
-- Add `chunks_id` field to reference chunk sequence (future)
-- Messages created from chunks summary, not vice versa
-
-## API Changes
-
-### New Endpoints
-```
-GET /api/conversations/:id/chunks?since=<timestamp>
-Response: [{id, sessionId, conversationId, sequence, type, data, created_at}...]
-
-GET /api/sessions/:id/chunks?since=<timestamp>
-Response: Same as above, filtered by session
-```
-
-### Modified Endpoints
-```
-POST /api/conversations/:id/messages
-- Still creates message (for conversation history)
-- But also triggers chunk persistence for streaming blocks
-- No change to request/response format
-```
-
-### Removed/Deprecated
-```
-The "save on completion" behavior in streaming_complete event
-- Keep the event for UI ("execution finished")
-- Just don't save aggregated JSON
-- Chunks already in DB from streaming
-```
-
-## System Prompt Changes
-
-### Current
-```
-Always write your responses in ripple-ui enhanced HTML. Avoid overriding
-light/dark mode CSS variables. Use all the benefits of HTML to express
-technical details with proper semantic markup, tables, code blocks, headings,
-and lists. Write clean, well-structured HTML that respects the existing
-design system.
-```
-
-### New (Clearer)
-```
-RESPONSE RENDERING:
-Your thoughts and responses are rendered as semantic HTML in the UI using
-ripple-ui components. Always structure responses with proper HTML:
-- Use headings for sections (<h2>, <h3>)
-- Use lists for sequences (<ul>, <ol>)
-- Use tables for structured data
-- Use code blocks with language tags
-- Use semantic elements: <strong>, <em>, <code>, <pre>
-- Never override CSS variables (use class names instead)
-- Respect the design system
-
-DISTINGUISH: HTML Response vs File Operations
-- HTML above is for UI rendering, not file creation
-- When you need to create files on disk: use Write, Edit, or Bash tools
-- Message blocks (text, code, thinking, tool_use) render as HTML automatically
-- File operations create actual files in the working directory
-- Do not try to "output files" as HTML in your response
-- File operations are explicit via tools, not implicit via response text
-
-BLOCK TYPES:
-Your assistant message will be parsed into blocks:
-- text: Plain text with markdown support
-- code: Code with language detection
-- thinking: Internal reasoning (expandable)
-- tool_use: Showing which tools you're calling
-- tool_result: Tool output
-- bash: Shell commands
-- system: System information
-- image: Image display
-Each block renders with semantic HTML and proper styling.
-```
-

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "agentgui",
-  "version": "1.0.105",
+  "version": "1.0.107",
   "description": "Multi-agent ACP client with real-time communication",
   "type": "module",
   "main": "server.js",

package/static/index.html

@@ -26,7 +26,7 @@
       --color-warning: #f59e0b;
       --sidebar-width: 300px;
       --header-height: 52px;
-      --msg-max-width: 768px;
+      --msg-max-width: 100%;
     }
 
     html.dark {
@@ -318,10 +318,12 @@
       max-width: var(--msg-max-width);
       margin: 0 auto;
       width: 100%;
-      padding: 1.5rem 1rem;
+      padding: 1.5rem 2rem;
       display: flex;
       flex-direction: column;
       min-height: 100%;
+      padding-left: calc(max(2rem, (100vw - 900px) / 2));
+      padding-right: calc(max(2rem, (100vw - 900px) / 2));
     }
 
     #output {
@@ -817,6 +819,49 @@
       .agent-selector { display: none; }
     }
 
+    /* ===== SCROLLBAR STYLING ===== */
+    ::-webkit-scrollbar {
+      width: 10px;
+      height: 10px;
+    }
+
+    ::-webkit-scrollbar-track {
+      background: transparent;
+    }
+
+    ::-webkit-scrollbar-thumb {
+      background: #cbd5e1;
+      border-radius: 8px;
+      border: 3px solid transparent;
+      background-clip: padding-box;
+      transition: background-color 0.2s;
+    }
+
+    ::-webkit-scrollbar-thumb:hover {
+      background-color: #94a3b8;
+      background-clip: padding-box;
+    }
+
+    html.dark ::-webkit-scrollbar-thumb {
+      background: #475569;
+      background-clip: padding-box;
+    }
+
+    html.dark ::-webkit-scrollbar-thumb:hover {
+      background-color: #64748b;
+      background-clip: padding-box;
+    }
+
+    /* Firefox scrollbar */
+    * {
+      scrollbar-width: thin;
+      scrollbar-color: #cbd5e1 transparent;
+    }
+
+    html.dark * {
+      scrollbar-color: #475569 transparent;
+    }
+
     /* ===== RESPONSIVE: TABLET ===== */
     @media (min-width: 769px) and (max-width: 1024px) {
       :root { --sidebar-width: 260px; }