updated content

Author: bidi47

docs/book/llms-full.txt

@@ -26,3 +26,8 @@ A: Yes, it has built-in reports and graphs to help you monitor your platform.
 
 **Q: What standards does Dotkernel Admin implement?**
 A: PSR-7 and PSR-15, as defined by the PHP Framework Interop Group (PHP-FIG).
+
+## See also
+
+- [Usage](usage.md) — how Admin fits alongside API and Queue.
+- [Architecture Overview](../architecture.md) — how all the platform pieces fit together.

docs/book/v1/admin/introduction.md

@@ -7,11 +7,7 @@ Explains how Dotkernel Admin fits alongside Dotkernel API and Dotkernel Queue, a
 ## Details
 
 Dotkernel Admin can be installed independently or together with other applications in the Dotkernel suite, based on your business requirements.
-These components are designed to complement each other (out-of-box they are separate codebases):
-
-- **Dotkernel API** exposes the content to 3rd-party frontends or backends.
-- **Dotkernel Admin** (optional) manages the data (create, edit, delete).
-- **Dotkernel Queue** (optional) queue management microservice.
+Out of the box, Admin, API, and Queue are separate codebases designed to complement each other — see the [Architecture Overview](../architecture.md) for how they fit together.
 
 You can start with Dotkernel Admin and integrate it into your existing platform.
 The Admin has built-in reports and graphs that can be configured and customized based on your needs.
@@ -31,3 +27,9 @@ A: No, out of the box they are separate codebases designed to complement each ot
 
 **Q: What do Dotkernel API and Dotkernel Queue add to Admin?**
 A: The API handles data manipulation for the platform, and Queue handles asynchronous task processing.
+
+## See also
+
+- [Dotkernel API: Usage](../api/usage.md)
+- [Dotkernel Queue: Usage](../queue/usage.md)
+- [Architecture Overview](../architecture.md)

docs/book/v1/admin/usage.md

@@ -7,7 +7,7 @@ An overview of Dotkernel API, the Mezzio-based REST API at the root of the Dotke
 ## Details
 
 Dotkernel API is a REST API based on the Mezzio skeleton.
-The API is the root or the Dotkernel Headless Platform.
+The API is the root of the Dotkernel Headless Platform.
 
 Dotkernel API:
 
@@ -25,3 +25,8 @@ A: It is the root of the Dotkernel Headless Platform.
 
 **Q: What standards does Dotkernel API implement?**
 A: PSR-7 and PSR-15, as defined by the PHP Framework Interop Group (PHP-FIG).
+
+## See also
+
+- [Usage](usage.md) — how API fits alongside Admin and Queue.
+- [Architecture Overview](../architecture.md) — how all the platform pieces fit together.

docs/book/v1/api/introduction.md

@@ -7,11 +7,7 @@ Explains how Dotkernel API fits alongside Dotkernel Admin and Dotkernel Queue, a
 ## Details
 
 Dotkernel API can be installed independently or together with other applications in the Dotkernel suite, based on your business requirements.
-These components are designed to complement each other (out-of-box they are separate codebases):
-
-- **Dotkernel API** exposes the content to 3rd-party frontends or backends.
-- **Dotkernel Admin** (optional) manages the data (create, edit, delete).
-- **Dotkernel Queue** (optional) queue management microservice.
+Out of the box, API, Admin, and Queue are separate codebases designed to complement each other — see the [Architecture Overview](../architecture.md) for how they fit together.
 
 A safe bet is to start with Dotkernel API and integrate it into your existing platform.
 The API can manage the access permissions to keep your data secure:
@@ -34,3 +30,9 @@ A: Admin-level users create and edit the data, while regular users read the data
 
 **Q: What can I add to Dotkernel API later?**
 A: Dotkernel Admin for its table-based management, reports and graphs, and Dotkernel Queue for asynchronous task processing.
+
+## See also
+
+- [Dotkernel Admin: Usage](../admin/usage.md)
+- [Dotkernel Queue: Usage](../queue/usage.md)
+- [Architecture Overview](../architecture.md)

docs/book/v1/api/usage.md

