Filament Kanban Laravel Package

Technical Evaluation

Architecture fit packstub/kanban is a Filament panel plugin that renders a board as a Livewire component, mapping one Eloquent model per card and one enum/closure-defined set per column. v0.2.0 moves it from a display-and-drag widget toward a full work-surface: card and create actions run through Filament's action system, WIP limits and column creatability are enforced server-side, and column summaries plus polling make the board a live operational view rather than a static grid. That is the right architectural direction for a TPM — the enforcement layer now sits on the server, so the board can be trusted as a system of record for column constraints rather than a cosmetic UI.

Integration feasibility Feasible in a standard Laravel + Filament panel with an existing resource. The package resolves card actions through the board's own query, which means it inherits whatever scoping the board is configured with rather than requiring a parallel authorization path — a meaningful reduction in integration surface. Costs to budget: one Eloquent model plus a status/column attribute per board, a Filament resource (or at minimum HasActions) on the card component, and, for summaries, an aggregate expression per column that must be expressible as a Builder callback.

Technical risk

• Filament version coupling. CreateAction::make()->schema([...]) and the HasActions contract place this firmly in the Filament v4 action API. Teams on v3 will need a v3-compatible branch or a version bump; this is the single largest adoption gate.
• Silent degradation. Components lacking HasActions get no card or create actions — no exception, no warning. A misconfigured resource renders a plausibly working board with missing capability, which is the kind of defect that surfaces in production, not in review.
• Concurrency. Polling refreshes and post-action refreshes are described as preserving "Load more" state, but there is no stated conflict policy for two users moving the same card, nor for a poll landing mid-drag. Server-side WIP refusal implies the client can be told "no" — the failure UX for that rejection is unspecified.
• Summary cost. summarize() runs per column, refreshed after every move. On a wide board this is N aggregate queries per move, uncached unless we add caching ourselves.

Key questions

1. Which Filament versions are supported, and is v3 a supported target or explicitly out of scope?
2. Are card actions subject to the underlying model's policies, or only to board-query scoping? Scoping and authorization are not the same control.
3. What does the user see when the server refuses a move or a create (WIP limit, read-only, full column)? Toast, revert, or silent snap-back?
4. Is CardMoved dispatched inside a transaction, and is it reliable enough to drive downstream automation (notifications, SLA clocks)?
5. Are summaries batched into a single query, or one per column?

Integration Approach

Stack fit Best fit is a Filament v4 panel backed by a single table carrying a column attribute (enum or string) plus an ordering field. Teams already using Filament resources get actions, modals and slide-overs for free; teams without Filament should not adopt this package, since the action, create and card-action surface is now the core value.

Migration path Greenfield boards are straightforward: define the enum, map columns, wire the board query. Brownfield boards already using a hand-rolled drag-and-drop Livewire component should be migrated board-by-board rather than wholesale, because the enforcement semantics change — moves that previously always succeeded can now be refused. Any existing client-side limit logic should be removed at cutover to avoid two sources of truth disagreeing.

Compatibility Enum columns require HasLabel and HasColor on the backing enum; without them the board renders but columns are unlabelled. Card avatars expect a URL plus display name, so the owner/assignee relation must be resolvable cheaply — eager-load it or the card foot becomes an N+1. The browser kanban-card-moved event gives a low-risk hook for front-end analytics without touching PHP.

Sequencing

1. Pin the Filament version and confirm the action API matches our installed minor.
2. Model + enum + board query; verify scoping matches existing resource scoping exactly.
3. Read-only render with columns and enum labels — no actions — to validate data mapping.
4. Enable drag with server-side limits off, then turn on Column::limit() and creatable() once the refusal UX is designed.
5. Add card actions and create actions; audit policies at this step, not later.
6. Add summarize() last, with caching, and measure query count per move before shipping.
7. Enable poll() only after concurrent-edit behaviour is tested with two sessions.

Operational Impact

Maintenance Small dependency with a fast-moving surface — v0.2.0 alone adds eight feature areas. Pin the version and treat upgrades as scheduled work, not automatic. The ghost/Alpine and dark-mode fixes suggest the drag layer has had rendering rough edges; expect ongoing small patches there.

Support Support load will concentrate in two places: "the button isn't there" (missing HasActions, or Card::actions() narrowing the list) and "the move was refused" (WIP limit or read-only column, presented without enough explanation). Both are preventable with a short internal runbook and explicit UI copy. CardMoved and kanban-card-moved give support a concrete trace to reason from when a card ends up somewhere unexpected.

Scaling Polling is the main scaling consideration: every open board issues a recurring request, and each poll that returns changes triggers a refresh. Boards with many concurrent viewers, heavy summaries and deep "Load more" pagination will compound. Mitigate by increasing the poll interval for large boards, caching summary aggregates, and capping initial card loads. Auto-loading "Load more" on scroll removes a user gate that previously bounded pagination — watch for long-lived boards pulling large result sets.

Failure modes

• Card action fails server-side after the board refreshes — user sees a refresh with no visible change and no error.
• Two users move the same card within one poll window; last write wins, with no stated conflict signal.
• WIP limit reached by someone else mid-drag; the drop is refused after the fact.
• Summary query throws on an unusual column (nullable aggregate); if not isolated, the whole column header fails.
• Component missing HasActions — feature silently absent rather than loudly broken.
• Large board plus polling plus auto-load produces repeated broad queries.

Ramp-up Low for a developer already fluent in Filament v4 — an afternoon to a first working board, a day or two to production-grade with limits, actions and summaries. Non-Filament developers will spend most of their time on the action system and Livewire lifecycle rather than the board itself. Budget explicit time for the refusal UX and the authorization audit; those are the two areas where the package's server-side guarantees meet our own policy requirements, and neither is fully answered by the release notes.