Runtracy Laravel Package

Product Decisions This Supports

• Stack-fit gating for the PHP portfolio. Runtracy is a Tracy debugger integration for the Slim micro-framework, not Laravel. If our roadmap is Laravel-first, this package is out of scope by default; if we maintain Slim 3-era services or legacy APIs, it becomes a candidate. The first decision it informs is simply which services are even eligible.
• Build vs. buy vs. borrow for developer tooling. Tracy (the upstream debugger) is mature and actively maintained; Runtracy is a thin adapter. The real decision is whether to (a) depend on this adapter, (b) wire Tracy into Slim directly with ~50 lines of bootstrap code, or (c) fork the adapter. Because the package is stale (last release 2017-05-24, zero dependents), the likely outcome is borrow the pattern, own the code rather than adopt as a dependency.
• Debug/observability investment for non-production environments. A debug bar with request panels, error pages, and dump panels materially shortens time-to-diagnose in local/staging. This supports a roadmap item like "standardize local debugging across PHP services" — but only for the subset of services on Slim.
• Dependency risk budgeting. Apache-2.0 is permissive and dev-only installs carry negligible production blast radius, but an unmaintained package with no dependents means no community backstop, no security triage, and no PHP 8+ guarantees. That feeds a "no new unmaintained dependencies" policy decision.
• Migration sequencing. If we're planning Slim 3 → Slim 4 (or Slim → Laravel) migrations, adopting this now creates a throwaway integration. It informs when to invest in tooling relative to platform migrations.
• Vendor/ecosystem posture. Choosing Tracy as the debugging substrate (vs. Symfony VarDumper, Xdebug-only, or a hosted APM) is a standardization decision that outlives any single adapter.

When to Consider This Package

Consider it when:

• The service is confirmed on Slim 3 (or contemporaneous Slim), running PHP 5.6–7.x, and unlikely to be migrated within the planning horizon.
• The team already knows Tracy and wants its error screen, debug bar, and dump panels without hand-rolling bootstrap wiring.
• It is installed dev-only (require-dev), never shipped to production.
• You're comfortable treating it as a reference implementation — copy the integration, pin it, and accept ownership — rather than as a supported upstream.
• Time-to-first-debug matters more than long-term maintenance (prototypes, internal tools, short-lived services).

Look elsewhere when:

• The stack is Laravel — use Laravel Telescope, Ignition/Flare, or laravel-debugbar; Runtracy adds nothing here.
• The stack is Slim 4+ — the middleware/PSR-15 interfaces changed; use Tracy directly or a maintained Slim 4 integration.
• You need PHP 8.x compatibility, security patches, or an active maintainer — 2017-era releases and zero dependents are a hard stop for anything long-lived or customer-facing.
• You need production observability — this is a debugging aid, not monitoring. Use Sentry, OpenTelemetry, or an APM for that; conflating the two is a common and expensive mistake.
• Your dependency policy requires SLA, CVE response, or a named maintainer.

How to Pitch It (Stakeholders)

To executives: This is a small, free, dev-only debugging helper for one narrow slice of our PHP estate (Slim applications). It costs nothing to evaluate and nothing at runtime, but it has been unmaintained since 2017 with no downstream users — so we should treat it as a source of a proven pattern, not a strategic dependency. Recommendation: spend a day evaluating whether copying its ~small integration into our own codebase gets us the same debugging ergonomics with none of the abandonment risk. Expected benefit is faster diagnosis in development and staging; expected cost is near zero, with a small ongoing ownership burden if we fork.

To engineering: Tracy is the value here, not the wrapper. If you're on Slim 3, Runtracy saves you the bootstrap wiring for a debug bar, rich error pages, and dump panels — genuinely useful day-to-day. But it predates Slim 4 and PHP 8, has zero dependents, and won't get fixes. Install it dev-only, or better, lift the integration into our own dev-support package so we control compatibility. Do not let it become a production dependency, and do not treat it as a substitute for real error tracking.

To security/compliance: Apache-2.0, permissive, dev-only, no data egress. Primary risk is unmaintained code rather than licensing or supply chain; mitigate by vendoring or forking if adopted.