Add missing .md files. Author entity updated with github

bin/doctrine-fixtures

@@ -33,6 +33,6 @@ $executor = new ORMExecutor($entityManager, $purger);
 
 echo "Loading fixtures from: {$fixturesPath}\n";
 
-$executor->execute($loader->getFixtures());
+$executor->execute($loader->getFixtures(), true);
 
-echo "Fixtures loaded successfully!\n";
+echo "Fixtures loaded successfully!\n";

public/readme/android/listen-for-android-install-referrer.md → public/llms-content/android/listen-for-android-install-referrer.md

@@ -12,12 +12,15 @@ language: "en"
 
 ## Getting Referrer Data at Install Time
 
-Android market sends information at the moment of app install, delivered as a broadcasted intent by Android market at install time - even before the app is opened for the first time. This can be used to create custom links to an Android application, including bits of information about the referrer, sent directly to the app for processing at install. It can be a simple and accurate solution for mobile app install tracking, among other uses.
+Android market sends information at the moment of app install, delivered as a broadcasted intent by Android market at install time - even before the app is opened for the first time.
+This can be used to create custom links to an Android application, including bits of information about the referrer, sent directly to the app for processing at install.
+It can be a simple and accurate solution for mobile app install tracking, among other uses.
 
 ## FAQ
 
 **Q: Does Android send information when the app is installed?**
-A: Yes. Android market broadcasts an intent containing referrer information at the moment the app is installed.
+A: Yes.
+Android market broadcasts an intent containing referrer information at the moment the app is installed.
 
 **Q: When is this referrer information available to the app?**
 A: It's delivered as a broadcasted intent at install time, before the app is ever opened.

public/readme/android/multiple-broadcast-receivers-in-the-same-app-for-the-same-action.md → public/llms-content/android/multiple-broadcast-receivers-in-the-same-app-for-the-same-action.md

@@ -12,7 +12,8 @@ language: "en"
 
 ## The problem
 
-When multiple broadcast receivers are registered separately to listen for the same intent within the same Android app, this can lead to unexpected results: one broadcast receiver might consume the broadcasted intent, leaving the others with nothing to receive. This can happen when using 3rd party libraries that define their own broadcast receivers alongside an app's own receivers.
+When multiple broadcast receivers are registered separately to listen for the same intent within the same Android app, this can lead to unexpected results: one broadcast receiver might consume the broadcasted intent, leaving the others with nothing to receive.
+This can happen when using 3rd party libraries that define their own broadcast receivers alongside an app's own receivers.
 
 ## The approach
 

public/readme/architecture/configprovider-bootstrap-modern-php-applications.md → public/llms-content/architecture/configprovider-bootstrap-modern-php-applications.md

@@ -12,11 +12,13 @@ language: "en"
 
 ## TL;DR
 
-In PHP, a `ConfigProvider` is a class or callable that is part of an application's bootstrap process, returning configuration data that tells the platform which middleware should run, in what order, and under what conditions. Frameworks like Mezzio, Laminas, Slim, and the Dotkernel Headless Platform use ConfigProviders to declare middleware pipeline configuration, dependency injection mappings, and request handlers, which get merged together automatically during bootstrap (except in Dotkernel, where new ConfigProviders must be registered manually).
+In PHP, a `ConfigProvider` is a class or callable that is part of an application's bootstrap process, returning configuration data that tells the platform which middleware should run, in what order, and under what conditions.
+Frameworks like Mezzio, Laminas, Slim, and the Dotkernel Headless Platform use ConfigProviders to declare middleware pipeline configuration, dependency injection mappings, and request handlers, which get merged together automatically during bootstrap (except in Dotkernel, where new ConfigProviders must be registered manually).
 
 ## Where Is the ConfigProvider Used?
 
