Filament Demo Mode Laravel Package

Technical Evaluation

What this release is: v0.1.0 is the initial public cut of a Laravel package that provisions a persistent, SQLite-backed sandbox environment with model selection, role switching, and Filament admin integration. It is a first release, so there is no prior assessment to diff against — this document establishes the baseline.

Architecture fit

• Fits the standard Laravel package contract: service provider auto-discovery, publishable config and views, Artisan install/doctor commands. Low conceptual overhead for any team already shipping Laravel packages.
• The "one installation-wide sandbox" design is a deliberate singleton. That is coherent for single-tenant internal tooling but is a hard architectural constraint for multi-tenant SaaS, per-team staging, or any product where two users need isolated sandboxes concurrently. Treat this as a design decision to accept or reject up front, not a configuration detail.
• persistent SQLite + indefinite restore is an opinionated durability model. It trades operational simplicity (a file, no external service) for constraints on horizontal scale and on where the filesystem lives.

Integration feasibility

• Strong pull for Filament 4 shops: registration plus provider auto-discovery means near-zero wiring for the admin surface.
• Spatie integration is described as "default" but unnamed. Whether this is laravel-permission, activitylog, or medialibrary materially changes the RBAC and audit story — this is a blocking clarification, not a footnote.
• "Callbacks and custom application adapters" is the right extensibility shape; it suggests the maintainers expect the package to be embedded rather than used as-is. Budget integration work against the adapter seam, not against the happy path.

Technical risk (v0.1.0 baseline)

Key questions to put to the maintainers

1. What precisely does "production-context isolation" enforce, and what test or doctor check proves it at runtime?
2. Which Spatie package is integrated by default, and is the coupling optional?
3. Where does the SQLite file live, and what happens on read-only or ephemeral filesystems (containers, PaaS, Lambda)?
4. What is the concurrency model — single writer, WAL, per-request locking? What happens under two simultaneous sandbox writes?
5. Is there an authorization contract for the role picker, or does it rely on Filament panel access alone?
6. What is the support policy, release cadence, and maintainer count? Is there a security disclosure channel?
7. Minimum PHP version, and is Laravel 11 support on the roadmap?
8. Does "indefinite restore" have a documented purge/expiry mechanism?

Verdict: technically credible and well-scoped for a first release, but the risk profile is dominated by two unverified claims — context isolation and data retention — not by code quality. Not approvable for any path that touches production data until both are demonstrated.

Integration Approach

Stack fit

• Good fit: Laravel 12, Filament 4, PHP 8.3+, internal admin/back-office tooling, single-tenant deployment, teams already comfortable publishing and version-controlling package config.
• Poor fit: multi-tenant SaaS requiring per-customer sandboxes, Laravel 10/11 estates, Filament 3 panels, serverless or read-only-filesystem deployments, or any environment with strict data-residency rules.

Migration path

• No migration in the conventional sense — there is no incumbent package to displace and no prior assessment to reconcile. This is a greenfield adoption decision.
• The real migration cost is the platform uplift: adopting this forces Laravel 12 and Filament 4. Scope that upgrade separately and do not let it hide inside the package rollout.
• Treat the published config and views as fork-on-publish. Once customized, upstream upgrades require manual diffing. Record every deviation from the published defaults in a tracked file from day one.

Compatibility and versioning

• Pin the exact version (0.1.0), not a caret range. Expect breakage on 0.x minors and budget a review cycle per bump.
• Validate the full matrix explicitly: PHP version, Laravel 12 minor, Filament 4 minor, database driver for the host app, and the Spatie package version. The CI claim covers Laravel 12 / Filament 4 only — it says nothing about your host app's other dependencies.

Sequencing

1. Spike (1 week, staging only). Install via the doctor command, wire the Filament panel, confirm auto-discovery behaves in your app skeleton. Produce a short written findings note.
2. Isolation proof. Attempt to force production-context access from the sandbox path — misconfigured env, missing config key, direct route hit. Document the result. This is the go/no-go gate.
3. Authorization review. Walk the role picker as an unprivileged user. Confirm server-side enforcement, not UI hiding.
4. Data governance sign-off. Get security/legal to accept or reject persistent sandbox snapshots with indefinite restore. Define a purge schedule and owner.
5. Pilot. One internal, non-customer-facing panel. Define success criteria (zero isolation escapes, restore reliability, acceptable admin UX) and duration before wider rollout.
6. Re-evaluate at 0.2.0 or 1.0.0. Do not expand scope on a 0.x minor without re-running steps 2–4.

Operational Impact

Maintenance

• A 0.x package is a maintenance liability by definition. Expect breaking changes on minor bumps, thin upgrade documentation, and APIs that shift as the maintainers settle the design.
• Mitigate by wrapping usage behind your own thin adapter layer — the package's own callback/adapter seam makes this natural — so an upstream fork or replacement is a contained change rather than a codebase-wide one.
• Publishable views mean you inherit UI upgrade diffs. Keep customizations minimal and documented.

Support

• No stated support policy, LTS commitment, or security disclosure channel in these notes. Until that exists, treat support as best-effort community and staff accordingly.
• Identify a single internal owner for the package. Unowned 0.x dependencies decay quickly.
• Establish a contingency: confirm the license permits a hard fork, and record what forking would cost.

Scaling

• The one-installation-wide sandbox is a scaling ceiling, not a tuning knob. It caps you at one sandbox per deployment; concurrency is bounded by SQLite's writer model.
• SQLite file growth under indefinite restore is an unbounded resource. Set a retention window and monitor file size as a first-class metric.
• Horizontal scaling is off the table unless the SQLite file sits on shared, lock-capable storage — which reintroduces the failure modes SQLite was chosen to avoid. Plan for vertical scaling and a single writable instance.

Failure modes to instrument

• Isolation escape — sandbox path resolves to production context. Highest impact, lowest detectability. Add an assertion/health check and alert on it.
• Sandbox corruption or failed restore — the persistent file is damaged or restore silently no-ops. Verify restore integrity on a schedule; do not trust the success message.
• Disk exhaustion — SQLite growth on the host volume. Alert at a percentage threshold well below full.
• Ephemeral filesystem loss — container restart wipes the sandbox. Detect at boot via the doctor command and fail loudly rather than starting empty.
• Auto-discovery conflict — provider registration colliding with an existing binding in the host app. Cover in the spike.
• Authorization bypass — role picker reachable by an under-privileged user. Log and alert on every role switch with actor identity.
• Orphaned sandbox state — sandboxes surviving user or tenant deletion. Tie purge to the deprovisioning runbook.

Ramp-up

• Developer ramp-up is low: standard Laravel idioms, Artisan install, publishable config. Half a day for a Laravel-fluent engineer to reach a working local sandbox.
• Operations ramp-up is moderate: the team must own SQLite backup, retention, disk monitoring, and an isolation health check — none of which are conventional Laravel ops concerns.
• Admin/user ramp-up is low given the Filament-native UI, but requires a short written policy on when sandbox use is permitted and what data may be placed in it.
• Budget roughly one engineer-week for the spike plus the isolation proof, and treat the governance sign-off as the long-lead item.