docs: fixes broken links and images

docs/getting-started/concepts.md

@@ -26,11 +26,11 @@ various middleware hooks are called.
 
 As you can see in the diagram, a log chain is made up of three parts:
 
-- [Log Class](adze-class.md)
+- [Log Class](../reference/log-class.md)
   - This is where all logs begin, often by calling its static methods to start a chain.
-- [Modifiers](modifiers.md)
+- [Modifiers](../reference/modifiers.md)
   - These log methods modify the instance and then return it.
-- [Terminator](default-terminators.md)
+- [Terminator](../reference/terminators.md)
   - These methods end the chain and generate the log.
 
 #### Example
@@ -50,7 +50,7 @@ log, simply call a terminator method.
 
 ### Modifiers
 
-Once you have a Log instance you can immediately [terminate](terminators) it, or you can call
+Once you have a Log instance you can immediately [terminate](../reference/terminators.md) it, or you can call
 certain methods that this library calls **modifiers**. Modifiers are methods on a Log instance
 that changes its behavior. For example, if you wanted to add a performance timestamp to your log you
 could use the `timeNow` modifier.
@@ -71,10 +71,10 @@ For documentation of all of the supported modifiers, please read the [Modifiers]
 ### Terminator
 
 In our [Modifiers](../reference/modifiers.md) example code above, you can see we ended our
-chain with [`log()`](default-terminators.md#log). The log method is one of the eight [default log terminators](default-terminators.md).
-The library also comes with [other special terminators](other-terminators.md) like
-[custom](other-terminators.md#custom). A log method is considered a terminator when it
-ends your log chain and returns a [terminated log object](data.md#terminated-log-object).
+chain with [`log()`](../reference/terminators.md#log). The log method is one of the nine [default log terminators](../reference/terminators.md).
+The library also comes with other special terminators like
+[custom](../reference/terminators.md#custom). A log method is considered a terminator when it
+ends your log chain.
 
 For more information about all of the supported terminators, please read the [Terminators](../reference/terminators.md) page of
 the [Reference Manual](../reference/introduction.md).

docs/home/universal.md

@@ -1,5 +1,5 @@
 Modern JavaScript frameworks like [NextJS](https://nextjs.org/), [NuxtJS](https://nuxt.com/), and
 [SvelteKit](https://kit.svelte.dev/) combine your "back-end" and "front-end" code in the same
 location. **Adze is universal** which means it can be executed on the
-[server side or the browser side](/guide/installation.md) without any extra considerations. Use it
-anywhere!
+[server side or the browser side](../getting-started/installation.md) without any extra
+considerations. Use it anywhere!

docs/reference/micro-frontends.md

@@ -11,16 +11,16 @@ For a more detailed explanation, please visit these excellent resources:
 
 A challenge that comes with micro-frontend architectures is enabling the parent application to be able to coordinate behaviors from the child applications. One of these challenges is logging. Within a micro-frontend architecture you will have multiple apps that are able to injected into the parent application without the parent application needing to know much about how the child application implements their features. In order to prevent chaos within the parent app, child apps typically remove all of their logs before packaging for the parent application. This keeps the browser console clean. The downside to this however is that you may need to capture some logs in production and react to them. Removing them leaves you helpless in this regard.
 
-This is where [Adze](adze-concepts.md) and [GlobalStore](globalstore-concepts.md) come in to help. Because a GlobalStore is a global cache and configuration store, it takes precedence over the configuration of any Adze logs. What this means for a micro-frontend architecture is that you can keep your logs for production and the parent application can control their behavior without knowing anything about the child application.
+This is where [Adze](../getting-started/concepts.md) and [GlobalStore](../getting-started/global-store.md) come in to help. Because a GlobalStore is a global cache and configuration store, it takes precedence over the configuration of any Adze logs. What this means for a micro-frontend architecture is that you can keep your logs for production and the parent application can control their behavior without knowing anything about the child application.
 
 ### Example Architecture
 
-![micro front end architecture example](./assets/micro-frontends-diagram.svg)
+<!-- ![micro front end architecture example](./assets/micro-frontends-diagram.svg) -->
 
 ### Explanation
 
 Within the dev environment of each of your child applications you can interact with a GlobalStore. When packaging your application for production you will leave out your GlobalStore instance and only deploy it with Adze logs. Then, in the parent application, your child applications logging behavior can be controlled by the parent app's GlobalStore instance.
 
 ## Best Practices
 
-When writing logs in your child applications you should apply a common [namespace](modifiers.md#namespace-ns) across all of them. This enables the parent application to target those logs and control them as needed.
+When writing logs in your child applications you should apply a common [namespace](../reference/modifiers.md#namespace--ns) across all of them. This enables the parent application to target those logs and control them as needed.