App Status Bundle Laravel Package

Product Decisions This Supports

• Bug triage speed / support cost: The core value is answering "which build is this environment actually running?" inside the Symfony profiler. That shortens the loop between a QA or support report and the commit that caused it — a measurable reduction in mean time to diagnose, even if small.
• Build-vs-buy on internal tooling: This is a ~100-line profiler collector, not a platform. The decision it informs is "do we adopt an unmaintained third-party bundle, fork it, or spend half a day writing our own collector?" Given 0 stars, 0 dependents, and no release since July 2022, the honest answer is build or fork, and this package is best used as a reference implementation and a spec for what metadata to surface.
• Standardizing build metadata across services: Use it to force an internal decision on what build info we expose everywhere — git SHA, branch, tag, build timestamp, CI job/build number, deployer identity. That standard then applies to non-Symfony services too (headers, /version endpoint, error-tracker release tags), so the PM gets a cross-cutting convention out of a narrow tool.
• Roadmap signal, not a feature: Adopting it is a dev-experience/observability hygiene item. It should live in an "engineering enablement" line, not on a customer-facing roadmap, and it should not be sold internally as improving production reliability — the profiler does not run in prod.
• Scope correction: The framing matters. This is a Symfony bundle, not a Laravel package. If the roadmap assumes Laravel, this package is not a candidate at all, and the relevant equivalent is a Laravel debugbar/telescope panel or a simple /version route. Confirm the framework target before any evaluation time is spent.

When to Consider This Package

Consider (as a reference or a quick fork):

• The stack is Symfony (this bundle targets the Symfony Profiler; it is not usable in Laravel or framework-agnostic PHP).
• You only need the capability in dev/staging to correlate a running app with a commit — the "what am I looking at?" problem during QA passes and demo environments.
• You are comfortable pinning a commit and owning the code, because the upstream is dormant (last release 2022-07-15, no dependents, no community).
• You want a cheap template for wiring a custom DataCollector + profiler template rather than designing the panel from scratch.

Look elsewhere or build in-house:

• Laravel or any non-Symfony stack — hard stop; the bundle is profiler-specific.
• You need production visibility. Profiler collectors are debug-only. For prod, the right primitives are error-tracker release tags (Sentry release/dist), OpenTelemetry resource attributes, structured log fields, and an authenticated /version or /health endpoint. Those are the buy-or-standardize decisions; this package is not.
• You need Symfony 6.2+/7 support. No release in ~3.5 years means unsupported framework versions and no maintenance guarantee. Verify compatibility against your pinned Symfony version before assuming it installs; expect to patch service definitions and profiler template paths.
• Your dependency policy requires maintained packages (security advisories, automated updates, SBOM provenance). A 0-star, zero-dependent, single-maintainer bundle will fail that gate — correctly.
• The information is already available. If CI already stamps the build into composer.json/an env var and your deploy pipeline tags releases in your error tracker, the incremental value is a nicer panel, not new information.

How to Pitch It (Stakeholders)

To executives — one paragraph: This is a small developer-productivity utility, not a product capability. It surfaces build metadata (commit, branch, timestamp) inside Symfony's developer profiler so engineers and QA can immediately tell which build an environment is running, which trims time spent on "is this the version with the fix?" confusion. The package itself is effectively abandoned — no release since mid-2022, no adopters, no maintainer activity — so the recommendation is not to adopt it as a dependency. Instead, we take the idea and the metadata standard it implies and implement it ourselves in roughly a day, then extend that same standard to our production error tracking and /version endpoint, which is where the real operational value sits. Net ask: near-zero budget, small engineering timebox, no long-term dependency risk.

To engineering — the short version: The pattern is right, the package is not. It's a Symfony-only profiler collector that injects build info into a panel; useful in dev, invisible in prod. Upstream is dormant (0 stars, 0 dependents, last release 2022-07-15, MIT), so we'd own it from day one anyway. Proposal: use it as a reference implementation, write a ~100-line internal collector with our own metadata contract (SHA, branch, build number, timestamp, deployer), pin the contract in a shared doc, and wire the same fields into Sentry release tags and a /version endpoint so QA and on-call get the same answer in every environment. If we do take the dependency temporarily, vendor/fork it and gate it behind dev only.