fix capitalization, add more reference links to text, and other small updates

Author: Ethan-Arrowood

learn/developers/harper-applications-in-depth.mdx

@@ -8,11 +8,11 @@ import TabItem from '@theme/TabItem';
 import HarperArchitectureDiagram from '../../src/components/learn/harper-architecture-diagram.mdx';
 import BasicAuthentication from '../../src/components/learn/basic-authentication.mdx';
 
-In the Getting Started guides you successfully installed Harper and created your first application. You experienced Harper's schema and database system, and the automatic REST API feature too. This guide dives deeper into Harper's Component Architecture differentiating applications from plugins, and introduces multiple new ways to interact with Harper. By the end of this guide you will be a confident Harper application developer capable of creating just about anything with Harper!
+In the Getting Started guides you successfully installed Harper and created your first application. You experienced Harper's schema and database system, and the automatic REST API feature too. This guide dives deeper into Harper's component architecture differentiating applications from plugins, and introduces multiple new ways to interact with Harper. By the end of this guide you will be a confident Harper application developer capable of creating just about anything with Harper!
 
 ## What You Will Learn
 
-- The fundamental concepts and architecture of Harper Applications
+- The fundamental concepts and architecture of Harper applications
 - How applications and plugins work together in the Harper ecosystem
 - The distinction between applications and plugins
 - The structure of the Harper installation
@@ -50,13 +50,13 @@ Plugins run exclusively on worker threads. Some of Harper's core services, such
 
 Harper further classifies components (plugins and applications) as either built-in or custom. **Built-in** components are internal to Harper, require no additional installation steps, and are immediately accessible for use. The `graphqlSchema` and `rest` plugins are great examples of built-in plugins. **Custom** components are external to Harper, generally available as an npm package or git repository, and do require additional installation steps in order to be used. Custom components can be authored by anyone, including Harper. Any of Harper's official custom components are published using the `@harperdb` and `@harper` package scopes, such as the [`@harperdb/nextjs`](https://github.com/HarperDB/nextjs) plugin for developing Next.js applications or the [`@harperdb/status-check`](https://github.com/HarperDB/status-check) application.
 
-Harper's reference documentation contains detailed documentation for all built-in components. Custom components will be documented within their respective repositories.
+Harper's reference documentation contains detailed documentation for all [built-in components](/docs/reference/components/built-in-extensions). Custom components are documented within their respective repositories.
 
 Harper does not currently include any built-in applications, making "custom applications" a bit redundant. Generally, we just refer to them as "applications". However, there is a multitude of both built-in and custom plugins, and so the documentation tends to specify whenever relevant.
 
 ### Harper Installation File Structure
 
-One of the founding principles of Harper is its simplicity. When you install Harper locally or are using a Fabric instance, we wanted it to be effortless to introspect your installation and understand how it works. Refer back to the previous installation guide and determine what path you installed Harper to. For many users, this path is likely within your home directory. Local, container installs likely mounted to a similar path. And Fabric users should follow along using the browser.
+One of the founding principles of Harper is its simplicity. When you install Harper locally or are using a Fabric instance, we wanted it to be effortless to introspect your installation and understand how it works. Refer back to the previous installation guide and determine what path you installed Harper to. For many users, this path is likely within your home directory. Local, container installs likely mounted to a similar path. Fabric users should follow along using the browser.
 
 Within every Harper installation are these core files and directories:
 
@@ -98,7 +98,7 @@ In the first guide, we introduced you to the `/health` endpoint. This is provide
 
 The **Operations API** provides a full set of capabilities for configuring, deploying, administering, and controlling Harper. It is configured on port `9925` by default, and primarily functions through JSON-based, POST requests to the root path `/`. It has some additional functionalities too such as the `/health` endpoint and an OpenAPI endpoint `/api/openapi/rest`.
 
-The operations API root path POST requests must be authenticated. Harper provides an `authentication.authorizeLocal` configuration option for automatically authorizing any requests from the loopback IP address as the superuser (the one created during Harper installation). This option is enabled automatically when Harper is installed using the `dev` default config (as was instructed in the getting started guide). Thus, local installation users may make unauthenticated requests. Container based installation users must use `--network host` when running the container in order to make use of this option. And Fabric or any other remote host installations generally must authenticate all requests.
+The operations API root path POST requests must be authenticated. Harper provides an `authentication.authorizeLocal` configuration option for automatically authorizing any requests from the loopback IP address as the superuser (the one created during Harper installation). This option is enabled automatically when Harper is installed using the `dev` default config (as was instructed in the getting started guide). Thus, local installation users may make unauthenticated requests. Container based installation users must use `--network host` when running the container in order to make use of this option. Fabric or any other remote host installations generally must authenticate all requests.
 
 :::note
 The `authentication.authorizeLocal` option should be disabled for any Harper servers that may be accessed by untrusted users from the same instance. For example, it should be disabled if you are using a local proxy, or for general server hardening.
