Statamic Certificates Laravel Package

Product Decisions This Supports

• Control Panel information architecture for addon suites. The addon now tells the host where its settings belong (settingsNavParent() returns [section, name] of its own CP nav entry), so settings surface as the sub-item "Einstellungen" beneath that entry rather than floating loose. This is a UX decision made in code: fewer top-level settings pages, more predictable admin navigation.
• Consolidation strategy for multi-addon installs. Addons without a nav of their own are deliberately pooled into a single "Addon-Suite" page under Settings. This supports a "one place for suite configuration" model instead of one settings screen per addon — worth deciding explicitly before your CP Settings menu sprawls.
• Version pinning as a product decision. The improved layout only activates with statamic-brand-context 1.16+; older versions silently ignore the method and keep the previous layout. Adoption therefore implies a floor on the companion package — treat that as a roadmap dependency, not an implementation detail.
• Build-vs-buy and packaging signal. The fact that this coordination logic lives in a shared brand-context package (rather than in each addon) indicates an ecosystem-level convention. If you maintain several addons, aligning to that convention is cheaper than inventing your own settings-grouping mechanism.
• Upgrade cadence. No migration, no new config keys — this is a zero-cost upgrade that can ride along with routine maintenance rather than requiring a scheduled change window.

When to Consider This Package

Consider it when:

• You run or maintain multiple Statamic addons and want their settings discoverable in a consistent place in the Control Panel.
• You already depend on (or are willing to pin to) statamic-brand-context 1.16 or newer, so the new navigation behaviour actually takes effect.
• You want the settings-placement convention handled by the suite rather than hardcoded per addon.
• You can tolerate pre-1.0 versioning: at v0.1.x the API and conventions are still settling, and this release itself shows behaviour that changes based on a sibling package's version.

Look elsewhere or defer when:

• You are not on Statamic, or you run a single addon where a shared "Addon-Suite" settings page adds indirection without benefit.
• You are pinned to an older brand-context: you get the previous layout and no upside from this release.
• You need a stable, semver-guaranteed public API; a 0.x package is not that, and method-level contracts like settingsNavParent() may still shift.
• Your admin UX requirement is a bespoke navigation structure — this package imposes its own grouping model.

How to Pitch It (Stakeholders)

For executives: A small, low-risk maintenance release. It tidies where the addon's settings appear in the admin Control Panel, so administrators find configuration in one expected place instead of hunting across menus. No database migration, no new configuration, no downtime — the upgrade is effectively free. The only dependency note is that the improved layout requires the companion brand-context package at 1.16 or above; on older versions the current layout is preserved, so nothing breaks either way.

For engineering: Additive and opt-in. The addon now declares settingsNavParent() returning [section, name], which places its settings as the "Einstellungen" child of its own CP nav entry when brand-context ≥1.16 is present; addons without their own nav collapse into a shared "Addon-Suite" settings page. Older brand-context versions ignore the method entirely, so the change is backward compatible by construction. No schema changes, no config keys, no data migration. Practical ask: confirm the brand-context version floor in composer.json and verify the CP settings menu renders as expected in staging. Caveat to carry forward: the package is at 0.1.x, so treat the settings-navigation contract as provisional and pin versions accordingly.