Form Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy (narrowly scoped): Informs whether to build custom form capture/submission logic or inherit it from the Enhavo CMS stack. This bundle is the form layer of Enhavo — it is only a "buy" decision if Enhavo is already the platform.
• Platform commitment: Adopting this bundle is effectively a decision to adopt Enhavo CMS on Symfony. It should be evaluated as part of a CMS/platform selection, not as a utility library.
• Roadmap fit for form-heavy features: Relevant if the roadmap includes admin-managed forms, structured submissions stored as CMS data, or form rendering inside CMS-managed pages/blocks.
• Framework fit check: This is a Symfony bundle, not a Laravel package. For a Laravel codebase the correct PM decision is "reject and use Laravel-native form/validation tooling" — the assessment prevents wasted spike time.
• Vendor/dependency risk register: Zero stars, zero dependents, stub README, and a read-only subtree split mean no independent issue tracker, no independent release cadence, and no community support. That is a governance input, not just a technical one.

When to Consider This Package

Consider it only when all of the following hold:

• You have already selected (or are seriously evaluating) the Enhavo CMS on Symfony for the product.
• You need form handling that is integrated with Enhavo's admin, entity model, and content blocks — reimplementing it would mean fighting the platform.
• You are comfortable consuming it as a subtree split: pin a version, track the main enhavo/enhavo repo for changelogs and fixes, and accept that this repository is read-only with no local issue queue.
• Your team has Symfony depth and can read the source as the primary documentation, since the README is effectively a pointer to the main repo.

Look elsewhere when:

• The application is Laravel or framework-agnostic PHP — use Laravel's validation/form request tooling, or a standalone form library.
• You are on Symfony but not on Enhavo — use symfony/form directly with your own persistence; pulling in a CMS bundle for forms is disproportionate coupling.
• You need documented APIs, community support, SLAs, or a visible maintenance signal (stars, dependents, release history) for procurement or security review.
• You need a standalone, host-agnostic form builder with a public roadmap — a first-party form SaaS or a maintained Symfony UX-based solution is a lower-risk bet.

How to Pitch It (Stakeholders)

For executives: This is an internal component of an open-source CMS, republished as a read-only subtree split, not a product with its own community or support. Its value is cost avoidance only if we commit to Enhavo as our CMS; otherwise it adds a Symfony-specific dependency with no adoption signal and no support channel. Recommendation: treat it as part of a platform decision, not a standalone procurement.

For engineering: MIT-licensed, Symfony-based form bundle from Enhavo CMS. Consume via Composer with a pinned version, treat the main enhavo/enhavo repository as the source of truth for issues and releases, and expect to read source rather than docs. Do not fork the split repo; do not assume Laravel compatibility. If we are not on Enhavo, the correct answer is symfony/form (Symfony) or native validation (Laravel).

Bottom line: Low strategic value, non-zero integration value inside one specific stack. Adopt conditionally; do not make it a dependency of anything outside Enhavo.