Statamic Changelog Laravel Package

Product Decisions This Supports

• Build vs. buy for "what changed?" visibility. Replaces a bespoke "recent changes" CP widget or a hand-maintained changelog page with a one-line install. The realistic alternative is hours of dev plus ongoing upkeep; this is a composer require.
• Roadmap input on an audit/activity story. Shipping this as a low-cost experiment tells you whether editors actually look at change history. If usage is flat, you've saved yourself from investing in a full content audit-log feature; if it's high, that's a validated signal for a first-class roadmap item.
• Scope decisions on notification and digest behavior. The package chooses per-user, last-seen semantics over org-wide digests. That's a product opinion you can adopt as-is, or treat as a gap to build on (Slack/email summaries, "changes since last deploy" for the whole team).
• Support and onboarding workflows. New CP users, freelancers, and agency handovers get a self-serve answer to "who changed this / when did this ship?" — reduces interruptions to developers and shortens time-to-context for editors.
• Incident triage and post-mortems. A filtered commit view (by path or author, merges hidden) gives a fast, in-product timeline during "something broke, what landed?" moments, without granting CP users repo access.
• Tooling consolidation. If the team already runs Statamic's Git addon, the auto-commit filter collapses two overlapping sources of truth into one view — a small but real reduction in CP noise.
• Scoping constraint to record: this is a Statamic 6 addon, not a general Laravel package. It only enters the decision set for Statamic-based projects; treat it as out of scope for plain Laravel or other CMS work.

When to Consider This Package

Good fit when:

• You're on Statamic 6.0+ and PHP 8.3+, and the project is already the team's system of record for content.
• The application server has the git binary and a real .git directory — verified in production, not just locally.
• Your editors are technical-adjacent (agency, in-house content ops) and commit messages are meaningful.
• You want zero-maintenance change visibility and are comfortable with a young, single-release, likely single-maintainer dependency on a non-critical path.
• You use Statamic's Git addon and want the Spock / "Content saved" noise suppressed.

Look elsewhere or defer when:

• Deploy pipelines strip .git — container builds that copy only build artifacts, serverless/Vapor-style runtimes, read-only or ephemeral filesystems. There's no documented "read from a pre-generated log file" fallback, so this is a hard blocker, not a tuning exercise.
• You need compliance-grade audit logging. Git history is developer-centric and mutable: rebases and force-pushes rewrite it, and it won't capture field-level content diffs, retention policy, or tamper evidence. Per-user "seen" state surviving rewrites is a nice touch, not an audit control.
• The audience is customers or non-technical stakeholders. Raw commit subjects aren't release notes; don't repurpose this as a public changelog.
• You need notifications, role-based visibility, branch scoping, or diff rendering. Not in v1.0.0.
• Dependency risk tolerance is low. v1.0.0 with no track record: pin the version, keep it off the critical path, and have a fallback plan.
• Version mismatch — Statamic 5 or PHP < 8.3 has no supported path.

Practical evaluation gates before adoption: confirm .git presence in the built image; confirm which CP roles can see the nav item and whether commit author names/emails constitute unwanted data exposure; confirm the git shell-out is cached or bounded (a per-request git log on a large repo is a latency risk); confirm license terms.

How to Pitch It (Stakeholders)

For executives (30 seconds): A small, free add-on that puts recent site changes inside the admin panel, so the team can see what shipped and when without asking engineering. Cost is one dependency line and no infrastructure change beyond git already being present on the server. It's read-only, removes cleanly, and sits entirely off the critical path. Expected payoff is fewer "what changed?" interruptions and faster triage when something looks wrong — cheaper than commissioning a custom activity log. The trade-off is a brand-new, single-maintainer package, so we pilot it on one internal project rather than standardizing immediately.

For engineering (the honest version): composer require eminos/statamic-changelog, no migrations, no publish step — it reads git log and renders a CP nav widget with a per-user unseen count. Hard requirements: PHP 8.3, Statamic 6, git on the box. The real work is operational, not code: verify .git survives your build/deploy, confirm the process can execute git, and sanity-check the cost of a log read on your largest repo — cache it if it's non-trivial. Confirm role visibility before rollout, since commit author metadata becomes visible in the CP. Config covers path/author/message filtering and merge-commit exclusion, plus a toggle to hide Statamic Git addon auto-commits. Recommendation: pilot on staging or an internal project, pin the version, and keep a static changelog page as fallback if the package goes unmaintained.