Registry Bridge Laravel Package

Product Decisions This Supports

• Extension marketplace / in-app discovery. This package is the bridge between a Fleetbase install and the Fleetbase extension registry: browsing engines, extensions, installed, purchased, and categories. It underpins any roadmap item around third-party extensibility, in-product upsell, or a paid add-on catalog.
• Build vs. buy for ecosystem infrastructure. If the roadmap includes a marketplace, this package is the "buy/adopt" answer for the catalog-and-entitlements layer. Building an equivalent means owning registry auth, entitlement checks, category taxonomy, and the console UI — weeks of work for a non-differentiating capability.
• Monetization surface. "Purchased" and "installed" views are the customer-facing entitlement record. Blank purchased cards (fixed in #40) is a revenue-adjacent defect: a paying customer who cannot see what they bought generates support load and refund risk, not just a cosmetic bug.
• Environment strategy (sandbox vs. live). #41 pins registry data to the live connection even in console test mode. That is the right call for correctness — sandbox databases have no registry tables — but it is a product decision worth recording: sandbox/demo environments now depend on live registry availability and read live catalog data. Anyone planning a fully isolated demo or air-gapped staging environment should know this before committing.
• Release-train planning. The package moves in lockstep with fleetbase/ember-ui (v0.4.6) and fleetbase/ember-core (v0.3.26). Console upgrades become a coordinated, multi-repo operation rather than a single composer update.

When to Consider This Package

Adopt when:

• You run Fleetbase and want extension discovery, install, and purchase flows surfaced inside the console rather than managed manually.
• You are comfortable with a pre-1.0 (v0.1.x) API — expect breaking changes and treat every minor bump as a review.
• You can version-lock the Fleetbase front-end stack (ember-ui, ember-core) alongside this package; drift here is the most likely source of runtime breakage.
• You need catalog/entitlement plumbing that is maintained upstream, not a bespoke integration.

Look elsewhere (or plan to fork) when:

• You are not on Fleetbase — this is ecosystem-specific, not a general-purpose Laravel commerce or package-registry library.
• You require a stable 1.0 API contract, semantic-versioning guarantees, or long-term support commitments.
• You need a self-hosted or private registry with strict environment isolation; the live-connection pinning in #41 assumes the hosted Fleetbase registry is reachable.
• You need hard isolation for sandbox/CI — tests and demo environments now reach the live registry, which is a network dependency in your pipeline.
• You need data-residency or offline operation for catalog data.

Upgrade risk for v0.1.11 specifically is low: no migrations, no artisan commands, two targeted bug fixes plus dependency bumps. The dependency pins are the only coordination cost.

How to Pitch It (Stakeholders)

To executives: This is a small, low-risk patch to the component that powers our extension marketplace inside Fleetbase. It fixes two customer-visible defects: registry pages that errored out in test/demo environments, and a "Purchased" page that rendered empty cards — meaning paying customers could not see the name, price, or date of extensions they had bought. Neither fix requires a database migration or downtime. The strategic read: this package is what makes a third-party extension marketplace possible without us building catalog, entitlement, and purchase-listing infrastructure ourselves. The trade-off is coupling — we track Fleetbase's release train, and the package is still pre-1.0, so we should budget review time for each bump rather than auto-updating.

To engineering: v0.1.11 is a two-fix patch. (#41) Registry models and category queries are now pinned to the live connection, resolving 500s on ~registry/v1/engines, registry-extensions, installed, purchased, and categories in console test mode where registry tables don't exist — note the consequence that test mode now depends on live registry reachability, so mock or skip these paths in CI. (#40) ExtensionCard was receiving @extension while reading @resource, which blanked every purchased card and all card descriptions; the purchased page now passes @resource. (#43) Bumps the console engine to fleetbase/ember-ui v0.4.6 and fleetbase/ember-core v0.3.26 — align these in the same deploy, and pin them in the lockfile to keep console upgrades reproducible. No migrations or commands, so rollback is a straight revert.