docs(6): create phase plan

Phase 6: Session Chat Research & Design
- 2 plans created
- 6 total tasks defined (3 per plan)
- Ready for execution

Plan 1: Legacy Chat Analysis & API Documentation
Plan 2: React Architecture & Implementation Roadmap
This commit is contained in:
Nuwan 2026-01-26 15:04:31 +05:30
parent 3f9602346c
commit eca7f95c23
2 changed files with 591 additions and 0 deletions

View File

@ -0,0 +1,251 @@
---
phase: 06-session-chat-research-design
plan: 01
type: execute
---
<objective>
Understand legacy chat implementation and document all APIs, WebSocket messages, and patterns.
Purpose: Build comprehensive understanding of how session chat works in the legacy jQuery/CoffeeScript codebase before designing React version. This research phase mirrors Phase 4 Plan 1 (JamTrack Legacy Analysis).
Output: Three documentation files capturing legacy patterns, chat API surface, and React integration approach.
</objective>
<execution_context>
@./.claude/get-shit-done/workflows/execute-phase.md
@./.claude/get-shit-done/templates/summary.md
</execution_context>
<context>
@.planning/PROJECT.md
@.planning/ROADMAP.md
@.planning/STATE.md
@.planning/phases/06-session-chat-research-design/06-CONTEXT.md
# Phase 4 pattern reference (JamTrack research)
@.planning/phases/04-jamtrack-research-design/04-01-SUMMARY.md
# Codebase understanding
@.planning/codebase/ARCHITECTURE.md
@.planning/codebase/CONVENTIONS.md
# Screenshots for reference
@/Users/nuwan/Desktop/chat-window.png
@/Users/nuwan/Desktop/chat-button-unread.png
**Key context from Phase 6 CONTEXT.md:**
- Deep dive into legacy code: jQuery/CoffeeScript chat, APIs, WebSocket messages
- Focus on happy path (not edge cases yet)
- Read/unread tracking is NEW functionality not in legacy
- File attachments out of scope (next milestone)
**Established patterns from prior phases:**
- jamClient API integration patterns (Phase 2,3: Backing Track, Phase 5: JamTrack)
- Redux state management (Phase 5: mediaSlice extensions)
- WebSocket message handling (Phase 5: MIXER_CHANGES, JAM_TRACK_CHANGES)
- Modal/dialog patterns in jam-ui
</context>
<tasks>
<task type="auto">
<name>Task 1: Research legacy chat implementation and create CHAT_LEGACY.md</name>
<files>.planning/codebase/CHAT_LEGACY.md</files>
<action>
Search the legacy codebase (web/, coffee/, app/) for jQuery/CoffeeScript chat implementation:
1. **Find chat dialog code:**
- Search for chat dialog/modal patterns in CoffeeScript
- Look for jQuery UI dialogs with "chat" in names
- Examine how modeless dialogs are implemented
- Document how repositioning works
2. **Message display patterns:**
- How are messages rendered (templates, loops)?
- Where do user photos come from?
- How are timestamps formatted?
- How does auto-scroll work?
3. **Message composition:**
- How is text entry handled?
- How is send button wired up?
- What validation exists?
4. **State management:**
- Where is chat state stored (Reflux stores, jQuery data, global vars)?
- How are messages cached?
- What data structures are used?
5. **Integration points:**
- How does chat integrate with session UI?
- How is the chat button managed?
- When is chat initialized?
Document findings in CHAT_LEGACY.md with:
- File paths to key components
- Code patterns used (jQuery plugins, CoffeeScript classes, Reflux stores)
- Data flow diagrams (where possible)
- Key observations and quirks
**What to avoid:** Don't try to understand EVERYTHING - focus on happy path patterns. Skip error handling details (that's for Phase 11).
</action>
<verify>
CHAT_LEGACY.md exists with sections for: Dialog implementation, Message display, Composition, State management, Integration points. File includes actual file paths and code pattern descriptions.
</verify>
<done>
CHAT_LEGACY.md documents how legacy chat works with enough detail to design React equivalent. Contains file paths, patterns, and data flow.
</done>
</task>
<task type="auto">
<name>Task 2: Document chat API surface and create CHAT_API.md</name>
<files>.planning/codebase/CHAT_API.md</files>
<action>
Map all chat-related API endpoints and jamClient methods (if any):
1. **REST API endpoints (search web/config/routes.rb, web/app/controllers/):**
- GET endpoints for fetching messages
- POST endpoint for sending messages
- PUT/PATCH endpoints for marking as read
- Data structures (request/response format)
- Authentication/authorization
2. **WebSocket messages (search websocket-gateway/, pb/src/):**
- Chat message broadcast format
- Real-time message delivery patterns
- Protocol buffer definitions (if chat uses pb)
- Message types and payloads
3. **jamClient methods (if any - search for SessionChat* or Chat* methods):**
- Any native client chat methods
- OR confirm chat is purely web-based
4. **Database models (search web/app/models/):**
- Message model fields
- Session associations
- User associations
- Any read/unread tracking fields (likely don't exist yet)
Document in CHAT_API.md with:
- Complete API reference (endpoints, methods, params, responses)
- WebSocket message catalog (types, payloads, when sent)
- Data model ERD or schema snippet
- Example requests/responses
- Notes on what's missing (like read/unread tracking)
**What to avoid:** Don't implement anything - this is documentation only. Don't worry about error responses yet (happy path focus).
</action>
<verify>
CHAT_API.md exists with sections for: REST endpoints, WebSocket messages, jamClient methods (if any), Database models. Includes example payloads and schemas.
</verify>
<done>
Complete chat API surface documented. Any developer can understand how to fetch, send, and receive messages. Missing functionality (read/unread) clearly identified.
</done>
</task>
<task type="auto">
<name>Task 3: Analyze React patterns and create CHAT_REACT_PATTERNS.md</name>
<files>.planning/codebase/CHAT_REACT_PATTERNS.md</files>
<action>
Analyze existing jam-ui patterns and identify what's available vs what needs building:
1. **Existing modal/dialog components (search jam-ui/src/components/):**
- Find WindowPortal (used by JamTrack, Metronome)
- Check JKModal, JKDialog patterns
- Understand modeless dialog patterns
- Document reusable components
2. **Redux state patterns (search jam-ui/src/store/):**
- Review mediaSlice (Backing Track, JamTrack patterns)
- Review activeSessionSlice (session state)
- Review sessionUISlice (UI state patterns)
- Identify where chat state should live
3. **WebSocket integration (search jam-ui/src/):**
- Review existing WebSocket handler patterns
- Check how MIXER_CHANGES, JAM_TRACK_CHANGES work
- Understand message routing
4. **API integration (search jam-ui/src/services/, jam-ui/src/api/):**
- Review existing API client patterns
- Check async thunk patterns from Phase 5
- Understand error handling patterns
5. **Component patterns (search jam-ui/src/components/):**
- Look at JKSessionJamTrackPlayer structure (Phase 5)
- Look at JKSessionBackingTrackPlayer structure (Phase 3)
- Identify reusable sub-component patterns (buttons, inputs, lists)
Document in CHAT_REACT_PATTERNS.md with:
- **Available Components:** What can be reused (WindowPortal, buttons, etc.)
- **Redux State Patterns:** Where chat fits in Redux architecture
- **WebSocket Integration:** How chat messages will be received
- **API Integration:** How to call chat endpoints (following established patterns)
- **Gap Analysis:** What's missing and needs to be created
- **TDD Candidates:** Which parts should follow TDD (API calls, message parsing, read/unread logic)
**What to avoid:** Don't design components yet (that's Plan 2). Don't write code. Just document what exists and identify gaps.
</action>
<verify>
CHAT_REACT_PATTERNS.md exists with sections for: Available components, Redux patterns, WebSocket integration, API integration, Gap analysis, TDD candidates. Includes file paths and pattern descriptions.
</verify>
<done>
Clear picture of what jam-ui provides for chat and what needs building. Gap analysis shows exactly what Phases 7-11 will implement. TDD candidates identified per CLAUDE.md requirements.
</done>
</task>
</tasks>
<verification>
Before declaring plan complete:
- [ ] All 3 documentation files exist in .planning/codebase/
- [ ] CHAT_LEGACY.md documents how legacy chat works (file paths, patterns, data flow)
- [ ] CHAT_API.md documents complete API surface (REST, WebSocket, models)
- [ ] CHAT_REACT_PATTERNS.md shows available patterns and gaps
- [ ] Read/unread tracking identified as NEW functionality (not in legacy)
- [ ] TDD candidates identified for implementation phases
</verification>
<success_criteria>
- All tasks completed
- Three documentation files created
- Legacy patterns thoroughly documented
- API surface completely mapped
- React integration approach identified
- Gaps clearly documented
- Ready for Plan 2 (React architecture design)
</success_criteria>
<output>
After completion, create `.planning/phases/06-session-chat-research-design/06-01-SUMMARY.md`:
# Phase 6 Plan 1: Legacy Chat Analysis & API Documentation Summary
**Documented legacy chat implementation, APIs, and React integration patterns**
## Accomplishments
- Created CHAT_LEGACY.md documenting jQuery/CoffeeScript implementation
- Created CHAT_API.md mapping REST endpoints, WebSocket messages, database models
- Created CHAT_REACT_PATTERNS.md analyzing jam-ui patterns and gaps
## Files Created/Modified
- `.planning/codebase/CHAT_LEGACY.md` - Legacy implementation analysis
- `.planning/codebase/CHAT_API.md` - Complete API reference
- `.planning/codebase/CHAT_REACT_PATTERNS.md` - React pattern analysis and gaps
## Decisions Made
[Document key findings: What patterns are used? What APIs exist? What's missing?]
## Issues Encountered
[Any surprises or complications discovered, or "None"]
## Next Phase Readiness
Ready for Plan 2 (React Architecture & Implementation Roadmap)
</output>

View File

@ -0,0 +1,340 @@
---
phase: 06-session-chat-research-design
plan: 02
type: execute
---
<objective>
Design React architecture for session chat including components, Redux state, WebSocket integration, and read/unread tracking system.
Purpose: Create comprehensive design for Phases 7-11 implementation, following established jam-ui patterns. This design phase mirrors Phase 4 Plan 2 (JamTrack Component & Redux Design).
Output: Component design, Redux design, and implementation roadmap for chat feature.
</objective>
<execution_context>
@./.claude/get-shit-done/workflows/execute-phase.md
@./.claude/get-shit-done/templates/summary.md
</execution_context>
<context>
@.planning/PROJECT.md
@.planning/ROADMAP.md
@.planning/STATE.md
@.planning/phases/06-session-chat-research-design/06-CONTEXT.md
# Plan 1 research outputs
@.planning/codebase/CHAT_LEGACY.md
@.planning/codebase/CHAT_API.md
@.planning/codebase/CHAT_REACT_PATTERNS.md
# Phase 4 pattern reference (JamTrack design)
@.planning/phases/04-jamtrack-research-design/04-02-SUMMARY.md
# Prior design patterns
@.planning/phases/05-jamtrack-implementation/05-01-SUMMARY.md
# Codebase understanding
@.planning/codebase/ARCHITECTURE.md
@.planning/codebase/CONVENTIONS.md
**Key context from Phase 6:**
- Read/unread tracking is NEW functionality not in legacy
- Modeless dialog (WindowPortal) can be kept open and repositioned
- Follow Backing Track and JamTrack patterns
- TDD required for jam-ui implementation (CLAUDE.md)
**Established patterns from prior phases:**
- Component architecture: Player component with sub-components (Phase 5)
- Redux state extensions: Multiple slices for different concerns (Phase 5)
- WebSocket handlers: Message type routing and state updates (Phase 5)
- Async thunks: API integration with error handling (Phase 3,5)
</context>
<tasks>
<task type="auto">
<name>Task 1: Design component architecture and create CHAT_COMPONENT_DESIGN.md</name>
<files>.planning/phases/06-session-chat-research-design/CHAT_COMPONENT_DESIGN.md</files>
<action>
Design JKSessionChatWindow component architecture following Phase 5 (JamTrack) patterns:
1. **Main component: JKSessionChatWindow**
- Uses WindowPortal for modeless dialog (like Metronome)
- Manages window state (open/closed, position)
- Connects to Redux for messages and state
- Handles WebSocket integration
2. **Sub-components to design:**
- **ChatMessageList** - Scrollable message container with auto-scroll
- **ChatMessage** - Single message item (photo, name, text, timestamp)
- **ChatComposer** - Text input + send button
- **ChatHeader** - Window title bar (with close, maybe minimize)
- **ChatEmptyState** - Shown when no messages
- **ChatLoadingSpinner** - While fetching message history
3. **Props vs Redux decision:**
- Which data comes from props vs Redux?
- Which callbacks are props vs dispatch?
- Follow Phase 5 patterns (JamTrack used minimal props, heavy Redux)
4. **Component hierarchy:**
```
JKSessionChatWindow (WindowPortal)
├── ChatHeader
├── ChatMessageList
│ ├── ChatLoadingSpinner (conditional)
│ ├── ChatEmptyState (conditional)
│ └── ChatMessage (repeated)
└── ChatComposer
```
5. **Reusable components:**
- Can reuse JKButton, JKAvatar, JKTimeDisplay?
- Document what's available vs what needs creating
6. **Integration with session screen:**
- Chat button in JKSessionScreen top nav
- Badge/indicator for unread count
- Click handler to toggle window
Document in CHAT_COMPONENT_DESIGN.md with:
- Component tree diagram
- Props interface for each component
- State ownership (props vs Redux)
- Reusable components identified
- File structure (where components live)
- Integration points with existing UI
**What to avoid:** Don't write actual React code. Don't implement - just design the architecture. Keep it similar to JamTrack structure for consistency.
</action>
<verify>
CHAT_COMPONENT_DESIGN.md exists with component tree, props interfaces, state ownership decisions, and integration approach documented.
</verify>
<done>
Complete component architecture designed. Developers can understand the component structure, data flow, and how to build each piece in Phases 7-11.
</done>
</task>
<task type="auto">
<name>Task 2: Design Redux state and WebSocket integration, create CHAT_REDUX_DESIGN.md</name>
<files>.planning/phases/06-session-chat-research-design/CHAT_REDUX_DESIGN.md</files>
<action>
Design Redux state extensions and WebSocket integration following Phase 5 patterns:
1. **Redux state structure:**
Decide which slice(s) to extend:
- **sessionChatSlice** (new) - messages, read/unread state
- **activeSessionSlice** extensions - current session's chat state
- **sessionUISlice** extensions - window open/closed, position
Design state shape:
```javascript
// Example structure (refine based on research)
sessionChat: {
messages: {
[sessionId]: {
byId: { [messageId]: {id, userId, text, timestamp, isRead} },
allIds: [messageIds],
isLoading: boolean,
error: string | null
}
},
unreadCounts: {
[sessionId]: number
}
}
sessionUI: {
chatWindow: {
isOpen: boolean,
position: {x, y} | null
}
}
```
2. **Async thunks to create:**
- **fetchChatMessages** - Load message history for session
- **sendChatMessage** - Post new message
- **markMessagesAsRead** - Mark messages read (new functionality)
- **openChatWindow** - Open window + mark as read
- **closeChatWindow** - Close window
- Each thunk should follow Phase 5 patterns (error handling, loading states)
3. **Selectors to create:**
- selectChatMessages(sessionId)
- selectUnreadCount(sessionId)
- selectIsChatOpen
- selectChatWindowPosition
- Memoized selectors using Reselect (like Phase 5)
4. **WebSocket message handlers:**
- **NEW_CHAT_MESSAGE** - Real-time message received
- **CHAT_MESSAGE_READ** - Message marked read by another user
- Extend existing WebSocket reducer patterns (see Phase 5: MIXER_CHANGES, JAM_TRACK_CHANGES)
- Handle message routing and state updates
5. **Read/unread tracking logic:**
- When is a message marked read? (window open, user views)
- How does unread count update? (WebSocket + local state)
- How to handle multiple tabs/windows? (server as source of truth)
- Design API calls needed (may need new endpoint: PUT /api/sessions/:id/messages/mark_read)
Document in CHAT_REDUX_DESIGN.md with:
- State shape with TypeScript interfaces
- Async thunk signatures and behavior
- Selector implementations (signatures)
- WebSocket message format and handlers
- Read/unread tracking state machine
- API integration approach
**What to avoid:** Don't implement Redux code. Design the structure, but implementation is for Phases 7-11. Ensure consistency with existing Redux patterns.
</action>
<verify>
CHAT_REDUX_DESIGN.md exists with state shape, async thunks, selectors, WebSocket handlers, and read/unread logic documented.
</verify>
<done>
Complete Redux architecture designed. Clear plan for state management, async operations, real-time updates, and read/unread tracking. Follows established jam-ui Redux patterns.
</done>
</task>
<task type="auto">
<name>Task 3: Create implementation roadmap for Phases 7-11</name>
<files>.planning/phases/06-session-chat-research-design/IMPLEMENTATION_ROADMAP.md</files>
<action>
Create detailed roadmap for Phases 7-11 following Phase 4 Plan 2 pattern (which created Phase 5 roadmap):
1. **Break down remaining phases into specific plans:**
**Phase 7: Chat Infrastructure & State Management** (suggest 2-3 plans)
- Redux slice creation and selectors
- Async thunks for API calls
- WebSocket message handlers
**Phase 8: Chat Window UI & Message Display** (suggest 2-3 plans)
- JKSessionChatWindow component with WindowPortal
- ChatMessageList and ChatMessage components
- Chat button integration in session screen
**Phase 9: Message Composition & Sending** (suggest 2 plans)
- ChatComposer component
- Send message functionality
- Real-time message delivery
**Phase 10: Read/Unread Status Management** (suggest 2 plans)
- Read/unread tracking logic
- Unread badge indicator
- Mark-as-read on window open
**Phase 11: Chat Finalization** (suggest 2-3 plans)
- Error handling and edge cases
- Performance optimization
- UAT and polish
2. **For each plan, estimate:**
- Number of tasks (target 2-3 per plan)
- Complexity (simple/medium/complex)
- Dependencies on prior plans
- TDD candidates (per CLAUDE.md requirements)
3. **Risk analysis:**
- What are the HIGH risk areas? (read/unread tracking, WebSocket reliability)
- What are the MEDIUM risk areas? (modeless dialog positioning)
- What are the LOW risk areas? (message display)
4. **TDD strategy:**
- Which features warrant TDD plans? (API thunks, message parsing, read/unread logic)
- Which use standard plans? (UI components, layout)
- Reference CLAUDE.md TDD requirements
5. **Testing approach:**
- Unit tests (Jest): Redux thunks, selectors, utility functions
- Integration tests (Playwright): API calls, message flow, read/unread behavior
- E2E tests: Complete chat workflow
6. **Deferred decisions for Phase 7-11:**
- Attachment display (next milestone)
- Message search/filtering (future)
- Message editing/deletion (future)
- Typing indicators (future)
Document in IMPLEMENTATION_ROADMAP.md with:
- Phase-by-phase breakdown (Phases 7-11)
- Plan-level detail with task estimates
- Risk analysis with mitigation strategies
- TDD strategy per CLAUDE.md
- Testing approach
- Deferred features list
**What to avoid:** Don't create the actual PLAN.md files for Phases 7-11 - that happens during their planning. This is high-level roadmap only.
</action>
<verify>
IMPLEMENTATION_ROADMAP.md exists with detailed breakdown of Phases 7-11, risk analysis, TDD strategy, and testing approach documented.
</verify>
<done>
Clear roadmap for implementing chat feature. Phases 7-11 have structured breakdown ready for plan-phase commands. TDD requirements identified. Risks documented with mitigation strategies.
</done>
</task>
</tasks>
<verification>
Before declaring phase complete:
- [ ] CHAT_COMPONENT_DESIGN.md exists with complete component architecture
- [ ] CHAT_REDUX_DESIGN.md exists with state design and WebSocket integration
- [ ] IMPLEMENTATION_ROADMAP.md exists with Phases 7-11 breakdown
- [ ] Read/unread tracking design is comprehensive (NEW functionality)
- [ ] TDD strategy documented per CLAUDE.md requirements
- [ ] All designs follow established jam-ui patterns (Backing Track, JamTrack)
- [ ] Phase 6 complete - ready for Phase 7 implementation
</verification>
<success_criteria>
- All tasks completed
- Three design documents created
- Component architecture designed (following Phase 5 patterns)
- Redux state designed (following established patterns)
- Read/unread tracking system designed (NEW)
- WebSocket integration designed
- Implementation roadmap created for Phases 7-11
- TDD strategy documented
- Phase 6 complete - ready to begin implementation
</success_criteria>
<output>
After completion, create `.planning/phases/06-session-chat-research-design/06-02-SUMMARY.md`:
# Phase 6 Plan 2: React Architecture & Implementation Roadmap Summary
**Designed React architecture, Redux state, and created implementation roadmap for Phases 7-11**
## Accomplishments
- Created CHAT_COMPONENT_DESIGN.md with component tree and integration approach
- Created CHAT_REDUX_DESIGN.md with state shape, async thunks, WebSocket handlers
- Created IMPLEMENTATION_ROADMAP.md with detailed Phase 7-11 breakdown
- Designed read/unread tracking system (NEW functionality)
- Identified TDD candidates per CLAUDE.md requirements
## Files Created/Modified
- `.planning/phases/06-session-chat-research-design/CHAT_COMPONENT_DESIGN.md` - Component architecture
- `.planning/phases/06-session-chat-research-design/CHAT_REDUX_DESIGN.md` - Redux design
- `.planning/phases/06-session-chat-research-design/IMPLEMENTATION_ROADMAP.md` - Phases 7-11 roadmap
## Decisions Made
[Document key architectural decisions: Redux state structure? Component hierarchy? WebSocket integration approach? Read/unread tracking design?]
## Issues Encountered
[Any challenges in the design process, or "None"]
## Next Phase Readiness
**Phase 6 complete!** Ready for Phase 7 (Chat Infrastructure & State Management).
Use `/gsd:plan-phase 7` to break down Phase 7 into executable plans.
</output>