Doctrine State Machine Bundle Laravel Package

Product Decisions This Supports

• Modelling entity lifecycles (not a strategic dependency): the package illustrates a pattern — persisting a finite state machine directly on a Doctrine entity so that order, invoice, subscription, or approval objects carry their own status, allowed transitions, and guards. The pattern is a real product decision; this package should not be the implementation.
• Where it would show up in a roadmap if it worked: order/payment lifecycle (pending → authorized → captured → refunded), content moderation (draft → review → published → archived), onboarding/KYC steps, ticket triage, subscription dunning. Any feature where a business analyst asks "what states can this be in, and who can move it?"
• Build vs. buy — this one resolves to "build on a maintained primitive": the underlying capability is commoditized. Symfony's symfony/workflow component (same ecosystem, actively maintained, supports state machines, guards, transition events, and Doctrine entity persistence out of the box) or a lightweight PHP 8.1 backed-enum + transition-method approach covers the same ground with no third-party dead weight.
• Decision it should drive: explicitly defer adoption and log a technical-debt ticket if any codebase still references it. The scoring here is instructive — high "opportunity" (7.76) reflects a genuinely valuable problem domain, while the low composite (2.21) reflects an unmaintained artifact. Don't let the former justify the latter.
• Legacy-scope decision: if inherited code already depends on it, the decision is migration sequencing — extract the state definitions and transition rules, re-express them on symfony/workflow, and keep the persisted status column stable so no data migration is needed.

When to Consider This Package

Adoption criteria — and it fails nearly all of them:

• Only if you are maintaining an existing Symfony 2.x/3.x application that already references kphoen/doctrine-state-machine-bundle and you need to understand or patch its behavior in place.
• Only if your PHP/Doctrine versions are pinned to the era it supported (PHP 5.x/early 7.x, Doctrine 2 pre-2.6), since the last release was 2016-08-17.

Look elsewhere — i.e., always for new work — because:

• It is explicitly marked [DEPRECATED] by its maintainer. That is a hard stop, not a yellow flag.
• 45 stars, 0 dependents, no release in ~9 years. No community to absorb a bug report, no security patching path, and no evidence of production usage at scale to borrow confidence from.
• The ecosystem has moved decisively toward symfony/workflow, which offers the same entity-state-machine capability with guards, transition events, marking-store persistence, and visualization — with actual maintenance.
• Anything you'd hand-roll is small. A status column plus a transition table plus validation in a service is on the order of a day's work and carries no abandonment risk.

How to Pitch It (Stakeholders)

Short version: we should not adopt this, and here's the cheap way to get what it promises.

Executives: the underlying need — giving records like orders or applications an explicit, auditable set of states and permitted moves between them — is legitimate and worth funding. This specific library is not. It was deprecated by its author, hasn't shipped a release since 2016, and has zero downstream users. Depending on it would mean owning a piece of abandoned infrastructure in the middle of a business-critical workflow, where a bug becomes our problem to fix with no upstream to escalate to.

Engineering: use Symfony's Workflow component for state-machine semantics on entities, or a backed enum plus explicit transition methods if the workflow is small. Either gets us guards, transition events for audit logging, and diagram generation, on a supported release cadence. Migration cost for anything already on the deprecated bundle is modest because the persisted status column can stay unchanged — only the transition logic moves.

Recommendation: close as "do not adopt," reuse the design pattern, and allocate the saved integration time to the workflow we actually need.