updated faq - added empty line

docs/book/v1/admin/introduction.md

@@ -19,12 +19,15 @@ Dotkernel Admin:
 ## FAQ
 
 **Q: What is Dotkernel Admin?**
+
 A: It's a skeleton application for quickly setting up an administration site to manage records in your database.
 
 **Q: Does Dotkernel Admin include reporting features?**
+
 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

docs/book/v1/admin/usage.md

@@ -20,12 +20,15 @@ Later on you can add:
 ## FAQ
 
 **Q: Can Dotkernel Admin be used on its own?**
+
 A: Yes, it can be installed independently and integrated into your existing platform.
 
 **Q: Are Dotkernel Admin, API, and Queue part of the same codebase?**
+
 A: No, out of the box they are separate codebases designed to complement each other.
 
 **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

docs/book/v1/api/introduction.md

@@ -18,12 +18,15 @@ Dotkernel API:
 ## FAQ
 
 **Q: What is Dotkernel API built on?**
+
 A: It's a REST API based on the Mezzio skeleton.
 
 **Q: What role does Dotkernel API play in the Headless Platform?**
+
 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

docs/book/v1/api/usage.md

@@ -23,12 +23,15 @@ Later on you can add:
 ## FAQ
 
 **Q: Should I start with Dotkernel API or Admin?**
+
 A: Starting with Dotkernel API is a safe bet since it can manage access permissions to keep your data secure.
 
 **Q: How does Dotkernel API separate admin and regular users?**
+
 A: Admin-level users create and edit the data, while regular users read the data for your frontend.
 
 **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

docs/book/v1/architecture.md

@@ -23,10 +23,13 @@ Regardless of which pieces you use, every Dotkernel application and package boot
 ## 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/config-provider/benefits.md

@@ -18,12 +18,15 @@ Lists the benefits of using a ConfigProvider, including centralized, modular, co
 ## FAQ
 
 **Q: Why use a ConfigProvider instead of hardcoding bootstrap code?**
+
 A: It centralizes configuration so it's easy to read, change, or extend.
 
 **Q: Does a ConfigProvider work with dependency injection containers?**
+
 A: Yes, it's container-friendly and works with DI containers like Laminas ServiceManager, PHP-DI, or Pimple.
 
 **Q: Do I need to register Dotkernel ConfigProviders manually?**
+
 A: Yes, Dotkernel ConfigProviders must be added manually in `config/config.php`.
 
 ## See also

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

@@ -31,12 +31,15 @@ Below you can see how Mezzio and Dotkernel merge and use ConfigProviders to buil
 ## FAQ
 
 **Q: When is the ConfigProvider picked up?**
+
 A: Automatically, by the framework during application bootstrap.
 
 **Q: What happens during the "Resolve item" step?**
+
 A: `$app->pipe()` resolves a service name from the container, wraps a middleware array, or calls a closure/invokable object.
 
 **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

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

@@ -61,12 +61,15 @@ All Dotkernel applications and packages use ConfigProviders:
 ## FAQ
 
 **Q: What does a ConfigProvider return in Dotkernel?**
+
 A: Dependency injection mappings, request handlers, and template file paths.
 
 **Q: Which Dotkernel applications use ConfigProviders?**
+
 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

docs/book/v1/core/benefits.md

@@ -20,12 +20,15 @@ This ensures consistency throughout your platform, while allowing any number of
 ## FAQ
 
 **Q: How does the Core submodule pattern help as a platform grows?**
+
 A: It provides design flexibility and scalability suited for both enterprise and smaller applications.
 
 **Q: Can multiple developers work on the platform using this pattern?**
+
 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

docs/book/v1/core/creation.md

@@ -60,18 +60,23 @@ git submodule update
 ## FAQ
 
 **Q: Where can I find the full steps for creating a Git submodule?**
