Monitor Symfony Bundle Laravel Package

Getting Started

This is a Symfony bundle, not a Laravel package — there is no service provider, no package auto-discovery, and no config/monitor.php publish step. Your composer.json, config/bundles.php, and config/packages/ are the integration points.

1. Require the bundle (this pulls in the core at ^0.5.0):

   composer require quiet-guard/monitor-symfony-bundle:^0.5.0
   

2. Register it in config/bundles.php:

   return [
       // ...
       QuietGuard\MonitorBundle\QuietGuardMonitorBundle::class => ['all' => true],
   ];
   

3. Add whatever credentials/endpoint the core expects to .env (keep them out of config/packages/*.yaml — use %env()% indirection so the same config promotes across environments).
4. First use case: get a heartbeat/health signal from the Symfony app into the Quiet Guard dashboard and confirm it arrives. Verify with bin/console debug:container --tag=... or by hitting a health endpoint before you wire anything else up.

v0.5.0 itself is a no-op for your application code: it only bumps the core constraint to ^0.5.0. Nothing in the bundle's behaviour changed, so if you're already on 0.4.x, composer update quiet-guard/monitor-symfony-bundle is the entire upgrade.

Implementation Patterns

• Lockstep versioning with the core. The bundle and the core move together. In practice, treat "bundle version" and "core version" as one unit — don't hand-pin the core to a lower line while running a newer bundle, or Composer will silently resolve you back to an older bundle release that allows it.
• Config as environment-shaped YAML. Put the bundle's config in config/packages/quiet_guard_monitor.yaml and override per-environment in config/packages/dev/ and config/packages/prod/. This is the natural Symfony idiom and keeps noisy dev telemetry out of your production dashboard.
• Commit composer.lock. Pre-1.0 (0.x) semantics mean minor bumps may carry breaking changes; the lockfile is your only real guard across a team.
• Keep monitoring outbound-only and non-blocking. Wrap the bundle's reporting path so a Quiet Guard outage (or a network blip on deploy) can't cascade into request failures. In a Symfony app the easiest place is a small decorator around the reporter service rather than touching the bundle internals.
• CI check: run composer outdated --direct and composer validate as a job. Given the paired-release model, an outdated bundle usually means an outdated core and vice versa.

Gotchas and Tips

• Don't go looking for monitor:backup --exclude-table. The v0.5.0 notes explicitly call out that this flag lives in the Laravel SDK and that this bundle does not ship it. If your team shares docs across a Laravel app and a Symfony app, this is the exact spot where someone will file a bogus bug report.
• ^0.5.0 on the core is not a widening. It's a floor and a ceiling within the 0.5 line. If you have a transitive dependency pinning the core at 0.4.x, Composer will keep you on bundle 0.4.x — and the failure mode is a silently stale package, not an error. Check composer why quiet-guard/core when an update "doesn't take".
• The changelog is the source of truth for scope. v0.5.0 states "the core carries no change of its own" — so there is no behavioural delta to test beyond a normal smoke test of your health endpoint.
• Extension points: for anything beyond config (custom reporters, extra checks), extend through the bundle's service definitions in your own services.yaml rather than forking — you're pre-1.0, and forks will diverge fast given the paired-release cadence.
• Debugging: when telemetry doesn't appear, the bundle is almost never the culprit — check the outbound HTTP path (proxy, egress firewall, TLS) and the credentials in the environment before assuming a version mismatch.