Statamic Certificates Laravel Package

Technical Evaluation

Architecture fit This remains a Statamic Control Panel addon shipped as a Laravel/PHP Composer package, with no new runtime architecture introduced since v0.1.4. Two releases are now in scope for this assessment:

• v0.1.4 — declarative CP navigation metadata (settingsNavParent() returning a [section, name] tuple) pointing the addon's settings at its own CP nav entry.
• v0.1.6 — a pure dependency-contract change: statamic-courses ^0.6 is added to the Composer constraint. The release explicitly states nothing the addon reads has changed, so there is no code-path or data-shape delta.

Architecturally, v0.1.6 is the more consequential of the two for a TPM even though it is the smaller change in code terms. It converts an implicit assumption ("this addon works alongside statamic-courses") into an explicit, machine-enforced constraint. That is good hygiene — the constraint is now discoverable by Composer rather than by incident — but it also means the addon's installability is now a joint function of two third-party packages rather than one.

Integration feasibility High for both releases; v0.1.6 is again a Composer version bump with no migration, no config key, and no cache-clear step beyond normal autoload refresh.

The integration variable set has grown from one to two:

1. statamic-brand-context (soft feature gate, from v0.1.4). At >= 1.16 the addon's settings render as the sub-item "Einstellungen" beneath its own CP nav entry; below 1.16 the method is ignored and the prior layout persists. Addons with no nav of their own collapse into a shared "Addon-Suite" page under Settings.
2. statamic-courses (hard constraint, from v0.1.6). Hosts must now resolve to ^0.6 to install this release.

The second is the sharper edge: the brand-context gate degrades silently, whereas a Composer constraint fails loudly at composer update. Loud is preferable, but it lands at dependency-resolution time, which is often CI rather than a developer's machine — so the practical failure surfaces as a red pipeline, not a conversation.

Technical risk Low, and unchanged in kind from v0.1.4 — but the risk profile has shifted from presentational to dependency-graph:

• New transitive pinning surface. statamic-courses ^0.6 can conflict with any other package in the host that requires <0.6, including other addons in the same suite. This is the most likely cause of an install failure and it is entirely outside this package's control.
• Constraint semantics unverified. The notes say ^0.6 was added. Whether that is a widening (previously ^0.5 || ^0.6, now including 0.6), a tightening (previously unconstrained or *, now floored at 0.6), or a replacement of a 0.5-only constraint materially changes the upgrade story — a tightening is a potentially breaking change for hosts on 0.5, while a widening is strictly additive. The release framing implies additive, but it is not stated.
• Silent degradation still present. The v0.1.4 brand-context behavior is untouched: no error, warning, or log line when brand-context is below 1.16. Teams will see two different CP layouts across environments and may misattribute it to this release.
• Version-coupled UX. A cosmetic outcome (where a settings item appears) still depends on a transitive package version — a fragile contract to reason about during upgrades and incident triage.
• Shared-parent ambiguity. The "Addon-Suite" fallback implies multiple addons can target the same parent; ownership, ordering, and collision behavior remain undescribed.
• Release velocity. Three tags (0.1.4, 0.1.5 unseen, 0.1.6) within a short window, with 0.1.5 undocumented in this assessment. Worth confirming 0.1.5 carried nothing material before treating 0.1.6 as the cumulative state.

Key questions

1. Is the statamic-courses constraint in v0.1.6 a widening, a tightening, or a replacement of the prior constraint? Is it require or require-dev/suggest?
2. What did v0.1.5 change? It is not covered by either set of release notes reviewed here.
3. What are the full declared constraints — Statamic major versions, PHP version, Laravel version range, and now statamic-courses and statamic-brand-context minimums?
4. Is statamic-brand-context a hard require or an optional suggest/soft dependency? If hard, what is its minimum constraint?
5. Does settingsNavParent() fail closed (ignore) or fail loudly if the referenced [section, name] entry does not exist?
6. What is the deterministic ordering when several addons declare the same parent or fall back to "Addon-Suite"?
7. What does this addon actually do beyond settings navigation, and does any of that surface carry permission/role implications in the CP?
8. Is there automated coverage for the pre-1.16 and post-1.16 brand-context paths, and for the statamic-courses 0.5 vs 0.6 resolution paths?

Integration Approach

Stack fit Standard Laravel + Statamic CP stack. No new infrastructure, queue, storage, or external service dependency. The v0.1.6 change touches only composer.json metadata; v0.1.4 touches only the admin surface. Neither affects request-path performance or application domain logic.

Migration path No data or schema migration for either release. Upgrade path is composer update on this package; nothing to publish, no config keys to add. The one new prerequisite: the host must already resolve, or be able to resolve, statamic-courses ^0.6 — so the effective migration is a two-package co-upgrade where previously it was a one-package bump.

Compatibility Backward compatible at the code level for both releases; the new nav method is additive and older brand-context releases ignore it. Forward compatibility for the CP layout requires brand-context >= 1.16. v0.1.6 constrains forward install compatibility with statamic-courses: hosts pinned to 0.5 will be unable to install this release, which is a deliberate and correct use of Composer, but should be communicated as a coordinated upgrade rather than a routine patch.

Sequencing

1. Confirm which statamic-courses version the host resolves today, and enumerate any other package pinning <0.6 before touching anything.
2. Upgrade statamic-courses to ^0.6 first, on its own, and verify the host's course functionality is unaffected — this isolates the riskier of the two changes.
3. Upgrade statamic-brand-context to >= 1.16, then this addon to v0.1.6. This yields the new CP layout and makes the v0.1.4 change observable and testable in one step.
4. Verify in a staging CP as a super user and as a scoped/limited-role user, since nav visibility is permission-sensitive.
5. If brand-context cannot be upgraded (pinned elsewhere), still deploy v0.1.6; the CP behavior is unchanged and only the courses constraint takes effect.
6. Roll out to production and confirm no duplicate or orphaned nav entries where other addons also register settings.

Operational Impact

Maintenance Still negligible ongoing cost, with one addition to the release checklist: this addon now participates in a two-package compatibility matrix (statamic-courses 0.6 and statamic-brand-context 1.16). The maintenance burden remains one of awareness rather than effort — future upgrades of either dependency should be paired deliberately rather than left to Composer's resolution order.

Support Two support vectors now, distinguishable by where they surface:

• "My settings moved" — CP layout ticket. Rule to publish plainly: the new sub-item layout requires brand-context >= 1.16; otherwise the previous layout is retained by design and is not a bug. Because the behavior is silent, first-line support needs the brand-context version in any intake form.
• "Composer won't resolve / CI is red after the bump" — dependency conflict on statamic-courses. Almost always another package pinning <0.6, not this addon. Support intake should capture the full composer why-not statamic-courses 0.6 output.

Scaling No effect. CP navigation metadata renders for authenticated admin users only and is not on the hot path; cost is constant per admin request regardless of application traffic. The dependency constraint has no runtime footprint at all.

Failure modes

• statamic-courses resolution conflict — host or sibling addon pinned to <0.6, blocking install. Loud, caught at CI or deploy, most likely failure mode introduced by v0.1.6.
• Older brand-context present — method ignored, old layout retained, no error surfaced. Silent, and the hardest to diagnose; unchanged from v0.1.4.
• Referenced parent entry absent or renamed — settings could be orphaned or land on the shared "Addon-Suite" page depending on fallback behavior (unverified).
• Multiple addons declaring the same parent — potential ordering ambiguity or duplicate settings entries.
• Version skew across environments — staging and production showing different CP layouts after an apparently identical deploy, now compounded by a second version to correlate.

Ramp-up Very low. For a TPM this needs no engineering onboarding beyond a two-line dependency note. The practical ramp-up is for whoever owns the admin release checklist: record both paired constraints (this addon ↔ brand-context 1.16, this addon ↔ statamic-courses 0.6) so future upgrades do not silently revert the CP layout or block installs. Add a standing check that Composer resolution is exercised in CI against the host's real dependency set, so constraint conflicts fail before deploy rather than during it.