Skip to content

Commit 3416354

Browse files
committed
refactor: Replace CachedWorkflowState with minimal instruction buffer
Remove redundant 7-field CachedWorkflowState that duplicated ConversationManager state and could get out of sync (e.g. on session resume). Replace with: - BufferedInstructions: minimal buffer set by proceed_to_phase/start_development, consumed+cleared by chat.message hook. Falls back to WhatsNextHandler when empty. - getWorkflowState(): reads from shared ServerContext's ConversationManager for tool.execute.before and compaction hooks (no more throwaway instances). Net -121 lines. All tests pass.
1 parent 02e7110 commit 3416354

4 files changed

Lines changed: 207 additions & 302 deletions

File tree

Lines changed: 53 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,53 @@
1+
# Development Plan: responsible-vibe (remove-internal-plugin-state branch)
2+
3+
*Generated on 2026-03-31 by Vibe Feature MCP*
4+
*Workflow: [epcc](https://mrsimpson.github.io/responsible-vibe-mcp/workflows/epcc)*
5+
6+
## Goal
7+
Remove redundant `CachedWorkflowState` from the opencode plugin. The plugin maintains internal state (`cachedState`) that duplicates what `ConversationManager` already persists to disk. This state gets out of sync on session resume. Replace all reads from `cachedState` with reads from `ConversationManager` via `getServerContext()`.
8+
9+
## Key Decisions
10+
1. **`ProceedToPhaseHandler` already persists to disk** (line 125-127 of mcp-server proceed-to-phase.ts calls `conversationManager.updateConversationState`), so the next `WhatsNextHandler` call in `chat.message` will read correct state. The "race condition" from commit 8985941 does not actually exist — the tool writes to disk before returning.
11+
2. **Three consumers of `cachedState`**: `chat.message` (instructions), `tool.execute.before` (file patterns), `experimental.session.compacting` (phase info). All can read from `ConversationManager` instead.
12+
3. **`updateCachedState` callback passed to tool handlers** can be removed — tools no longer need to update plugin state.
13+
4. **`loadStateDirectly()` creates its own `FileStorage`/`ConversationManager`** — wasteful. Use the shared `ServerContext` instead.
14+
5. **Replace 7-field CachedWorkflowState with minimal instruction buffer**: `lastPhaseInstructions: { phase: string, instructions: string, allowedFilePatterns: string[] } | null`. Set by proceed_to_phase/start_development, consumed+cleared by chat.message. Falls back to WhatsNextHandler if null.
15+
6. **tool.execute.before and compacting**: Read from ConversationManager via shared ServerContext. No more `loadStateDirectly` with throwaway instances.
16+
7. **Tool handlers**: Replace `updateCachedState` callback with simpler `setLastInstructions` callback.
17+
18+
## Notes
19+
- `cachedState` is used in 4 places: `chat.message`, `tool.execute.before`, `experimental.session.compacting`, and initial load at plugin startup
20+
- Tool handlers `start_development` and `proceed_to_phase` accept `updateCachedState` callback — needs removal from signature
21+
- The `ServerContext` is already cached and reused (`cachedServerContext`), so reading from it is cheap
22+
- `ConversationManager.getConversationContext()` reads from `FileStorage` (disk) every call — no in-memory cache to go stale
23+
- `FileStorage.initialize()` only creates directories — the shared ServerContext's FileStorage works because the directory already exists from previous operations
24+
- Minor pre-existing issue: `initializeServerContext` creates a throwaway `FileStorage` — out of scope
25+
26+
## Explore
27+
<!-- beads-phase-id: responsible-vibe-23.1 -->
28+
### Tasks
29+
30+
*Tasks managed via `bd` CLI*
31+
32+
## Plan
33+
<!-- beads-phase-id: responsible-vibe-23.2 -->
34+
### Tasks
35+
36+
*Tasks managed via `bd` CLI*
37+
38+
## Code
39+
<!-- beads-phase-id: responsible-vibe-23.3 -->
40+
### Tasks
41+
42+
*Tasks managed via `bd` CLI*
43+
44+
## Commit
45+
<!-- beads-phase-id: responsible-vibe-23.4 -->
46+
### Tasks
47+
48+
*Tasks managed via `bd` CLI*
49+
50+
51+
52+
---
53+
*This plan is maintained by the LLM and uses beads CLI for task management. Tool responses provide guidance on which bd commands to use for task management.*

0 commit comments

Comments
 (0)