Nova Horizon Link Laravel Package

Product Decisions This Supports

• Internal tooling consolidation: Nova is already the operations surface for support and on-call staff; Horizon is where queue health, failed jobs, and retry decisions live. This package closes the navigation gap between the two, so the decision it supports is "do we make our admin panel the single entry point for operational triage?" That's a small but real DX/ops decision, not a customer-facing feature.
• Mean-time-to-diagnose (MTTD) for queue incidents: every extra bookmark, URL guess, or environment-switch between admin and Horizon is friction during an incident. A smart link removes a step from the runbook. Frame this as an MTTR/MTTD lever for the platform or SRE-adjacent team, sized appropriately (seconds, not hours).
• Build vs. buy: this is a ~tens-of-lines convenience wrapper. The genuine PM decision is not "should we adopt this package" but "do we accept an unsupported dependency for something we could vendor in an afternoon?" Default recommendation: copy the pattern into your own Nova service provider rather than take a require on it. If you do adopt, pin it and treat it as disposable.
• Opportunity signal is misleading: the 4.16 "opportunity" score reflects a gap in the ecosystem (Nova ↔ Horizon integration is not first-party), not the package's maturity. Zero stars and zero dependents mean zero social proof, zero community testing, and a single point of failure. That is a vendor-risk input, not a product opportunity input.
• Roadmap placement: bottom of the backlog, "quality-of-life / internal tooling" swimlane. Ship it opportunistically alongside other Nova customizations; never as a standalone initiative, and never something you announce to stakeholders as a deliverable.

When to Consider This Package

Adopt or replicate when all of the following hold:

• You run Laravel Nova as a real operational surface (support, ops, or on-call actually use it), not just a demo admin panel.
• You run Laravel Horizon for queue management, and staff regularly need to jump from a resource/dashboard into Horizon.
• You have multiple environments (local/staging/prod) where Horizon paths and access differ, and manual linking is error-prone — this is where the "smart" part earns its keep.
• The link targets an internal audience, so a broken or stale link is a minor annoyance rather than a customer-visible defect.

Look elsewhere (or just write the link yourself) when:

• You don't use Horizon, or you've replaced it with a managed queue/observability stack (Datadog, Sentry, CloudWatch). The package has no value outside the Nova + Horizon pair.
• You need deep observability — metrics, alerting, historical queue trends. Use Horizon's own tooling plus an APM; a navigation link is not observability.
• You need access control beyond whatever Nova and Horizon already enforce. A link doesn't grant permissions, but it does create an expectation that the destination is safe for everyone who sees it. Verify Horizon's Horizon::auth gate matches Nova's audience before exposing the link broadly.
• Your team has a policy against unmaintained/zero-adoption dependencies in production. Zero stars, zero dependents, and a single maintainer is an honest red flag — fork it or reimplement.
• The link is the only thing you'd install it for. The dependency cost (composer audit surface, upgrade churn on Nova major versions) exceeds the implementation cost.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a small internal-tooling convenience: it puts a shortcut from our admin panel into our queue-monitoring dashboard so the team spends less time navigating and more time resolving incidents. It is not a customer-facing feature and carries no direct revenue impact. Cost is negligible — roughly an afternoon to build ourselves or a trivial dependency to adopt — and the risk is low because it touches internal staff tooling only. I'd fund it as part of routine internal tooling hygiene, not as a roadmap item, and I'd recommend we build the small amount of glue ourselves rather than depend on a package with no community adoption.

For engineering (the actual ask): Horizon exposes its dashboard at a configurable path; Nova already knows its own base URL and environment. The whole feature is a menu entry (or a resource tool/link) that resolves the Horizon route correctly per environment, hides itself when Horizon isn't installed or the current user fails Horizon's authorization gate, and opens in a new tab. Please implement it in-house behind a small config toggle rather than adding mad-web/nova-horizon-link as a dependency — we get the same behavior, we own the upgrade path across Nova majors, and we avoid an unmaintained third-party package in the auth-adjacent surface of our admin panel. Acceptance criteria: link appears only in environments where Horizon is enabled, respects the same authorization boundary as Horizon, and fails safe (hidden, not broken) if Horizon is removed.