Artemis Laravel Package

Technical Evaluation

Architecture fit. Artemis is a presentation-only layer: Blade views, Tailwind tokens/CSS, and a service provider that registers a Filament panel theme. It ships no models, migrations, routes, jobs, or integrations. From a TPM standpoint that is the most important fact in the evaluation, because it bounds the blast radius to rendering and makes the adopt/skip decision a design decision rather than an architecture decision. Fit is binary — high if the admin surface already runs the Lara Zeus family (bolt, thunder, rhea, sky, athena, hermes, cron), effectively zero on plain Filament or custom Blade. Confirm the Zeus inventory before any engineering time is spent.

Integration feasibility. Mechanically trivial: composer require, publish config/views/assets, register the theme on the panel, add published view paths to the Tailwind content globs, rebuild assets. Estimate measured in hours for an engineer who has done a Filament theme registration before. The cost is not installation, it is adaptation — the aesthetic is opinionated, so brand and accessibility alignment is a design task paid up front.

Technical risk. The dominant risk is governance, not code. The repository is archived with a last release of v1.0.10 (2025-03-07), 2 stars, 0 dependents, and a 0.155 health score. That means no Filament v4 work, no Tailwind v4 work, no CVE response, and no upstream to absorb breaking changes in theme registration, asset publishing, or view namespaces. Breakage will be silent and visual — correct in npm run dev, half-styled in production — not loud and runtime. Secondary risks: the v1.0.10 removal of iconpark degrades icons without erroring on upgrades from <=1.0.9; Blade executes PHP inside an authenticated admin panel, so views require review before first render; and vendor:publish --force will clobber local edits.

Key questions to close before funding.

• Which Zeus packages and view namespaces does the theme override, and do those collide with views we have already customized? The collision inventory is the single most useful artifact we can produce about this package.
• Do our pinned PHP / Laravel / Filament / Tailwind majors satisfy the package's composer.json constraints — and are we mid-migration to Filament v4 or Tailwind v4? If so, defer outright; straddling two sets of breaking changes with no upstream is not a funded risk.
• Is the aesthetic a requirement with an executive sponsor, or a nice-to-have?
• Who owns the fork indefinitely, named in the service catalog?
• Is this surface internal back-office only, or does it touch anything customer-facing? The latter should be an automatic no.

Integration Approach

Stack fit. Treat Artemis as a design reference or MIT fork, not a dependency. The defensible paths are skip, or vendor/fork into an internally owned theme package. "Buy" is not available — an archived repository with zero dependents is not a supplier.

Migration path. If adopted: copy the package into the monorepo under our vendor namespace, point at it via a Composer path repository with symlink: true, and drop the upstream lara-zeus/artemis requirement. Record ownership and the rationale in the service catalog — otherwise a future engineer will "clean up" the local package by reinstalling the archived original and quietly reinstate abandoned upstream as the source of truth. Flatten the theme's CSS custom properties and typography scale into our existing design tokens in the same PR; two competing palettes is a maintenance debt we should refuse at review.

Compatibility. Pin versions explicitly rather than using a caret range — a floating constraint signals to the next reader that upgrades are coming, and they are not. Pin the Filament and Tailwind majors the fork was validated against. If the team is on Tailwind v3, note the glob configuration differs from v4. Audit the built CSS for a known theme class before trusting any build; classes in unscanned vendor Blade files simply do not exist.

Sequencing. Run it as a time-boxed spike with a hard go/no-go, not a workstream slotted into a release:

1. Inventory the Zeus packages in use and the view namespaces the theme overrides; diff against our existing customizations.
2. Confirm version constraints and confirm we are not mid-migration to Filament v4 or Tailwind v4.
3. Fork into a local path repository; publish views and assets; commit published output to VCS.
4. Theme a single throwaway or secondary panel first — one list page with a form and a table. Register the theme there only, never on a customer-facing panel.
5. Run npm run build (not just dev) and verify the theme entry lands in the Vite manifest.
6. Screenshot-diff against current rendering. Go/no-go at the end of the box; if not funded as a differentiator, demote to design reference and move on.

Operational Impact

Maintenance. Ownership transfers to us on day one and is permanent. The recurring cost is a manual theme-compatibility task sized into every Filament and Tailwind major upgrade — that, not installation, is the true price of adoption. Budget design time once, up front, to align the opinionated visual language to brand and accessibility standards, plus ongoing engineering time per upgrade cycle. Put a visual regression check (Playwright or Dusk screenshot diff on the themed list/form/table pages) into CI; breakage here is silent, so a screenshot diff is the only cheap detection available.

Support. There is no upstream support channel and there will not be one. Internal support means a named owner, a documented runbook, and a known-issues list. Grep published views for the iconpark icon set before any version bump; upgrade the fork deliberately, never via --force. Review any third-party Blade view before it renders inside an authenticated panel — low risk for a mostly-CSS package, but "mostly CSS" is not a guarantee.

Scaling. Negligible runtime scaling concern — this is CSS and view rendering. The scaling constraint is organizational: one theme, one owner, one token source of truth. If multiple Zeus panels exist, register the theme per panel so rollout and rollback are independent, and never run Artemis alongside another panel theme on the same panel — the CSS specificity conflicts are invisible in code review and obvious to users.

Failure modes and detection.

• Unstyled or half-styled panel in production only — Tailwind content glob missing vendor view paths. Check theme registration → Vite manifest → Tailwind glob → view:clear, in that order.
• Silent icon degradation — the iconpark removal in v1.0.10; no error, just missing icons.
• Lost customizations — vendor:publish --force. Mitigation: commit published views; treat --force as a reviewed operation.
• Config changes that appear to do nothing — config:cache still active; always re-run php artisan config:cache after changes.
• Deploy serves stale CSS against new markup — wire asset cache-busting to the Vite manifest.
• Breakage surfacing during a Filament/Tailwind major upgrade with no upstream fix — the strategic failure mode; the runbook must assume we absorb it.

Ramp-up. Low for engineers familiar with Filament panel providers and Tailwind content configuration; the friction is diagnosis, not learning. Ramp-up for the organization is the harder part — establishing the fork as a first-class owned package with a catalog entry, an owner, a runbook, and a CI visual check. Without those four artifacts, this becomes orphaned infrastructure within two quarters.

Recommendation for the portfolio. Do not adopt as a production dependency. Track it as a design asset. If an executive sponsor funds the aesthetic as a differentiator on internal admin surfaces, fork-and-own with the sequencing above and a hard go/no-go gate; otherwise cite it as inspiration, close the ticket, and move on.