@@ -118,7 +118,9 @@ All `operation` values will be in `snake_case`; all lowercase and underscores in
 
 First, ensure Harper is running (refer to the previous guide if you need a quick refresher). Then, using your HTTP client of choice, create a POST request to your running Harper instance with `Content-Type: application/json` header, and a JSON body containing `{ "operation": "get_status" }`.
 
-> Fabric users, remember to replace `http://localhost` with your Fabric instance URL, and include an authorization header.
+:::note
+Fabric users, remember to replace `http://localhost` with your Fabric instance URL, and include an authorization header.
+:::
 
 <Tabs groupId="http-client">
   <TabItem value="curl">
@@ -154,6 +156,29 @@ console.log(data);
 
 This operation returns a JSON object with three top-level properties: `restartRequired`, `systemStatus`, and `componentStatus`.
 
+```json
+{
+	"systemStatus": [
+		// ...
+	],
+	"componentStatus": [
+		{
+			"name": "http",
+			"componentName": "http",
+			"status": "healthy",
+			"lastChecked": {
+				"workers": {
+					"0": 1770141380945
+				},
+				"main": 1770141380484
+			}
+		}
+		// ...
+	],
+	"restartRequired": false
+}
+```
+
 The `restartRequired` property is a mechanism for Harper plugins to indicate they require a restart for some changes to take effect.
 
 The other two properties are lists containing status objects corresponding to different parts of Harper. These should all read `"status": "healthy"` right now, and you may recognize some of the `"name"` and `"componentName"` fields as they correspond to Harper's built-in subsystems (such as `"http"`, `"threads"`, and `"authentication"`).
@@ -162,7 +187,7 @@ The other two properties are lists containing status objects corresponding to di
 
 The Operations API is mainly intended to be used for system management purposes. It does have the ability to do data management (create/modify/query databases, tables, and records), but Harper has released significantly more ergonomic and performant methods instead.
 
-Harper keeps a reference of all operations in the Operations API reference documentation, but here a few more you can try immediately: `user_info`, `read_log`, and `describe_all`.
+Harper keeps a [reference of all operations](/docs/developers/operations-api) in the Operations API reference documentation, but here a few more you can try immediately: `user_info`, `read_log`, and `describe_all`.
 
 For `describe_all` to work, ensure that you are still running the Harper application you created in the previous guide. If you need to, checkout the [`02-rest-api`](https://github.com/HarperFast/create-your-first-application/tree/02-rest-api) branch of the `HarperFast/create-your-first-application` repository to ensure you have the necessary application files for this example.
 
@@ -305,7 +330,7 @@ In previous guides we demonstrated how to use the `harper` and `harper dev` comm
 
 There are a few more commands not listed here (check out the [CLI reference](/docs/deployments/harper-cli) if you're interested), and there is one more fun trick with the CLI.
 
-Certain operations from the Operations API are available as CLI commands! They follow the convention: `harper <operation> <param>=<value>`, and by return YAML by default. You can always pass `json=true` to see the result in JSON instead.
+Certain operations from the Operations API are available as CLI commands! They follow the convention: `harper <operation> <param>=<value>`, and return YAML by default. You can always pass `json=true` to see the result in JSON instead.
 
 We'll dive deeper in the CLI operations later for the purpose of deploying and managing your application, but for now, try out some of the operations you've already learned. Don't forget that you can append `json=true` and `| jq` to get nicely formatted JSON output.
 
@@ -328,7 +353,7 @@ Create a new file `resources.js` within your Harper application; here we are goi
 
 **Resources** are the mechanism for defining custom functionality in your Harper application. This gives you tremendous flexibility and control over how data is accessed and modified in Harper. The corresponding Resource API is a unified API for modeling different data sources within Harper as JavaScript classes. Generally, this is where the core business logic of your application lives. Database tables (the ones defined by `graphqlSchema` entries) are `Resource` classes, and so extending the function of a table is as simple as extending their class.
 
-Resource classes have methods that correspond to standard HTTP/REST methods, like `get`, `post`, `patch`, and `put` to implement specific handling for any of these methods (for tables they all have default implementations). Furthermore, by simply `export` 'ing a resource class, Harper will generate REST API endpoints for it just like the `@export` directive did in `graphqlSchema`. The Resource API is quite powerful, and we'll dive into different aspects throughout future Learn guides, but for now lets start with a simple example extending the existing `Dog` table that already exists in the application.
+Resource classes have methods that correspond to standard HTTP/REST methods, like `get`, `post`, `patch`, and `put` to implement specific handling for any of these methods (for tables they all have default implementations). Furthermore, by simply `export` 'ing a resource class, Harper will generate REST API endpoints for it just like the `@export` directive did in `graphqlSchema`. The [Resource API](/docs/reference/resources) is quite powerful, and we'll dive into different aspects throughout future Learn guides, but for now lets start with a simple example extending the existing `Dog` table that already exists in the application.
 
 Inside of `resources.js` add the following code for defining a `DogWithHumanAge` custom resource: