Statamic Inbox Laravel Package

Technical Evaluation

Architecture fit. v0.2.4 does not touch the inbox domain at all — no changes to ConversationQuery, the inbox:summary command, fetch handling, or snooze logic. What it does is correct a blind spot in the previous assessment: the package is not purely a headless Laravel domain module with an artisan surface. It is a Statamic addon with a Control Panel presence, and v0.2.4 changes how that presence nests. The addon now declares settingsNavParent() returning [section, name] for its own CP navigation entry, so its settings screen renders as a sub-item ("Einstellungen") under its own nav entry rather than wherever it previously landed. Addons without their own navigation share a single "Addon-Suite" page under Settings. That is a UI-information-architecture change, not a data change, and it tells us the package owns a CP nav entry plus a settings screen — a surface the prior assessment never accounted for in access control, screenshots-in-tickets, or user training.

Integration feasibility. Low risk, with one new external constraint. The release introduces an explicit dependency floor: the new layout requires statamic-brand-context 1.16 or newer. Older versions ignore the method and keep the previous layout — graceful degradation, which is the right design, but it means our CP layout becomes a function of a different addon's version. Two addons now have to be upgraded in a compatible order, and the visible outcome differs per environment if our sites are not on the same brand-context version. No migration, no config key, no breaking change, so the code-level upgrade is a composer bump.

Technical risk. Three items:

1. Provenance. The v0.2.4 notes describe only Statamic settings navigation and reference statamic-brand-context. Nothing mentions inbox, mailboxes, or the summary command. Plausible readings: this is the same Statamic-based addon (coherent — Statamic addons are Laravel packages, and an inbox addon would legitimately have a CP nav entry), or the notes were published against the wrong repository. Confirm the tag belongs to the package we assessed before merging anything; the whole v0.2.3 assessment assumed a Laravel-only shape.
2. Implicit inter-addon coupling. A CP layout that depends on another addon's version is a support-matrix problem. If we run brand-context 1.15 on one site and 1.16 on another, the same addon version produces two different settings layouts, and a runbook screenshot will be wrong on half the fleet.
3. Label coupling. The sub-item "carries the same name as the navigation entry, also when the entry shows a counter." If the nav entry label includes a live counter, the settings sub-item inherits whatever that label evaluates to. Worth eyeballing: a settings menu item whose text changes with unread volume is odd but harmless; it becomes a bug only if the label is long enough to truncate in the CP sidebar. Also note the string is German ("Einstellungen") — confirm whether the addon ships translations or whether our English-language CP will show a mixed-language settings tree.

Key questions.

• Confirm the v0.2.4 tag belongs to the inbox/helpdesk package we assessed, and not to a sibling addon.
• Is statamic-brand-context a hard require at ^1.16, or a suggest/soft check? What is the actual behavior on 1.15 — silent fallback to the old layout, or a warning?
• On our installs, does this addon have its own CP nav entry, or do we currently fall under the shared "Addon-Suite" page? That determines whether the user-visible change is a move or a no-op.
• Is "Einstellungen" localized, and do we publish lang files or accept the default?
• Does the counter-bearing nav label affect the settings sub-item in any user-visible way (truncation, layout shift)?
• Still open from v0.2.3 and now more important, since CP screens are where operators read these numbers: is the --json output shape stability-committed, what exactly is --wartet measured against (calendar/business days, mailbox vs server timezone), is there a retention window on fetch-error records that can make the summary read healthy when it is empty, is ConversationQuery a documented extension point, and how does --brand fail on an unknown value?

Integration Approach

Stack fit. Statamic addon on Laravel: composer update, no publish step, no migration. It now participates in the Statamic CP navigation lifecycle and in the brand-context addon's settings grouping. No new infrastructure or SaaS dependency; the new coupling is to another composer package already in the CP stack.

Migration path. Bump the dependency in a branch, run the existing test suite (which will not exercise CP layout, so treat it as a regression check on the domain logic only), then open the Control Panel on staging and compare the Settings tree against the pre-bump build. Check three states explicitly: addon with its own nav entry, addon without one (shared "Addon-Suite" page), and the fallback path on brand-context 1.15 if we still run it anywhere. No data migration means no backfill and no rollback risk beyond reverting the composer lock.

