diff --git a/.story_kit/work/1_upcoming/136_bug_broadcast_channel_silently_drops_events_on_subscriber_lag.md b/.story_kit/work/1_upcoming/136_bug_broadcast_channel_silently_drops_events_on_subscriber_lag.md
new file mode 100644
index 0000000..54fa3ba
--- /dev/null
+++ b/.story_kit/work/1_upcoming/136_bug_broadcast_channel_silently_drops_events_on_subscriber_lag.md
@@ -0,0 +1,29 @@
+---
+name: "Broadcast channel silently drops events on subscriber lag"
+---
+
+# Bug 136: Broadcast channel silently drops events on subscriber lag
+
+## Description
+
+The watcher broadcast channel (capacity 1024) silently drops events when a subscriber lags behind. In the WebSocket handler, the `Lagged` error is caught and handled with a bare `continue`, meaning the frontend never receives those state updates and falls out of sync.
+
+## How to Reproduce
+
+1. Open the web UI
+2. Start agents that generate pipeline state changes
+3. If the WebSocket consumer is momentarily slow (e.g., blocked on send), the broadcast subscriber falls behind
+4. Lagged events are silently skipped
+
+## Actual Result
+
+Events are silently dropped with `continue` on `RecvError::Lagged`. The frontend misses state transitions and shows stale data.
+
+## Expected Result
+
+When a lag occurs, the system should recover by re-sending the full current pipeline state so the frontend catches up, rather than silently dropping events.
+
+## Acceptance Criteria
+
+- [ ] Lagged broadcast events trigger a full state resync to the affected subscriber
+- [ ] No silent event drops — lag events are logged as warnings