Taxonomy Bundle Laravel Package

Product Decisions This Supports

• Platform fit decision: This is not a Laravel package; it is a Symfony bundle and a read-only subtree split of the Enhavo CMS. For a Laravel product, it should be treated as a rejected option in taxonomy build-vs-buy evaluation, not as an implementation candidate.
• CMS selection: If Enhavo/Symfony is already on the shortlist, this bundle supports content taxonomy requirements such as categorization, tagging, content grouping, and structured content organization as part of the broader CMS.
• Build vs. buy: In an Enhavo context, it can reduce the need to custom-build basic taxonomy capabilities and let the team focus on product-specific content workflows. Outside Enhavo, it does not reduce build effort because integration and compatibility risk are too high.
• Roadmap scoping: Use it to ask whether taxonomy is a commodity CMS capability or a differentiated product feature. If taxonomy is core to search, personalization, permissions, localization, or editorial governance, validate those needs against the main Enhavo repository—not this read-only split.
• Dependency risk: The package has 0 stars, 0 dependents, and README-only maturity. A PM should not treat it as a supported standalone library or assume independent release cadence, documentation, or community support.

When to Consider This Package

• Consider it only when the product is already committed to Enhavo CMS / Symfony and the team needs taxonomy behavior consistent with Enhavo’s content model.
• Consider it as an inspection or extension point for an Enhavo implementation, with the main enhavo/enhavo repository as the source of truth for versions, docs, tests, and upgrades.
• Consider it only if engineering accepts the risks of a subtree split: no standalone maturity signal, limited package-level documentation, and dependency on the parent project’s release process.
• Look elsewhere if the product is Laravel-based, needs a standalone taxonomy service, requires vendor support/SLA, or needs independently versioned documentation and adoption evidence.
• Look elsewhere if taxonomy is central to the product and requires proven capabilities around faceted search, hierarchy governance, localization, bulk editing, permissions, audit trails, or API-first taxonomy management. Those requirements need evaluation against the full CMS or a dedicated domain model, not this package alone.

How to Pitch It (Stakeholders)

For executives: This is not a strategic standalone dependency. It is an internal Enhavo CMS component that may reduce custom taxonomy work only if Enhavo is already the chosen platform. Its low external adoption and README-only maturity mean it should not be presented as a de-risked buy. For a Laravel product, exclude it and evaluate Laravel-native taxonomy options or a small custom domain model.

For engineering: Treat this as a Symfony/Enhavo subtree split, not a Laravel package. Use it only inside an Enhavo implementation, pin to the parent repository’s supported version, and verify taxonomy behavior against the main Enhavo codebase and documentation. Do not architect a Laravel service around it or assume independent package support.