Wisplog as single source of truth for chat history

[mcintyre94]

Summary

Eliminates SwiftData message persistence entirely. The on-sprite wisplog file (/home/sprite/.wisp/chats/UUID.wisplog) is now the canonical record of conversation history — written in real-time by tee -a during streaming, read on demand when needed.

Removed:

• SpriteChat.messagesData, streamEventUUIDsData, lastSessionComplete
• PersistedChatMessage.swift (whole file)
• persistMessages (14 call sites)
• restoreFromSessionFile
• linkToolResults (only needed for SwiftData round-trip)
• 1-second periodic persist in processExecStream
• All SwiftData-persistence tests

Changed:

• parseWispLog now returns eventUUIDs: Set<String> so reattachToExec can seed processedEventUUIDs from the wisplog, preventing duplicate content when the exec session replays events already shown
• reconnectIfNeeded simplified: execSessionId set → reattach; messages empty → load wisplog; otherwise → restore draft
• reattachToExec pre-loads the wisplog before connecting to the exec WebSocket (instant history display during reconnect), then streams live events with UUID deduplication
• saveSession drops the isComplete parameter; the result event clears execSessionId directly, so execSessionId == nil signals a completed session
• DashboardView reconnect query: execSessionId != nil instead of !lastSessionComplete
• Fork path: single on-sprite awk command copies the parent wisplog up to the fork point into the new chat's wisplog (replaces saveMessages + PersistedChatMessage serialisation)
• importJSONLSession: calls loadFromWispLog after jq conversion (already wrote the wisplog, no separate persist needed)
• SwiftData schema migration: WispSchema.swift with a SchemaV1 → SchemaV2 lightweight migration to drop the removed columns

Trade-offs

• Cold-open latency: opening an old chat now requires a sprite round-trip (cat the wisplog) instead of an instant SwiftData read. The sprite is typically warm when you're actively using a chat.
• Checkpoint annotations (checkpointId/checkpointComment on ChatMessage): in-memory only, not persisted. Can be fixed later by adding a wisp_checkpoint event type to the wisplog format.

Test plan

• Send a message, let it complete — history displayed correctly
• Background app mid-stream, return — reconnects and shows in-progress response
• Background app, Claude finishes while backgrounded — history loads from wisplog on return
• Open old completed chat — wisplog loads, full history shown
• Fork from checkpoint — new chat shows prior history (from awk wisplog copy)
• Load chat from Claude history — JSONL import converts and displays via wisplog
• Fresh install / SwiftData cleared — wisplog load restores history seamlessly

🤖 Generated with Claude Code

[claude]

test connection

[claude]

Code review — 2 bugs and 1 CLAUDE.md violation found.

---

Bug 1: loadFromWispLog incorrectly clears execSessionId for in-progress sessions

wisp/Wisp/ViewModels/ChatViewModel.swift

Lines 720 to 727 in 472df5f

	if let last = messages.last, last.role == .user {
	restoreUndeliveredDraft(modelContext: modelContext)
	} else {
	execSessionId = nil
	saveSession(modelContext: modelContext)
	}
	}

The else branch fires whenever the last wisplog message is not a .user message — but an in-progress session (exec still running, Claude mid-stream) also ends with a partial assistant tail. loadFromWispLog clears execSessionId and calls saveSession for a live session. reattachToExec then hits the guard immediately after and bails:

wisp/Wisp/ViewModels/ChatViewModel.swift

Lines 1282 to 1290 in 472df5f

	// If the wisplog showed a complete session (execSessionId cleared by loadFromWispLog),
	// the exec is already done — no need to attach.
	guard self.execSessionId != nil else {
	if !Task.isCancelled { status = .idle }
	return
	}
	isReplaying = true

Impact: A user who backgrounds the app mid-stream and returns will have their in-flight Claude response silently abandoned. The execSessionId is also cleared in SwiftData, so subsequent dashboard reconnects won't pick this chat up.

