Extra Step Bundle Laravel Package

Product Decisions This Supports

• Choosing a flow architecture for branching, multi-step journeys. The business capability under discussion is "steps and paths computed at runtime" — onboarding wizards, quoting and eligibility flows, KYC/document collection, checkout variants, approval chains, configuration builders. This package is useful to a PM primarily as a reference model for that capability: a step registry plus a dynamic path resolver, with each step isolated as a service owning its own form, validation, and template. That decomposition is the durable insight; the code is not.
• Build vs. buy vs. borrow. Three real options get clarified by looking at this: hand-rolled branching inside controllers (fast to start, rots quickly past three flows), a workflow/state-machine library (maintained, testable, hireable), or a workflow SaaS (opex, vendor lock, but no engine to own). The bundle sits off to the side as prior art — evidence that the step-registry/resolver split is a sane design — rather than as a viable fourth option.
• Scoping "dynamic" so it doesn't become infinite. Before committing a roadmap slot, the PM should pin down which semantics the product actually needs: linear wizard with skip-logic, conditional branching, loops/backtracking, or mid-flow step injection. This package's model sets an upper bound on what "dynamic" should mean, which is useful for cutting scope in review rather than letting "dynamic" mean "anything the sales team promised."
• Platform reuse and ownership. If two or more product surfaces need branching flows, one shared engine beats three teams writing their own if ladders. This is a platform-team argument and a roadmap-sequencing decision: fund the engine once, name the owner, and require consumers to build on it.
• Risk intake. Zero stars, zero dependents, no score, single-vendor provenance, and a Symfony 2-era footprint are themselves decision inputs. They belong in the risk register as a worked example of "unmaintained dependency in a revenue path," which is exactly the pattern the engineering standards should screen for.
• Explicit non-decision. No feature, roadmap item, or roadmap dependency in a Laravel product should be gated on this package. It does not install there. Treating it as a candidate would create a false dependency in the plan and waste review cycles.

When to Consider This Package

• The only genuinely valid case: you are maintaining a legacy Symfony 2.x application that already depends on idci/step-bundle, you need branching the base bundle can't express, and the flow is non-critical. Even then, budget it as fork-and-own, not as an upstream dependency with a support assumption.
• As reading material, always. Skim the source to see one working decomposition of "dynamic step + path generation" before your team designs its own. Reading costs an afternoon; depending costs quarters.
• Look elsewhere — firmly — when:
  • The stack is Laravel. This is a Symfony bundle, packaged around Symfony's kernel/bundle/DI model. Laravel's package auto-discovery reads a service provider and extra.laravel, which a Symfony bundle does not expose. There is no drop-in integration path, and "leverage" would mean a rewrite of the integration layer, not an adoption. For Laravel, the substitutes are a maintained state-machine/workflow package, the framework's pipeline and validation primitives, or a hosted workflow service.
  • You are on Symfony 3+. Use the maintained symfony/workflow component plus your own step resolver. Documented, hireable, patched.
  • You need an SLA, security patching, or a vendor contact. Zero dependents means zero downstream pressure to fix anything and effectively no community answers. Escalation path is the source code.
  • The flow touches money, entitlements, or compliance. An unmaintained dependency on a decision path is an audit finding in waiting.
  • You need a staffing story. No contributor pool, no tutorials, no Stack Overflow corpus — every question is reverse-engineering.
• Disqualifier summary: wrong framework for the stated context + unmaintained + no adoption + EOL runtime generation = study, don't ship. The PM action is a documented substitution decision, not a backlog item.

How to Pitch It (Stakeholders)

Executives. The capability is worth funding: flows whose steps and branches are decided at runtime from user data show up everywhere in quoting, onboarding, and approvals, and they are hard to retrofit later. The package is not investable — it is a Symfony 2-era artifact with no adoption, no maintainer, no support channel, and it does not run on our Laravel stack. Recommendation: approve a small, owned flow-engine capability on our current stack; use this repository as prior art and a design reference only; do not add it to composer.json.

Engineering. Treat this as a design reference, not a dependency. The useful pattern is the split between a step registry (tagged services, each owning controller + form + template + validation) and a runtime path resolver that computes the next step — then implement it on primitives we already maintain: symfony/workflow if Symfony services are in play, or a Laravel-native state machine with steps registered via a service provider and transitions dispatched on Laravel's event dispatcher. Persist step state in our own schema, and cache path resolution explicitly — runtime step computation is a natural performance hotspot. Do not attempt a direct install: expecting Composer to resolve symfony/* ^2.x against a current Laravel or Symfony 6/7 constraint set is a known dead end, and --ignore-platform-reqs workarounds are an operational liability we should not accept.

Decision requested. (1) Record this package as evaluated and rejected, with substitution as the documented outcome — requirement preserved, package declined. (2) Approve the step-registry + dynamic-path-resolver pattern as a design input for the flow-engine epic. (3) Confirm the owning team and a timeboxed spike (one to two weeks) to nail down which flow semantics the roadmap actually requires — linear, branching, loops, mid-flow injection — before any build commitment. (4) Confirm that no roadmap item lists this package as a dependency, so downstream planning isn't silently blocked on something we will never install.