docs: Post review fixes

docs/source/caching/cache-key-resolution.mdx

@@ -88,7 +88,7 @@ If the JSON response `object` has no `id` field, the function returns `nil` and
 
 #### JSON value convenience initializer
 
-Alternatively, you can use the [`init(jsonValue:uniqueKeyGroup:)`](https://www.apollographql.com/docs/ios/docc/documentation/apolloapi/cachekeyinfo/init(jsonvalue:uniquekeygroupid:)) convenience initializer. This initializer attempts to use the value of a key in the JSON response, throwing an error if the key does not exist.
+Alternatively, you can use the [`init(jsonValue:uniqueKeyGroup:)`](https://www.apollographql.com/docs/ios/docc/documentation/apolloapi/cachekeyinfo/init(jsonvalue:uniquekeygroup:)) convenience initializer. This initializer attempts to use the value of a key in the JSON response, throwing an error if the key does not exist.
 
 If you want to return `nil` when the value does not exist, you can use `try?`.
 

docs/source/fetching/fetching-data.mdx

@@ -191,7 +191,7 @@ The cache polices which you can specify are:
   - This is the most common use case, and is the most performant method if your data is not expected to change.
   - If you do not need to check for updates to data once it's been fetched, you should usually use this cache policy.
 
-> If you're interested in returning cached data after a failed fetch, the current recommended approach is to use an `additionalErrorInterceptor` on your interceptor chain to examine if the error is one it makes sense to show old data for rather than something that needs to be passed on to the user, and then retrying with a `.returnCacheDataDontFetch` retry policy. An example of this setup can be found in the [Cache-dependent interceptor tests](https://github.com/apollographql/apollo-ios/blob/main/Tests/ApolloTests/Cache/CacheDependentInterceptorTests.swift).
+> If you're interested in returning cached data after a failed fetch, the current recommended approach is to use an `additionalErrorInterceptor` on your interceptor chain to examine if the error is one it makes sense to show old data for rather than something that needs to be passed on to the user, and then retrying with a `.returnCacheDataDontFetch` retry policy. An example of this setup can be found in the [Cache-dependent interceptor tests](https://github.com/apollographql/apollo-ios-dev/blob/main/Tests/ApolloTests/Cache/CacheDependentInterceptorTests.swift).
 
 For more information on how result data is stored in the cache data or how to configure the normalized cache, see the [Caching documentation](./../caching/introduction).
 

docs/source/fetching/operation-arguments.mdx

@@ -4,7 +4,7 @@ title: Operation Arguments
 
 GraphQL operations can define arguments as part of their definitions, the values of these arguments can be passed to field arguments or directive arguments (eg. `@skip` and `@include`).
 
-Apollo iOS generates type-safe initializers for your operation that accept your operation's arguments. These arguments can be [built-in scalar types](https://graphql.org/learn/schema/#scalar-types), [custom scalars](./../custom-scalars), [enums](./../enums), or [input objects](./../input-objects) defined in your schema.
+Apollo iOS generates type-safe initializers for your operation that accept your operation's arguments. These arguments can be [built-in scalar types](https://graphql.org/learn/schema/#scalar-types), [custom scalars](./../custom-scalars), [enums](https://graphql.org/learn/schema/#enumeration-types), or [input objects](https://graphql.org/learn/schema/#input-types) defined in your schema.
 
 Let's say we define a GraphQL query named `HeroName` with an `episode` argument which is a custom `Episode` enum defined in our schema:
 

docs/source/project-configuration/modularization.mdx

@@ -19,7 +19,7 @@ Alternatively you may use a single target configuration with a multi-module proj
 
 ---
 
-For a single target project configuration, you can link your target to the `Apollo` library. You can also optionally link to [`ApolloSQLite`](#apollosqlite) and/or [`ApolloWebSocket`](#apollowebsocket) to enable their functionality.
+For a single target project configuration, you can link your target to the `Apollo` library. You can also optionally link to [`ApolloSQLite`](./sdk-components#apollosqlite) and/or [`ApolloWebSocket`](./sdk-components#apollowebsocket) to enable their functionality.
 
 > For more information about the libraries that make up the Apollo iOS SDK, see the [Apollo iOS SDK](./sdk-components).
 

docs/source/project-configuration/schema-types.mdx

@@ -25,7 +25,7 @@ Wherever you place your schema types, they will need to be linked to by any modu
 
 ## Schema module
 
-For most projects, we recommend creating a "schema module" to contain your schema types. This enables you to share your generated models across modules as your project grows. You can use either the [`.swiftPackageManager`](#swiftpackagemanager) or [`.other`](#other-module) options to create a schema module.
+For most projects, we recommend creating a "schema module" to contain your schema types. This enables you to share your generated models across modules as your project grows. You can use either the [`.swiftPackageManager`](#swiftpackagemanager) or [`.other`](#other) options to create a schema module.
 
 With this approach your schema types will be `public` top-level symbols in a module using the provided `schemaNamespace` as the module name.