Wide Events Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for request-level observability. The bundle implements the "wide event" / canonical log line pattern — one enriched event per request or message instead of scattered log lines. That's a decision point: adopt a small, pluggable bundle vs. hand-rolling middleware and context propagation in-house.
• Observability cost strategy. Tail-based sampling (added in this release, with slow-event retention keyed on outcome duration) directly supports the roadmap question "how do we keep 100% of the interesting requests without paying for 100% of the traffic." This is the single most budget-relevant capability in 0.1.0.
• PII / compliance posture. Built-in redaction and event-size normalization/limits let you commit to "we can log rich request context without shipping secrets or unbounded payloads." That unlocks features (e.g., debugging endpoints, richer error telemetry) that legal/security would otherwise block.
• Async architecture roadmap. The Messenger middleware + correlation stamp means queue-based work can be traced end-to-end. Supports decisions like "can we move checkout to async without losing debuggability."
• Vendor/tooling lock-in. Emitters are abstracted (in-memory, wide event, Monolog, OpenTelemetry correlation). Supports a "start with Monolog, migrate to OTel later" roadmap without a rewrite.
• Use cases to evaluate against: incident triage and MTTR reduction, per-request latency/cost attribution, audit-safe structured logging, correlating web requests to background jobs.
• Caveat affecting all of the above: this is a Symfony bundle, not a Laravel package, and it is 0.1.0 (pre-1.0). Treat it as a spike/prototype input, not a platform commitment. If the roadmap assumes Laravel, the decision is "port the concept / wait for a Laravel adapter," not "adopt this."

When to Consider This Package

Consider it when:

• You're on Symfony (the release ships bundle config, DI foundation, HTTP lifecycle subscriber, Messenger middleware, Monolog emitter) — not Laravel or plain PHP frameworks.
• You already run Monolog and/or OpenTelemetry and want richer per-request context without replacing your stack.
• Log volume or observability spend is a live problem and tail-based sampling with slow/error retention is attractive.
• You need redaction and payload limits enforced centrally rather than per-log-call discipline.
• You want request-to-queue correlation (request IDs propagated, correlation stamps on messages).
• You're comfortable pinning a 0.x dependency and reading the source; the component-isolation work in this release suggests APIs will still move.

Look elsewhere when:

• You're on Laravel. There is no service provider, no Laravel HTTP/middleware integration, no Laravel queue integration here. The core WideEvent/WideEventContext types may be reusable, but adoption means writing your own glue.
• You need a stable public API or long-term support — 0.1.0 with architecture-enforcement churn is not that.
• You need managed vendor support, SLAs, or a mature ecosystem (Sentry, Honeycomb, Datadog, or the OTel SDK directly).
• You need capabilities not present yet: no evidence of dashboards, storage backends beyond in-memory/Monolog, or a documented sampling policy API.
• Your team won't own upgrading across pre-1.0 breaking changes.

How to Pitch It (Stakeholders)

For executives: This is a small, low-cost observability component that cuts mean-time-to-resolution and, more importantly, cuts log/telemetry spend — it keeps every slow or failed request and samples away the boring ones. It also enforces PII redaction centrally, reducing the chance of a logging-driven data incident. It is a 0.1.0 Symfony bundle, so the recommendation is a time-boxed pilot on one service, not a platform-wide rollout. Success criteria: measurable reduction in telemetry volume, faster incident triage on the pilot service, and no PII findings.

For engineering: Framework-native instrumentation — an HTTP lifecycle subscriber collects context through the request, a Messenger middleware carries correlation into async work, and emitters are pluggable (in-memory for tests, Monolog for output, OpenTelemetry for trace correlation). Sensitive-field redaction and event size limits are built in. Tail-based sampling decides retention after the fact, so you keep errors and slow requests. Cost of entry is low and the integration surface is narrow; the main risk is pre-1.0 API churn, so isolate it behind our own logging facade. Note: this is Symfony-only — if the target service is Laravel, the pitch becomes "adopt the pattern or fund a thin Laravel adapter," and that's a separate estimate.