State Transition Machine Bundle Laravel Package

Product Decisions This Supports

• Order, cart, checkout, and payment lifecycle design — this package is the concrete embodiment of a question every commerce product must answer: what states can an order be in, and who is allowed to move it from one to the next? Its structure (explicit states, explicit transitions, service-driven execution) is a useful reference model when scoping our own lifecycle requirements, even though we should not ship it.

• Build vs. buy vs. adopt for workflow state management — this package resolves that decision decisively toward build (or adopt a maintained equivalent). Zero stars, zero dependents, read-only subtree split, no pull requests accepted, and no maintainer path. The evaluation cost is low and the answer is clear; it saves us from a lengthy bake-off.

• Auditability and finance/ops requirements — a formal state machine is how you answer "can a refunded order be re-shipped?" in code rather than in tribal knowledge. This package validates that the requirement ("controlled, enumerable transitions with a recorded history") is standard in e-commerce, which strengthens the case for funding the capability in our own domain model.

• Roadmap signal, negative but useful — the pattern is well-established and worth designing for; the implementation is abandoned. Takeaway: spec the workflow, don't inherit the dependency.

• Risk framing for payments-adjacent code — adopting unmaintained code in a state path touching orders and payments is a governance question, not just a technical one. This assessment gives us the artifact to say no quickly and move on.

When to Consider This Package

Adoption criteria, stated plainly — essentially none are met here:

• Only if we are already running the monolithic elcodi/elcodi suite and this bundle arrives as a transitive dependency we cannot remove without a larger migration. In that case, treat it as frozen vendor code: pin the version, never patch locally, and never file issues here — the README explicitly redirects to the parent repository.

• Only if the support posture (a Gitter room, a Twitter handle, Elcodi docs, no security advisory process, no release cadence) is acceptable for the domain in question. It is not acceptable for anything touching payments or order state.

• Look elsewhere in every other scenario. If we need a state machine in Laravel/PHP today, evaluate maintained alternatives: Symfony Workflow as a standalone component, a lightweight in-house transition table over our Eloquent models, or a maintained Laravel workflow package. All provide upgrade paths, security response, and a community to ask.

• Look elsewhere if the requirement is Laravel-native. This is a Symfony bundle; wiring it in means fighting the service-container and event-dispatcher assumptions for no compensating benefit.

• Look elsewhere if anyone proposes "just fork it." A zero-dependent, read-only split with no maintainer is a fork-and-own commitment, and owning a state machine is a much larger promise than it appears — it becomes core domain infrastructure that product, finance, and ops all depend on.

How to Pitch It (Stakeholders)

For executives: We evaluated an open-source component for order and checkout state management. It belongs to the Elcodi e-commerce suite, which is no longer maintained — the repository is explicitly read-only, accepts no contributions, and has no downstream users. Adopting it would mean taking ownership of unmaintained code in a payments-adjacent path, a risk we should not carry. Recommendation: do not adopt. The underlying pattern — explicit, enforced state transitions for orders — is sound and standard, and we should build it into our own domain model with a maintained library or a small in-house implementation.

For engineering: This is a read-only subtree split of elcodi/elcodi. No issues, no PRs, no independent releases, and it is Symfony-coupled, so it does not fit our Laravel stack without adapter work. If we want a state machine, use Symfony Workflow's standalone component or write the transition rules explicitly over our models — the latter is often better, because our order rules are business logic, not infrastructure, and product should be able to read and change them. I am not asking for further evaluation of this package. I am asking for a short design note covering: our order lifecycle states, who or what may transition between them, what guards apply, and what we persist as transition history.

One-line version for a stakeholder summary: "The library is abandoned and the pattern is standard — we should copy the idea, not the dependency."