Flow Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for multi-step orchestration. This bundle is a compact, readable model of exactly one thing: an ordered sequence of steps with per-step validation and state persisted between them. That is the shape of checkout, onboarding, KYC, account setup, and product configurators. Evaluating it forces the question early: do we own a step/flow engine, or compose it from framework primitives? For a Laravel team the honest answer is usually "compose it ourselves," and this package is the cheapest way to find that out.
• Roadmap sequencing and estimation for wizard-shaped work. If a checkout or onboarding redesign is on the roadmap, this is credible prior art for how to model steps, transitions, step storage, and validation-before-advance. It gives the team shared vocabulary (Step, Flow, Storage, guard) before design starts, which shrinks estimation variance more than it shrinks the estimate.
• De-risking via a timeboxed spike. The domain model is small enough to read in a day. That makes a cheap, falsifiable spike possible: "can our checkout be expressed as N ordered steps with per-step validators and back-navigation?" A yes collapses the design question; a no is a genuine signal that the flow has branching or resumability requirements that need custom design.
• Reuse vs. reimplement in an inherited Sylius/Symfony codebase. For teams that already pull this in transitively, the decision this supports is whether the flow layer is load-bearing (checkout, registration) or incidental — which determines how much of an upgrade or migration is actually risky. The archived status makes that an explicit, budgeted decision rather than a default.
• Vendor/fork vs. depend vs. reimplement. Archived and zero-dependents means adopting it is not "adding a library," it is "accepting permanent ownership with no upstream." Framing that trade-off — one-time reference copy, pinned frozen dependency, or internal reimplementation — is itself the product decision.
• Setting a maintenance-exit policy. If any code already depends on it, this assessment produces a concrete artifact: a "frozen, planned exit" designation with no upgrade path and no patch cadence.

When to Consider This Package

Consider it when:

• You want a reference architecture, not a dependency. Read the source, extract the step/result contract, and implement it in your own idiom. This is the strongest and most defensible use.
• You are maintaining an existing Sylius or Symfony application that already includes it, and you need to reason about, extend, or plan removal of that code path.
• You are on Symfony and want a vendor-battle-tested pattern for step storage, transition guards, and pre/post-transition hooks — and you accept the ownership burden.
• You have a short-lived internal tool with no payment surface, no PII, and no compliance exposure, where "archived" is an acceptable property.
• You need a shared vocabulary and a spec for a design spike on checkout or onboarding, at essentially zero cost.

Look elsewhere when:

• You are on Laravel. This is a Symfony bundle, not a Laravel package: it assumes Symfony's DI container, event dispatcher, HttpKernel, routing, and typically Doctrine. Laravel has no bundle or CompilerPass concept, so "integrating" means running two container and event systems side by side and writing adapters for every step. The orchestration logic is small and conceptually framework-agnostic; the code is not. Port the pattern to Laravel primitives (a Step contract, a Flow definition, a state store, guard middleware) instead of porting the package.
• The flow touches money, PII, or compliance. Archived means no security response channel, no CVE patches, and no PHP-version compatibility work. That is disqualifying for checkout regardless of how well the pattern fits.
• The product has a multi-year horizon. 83 stars and zero dependents means effectively no community; any fork makes you the sole maintainer indefinitely.
• You need modern PHP or framework support. Read-only projects do not track language or dependency upgrades. Assume you will do that work, and confirm the license directly from the repository rather than inferring it from the parent project.
• You need branching flows, multi-device resume, or long-lived resumable state. The default state model is session-backed, which forces sticky sessions or a shared store and cannot survive device changes or abandonment without moving state to a persisted, user-keyed store.

How to Pitch It (Stakeholders)

For executives. This is a small, archived component extracted from the Sylius e-commerce platform that models multi-step flows such as checkouts and setup wizards. It is not a dependency we should adopt. It is read-only — no security patches, no PHP-version maintenance, no issue triage — and it has negligible adoption (83 stars, zero dependents), which means any fork would leave us as its only maintainer. Its value is as a free design reference: a compact, proven model for ordered steps, per-step validation, guarded transitions, and persisted partial state. We can use it to sharpen estimates and de-risk the design of our own checkout or onboarding flow for roughly a day of engineering reading. Recommendation: use it as prior art in a design spike; keep it out of the dependency graph.

For engineering. Treat it as a specification, not a library. The valuable surface is small: the Step contract (display() for GET, process()/forwardAction() for POST), the Flow/scenario definition holding ordered steps, the step-storage abstraction, and the result types that decide redirect vs. render vs. advance. Extract those semantics, discard the Symfony-specific scaffolding (configuration tree, CompilerPass, service tagging, bundle registration), and implement the contract in Laravel idioms — a Step interface, a Flow definition object, a FlowState store behind an interface so session-to-database is a swap rather than a rewrite, and middleware acting as a step guard against out-of-order or replayed access. Budget a one-to-two sprint implementation for something hardened and tested, not a day. Design explicitly against the failure modes this class of flow always has: abandonment with no expiry policy, double-submit producing duplicate side effects, state desync between flow progress and the persisted record, and session expiry mid-flow. If any existing code already depends on the bundle, mark it frozen — no upgrades, no patches, planned exit — and flag that as a tracked risk rather than an accepted condition.