Filament Kanban Laravel Package

Product Decisions This Supports

• Roadmap sequencing for "workflow" features. v0.2.0 turns a display-only board into a functioning workflow surface: card actions, per-column create, WIP limits, and column summaries each map directly to a shippable increment (e.g. "move cards and edit inline" → "enforce work-in-progress" → "surface metrics in the board header"). You can plan three releases off one dependency instead of one.
• Build vs. buy on the board itself. Drag-and-drop, optimistic UI, polling, ghost-element rendering, and "load more" are all things engineering would otherwise rebuild and re-debug. The changelog is largely bug-fix work on exactly the fiddly parts (Alpine evaluating the drag ghost, dark-mode styling on the dragged card) — that is the strongest buy signal in the release.
• Data model decisions. columns(Status::class) / Column::fromEnum() means an existing enum can back the board directly, so the board can be added to an existing domain model without a new table or a bespoke status registry. Worth deciding early, since it constrains whether columns come from config or from an enum.
• Server-side rules as product policy. WIP limits and creatable-column rules are enforced on the server, not just visually. That makes "a column is capped at 5" a defensible product guarantee that survives a stale browser tab or an API call — the kind of thing you can put in a spec without an asterisk.
• Integration and automation surface. The CardMoved event plus the kanban-card-moved browser event turn column changes into a hook for notifications, audit logs, SLA timers, or downstream sync. This is the difference between "a board" and "a board that is part of the system."
• Use cases now in scope: lightweight issue/ticket triage, sales or onboarding pipelines, editorial calendars, support queues, and internal approval flows — provided the team is already on Filament. Multi-user boards are viable because polling picks up other people's changes when nobody is dragging.
• Multi-user readiness is now a real product claim. Polling, action-triggered refresh, and poll-safe "load more" mean you can demo the board to two people at once without it looking broken. That affects when you can show it to customers, not just whether it works.
• Deliberate non-goals to plan around: no cross-board swimlanes, no dependencies, no card comments/history in this release. Anything in that list stays on your roadmap rather than the package's.

When to Consider This Package

Adopt when:

• The product already runs Filament. The card and create actions are explicitly gated on Filament's action system (HasActions); components without it get no actions at all — so a non-Filament admin panel gets a materially thinner board.
• The board is one screen inside a larger admin/internal tool, not the product's centrepiece. The feature set is deep on interaction polish and light on planning depth.
• The status set is (or can be) a PHP enum, or is at least stable enough to configure as columns — this release makes the enum path the obvious one.
• Work-in-progress limits or per-column aggregates are on your spec; you get them as configuration (Column::limit(5), summarize(...)) rather than as custom code.
• You need "someone adds a card, everyone else sees it" without standing up websockets. Ten-second polling is a reasonable answer for internal tools and a poor one for a live customer-facing surface.
• You want automation hooks now: CardMoved is enough to wire notifications or audit trails without forking.

Look elsewhere or wait when:

• Version risk is unacceptable. This is v0.2.0. Pre-1.0 means the public API can move; cardAction(), Column::fromEnum(), and the action wiring are all new surface area with no stability guarantee. If the board is load-bearing for revenue, either pin tightly and budget for upgrade work, or defer until 1.0.
• You need planning-grade tooling: swimlanes, dependencies, sub-tasks, comments, card history, per-card permissions, or real-time multi-cursor collaboration. None of that is here, and polling is not a substitute for live sync.
• You need board permissions beyond "read-only columns are refused on the server." Granular per-card or per-column visibility looks like your own problem.
• The stack is Livewire/Blade/Inertia without Filament. The interaction layer assumes Filament and the value drops sharply.
• You need a vendor-backed SLA. Single-package, pre-1.0, no stated support commitment in the notes — that is a procurement fact, not a criticism.

How to Pitch It (Stakeholders)

For executives (one line): We can ship a working kanban workflow — drag-and-drop, inline card actions, capped columns, live totals, and change notifications — as configuration on top of our existing Filament admin, instead of a custom build. It is at v0.2.0, so we pin the version and expect some upgrade work before we would call it permanent.

For engineering: This is a Filament-native board that handles the parts we would get wrong first: drag-and-drop, optimistic refresh, polling, server-side enforcement of WIP limits and column creatability, and the drag-ghost rendering bugs that eat a day each. We integrate through Card::actions([...]), createAction(CreateAction::make()->schema([...])), Column::limit() / Column::creatable(false), summarize(), and poll(), and we get a CardMoved event plus a browser event to hang our own logic on. The constraint to note: action wiring requires Filament's HasActions, so anything outside that system gets a static board. It is pre-1.0 — we pin the version and treat the configuration API as provisional.

For the delivery team: The release is mostly polish and enforcement, which is what we want from a dependency — the changelog is dominated by fixes to the drag interaction rather than new abstractions we would have to learn. The two items that change our plans are server-enforced limits (we can promise behaviour, not just visuals) and the move event (we can wire notifications without forking). Plan an upgrade pass when 1.0 lands.