-Mezzio (formerly Zend Expressive), Laminas, Slim, the Dotkernel Headless Platform, and other middleware-based frameworks often have a `ConfigProvider` class. In Laminas/Mezzio specifically, each module or package may contain a `ConfigProvider` that returns:
+Mezzio (formerly Zend Expressive), Laminas, Slim, the Dotkernel Headless Platform, and other middleware-based frameworks often have a `ConfigProvider` class.
+In Laminas/Mezzio specifically, each module or package may contain a `ConfigProvider` that returns:
 
 - Middleware pipeline configuration:
   - Middleware classes or service names.
@@ -80,7 +82,8 @@ The ConfigProvider is automatically picked up by the framework during applicatio
 - **Modular** - Each package can ship with its own config without interfering with others.
 - **Container-friendly** - Works well with frameworks using DI containers like Laminas ServiceManager, PHP-DI, or Pimple.
 - **Standardized service definitions** - Consistent rules for object creation, separate from business logic.
-- **Auto-Discovery** - In Laminas/Mezzio, the ConfigAggregator automatically loads and merges all ConfigProviders. Dotkernel is an exception: new ConfigProviders have to be added manually in `config/config.php`, because all the initial ConfigProviders required to install the applications are already injected.
+- **Auto-Discovery** - In Laminas/Mezzio, the ConfigAggregator automatically loads and merges all ConfigProviders.
+Dotkernel is an exception: new ConfigProviders have to be added manually in `config/config.php`, because all the initial ConfigProviders required to install the applications are already injected.
 - **Environment-agnostic** - 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 assertion of pipeline setup (e.g. checking if a config key is present).
 
@@ -93,7 +96,8 @@ A: It is a class that is part of an application's bootstrap process: a class or
 A: In the Laminas/Mezzio ecosystem, it's literally an array of configuration, settings, or anything else the application needs, and each module or package may contain its own ConfigProvider returning middleware pipeline configuration, dependency injection mappings, and request handlers.
 
 **Q: What is the difference between 'factories' and 'invokables' in the dependencies array?**
-A: `factories` will have the factory build the service, while `invokables` will use `new` directly. You can also use `aliases` to redirect to another service name and `delegators` to wrap the original service.
+A: `factories` will have the factory build the service, while `invokables` will use `new` directly.
+You can also use `aliases` to redirect to another service name and `delegators` to wrap the original service.
 
 **Q: How does the ConfigProvider get used during application bootstrap?**
 A: It is automatically picked up by the framework during bootstrap: all ConfigProviders are merged into one array, the configuration array is read, each item is resolved via `$app->pipe()`, the error-handling middleware is placed last in the pipeline, and at runtime Laminas Stratigility iterates over the pipeline in the order it was registered.

public/readme/architecture/request-lifecycle-for-a-mezzio-based-application.md → public/llms-content/architecture/request-lifecycle-for-a-mezzio-based-application.md

@@ -12,33 +12,44 @@ language: "en"
 
 ## TL;DR
 
-The request lifecycle is the sequence of steps that happen from the moment a user makes an HTTP request until the server sends back a response. This is illustrated using Dotkernel Light, one of the applications in the Dotkernel Headless Platform suite, walking through entry point setup, routing, handler execution, template rendering, response creation, and the response emitter.
+The request lifecycle is the sequence of steps that happen from the moment a user makes an HTTP request until the server sends back a response.
+This is illustrated using Dotkernel Light, one of the applications in the Dotkernel Headless Platform suite, walking through entry point setup, routing, handler execution, template rendering, response creation, and the response emitter.
 
 ## The Request Lifecycle, Step by Step
 
 ### Entry Point
 
 1. **HTTP Request** - Bootstrap the application, load configuration and create the Mezzio application instance.
