Statamic Teams Laravel Package

Product Decisions This Supports

• Upgrade scheduling (low risk): v0.4.2 is a patch release with no migration, no new config keys, and no breaking changes. It can ride along with routine maintenance windows rather than needing a dedicated release slot or customer communication.
• Control Panel information architecture: the addon now declares settingsNavParent(), so its settings surface as the sub-item "Einstellungen" beneath the addon's own CP navigation entry — or, for addons without their own nav, under a shared "Addon-Suite" page under Settings. This is a discoverability decision, not a functional one: it determines whether admins find configuration by browsing their addon's nav entry or by going to Settings.
• Host-version dependency as a product constraint: the new layout only appears with statamic-brand-context 1.16 or newer; older versions ignore the method and keep the previous layout. This makes brand-context version a lever for what end users see, and means "upgraded the addon" and "users see the new layout" are two separate facts.
• Build vs. buy / don't reinvent navigation: the release is a thin conformance to the host package's navigation conventions. It is a reason not to build custom settings pages or bespoke admin menus — let the platform's convention carry the placement and inherit future IA improvements for free.
• Documentation and enablement scope: any admin-facing screenshots, onboarding steps, or support macros that reference where settings live need review, since the path to settings is now conditional on the installed brand-context version.
• Use cases: multi-addon Statamic installs where admins manage several addons' settings — the shared "Addon-Suite" page reduces hunting; and single-addon installs where grouping settings under the addon's own nav entry keeps context together.

When to Consider This Package

• Adopt/upgrade when: you already run this addon and want a zero-migration, zero-config improvement to settings discoverability; you are standardizing on statamic-brand-context 1.16+ across environments; or you run several addons and want their settings consolidated under one place rather than scattered.
• Treat as a no-op when: you are pinned to a brand-context version below 1.16. The release is safe but delivers nothing visible — upgrading is harmless, but do not promise stakeholders a UI change you will not get.
• Requires coordination when: environments run mixed brand-context versions (e.g. staging ahead of production), which will produce inconsistent CP layouts and confusing screenshots during support or QA.
• Look elsewhere when: you need settings that live outside the Statamic CP entirely, need per-role or per-site settings scoping beyond what the host navigation convention supports, or cannot take a dependency on brand-context because your stack is not Statamic-based.
• Gate before rollout: confirm the installed brand-context version per environment, and verify the settings entry resolves to the intended parent (own nav entry vs. "Addon-Suite") rather than a duplicate or orphaned menu item.

How to Pitch It (Stakeholders)

For executives: v0.4.2 is a routine maintenance release with no migration and no configuration changes — no downtime, no data work, no retraining. Its one user-visible effect is that admins find this addon's settings in a more predictable place in the Control Panel, grouped either under the addon's own menu or under a shared "Addon-Suite" settings page. That improvement is unlocked by a companion package version, so the practical ask is: approve a low-risk patch upgrade and confirm our brand-context version, and users get a tidier admin experience at effectively no cost.

For engineering: this is a patch-level release that adds a settingsNavParent() declaration returning [section, name] for the addon's own CP navigation entry. With statamic-brand-context >= 1.16 the settings render as the "Einstellungen" sub-item under that entry; addons without their own nav fall under a shared "Addon-Suite" page. Older brand-context versions ignore the method and retain the existing layout, so behavior is version-gated — verify across environments and check the menu renders once, not twice. No migration, no new config key, nothing to backfill.