Laravel Violation Logger Laravel Package

Product Decisions This Supports

• Prioritization, not just detection. The headline change — each violation now reports how many times it occurred (third-level JSON becomes a detail→count map instead of a list) — converts the package's output from a pass/fail gate into a triage input. A PM can now rank remediation work by frequency and blast radius rather than by whichever violation was noticed first.
• Roadmap for reporting surfaces. Counts make trend reporting viable: top-N violations per run, frequency deltas between runs, and "noisiest rule" leaderboards. This is the difference between a validation library and a data-quality dashboard.
• Build vs buy. The counting itself is trivial to build; the package's defensible value is the surrounding validation plus a normalized, machine-readable violation envelope. If your roadmap includes a quality dashboard, buy/keep this and spend engineering time on the aggregation layer above it.
• Use cases it unlocks. Batch import validation, content/data QA pipelines, API contract checks, and migration audits — anywhere the business question is "how bad is it and where do we fix first," not "is it valid."
• Contract risk as a product decision. 0.2.0 is a breaking change to the output format: any downstream consumer that iterates the third level as an array, or indexes it positionally, will break. Whether to adopt now, pin, or wait is a scheduling decision, not just a technical one.

When to Consider This Package

Adopt when:

• You need structured, machine-readable violation output that something downstream parses (dashboards, ticketing, CI gates).
• Frequency weighting is genuinely useful to your stakeholders — i.e., you expect repeated violations of the same rule, not one-off edge cases.
• You can pin to an exact version and own a contract test asserting the JSON shape (level 1 → level 2 → level 3 as detail→count map).
• Your team treats pre-1.0 minor bumps as potentially breaking — which is exactly what 0.2.0 is.

Look elsewhere or wait when:

• You only need a boolean pass/fail signal; the extra structure and its churn are pure overhead.
• You cannot audit every consumer of the JSON body — the list→map change is silent to anything doing positional access, and will surface as wrong results rather than errors.
• You require serialization stability across minor versions. A 0.x package changing its output shape in a minor release is within its rights but outside most integration contracts; if that's unacceptable, either pin hard or budget for a wrapper that normalizes the payload.
• You need vendor-backed support or a published schema/compatibility policy.

Required PM follow-through before rollout: inventory downstream consumers, add a snapshot test on the JSON structure, and request a schema version field (or explicit changelog signal) in the payload so future shape changes are detectable at runtime rather than discovered in a broken report.

How to Pitch It (Stakeholders)

To executives: This release upgrades our validation output from "something failed" to "here's what failed and how often." That means remediation gets sequenced by impact instead of by discovery order — the same engineering spend, aimed at the highest-frequency problems first. The tradeoff is a small, contained migration: the output format changed, so any report or dashboard reading it needs a short update. Cost is bounded and known; the gain is a prioritization capability we'd otherwise have to build ourselves.

To engineering: Minor version, but a breaking payload change — the third level of the violation JSON is now a map of detail→count rather than a list. Please audit all consumers for positional/iterable access on that level, update fixtures and snapshot tests, and pin the version until the audit closes. Recommend we wrap the payload behind our own normalization layer so the next shape change doesn't propagate through the codebase.