chore: polish public release stuff

.github/ISSUE_TEMPLATE/bug_report.yml

@@ -26,6 +26,17 @@ body:
         4. See error
     validations:
       required: true
+  - type: checkboxes
+    id: bug-confirm
+    attributes:
+      label: Bug confirmation
+      description: Make sure this is not a native bug from Perplexity.ai
+      options:
+        - label: I am not able to reproduce the issue with the extension disabled
+          required: true
+        - label: I have re-installed the extension and the issue persists
+          required: true
+
   - type: textarea
     id: expected-behavior
     attributes:
@@ -54,4 +65,4 @@ body:
       label: Additional context
       description: Add any other context about the problem here.
     validations:
-      required: false
+      required: false

docs/architecture.md

@@ -6,28 +6,25 @@ The following implementations are opinionated and may not be the best solution.
 
 ## Intercepting Websocket Messages
 
-Some magic like switching model/focus mode on the fly, or modifying collections, are done by intercepting the messages sent and received by the Perplexity.ai's websocket connection, including the fallback to long-polling.
+Some magic like switching model/focus mode on the fly, or modifying collections, is done by intercepting the messages sent and received by Perplexity.ai's websocket connection, including the fallback to long-polling.
 
 ## Custom DOM Mutation Observer
 
-Although the all LLMs' context window on Perplexity.ai is limited to roughly 32K, a thread/convo can get infinitely long, there's no limit to how many messages can be sent. And the performance of the page will degrade as the thread grows. To have extra features, while maintaining the performance, excessive use of MutationObserver guarantees to significantly slow down the page. To tackle this, Complexity has a custom implemented MutationObserver wrapper class that applies many optimizations to keep the main thread as responsive as possible.
+Although all LLMs' context windows on Perplexity.ai are limited to roughly 32K, a thread/conversation can get infinitely long; there's no limit to how many messages can be sent. The performance of the page will degrade as the thread grows due to accumulated DOM mutations from MutationObserver. There have been several attempts to optimize the MutationObserver (batching, throttling, queueing, etc.), and the performance is much better than in previous iterations of Complexity.
 
-## Communication between js contexts
+It is shown that the latest version of Complexity can work well with a thread of ~50 messages (up from 20), but it is still recommended NOT to use that many messages in a thread.
 
-Due to the restriction of the isolated context, content scripts in isolated context cannot directly access the `window` object, react fiber node data, and the Websocket class itself, which a lot of the features of Complexity rely on. Hence, Complexity implements a simple request-response communication bridge to share data between different js contexts (isolated <-> main-world) based on the `window.postMessage` API.
+## Communication between JS contexts
+
+Due to the restrictions of the isolated context, content scripts in isolated contexts cannot directly access the `window` object, React fiber node data, and the Websocket class itself, which many of Complexity's features rely on. Hence, Complexity implements a simple request-response communication bridge to share data between different JS contexts (isolated <-> main-world) based on the `window.postMessage` API.
 
 ## React
 
-Complexity UI's is rendered using React:
+Complexity's UI is rendered using React:
 
 - TailwindCSS for styling.
 - Ark-UI for headless UI components.
 
-Complexity uses a combination of @tanstack/react-query and zustand for state management:
-
-- @tanstack/react-query for overall async states: data fetching and internal communication between js contexts.
-- zustand for local states: UI states and other local states.
-
-## Why there is `jquery` dependency?
+## Why is there `jquery` dependency?
 
-- Although it is mentioned that the project uses React, `jquery` is exclusively used for direct DOM selections and manipulations of the host page. It provides much better DX than vanilla js methods.
+Although it is mentioned that the project uses React, `jquery` is exclusively used for direct DOM selections and manipulations of the host page. It provides a much better developer experience (DX) than vanilla JS methods.

src/content-script/hooks/useThreadTocObserver.ts

@@ -15,6 +15,8 @@ import { DomHelperSelectors } from "@/utils/DomSelectors";
 import UiUtils from "@/utils/UiUtils";
 import { scrollToElement } from "@/utils/utils";
 
+// TODO: refactor to use IntersectionObserver
+
 export default function useThreadTocObserver() {
   const { url } = useRouter();
 

src/content-script/index.ts

@@ -94,7 +94,7 @@ function initTrafficInterceptors() {
   WebpageMessageInterceptor.removeComplexityIdentifier();
 }
 
-async function initConsoleMessage() {
+function initConsoleMessage() {
   console.log(
     "%cCOMPLEXITY v" +
       packageData.version +

src/services/CplxApi.ts

@@ -1,6 +1,8 @@
 import { CplxVersionsApiResponse } from "@/types/update.types";
 import { fetchResource, jsonUtils } from "@/utils/utils";
 
+// TODO: migrate to main repo
+
 export default class CplxApi {
   static async fetchVersions() {
     return jsonUtils.safeParse(