fix(tasks): restore session context on Resume/Launch from kanban board - #417
Closed
kadeross wants to merge 5 commits into
Closed
fix(tasks): restore session context on Resume/Launch from kanban board#417kadeross wants to merge 5 commits into
kadeross wants to merge 5 commits into
Conversation
Three compounding bugs prevented agents from getting real conversation history when resuming or launching from a task card: 1. Prior context was read from the local session store (.runtime/ local-sessions.json), which only ever contained the initial briefing message — not the actual conversation from the Hermes gateway. 2. The session ID stored on the task was a workspace-generated placeholder (task-<uuid>-<uuid>), not the real Hermes gateway session ID. Even querying the right source would fail because the ID was wrong. 3. The prior-session tail was limited to 8 messages × 500 chars — too thin to reconstruct meaningful state. Fixes: - hermes-tasks.$taskId.ts: launch action now queries the dashboard API (port 9119) for real message history first, falls back to local store. Tail bumped to 20 messages × 800 chars. - tasks-screen.tsx: on successful launch, stores a workspace-session-id → task-id mapping in localStorage so the chat route can back-link. - chat/$sessionKey.tsx: when the gateway resolves the real session ID (handleSessionResolved), reads the localStorage mapping and PATCHes the task with the real gateway session ID. Future Resume/Launch calls now query the correct session in the dashboard. - claude-dashboard-api.ts + claude-api.ts: add sendChat export and route sendChat through dashboard when available (fixes Launch routing to correct port 9119 vs 8642). - hermes-tasks.ts + hermes-tasks-assignees.ts: add tasks board API routes for task CRUD and assignee listing.
… tasks-api.ts .gitattributes marks src/lib/tasks-api.ts with merge=ours, which prevents upstream merges from overwriting our backend auto-detection logic. However, git requires the 'ours' driver to be registered in .git/config via git config merge.ours.driver true Without this, the attribute is silently ignored and upstream merges reset the file, breaking the task board. Now registered at install time.
Owner
|
Closing as superseded by #432. The validated fix was folded into the consolidated batch branch |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Three compounding bugs caused agents to get zero real conversation history when clicking Resume or Launch from a kanban task card.
Root Causes
1. Wrong context source
Prior session history was read from
.runtime/local-sessions.json(the workspace's in-memory local store), which only ever holds the initial briefing message. The actual conversation lives in the Hermes gateway SQLite DB on port 9119.2. Wrong session ID on the task
On launch, the workspace generates a placeholder ID (
task-<uuid>-<uuid>) and writes it totask.session_id. The real Hermes gateway session ID — created when the user sends the first message — was never written back. So even querying the right source failed because the ID was wrong.3. Tail too short / truncated
Only the last 8 messages at 500 chars each — not enough to reconstruct meaningful state for most tasks.
Fix
src/routes/api/hermes-tasks.$taskId.ts— launch action now:src/screens/tasks/tasks-screen.tsx— on successful launch:hermes-task-wsession:<wsSessionId> → taskIdmapping in localStorage so the chat route can back-link the real sessionsrc/routes/chat/$sessionKey.tsx— inhandleSessionResolved:task.session_idwith the real gateway session IDsrc/server/claude-dashboard-api.ts+src/server/claude-api.ts:sendChatexport that routes through port 9119 (dashboard) when available, fixing the Launch routing bug (was hitting port 8642 / zero-fork mode which returns 404)src/routes/api/hermes-tasks.ts+hermes-tasks.$taskId.ts+hermes-tasks-assignees.ts:Testing