Hello Bundle Laravel Package

Product Decisions This Supports

• A documented "evaluated and rejected" record — not a roadmap input. liip/hello-bundle is archived, self-declared [DEPRECATED], and has 0 dependents. The PM decision it supports is negative: capture the rejection so this candidate does not resurface in future intake reviews.
• Framework-fit screening precedent. Although it surfaces in a "Laravel/PHP package" backlog, it is a Symfony 2 bundle with no Laravel applicability — different kernel, container, routing, and autoloading model. This is a clean worked example of "wrong framework generation = automatic reject," and justifies adding a framework-target field to the intake template.
• Dependency-intake policy calibration. Use it as the canonical example when writing intake tripwires: DEPRECATED in the name, repo archived, zero downstream dependents, framework branch out of security support. These should be hard filters, not weighted scoring inputs — this package should never have consumed a review cycle.
• Architecture direction (indirect). It illustrates the Symfony2 "assemble many small third-party bundles" composition model that was later replaced by Symfony Flex recipes, API Platform, and MakerBundle — evidence for standardizing on first-party scaffolding rather than hand-pinning a stack of third-party bundles.
• Vendor/support risk template. Archived + deprecated + EOL framework + no maintenance channel is the pattern for "unsupported dependency" in an audit finding. Useful as the reference case in the checklist, not as a decision input for any feature.

Not supported: no build-vs-buy comparison, no feature planning, no roadmap slot. Any appearance on a roadmap is a process defect.

When to Consider This Package

Adopt it essentially never. The only defensible reasons to engage with it at all:

• Legacy reference reading. You maintain a pre-Flex Symfony 2.x application and need a working example of FOSUserBundle + FOSRestBundle wiring (dual session/stateless firewalls, format listener rules, serialization groups). Copy the patterns into your own code — do not add the dependency.
• Archaeology on an existing tree. A downstream project already vendors it and you need to understand expected routing/config conventions before removal.

Look elsewhere in every other case:

• Modern PHP reference app: symfony/demo, API Platform's distribution, or MakerBundle-generated scaffolding.
• Laravel stack: Laravel Breeze / Jetstream / Folio. This package is irrelevant here — different framework entirely.
• Auth + REST quickly: symfony/security-bundle with the authenticator system, or Laravel's first-party scaffolding.
• A "hello world" or smoke-test endpoint: build it natively — one route, one invokable controller, one Blade/Twig view, roughly 50 lines, zero external dependency. Publish internally if teams want it standardized.
• Any production, security-reviewed, or compliance-scoped work: hard no. Symfony 2 is EOL with no security patches; adopting guarantees an audit finding and an unpatched transitive surface.

Disqualifying signals to record on intake: DEPRECATED in the name, archived repo, 0 dependents, out-of-support framework branch, single-digit-quality score.

How to Pitch It (Stakeholders)

To executives (one line): "We evaluated a candidate PHP component for scaffolding our user/API layer. It is archived, explicitly deprecated by its maintainer, built for an end-of-life Symfony version, and has no downstream users. Recommendation: do not adopt. It carries security and maintenance risk with zero offsetting benefit and no budget or roadmap impact."

To engineering: "This is a Symfony 2-era reference application, not a library — treat it as documentation of a dead pattern, not a dependency. Do not vendor it; Composer resolution against a modern Laravel or current-Symfony app will fail outright, and forcing it via platform-req overrides drags abandoned transitive dependencies in. If you want a reference for modern REST + auth scaffolding, use symfony/demo or API Platform; on Laravel, use Breeze/Jetstream. If it turns up in an existing tree, flag it for removal as dependency hygiene and note the Symfony 2 baseline is out of security support."

Net PM output: decision = reject and close; action = add "archived / deprecated / EOL-framework / zero-dependents" as automatic tripwires in the dependency intake checklist, using this package as the canonical example, and re-baseline the candidate list to confirm no other Symfony2-era packages are sitting in the Laravel queue.