Log Laravel Package

Product Decisions This Supports

• API error contract. Stable rule IDs let you commit to machine-readable validation error codes (required, unique, etc.) in your API responses instead of relying on human-readable strings that change with copy edits and translations. This is a contract decision, not an implementation detail — it determines whether third parties can build against your error format.
• Multi-client strategy. If web, mobile, and partner integrations all consume the same API, stable IDs give every client one key to map to inline field messaging, localized copy, or support documentation.
• Localization roadmap. IDs decouple rule identity from presentation, so message copy can be rewritten, translated, or A/B tested without breaking consumers. This unblocks i18n work that would otherwise be blocked on error-format churn.
• Validation telemetry as a product input. Per-rule identifiers make it cheap to count which rules fail most often in production. That data feeds UX investment decisions — if unique or regex failures dominate, the form is the problem, not the user.
• Documentation and support tooling. Stable IDs enable auto-generated error catalogs for public docs and support runbooks, reducing per-incident triage.
• Build vs. buy. If you are hand-rolling error-code mapping across services today, this is a candidate to standardize on rather than maintain internally. If you already have a bespoke error vocabulary, that calculus flips.
• Roadmap risk signal. Rule IDs were added in a patch release (v1.0.2) alongside a README introduction block. That tells you the API surface is still settling and documentation was thin until now — plan a spike, not a platform commitment.

When to Consider This Package

Consider it when:

• You expose a public or partner-facing API where validation failures are consumed programmatically.
• You have more than one client that must handle validation errors consistently.
• You need a code/message split for localization or for presentation-layer flexibility.
• You want validation failure analytics without building an instrumentation layer yourself.
• You are on Laravel and value a native, low-friction fit over a framework-agnostic validator.

Look elsewhere or defer when:

• Validation errors are only ever rendered as strings in server-side forms — stable IDs add indirection with no consumer.
• You need a written long-term support or backward-compatibility guarantee. At v1.0.2 the IDs are new; confirm they are documented and covered by an explicit stability policy before betting a public contract on them.
• You already own an error-code standard across services; a second vocabulary is net-negative.
• The need is small enough to satisfy with a local enum map, avoiding the dependency entirely.
• You have not yet assessed the package's remaining surface — the release notes cover only IDs and documentation, so fit for your full rule set is unverified.

Due diligence before adoption: read the new README introduction block, verify the IDs are enumerated in documentation, check whether they are treated as public API, and confirm behavior on the Laravel versions you run.

How to Pitch It (Stakeholders)

For executives. This package gives our API a stable, machine-readable way to report validation failures. Today, client teams re-map our error strings by hand, which is brittle, slows integrations, and generates support load whenever we change wording. Stable rule IDs let us publish an error contract once and keep it, translate messages without breaking clients, and see which validation rules fail most so we can fix the forms causing them. It is Laravel-native and low-cost. Recommendation: fund a short spike on one public endpoint before we commit broadly.

For engineering. The v1.0.2 addition of stable rule IDs is the actual unlock: validation errors become identifiers rather than prose, so we can version them, localize them, log them, and document them. Proposal is a timeboxed spike — pick one public endpoint, emit IDs in the error envelope, and measure the client-side mapping effort saved. Two caveats to resolve in the spike: v1.0.2 is early, so treat the IDs as stable-in-practice until there is a written compatibility policy; and the README only gained an introduction block in this release, so documentation maturity should be verified rather than assumed.