-2. **Service Container** - Register factories, aliases and delegators. All services are configured and ready to use.
-3. **Route Registration** - Read all available routes with their allowed request methods and dynamically register them in the application. Routes are managed by FastRoute. Example: `/page/about` -> `GetPageViewHandler`, Method: `GET`, Route name: `page::about`.
-4. **Middleware Pipeline** - Loads the predefined order of middleware. It defines how incoming HTTP requests move through the application and how responses are generated.
+2. **Service Container** - Register factories, aliases and delegators.
+All services are configured and ready to use.
+3. **Route Registration** - Read all available routes with their allowed request methods and dynamically register them in the application.
+Routes are managed by FastRoute.
+Example: `/page/about` -> `GetPageViewHandler`, Method: `GET`, Route name: `page::about`.
+4. **Middleware Pipeline** - Loads the predefined order of middleware.
+It defines how incoming HTTP requests move through the application and how responses are generated.
 
 ### Processing
 
-5. **Routing** - FastRoute matches the URL and method against registered routes. Match: `GET /page/about`, Handler: `GetPageViewHandler`, Route name: `page::about`.
+5. **Routing** - FastRoute matches the URL and method against registered routes.
+Match: `GET /page/about`, Handler: `GetPageViewHandler`, Route name: `page::about`.
 6. **Handler Invocation** - Extract the matched route name from the request and pass it to the renderer:
    ```php
    $template = $request->getAttribute(RouteResult::class)->getMatchedRouteName();
    // $template = 'page::about';
    ```
-7. **Custom Logic Execution in Handler** - Execute the business logic in the handler. The process can involve services and any custom logic.
-8. **Template Rendering** - Twig loads the template, applies the layout, renders blocks and includes partials. Load: `src/Page/templates/page/about.html.twig`, Extends: `@layout/default.html.twig`, Render blocks: `title`, `content`, Include partials: `alerts.html.twig`, etc., Output: Final HTML.
-9. **Response Creation** - An `HtmlResponse` is created with status, headers and the rendered HTML body. Status: `200 OK`, Content-Type: `text/html; charset=utf-8`, Body: Rendered HTML.
-10. **Response Pipeline** - The response flows back through the middleware stack. Middleware can modify headers, cookies, compress content, etc.
+7. **Custom Logic Execution in Handler** - Execute the business logic in the handler.
+The process can involve services and any custom logic.
+8. **Template Rendering** - Twig loads the template, applies the layout, renders blocks and includes partials.
+Load: `src/Page/templates/page/about.html.twig`, Extends: `@layout/default.html.twig`, Render blocks: `title`, `content`, Include partials: `alerts.html.twig`, etc., Output: Final HTML.
+9. **Response Creation** - An `HtmlResponse` is created with status, headers and the rendered HTML body.
+Status: `200 OK`, Content-Type: `text/html; charset=utf-8`, Body: Rendered HTML.
+10. **Response Pipeline** - The response flows back through the middleware stack.
+Middleware can modify headers, cookies, compress content, etc.
 
 ### Exit Point
 
-11. **Response Emitter** - The final response is sent back to the browser. The page is rendered and sent to the user, as one of `HTTP 20x/30x`, `HTTP 40x`, or `HTTP 50x`.
+11. **Response Emitter** - The final response is sent back to the browser.
+The page is rendered and sent to the user, as one of `HTTP 20x/30x`, `HTTP 40x`, or `HTTP 50x`.
 
 ## FAQ
 
@@ -58,7 +69,8 @@ A: The matched route name is extracted from the request attribute and passed to
 A: Twig loads the matched template file, applies the layout it extends, renders its blocks, and includes any partials, producing the final HTML output.
 
 **Q: How is the response created and returned to the browser?**
-A: An `HtmlResponse` is created with a status code, headers, and the rendered HTML body. It then flows back through the middleware stack in reverse (the response pipeline), where middleware can modify headers, cookies, or compress content, before the response emitter sends the final response back to the browser as HTTP 20x/30x, 40x, or 50x.
+A: An `HtmlResponse` is created with a status code, headers, and the rendered HTML body.
+It then flows back through the middleware stack in reverse (the response pipeline), where middleware can modify headers, cookies, or compress content, before the response emitter sends the final response back to the browser as HTTP 20x/30x, 40x, or 50x.
 
 ## Resources