Identity Core Livewire Laravel Package

Product Decisions This Supports

• Build vs. buy for authentication UI. If the product already uses liberusoftware/module-identity-core, this package supplies the Livewire presentation layer — login, registration, verification, password reset, account screens — that would otherwise be hand-built. The decision it informs is "do we spend two to four weeks of design/engineering on auth surfaces, or adopt the adapter?"
• Roadmap sequencing. Auth UI is a hard dependency for nearly every downstream feature (onboarding, billing-gated areas, team invites). This package compresses that critical path in the Liberu ecosystem, letting you sequence revenue features earlier.
• Use-case fit. Best suited to internal admin panels, B2B dashboards, MVP SaaS products, and white-label deployments already standardized on Liberu modules. Poor fit for consumer-facing products with bespoke brand/UX requirements.
• Architectural boundary setting. The package's existence signals a deliberate split between identity domain (core) and identity presentation (this adapter). That split is a useful precedent when deciding where to invest in custom UX: customization belongs at the presentation layer, not by forking the core.
• What it does not decide. It is not an input into "should we use Livewire?" or "should we use the Liberu identity core?" — it is a downstream consequence of both. Adopting it as a reason to pick either stack would be backwards.
• Vendor/concentration risk tracking. With 0 stars, 0 dependents, and a single publisher, this belongs on the dependency-risk register rather than the strategic-bet list.

When to Consider This Package

Consider adopting when:

• You are already committed to liberusoftware/module-identity-core. In isolation this package has essentially no value — it is an adapter, not a standalone auth solution.
• Your stack is Laravel + Livewire and will stay that way through the relevant release horizon.
• You want UI consistency across several Liberu modules and would rather inherit one set of screens than maintain parallel auth views.
• You are comfortable with a single-maintainer, near-zero-adoption dependency and can pin/fork it if needed.
• The licensing question can be resolved favorably and quickly (see below).

Look elsewhere when:

• License is unresolved. NOASSERTION is a procurement and legal blocker, not a detail. Until the actual terms are confirmed, this cannot enter a commercial build without sign-off. For many organizations this alone is disqualifying.
• You need first-party support and community depth. Laravel Breeze, Jetstream, and Fortify are the default answers for Laravel auth surfaces; they have broad usage, documentation, and a hiring pool that knows them.
• Your front end is not Livewire (Inertia/React/Vue/API-first). The adapter is inert in those architectures.
• You need enterprise identity — SSO, SAML/OIDC, SCIM, audit trails, policy engines. A presentation adapter is the wrong layer; you'd be evaluating an IdP or a dedicated auth platform.
• You have bespoke UX or accessibility obligations. Auth screens are high-visibility; retrofitting a vendor's Blade/Livewire views to a design system can cost more than building fresh.
• Support-risk tolerance is low. Zero dependents means no community fallback, no third-party bug reports, and bus factor of one.

Due diligence flag: the recorded last release date is in the future (2026-10-26). Treat this as unreliable metadata and verify actual tags, changelog, and CI status before any commitment.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a UI kit for login and account screens, built to plug into an identity backend we would already be running. It is cheap to trial and could save a few weeks of front-end work on early auth flows. It is not a strategic dependency: it has no external users, one maintainer, and unclear licensing, so we should treat it as internal scaffolding — pilot it in a non-critical module, keep a fork path open, and avoid building anything irreversible on top of it.

For engineering (summary):

• What it is: a thin Livewire presentation layer over module-identity-core. It owns views and component behavior, not identity data or policy.
• Coupling: shallow. The Blade/Livewire views can be published, forked, and restyled without touching the core's domain logic — that is the main reason it is low-risk to try.
• What to verify first: (1) actual license terms — NOASSERTION will block merge in most orgs; (2) real release tags versus the anomalous future-dated release metadata; (3) compatibility matrix against our Laravel and Livewire versions; (4) whether tests exist and run.
• Integration plan: pin to an exact tag, vendor the source or mirror the repo internally, and isolate it behind our own auth routes so we can swap in Breeze/Fortify or a first-party implementation without a rewrite.
• Recommendation: approve a time-boxed pilot in an internal or low-traffic surface. Do not adopt for customer-facing authentication until licensing is confirmed and a fork/maintenance owner is named internally.