App Bundle Laravel Package

Product Decisions This Supports

• Platform standardization (build vs. buy vs. fork): The core decision remains whether our Symfony service template should be a shared "app bundle" — kernel/config bootstrapping, console wiring, ops/health endpoints, message-bus conventions — or copy-pasted boilerplate per service. This package is a candidate reference implementation for that template, not a feature dependency. v4.0.0 sharpens this: the release adds no product capability, it only re-bases the package on Symfony 8.x and PHP 8.5+. That is a platform-baseline decision being made by the vendor, not by us — reinforcing "read it, don't depend on it" unless our runtime roadmap already points at Symfony 8 / PHP 8.5.
• Runtime baseline commitment (new): Adopting v4.0.0 is a decision to move our images, CI matrix, and every co-resident library to PHP 8.5+ and Symfony 8.x. That is a multi-team infrastructure line item, not a composer require. Worth explicitly separating "we want this bundle's conventions" from "we want the vendor's runtime cadence," because v4 bundles them together.
• Time-to-first-endpoint: Still the main upside — onboarding cost per new microservice and how many services one squad can own. If it removes a sprint of glue per service, that's real roadmap capacity at 3+ services. Unchanged by this release, but now gated on our ability to run PHP 8.5.
• Ecosystem commitment: Adopting it only makes sense alongside the rest of the Gdbots stack (PBJ messages, NCR/Curator, queue transports). v4.0.0 is evidence of how that stack behaves: a single-vendor ecosystem that cuts a hard major to chase the newest Symfony/PHP release. Committing to it means committing to that release cadence, and to a version-support policy we cannot influence.
• Upgrade roadmap input: Now a concrete, dated tax rather than a hypothetical. Any dependency here pins us to Symfony major cadence and the vendor's cadence and PHP minor-version adoption speed. Put "track vendor majors; budget a migration whenever they bump Symfony" into the annual framework-upgrade budget.
• Support-window / LTS risk (new): v4.0.0 gives no indication that v3.x remains patched. If we adopt on Symfony 7.x/PHP 8.3 and decline v4, we should assume we own that branch entirely. Quantify as "one named engineer, part-time, plus our own backport policy."
• Fork/maintenance liability: Apache-2.0 means forking is legal and cheap; the decision to adopt is really a decision to potentially own. A hard-major release like this is a reminder that forking is the likely end state if we ever need to stay on an older Symfony.
• Use cases: Internal event-sourced/message-driven services, admin and ops-facing APIs, back-office tooling. Explicitly not consumer-facing feature work, and not applicable to non-Symfony PHP.

When to Consider This Package

Adopt/evaluate when:

• You are already on Symfony and seriously evaluating the Gdbots stack — this bundle is the wiring layer and delivers little standalone.
• You can realistically run Symfony 8.x on PHP 8.5+ within the current planning horizon. If your org standard is Symfony 7.x / PHP 8.3–8.4, v4.0.0 is not adoptable today and you are effectively evaluating an unsupported v3 branch.
• You run 3+ Symfony services and can point to duplicated bootstrap/config code you're actively paying to maintain.
• You want inherited opinions on CQRS/event-sourcing/queueing rather than designing them from scratch.
• You have an engineer who can read and patch vendor Symfony code, and CI that can pin, matrix-test, and upgrade-test it.
• You value conventions over community size and are comfortable being an early adopter — including being early on PHP 8.5 itself, with the tooling and hosting gaps that implies.

Look elsewhere when:

• Adoption signals matter to you. Three stars, zero dependent packages, single-vendor origin, low opportunity score — this is effectively an internal library published publicly. No ecosystem, no third-party integrations, no talent pool, thin tutorial/Stack Overflow coverage.
• You are not ready to move the whole platform to PHP 8.5 / Symfony 8. v4.0.0 is a breaking runtime-floor bump with no deprecation runway; there is no supported middle path visible.
• You need vendor support, SLAs, security advisories, an LTS branch, or any maintenance guarantee — the v3-to-v4 jump is a live example of what "no guarantee" looks like in practice.
• Your application isn't event-sourced or message-driven — the opinions become dead weight and coupling.
• You're not on Symfony (Laravel, Slim, vanilla PHP) — use framework-native primitives.
• You only want one or two capabilities (health checks, logging, console wiring); a small compiler pass or a well-known bundle is far cheaper than a platform dependency.
• Your team lacks Symfony internals depth — bundles like this become opaque the moment they break, and debugging moves into vendor code.

Due diligence before any commitment: confirm the release history and CHANGELOG reflect an actual cadence rather than a single internal tag; check whether issues/PRs get responses; and — newly relevant — ask explicitly whether v3.x receives security fixes now that v4.0.0 has moved the floor to Symfony 8 / PHP 8.5. A recent major bump with no dependents often means "internal release aligned to the vendor's own roadmap," not "supported product."

How to Pitch It (Stakeholders)

To executives: This is a free, Apache-2.0 Symfony application scaffold from a small vendor, and its new v4.0.0 ships no features — it simply requires Symfony 8 and PHP 8.5. That tells us two things: the upside is still 1–2 sprints of boilerplate avoided per new service, and the cost of dependence is now concrete — we would move our entire runtime baseline on the vendor's schedule, and with 3 stars and zero public dependents we would become the de facto maintainers if anything breaks. Recommend a two-week spike with a hard exit criterion, scoped to reading the code as a reference template, and treat "adopt v4" as a separate decision tied to our PHP 8.5 / Symfony 8 roadmap.

To engineering: Treat it first as a reference implementation of Symfony service conventions — read it before writing our own. If we adopt, adopt it as first-party code: vendor or fork it, pin the version, add upgrade tests across the PHP/Symfony matrix, and don't assume upstream fixes land on our schedule. Note that v4.0.0 is a hard major with no deprecation path, so decide deliberately whether we track the vendor onto Symfony 8 / PHP 8.5 or fork a v3 branch and own it. Assign a named owner and budget their time explicitly.

Decision framing: Cheap to evaluate, small blast radius, expensive to be surprised by — and the surprise we now expect is a forced runtime upgrade. Default position remains evaluate, don't depend; upgrade to "depend" only if the broader Gdbots stack is already a strategic choice for the platform and our PHP 8.5 / Symfony 8 timeline matches theirs.