Tardis Laravel Package

Technical Evaluation

Architecture fit

• Tardis is an opinionated, full-stack admin panel for Laravel 13 + Livewire 4 + DaisyUI 5, delivering BREAD (Browse/Read/Edit/Add/Delete) resources defined in JSON rather than hand-built Filament/Nova-style resources. It is a strong fit only if the host application is already committed to Laravel 13 and Livewire 4.
• It assumes it owns the /admin surface and a substantial slice of the auth/authorization model (access admin gate, super-admin role, permission tree, plugin-provided routes/assets/settings). This is a platform decision, not a package decision.
• Translatable content with locale tabs plus data-driven themes, menu builder, widget dashboard and media library make it closer to a lightweight CMS/admin framework than a CRUD helper. Expect coupling to its conventions (JSON resource definitions, plugin lifecycle, theme model).
• The plugin system (assets, routes, settings screens) is the main extensibility lever; it is also the least stable surface at 0.1.0.

Integration feasibility

• Installation is from a Git VCS repository, not Packagist. This requires Composer VCS repository configuration, pinned refs/tags and a private-fork/mirror strategy for CI and production builds. Treat dependency management as a project workstream, not a one-liner.
• tardis:install performs privileged bootstrap work: creates the first administrator, assigns super-admin, and prints a generated password to console output. This needs to be captured, rotated immediately and never allowed to land in CI logs.
• tardis:doctor is a useful pre-flight/health check; wire it into CI and deploy smoke tests from day one.
• Creating a BREAD invalidates route caching — php artisan route:cache must be re-run. This means resource definition changes are a deploy-time concern, not a runtime admin action, unless the deploy pipeline is adjusted.
• Strict translation validation (every locale required for required translatable fields) will surprise content editors; the tardis.translation.validation = active relaxation is the escape hatch and should be decided explicitly per project.

Technical risk

• Pre-release with an explicit "API can still change before 1.0" warning. JSON resource schema, plugin contracts, theme format and settings screens should all be assumed unstable. Any custom plugin or theme work is throwaway-risk until 1.0.
• Bleeding-edge version floor (Laravel 13, Livewire 4, PHP 8.3) narrows the hosting/platform matrix and increases the chance of upstream ecosystem gaps (other packages, hosting images, static analysis tooling).
• Security-sensitive defaults: a super-admin bypass role, an allow-listed command runner (off by default — keep it off and gate any enablement behind an explicit ADR), a log viewer with potential PII exposure, and a media library handling uploads. Each needs review before production exposure.
• No drag-and-drop menu/dashboard ordering and no nested menus are functional limits that will hit navigation-heavy back offices early.
• Route-cache coupling is an operational footgun that can silently produce 404s after a BREAD change if the deploy step is missed.
• Single-vendor, low-maturity package with a small release history: bus factor, security response time and long-term maintenance are unknown.

Key questions

• Is the platform already on Laravel 13 / Livewire 4, or is this package pulling the whole stack forward?
• Do we accept /admin being owned by Tardis, including its auth, roles and plugin routing?
• What is the upgrade contract pre-1.0 — tagged releases, changelog discipline, UPGRADE.md completeness, deprecation notice period?
• How do BREAD JSON definitions get version-controlled, reviewed and promoted across environments?
• Which plugin surfaces do we actually need in the first 90 days, and can we defer all custom plugin work until 1.0?
• Who owns the security review of the command runner, log viewer, media uploads and super-admin bootstrap?
• What is the fallback if the package stalls — is the JSON resource layer thin enough to reimplement on Filament/Nova?

Integration Approach

Stack fit

• Hard requirements: PHP 8.3+, Laravel 13+, Livewire 4, DaisyUI 5. Confirm the existing front-end build (Vite/Tailwind/DaisyUI version) aligns; DaisyUI 5 is a major-version constraint on the host's CSS pipeline.
• Best fit: internal back-office/ops tooling on a greenfield or already-modern Laravel app, where admin UX speed matters more than front-end bespoke design.
• Poor fit: customer-facing surfaces, apps pinned to Laravel 11/12 or Livewire 3, or teams standardising on Filament/Nova with existing resource investment.

Migration path

1. Spike in an isolated branch/app — install via VCS, run tardis:install with a non-personal mailbox, run tardis:doctor, build two representative BREAD resources (one translatable, one soft-deleted with bulk actions).
2. Security and bootstrap review — verify access admin gating on every route, confirm command runner is disabled, review log viewer and media upload handling, and rotate the generated super-admin password.
3. Definition authoring workflow — decide where BREAD JSON lives (repo path, review process, seeding into environments), and add the route:cache step to the deploy pipeline.
4. Pilot one real back-office module behind auth, with an explicit rollback path.
5. Only then evaluate plugins/themes, and only after 1.0 or a documented API-stability commitment.

