Getting Started

Install as a dev dependency: composer require --dev vendor/package. This is a developer-facing toolbar; keeping it in require-dev avoids shipping it to production.
Publish the config and routes: php artisan vendor:publish --provider="Vendor\Package\ServiceProvider" (or the package's publish tags). The config file is where route names, middleware, and environment gating live — read it before writing any integration code.
Confirm the service provider is auto-discovered, then load any page in local. The toolbar should render. If it doesn't, check in this order: environment gating, middleware ordering, and whether the config is cached.
First use case: enable the toolbar locally, open a page that uses a template route, and verify the toolbar resolves and links correctly. This is also the fastest way to confirm the 1.7.0 route rename didn't break your app.
Where to look first: config/<package>.php for enabled environments and route prefix; the package's routes/ file for the toolbar route name; the changelog for the 1.7.0 renames.

Implementation Patterns

Environment gating: enable only in local/staging, never production. Prefer the config's enabled closure over ad-hoc App::environment() checks scattered through middleware.
Route references: always use route('...') with the named route, never hardcode the URI. 1.7.0 renamed the toolbar route to follow conventions, so any literal string or stale route() name will 404/500.
Middleware ordering: register the toolbar middleware after the session/auth stack so it can resolve the current user and template context; before response-terminating middleware otherwise.
Template route resolution: if you render a template route (preview, SPA shell, or dynamic template), go through the package's resolver rather than building URLs by hand — 1.7.0 improved error handling here, so surface failures rather than silently falling back.
Testing: disable the toolbar in the test env. If you need to assert on it, fake the route or call the resolver directly instead of hitting HTTP.
Config caching: php artisan config:cache freezes the published config. Clear it after any route/config change, especially in CI.

Breaking: the toolbar route was renamed in 1.7.0. Grep your codebase and Blade views for the old route name and any hardcoded URIs; update to route('...') with the new name. Add a smoke test that hits the toolbar endpoint so future renames fail loudly instead of silently 404ing.
Behaviour change: error handling when resolving the template route is now stricter/better. Exceptions that were previously swallowed may now surface — check logs after upgrading and make sure your template routes resolve deterministically (named routes, no wildcard collisions).
Dependency and tooling updates in 1.7.0 are low-risk, but re-run composer update and your test suite; watch for minor-version bumps in transitive dependencies.
Debugging a toolbar that renders but whose links 404 is almost always a stale route cache (php artisan route:clear) or config cache — not the package itself.
Extension points: use the config's middleware/route hooks and the package's published views rather than editing vendor files. The resolver and toolbar renderer are the two seams worth wrapping if you need custom behaviour.
Don't ship it: keep the toolbar disabled by default in production, and don't commit its assets into your public build pipeline unless you intend to.