Merge branch 'tutorials-cross-references' of github.com:powersync-ja/mintlify-docs into tutorials-cross-references

Author: benitav

mint.json

@@ -425,6 +425,7 @@
         },
         "resources/troubleshooting",
         "resources/performance-and-limits",
+        "resources/feature-status",
         "resources/supported-hardware",
         "resources/faq",
         "resources/release-notes",
@@ -584,4 +585,4 @@
     "youtube": "https://www.youtube.com/@powersync_",
     "linkedin": "https://www.linkedin.com/showcase/journeyapps-powersync/"
   }
-}
+}

resources/feature-status.mdx

@@ -0,0 +1,13 @@
+---
+title: "Feature Status"
+description: "PowerSync feature states and their implications for factors such as API stability and support."
+---
+
+Features in PowerSync are introduced through a phased release cycle to ensure quality and stability. Below is an overview of the four release stages namely Closed Alpha, Open Alpha, Beta and Stable:
+
+| **Stage**         | **Production Readiness**                                   | **API Stability**                       | **Support**      | **Documentation**                      |
+|--------------------|-----------------------------------------------|-----------------------------------------|--------------------------|-----------------------------------------|
+| **Closed Alpha**  | Not production-ready; purpose is early feedback and testing of new ideas.      | Subject to breaking changes.            | Not covered under SLAs.             | Limited or placeholder documentation. |
+| **Open Alpha**    | Not production-ready; purpose is broader testing and wider public feedback.  | Subject to changes based on feedback.   | Not covered under SLAs.             | Basic documentation provided.        |
+| **Beta**          | Production-ready for tested use cases.       | Fully stable; breaking changes clearly communicated.  | Covered under SLAs.             | Documentation provided; may contain known gaps. |
+| **Stable**        | Production-ready for all main use cases.               | Fully stable; breaking changes clearly communicated and backward compatibility. | Covered under SLAs.      | Comprehensive and finalized documentation. |

usage/use-case-examples/prioritized-sync.mdx

@@ -3,18 +3,26 @@ title: "Prioritized Sync"
 description: "In some scenarios, you may want to sync tables using different priorities. For example, you may want to sync a subset of all tables first to log a user in as fast as possible, then sync the remaining tables in the background."
 ---
 
+<Info>
+  Note that this strategy is specifically to prioritize data on initial sync, and cannot be used for incremental sync after that.
+</Info>
+
 ## Overview
 
 The general approach is as follows:
 
 1. Define how many priority types you want - typically only two are needed: "high priority" and "the rest"
+
 2. Create a sync bucket for each priority type
+
 3. Use [client parameters](/usage/sync-rules/advanced-topics/client-parameters) to control which priorities you want the client to sync
 
 ## Example
+
 Suppose we have two tables: `lists` and `todos` (as per the standard todolist demo app [schema](/integration-guides/supabase-+-powersync#create-the-demo-database-schema)). Further, suppose we want the sync priority to behave as follows:
 
 1. First, sync all the user's lists, enabling us to render the initial screen in the app
+
 2. Then, sync the user's todos
 
 Below are the sync rules that will enable this:
@@ -36,7 +44,7 @@ bucket_definitions:
 It is recommended to set Client Parameters in the [Diagnostics App](https://github.com/powersync-ja/powersync-js/tree/main/tools/diagnostics-app) to verify functionality at this point:
 
 <Frame>
-  <img src="/images/usage/use-case-prioritized.png"/>
+  <img src="/images/usage/use-case-prioritized.png" />
 </Frame>
 
 If everything checks out, you can then proceed to implement the client parameter switching accordingly in your app.