build: make the package installable, and run the suite that never has - #13
Conversation
dappcore/mcp could not be installed or tested by anyone. composer.json
declared only php and dappcore/php while src/ imports Laravel\Mcp in 14
files, Livewire in 46 and Core\Tenant in 19 — none of them declared. There
was no phpunit config, no test script, no vendor tree, and no /vendor rule
in .gitignore, because composer had never been run here at all. Its eleven
test files have therefore never executed.
Declared what the code actually uses: laravel/mcp as a hard requirement (the
tools extend Laravel\Mcp\Server\Tool), and dappcore/php-tenant, livewire,
mockery, testbench, pest and pint as dev requirements, matching how
dappcore/agent already carries its sibling modules.
The harness had the same three faults core/agent had. Pest.php bound its
TestCase to bare 'Feature' and 'Unit', which Pest resolves against its
default ./tests while this suite lives at php/tests, so nothing matched.
php/tests/TestCase.php declared namespace Tests with no PSR-4 entry for it,
so `use Tests\TestCase` could not resolve. And it extended
Illuminate\Foundation\Testing\TestCase, which expects a host application to
have booted — a package suite needs Testbench, and the package's own
provider registering, since Testbench does not run package auto-discovery.
Then the suite immediately proved why the imports matter: it died at
collection on Trait "Mod\Mcp\Tools\Concerns\RequiresWorkspaceContext" not
found. Fifteen dangling imports are fixed here, each verified against the
symbol it resolves to rather than assumed:
Mod\Mcp\* -> Core\Mcp\* (the package's own)
Mod\Tenant\... -> Core\Tenant\... (dappcore/php-tenant)
Mod\Uptelligence\ -> Core\Mod\Uptelligence\ (dappcore/php-uptelligence)
A bare Mod\ root is mapped nowhere in any dappcore package — only in the
host application — so every one of these was unreachable. That includes
CircuitBreaker importing Mod\Mcp\Exceptions\CircuitOpenException while its
own exception sits at Core\Mcp\Exceptions\CircuitOpenException, which made
call() fatal the moment a circuit opened.
Five imports are deliberately left alone rather than guessed at:
Mod\Agentic\Models\{AgentPlan,AgentSession} and
Mod\Mcp\Tools\Agent\Contracts\AgentToolInterface all resolve into
dappcore/agent, which would make this package depend on a package that is
meant to depend on it; Mod\Mcp\Services\McpMonitoringService exists only in
an RFC and was never implemented; Mod\Api\Models\ApiKey has no counterpart
on disk. Each needs a decision, not a rewrite.
Result: the suite runs for the first time — 187 failed, 127 passed, 270
assertions. Not green, and not claimed to be: those 187 are the honest
backlog this package has been carrying unseen, and can now be worked with a
runner that reports them.
Co-Authored-By: Virgil <virgil@lethean.io>
📝 WalkthroughWalkthroughChangesThe package adds Composer and PHPUnit configuration, updates development dependencies and scripts, aligns imports with Package and test integration
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Warning Billing warning: we have not been able to collect payment for this subscription for more than 72 hours. Please update the payment method or pay any pending invoices in Billing to avoid service interruption. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@composer.json`:
- Around line 48-55: Add ext-pdo_sqlite to the require-dev dependencies in
composer.json so Composer enforces the SQLite PDO driver required by the test
configuration. The phpunit.xml SQLite configuration at lines 41-42 requires no
direct change.
In `@php/src/Website/Mcp/View/Modal/Dashboard.php`:
- Around line 10-14: Resolve the missing model dependencies referenced by
Dashboard.php: make AnalysisLog, Asset, Pattern, UpstreamTodo, and Vendor
available under Core\Mod\Uptelligence\Models by registering the namespace with
the appropriate existing module or adding the corresponding classes, or replace
the imports and usages with existing model classes.
In `@php/tests/TestCase.php`:
- Around line 37-42: Replace “behavior” with “behaviour” in the comments at
php/tests/TestCase.php lines 37-42 and php/tests/Pest.php lines 29-32,
preserving the surrounding documentation.
- Around line 9-33: Update TestCase::getPackageProviders() to register both the
existing Core\Front\Mcp\Boot provider and Core\Mcp\Boot, ensuring Testbench
loads the MCP singleton bindings and migrations alongside the current package
setup.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 9cc9d7e5-f8db-41f2-9729-bd9ba8c3fa47
⛔ Files ignored due to path filters (1)
composer.lockis excluded by!**/*.lock
📒 Files selected for processing (16)
.gitignorecomposer.jsonphp/src/Mcp/Console/Commands/CleanupToolCallLogsCommand.phpphp/src/Mcp/Console/Commands/McpMonitorCommand.phpphp/src/Mcp/Services/CircuitBreaker.phpphp/src/Mcp/Tests/Unit/McpQuotaServiceTest.phpphp/src/Mcp/Tests/Unit/ValidateWorkspaceContextMiddlewareTest.phpphp/src/Mcp/Tests/Unit/WorkspaceContextSecurityTest.phpphp/src/Mcp/Tools/Commerce/GetBillingStatus.phpphp/src/Mcp/Tools/Commerce/ListInvoices.phpphp/src/Mcp/Tools/Commerce/UpgradePlan.phpphp/src/Website/Mcp/View/Modal/ApiKeyManager.phpphp/src/Website/Mcp/View/Modal/Dashboard.phpphp/tests/Pest.phpphp/tests/TestCase.phpphpunit.xml
💤 Files with no reviewable changes (1)
- php/src/Mcp/Tests/Unit/McpQuotaServiceTest.php
| "require-dev": { | ||
| "dappcore/php-tenant": "^0.1", | ||
| "dappcore/php-uptelligence": "*", | ||
| "laravel/pint": "^1.18", | ||
| "livewire/livewire": "^3.0", | ||
| "mockery/mockery": "^1.6", | ||
| "orchestra/testbench": "^9.0|^10.0", | ||
| "pestphp/pest": "^3.0" |
There was a problem hiding this comment.
🩺 Stability & Availability | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/usr/bin/env bash
set -euo pipefail
printf 'Files:\n'
git ls-files | sed -n '1,120p'
printf '\ncomposer.json relevant section:\n'
if [ -f composer.json ]; then
nl -ba composer.json | sed -n '1,120p'
fi
printf '\nphpunit.xml relevant section:\n'
if [ -f phpunit.xml ]; then
nl -ba phpunit.xml | sed -n '1,100p'
fi
printf '\nSearch for sqlite/pdo_sqlite requirements:\n'
rg -n 'ext-pdo_sqlite|PDO_SQLITE|DB_CONNECTION|DB_DATABASE|:memory:' composer.json phpunit.xml php | sed -n '1,160p'Repository: dAppCore/mcp
Length of output: 3810
🏁 Script executed:
#!/usr/bin/env bash
set -u
printf 'composer.json relevant section:\n'
if [ -f composer.json ]; then
sed -n '1,140p' composer.json
fi
printf '\nphpunit.xml relevant section:\n'
if [ -f phpunit.xml ]; then
sed -n '1,100p' phpunit.xml
fi
printf '\nSearch for sqlite/pdo_sqlite references:\n'
rg -n 'ext-pdo_sqlite|PDO_SQLITE|DB_CONNECTION|DB_DATABASE|:memory:|sqlite' composer.json phpunit.xml composer.lock . 2>/dev/null | sed -n '1,220p'Repository: dAppCore/mcp
Length of output: 8381
🌐 Web query:
Laravel SQLite driver requires PDO Sqlite composer ext-pdo_sqlite Laravel documentation
💡 Result:
Yes, the Laravel SQLite driver requires the PHP pdo_sqlite extension to be enabled [1][2]. This is a fundamental system-level dependency for PHP applications using SQLite, not a Composer dependency [1][2]. Key points regarding this requirement: 1. System Dependency: The pdo_sqlite extension is a PHP extension that must be installed and enabled in your system's php.ini configuration file [1][2]. It is not managed via composer.json because it is a requirement of the PHP environment itself [3][4]. 2. Verification: You can verify if the extension is enabled by running php -m | grep sqlite in your terminal [1]. If it is missing, you must install the appropriate PHP SQLite package for your operating system (e.g., php-sqlite3 on Ubuntu/Debian) and ensure the extension=pdo_sqlite line is uncommented in your php.ini file [1][2]. 3. Laravel Configuration: Once the PHP extension is enabled, you configure Laravel to use SQLite by updating your .env file [5][6]. For example: DB_CONNECTION=sqlite DB_DATABASE=/absolute/path/to/database.sqlite [5][7] 4. Error Troubleshooting: If you encounter an "SQLite driver not found" or "PDO exception" error, it confirms that your PHP installation lacks the pdo_sqlite extension [1][2]. Installing the extension and restarting your web server or PHP-FPM service will resolve this [1][2].
Citations:
- 1: After installing Laravel version 11, I encountered an error stating that the SQLite driver was missing. Upon investigation, I realized that in Laravel 11, the .env file includes SQLite as the default database driver. laravel/framework#50484
- 2: https://stackoverflow.com/questions/38949781/pdo-exception-driver-not-found-in-laravel-for-sqlite
- 3: https://www.php.net/manual/en/ref.pdo-sqlite.php
- 4: https://www.php.net/ref.pdo-sqlite
- 5: https://laravel.com/docs/13.x/database
- 6: https://laravel.com/docs/11.x/database
- 7: https://laravel.com/docs/master/database
🌐 Web query:
composer.json platforms.ext pdo_sqlite require extension platform package reference
💡 Result:
In Composer, ext-pdo_sqlite is a virtual platform package that allows you to specify a dependency on the PHP pdo_sqlite extension [1][2]. To require this extension in your project, add it to the require section of your composer.json file [3][4]: { "require": { "ext-pdo_sqlite": "*" } } Key details regarding platform packages and extensions: 1. Nature of Platform Packages: These are virtual packages representing the environment where Composer is running [1][2]. They do not install actual code [1]. 2. Version Constraints: Because PHP extension versions can be inconsistent or report as 0, it is standard practice to use * as the version constraint when requiring them [2][5]. 3. Importance: Explicitly listing required extensions in composer.json is recommended [4]. If you do not list them, Composer may install your dependencies without error, but your application will fail at runtime if the extension is missing from the production environment [4][6]. 4. Local Development vs. Deployment: If you need to run composer commands on a machine that lacks an extension you have declared as a requirement, you can bypass the check using the --ignore-platform-reqs flag [7][8]. However, this is discouraged for long-term development; it is better to ensure your local environment matches production [9][5]. 5. Platform Configuration: You can use the config field in composer.json to fake or ignore specific platform packages for the purpose of dependency resolution (e.g., {"ext-pdo_sqlite": false} to hide an extension, or specifying a version) [9]. You can view all PHP extensions currently available in your environment by running: composer show --platform
Citations:
- 1: https://getcomposer.org/doc/articles/composer-platform-dependencies.md
- 2: https://getcomposer.org/doc/01-basic-usage.md
- 3: https://doc.scalingo.com/languages/php/extensions
- 4: https://getcomposer.org/doc/04-schema.md
- 5: https://devcenter3.assets.heroku.com/articles/managing-php-extensions
- 6: https://github.com/composer/composer/blob/main/doc/04-schema.md
- 7: https://stackoverflow.com/questions/50957285/dealing-with-the-requested-php-extension-pdo-sqlite-is-missing-from-your-system
- 8: https://getcomposer.org/doc/03-cli.md
- 9: https://getcomposer.org/doc/06-config.md
🌐 Web query:
Laravel 12 composer.json sqlite tests require ext-pdo_sqlite Laravel documentation
💡 Result:
In Laravel 12, the ext-pdo_sqlite PHP extension is a system-level requirement for utilizing SQLite databases, including during testing if your application or test suite is configured to use the SQLite driver [1][2]. While composer.json files for individual packages often list ext-pdo_sqlite as a dependency [3][4][5], the core Laravel framework does not strictly require it in the global composer.json of a fresh project unless your application explicitly relies on SQLite for its database connection [1][2]. Key points regarding Laravel 12 and SQLite testing: 1. Requirement: If you intend to run tests using an SQLite database (such as the common in-memory :memory: setup used for fast testing), your server or local environment must have the pdo_sqlite PHP extension installed and enabled [6]. This is a requirement of the PHP environment rather than a package listed in the primary composer.json of the Laravel core framework [1][2]. 2. Configuration: Laravel defaults to SQLite in new installations [2]. If you are using SQLite, ensure your environment variables (e.g., DB_CONNECTION=sqlite) are set correctly [1]. When running tests, Laravel automatically sets the configuration environment to testing, and you can manage database behavior using traits like RefreshDatabase, which supports SQLite [7][8][9]. 3. Dependency Management: If you are developing a package that specifically requires SQLite functionality for its tests, it is standard practice to include ext-pdo_sqlite in the require or require-dev section of your package's composer.json to ensure the environment is correctly prepared [6][5]. In summary, ext-pdo_sqlite is a PHP extension requirement for the database driver itself; it is not a Composer package, so it is typically verified via system-level installation rather than being explicitly required in the core Laravel composer.json [1][2][6].
Citations:
- 1: https://github.com/laravel/docs/blob/12.x/database.md
- 2: https://laravel.com/docs/12.x/installation
- 3: https://packagist.org/packages/alex-kudrya/adminix
- 4: https://libraries.io/packagist/larafied%2Flarafied
- 5: https://packalyst.com/packages/package/nexus-scholar/laravel-tenant-sqlite
- 6: https://devhide.com/run-pdo-sqlite-query-on-in-memory-database-on-github-actions-65764274
- 7: https://github.com/laravel/docs/blob/12.x/database-testing.md
- 8: https://laravel.com/docs/12.x/testing
- 9: https://api.laravel.com/docs/12.x/Illuminate/Foundation/Testing/LazilyRefreshDatabase.html
Declare the SQLite driver required by the test configuration.
composer.json and phpunit.xml both configure SQLite, from in-memory database tests to the phpunit.xml connection. Add ext-pdo_sqlite to require-dev so Composer makes the PHP extension a package requirement before tests run.
📍 Affects 2 files
composer.json#L48-L55(this comment)phpunit.xml#L41-L42
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@composer.json` around lines 48 - 55, Add ext-pdo_sqlite to the require-dev
dependencies in composer.json so Composer enforces the SQLite PDO driver
required by the test configuration. The phpunit.xml SQLite configuration at
lines 41-42 requires no direct change.
| use Core\Mod\Uptelligence\Models\AnalysisLog; | ||
| use Core\Mod\Uptelligence\Models\Asset; | ||
| use Core\Mod\Uptelligence\Models\Pattern; | ||
| use Core\Mod\Uptelligence\Models\UpstreamTodo; | ||
| use Core\Mod\Uptelligence\Models\Vendor; |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
for class in AnalysisLog Asset Pattern UpstreamTodo Vendor; do
echo "== ${class} =="
rg -n --glob '*.php' \
"(class|interface|trait|enum)[[:space:]]+${class}\\b|use Core\\\\Mod\\\\Uptelligence\\\\Models\\\\${class};" .
doneRepository: dAppCore/mcp
Length of output: 692
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== Candidate files =="
git ls-files 'php/src/**/*.php' 'php/src/*/**/*.php' 'php/src/*/*/**/*.php' | rg -n '(Uptelligence|AnalysisLog|UpstreamTodo|Dashboard)' | sed -n '1,120p'
echo
echo "== Usages of referenced symbols in PHP files =="
rg -n --glob '*.php' '\b(AnalysisLog|Asset|Pattern|UpstreamTodo|Vendor)\b' .Repository: dAppCore/mcp
Length of output: 3187
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== Locate mod/model-like directories =="
git ls-files php/src | rg -n 'php/src/(Core|Mod|Uptelligence|Models|AnalysisLog|UpstreamTodo|Vendor|Asset|Pattern)' | sed -n '1,200p'
echo
echo "== Full Dashboard.php header/usage area =="
cat -n php/src/Website/Mcp/View/Modal/Dashboard.php | sed -n '1,190p'
echo
echo "== Exact file tree around src =="
find php/src -maxdepth 5 -type d | sort | sed -n '1,160p'Repository: dAppCore/mcp
Length of output: 190
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== All PHP filename occurrences =="
git ls-files 'php/*/*.php' 'php/*/*/*.php' 'php/*/*/*/*.php' 'php/*/*/*/*/*.php' | awk -F/ '{print NF, $0}' | sort -n | sed -n '1,220p'
echo
echo "== Namespace declarations for Core/Mod/Uptelligence/Models/AnalysisLog =="
rg -n --glob '*.php' 'namespace\s+(Core\\\\Mod\\\\Uptelligence\\\\Models|Core\\\\Mod\\\\Uptelligence|Core\\\\Mod|Core|Mod\\\\Uptelligence\\\\Models|Mod\\\\Uptelligence|Mod\\\\Models);|^(class|interface|trait|enum)\s+AnalysisLog\b|^(class|interface|trait|enum)\s+UpstreamTodo\b|^(class|interface|trait|enum)\s+Asset\b|^(class|interface|trait|enum)\s+Pattern\b|^(class|interface|trait|enum)\s+Vendor\b' . || true
echo
echo "== Dashboard.php =="
cat -n php/src/Website/Mcp/View/Modal/Dashboard.php | sed -n '1,200p'Repository: dAppCore/mcp
Length of output: 13775
🌐 Web query:
Laravel PHP namespace resolution Core\Mod\Uptelligence\Models\AnalysisLog no class found
💡 Result:
The error "class not found" for Core\Mod\Uptelligence\Models\AnalysisLog in a Laravel application indicates that the autoloader cannot locate the file corresponding to that namespace [1][2]. Given the namespace structure, it appears this class belongs to a custom module within a modular monolith structure [3][4]. To resolve this, verify and perform the following steps: 1. Check PSR-4 Mapping and Directory Structure: Laravel relies on PSR-4 standards where the directory structure must match the namespace exactly [5]. Ensure that the file AnalysisLog.php is located at the exact path corresponding to the namespace Core\Mod\Uptelligence\Models [5][6]. If your project uses the dAppCore/php-uptelligence structure, verify that your module is correctly registered within the app/Mod directory [3][4]. 2. Regenerate Autoloader: Often, changes to namespaces or file locations are not picked up until the autoloader is refreshed. Run the following command in your terminal [2][5]: composer dump-autoload 3. Verify Namespace Declaration: Open the file app/Mod/Uptelligence/Models/AnalysisLog.php (or wherever it is located) and ensure the top line matches the expected namespace: namespace Core\Mod\Uptelligence\Models; 4. Clear Caches: If you are using Laravel's caching features for configuration or routes, stale data may be causing the resolution error [5]. Run these commands: php artisan config:clear php artisan cache:clear 5. Check for Typos: PHP namespaces and directory names are case-sensitive on most production servers (Linux) [5][7]. Ensure that all folders and the class name (AnalysisLog) match perfectly in both the file system and the code [5]. 6. If the class is being called in a route or service provider, ensure you have imported the class at the top of the file using the use statement [1][6]: use Core\Mod\Uptelligence\Models\AnalysisLog; If the issue persists, ensure that your composer.json file correctly maps the Core namespace to the appropriate directory under the "autoload" section [2].
Citations:
- 1: https://jonathanbird.com.au/blog/how-to-fix-target-class-does-not-exist-error-in-laravel-13-2026-guide
- 2: https://stackoverflow.com/questions/32475892/reflectionexception-class-classname-does-not-exist-laravel
- 3: https://github.com/dAppCore/php-uptelligence
- 4: https://packagist.org/packages/dappcore/php-uptelligence
- 5: https://stackoverflow.com/questions/57574438/laravel-class-not-found
- 6: https://blog.path-finder.jp/troubleshooting/illuminatecontractscontainerbindingresolutionexception-target-class-apphttpcontrollersxcontroller-does-not-exist-causes-and-fixes-laravel-2026-edition/
- 7: https://stackoverflow.com/questions/67517619/laravel-package-namespace-cant-find-controller-composer-2
Add the missing Uptelligence model classes before using these imports.
php/src/Website/Mcp/View/Modal/Dashboard.php now imports AnalysisLog, Asset, Pattern, UpstreamTodo, and Vendor from Core\Mod\Uptelligence\Models, but the repository only contains these imports/usages. Register Core\Mod\Uptelligence\Models with an existing package/module, add the missing class files, or replace these with classes that are already available.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@php/src/Website/Mcp/View/Modal/Dashboard.php` around lines 10 - 14, Resolve
the missing model dependencies referenced by Dashboard.php: make AnalysisLog,
Asset, Pattern, UpstreamTodo, and Vendor available under
Core\Mod\Uptelligence\Models by registering the namespace with the appropriate
existing module or adding the corresponding classes, or replace the imports and
usages with existing model classes.
| use Core\Front\Mcp\Boot as McpBoot; | ||
| use Orchestra\Testbench\TestCase as BaseTestCase; | ||
|
|
||
| /** | ||
| * Base test case for the core-mcp package. | ||
| * | ||
| * Testbench, not Illuminate\Foundation\Testing\TestCase: the latter expects a | ||
| * host application to have booted already and gives a package suite no app at | ||
| * all, so every test died before reaching its assertions. Testbench builds the | ||
| * minimal application this package needs. | ||
| */ | ||
| abstract class TestCase extends BaseTestCase | ||
| { | ||
| // | ||
| /** | ||
| * Register the package's own service provider. | ||
| * | ||
| * Testbench does not run Laravel's package auto-discovery, so the provider | ||
| * named in composer.json's extra.laravel.providers has to be given here or | ||
| * none of the package's bindings, routes or config exist under test. | ||
| */ | ||
| protected function getPackageProviders($app): array | ||
| { | ||
| return [ | ||
| McpBoot::class, | ||
| ]; |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/usr/bin/env bash
set -euo pipefail
rg -n -C 4 'getPackageProviders|Core\\Mcp\\Boot|Core\\Front\\Mcp\\Boot|singleton\(|loadMigrationsFrom' \
composer.json php/tests/TestCase.php php/src/Mcp/Boot.phpRepository: dAppCore/mcp
Length of output: 2592
Register the Core MCP provider in the Testbench application.
getPackageProviders() currently registers only Core\Front\Mcp\Boot. Core\Mcp\Boot owns the MCP singleton bindings and loads MCP migrations, so tests using those services or RefreshDatabase miss that setup.
Proposed fix
+use Core\Mcp\Boot as CoreMcpBoot;
use Core\Front\Mcp\Boot as McpBoot;
protected function getPackageProviders($app): array
{
return [
+ CoreMcpBoot::class,
McpBoot::class,
];
}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| use Core\Front\Mcp\Boot as McpBoot; | |
| use Orchestra\Testbench\TestCase as BaseTestCase; | |
| /** | |
| * Base test case for the core-mcp package. | |
| * | |
| * Testbench, not Illuminate\Foundation\Testing\TestCase: the latter expects a | |
| * host application to have booted already and gives a package suite no app at | |
| * all, so every test died before reaching its assertions. Testbench builds the | |
| * minimal application this package needs. | |
| */ | |
| abstract class TestCase extends BaseTestCase | |
| { | |
| // | |
| /** | |
| * Register the package's own service provider. | |
| * | |
| * Testbench does not run Laravel's package auto-discovery, so the provider | |
| * named in composer.json's extra.laravel.providers has to be given here or | |
| * none of the package's bindings, routes or config exist under test. | |
| */ | |
| protected function getPackageProviders($app): array | |
| { | |
| return [ | |
| McpBoot::class, | |
| ]; | |
| use Core\Mcp\Boot as CoreMcpBoot; | |
| use Core\Front\Mcp\Boot as McpBoot; | |
| use Orchestra\Testbench\TestCase as BaseTestCase; | |
| /** | |
| * Base test case for the core-mcp package. | |
| * | |
| * Testbench, not Illuminate\Foundation\Testing\TestCase: the latter expects a | |
| * host application to have booted already and gives a package suite no app at | |
| * all, so every test died before reaching its assertions. Testbench builds the | |
| * minimal application this package needs. | |
| */ | |
| abstract class TestCase extends BaseTestCase | |
| { | |
| /** | |
| * Register the package's own service provider. | |
| * | |
| * Testbench does not run Laravel's package auto-discovery, so the provider | |
| * named in composer.json's extra.laravel.providers has to be given here or | |
| * none of the package's bindings, routes or config exist under test. | |
| */ | |
| protected function getPackageProviders($app): array | |
| { | |
| return [ | |
| CoreMcpBoot::class, | |
| McpBoot::class, | |
| ]; |
🧰 Tools
🪛 PHPMD (2.15.0)
[warning] 29-29: Avoid unused parameters such as '$app'. (undefined)
(UnusedFormalParameter)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@php/tests/TestCase.php` around lines 9 - 33, Update
TestCase::getPackageProviders() to register both the existing
Core\Front\Mcp\Boot provider and Core\Mcp\Boot, ensuring Testbench loads the MCP
singleton bindings and migrations alongside the current package setup.
| * Testbench boots a bare app with no APP_KEY, and the encrypter is reached | ||
| * through the session middleware every rendered view runs through, so | ||
| * without a key the failure surfaces as a ViewException rather than as the | ||
| * behaviour under test. A fixed key, not a random one: it keeps runs | ||
| * reproducible and nothing here encrypts data that outlives the test. | ||
| * Exactly 32 bytes — AES-256-CBC rejects any other length. |
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win
Use UK English in test comments.
php/tests/TestCase.php#L37-L42: changebehaviortobehaviour.php/tests/Pest.php#L29-L32: changebehaviortobehaviour.
As per coding guidelines, php/**/*.{php,blade.php,md,json} requires UK English spellings such as colour, organisation, and centre.
📍 Affects 2 files
php/tests/TestCase.php#L37-L42(this comment)php/tests/Pest.php#L29-L32
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@php/tests/TestCase.php` around lines 37 - 42, Replace “behavior” with
“behaviour” in the comments at php/tests/TestCase.php lines 37-42 and
php/tests/Pest.php lines 29-32, preserving the surrounding documentation.
Source: Coding guidelines
1 participant
Prerequisite for
dappcore/agentconsuming this package. It cannot be consumed, or even verified, in its current state.What was wrong
dappcore/mcpcould not be installed or tested by anyone:laravel/mcpLaravel\Mcp\Server\Tool)livewire/livewiredappcore/php-tenantNo
phpunit.xml, notestscript, novendor/, and no/vendorrule in.gitignore— because composer had never been run here at all. Its eleven test files have never executed.The harness
Same three faults core/agent had:
Pest.phpbound its TestCase to bare'Feature'/'Unit', which Pest resolves against its default./testswhile this suite lives atphp/tests— nothing matched.php/tests/TestCase.phpdeclaresnamespace Testswith no PSR-4 entry for it, souse Tests\TestCasecould never resolve.Illuminate\Foundation\Testing\TestCase, which expects a host application to have booted. A package suite needs Testbench — and the package's own provider registered, since Testbench doesn't run auto-discovery.The dangling imports
With the harness working, the suite immediately died at collection on
Trait "Mod\Mcp\Tools\Concerns\RequiresWorkspaceContext" not found.A bare
Mod\root is mapped nowhere in any dappcore package — only in the host application. So everyMod\*import here was unreachable. Fifteen are fixed, each verified against the symbol it resolves to rather than assumed:That includes
CircuitBreakerimportingMod\Mcp\Exceptions\CircuitOpenExceptionwhile its own exception sits atCore\Mcp\Exceptions\CircuitOpenException— makingcall()fatal the moment a circuit opened.Five left deliberately alone
Not guessed at, because each needs a decision rather than a rewrite:
Mod\Agentic\Models\AgentPlan,Mod\Agentic\Models\AgentSession,Mod\Mcp\Tools\Agent\Contracts\AgentToolInterface— all resolve intodappcore/agent, which would make this package depend on the package that is meant to depend on it. A dependency cycle, in 4 files:McpApiController,McpAgentServerCommand,AgentToolRegistry,AgentSessionService.Mod\Mcp\Services\McpMonitoringService— exists only inRFC.services-extended.md. Never implemented.Mod\Api\Models\ApiKey— no counterpart anywhere on disk.Result
The suite runs for the first time: 187 failed, 127 passed, 270 assertions.
Not green, and not claimed to be. Those 187 are the honest backlog this package has been carrying unseen, now visible to a runner that reports them. The 127 passing are real signal that did not exist before this branch.
🤖 Generated with Claude Code
Co-Authored-By: Virgil virgil@lethean.io
Summary by CodeRabbit