Page Bundle Laravel Package

Product Decisions This Supports

• Close the "adopt" branch of the build-vs-buy decision. Zero stars, zero dependents, archived status, and a 0.03 health score mean there is no adoption signal to weigh. Any roadmap item that named rz/page-bundle as a candidate should be re-scoped immediately against a maintained alternative or an in-house build.
• Turn the package into a requirements skeleton for the page-management epic. The domain model is genuinely useful as a checklist of what "editable pages" needs: a page entity (title, slug, body), SEO metadata (meta title, description, canonical URL), per-page templating/layout, slug→controller routing, and extensible custom fields/storage backends. Lift that list into the epic's acceptance criteria, not the dependency graph.
• Framework-fit decision is already made. Despite being evaluated in a Laravel/PHP context, this ships as a Symfony bundle (RZ Project namespace, *Bundle naming, kernel/bundle registration, service-container wiring). That is an architectural mismatch for a Laravel stack, not a configuration task — which closes the evaluation on its own.
• Dependency-hygiene / tech-debt decision. Archived + zero dependents is a clear "no" for the vendor-risk register. If the package appears anywhere in an existing composer.json, that is a remediation ticket, not a roadmap input.
• Roadmap signal (negative). The archive status plus zero dependents tells you the PHP community never converged on this as a page-management primitive. For "editable pages in PHP," the realistic answers are a full CMS (Statamic, Craft, WordPress) or a Laravel-native package — that shapes where you invest.

When to Consider This Package

Adoption criteria — effectively none are met:

• Maintained and installable: fails. Archived, no security patching, no PHP-version compatibility guarantees. Anything pinned to it is a frozen liability.
• Framework match: fails for Laravel. A Symfony bundle requires a Symfony kernel and bundle registration; grafting it onto a Laravel app means fighting two DI systems for marginal gain.
• Ecosystem traction: fails. Zero stars, zero dependents — no peer validation, no community fixes, no hiring pool that has seen it.
• Reversibility: fails. You would become the sole maintainer of a fork on day one.

When to look elsewhere / do something else:

• Editable marketing pages in Laravel → Laravel-native build (a pages table + slug routing + a Filament admin) or a headless CMS via API (Sanity, Contentful, Strapi).
• A real CMS → Statamic (Laravel-native), Craft CMS, or Winter CMS.
• A Symfony CMS/page layer → Sulu, Contao, or the symfony-cmf lineage — all with live maintainers.
• As a design reference only → Read the source once for entity/route-modelling ideas, then close the tab. Reading is free; depending is not.
• The only legitimate "consider" case → archaeology: you are auditing a legacy Symfony 2/3 app that already vendors it and need to understand its behaviour before replacing it.

How to Pitch It (Stakeholders)

Executive summary — recommendation: do not adopt.

rz/page-bundle is an archived, unmaintained PHP package with no measurable user base: zero GitHub stars, zero downstream dependents, and a health score of 0.03. It is a Symfony bundle, so it does not fit a Laravel stack without bespoke integration work. There is no support path, no security-patch stream, and no community to fall back on. Its only remaining value is as a feature checklist for the page-management epic.

For engineering: treat it as out of scope. If it is already in a dependency tree, flag it for replacement at the next maintenance window rather than patching it. Do not fork it — a fork makes us the permanent maintainer of a package nobody else uses.

For product/roadmap: the feature space it occupies — editable content pages — is real and worth building. But the effort is roughly one to two weeks of Laravel-native work (a pages table, slug routing, and an admin form) or a licensed CMS. Both are cheaper over twelve months than inheriting an orphaned dependency, and both are fully owned by us.

Ask: approve a small spike to build the page-management slice in-house or evaluate Statamic against the feature checklist above, and close this evaluation. Expected effort is bounded and the outcome is a decided, owned direction rather than an open vendor question.