Statamic Accounts Laravel Package

Product Decisions This Supports

• Control Panel information architecture. This release decides where the addon's settings appear in the Statamic CP: it now declares settingsNavParent() so its settings render as a sub-item ("Einstellungen") under the addon's own navigation entry, rather than being orphaned or lumped in generically. For a PM, that's a discoverability decision — fewer "where do I configure this?" support tickets and a shorter path from install to first successful configuration.
• Suite coherence. Addons that don't ship their own nav share a single "Addon-Suite" page under Settings. If you're assembling or reselling a bundle of addons, this is the mechanism that makes the bundle feel like one product instead of N disconnected plugins — a positioning and packaging input, not just a cosmetic one.
• Upgrade sequencing and risk tolerance. v0.5.1 has no migration and no new config key, so it's a low-risk patch you can take on a normal cadence. But its behaviour is conditional on statamic-brand-context ≥ 1.16; on older versions the method is ignored and layout is unchanged. That's a "schedule the brand-context bump separately" decision, and the fallback means the upgrade can't break existing installs.
• Dependency floor management. The release effectively sets an implied minimum for brand-context if you want the improved layout. Treat that as a roadmap input: decide whether the CP tidy-up justifies bumping and re-testing brand-context across your environments.
• Build vs. buy. Adopting this rather than hand-rolling CP settings pages buys you the navigation convention for free, but ties your admin UX to another vendor's release timing.

When to Consider This Package

Adopt when:

• You're on Statamic (Laravel-based) and the CP is used by non-technical editors or clients, so settings placement materially affects usability.
• You already run, or plan to run, statamic-brand-context at 1.16 or newer — otherwise this release provides no visible benefit.
• You operate multiple addons and want them to present as a coherent suite under one Settings page.
• You need a low-friction, no-migration upgrade and can absorb a pre-1.0 API surface.

Look elsewhere or wait when:

• You're not on Statamic — the settings-nav and brand-context integration is meaningless outside that ecosystem.
• You require a stable 1.0+ API contract; at v0.5.x the interface can still change between minor releases.
• You can't control the brand-context version (managed hosting, locked dependency tree), in which case you inherit the older layout and none of the upside.
• Your addon already has a bespoke CP navigation structure you'd have to unwind to use the shared convention.
• Settings placement isn't a pain point — this is polish, not capability.

How to Pitch It (Stakeholders)

To executives: A small, low-risk release that makes the addon easier to find and configure inside the admin panel. Settings now sit under the addon's own menu entry — or under a shared "Addon-Suite" page when several addons are installed together — which reduces confusion for editors and cuts configuration support requests. There is no migration and no new configuration, so there's no deployment cost and no downtime risk. The improvement only appears once our statamic-brand-context dependency is at 1.16+, so the only real decision is when to schedule that bump.

To engineering: One new method, settingsNavParent(), returning [section, name] of our own CP nav entry. It degrades gracefully — older brand-context versions ignore it entirely and keep the current layout — so the upgrade is safe to ship independently of the dependency bump. No schema change, no config key, no data migration. Flag for planning: the package is at v0.5.1, so treat the public API as pre-stable and pin versions; and note we now have a soft coupling to brand-context's release cadence for admin UX changes.