Statamic Teams Laravel Package

Technical Evaluation

Architecture fit: This is a Statamic (Laravel) addon, so it inherits the standard package architecture: a service provider, a Control Panel nav registration path, and config/settings surfaced through Statamic's addon settings system. v0.4.2 adds one thing to that architecture — the addon now declares settingsNavParent(), returning a [section, name] tuple that identifies its own CP navigation entry. That is a presentation-layer contract, not a data or domain change: it tells the host where to mount the addon's settings screen. For a TPM this is a low-surface-area release: it changes where users find configuration, not what the configuration does.

The important architectural nuance is that the behaviour is conditionally applied. With statamic-brand-context 1.16 or newer, the addon's settings render as the sub-item "Einstellungen" beneath the addon's own nav entry. On older brand-context versions the method is ignored and the previous layout persists. That means the addon has an optional, version-gated integration with a sibling package rather than a hard dependency — good for resilience, but it introduces two possible CP layouts across the fleet that support and documentation must account for.

Integration feasibility: High. composer require plus the existing Statamic addon registration is unchanged; there is no migration, no new config key, and no new service to boot. The only integration decision is whether the environment runs brand-context 1.16+.

Technical risk: Low-to-moderate, concentrated in the soft coupling rather than the code change itself.

• Version-gated behaviour means the effective UX differs per install. If brand-context is present but pinned below 1.16, users see the legacy layout with no error and no warning — a silent divergence.
• Third-party contract ownership. It is unclear whether settingsNavParent() is a Statamic core convention, a brand-context convention, or an addon-local convention that only brand-context happens to consume. If it is brand-context-specific, the addon's CP placement is now partly governed by another vendor's release cadence.
• Nav collisions. Multiple addons declaring settings under a shared "Addon-Suite" page under Settings raises the question of label uniqueness and ordering — "Einstellungen" as a sub-item name is generic and will repeat across addons sharing the suite page.
• Localisation. The literal sub-item label "Einstellungen" suggests a German-language default; confirm whether it is translatable and what non-German CP users see.
• Validation. The [section, name] tuple appears unvalidated at the contract boundary — a malformed return would presumably degrade to the legacy layout or misplace the item.

Key questions:

1. Is settingsNavParent() specified by Statamic core, or is this an addon-to-addon convention with brand-context? If the latter, what is the compatibility commitment if brand-context changes the signature?
2. What is the exact behaviour when brand-context is absent entirely (not merely old)? Does it fall back cleanly to the previous layout?
3. Is the "Einstellungen" label translatable, and what is the rendered label in a non-German CP?
4. How are label collisions and ordering resolved when several addons share the "Addon-Suite" page?
5. Is there a minimum supported brand-context version we should declare, or is this intentionally left unpinned?

Integration Approach

Stack fit: Native. Composer-installed Statamic addon on the existing Laravel application; no new runtime, no new datastore, no queue or scheduler footprint. It slots into the same deployment artifact and the same config-cache/build pipeline already used for other addons.

Migration path: Explicitly none. The release states no migration and no new config key, so there is no schema step, no php artisan migrate variant, no backfill, and no settings re-entry for existing installs. Existing configuration persists unchanged; only the CP mount point for the settings screen may shift. That is the defining property of this upgrade: it is a view-layer relocation with a zero-data-migration footprint.

Compatibility: Two axes to pin.

• Statamic/Laravel: no change signalled in this release; validate against the project's current Statamic minor and PHP version as usual.
• brand-context: the behaviour switch sits at 1.16. Below that, the addon is backward compatible and behaves as before. Above it, the new layout applies. Both directions are safe — the release is deliberately non-breaking in either order of upgrade.

Sequencing:

1. Upgrade the addon to v0.4.2 first without touching brand-context. This is the safe, no-visible-change step and confirms nothing regresses on the legacy layout.
2. Verify in staging that the addon's settings still resolve and save correctly on the old layout.
3. If adopting the new layout is desired, upgrade brand-context to ≥1.16 in a separate change window, then re-verify CP navigation placement and settings persistence.
4. Only after both steps are validated in staging, promote to production.
5. Update internal runbooks/screenshots in the same window as step 3, since that is the step where the UI actually moves.

Keeping the two upgrades in separate changes is the key TPM call here: it isolates "did the addon break anything" from "did the navigation move," which makes rollback attribution trivial.

Operational Impact

Maintenance: Low code maintenance, slightly elevated coordination maintenance. The addon itself gains a small, static method; there is no ongoing operational cost. The real overhead is tracking the brand-context version boundary, because the addon's CP behaviour is now a function of another package's version. That is a dependency-graph item to add to the upgrade checklist, not a recurring task.

Support: This is where the release has its main cost. Support must now handle two CP layouts:

• Environments on brand-context < 1.16 (or without it): settings under the previous location.
• Environments on ≥ 1.16: settings as "Einstellungen" beneath the addon's own nav entry, or under a shared "Addon-Suite" page under Settings for addons without their own nav.

Screenshots, KB articles, and onboarding docs should be branched or annotated accordingly. Expect a short tail of "the settings moved" tickets immediately after any brand-context upgrade. The German-language default label also warrants a note if the user base is not German-speaking.

Scaling: No scaling implications. CP navigation is per-request presentation metadata with negligible cost, and there is no data path, no query, no cache, and no queue involved. Multi-site and multi-brand installs should be spot-checked only to confirm nav placement resolves consistently when several brand contexts exist — that is the one place where a shared-suite page could produce ambiguous placement.

Failure modes:

• Silent layout divergence — brand-context pinned below 1.16 yields the legacy layout with no warning. Mitigation: document the boundary and assert the intended brand-context version in the upgrade checklist.
• Malformed [section, name] return — if the tuple is wrong or partially populated, the settings entry may misplace or fail to attach. Mitigation: smoke-test CP nav after upgrade.
• Label collision — multiple addons emitting "Einstellungen" on the shared suite page. Cosmetic, but it degrades discoverability. Mitigation: confirm collision handling with the brand-context owner.
• Upstream contract change — a future brand-context release alters or removes the settingsNavParent() handling. This is the only genuinely consequential risk, and its blast radius is limited to CP navigation — no data loss, no outage.
• Rollback — trivial and symmetric. Reverting the addon restores prior behaviour; reverting brand-context restores the prior layout. No data to unwind.

Ramp-up: Effectively zero for engineers (one method, no migration) and low for support (one relocated settings screen plus a version boundary). The realistic ramp-up cost is documentation refresh, not skill acquisition. A single staging pass per environment plus updated screenshots covers it.

TPM verdict: Adopt. v0.4.2 is a contained, backward-compatible UX refinement with no migration and no new configuration surface. The decision it forces is not "is this safe" (it is) but "do we want to take the brand-context ≥1.16 dependency now or later" — and that should be scheduled as its own change, with docs updated in the same window.