Filament Flow Laravel Package

Technical Evaluation

Architecture fit

• packstub/filament-flow is a Filament panel plugin, not a standalone workflow service. The value proposition collapses to zero if the automation surface does not belong inside an existing Filament v4/v5 admin. For teams already standardized on Filament, it is a native-shaped addition: a WorkflowResource, a RunsRelationManager on the workflow, the graph editor as a custom FlowBuilder field, and node configuration in a ManageNode slide-over. Nothing enters the stack that a Filament developer does not already recognize.
• The internals are more separable than the UI implies, and this is the seam a TPM should exploit. src/Engine/ splits Dispatcher, Graph, and Runner; src/Nodes/ exposes Trigger/Action/Condition base classes plus built-ins. That means domain automations can be created programmatically and extended with custom node classes without touching the canvas — the leverage point for making this feel like our product rather than a plugin.
• Ingress is not limited to the UI: Http/Controllers/WebhookController gives external entry, config/packstub-flow.php and a publishable database/migrations/create_flow_tables.php.stub mean config and schema are host-owned.
• The honest boundary: this is a workflow builder, not a workflow platform. No evidence of graph versioning for in-flight runs, SLA/escalation semantics, human-task assignment, or multi-tenancy. Position it as internal-ops automation glue; do not let it be sold into a roadmap slot that needs BPM-grade guarantees.

Integration feasibility

• Install path is conventional and low-ceremony: composer require, publish config + migration stub, migrate, register the plugin on the panel, php artisan filament:assets. The frontend ships prebuilt (resources/dist/flow.js, flow.css registered via FilamentAsset), so consuming teams need no bun/Vite/Tailwind toolchain unless they fork the canvas — a real advantage in locked-down CI.
• The queue is the hard dependency, and it should be validated rather than assumed. Runs are described as executing "optionally through the queue," but Wait steps always use it. Any workflow containing a Wait has a non-negotiable runtime dependency on a healthy, delay-tolerant worker pool.
• Optional packstub/agents dev dependency (PHP 8.4) unlocks a real Ask AI node in the workbench. Treat that as a separate build-vs-buy and cost decision (per-invocation model spend, data egress), not a free feature.

Technical risk

• Ecosystem validation is thin. 20 stars, 0 dependents, single small vendor (packstub) shipping a product family. No third-party production references to borrow confidence from, no stated commercial support, MIT license means fork is the fallback.
• Toolchain surface. Svelte 5 + @xyflow/svelte + Tailwind v4 + Vite, with build artifacts committed to the repo. Tailwind v4 inside a Filament panel is a known class of styling-collision risk, and v1.6.1's own upgrade note ("rebuild the stylesheet; run php artisan filament:assets") shows asset staleness is a recurring operational step rather than a one-off.
• Dual Filament v4/v5 support implies an ongoing compatibility matrix and genuine breakage risk on panel major upgrades.
• Queue semantics are unproven. Concurrency, idempotency, and partial-failure behavior are the difference between a demo and a production automation layer.

Key questions

1. What Filament / Laravel / PHP versions are actually in the CI matrix, and what is the stated upgrade and deprecation policy?
2. Does a run pin the graph version it started on, or does editing a workflow mutate behavior for runs already in flight?
3. What are the retry, backoff, timeout, and idempotency semantics for actions with external side effects?
4. Is the runs table pruned by a shipped command, or is retention entirely our problem?
5. How is the webhook controller authenticated — signature verification, shared secret, replay protection?
6. Is the custom-node API (base classes, registration) a public contract, or internal and free to change in a minor?
7. Is there a permission/tenancy model distinguishing who may author workflows from who may run them?
8. Is Postgres supported, or only the SQLite/MySQL combination visible in the test commands?

Integration Approach

Stack fit

• Strong fit: Laravel + Filament v4/v5 panel, Redis or database queue with supervised workers, and an existing backlog of "let ops do X without a ticket" requests.
• Poor fit: API-only services, non-Filament admin stacks, multi-tenant customer-facing automation, or anything needing exactly-once guarantees.
• Audience assumption is load-bearing: internal operators or a small trusted admin set. Customer-visible automation requires isolation, quota, and audit evidence the package does not advertise.

Migration path

