Statamic Secretary Laravel Package

Technical Evaluation

What v0.1.13 actually is. A hygiene release, not a feature release. Three things landed: (1) committed Control Panel assets rebuilt against a pinned Statamic 6.31.0 lock, (2) CI now verifies those assets are deterministic (build output must match what is committed), (3) it rolls up the security work from v0.1.11 (Postmark replay protection) and v0.1.12 (dependency lock refresh). There are no new features, no deprecations, and no announced breaking changes in this version.

Architecture fit. The notes place this firmly as a Statamic addon consumed by a Laravel application, not a standalone Laravel library: it ships Control Panel (CP) frontend assets and is version-locked to a Statamic 6.31.0 dev lock. That means it inherits Statamic's addon lifecycle — service provider registration, config publishing, Vite-based CP asset build — and its compatibility envelope is capped by the host app's Statamic major/minor. It is not a drop-in for a plain Laravel app without Statamic.

Integration feasibility. Mechanically easy: Composer require, publish config, publish/migrate if the replay-protection store is DB-backed, add Postmark credentials and a webhook route. The friction points are the committed-asset workflow (consumers either trust the committed dist or must reproduce the build) and the Statamic version pin.

Technical risk — the dominant concerns are version maturity and coupling, not this release.

• Pre-1.0 (0.1.x). No semver stability guarantee. Every 0.1.x bump is allowed to break. This is the single largest risk and it will not change based on v0.1.13.
• Hard Statamic coupling to a specific lock. "Development lock" is a yellow flag: it suggests the shipped assets were built against dependency versions resolved from a dev lockfile rather than a released, reproducible dependency set. Worth confirming that the pin resolves identically for an external consumer.
• Security posture is improving but opaque. "Replay protection" and "security lock refresh" imply prior exposure (replayed Postmark webhooks, vulnerable transitive dependency). We have no CVE, advisory, or affected-version range in the notes.
• Statefulness. Replay protection requires a dedup store (cache or DB) with a TTL; that is an operational commitment that has not been documented here.

Key questions to put to the maintainer before adoption.

1. One-line scope: is this a Postmark mail transport, a Postmark webhook/event handler, a CP UI over email logs, or all three?
2. Exact supported matrix: Laravel versions, PHP versions, Statamic 6.31.x only or a range?
3. Does the "development lock" resolve to released packages for consumers, or only in the maintainer's CI?
4. Where is replay-protection state stored, what is the retention/TTL, and is there a prune command?
5. What was the vulnerability behind v0.1.11/v0.1.12 — advisory link and affected range?
6. Are releases tagged and signed, and is there an upgrade guide or public changelog?
7. Is there a published dist integrity check (checksum or build attestation) beyond internal CI?

Integration Approach

Stack fit. Assumes Laravel + Statamic 6.31.x + Control Panel enabled. In that stack the package slots in as a normal addon; outside it, nothing here applies. Confirm the Laravel major implied by Statamic 6.31 matches the host application before anything else.

Migration path. v0.1.12 → v0.1.13 is patch-level and should be a lockfile-only change plus a rebuilt asset directory: no config keys, no routes, no migrations. If arriving from ≤ v0.1.10, treat it as a minor upgrade — verify whether the replay-protection migration is new, and whether the webhook endpoint must be re-registered in Postmark.

Compatibility gates.

• Pin ^0.1.13 explicitly; do not float dev-main.
• Pin Statamic to the same 6.31.x line the addon's assets were built against; a Statamic minor bump invalidates the CP asset hash.
• Verify the lockfile diff shows only the intended security bumps before merging.

Sequencing.

1. Branch, composer update <package>, diff composer.lock and review every transitive bump.
2. If migrations are published, run them in staging; confirm rollback path.
3. Publish/rebuild CP assets and confirm the build is byte-identical to the committed output (this is the property CI now asserts — reproduce it locally to prove the pin is honest).
4. Postmark webhook smoke test, including a deliberate duplicate delivery, to prove replay rejection works and does not reject legitimate retries.
5. Verify cache/DB backend used by the dedup store exists in production (Redis vs. array driver is a classic silent failure).
6. Roll out to a canary tenant, then broadly.

Operational Impact

Maintenance. Release cadence is high relative to payload size — three releases in three patch versions, two of them security-motivated. Combined with pre-1.0 versioning, expect to touch this package at least monthly and to read every changelog. Small blast radius per release, but non-zero.

Support. Unverified upstream responsiveness. No LTS, no vendor SLA, likely one or two maintainers. Needs a named internal owner who can read the source; do not assume upstream will answer.

Scaling. The package itself is thin; volume is bounded by Postmark and by CP UI traffic. The real scaling concern is the replay-protection store — it grows with webhook volume and needs a TTL and a prune job, or it becomes an unbounded table/cache region.

Failure modes.

• Replay protection false-positive: legitimate but delayed or retried Postmark webhooks silently dropped. Symptom is missing email events, not errors — dangerous.
• Stale committed CP assets after an upgrade: broken CP JS/CSS, hash mismatches, 404s on hashed filenames.
• Statamic minor drift: CP asset incompatibility, usually presenting as a blank or unstyled panel.
• Dedup store backend misconfigured (array/file cache in prod): replay protection appears enabled but enforces nothing.
• Webhook signing secret rotated without redeploy: handler rejects everything.
• No visible alerting on any of the above; all are silent.

Ramp-up. Roughly half a day for a Laravel developer already fluent in Statamic addon conventions; add a further day if the team must own and reproduce the CP asset build pipeline rather than trusting committed dist. Teams without Statamic experience should budget a week, most of it on Statamic rather than this package.

Recommendation. Safe to take as a patch on an already-integrated v0.1.11+ install. For new adoption, treat the pre-1.0 version and the Statamic-only fit as the deciding factors, not the security fixes — and do not sign off until questions 1–4 above have answers, since the current changelog does not describe what the package does, what it supports, or how its new stateful component behaves.