fix docs links

packages/docs/src/pages/client-options.mdx

@@ -4,9 +4,9 @@
 
 These options define your local cache.
 
-- `migrations` is a list of migrations to run on the local cache (which will define a schema, see [Schema](/schema))
+- `migrations` is a list of migrations to run on the local cache (which will define a schema, see [Schema](/schemas))
 - `schema` is a hard coded schema for your local cache
-- `storage` determines the storage engines for your local cache (see [Storage](/storage))
+- `storage` determines the storage engines for your local cache (see [Storage](/client-database/storage))
 
 ## Sync options
 

packages/docs/src/pages/fetching-data/fetch.mdx

@@ -34,7 +34,7 @@ const queryEmpty = client
 const resultEmpty = await client.fetchOne(queryEmpty); // null
 ```
 
-This is a convenient shorthand for using the [limit parameter](/queries#limit) `.limit(1)` and extracting the result from the result set.
+This is a convenient shorthand for using the [limit parameter](/fetching-data/queries#limit) `.limit(1)` and extracting the result from the result set.
 
 ## FetchById
 
@@ -49,7 +49,7 @@ const leela = await client.fetchById('employees', 'Leela', options); // { name:
 const bender = await client.fetchById('employees', 'Bender', options); // null
 ```
 
-This is a convenient shorthand for using the [entityId parameter](/queries#entity-id) `.entityId(id)` and extracting the result from the result set.
+This is a convenient shorthand for using the [entityId parameter](/fetching-data/queries#entity-id) `.entityId(id)` and extracting the result from the result set.
 
 ## Fetch options
 
@@ -62,8 +62,9 @@ If no options are provided, queries will be fulfilled with the options `{ policy
 The `policy` option determines how you interact with your local and remote databases.
 
 <Callout type="info" emoji="ℹ️">
-  This is distinct from the [syncState](/queries#sync-state) parameter on a
-  query, which indicates how you wish to query your local database.
+  This is distinct from the [syncState](/fetching-data/queries#sync-state)
+  parameter on a query, which indicates how you wish to query your local
+  database.
 </Callout>
 
 The following policy types are valid:

packages/docs/src/pages/fetching-data/queries.mdx

@@ -127,7 +127,7 @@ const query = client
   .limit(10);
 ```
 
-As a convenience, Triplit also provides a method [fetchOne](/fetching#fetch) to fetch just the first entity of a query result.
+As a convenience, Triplit also provides a method [fetchOne](/fetching-data/fetch#fetchone) to fetch just the first entity of a query result.
 
 ## Variables
 
@@ -152,7 +152,7 @@ Certain variables are used internally by Triplit to aid with authorization and o
 
 ## Sync state
 
-Triplit's client [storage](/storage) is split into two areas - an outbox for unsynced updates and a cache for synced updates. Sometimes you may want to indicate that to a user that data has not yet been saved to the server. To do this, you can use the `syncStatus` method. This method accepts a single sync state (`pending`, `confirmed`, `all`) as an argument.
+Triplit's client [storage](/client-database/storage) is split into two areas - an outbox for unsynced updates and a cache for synced updates. Sometimes you may want to indicate that to a user that data has not yet been saved to the server. To do this, you can use the `syncStatus` method. This method accepts a single sync state (`pending`, `confirmed`, `all`) as an argument.
 
 For example, a messaging app could use two queries to build message sent indicators. In [React](/frameworks/react):
 
@@ -197,4 +197,4 @@ You may also pass a DB variable to `entityId`.
 const query = client.query('users').entityId('$userId');
 ```
 
-As a convenience, Triplit also provides a method [fetchById](/fetching#fetch) to fetch an entity by its id.
+As a convenience, Triplit also provides a method [fetchById](/fetching-data/fetch#fetchbyid) to fetch an entity by its id.

packages/docs/src/pages/fetching-data/subscriptions.mdx

@@ -19,4 +19,4 @@ const unsubscribe = client.subscribe(
 );
 ```
 
-If a subscription query fails on the server then syncing for that query will stop. However, the subscription will remain active and updates to the local database will still be available. As well, the syncing of other queries will not be impacted. Although you will not recieve updates from the server, updates that you make via [mutations](/mutations) will be sent.
+If a subscription query fails on the server then syncing for that query will stop. However, the subscription will remain active and updates to the local database will still be available. As well, the syncing of other queries will not be impacted. Although you will not recieve updates from the server, updates that you make via [mutations](/updating-data) will be sent.

packages/docs/src/pages/getting-started.mdx

@@ -41,7 +41,7 @@ Alternatively, you may manually install the packages you need.
 
 ## Setting up your client
 
-A Triplit Client instance will set up a local database for your data and ([if turned on](/sync-engine)) will set up the required network connections for syncing. The specifics of your local database and syncing can be configured by passing in options to the client, which are described in the [client options reference](/client-options). For now we will not pass in any options, which will just set up an in-memory local database.
+A Triplit Client instance will set up a local database for your data and ([if turned on](/sync)) will set up the required network connections for syncing. The specifics of your local database and syncing can be configured by passing in options to the client, which are described in the [client options reference](/client-options). For now we will not pass in any options, which will just set up an in-memory local database.
 
 ```typescript
 import { TriplitClient } from '@triplit/client';

packages/docs/src/pages/guides/auth.mdx

@@ -2,7 +2,7 @@
 
 ## Authentication
 
-Many apps require a way to authenticate users. Triplit is configured to look for certain [variables](/queries#variables) to determine who is making a request. This information is then used to inform the [authorization](#authorization) process.
+Many apps require a way to authenticate users. Triplit is configured to look for certain [variables](/fetching-data/queries#variables) to determine who is making a request. This information is then used to inform the [authorization](#authorization) process.
 
 Authentication itself should be handled by an authentication service outside of Triplit. This could be a third-party service like [Auth0](https://auth0.com/), [Firebase Auth](https://firebase.google.com/products/auth), [AWS Cognito](https://aws.amazon.com/cognito/), [Supabse Auth](https://supabase.com/docs/guides/auth), etc or a custom service built by your team. The authentication service should provide a way to generate a token with Triplit specific claims that can be used to identify the user.
 
@@ -17,6 +17,6 @@ With these claims, Triplit can assign the special variable `$SESSION_USER_ID` in
 
 Triplit allows you to define rules on your collections that determine who can read and write data. These rules are defined in the `rules` property of your collection's schema.
 
-Rules are defined as [filter clauses](/queries#filtering) that are applied to a query's result. For example, a write rule `[['author', '=', '$SESSION_USER_ID']]` on a collection `todos` would only allow users to assign themselves as the author of a todo.
+Rules are defined as [filter clauses](/fetching-data/queries#filtering) that are applied to a query's result. For example, a write rule `[['author', '=', '$SESSION_USER_ID']]` on a collection `todos` would only allow users to assign themselves as the author of a todo.
 
-Rules can be defined with [migrations](/schemas#migrations) or in your project's [Dashboard](https://www.triplit.dev/dashboard) (coming soon).
+Rules can be defined with [migrations](/guides/migrations) or in your project's [Dashboard](https://www.triplit.dev/dashboard) (coming soon).

packages/docs/src/pages/schemas.mdx

@@ -55,7 +55,7 @@ const client = new TriplitClient({
 });
 ```
 
-Passing a schema to the client constructor will override any schema currently stored in your cache. You may also manage your schema with migrations, as explained in the [Migrations](#migrations) section. Using migrations is recommended for production applications that persist state locally or use syncing.
+Passing a schema to the client constructor will override any schema currently stored in your cache. You may also manage your schema with migrations, as explained in the [Migrations](/guides/migrations) section. Using migrations is recommended for production applications that persist state locally or use syncing.
 
 ### id
 

packages/docs/src/pages/updating-data.mdx

@@ -26,7 +26,7 @@ await client.update('employee', 'Fry', async (entity) => {
 
 If possible, `update` will look at the schema you have provided to provide proper type hints for interacting with you data. If no schema is provided, all fields are treated as `any`.
 
-See [here](/docs/schema#data-types) for more information on data types.
+See [here](/schemas#data-types) for more information on data types.
 
 ### Delete