Filament Goatcounter Laravel Package

Product Decisions This Supports

• Panel information architecture: Plugin::make()->navigationGroup(string|Closure) lets us place the package's settings page inside one of our own panel navigation groups instead of accepting the package's translated default. This is a small but real lever for keeping the admin sidebar organized around our vocabulary rather than vendor terminology.
• Multi-panel / multi-tenant layouts: the Closure form implies per-panel resolution, so a single install can render the page under different groups in different panels (e.g. per-tenant or per-role panels). Worth confirming the closure's signature before we design around it.
• Build vs buy: this remains a configuration-level decision, not an engineering one. Placement costs one method call; the alternative is forking the view or building our own settings surface, which we should not do for a navigation-label concern.
• Roadmap impact: none material. This is an ergonomics and consistency improvement for administrators, not a new end-user capability. It should not displace anything on the roadmap, but it does remove a recurring "why is this menu item named that way" class of feedback.
• Upgrade sequencing: the feature is gated on filament-analytics-core 3.1. That dependency bump is the actual decision to schedule; the navigation group is the payoff.

When to Consider This Package

Consider adopting (or taking this upgrade) when:

• We are already on Filament and want the analytics settings surface without building it.
• We can move to filament-analytics-core 3.1 — 3.1.0 of this package assumes it. Teams pinned below 3.1 get no benefit from this release and should treat the upgrade as a separate, scheduled task.
• Our panel navigation is opinionated: custom group names, non-English admin locales, or several panels that should not share one group label.
• We want the default preserved where it already works — omitting the call keeps the translated group, so adoption can be incremental and per-panel.

Look elsewhere, or defer, when:

• We are not on Filament, or are on a version the core dependency does not support.
• Our need is analytics/reporting behavior rather than a settings page — this release adds no reporting capability.
• We need navigation control beyond a single group assignment (ordering, collapsibles, nested groups, icons) — that is not what this method exposes.
• The translated default label is already acceptable and the core 3.1 bump carries risk we don't want to absorb for a cosmetic change.

How to Pitch It (Stakeholders)

For executives: A minor, additive release. It lets us file the analytics settings page under a navigation group we already use, instead of the vendor's default label, so the admin experience stays consistent with the rest of the panel. There are no breaking changes and no user-facing behavior change unless we explicitly opt in by calling the new method — doing nothing preserves today's behavior exactly. The cost is a dependency bump to filament-analytics-core 3.1, which is the only real item to schedule. No roadmap impact.

For engineering: One new fluent method on the plugin, accepting a string or a closure, applied per panel. Defaults are unchanged, so it is safe to merge and adopt selectively. Two things to verify before we commit: (1) the closure signature — what it receives and when it is evaluated — since we would rely on it for per-panel grouping; (2) that the filament-analytics-core 3.1 constraint is compatible with our pinned Filament version and does not force a wider upgrade. Recommend landing the dependency bump on its own, then applying the navigation group panel by panel so any layout regressions are easy to attribute.