Getting Started

Install with composer require webduonederland/backbone-agent and confirm the service provider is auto-discovered; if you use a custom provider list, register it manually in config/app.php.
Publish the package config first (php artisan vendor:publish --tag=backbone-agent-config or the tag listed in the README) so route prefixes, middleware, and dump settings are visible and version-controlled.
Look first at the package's routes/ file and its config file — the 0.1.0 "info route" is the fastest way to see what the package registers and what it exposes.
First use case: call the info endpoint from a staging deployment or CI smoke test to confirm app/environment metadata is reachable, then exercise the database-dump feature manually before wiring it into a scheduled job.

Implementation Patterns

Info route as a health check: point your uptime monitor or post-deploy script at the info endpoint. Prefer asserting on a narrow field (status/version) rather than snapshotting the whole payload, so future additions don't break tests.
Gate the route by environment: wrap it in middleware or disable it via config outside local/staging. It is a diagnostic surface, not a public API.
Database dumps in deploy pipelines: invoke the dump command from your release script before running migrations, and write output to a path outside the repo. Combine with your existing backup retention rather than relying on the package alone.
Scheduling: register the dump command in app/Console/Kernel.php (or routes/console.php on newer Laravel) with withoutOverlapping() and an explicit output directory so repeated runs don't accumulate indefinitely.
CI integration: the coverage workflow added in 0.1.0 is internal to the package repo — don't copy it expecting it to run your app's tests.

Pre-1.0 churn: 0.1.0 is the initial release. Pin the version in composer.json and read the changelog before every minor bump; command names, config keys, and route paths are all subject to change.
Sensitive payloads: inspect exactly what the info route returns. Environment names, paths, and version strings are usually harmless, but verify nothing adjacent to credentials or .env values leaks before enabling it in production.
Route caching: after changing package config, run php artisan route:clear / config:clear — cached routes and configs will otherwise mask your edits during debugging.
Dump size and locking: large databases can make the dump slow or hold locks. Run off-peak, target read replicas where possible, and check whether the command supports schema-only or table-exclusion options before using it on production.
Storage and permissions: the dump destination must be writable by the web/queue user if triggered outside the CLI. A silent failure here is common — assert the file exists in your automation.
Extension points: the published config is the intended override surface; prefer config toggles over editing vendor files, and use custom middleware for auth rather than forking routes.