Currency Context Filament Laravel Package

Product Decisions This Supports

• Build vs. buy for multi-currency admin surfaces. This is a presentation adapter — Filament resources/pages that expose an existing module-currency-context domain layer (currencies, base-currency selection, exchange rates, per-tenant/store currency context). It answers "do we need to budget engineering time for a currency admin UI?" — and the honest answer is that a Filament CRUD layer over 3–4 models is roughly 1–3 engineer-days. It is not a multi-currency engine; it does not decide rounding, FX sourcing, or price conversion semantics for you.
• Scoping the actual feature, not the package. Use this repo as a spec sketch for what a currency-context admin needs (list/create/edit currency context, set base currency, attach rates). That's useful for writing acceptance criteria and estimating a sprint even if you never install it.
• Roadmap sequencing for internationalization. Where multi-currency sits relative to localization, tax, and pricing work. If your roadmap has multi-currency in the next two quarters, this package is a candidate dependency to evaluate now — otherwise it's a distraction.
• Ecosystem/architecture commitment. Adopting it implies adopting Liberu's modular stack conventions (module-* naming, Filament version alignment, their service-provider and config patterns). That's an architecture decision, not a feature decision — route it through the same review as choosing a framework.
• Vendor and maintenance risk tracking. 0 stars, 0 dependents, and a NOASSERTION license are three separate risk items to log against your dependency register.

When to Consider This Package

Consider it when all of the following hold:

• You are already running the Liberu modular ecosystem (or are evaluating it wholesale), so the module-currency-context domain package and Filament version are already in your stack.
• Your admin panel is Filament-based and you want consistency with other Liberu *-filament adapters rather than a bespoke UI.
• Your multi-currency needs are modest — select a base currency, manage a currency list, maintain rates — not a full FX treasury/pricing-policy system.
• Legal has cleared the NOASSERTION license, or the package is trivially replaceable if the license turns out to be incompatible.
• You have a fork-and-own plan: someone on the team is willing to pin a commit and carry patches.

Look elsewhere (or build) when:

• You are not on the Liberu stack. A standalone Filament resource is cheaper than adopting a whole module ecosystem for one admin screen.
• You need the domain depth. Exchange-rate providers, historical rate snapshots, rounding/margin rules, price-list-per-currency, and audit trails are domain problems this adapter does not solve.
• License clarity is a hard requirement. NOASSERTION is a blocker for many orgs until resolved in writing.
• You require maintenance guarantees. Zero stars, zero dependents, no visible community, and a release date that appears future-dated relative to today — treat it as effectively unmaintained third-party code you would be the sole steward of.
• You need multi-tenant currency context with strict isolation semantics — verify that behavior yourself; do not assume it from the description.

How to Pitch It (Stakeholders)

To executives: There is a small, narrowly scoped open-source component that provides the admin screens for managing currencies and exchange rates. It is not a multi-currency product — it is UI glue for one piece of one. It carries three flags: no adoption (0 stars, 0 dependents), an unclear license, and a single-vendor origin. Recommendation: do not treat this as a build-vs-buy decision worth executive time. The real decision is whether we commit to the Liberu modular stack; this package is a downstream consequence of that.

To engineering: This is a Filament presentation adapter for module-currency-context. Value is consistency with Liberu's other adapter packages and saved UI work — realistically one to three days of effort. Costs are ecosystem lock-in, a NOASSERTION license requiring legal review, no dependents or community to inherit fixes from, and a release timestamp that warrants verification. Proposal: do not add it as a dependency. Instead, use its surface area as a requirements sketch, and either (a) adopt it only if we standardize on Liberu elsewhere, with a pinned commit and a named owner, or (b) build the equivalent resource in-house on our own currency domain model, where the actual complexity lives.