@@ -0,0 +1,29 @@
+# Architecture Overview
+
+## Summary
+
+Ties together the four building blocks of the Dotkernel Headless Platform — API, Admin, Queue, and the Core submodule — and shows how they combine into a single platform.
+
+## Details
+
+The [Headless Platform](introduction.md) principle is to decouple the frontend from the backend services, so any number of outside systems can consume the same backend. Dotkernel implements this with four building blocks, each its own Git repository, which you combine based on your needs:
+
+- **[Dotkernel API](api/introduction.md)** exposes your data to 3rd-party frontends or backends.
+- **[Dotkernel Admin](admin/introduction.md)** (optional) manages the data through a simple table-based UI, with built-in reports and graphs.
+- **[Dotkernel Queue](queue/introduction.md)** (optional) handles asynchronous task processing as its own microservice.
+- **[Core submodule](core/introduction.md)** is the shared codebase that any of the above applications can include, so they all manage database entities and services the same way.
+
+You don't need every piece from the start. You can begin with [just Admin](admin/usage.md) or [just API](api/usage.md) and add the others later as requirements grow. Once you're running more than one application, pull the shared logic out into a [Core submodule](core/creation.md) and include it in each one — a typical setup looks like API + Core, Admin + Core, and Queue + Core, each in its own repository, all reading from the same shared entities and services (see [Using the Core Submodule](core/usage.md)).
+
+Regardless of which pieces you use, every Dotkernel application and package boots the same way: through a [ConfigProvider](config-provider/introduction.md) that declares its dependencies, handlers, and configuration, merged together by the framework at [bootstrap time](config-provider/functionality.md).
+
+## FAQ
+
+**Q: What are the building blocks of the Dotkernel Headless Platform?**
+A: Dotkernel API, Dotkernel Admin, Dotkernel Queue, and the Core submodule.
+
+**Q: Do I need all four components to get started?**
+A: No, you can start with just Admin or just API and add the others as your requirements grow.
+
+**Q: How do multiple applications stay consistent with each other?**
+A: By sharing a Core submodule for entities and services, and by each bootstrapping through its own ConfigProvider.

docs/book/v1/architecture.md

@@ -9,9 +9,9 @@ Lists the benefits of using a ConfigProvider, including centralized, modular, co
 - **Centralized setup** – Instead of hardcoding bootstrap code, you declare it in a config provider so it's easy to read, change, or extend.
 - **Modular** – Each package can ship with its own config without interfering with others.
 - **Container-friendly** – It works well with frameworks using DI containers like Laminas ServiceManager, PHP-DI, or Pimple.
-- **Standardized service definitions** - It has consistent rules for object creation that are separate from business logic.
-- **Environment-agnostic** - It returns an array that defines dev, test, or prod environments.
-- **Testability** - The consistent, central configuration promotes isolated (e.g. per-module) testing, easier swapping of dependencies and the assertion of pipeline setup (e.g. check if a config key is present).
+- **Standardized service definitions** – It has consistent rules for object creation that are separate from business logic.
+- **Environment-agnostic** – It returns an array that defines dev, test, or prod environments.
+- **Testability** – The consistent, central configuration promotes isolated (e.g. per-module) testing, easier swapping of dependencies and the assertion of pipeline setup (e.g. check if a config key is present).
 
 > **Dotkernel ConfigProviders** have to be **added manually** in `config/config.php`, because all the initial ConfigProviders required to install the applications are already injected.
 
@@ -25,3 +25,8 @@ A: Yes, it's container-friendly and works with DI containers like Laminas Servic
 
 **Q: Do I need to register Dotkernel ConfigProviders manually?**
 A: Yes, Dotkernel ConfigProviders must be added manually in `config/config.php`.
+
+## See also
+
+- [Introduction](introduction.md)
+- [How the ConfigProvider works](functionality.md)

docs/book/v1/config-provider/benefits.md

@@ -26,7 +26,7 @@ $config = $container->get('config')['key'] ?? [];
 
 Below you can see how Mezzio and Dotkernel merge and use ConfigProviders to build the middleware pipeline and dependencies.
 
-![Headless Platform with Core Submodule](https://docs.dotkernel.org/img/headless-platform/ConfigProvider.png)
+![Diagram of Mezzio and Dotkernel merging ConfigProviders into the middleware pipeline](https://docs.dotkernel.org/img/headless-platform/ConfigProvider.png)
 
 ## FAQ
 
@@ -38,3 +38,8 @@ A: `$app->pipe()` resolves a service name from the container, wraps a middleware
 
 **Q: Why does the error-handling middleware run last in the pipeline?**
 A: So it can catch any exceptions raised by the preceding middleware.
+
+## See also
+
+- [Introduction](introduction.md)
+- [Benefits](benefits.md)

docs/book/v1/config-provider/functionality.md

@@ -68,3 +68,9 @@ A: Dotkernel API, Admin, Frontend, Light, and Packages all use ConfigProviders.
 
 **Q: Is the Dotkernel ConfigProvider approach specific to Dotkernel?**
 A: No, it follows an approach similar to Laminas/Mezzio.
+
+## See also
+
+- [How the ConfigProvider works](functionality.md)
+- [Benefits](benefits.md)
+- [Glossary](../glossary.md)

docs/book/v1/config-provider/introduction.md

@@ -27,3 +27,8 @@ A: Yes, it allows splitting the work across multiple developers.
 
 **Q: How do new applications connect to the platform?**
 A: Each new application connects via the central API, which services everything the other applications require.
+
+## See also
+
+- [Introduction](introduction.md)
+- [Using the Core Submodule](usage.md)