Ploi Dashboard Laravel Package

Technical Evaluation

What changed in v2.1.1: The only substantive change is PR #12 ("Support filament 5") from a first-time contributor. Everything else is Dependabot churn on CI-only tooling (aglipanci/laravel-pint-action 2.4→2.6, dependabot/fetch-metadata 2.3.0→2.5.0). Those CI bumps carry zero runtime risk.

The Filament 5 addition is the one item with real integration weight. lartisan/ploi-dashboard is a Filament panel plugin that surfaces Ploi server/site management inside an admin console, so its compatibility envelope is dictated by Filament's major version. Filament majors have historically shipped breaking changes to panel registration, resource/form schema APIs, and asset registration, so "supports Filament 5" is either:

• a widened Composer constraint (multi-version support — low risk, high value), or
• a hard pivot to Filament 5 that drops 3.x/4.x (breaking for any host app still on an older major).

The release notes do not disambiguate this, and composer.json was not supplied in the review data. That is the single most important thing to verify before planning around this release.

Architecture fit: Reasonable if the org already standardises on Filament for internal admin surfaces. The package is a thin UI/read-mostly layer over the Ploi API; it does not own persistent domain state, which keeps it architecturally cheap to adopt and equally cheap to remove. It is not a fit for teams without a Filament panel, and it is not a substitute for infrastructure-as-code or a deployment pipeline — it is an operator convenience layer.

Integration feasibility: Straightforward for a Filament host app: composer require, register the plugin on a panel, supply a Ploi API token, publish config. Effort is measured in hours, not sprints. The real gate is the Filament major-version alignment check described above.

Technical risk:

• Bus factor / maintenance. Single-maintainer community package, now accepting outside contributions. A first-time contributor landing the framework-compatibility PR is a mild positive signal but also indicates the maintainer is not the one tracking Filament releases.
• Abstraction lag. Filament moves fast; a plugin whose headline feature is "we now support the new major" is structurally always playing catch-up. Expect a window after each Filament major where this package is pinned or broken.
• Credential surface. The package requires a Ploi API token with account-level scope. That token lands in the app's config/env and therefore in the blast radius of any app compromise. This is the highest-severity risk in the whole assessment and is unrelated to the release.
• CI-only bumps. No risk; noted only for completeness.

Key questions for the maintainer / spike:

1. Does v2.1.1 widen the Filament constraint (supporting 3/4/5 concurrently) or replace it? Show me the composer.json require block.
2. If Filament 4 is dropped, is there a maintained LTS branch for it?
3. What Ploi API scopes does the package actually use, and can the token be scoped read-only?
4. Is the Filament 5 PR covered by the package's test suite, or was it merged on CI-green alone with no rendering test?
5. What is the maintainer's stated support policy per Filament major — and what happened at the Filament 3→4 transition as a precedent?

Integration Approach

Stack fit: Requires PHP 8.x, Laravel, and a Filament panel (v3/v4/v5 depending on the answer to Q1). If the host application is Laravel without Filament, adopting this package means adopting Filament first — a much larger decision that should not be smuggled in via a dashboard plugin. Confirm Filament is already a dependency of the target app before scoping any work.

Migration path: None required for existing installs on v2.1.0 — patch release, no migrations, no config schema change, no deprecations announced. For new installs, the sequence is: pin the package to a version whose Filament constraint matches the host app, register the plugin, provision a scoped Ploi token, then publish and review config.

Compatibility: The version matrix is the whole game here. Build a small explicit table — package version × Filament major × Laravel major — and pin to a cell you have actually tested. Do not rely on a caret constraint resolving to a working combination.

Sequencing:

1. Resolve the Filament constraint question (read composer.json on the v2.1.1 tag). Blocking.
2. Spike in a non-production branch against a staging Ploi account with a scoped token.
3. Restrict the panel to an admin/ops role; the plugin should not be reachable by general users.
4. Deploy behind a feature flag to the ops team only, run for 2–4 weeks, then decide on broader rollout or removal.

Given the small blast radius and cheap removal, this is a low-ceremony adoption — but do not let it become load-bearing for any runbook.

Operational Impact

Maintenance: Low but non-zero, and it is not your maintenance — it's the maintainer's, and they are one person. Budget a recurring half-day per Filament major release to validate compatibility. Treat the dependency as "pinned and periodically re-evaluated" rather than "tracking latest." Do not enable automated major-version bumps for this package.

Support: No commercial support. Escalation path is a GitHub issue. That is acceptable for an internal ops convenience tool and unacceptable for anything on a production incident path. Explicitly document that the Ploi dashboard is not part of the incident-response toolchain — if it breaks during an outage, engineers fall back to the Ploi UI or CLI.

Scaling: Negligible compute footprint — it is a read-mostly UI over an external API. The real scaling concern is the shared Ploi API token: rate limits are per-account, so multiple environments (dev/staging/prod) all rendering dashboards against the same account will contend. Provision separate tokens per environment if Ploi permits.

Failure modes:

• Ploi API outage or rate limit → dashboard renders empty or errors; underlying infrastructure unaffected. Contained.
• Ploi API breaking change → package silently breaks on an unannounced upstream change. Mitigate with a synthetic check against the Ploi API and a pinned, tested package version.
• Filament major upgrade in the host app → plugin breaks the panel build, potentially taking down the whole admin surface, not just this plugin. This is the blast-radius amplifier: a plugin failure can fail the entire Filament panel boot. Validate in CI on every host-app Filament bump.
• Token compromise → account-level Ploi access. Rotate policy and least-privilege scoping are mandatory, not optional.
• Package abandonment → removal is a composer remove plus deleting the panel registration; no data migration. This is the reason the package is safe to trial.

Ramp-up: Under a day for a Laravel/Filament-fluent engineer. The only unfamiliar surface is Ploi's API semantics. No training programme needed; write a one-page README addendum covering token provisioning, panel access control, and the explicit "not an incident tool" caveat.

Recommendation on v2.1.1: Adopt as a patch update if already on v2.1.0 — the CI bumps are inert. The Filament 5 support is a genuine positive for forward compatibility but is unverifiable without the Composer constraints, so gate any new adoption or host-app Filament upgrade on answering Q1 first. Overall: trial behind a flag with scoped credentials; keep it off the critical path.