Artemis Laravel Package

Product Decisions This Supports

• A brand/design bet on internal admin surfaces — nothing more. Artemis is a presentation-only theme: Blade views, Tailwind tokens, and a service provider that registers a panel theme for the Lara Zeus family of Filament packages (bolt, thunder, rhea, sky, athena, hermes, cron). It ships zero backend behavior, data model, routes, integrations, or user-facing capability. The only decision it legitimately informs is whether a cohesive, narrative visual identity for back-office tooling is worth owning.
• Build vs. buy vs. fork — and the answer here is "fork or skip." With 2 stars, 0 dependents, an archived repository, a 0.155 quality score, and a final release in March 2025, this is not a viable "buy." Even the package's strong 7.09 opportunity score should be read as design-idea signal, not adoption signal — opportunity scores measure whitespace, not maintenance.
• Roadmap impact: effectively nil. It unlocks no revenue, no integration, no workflow, and no customer segment. Treat any proposal to adopt it as a design/ops line item, not a product initiative.
• Legitimate use cases worth funding. Internal back-office theming where the team already runs Lara Zeus; a design-exploration spike to pressure-test an artistic admin aesthetic; demo and prototype surfaces; or a reference implementation for building your own Tailwind token layer. It is explicitly not appropriate for customer-facing surfaces or as a general-purpose Laravel design system.
• Ecosystem-signal value. The package is a useful artifact for competitive/design intelligence: it shows what an opinionated, story-driven admin aesthetic looks like in the Filament + Zeus ecosystem. That's a research input, not a dependency decision.

When to Consider This Package

Consider it only when all of the following hold:

• Your admin panel already runs at least one Lara Zeus package, so the theme's view-namespace overrides actually land on something. Outside that stack the package delivers essentially nothing.
• You want a fast visual prototype of an artistic/narrative admin aesthetic and are treating the output as disposable or forkable.
• You explicitly accept that the codebase is archived and unsupported — no Filament v4 work, no Tailwind v4 work, no CVE response — and are prepared to vendor or fork it under MIT.
• The aesthetic is a genuine differentiator for your product and someone has signed up to own the fork indefinitely, with time budgeted into every Filament and Tailwind upgrade runbook.
• Engineering has validated concrete composer.json constraints against your PHP, Laravel, Filament, and Tailwind versions, and has inventoried exactly which Zeus view namespaces the theme overrides (the collision map is the single most valuable artifact you can produce).
• The surface is internal, behind auth, and one where a silent visual regression is tolerable and detectable.

Look elsewhere when:

• You need a maintained design system with community support, issue triage, accessibility coverage, or upgrade guarantees.
• You are mid-migration to Filament v4 or Tailwind v4 — adopting an archived theme during a major upgrade means straddling two sets of breaking changes with no upstream to absorb either.
• You are not running Lara Zeus. There is nothing here for a plain Filament or custom Blade panel.
• The surface is customer-facing, where an archived dependency is an upgrade and security liability.
• You want an internal Tailwind design system — building your own tokens and components is likely cheaper, safer, and faster than adopting a 2-star abandoned package.
• Any gate question (version fit, Tailwind v3 vs. v4, override precedence, aesthetic-as-requirement vs. nice-to-have, named on-call owner) comes back "unclear."

How to Pitch It (Stakeholders)

Executive summary: Artemis is an MIT-licensed, archived artistic theme for Lara Zeus admin packages. It has negligible adoption (2 stars, 0 dependents), no active maintenance, and no measurable impact on features, revenue, or customers. It is a design consideration, not a strategic build-vs-buy call. Recommendation: do not adopt as a production dependency. If the visual direction resonates, treat it as design inspiration or a forkable prototype — and if it's ever adopted, fund it as an owned internal theme, not as a dependency.

Product summary: Because this is purely a presentation layer, the decision collapses to two questions: do we want this look on our admin surfaces? and are we willing to own it forever? If yes, budget design time to adapt an opinionated visual language to brand and accessibility standards, plus recurring engineering time for every Filament and Tailwind upgrade — ownership transfers wholly to us on day one, with no upstream to lean on. Frame it as a one-to-two sprint side quest with a hard go/no-go, not a workstream to slot into a release. Default recommendation: keep it as a design reference and move on.

Engineering summary: Mechanically simple to install — composer require, publish views and assets, register the Filament panel theme, add vendor view paths to the Tailwind content globs. Fit is binary: high if the admin already runs the Zeus family, effectively zero otherwise. The real risks are governance and decay, not code: an archived theme cannot track Filament major-version changes to theme registration, asset publishing, or view namespaces, and will never get Tailwind v4 work. The defining failure mode is silent and visual — correct in npm run dev, half-styled in production when vendor Blade classes fall outside the Tailwind content glob — so a CI screenshot diff is the only cheap detection available. Security surface is low (mostly Blade and CSS) but Blade executes PHP, so any third-party view must be reviewed before it renders inside an authenticated panel. Licensing is clean; fork-and-own is legally unencumbered.

Recommended path if adopted: Fork, don't install. Publish views and CSS into an internally owned theme package, drop the Composer requirement, point at a local path repository, fold the color and typography tokens into the existing design system so you don't ship two competing palettes, and register the theme per panel so rollout and rollback are independent. Record ownership and the why in the service catalog — otherwise a future engineer will "clean up" the local package by reinstalling the archived original and quietly reintroduce abandoned upstream as the source of truth.