Jetstream Bridge Laravel Package

Product Decisions This Supports

• Auth stack standardization. The package is a thin adapter layer that lets a Laravel app keep the Fortify/Jetstream action contracts (registration, password reset, profile updates, 2FA, team membership) while delegating the actual identity logic to Liberu's identity capabilities. The decision it unlocks: do we keep the first-party Jetstream UX and swap the backend, or do we fork/rewrite auth? This package exists to make the first option cheap.
• Identity consolidation across a product suite. If we ship more than one Laravel product (CMS, accounting, or internal apps), this is the seam that lets a single identity implementation serve all of them instead of every app growing its own users table semantics. That is a roadmap decision about platform investment, not a feature decision.
• Build vs. buy vs. adopt. The realistic comparison is not "this vs. nothing" but "this vs. writing our own Fortify action adapters" (a few days of work, plus ongoing drift as Fortify evolves) and "this vs. buying an identity vendor" (Auth0/WorkOS/Cognito — real money, real migration). This package sits in the cheap-but-unproven corner of that matrix.
• De-risking auth roadmap items. 2FA, email verification, and profile management are commonly punted quarter after quarter because they're tedious rather than hard. An adapter that inherits Fortify's implementations moves these from "build" to "configure" on the roadmap.
• Ecosystem bet sizing. Adopting it is implicitly a bet on the Liberu module ecosystem. That's a portfolio-level call worth making explicitly rather than by default.
• Not supported: pricing, packaging, or go-to-market decisions. This is internal plumbing.

When to Consider This Package

Consider it when:

• We are already committed to Laravel + Fortify and/or Jetstream and have no intention of replacing that UI.
• We are already running, or actively planning to run, more than one Liberu module or app, so a shared identity layer has somewhere to pay off.
• We want Liberu identity semantics (its user model, its policies) without abandoning the standard Fortify::loginView / action-binding conventions.
• We treat it as a thin, vendored, MIT-licensed adapter — something an engineer can read end-to-end in an hour and patch locally if the maintainer disappears.
• Our timeline tolerates pre-1.0 churn on an auth boundary, i.e. we have integration tests around login, reset, and 2FA.

Look elsewhere when:

• No existing Liberu commitment. If we aren't in that ecosystem, this adds a dependency and a mental model for no benefit. Plain Fortify, Breeze, or Jetstream alone is the right answer.
• Provenance matters. Zero stars, zero dependents, and a single-vendor maintenance path is the whole risk story. If the auth layer needs an SLA, a CVE response process, or a support contract, this is not it — that's WorkOS/Auth0/Okta territory.
• We need capabilities beyond the adapter's scope. Enterprise SSO/SAML, SCIM provisioning, social login breadth, and audit logging are not what an action adapter provides.
• We don't use Jetstream's opinions. If the product has a bespoke auth UX, the adapter's value evaporates — you'd be paying for compatibility with a framework you aren't using.
• Team familiarity is low. Unfamiliar abstractions on the auth path are the most expensive kind of unfamiliarity.

Treat the "last release 2026-10-27" metadata as a flag to verify rather than a fact to plan around.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a small, free, MIT-licensed adapter that lets our Laravel applications reuse one identity implementation instead of each app rebuilding login, password reset, and two-factor auth. The upside is duplication removed and a shared identity foundation across products, at essentially zero licence cost and a few days of integration. The honest downside is maturity: it's a young, single-maintainer, zero-adoption component sitting directly on our authentication path. The mitigating factor is that it's thin and permissively licensed — if it stalls, we own the fallback because it's a few hundred lines wrapping interfaces we already control. Recommendation: adopt only inside an existing Liberu commitment, behind integration tests, with an explicit exit plan. Do not adopt it as the foundation of a new product line.

For engineering (the ask): Implement against the Fortify/Jetstream action contracts and keep the bridge at the boundary — no Liberu identity types leaking into domain code. That preserves a clean fallback to upstream Fortify actions and makes replacing the adapter a contained change. Budget for: reading the adapter source before merge, integration tests covering registration/reset/2FA/team flows, and a note in the ADR recording why we took the dependency and what triggers removal. If the maintenance signal doesn't improve by the next major review, plan to absorb the adapters in-house — that cost is measured in days, not quarters.