story-kit: accept 96_story_reset_agent_lozenge_to_idle_state_when_returning_to_roster

.story_kit/work/4_merge/89_story_persistent_per_session_agent_logs.md

@@ -1,21 +0,0 @@
----
-name: "Persistent per-session agent logs"
----
-
-# Story 89: Persistent per-session agent logs
-
-## User Story
-
-As a user, I want each agent session to write its output to a persistent log file so I can inspect what an agent did after it completes, even across server restarts.
-
-## Acceptance Criteria
-
-- [ ] Each agent session writes output to a log file at .story_kit/logs/{story_id}/{agent_name}-{session_id}.log
-- [ ] Log files persist across server restarts and agent completions
-- [ ] The get_agent_output MCP tool falls back to reading the log file when the in-memory stream is empty or the agent has completed
-- [ ] Log files include timestamps, tool calls, text output, and status events
-- [ ] Different sessions for the same agent on the same story produce separate log files (no mixing)
-
-## Out of Scope
-
-- TBD

.story_kit/work/4_merge/93_story_expose_server_logs_to_agents_via_mcp.md

@@ -1,35 +0,0 @@
----
-name: "Expose server logs to agents via MCP"
----
-
-# Story 93: Expose server logs to agents via MCP
-
-## User Story
-
-As a coder agent, I want to read recent server logs via an MCP tool, so that I can verify runtime behavior (WebSocket events, MCP call flow, PTY interactions) without relying on a human to check.
-
-## Context
-
-Agents currently have no visibility into runtime server behavior. They can run `cargo test` and `cargo clippy`, but for bugs involving runtime flow (e.g. events not reaching the frontend, MCP tools not triggering), they can't verify their fix works end-to-end. Exposing server logs lets agents self-diagnose issues and confirm runtime behavior matches expectations.
-
-## Approach
-
-- Add a bounded ring buffer (e.g. 1000 lines) that captures `eprintln!` / `tracing` output in-process
-- Expose an MCP tool `get_server_logs(lines?, filter?)` that returns recent log entries
-  - `lines`: number of recent lines to return (default 100)
-  - `filter`: optional substring filter (e.g. `"watcher"`, `"permission"`, `"mcp"`)
-- The ring buffer lives in `AppContext` so it's accessible from the MCP handler
-
-## Acceptance Criteria
-
-- [ ] Server captures log output in a bounded in-memory ring buffer
-- [ ] `get_server_logs` MCP tool exists with optional `lines` and `filter` parameters
-- [ ] Tool returns recent log lines as a newline-separated string
-- [ ] Buffer does not grow unbounded (fixed capacity, oldest entries evicted)
-- [ ] cargo clippy and cargo test pass
-
-## Out of Scope
-
-- Per-worktree log isolation (agents see the main server's logs)
-- Log levels / structured logging migration (can use raw eprintln output for now)
-- Log persistence to disk