Mission Control Laravel Package

Getting Started

Mission Control is Grafite's admin/control-panel layer: a dashboard scaffold that gives you a protected UI, a layout, and an extension surface for your own operational screens. Despite the "PHP agnostic" description, in practice you should treat it as a Laravel package — it ships a service provider, routes, views, migrations, and config, and expects Laravel's container and auth.

Minimal path to a running dashboard:

composer require grafite/mission-control

# Laravel auto-discovers the provider; confirm the exact namespace first:
composer show grafite/mission-control

# Publish config, views, assets, migrations
php artisan vendor:publish --provider="Grafite\MissionControl\MissionControlServiceProvider"
php artisan migrate

php artisan route:list | grep -i mission

Where to look first, in order:

1. README.md and composer.json (extra.laravel.providers, version constraints) — the README is the only reliable source for the provider namespace and route prefix.
2. src/ — service provider, route file, and any Contracts/ directory (that's your extension surface).
3. config/mission-control.php after publishing — most behavior is config-driven.
4. resources/views/ — the dashboard layout you'll be overriding.

First use case: put the dashboard behind auth plus an admin gate, register one user, load the panel, then add a single custom card (an count of users, latest signups, queue depth) to prove the extension path end-to-end before building anything real. Doing this in an afternoon tells you whether the package is worth adopting or only worth reading.

Implementation Patterns

Wrap, don't inherit. Because the package is likely unmaintained, don't sprinkle its classes through your app. Create a thin App\Support\ControlPanel adapter that your controllers and views call, so a future replacement is a one-file change.

Guard everything. The package's routes may ship unguarded or behind a web group only. Apply protection explicitly rather than trusting defaults:

Route::middleware(['web', 'auth', 'can:viewMissionControl'])
    ->group(base_path('vendor/grafite/mission-control/routes/web.php'));

Better: disable the package's own route registration if the config allows it, and re-register the routes yourself with your middleware stack.

Config-driven modules. Typical Grafite packages let you declare dashboard cards/panels as arrays in the config file (label, icon, route, permission, view). Prefer that over editing published views — it survives upgrades and keeps diffs readable. If the config supports a cards or modules key, each entry usually maps to a route name plus a Blade partial.

Integrate with the Grafite ecosystem. Mission Control slots naturally alongside grafite/laravel-auth (roles/permissions) and grafite/crud-maker / grafite/form-maker for generated CRUD screens. If you're already on those, use their role checks inside your card visibility logic so the panel and the rest of the admin agree on permissions.

Cache the expensive cards. Dashboard cards are the classic N+1 trap — one aggregate query per widget per page load. Wrap each metric in Cache::remember(..., 60, fn () => ...) and give the panel a manual "refresh" action.

Test the panel as an admin. A single feature test per card (actingAs($admin)->get('/mission-control')->assertOk()->assertSee(...)) catches broken queries and unauthorized access cheaply.

Gotchas and Tips

• Adoption risk is the headline. Zero stars, zero dependents, a 0.03 score. Pin the exact version in composer.json, commit the lock file, and treat the source as reference code you may need to fork.
• Laravel version drift. Low-traffic packages lag on framework constraints. Check illuminate/* requirements in composer.json before installing on Laravel 10/11+; expect to widen constraints in a fork if needed.
• Namespace guessing is the #1 install failure. Grafite\... vs GrafiteInc\... shows up inconsistently in older Grafite repos. Run composer show and read extra.laravel.providers rather than copying a provider string from a blog post.
• Migrations can collide. If the package publishes a users/roles migration, inspect it before php artisan migrate in an existing app — you may need to delete or namespace it.
• Config caching bites after publishing. Run php artisan config:clear after editing config/mission-control.php; a stale bootstrap/cache/config.php silently ignores your changes.
• Published views win. Override via resources/views/vendor/mission-control/... rather than editing vendor/, and republish assets (--force) after any version bump — asset hashes and layout markup change between releases.
• Debugging routes: php artisan route:list --path=mission -v shows middleware and controller per route. If the dashboard 404s, the provider likely isn't discovered (check bootstrap/cache/packages.php).
• Extension points to prefer: the config arrays, Blade view overrides under resources/views/vendor/, and any interfaces in src/Contracts. Avoid subclassing concrete controllers or models — those are the first things to change in an unmaintained package.
• Have an exit plan. If you adopt it, keep your custom screens in your own app/ and resources/ and use Mission Control only for layout, nav, and auth glue. That way ripping it out later is a template swap, not a rewrite.