Initial commit

.context/task2.md

@@ -0,0 +1,103 @@
+To solve the **desynchronization problem** where **Client 2 sees default state instead of current state**, the AI agent needs to implement **state synchronization on join**. Here's a detailed plan for what needs to be done, which you can feed to an AI agent or developer:
+
+---
+
+## ✅ Problem Summary
+
+* **Client 1** changes app state; changes are broadcast via WebSocket.
+* **Client 2** joins a session but does **not receive the current state** of all elements—only the default.
+* When Client 1 makes further changes, Client 2 sees them, but this causes layout inconsistency since Client 2’s other state is outdated.
+* If Client 2 makes changes, it **overwrites** the correct session state.
+
+---
+
+## 🧠 What the AI Agent Must Do
+
+### 1. **Server: Maintain the Current State per Session**
+
+* In `server.js`, ensure there is a per-session object (e.g., `{ sessionId: stateObject }`) that stores **all element states**.
+* When **Client 1** sends a change message (`{ type: 'update', payload: {...} }`), update that stored session state accordingly.
+
+#### ✅ Example in `server.js`
+
+```js
+const sessions = {}; // { [sessionId]: { state: {...}, clients: [] } }
+
+function handleMessage(message, ws, sessionId) {
+  const data = JSON.parse(message);
+  if (data.type === 'update') {
+    // Update session state
+    if (!sessions[sessionId].state) sessions[sessionId].state = {};
+    sessions[sessionId].state[data.payload.id] = data.payload;
+    
+    // Broadcast to others
+    broadcastExcept(ws, sessionId, message);
+  }
+}
+```
+
+---
+
+### 2. **Client 2: Request the Current Session State on Join**
+
+* When Client 2 connects via WebSocket, it must send a message like:
+
+```json
+{ "type": "get_state" }
+```
+
+---
+
+### 3. **Server: Respond to `get_state` with Full State Snapshot**
+
+* On receiving `{ type: 'get_state' }`, send:
+
+```json
+{ "type": "session_state", "payload": { ...allCurrentState } }
+```
+
+---
+
+### 4. **Client 2: Apply the Session State on First Load**
+
+In `useDrumMachine` (or wherever state is applied), handle a new message type:
+
+```ts
+if (message.type === 'session_state') {
+  applyFullState(message.payload); // update all controls
+}
+```
+
+---
+
+### 5. **(Optional) Mark Synchronization Complete**
+
+* Use a flag like `isSynchronized` on the client to **ignore all inputs** until the full session state is received and applied.
+
+---
+
+## 🧩 Where This Fits in Your Code
+
+* In `App.tsx`, you’re already using a `useWebSocket` hook — you’ll need to modify it so that:
+
+  * On `open`, send `get_state`.
+  * On receiving `session_state`, trigger state application.
+
+* The actual application of state will happen inside `useDrumMachine`.
+
+---
+
+## ✅ Summary Checklist
+
+| Step | Task                                                      |
+| ---- | --------------------------------------------------------- |
+| ✅    | Store session state on server per `sessionId`             |
+| ✅    | Update session state on every change                      |
+| ✅    | On new client connect, send `get_state`                   |
+| ✅    | Server responds with `session_state`                      |
+| ✅    | Client applies full session state before handling updates |
+| ⛔    | Don't allow local edits before sync is complete           |
+
+---
+
+Would you like help modifying the specific `useWebSocket` or `useDrumMachine` code to support this logic?