story-kit: gitignore intermediate pipeline stages (spike 92 follow-up)
Ignore 2_current/, 3_qa/, and 4_merge/ in git since spike 92 stopped committing intermediate pipeline moves. Keep 5_done/ tracked so accepted work is in git history before sweep to archived. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
Dave
@@ -1,49 +0,0 @@
|
||||
---
|
||||
name: "Matrix bot structured conversation history"
|
||||
agent: coder-opus
|
||||
---
|
||||
|
||||
# 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
|
||||
|
||||
## Investigation Notes (2026-03-18)
|
||||
|
||||
The current implementation attempts session resumption via `--resume <session_id>` but it's not working:
|
||||
|
||||
### Code path: how session resumption is supposed to work
|
||||
|
||||
1. `server/src/matrix/bot.rs:671-676` — `handle_message()` reads `conv.session_id` from the per-room `RoomConversation` to get the resume ID.
|
||||
2. `server/src/matrix/bot.rs:717` — passes `resume_session_id` to `provider.chat_stream()`.
|
||||
3. `server/src/llm/providers/claude_code.rs:57` — `chat_stream()` stores it as `resume_id`.
|
||||
4. `server/src/llm/providers/claude_code.rs:170-173` — if `resume_session_id` is `Some`, appends `--resume <id>` to the `claude -p` command.
|
||||
5. `server/src/llm/providers/claude_code.rs:348` — `process_json_event()` looks for `json["session_id"]` in each streamed NDJSON event and sends it via a oneshot channel (`sid_tx`).
|
||||
6. `server/src/llm/providers/claude_code.rs:122` — after the PTY exits, `sid_rx.await.ok()` captures the session ID (or `None` if never sent).
|
||||
7. `server/src/matrix/bot.rs:785-787` — stores `new_session_id` back into `conv.session_id` and persists via `save_history()`.
|
||||
|
||||
### What's broken
|
||||
|
||||
- **No session_id captured:** `.story_kit/matrix_history.json` contains conversation entries but no `session_id`. `RoomConversation.session_id` is always `None`.
|
||||
- **Root cause:** `claude -p --output-format stream-json` may not emit a `session_id` in its NDJSON events, or the parser at step 5 isn't matching the actual event shape. The oneshot channel never fires.
|
||||
- **Effect:** Every message spawns a fresh Claude Code process with no `--resume` flag. Each turn is a blank slate.
|
||||
- **History persistence works fine** — serialization round-trips correctly (test at `bot.rs:1335-1339`). The problem is purely that `--resume` is never invoked.
|
||||
|
||||
### Debugging steps
|
||||
|
||||
1. Run `claude -p "hello" --output-format stream-json --verbose 2>/dev/null` manually and inspect the NDJSON for a `session_id` field. Check what event type carries it and whether the key name matches what `process_json_event()` expects.
|
||||
2. If `session_id` is present but nested differently (e.g. inside an `event` wrapper), fix the JSON path at `claude_code.rs:348`.
|
||||
3. If `-p` mode doesn't emit `session_id` at all, consider an alternative: pass conversation history as a structured prompt prefix, or switch to the Claude API directly.
|
||||
|
||||
## Out of Scope
|
||||
|
||||
- TBD
|
||||
@@ -1,19 +0,0 @@
|
||||
---
|
||||
name: "Show assigned agent in expanded work item view"
|
||||
---
|
||||
|
||||
# Story 271: Show assigned agent in expanded work item view
|
||||
|
||||
## User Story
|
||||
|
||||
As a project owner viewing an expanded work item in the web UI, I want to see which agent (e.g. coder-opus) has been assigned via front matter, so that I know which coder is working on or will pick up the story.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] Expanded work item view displays the agent front matter field if set
|
||||
- [ ] Shows the specific agent name (e.g. 'coder-opus') not just 'assigned'
|
||||
- [ ] If no agent is set in front matter, the field is omitted or shows unassigned
|
||||
|
||||
## Out of Scope
|
||||
|
||||
- TBD
|
||||
@@ -1,19 +0,0 @@
|
||||
---
|
||||
name: "Matrix bot uses its configured name instead of \"Claude\""
|
||||
---
|
||||
|
||||
# Story 277: Matrix bot uses its configured name instead of "Claude"
|
||||
|
||||
## User Story
|
||||
|
||||
As a Matrix user, I want the bot to identify itself by its configured name (e.g., "Timmy") rather than "Claude", so that the bot feels like a distinct personality in the chat.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] The Matrix bot refers to itself by its configured display name (e.g., 'Timmy') in conversations, not 'Claude'
|
||||
- [ ] The bot's self-referencing name is derived from configuration, not hardcoded
|
||||
- [ ] If no custom name is configured, the bot falls back to a sensible default
|
||||
|
||||
## Out of Scope
|
||||
|
||||
- TBD
|
||||
@@ -1,17 +0,0 @@
|
||||
---
|
||||
name: "Auto-assign agents to pipeline items on server startup"
|
||||
---
|
||||
|
||||
# Story 278: Auto-assign agents to pipeline items on server startup
|
||||
|
||||
## User Story
|
||||
|
||||
As a ..., I want ..., so that ...
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] TODO
|
||||
|
||||
## Out of Scope
|
||||
|
||||
- TBD
|
||||
@@ -1,17 +0,0 @@
|
||||
---
|
||||
name: "Auto-assign should respect agent stage when front matter specifies agent"
|
||||
---
|
||||
|
||||
# Story 279: Auto-assign should respect agent stage when front matter specifies agent
|
||||
|
||||
## User Story
|
||||
|
||||
As a ..., I want ..., so that ...
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] TODO
|
||||
|
||||
## Out of Scope
|
||||
|
||||
- TBD
|
||||
@@ -1,20 +0,0 @@
|
||||
---
|
||||
name: "Matrix bot sends typing indicator while waiting for Claude response"
|
||||
---
|
||||
|
||||
# Story 273: Matrix bot sends typing indicator while waiting for Claude response
|
||||
|
||||
## User Story
|
||||
|
||||
As a user chatting with the Matrix bot, I want to see a typing indicator in Element while the bot is processing my message, so that I know it received my request and is working on a response.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] Bot sets m.typing on the room as soon as it starts the Claude API call
|
||||
- [ ] Typing indicator is cleared when the first response chunk is sent to the room
|
||||
- [ ] Typing indicator is cleared on error so it doesn't get stuck
|
||||
- [ ] No visible delay between sending a message and seeing the typing indicator
|
||||
|
||||
## Out of Scope
|
||||
|
||||
- TBD
|
||||
Reference in New Issue
Block a user