Root cause: parseWispLog returns no signal about whether a result event was seen, so the caller can't distinguish a completed session from a still-running one — both end with an assistant tail. Fix: return whether a result event was observed, and only clear execSessionId when confirmed complete.

---

Bug 2: processedEventUUIDs blocks the exec replay from rebuilding the removed content

wisp/Wisp/ViewModels/ChatViewModel.swift

Lines 1299 to 1309 in 472df5f

	// Strip any trailing incomplete assistant from the wisplog load; the exec replay
	// will rebuild it. A complete turn ends with a result event, so if the last message
	// is assistant it may be partial.
	if let last = messages.last, last.role == .assistant {
	messages.removeLast()
	}
	let assistantMessage = ChatMessage(role: .assistant)
	messages.append(assistantMessage)
	currentAssistantMessage = assistantMessage

loadFromWispLog (called just above at line ~1281) sets processedEventUUIDs = seenUUIDs — which includes the UUIDs of every event that built the trailing assistant message being removed here. When the exec WebSocket replays those events, handleOrSkip finds their UUIDs already in processedEventUUIDs and skips them without emitting content.

wisp/Wisp/ViewModels/ChatViewModel.swift

Lines 1166 to 1203 in 472df5f

	func processExecStream(
	events: AsyncThrowingStream<ExecEvent, Error>,
	modelContext: ModelContext
	) async -> StreamResult {
	var receivedData = false
	let timeoutTask = Task {
	try await Task.sleep(for: .seconds(30))
	if !receivedData {
	logger.warning("No exec data received in 30s")
	}
	}
	func handleOrSkip(_ parsedEvent: ClaudeStreamEvent) {
	if let uuid = parsedEvent.uuid, processedEventUUIDs.contains(uuid) {
	switch parsedEvent {
	case .system(let se):
	receivedSystemEvent = true
	sessionId = se.sessionId
	modelName = se.model
	case .result(let re):
	receivedResultEvent = true
	sessionId = re.sessionId
	default: break
	}
	return
	}
	if let uuid = parsedEvent.uuid {
	processedEventUUIDs.insert(uuid)
	}
	if isReplayingLiveService {
	applyReplayBuffer()
	isReplaying = false
	isReplayingLiveService = false
	if case .reconnecting = status { status = .streaming }
	}
	handleEvent(parsedEvent, modelContext: modelContext)
	}

Impact: The comment 'the exec replay will rebuild it' is incorrect. The new empty assistant bubble will only receive truly new events arriving after the wisplog snapshot. In the common case where the wisplog is fully caught up, the bubble stays empty for the rest of the turn.

Fix options: (a) before removing the last message, remove its events' UUIDs from processedEventUUIDs, or (b) don't pre-seed processedEventUUIDs from the wisplog at all. Note: this bug is only reachable once Bug 1 is fixed.

---

CLAUDE.md violation: Missing test for parseWispLog's new eventUUIDs return value

wisp/WispTests/ChatViewModelTests.swift

Lines 1261 to 1265 in 472df5f

	"""
	let (messages, sessionId, _) = ChatViewModel.parseWispLog(ndjson)
	#expect(messages.count == 2)

Per CLAUDE.md (https://github.com/mcintyre94/wisp/blob/472df5f3c7e131bf6e5cd7ce17cd93ac45b1c7d4/CLAUDE.md): 'Add new unit tests when adding or modifying logic (models, parsers, utilities, view models)'.

The PR adds eventUUIDs: Set as a new return value from parseWispLog, collecting event UUIDs from the wisplog. This output directly drives deduplication in loadFromWispLog (processedEventUUIDs = seenUUIDs). All test call sites discard it with _ — no test verifies that events with UUIDs are collected, events without UUIDs don't break the parse, or that empty input returns an empty set.

---

Disregard the earlier 'test connection' comment — posted during review tooling setup.