Compatibility

• Verify Livewire 4 compatibility with any existing Livewire components in the app — Livewire 3→4 migration may already be in flight and should not be conflated with Tardis adoption.
• Check interaction with existing auth scaffolding (Breeze/Jetstream/Fortify), existing gates/policies and any SSO. Tardis introduces its own role and permission model; running two authorization systems in parallel is a known source of drift.
• Confirm queue/cache/session drivers and file storage for media library (local vs S3) before pilot.
• Assess Tailwind/DaisyUI coexistence with the host's design system; theme editor output must not fight application CSS.

Sequencing

• Phase 0 (1–2 weeks): spike, doctor run, security review, go/no-go on the Laravel 13/Livewire 4 constraint.
• Phase 1: one pilot resource, deploy pipeline updated with route:cache, BREAD JSON review process agreed.
• Phase 2: expand to core back-office modules; decide translation-validation policy; finalise role mapping to business roles.
• Phase 3 (post-1.0): plugins, custom themes, media library rollout, menu/dashboard build-out.
• Gate between every phase: tardis:doctor clean, no API breakage since last pinned tag, UPGRADE.md reviewed on each bump.

Operational Impact

Maintenance

• Pin to an exact tag/commit; do not float ^0.1 in production even post-pilot. Pre-1.0 minor bumps may break JSON schemas or plugin contracts.
• Budget recurring effort for upgrade reviews against UPGRADE.md and RELEASE_NOTES.md, plus re-running tardis:doctor and the route cache step.
• Track the package's release cadence and issue responsiveness; a stalled pre-1.0 package is an escalating liability the longer it sits in a critical path.

Support

• No Packagist distribution means no standard Composer support path, no version constraint guarantees from the maintainer and a manual mirror/VCS credential story for CI.
• Internal support model needed: a named owner for the admin panel, an internal runbook covering install, doctor failures, route-cache refreshes and super-admin recovery.
• Command runner and log viewer are privileged support surfaces — restrict to break-glass roles, log all invocations and keep the runner disabled by default in every environment.
• Generated super-admin passwords must be treated as one-time secrets: captured securely, rotated on first login, excluded from logs and tickets.

Scaling

• Livewire-driven admin scales with normal Laravel/PHP-FPM and queue capacity; the main scaling concern is data volume on list views. Validate search/sort/filter performance on the largest expected tables and confirm pagination/indexing before wide rollout.
• Media library storage and image processing will drive infrastructure cost at scale — plan storage driver, CDN and thumbnail strategy early.
• Multi-locale content multiplies editing effort and validation friction; strict translation validation can bottleneck content throughput, so the active relaxation should be a deliberate, documented choice.
• Menu/dashboard ordering via up/down buttons and no nested menus will degrade admin usability as navigation grows; plan for this limitation in information architecture.

Failure modes

• Route cache staleness — BREAD changes not followed by route:cache produce missing routes/404s. Mitigate in deploy pipeline.
• Authorization drift — dual role systems (app + Tardis super-admin) leading to privilege creep. Mitigate with a role-mapping matrix and periodic access review.
• Pre-1.0 breakage — schema or plugin changes breaking custom resources after an upgrade. Mitigate with pinned versions, staging upgrade rehearsals and a re-implementation fallback for custom plugins.
• Bootstrap leakage — generated admin password exposed in CI logs or shell history. Mitigate with secret capture and forced rotation.
• Translation validation lockout — editors unable to save records because a required field is missing in an unused locale. Mitigate by deciding the validation mode per content type up front.
• Command runner / log viewer exposure — privilege escalation or PII leakage if enabled without controls. Mitigate by leaving disabled and gating behind explicit approval.

Ramp-up

• Developers: low-to-moderate. JSON BREAD definitions are quick to learn; the real cost is internalising conventions, plugin lifecycle and the deploy-time route-cache step. Estimate 1–2 sprints to productive on a pilot.
• Content/ops users: low for basic CRUD; moderate for translatable content and the strict-validation behaviour. Provide a short guide covering locale tabs and the required-in-every-locale rule.
• Ops/DevOps: moderate. New install path (VCS), new artisan commands, new route-cache step, media storage and privileged surfaces to secure.
• Overall recommendation: proceed as a time-boxed pilot only, on a non-critical back-office module, with pinned versions and a documented exit path; do not commit to Tardis as the strategic admin platform until 1.0 and a stable API/plugin contract are published.