fixed linting

Author: bidi47

docs/book/v1/architecture.md

@@ -6,14 +6,17 @@ Ties together the four building blocks of the Dotkernel Headless Platform — AP
 
 ## 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:
+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)).
+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).
 

docs/book/v1/core/creation.md

@@ -21,7 +21,8 @@ The full steps for creating a submodule are described in [Git Tools – Submodul
 
 First create a new Git repository that will contain the Core code.
 
-> If the existing Core folder already has commit history you want to keep, extract it with a history-preserving tool such as `git subtree split` before pushing to the new repository. Simply creating an empty repository and adding it as a submodule does not carry over the folder's original history.
+> If the existing Core folder already has commit history you want to keep, extract it with a history-preserving tool such as `git subtree split` before pushing to the new repository.
+> Simply creating an empty repository and adding it as a submodule does not carry over the folder's original history.
 
 To create the submodule in an application, you need to have Git create the `.gitmodules` file in the root of the main repository by running the command below.
 Use the url from the new repository you just created instead of `<url>`:

docs/book/v1/getting-started.md

@@ -8,7 +8,8 @@ Explains the prerequisites and general installation flow for setting up a Dotker
 
 Before installing any Dotkernel application, make sure you have:
 
-- **PHP** – Dotkernel API and Admin require PHP 8.3, 8.4, or 8.5. Dotkernel Queue requires PHP 8.4 or 8.5.
+- **PHP** – Dotkernel API and Admin require PHP 8.3, 8.4, or 8.5.
+  Dotkernel Queue requires PHP 8.4 or 8.5.
 - **Composer** – used to install and manage dependencies for every Dotkernel application.
 - **A relational database** – API and Admin use Doctrine ORM, typically against a MariaDB or MySQL database (the `utf8mb4_general_ci` collation is recommended).
 - **Git** – required if you plan to share code across applications via a [Core submodule](core/creation.md).
@@ -18,16 +19,19 @@ Before installing any Dotkernel application, make sure you have:
 Both applications follow the same general installation pattern:
 
 1. Clone the application's repository into an empty project directory and install its dependencies with Composer.
-2. During installation, Composer may prompt you about registering additional ConfigProviders. Choose not to inject them — the application already includes the [ConfigProviders](config-provider/introduction.md) it needs.
+2. During installation, Composer may prompt you about registering additional ConfigProviders.
+   Choose not to inject them — the application already includes the [ConfigProviders](config-provider/introduction.md) it needs.
 3. Duplicate the distributed configuration files (for example the local and CORS configuration) into their local, non-versioned counterparts, and fill in your database connection parameters.
 4. Run the database migrations, and the fixtures if provided, to seed initial data.
 5. Enable development mode while you're building the application.
 
-> Dotkernel Admin ships with a default admin account for first login. Change its credentials before deploying to production.
+> Dotkernel Admin ships with a default admin account for first login.
+> Change its credentials before deploying to production.
 
 ### Installing Dotkernel Queue
 
-Dotkernel Queue is set up separately from API and Admin, since it centers on asynchronous message processing rather than a database-backed admin interface. Refer to the official Dotkernel Queue documentation for its installation and message transport configuration steps.
+Dotkernel Queue is set up separately from API and Admin, since it centers on asynchronous message processing rather than a database-backed admin interface.
+Refer to the official Dotkernel Queue documentation for its installation and message transport configuration steps.
 
 ## FAQ
 

docs/book/v1/glossary.md

@@ -7,10 +7,12 @@ Plain-language definitions for the standards, frameworks, and terms used through
 ## Details
 
 **ConfigProvider**
-A PHP class, part of an application's bootstrap process, that returns an array of configuration such as dependency injection mappings, request handlers, and template paths. See [ConfigProvider: Introduction](config-provider/introduction.md).
+A PHP class, part of an application's bootstrap process, that returns an array of configuration such as dependency injection mappings, request handlers, and template paths.
+See [ConfigProvider: Introduction](config-provider/introduction.md).
 
 **Core submodule**
-The shared codebase, included as a Git submodule, that centralizes database entities and services across the Dotkernel applications in your platform. See [Core: Introduction](core/introduction.md).
+The shared codebase, included as a Git submodule, that centralizes database entities and services across the Dotkernel applications in your platform.
+See [Core: Introduction](core/introduction.md).
 
 **Dependency injection (DI) container**
 A framework component (e.g. Laminas ServiceManager, PHP-DI, Pimple) that creates and wires together an application's objects based on configuration, instead of that wiring being hardcoded.
@@ -19,16 +21,19 @@ A framework component (e.g. Laminas ServiceManager, PHP-DI, Pimple) that creates
 The object-relational mapper (ORM) Dotkernel API and Admin use to manage database entities against a relational database such as MariaDB or MySQL.
 
 **Git submodule**
-A Git feature that lets one repository include another repository at a fixed path, so shared code (like the Core submodule) can be versioned and updated independently of the applications that include it. See [Creating a Core Submodule](core/creation.md).
+A Git feature that lets one repository include another repository at a fixed path, so shared code (like the Core submodule) can be versioned and updated independently of the applications that include it.
+See [Creating a Core Submodule](core/creation.md).
 
 **Headless Platform**
-An architecture that decouples the user interface (frontend) from the backend services, so the backend's responses can be consumed by any number of other systems, such as websites or mobile apps. See [Introduction](introduction.md).
+An architecture that decouples the user interface (frontend) from the backend services, so the backend's responses can be consumed by any number of other systems, such as websites or mobile apps.
+See [Introduction](introduction.md).
 
 **Mezzio**
 The PHP micro-framework, part of the Laminas project, that Dotkernel API, Admin, and Queue are all built on.
 
 **Middleware**
-A unit of code that sits in a request/response pipeline, able to handle a request and return a response, or delegate to the next middleware in line. Dotkernel applications use a PSR-Compliant Middleware Stack for this.
+A unit of code that sits in a request/response pipeline, able to handle a request and return a response, or delegate to the next middleware in line.
+Dotkernel applications use a PSR-Compliant Middleware Stack for this.
 
 **Monolith**
 A single, tightly coupled codebase where features aren't separated into independent modules — the usual starting point for a [Modular Refactoring](migration/modular-refactoring.md).
@@ -46,4 +51,5 @@ The PSR specification defining HTTP server request handlers and middleware inter
 Moving a software system to a new infrastructure or environment — for example, from on-premises servers to the cloud — as part of a broader [migration](migration/introduction.md).
 
 **Stratigility**
-The Laminas library that implements the middleware pipeline Mezzio applications run on, iterating over registered middleware in order until a response is returned. See [How the ConfigProvider works](config-provider/functionality.md).
+The Laminas library that implements the middleware pipeline Mezzio applications run on, iterating over registered middleware in order until a response is returned.
+See [How the ConfigProvider works](config-provider/functionality.md).

docs/book/v1/migration/choosing-a-strategy.md

@@ -8,11 +8,11 @@ A decision guide comparing the Full Rewrite, Modular Refactoring, and Strangler
 
 Each [migration strategy](introduction.md) documented in this section trades off risk, timeline, and cost differently:
 
-| | [Full Rewrite](full-rewrite.md) | [Modular Refactoring](modular-refactoring.md) | [Strangler Fig](strangler-fig.md) |
-|---|---|---|---|
-| Risk | High — no partial rollback | Moderate — contained to one module at a time once modularized | Low — each change is small and reversible |
-| Timeline | Long, with no value delivered until launch | Long upfront preparation, then incremental | Incremental, with continuous delivery |
-| Team size | Can be smaller, but works in isolation from the live system | Can scale across teams once modules are defined | Can be smaller, since work is isolated by feature |
+|                 | [Full Rewrite](full-rewrite.md)                                                    | [Modular Refactoring](modular-refactoring.md)                                | [Strangler Fig](strangler-fig.md)                                      |
+|-----------------|------------------------------------------------------------------------------------|------------------------------------------------------------------------------|------------------------------------------------------------------------|
+| Risk            | High — no partial rollback                                                         | Moderate — contained to one module at a time once modularized                | Low — each change is small and reversible                              |
+| Timeline        | Long, with no value delivered until launch                                         | Long upfront preparation, then incremental                                   | Incremental, with continuous delivery                                  |
+| Team size       | Can be smaller, but works in isolation from the live system                        | Can scale across teams once modules are defined                              | Can be smaller, since work is isolated by feature                      |
 | Best suited for | Small or simple systems, or codebases too tightly coupled to migrate incrementally | Large, tightly coupled monoliths that need to be decomposed before migrating | Complex, business-critical legacy systems that can't tolerate downtime |
 
 As a general rule:

docs/book/v1/queue/usage.md

@@ -6,9 +6,11 @@ Explains how Dotkernel Queue fits alongside Dotkernel API and Dotkernel Admin, a
 
 ## Details
 
-Dotkernel Queue can be installed independently or alongside other applications in the Dotkernel suite, based on your business requirements. Like API and Admin, it is a separate codebase designed to complement the others — see the [Architecture Overview](../architecture.md) for how the three fit together.
+Dotkernel Queue can be installed independently or alongside other applications in the Dotkernel suite, based on your business requirements.
+Like API and Admin, it is a separate codebase designed to complement the others — see the [Architecture Overview](../architecture.md) for how the three fit together.
 
-Add Dotkernel Queue once you have work that shouldn't run inline with a request, such as sending bulk emails, generating reports, or processing uploads. Your API or Admin application dispatches a message, and Queue processes it asynchronously in the background, independent of the request/response cycle.
+Add Dotkernel Queue once you have work that shouldn't run inline with a request, such as sending bulk emails, generating reports, or processing uploads.
+Your API or Admin application dispatches a message, and Queue processes it asynchronously in the background, independent of the request/response cycle.
 
 Because Queue is its own microservice, it can be deployed and scaled separately from API and Admin, and it can consume messages produced by either one.