+
 A: In the official Git documentation, [Git Tools – Submodules](https://git-scm.com/book/en/v2/Git-Tools-Submodules).
 
 **Q: What command creates a submodule in an application?**
+
 A: `git submodule add <url>`, using the URL of the new Core repository.
 
 **Q: How do I get the submodule after cloning the project?**
+
 A: Run `git submodule init` followed by `git submodule update`.
 
 **Q: Should I keep the existing Core module after adding the submodule?**
+
 A: No, delete the existing Core module before adding the submodule to other applications.
 
 **Q: Will I lose the Core folder's Git history when I create the submodule?**
+
 A: Yes, unless you extract it first with a history-preserving tool such as `git subtree split` — simply creating an empty repository and adding it as a submodule does not carry over the folder's original history.
 
 ## See also

docs/book/v1/core/introduction.md

@@ -23,12 +23,15 @@ General rules:
 ## FAQ
 
 **Q: Can the same Core submodule be used across multiple applications?**
+
 A: Yes, it can be included in any combination of APIs, Admins, and Frontends in your project.
 
 **Q: What is the golden rule for the Core codebase?**
+
 A: It's the only place that manages the database entities.
 
 **Q: Where is the Core submodule located?**
+
 A: At `src/Core`.
 
 ## See also

docs/book/v1/core/usage.md

@@ -33,12 +33,15 @@ Whenever you create new shared code, you should add it in the Core submodule and
 ## FAQ
 
 **Q: What does a platform using the Core submodule look like?**
+
 A: Each application (API, Admin, Queue) pairs with Core, with each box being a separate Git repository.
 
 **Q: Should all new code go into Core?**
+
 A: No, only shared code should go into Core — functionality used by only one application can stay in that application.
 
 **Q: What kinds of entities are already split between applications?**
+
 A: For example, Admin has admins, admin logins, and settings entities, while API has users, admins, and authentication entities.
 
 ## See also

docs/book/v1/getting-started.md

@@ -36,13 +36,17 @@ Refer to the official Dotkernel Queue documentation for its installation and mes
 ## FAQ
 
 **Q: What PHP version do I need?**
+
 A: PHP 8.3, 8.4, or 8.5 for Dotkernel API and Admin; PHP 8.4 or 8.5 for Dotkernel Queue.
 
 **Q: What database does Dotkernel use?**
+
 A: API and Admin use Doctrine ORM, typically against a MariaDB or MySQL database.
 
 **Q: Why am I prompted about ConfigProviders during installation?**
+
 A: Composer may ask whether to inject additional ConfigProviders — decline, since the application's required ConfigProviders are already included.
 
 **Q: Do I need to configure anything before running the application for the first time?**
+
 A: Yes — duplicate the distributed local configuration files, fill in your database connection details, run migrations (and fixtures, if provided), and change any default credentials before production use.

docs/book/v1/introduction.md

@@ -21,12 +21,15 @@ Here are some advantages of the Headless Platform:
 ## FAQ
 
 **Q: What is the core principle of a Headless Platform?**
+
 A: Decoupling the User Interface (frontend) from the backend services.
 
 **Q: Who consumes the platform's responses?**
+
 A: Another system, such as a website or mobile app.
 
 **Q: What are the advantages of this design?**
+
 A: It allows multiple frontends targeted to different end-users, niches, and countries, each customizable in design and features.
 
 ## See also

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

@@ -26,10 +26,13 @@ In practice, Modular Refactoring and the Strangler Fig Pattern are often used to
 ## FAQ
 
 **Q: Which migration strategy has the lowest risk?**
+
 A: The Strangler Fig Pattern, since each change is small, reversible, and easy to test in isolation.
 
 **Q: When does a Full Rewrite make sense?**
+
 A: Mainly for small or simple systems, or when the existing codebase is too tightly coupled for an incremental migration to be practical.
 
 **Q: How do Modular Refactoring and the Strangler Fig Pattern relate?**
+
 A: Modular Refactoring prepares a large, tightly coupled codebase for migration by breaking it into modules; the Strangler Fig Pattern is then typically used to carry out the actual migration, module by module.

docs/book/v1/migration/full-rewrite.md

@@ -41,12 +41,15 @@ You may find yourself delaying its implementation until you are forced to do so
 ## FAQ
 
 **Q: What is a Full Rewrite migration strategy?**
+
 A: Completely rebuilding the system from scratch in the new architecture or technology.
 
 **Q: What is the biggest risk of a full rewrite?**
+
 A: High risk — the release must work on the first try, with no partial rollback.
 
 **Q: Why might a full rewrite be expensive?**
+
 A: Building a second product in parallel can prove just as costly as the original product.
 
 ## See also

docs/book/v1/migration/introduction.md

@@ -25,12 +25,15 @@ It is also the perfect opportunity to implement modern design patterns recommend
 ## FAQ
 
 **Q: What does "migration" primarily refer to?**
+
 A: The transfer of functionality (the codebase) from one platform to another, e.g. from MVC to middleware.
 
 **Q: What else can a complex platform migration include?**
+
 A: Replatforming, refactoring, and database or storage migration.
 
 **Q: Why is migration a good opportunity beyond just moving code?**
+
 A: It's a chance to implement modern design patterns recommended by the development community.
 
 ## See also

docs/book/v1/migration/modular-refactoring.md

@@ -43,12 +43,15 @@ For the actual code migration, you can opt for the Strangler Fig Pattern.
 ## FAQ
 
 **Q: What is Modular Refactoring?**
+
 A: Breaking a large, tightly coupled codebase into smaller, independent modules before migrating them.
 
 **Q: Can teams work on Modular Refactoring in parallel?**
+
 A: Yes, it enables parallel work — different teams can migrate different modules at the same time.
 
 **Q: What pattern is recommended for the actual code migration after modularizing?**
+
 A: The Strangler Fig Pattern.
 
 ## See also

docs/book/v1/migration/strangler-fig.md

@@ -35,12 +35,15 @@ The development team can be smaller (since you isolate sections of code you work
 ## FAQ
 
 **Q: What is the Strangler Fig Pattern?**
+
 A: A migration strategy that gradually replaces parts of the old application with new components until the old one is no longer needed.
 
 **Q: What must be in place for the Strangler Fig Pattern to work?**
+
 A: The ability to intercept requests and redirect execution via a routing layer.
 
 **Q: Why is this pattern recommended for complex legacy applications?**
+
 A: It mitigates downtime and risk by handling small, manageable sections of code at a time.
 
 ## See also

docs/book/v1/queue/introduction.md

@@ -19,12 +19,15 @@ Dotkernel Queue:
 ## FAQ
 
 **Q: What is Dotkernel Queue?**
+
 A: A standalone microservice for processing asynchronous tasks, separate from your API or Admin application.
 
 **Q: What is Dotkernel Queue built on?**
+
 A: The Mezzio microframework, using Laminas Messenger to dispatch and handle messages.
 
 **Q: Why would I use Dotkernel Queue?**
+
 A: To offload slow or non-critical work, such as sending emails, generating exports, or processing uploads, so it doesn't block the request/response cycle.
 
 ## See also

docs/book/v1/queue/usage.md

@@ -17,12 +17,15 @@ Because Queue is its own microservice, it can be deployed and scaled separately
 ## FAQ
 
 **Q: Can Dotkernel Queue be used on its own?**
+
 A: Yes, it can be installed independently, though it's most useful once another application (API or Admin) is producing messages for it to process.
 
 **Q: When should I add Dotkernel Queue to my platform?**
+
 A: Once you have work that shouldn't run inline with a request, such as sending bulk emails, generating reports, or processing uploads.
 
 **Q: Can Dotkernel Queue be scaled independently of API and Admin?**
+
 A: Yes, since it's a separate microservice, it can be deployed and scaled on its own.
 
 ## See also