story-kit: accept 264_bug_claude_code_session_id_not_persisted_across_browser_refresh
This commit is contained in:
Dave
@@ -0,0 +1,21 @@
|
||||
---
|
||||
name: "Matrix bot self-signs device keys at startup for verified encryption"
|
||||
agent: mergemaster
|
||||
---
|
||||
|
||||
# Story 263: Matrix bot self-signs device keys at startup for verified encryption
|
||||
|
||||
## User Story
|
||||
|
||||
As a Matrix room participant, I want the bot's messages to not show "encrypted by a device not verified by its owner" warnings, so that I have confidence the bot's encryption is fully verified.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] At startup the bot checks whether its own device keys have been self-signed (cross-signed by its own user identity)
|
||||
- [ ] If the device keys are not self-signed, the bot signs them automatically
|
||||
- [ ] After signing, the bot uploads the new signatures to the homeserver
|
||||
- [ ] After a clean start (fresh matrix_store / device_id) the bot's messages no longer show the 'encrypted by a device not verified by its owner' warning
|
||||
|
||||
## Out of Scope
|
||||
|
||||
- TBD
|
||||
@@ -0,0 +1,43 @@
|
||||
---
|
||||
name: "Claude Code session ID not persisted across browser refresh"
|
||||
---
|
||||
|
||||
# Bug 264: Claude Code session ID not persisted across browser refresh
|
||||
|
||||
## Description
|
||||
|
||||
The Claude Code provider uses a session_id to resume conversations via `--resume <id>`. This session_id is stored in React state (`claudeSessionId`) but is NOT persisted to localStorage. After a browser refresh, the session_id is lost (`null`), so Claude Code cannot resume the prior session.
|
||||
|
||||
A fallback exists (`build_claude_code_context_prompt` in `server/src/llm/chat.rs:188`) that injects prior messages as flattened text inside a `<conversation_history>` block, but this loses structure (tool calls, tool results, reasoning) and Claude Code treats it as informational text rather than actual conversation turns. In practice, the LLM does not retain meaningful context after refresh.
|
||||
|
||||
This is the root cause behind bug 245 (chat history persistence regression). The localStorage message persistence from story 145 works correctly for the UI, but the LLM context is not properly restored because the session cannot be resumed.
|
||||
|
||||
Key files:
|
||||
- `frontend/src/components/Chat.tsx:174` — `claudeSessionId` is ephemeral React state
|
||||
- `frontend/src/components/Chat.tsx:553` — session_id only sent when non-null
|
||||
- `server/src/llm/chat.rs:278` — backend branches on session_id presence
|
||||
- `server/src/llm/providers/claude_code.rs:44` — `--resume` flag passed to Claude CLI
|
||||
|
||||
## How to Reproduce
|
||||
|
||||
1. Open the Story Kit web UI and select claude-code-pty as the model
|
||||
2. Have a multi-turn conversation with the agent
|
||||
3. Refresh the browser (F5 or Cmd+R)
|
||||
4. Send a new message referencing the prior conversation
|
||||
5. The LLM has no knowledge of the prior conversation
|
||||
|
||||
## Actual Result
|
||||
|
||||
After refresh, claudeSessionId is null. Claude Code spawns a fresh session without --resume. The fallback text injection is too lossy to provide meaningful context. The LLM behaves as if the conversation never happened.
|
||||
|
||||
## Expected Result
|
||||
|
||||
After refresh, the Claude Code session is resumed via --resume, giving the LLM full context of the prior conversation including tool calls, reasoning, and all turns.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] claudeSessionId is persisted to localStorage (scoped by project path) and restored on component mount
|
||||
- [ ] After browser refresh, the next chat message includes session_id in the ProviderConfig
|
||||
- [ ] Claude Code receives --resume with the persisted session_id after refresh
|
||||
- [ ] Clearing the session (clear button) also clears the persisted session_id
|
||||
- [ ] After server restart with session files intact on disk, conversation resumes correctly
|
||||
@@ -0,0 +1,33 @@
|
||||
---
|
||||
name: "Spikes skip merge and stop for human review"
|
||||
agent: coder-opus
|
||||
---
|
||||
|
||||
# Story 265: Spikes skip merge and stop for human review
|
||||
|
||||
## User Story
|
||||
|
||||
As a user, I want spike work items to stop after QA instead of auto-advancing to the merge stage, so that I can review the spike's findings and prototype code in the worktree before deciding what to do with them.
|
||||
|
||||
## Context
|
||||
|
||||
Spikes are investigative — their value is the findings and any prototype code, not a merge to master. The user needs to:
|
||||
- Read the spike document with findings
|
||||
- Review prototype code in the worktree
|
||||
- Optionally build and run the prototype to validate the approach
|
||||
- Then manually decide: archive the spike and create follow-up stories, or reject and re-investigate
|
||||
|
||||
Currently all work items follow the same pipeline: coder → QA → merge → done. Spikes should diverge after QA and wait for human review instead of auto-advancing to merge.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] Items with `_spike_` in the filename skip the merge stage after QA passes
|
||||
- [ ] After QA, spike items remain accessible for human review (worktree preserved, not cleaned up)
|
||||
- [ ] Spikes do not auto-advance to `4_merge/` — they stay in `3_qa/` or move to a review-hold state
|
||||
- [ ] The human can manually archive the spike when done reviewing
|
||||
- [ ] Non-spike items (stories, bugs, refactors) continue through the full pipeline as before
|
||||
|
||||
## Out of Scope
|
||||
|
||||
- New UI for spike review (manual file inspection is fine)
|
||||
- Changes to the spike creation flow
|
||||
@@ -0,0 +1,21 @@
|
||||
---
|
||||
name: "Matrix bot structured conversation history"
|
||||
---
|
||||
|
||||
# Story 266: Matrix bot structured conversation history
|
||||
|
||||
## User Story
|
||||
|
||||
As a user chatting with the Matrix bot, I want it to remember and own its prior responses naturally, so that conversations feel like talking to one continuous entity rather than a new instance each message.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] Conversation history is passed as structured API messages (user/assistant turns) rather than a flattened text prefix
|
||||
- [ ] Claude recognises its prior responses as its own, maintaining consistent personality across a conversation
|
||||
- [ ] Per-room history survives server restarts (persisted to disk or database)
|
||||
- [ ] Rolling window trimming still applies to keep context bounded
|
||||
- [ ] Multi-user rooms still attribute messages to the correct sender
|
||||
|
||||
## Out of Scope
|
||||
|
||||
- TBD
|
||||
@@ -0,0 +1,19 @@
|
||||
---
|
||||
name: "MCP update_story tool should support front matter fields"
|
||||
---
|
||||
|
||||
# Story 267: MCP update_story tool should support front matter fields
|
||||
|
||||
## User Story
|
||||
|
||||
As an operator using the MCP tools, I want update_story to accept optional front matter fields (like agent, manual_qa, etc.) so that I can update story metadata without editing files by hand.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] update_story MCP tool accepts optional agent parameter to set/change the agent front matter field
|
||||
- [ ] update_story MCP tool accepts optional arbitrary front matter key-value pairs
|
||||
- [ ] Front matter updates are auto-committed via the filesystem watcher like other story mutations
|
||||
|
||||
## Out of Scope
|
||||
|
||||
- TBD
|
||||
@@ -0,0 +1,23 @@
|
||||
---
|
||||
name: "Upgrade tokio-tungstenite to 0.29.0"
|
||||
---
|
||||
|
||||
# Refactor 268: Upgrade tokio-tungstenite to 0.29.0
|
||||
|
||||
## Current State
|
||||
|
||||
- TBD
|
||||
|
||||
## Desired State
|
||||
|
||||
Upgrade tokio-tungstenite from 0.28.0 to 0.29.0 in workspace Cargo.toml and fix any breaking API changes.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] tokio-tungstenite = "0.29.0" in workspace Cargo.toml
|
||||
- [ ] All code compiles without errors
|
||||
- [ ] All tests pass
|
||||
|
||||
## Out of Scope
|
||||
|
||||
- TBD
|
||||
@@ -0,0 +1,22 @@
|
||||
---
|
||||
name: "@ file references in web UI chat input"
|
||||
---
|
||||
|
||||
# Story 269: @ file references in web UI chat input
|
||||
|
||||
## User Story
|
||||
|
||||
As a user chatting in the web UI, I want to type @ to get an autocomplete overlay listing project files, so that I can reference specific files in my messages the same way Zed and Claude Code do.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] Typing @ in the chat input triggers a file picker overlay
|
||||
- [ ] Overlay searches project files with fuzzy matching as the user types after @
|
||||
- [ ] Selecting a file inserts a reference into the message (e.g. @path/to/file.rs)
|
||||
- [ ] The referenced file contents are included as context when the message is sent to the LLM
|
||||
- [ ] Overlay is dismissable with Escape
|
||||
- [ ] Multiple @ references can be used in a single message
|
||||
|
||||
## Out of Scope
|
||||
|
||||
- TBD
|
||||
@@ -0,0 +1,31 @@
|
||||
---
|
||||
name: "QA test server overwrites root .mcp.json with wrong port"
|
||||
---
|
||||
|
||||
# Bug 270: QA test server overwrites root .mcp.json with wrong port
|
||||
|
||||
## Description
|
||||
|
||||
When the QA agent starts a test server in a worktree (e.g. on port 3012), that server auto-detects the shared project root and calls open_project, which writes .mcp.json with the test server's port. This clobbers the root .mcp.json that should always point to the main server (port 3001).
|
||||
|
||||
Root cause: open_project in server/src/io/fs.rs:527 unconditionally calls write_mcp_json(&p, port) with its own port. Because worktrees share .story_kit/ with the real project, the test server resolves to the real project root and overwrites the root .mcp.json instead of writing to its own worktree directory.
|
||||
|
||||
Fix: Remove the write_mcp_json call from open_project entirely. Worktree .mcp.json files are already written correctly during worktree creation (worktree.rs:81,97), and the root .mcp.json is committed in git. open_project should not touch it.
|
||||
|
||||
## How to Reproduce
|
||||
|
||||
1. QA agent starts on a story\n2. QA agent starts a test server in the worktree on a non-default port (e.g. 3012)\n3. Test server auto-opens the project root\n4. Root .mcp.json is overwritten with test port
|
||||
|
||||
## Actual Result
|
||||
|
||||
Root .mcp.json contains the QA test server's port (e.g. 3012) instead of the main server's port (3001). Interactive Claude sessions lose MCP connectivity.
|
||||
|
||||
## Expected Result
|
||||
|
||||
Root .mcp.json always points to the primary server's port. Test servers started by QA agents should not overwrite it.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] QA test servers do not overwrite root .mcp.json
|
||||
- [ ] Root .mcp.json always reflects the primary server's port
|
||||
- [ ] Worktree .mcp.json files are only written during worktree creation
|
||||
@@ -0,0 +1,19 @@
|
||||
---
|
||||
name: "Clear merge error front matter when story leaves merge stage"
|
||||
---
|
||||
|
||||
# Story 272: Clear merge error front matter when story leaves merge stage
|
||||
|
||||
## User Story
|
||||
|
||||
As an operator, I want merge error front matter to be automatically removed when a story is moved out of the merge stage via MCP, so that stale error metadata doesn't persist when the story is retried.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] When a story with merge_error front matter is moved out of 4_merge via MCP, the merge_error field is automatically stripped
|
||||
- [ ] Works for all destinations: back to 2_current, back to 1_upcoming, or forward to 5_done
|
||||
- [ ] Stories without merge_error front matter are unaffected
|
||||
|
||||
## Out of Scope
|
||||
|
||||
- TBD
|
||||
Reference in New Issue
Block a user