Compatibility. No deprecations or removals. Two compatibility vectors, both unchanged in kind but now explicit: the --json payload shape (external consumers) and the brand-context version floor (CP layout). Keep the standing rule that we do not depend on Support\ConversationQuery until it is documented as public. Add a second rule: do not describe the CP settings location in a runbook without stating the brand-context version it applies to.

Sequencing.

1. Verify the release/tag provenance before anything else.
2. Reconcile brand-context versions across the fleet, or accept and document a mixed layout during the transition.
3. Upgrade and regression-check the v0.2.3 surfaces that actually matter — nav unread badge and tab counts — since the shared query still sits behind every page load even though this release did not touch it.
4. Run inbox:summary against staging then production to keep the baseline current and re-confirm the read-only claim empirically.
5. Only after the --json output has proven stable for a couple of weeks, wire it into monitoring or runbooks and pin the package version.

Operational Impact

Maintenance. Near zero for the change itself. The ongoing cost is now two-dimensional: the --json contract (pin the version, add a smoke test asserting the payload parses and expected top-level keys exist) and the CP layout dependency on brand-context. The latter needs no test but does need a line in the runbook: "settings live under X, and the location depends on brand-context ≥1.16."

Support. This release is a support-experience change, not a capability change. It reduces "where are the inbox settings?" tickets if our sites are on brand-context 1.16+, and it will generate a small burst of them at the moment of upgrade if support screenshots are stale. The substantive support posture from v0.2.3 is unchanged and still the priority: inbox:summary shortens mailbox-health triage from "open the UI and count" to one SSH command, and --details is the right compromise — subject line, counterparty, age, never a body. Write the runbook entry, define the --wartet threshold we actually use, and name who may run --details.

Scaling. Unchanged from v0.2.3 and unaffected by this release. The command aggregates per mailbox, so cost tracks mailbox count and conversation volume, not message bodies; the --details path walks conversations behind each number and can be expensive on a large aged backlog. The shared ConversationQuery still sits behind every listing page load and every nav badge render — confirm index coverage on the snooze and unread predicates before this goes to a large tenant, and confirm the command is safe to run concurrently with a fetch job. The new scaling note is organizational: one more addon version to keep in sync across sites.

Failure modes.

• Wrong release on wrong package. If these notes were published against the wrong repository, the tag we upgrade to may contain none of what the notes describe. Verify provenance first; this is the cheapest check and the highest-consequence error.
• Silent layout divergence. Sites on brand-context 1.15 keep the old settings location. Support guidance and screenshots will be wrong on those sites with no error anywhere. Detect by asserting brand-context version per environment rather than assuming.
• Silent healthy. Unchanged and still the most dangerous operational failure: if fetch-error records are pruned, the summary reports zero problems because nothing is left to report. Absence of errors and absence of error records must be distinguishable; document retention in the runbook.
• Boundary drift on snooze. "Snoozed until today" is a date-boundary computation; a mailbox/server timezone mismatch makes conversations appear snoozed or awake at the wrong hour. Test with a non-UTC mailbox.
• Badge regression. Still the highest-probability real failure across this release line, since the shared query remains behind every request. Regression-test tab counts and the nav unread badge explicitly.
• Unknown --brand. If an unrecognized brand returns an empty summary rather than an error, an operator reads "no work waiting" when they meant a different brand. Prefer loud failure; verify before relying on it.
• Stale summary as decision input. Operators will escalate from this output. State in the runbook that it is a point-in-time snapshot, not a queue, and pair it with the fetch timestamp.

Ramp-up. Engineering: a version bump plus a CP screenshot refresh — under an hour. Support and on-call: the real effort, and unchanged at roughly half a day — publish the runbook entry, define the --wartet threshold and the --details authorization rule, and add one line naming the settings location and the brand-context version it requires. Do not invest more than that in v0.2.4; the release does not earn it.