Readonly On Update Laravel Package

Product Decisions This Supports

• Immutable business identifiers. SKUs, invoice numbers, account numbers, external/customer IDs, and URL slugs are set once at creation and must never drift. Locking them in the admin UI protects links, integrations, and downstream reporting from silent breakage.
• Financial and ledger integrity. Currency, price book, tax jurisdiction, and exchange-rate basis should reflect the state at record creation, not whatever an ops user picked up six months later.
• Compliance and audit snapshots. Consent capture, KYC attributes, contract terms, and effective-date fields often need to represent "as of creation." Making them read-only on update is a cheap control that supports audit narratives.
• Tenant and ownership boundaries. Preventing reassignment of tenant_id, owner_id, or organization_id in the back office reduces cross-tenant data-leak risk from simple admin error.
• Lifecycle guardrails. Fields that should freeze once a record enters a state (e.g., "published," "invoiced," "closed") can be locked at the form layer, reinforcing workflow rules without new services.
• Build vs. buy signal: this is a convenience wrapper, not a platform. The same behavior is achievable with Nova's readonly()/canSee() closures. Treat it as a reference implementation, not a strategic dependency.
• Use cases: SaaS internal admin panels, back-office ops tooling, support consoles, and any Nova-backed CRM or billing admin where non-technical staff edit records daily.

When to Consider This Package

Consider it when:

• You are already on Laravel Nova — this is a Nova tool and has no value outside it.
• A small, stable set of fields must be immutable after creation, and you want that expressed declaratively per field rather than scattered across resource fields() methods.
• You want a fast proof-of-concept or a pattern to copy, and your team is comfortable auditing a small package's source before merging.

Look elsewhere or build it in-house when:

• You need actual enforcement. This affects the Nova form only. It is not a security boundary — API clients, tinker, imports, and queued jobs can still mutate the field. Pair it with model observers, policies, or DB constraints, or the control is theater.
• You are not on Nova. Filament, custom Vue/Inertia, or API-first admin surfaces need an equivalent pattern, not this dependency.
• You need field history. Locking the field is not the same as auditing changes; if the requirement is "prove what it was and when," you need an activity log.
• You need role-based immutability. If "locked for support, editable for finance" is the requirement, closures or policies will be clearer than a blanket read-only rule.
• Dependency risk matters. Zero dependents and no visible adoption signal is a real maintenance flag. Nova itself is a paid, versioned product; an unmaintained extension can break on a Nova major release. Given the implementation is likely tens of lines, the safer play is to vendor the logic internally.

How to Pitch It (Stakeholders)

To executives (one line): A small Nova add-on that locks key fields once a record is created, so identifiers and financial attributes can't be accidentally changed by back-office staff — protecting integrations, reporting, and audit posture at near-zero cost.

Business value: Fewer data-integrity incidents, fewer support escalations from "someone edited the account number," and a defensible answer to auditors asking how immutable attributes are protected in the admin tool. Cost is measured in hours, not sprints.

To engineering: The behavior is a handful of Nova field closures; the package is a convenience, not a capability. Recommendation: evaluate the source (small, auditable), and unless it's already in use, reimplement the pattern internally in 1–2 hours to avoid an unmaintained dependency in a paid, version-sensitive framework. Either way, do not treat the UI lock as the control — add a model-level guard and a test that asserts the attribute can't change after creation.

Risk to flag: UI-only enforcement creates a false sense of safety. The pitch should always ship with the model-layer counterpart, or the decision is cosmetic.