release: 7.75.0

.agents/skills/ab-testing-implementation/scripts/check-ab-testing-compliance.sh

@@ -11,7 +11,7 @@ Checks changed files for A/B testing implementation compliance.
 
 Rules:
   - Fail: New ab_tests payload additions in checked code diffs
-  - Fail: Malformed literal active_ab_tests objects missing key/value
+  - Fail: Malformed literal active_ab_tests objects missing key/value/key_value_pair
   - Fail: Inline useABTest variants object missing control
   - Warn: Flag key naming mismatch for Abtest keys
   - Warn: Risky A/B integration changes without test-file updates
@@ -246,15 +246,32 @@ for file in "${CHANGED_FILES[@]}"; do
   for ((i=0; i<line_count; i++)); do
     line="${added_lines[$i]}"
 
-    # Rule: validate literal active_ab_tests payloads include both key and value.
+    # Rule: validate literal active_ab_tests payloads include key, value, and key_value_pair.
     if [[ "$line" =~ active_ab_tests[[:space:]]*: ]]; then
       if [[ "$line" =~ active_ab_tests[[:space:]]*:[[:space:]]*(\[|\{) ]]; then
-        window="$line"
-        for ((j=i+1; j<line_count && j<=i+8; j++)); do
-          window+=$'\n'"${added_lines[$j]}"
-        done
-        if ! grep -Eq 'key[[:space:]]*:' <<< "$window" || ! grep -Eq 'value[[:space:]]*:' <<< "$window"; then
-          FAILURES+=("$file: malformed literal active_ab_tests object (expected key and value).")
+        payload="$(sed -E 's/.*active_ab_tests[[:space:]]*:[[:space:]]*//; q' <<< "$line")"
+        closing_char="]"
+        if [[ "${BASH_REMATCH[1]}" == "{" ]]; then
+          closing_char="}"
+        fi
+
+        if [[ "$payload" == *"$closing_char"* ]]; then
+          payload="$(printf '%s' "$payload" | cut -d "$closing_char" -f 1)$closing_char"
+        else
+          for ((j=i+1; j<line_count && j<=i+8; j++)); do
+            next_line="${added_lines[$j]}"
+            if [[ "$next_line" == *"$closing_char"* ]]; then
+              payload+=$'\n'"$(printf '%s' "$next_line" | cut -d "$closing_char" -f 1)$closing_char"
+              break
+            fi
+            payload+=$'\n'"${next_line}"
+          done
+        fi
+
+        if grep -Eq 'key[[:space:]]*:|value[[:space:]]*:|key_value_pair[[:space:]]*:' <<< "$payload"; then
+          if ! grep -Eq 'key[[:space:]]*:' <<< "$payload" || ! grep -Eq 'value[[:space:]]*:' <<< "$payload" || ! grep -Eq 'key_value_pair[[:space:]]*:' <<< "$payload"; then
+            FAILURES+=("$file: malformed literal active_ab_tests object (expected key, value, and key_value_pair).")
+          fi
         fi
       fi
     fi
@@ -300,6 +317,9 @@ for file in "${CHANGED_FILES[@]}"; do
     while IFS= read -r quoted; do
       [[ -z "$quoted" ]] && continue
       key="${quoted:1:${#quoted}-2}"
+      if [[ "$key" =~ [[:space:]{}=] ]]; then
+        continue
+      fi
       if [[ -n "$use_abtest_literal_key" && "$key" == "$use_abtest_literal_key" ]]; then
         continue
       fi

.agents/skills/e2e-test/references/mocking.md

@@ -127,15 +127,17 @@ Add a mock for every such request to ensure test determinism.
 
 ## Features using WebSockets or complex transport
 
-Some features depend on **WebSockets** or other non-HTTP transport (e.g. Perps/HyperLiquid, real-time data). The HTTP mock server cannot intercept these. The repo uses two patterns:
+Some features depend on **WebSockets** or other non-HTTP transport (e.g. Perps/HyperLiquid, real-time data). The HTTP mock server cannot intercept these. The repo uses three patterns:
 
-1. **Controller-level mocking** — A mixin under `tests/controller-mocking/mock-config/` replaces provider SDK touchpoints so E2E runs with stable, test-controlled data. Example: `perps-controller-mixin.ts` for HyperLiquid. See **`tests/docs/CONTROLLER_MOCKING.md`** for when and how to use it.
-2. **Command queue / test server** — Tests that need to drive the app (e.g. inject state or commands) can use **`CommandQueueServer`** (`tests/framework/fixtures/CommandQueueServer.ts`). Enable it in the fixture with `useCommandQueueServer: true`. Used by Perps specs (e.g. `tests/smoke/perps/perps-add-funds.spec.ts`, `tests/regression/perps/perps-limit-long-fill.spec.ts`). The app consumes the queue in E2E context.
+1. **WebSocket mocking** — A `LocalWebSocketServer` (`tests/websocket/server.ts`) intercepts production WebSocket connections via URL rewriting in the E2E shim. Protocol-specific mocks handle subscribe/unsubscribe and push notifications. See **`tests/docs/WEBSOCKET_MOCKING.md`** for full usage guide and how to add new services. Example: `tests/websocket/account-activity-mocks.ts` for AccountActivity.
+2. **Controller-level mocking** — A mixin under `tests/controller-mocking/mock-config/` replaces provider SDK touchpoints so E2E runs with stable, test-controlled data. Example: `perps-controller-mixin.ts` for HyperLiquid. See **`tests/docs/CONTROLLER_MOCKING.md`** for when and how to use it.
+3. **Command queue / test server** — Tests that need to drive the app (e.g. inject state or commands) can use **`CommandQueueServer`** (`tests/framework/fixtures/CommandQueueServer.ts`). Enable it in the fixture with `useCommandQueueServer: true`. Used by Perps specs (e.g. `tests/smoke/perps/perps-add-funds.spec.ts`, `tests/regression/perps/perps-limit-long-fill.spec.ts`). The app consumes the queue in E2E context.
 
 **When adding support for a new feature that uses WebSockets or similar:**
 
-- Follow the **same pattern** as existing features (controller mixin and/or CommandQueueServer).
-- Implement under `tests/controller-mocking/mock-config/` or extend the command-queue protocol as needed.
+- For WebSocket services: add a service config in `tests/websocket/constants.ts` and a protocol mock. See `tests/docs/WEBSOCKET_MOCKING.md`.
+- For SDK-level mocking: implement under `tests/controller-mocking/mock-config/`.
+- For test-driven commands: extend the command-queue protocol as needed.
 - Add or update **tests/specs** that cover the mock infrastructure and the E2E flow.
 
-Prefer HTTP mocking whenever the feature’s API is plain HTTP; use controller mocking or the command server only when necessary.
+Prefer HTTP mocking whenever the feature’s API is plain HTTP; use WebSocket mocking for WS connections; use controller mocking or the command server only when necessary.