Laravel Mutable Content Laravel Package

Product Decisions This Supports

• Audit trail & compliance features: Human-readable change descriptions are the difference between a usable audit log and a database dump. This release makes money fields render as 10.50 $ rather than raw JSON, which directly improves admin-facing history views, support tooling, and any "who changed what" surface.
• Customer- and support-facing activity feeds: If change history is exposed to users (order timelines, account change logs, dispute resolution), formatted monetary amounts reduce ambiguity and support tickets. This is a UX/comprehension fix, not just an internal cosmetic one.
• Build vs. buy: The package continues to absorb the tedious part of change tracking — diffing, describing, and formatting field-level changes — letting the team avoid maintaining a bespoke diff/rendering layer for Eloquent models.
• Roadmap input: Signals the package is in a stabilization/polish phase (patch release, correctness of presentation). Reasonable to depend on for history features now; not the moment to expect new architectural capability.
• Scope guardrail for PMs: Because descriptions are now formatted for humans, treat describe() / describeChanges() output as presentation. Any product requirement for machine-readable export, reconciliation, or downstream ingestion must be sourced from raw model data/casts, not from these strings.

When to Consider This Package

Consider it when:

• You are on Laravel/Eloquent and need field-level change history with typed rendering (money, dates, enums, booleans) rather than raw before/after blobs.
• The primary consumer is a human: admins, support agents, or end users reading an activity feed.
• You want change descriptions delivered consistently across models without hand-rolling per-model formatters.
• You can tolerate a young API surface (0.x) and pin versions deliberately.

Look elsewhere when:

• You need machine-consumable diffs as a system of record — formatted strings are lossy for money (locale/scale assumptions, no currency code in the rendered output). Use raw casts, event sourcing, or a dedicated audit store.
• You require strict regulatory guarantees: immutability, tamper-evidence, retention, or certifications are not established by this release.
• You have high write volume / hot-path auditing where description generation cost matters.
• Your history needs span multiple services or non-Eloquent data sources.
• Currency handling is multi-currency or locale-sensitive at scale — verify how money fields carry currency and precision before relying on the formatted output.

How to Pitch It (Stakeholders)

For executives: This is a small, low-risk maintenance release that improves how money values appear in our change-history and audit views — 10.50 $ instead of unreadable JSON. It reduces support friction and makes compliance/history screens presentable, with no migration, no breaking changes, and no new infrastructure. It reinforces the build-vs-buy case for keeping history rendering off our own roadmap.

For engineering: Patch-level fix to LogHelper::describeChanges() and Entry::describe() so money-typed fields render as formatted amounts with the field's declared decimals rather than JSON. No API changes expected. Action: bump the dependency, confirm existing tests assert on structured/raw values rather than formatted strings (this changes string output and may break brittle assertions), and verify multi-currency/precision assumptions if you render these descriptions externally. Keep machine-facing consumers on raw attributes, not the description text.