HawkBitPhp/hawkbit
61.6
Adequate · 22 September 2026
2.6k
lines of production code
PHP
primary language
6
measurements over time
What this system is
Hawkbit is a PHP microframework that provides a structured environment for building HTTP and CLI applications. It features a modular architecture with middleware pipelines, event-driven request handling, and integrated error management. The system supports integration with external ecosystems like Symfony and Stratigility, and includes a comprehensive test suite for its core components.
How it got here
2014 — Hawkbit micro framework initial release
3 changes.
This period marks the initial release of the Hawkbit micro PHP framework, establishing its core structure with HTTP and CLI application classes. The work involved setting up the project's dependencies, including PSR-7 support and routing, alongside a comprehensive PHPUnit test suite to ensure reliability.
2016–2017 — HTTP and console integration
9 changes.
This period focused on establishing the application's core request handling architecture by integrating PSR-7, Symfony, and Stratigility middleware pipelines. It also introduced a structured console command system and centralized error handling with Whoops and Monolog.
Features
Add Symfony HTTP kernel adapter for PSR-7 bridging
A new \HttpKernelAdapter\ class has been added to the Symfony integration layer. This adapter implements \HttpKernelInterface\ and \TerminableInterface\, serving as a bridge between PSR-7 and Symfony HTTP components. It converts incoming Symfony \Request\ objects into PSR-7 requests for the application's \handle\ and \terminate\ methods, and converts the resulting PSR-7 responses back to Symfony \Response\ objects using \DiactorosFactory\ and \HttpFoundationFactory\.
src/Symfony · high confidence
Added Stratigility integration for middleware handling
The framework now includes a new integration with the Zend Stratigility library. This adds two new classes, \ApplicationMiddleware\ and \MiddlewarePipeAdapter\, which allow the Hawkbit application to process HTTP requests and responses through Stratigility's middleware pipeline, enabling better request handling and error management within that ecosystem.
src/Stratigility · high confidence
Introduce Hawkbit micro framework with HTTP and CLI application classes
The framework introduces the \Hawkbit\ namespace, providing an \Application\ class for handling HTTP requests and a \Console\ class for CLI commands. The \Application\ class integrates with \League\\Route\ for routing and middleware, while the \Console\ class supports command mapping and execution. Both share common initialization traits for configuration and error handling, establishing the core structure for the Hawkbit micro framework.
src · high confidence
Introduce basic console command handling
Added new classes in the Console namespace to support command-line interface execution. The Command class encapsulates a handler and argument parsing logic, while the Dispatcher class routes input to the appropriate command and resolves its handler via a dependency injection container. A ConsoleEvent class was also added to carry event data for the console subsystem.
src/Console · high confidence
Behavioural changes
Added public entry point and URL rewriting for the Hawkbit application
The public directory now includes an .htaccess file that enforces clean URLs by redirecting requests to index.php, while also stripping the PHPSESSID query parameter for security. A new index.php entry point bootstraps the Hawkbit application, which serves a basic 'Hello, World!' response on the root path.
public · high confidence
Centralized error handling with Whoops and Monolog services
The application now features dedicated service providers and services for error handling, separating concerns for logging and exception display. A new MonologServiceProvider registers the PSR LoggerInterface, while a WhoopsServiceProvider bootstraps the Whoops error handler, wiring it to a new HandlerService that intelligently selects response formats (HTML, JSON, XML, or plain text) based on the request type. The WhoopsService provides utilities to convert various error types into exceptions and manage error display behavior, ensuring consistent error reporting and logging across the application.
src/Application/Services · high confidence
Introduces new application event and middleware execution architecture
The framework now includes a dedicated \ApplicationEvent\ class and an \HttpApplicationEvent\ for managing request and response lifecycle events. Additionally, a new \MiddlewareRunner\ class and \MiddlewareAwareInterface\ are introduced to handle the execution and error handling of middleware chains, allowing for more robust middleware integration and exception tracking.
src/Application · medium confidence
Test coverage
Add tests for Symfony HttpKernelAdapter; Added test asset classes for unit testing; Added unit tests for the Stratigility MiddlewarePipeAdapter; Initial test suite for the Hawkbit microframework.
Dependencies
Initial release of Hawkbit micro framework with PSR-7 and middleware support
Introduced the Hawkbit PSR-7 micro PHP framework, establishing the project's dependency on league/route, league/container, league/event, league/climate, monolog, zend-config, and zend-diactoros, while adding phpunit and symfony packages for testing and adapters.
(dependencies) · medium confidence
Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.
How this codebase got here
Score
- CAI 61 → 62 (+0.1)
- Rubric changed (rubric-2026.08.19 → rubric-2026.09.15) — scores are not directly comparable.
Lenses
- Code Health 97 → 98 (+1.2)
- Architecture 100 → 99 (-0.9)
- Maturity 47 → 47 (+0.0)
- Readiness 50 → 50 (-0.0)
- Security 100 → 100 (+0.0)
Resolved (6)
- Coverage not included — suite not readable by the collector
- Dependency hygiene not measured — dependency manifest found but not parsed for hygiene
- No exposed public API
- Test reliability not included
- The 'Motivation' section is an unmaintained long prose block that reads like a personal vision rather than documented rationale. (README.md)
- dormant codebase — no living knowledge left to concentrate
New (8)
- Ambiguous request handling entry points. handleRequest implies a full lifecycle execution (request to response), while handle requires both request and response objects and includes a catch handler. It is unclear if handleRequest is a convenience wrapper for handle, or if they serve distinct purposes (e.g., one for middleware pipeline, one for direct dispatch). The naming 'handle' vs 'handleRequest' is inconsistent with common patterns where 'handle' is the core dispatcher.
- Dependency hygiene PARTLY measured — Composer dependencies read, no committed lock to grade for currency
- Documentation: no installation or build instructions (README.md)
- Documentation: no usage examples (README.md)
- Duplicate initialization logic with divergent signatures. The concrete Application class exposes an init method taking configuration, while the AbstractApplication base class also exposes an init method with no parameters. This creates confusion about whether initialization is handled by the concrete class or the abstract base, and suggests a potential violation of the Template Method pattern or redundant entry points.
- Duplicate shutdown logic with divergent signatures. Similar to init, Application.shutdown() takes a response argument, while AbstractApplication.shutdown() takes none. This inconsistency makes it unclear which method should be called by consumers and which one performs the actual cleanup.
- No dependency advisory monitoring
- Redundant termination interfaces. Application implements TerminableInterface, and HttpKernelAdapter also exposes terminate. While HttpKernelAdapter is an adapter, the presence of TerminableInterface alongside Application's own terminate method suggests a potential duplication of intent if Application is the primary consumer. More critically, the signature is identical across Application and the interface, which is fine, but the existence of both suggests the interface might be unnecessary if Application is the sole implementer, or if other classes implement it, the naming is consistent. However, the real issue is the potential confusion between Application.terminate and the adapter's terminate.
Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.
Survey your own repository
HawkBitPhp/hawkbit was measured the same way every project in this corpus was: the same rubric, at a pinned commit, with the result published in full. Point a surveyor at a repository you know and see whether you agree with it.
About this page
- The score is its most recent published measurement, taken on 22 September 2026 at a pinned commit. It is not a live figure and does not change until the project is measured again.
- Measured at commit f60b914782d8a4770057f898c9d0cdf00c692fc1 — the exact code this score is about.
- Scored under rubric-2026.09.15 — the same rubric and the same method as every other entry in this index.
- Measured by watchdog.canine.dev using codehealth-analyzer preprod-821afab8930d.