• Adoption is additive — no importer, no migration from another engine. Inventory existing ad-hoc automation (observers, scheduled commands, bespoke "when X then Y" controller logic), rank by blast radius, and port lowest-risk first: notifications and enrichment before write-back actions.
• Keep the original code path live until a ported workflow has survived a full business cycle. Porting is a rewrite into configuration, so behavioral drift is the expected failure, not the exception.

Compatibility

• Pin the plugin to the panel's Filament major and treat every panel upgrade as requiring a plugin compatibility gate in the release checklist. Review CHANGELOG.md on each bump — the project's convention is a changelog line per change, which makes this cheap.
• Because assets are prebuilt, consumption needs no Node toolchain. Forking the canvas flips that: you inherit bun, Vite, svelte-check, and vitest as part of your build and release process. Make the fork decision explicitly, not by accident.

Sequencing

1. Time-boxed spike (1–2 weeks), non-critical panel. Build two workflows — one synchronous, one with a Wait step — then deliberately kill the worker mid-run and observe what state survives. This single test answers most of the risk list.
2. Guardrails before breadth. Dedicated workflows queue, per-job timeouts, failed-job alerting, a run-retention job, and a written rule that every action must be idempotent or compensable.
3. Custom node set behind the base classes. This is where product differentiation lives: keep the canvas generic, put domain logic in our PHP. Also the cheapest way to test whether the extension API is stable.
4. Webhook ingress, only after auth/signature and replay handling are verified against question 5.
5. Broaden to write-back automations once run history demonstrates stability over real weeks.
6. Formalize ownership: named internal maintainer, upgrade cadence, documented fork path.

Operational Impact

Maintenance

• MIT, small project, no support contract — assume internal ownership from day one, including the possibility of forking. Budget maintainer time explicitly; do not treat this as fire-and-forget dependency.
• Offsetting that, engineering hygiene is well above what 20 stars implies: Pest suite, Pint, PHPStan level 6, svelte-check, vitest, Playwright e2e against testbench, and a stated convention that every change ships a test and a CHANGELOG.md line. v1.6.1 is a clean patch with explicitly "nothing to do" upgrade notes. That discipline lowers silent-breakage odds but does not remove bus factor.
• Known recurring chores: php artisan filament:assets after any plugin asset change, and committed resources/dist artifacts that must be rebuilt and committed if we fork.

Support

• Community issues only. No SLA, no security-review trail, no vendor escalation path — a hard blocker if any automation touches regulated data or a customer-visible surface.
• Docs live in-repo (docs/ with screenshots). resources/lang/en/flow.php centralizes every UI string, node name, and description, which makes localization and copy review cheap — but also means UI copy is a package-level concern, not an admin-panel setting. Copy changes ride the upgrade cycle.

Scaling

• Throughput is bounded by queue workers, not by the canvas. Each step is a discrete job or runner execution, so high-volume triggers amplify DB roundtrips — batch or debounce at the trigger rather than fanning out per row.
• Wait steps hold delayed jobs, so long waits inflate the scheduler set and inherit your queue driver's retention limits. Model this before committing to multi-day approval chains.
• The runs table grows without documented pruning. Assume we own a retention command, supporting indexes, and a storage-growth line item.

Failure modes

• Queue outage: automations stop silently. The UI is not a health signal — monitor queue depth and failed jobs independently, and alert on stalled workflows queue.
• Partial execution: a mid-graph failure leaves side effects applied upstream. Without idempotent or compensable actions, retries duplicate work.
• Concurrent edits: in-flight runs may observe a workflow graph that changed underneath them. If no version pinning exists, establish an operational rule (freeze edits during long-running batches) until question 2 is answered.
• Silent drift on upgrades: dual Filament support plus committed assets means a panel upgrade can break the canvas without breaking PHP tests. Include a canvas smoke test in the upgrade checklist.
• Webhook ingress as an unauthenticated attack surface if item 5 comes back thin.

Ramp-up

• Low for anyone already fluent in Filament: a mid-level Laravel developer can ship a first workflow in days and a first custom node in about a week. The canvas is prebuilt, so no Svelte knowledge is required for the common path.
• Real ramp cost is operational, not technical: the team must learn queue-centric debugging (delayed jobs, retries, partial state), write idempotent actions by default, and treat the runs relation manager as the primary incident-triage surface.
• Plan a short internal enablement: one written runbook (how to pause, replay, and inspect a run), one worked example per node type, and a policy note on which automation categories are approved for self-service versus engineering-authored. That turns a plugin into a capability the org can actually operate.