docs: Fix todo links

docs/docs/guides/core-concepts/auth/index.md

@@ -86,7 +86,7 @@ mutation {
 ```
 
 :::info
-See the [Managing Sessions guide](/TODO) for how to manage authenticated sessions in your storefront/client applications.
+See the [Managing Sessions guide](/guides/storefront/connect-api/#managing-sessions) for how to manage authenticated sessions in your storefront/client applications.
 :::
 
 ## External authentication

docs/docs/guides/developer-guide/configuration/index.md

@@ -68,7 +68,7 @@ export const config: VendureConfig = {
 
 ### Configuring authentication
 
-Authentication settings are configured with [`VendureConfig.authOptions`](/reference/typescript-api/auth/auth-options/). The most important setting here is whether the storefront client will use cookies or bearer tokens to manage user sessions. For more detail on this topic, see [the Managing Sessions guide](/TODO).
+Authentication settings are configured with [`VendureConfig.authOptions`](/reference/typescript-api/auth/auth-options/). The most important setting here is whether the storefront client will use cookies or bearer tokens to manage user sessions. For more detail on this topic, see [the Managing Sessions guide](/guides/storefront/connect-api/#managing-sessions).
 
 The username and default password of the superadmin user can also be specified here. In production, it is advisable to use environment variables for these settings (see the following section on usage of environment variables).
 

docs/docs/guides/developer-guide/custom-fields/index.md

@@ -38,7 +38,7 @@ const config = {
 
 With the example config above, the following will occur:
 
-1. The database schema will be altered, and a column will be added for each custom field. **Note: changes to custom fields require a database migration**. See the [Migrations guide](/TODO).
+1. The database schema will be altered, and a column will be added for each custom field. **Note: changes to custom fields require a database migration**. See the [Migrations guide](/guides/developer-guide/migrations/).
 2. The GraphQL APIs will be modified to add the custom fields to the `Product` and `User` types respectively.
 3. If you are using the [AdminUiPlugin](/reference/core-plugins/admin-ui-plugin/), the Admin UI detail pages will now contain form inputs to allow the custom field data to be added or edited, and the list view data tables will allow custom field columns to be added, sorted and filtered.
 
@@ -909,7 +909,7 @@ This table shows the default form input component used for each custom field typ
 
 The Admin UI app has built-in selection components for "relation" custom fields that reference certain common entity types, such as Asset, Product, ProductVariant and Customer. If you are relating to an entity not covered by the built-in selection components, you will see a generic relation component which allows you to manually enter the ID of the entity you wish to select.
 
-If the generic selector is not suitable, or is you wish to replace one of the built-in selector components, you can create a UI extension that defines a custom field control for that custom field. You can read more about this in the [custom form input guide](/TODO)
+If the generic selector is not suitable, or is you wish to replace one of the built-in selector components, you can create a UI extension that defines a custom field control for that custom field. You can read more about this in the [custom form input guide](/guides/extending-the-admin-ui/custom-form-inputs/)
 :::
 
 ### Specifying the input component
@@ -995,7 +995,7 @@ The various configuration options for each of the built-in form input  (e.g. `su
 
 ### Custom form input components
 
-If none of the built-in form input components are suitable, you can create your own. This is a more advanced topic which is covered in detail in the [Custom Form Input Components](/TODO) guide.
+If none of the built-in form input components are suitable, you can create your own. This is a more advanced topic which is covered in detail in the [Custom Form Input Components](/guides/extending-the-admin-ui/custom-form-inputs/) guide.
 
 
 ## Tabbed custom fields

docs/docs/guides/developer-guide/overview/index.md

@@ -24,7 +24,7 @@ Vendure is built on the following open-source technologies:
 
 - **SQL Database**: Vendure requires an SQL database compatible with [TypeORM](https://typeorm.io/). Officially we support **PostgreSQL**, **MySQL/MariaDB** and **SQLite** but Vendure can also be used with API-compatible variants such [Amazon Aurora](https://aws.amazon.com/rds/aurora/), [CockroachDB](https://www.cockroachlabs.com/), or [PlanetScale](https://planetscale.com/).
 - **TypeScript & Node.js**: Vendure is written in [TypeScript](https://www.typescriptlang.org/) and runs on [Node.js](https://nodejs.org).
-- **NestJS**: The underlying framework is [NestJS](https://nestjs.com/), which is a full-featured application development framework for Node.js. Building on NestJS means that Vendure from the well-defined structure and rich feature-set and ecosystem that NestJS provides. If you are unfamiliar with NestJS, see our [NestJS for Vendure Developers guide](/TODO).
+- **NestJS**: The underlying framework is [NestJS](https://nestjs.com/), which is a full-featured application development framework for Node.js. Building on NestJS means that Vendure from the well-defined structure and rich feature-set and ecosystem that NestJS provides.
 - **GraphQL**: The Shop and Admin APIs use [GraphQL](https://graphql.org/), which is a modern API technology which allows you to specify the exact data that your client application needs in a convenient and type-safe way. Internally we use [Apollo Server](https://www.apollographql.com/docs/apollo-server/) to power our GraphQL APIs.
 - **Angular**: The Admin UI is built with [Angular](https://angular.io/), a popular, stable application framework from Google. Note that you do not need to know Angular to use Vendure, and UI extensions can even be written in the front-end framework of your choice, such as React or Vue.
 

docs/docs/guides/storefront/product-detail/index.mdx

@@ -278,7 +278,7 @@ fragment UpdatedOrder on Order {
 
 There are some important things to note about this mutation:
 
-- Because the `addItemToOrder` mutation returns a union type, we need to use a [fragment](/TODO) to specify the fields we want to return.
+- Because the `addItemToOrder` mutation returns a union type, we need to use a [fragment](/guides/getting-started/graphql-intro/#fragments) to specify the fields we want to return.
 In this case we have defined a fragment called `UpdatedOrder` which contains the fields we are interested in.
 - If any [expected errors](/guides/developer-guide/error-handling/) occur, the mutation will return an `ErrorResult` object. We'll be able to
 see the `errorCode` and `message` fields in the response, so that we can display a meaningful error message to the user.