Filament Brigada Cms Laravel Package

Technical Evaluation

Architecture fit. wotzebra/filament-brigada-cms is a Laravel package that layers a CMS onto Filament admin panels. Architecturally this is a good fit for teams already standardized on the TALL/Filament stack: it inherits Filament's resource, policy, and panel conventions rather than introducing a parallel admin abstraction. For teams not on Filament, it is a non-starter — the cost of adopting Filament as a prerequisite dwarfs any CMS feature gain.

Integration feasibility. Composer-installable, conventional Laravel service-provider/config-publish flow. Nothing in v0.10.0 changes the integration surface: the release is a single dependency constraint change, adding a hard requirement on wotz/filament-live-preview 0.3.1. That is the whole delta. Integration effort should be treated as low-to-moderate in isolation, but the dependency graph is the real work item.

Technical risk. Material, and concentrated in version maturity rather than code complexity:

• Pre-1.0 on both sides. The package is v0.10.0 and now pins to a dependency that is itself v0.3.1. Under semver, neither side owes backward compatibility. Any minor bump can break you.
• Tight coupling to a pre-1.0 transitive dependency. v0.10.0 exists solely to move the filament-live-preview constraint to 0.3.1, which means upstream changes in that package propagate directly into your admin panel. Live-preview functionality sits on the content-editing hot path — a break there is user-visible, not cosmetic.
• Constraint-collision exposure. A narrow 0.3.1 constraint raises the probability of Composer resolution conflicts if any other package in your graph touches filament-live-preview or its Filament version range.
• Thin release signal. A changelog consisting of one dependency-bump PR gives no visibility into behavioral change. The version jump 0.9.0 → 0.10.0 (a minor bump, which should signal breaking changes under semver) combined with a one-line changelog is a documentation-quality red flag, not necessarily a code-quality one.

Key questions.

1. What Filament major version does v0.10.0 target, and does that match our pinned Filament version?
2. Does the 0.3.1 constraint on wotz/filament-live-preview resolve cleanly against our existing composer.lock, or does it force upgrades elsewhere?
3. What actually changed in filament-live-preview 0.3.0 → 0.3.1, and is that change a fix we need or a break we must absorb?
4. Is the live-preview dependency optional or hard? If hard, we inherit its support burden whether or not we use the feature.
5. Who is the maintainer of record, and what is the bus factor across both filament-brigada-cms and filament-live-preview?
6. Why is a minor version bump shipping with a dependency-only changelog — is there an undocumented breaking change?

Integration Approach

Stack fit. Requires Laravel + Filament. Confirm the Filament major (v3 vs v4) before anything else; this single fact determines whether the package is viable on the current codebase. PHP version floor and Laravel support matrix are not evidenced in the release data and must be verified from composer.json directly rather than inferred.

Migration path. There is no migration from a prior state — this is a greenfield evaluation. If we proceed, treat adoption as: install into a non-production environment → publish config and migrations → validate against a copy of real content structure → then promote. Do not attempt to migrate existing CMS content in the same phase as the package introduction; separate the platform decision from the data migration so a failed evaluation doesn't leave content stranded.

Compatibility. The dominant compatibility risk is transitive, not direct. wotz/filament-live-preview 0.3.1 must resolve against our full dependency graph, including whatever Filament version we run. Run composer why-not wotz/filament-live-preview 0.3.1 as a gate before committing to the upgrade. Expect this to be the single most likely point of failure.

Sequencing.

1. Freeze the current composer.lock as a rollback artifact.
2. Pin filament-brigada-cms to 0.10.0 exactly (not ^0.10) given pre-1.0 semver risk.
3. Resolve and verify the filament-live-preview 0.3.1 constraint in an isolated branch.
4. Smoke-test the content-editing / live-preview path specifically — that is the surface this release touches.
5. Only then evaluate the CMS feature set on its own merits; do not conflate "it installs" with "it fits our editorial workflow."

Recommendation. Neither adopt nor reject on the basis of v0.10.0 — the release carries no product signal, only dependency churn. Make the call on a time-boxed technical spike that resolves question 1 and question 2 above. Absent that, default to hold.

Operational Impact

Maintenance. Expect to track upstream actively. A pre-1.0 package pinned to another pre-1.0 package means routine composer update cycles carry non-trivial breakage probability, and we will be doing constraint surgery rather than passive patching. Budget ongoing maintenance time, not a one-off integration cost.

Support. Support posture is weak. Sparse changelogs mean we cannot reason about risk from release notes; we will be reading diffs. Community support depth for a v0.x niche Filament plugin is likely thin — assume self-support via source reading, and price that into the estimate. There is no vendor SLA and no commercial backing in evidence.

Scaling. The package itself is admin-plane, not request-plane, so it does not sit on customer-facing throughput paths. Scaling concerns are operational rather than architectural: editorial concurrency, media handling, and live-preview rendering cost under large content trees. Live preview in particular can be chatty — validate behaviour with realistic content volume, not a demo dataset.

Failure modes.

• Composer resolution failure on filament-live-preview 0.3.1 — blocks upgrade entirely; detected early, low blast radius.
• Silent behavioral change in live preview shipped without changelog documentation — highest-risk mode, because it lands in the editor UI where users notice and engineers don't test.
• Abandonment — either package going stale strands the admin panel on an aging Filament version, and the eventual exit is a full CMS re-platform.
• Lockfile divergence across environments if the pin is loosened inconsistently.

Ramp-up. Low for developers already fluent in Filament — the mental model transfers directly. Moderate for the rest of the team: Filament itself is the learning curve, not this package. Editorial/users need onboarding to the CMS UX, which is a training cost independent of the version under review.

Overall. v0.10.0 is a maintenance release with no bearing on the adoption decision. The assessment is driven by maturity, dependency coupling, and maintainer concentration — all unchanged by this release. Verdict: hold pending a dependency-resolution spike; re-assess on the first release that ships documented feature or breaking-change content.