Kit Bundle Laravel Package

Technical Evaluation

Architecture fit First, a correction that governs everything else: this is a Symfony bundle, not a Laravel package. The prior assessment-pm.md and assessment-tpm.md in the source set describe a Laravel package with a PHP 8.1 floor. That framing is wrong, and any decision record built on it should be voided. The package is survos/kit-bundle, distributed via Composer and registered in config/bundles.php, with Symfony 8.1 as its target — the "8.1" in the release note is a framework version, not a PHP version. That single fact changes the entire evaluation: the package cannot be adopted by a Laravel application at all, and its real integration surface is Symfony's DI container, bundle extension, and compiler passes.

Architecturally it is a convention-over-configuration base layer: it scans by directory convention to auto-register routes, console commands, Twig namespaces, and AssetMapper paths, and ships entity traits, form types, and command utilities. For a TPM, that positions it as an internal starter kit substitute — the value proposition is eliminating boilerplate across a fleet of Symfony services, not adding a discrete capability. Adopting it means adopting Survos's project conventions as your house conventions.

Integration feasibility Low mechanical effort for a brand-new Symfony 8.1 service: composer require, register the bundle, set a couple of config keys. Higher effort for an existing application, because convention bundles implicitly assert directory layout and override defaults from FrameworkBundle/TwigBundle. There is no evidence of a Symfony Flex recipe, so registration is manual and upgrade steps are manual too.

The hard gate is the platform floor. Symfony 8.x tracks the newest PHP line (8.4-era), which means this package inherits an aggressive runtime requirement and, critically, excludes Symfony LTS. Enterprises standardize on LTS releases for long-lived services; a bundle pinned to the newest short-lived major is structurally at odds with that policy.

Technical risk

• Zero stars, bus factor one. This is a vendor-author's own toolkit published publicly ("ideal as a base layer for Survos-based projects"). Treat it as upstream-sourced internal code you may have to fork, not as a supported third-party dependency.
• Convention magic is the risk, not the code. Directory-scanning auto-registration produces silent collisions: duplicate route names, Twig namespace shadowing, AssetMapper path conflicts, and compiler-pass ordering surprises. These fail at cache-warmup or first request, not at install.
• Release discipline. 2.0.1's entire changelog is one sentence. There is no migration guide, no security policy, no CI matrix evidence in the sources.
• Version coupling. A bundle requiring Symfony 8.1 cannot be backported to 6.4/7.x without a fork, so it splits your fleet into haves and have-nots.

Key questions

1. What is the actual require block — symfony/framework-bundle, symfony/twig-bundle, symfony/asset-mapper constraints, and the PHP floor Symfony 8.1 implies?
2. Can each auto-registration behaviour be disabled individually? If not, the bundle is all-or-nothing and unsuitable for incremental adoption.
3. Is this a split of a private Survos application monorepo (i.e., an extraction), and is the public repo the source of truth or a mirror?
4. Test matrix: which Symfony 8.1 patch levels and PHP versions are exercised in CI?
5. License and any CLA — matters if we fork.
6. What is the upgrade story when Symfony 9 lands? A one-sentence release note suggests "none documented."

Integration Approach

Stack fit Fits Symfony 8.1 greenfield services and internal tooling. Does not fit: Laravel (any version), Symfony 6.4/7.x LTS estates, or any service where platform stability outranks boilerplate savings. Realistically the addressable set inside a typical org is "new Symfony services we are prototyping," which is small.

Migration path Do not migrate anything onto it. Introduce it only as the seed of a new service, and treat the exercise as an evaluation of whether to adopt Survos conventions or write a thin internal bundle of our own. If the spike succeeds, the deliverable is not "we use kit-bundle" but "we have a documented starter skeleton, currently derived from kit-bundle at 2.0.1," which we can fork the day upstream stalls.

Compatibility Verify before any merge: the app's symfony/* constraints and config.platform.php; the absence of a Flex recipe (so composer.json diffs are ours to maintain); bundle ordering in config/bundles.php; and whether the app already defines routes/Twig paths in the same directories the bundle scans.

Sequencing

1. Re-baseline the decision record: strike the Laravel/PHP-8.1 analysis, restate scope as "Symfony 8.1 bundle, convention layer."
2. Timeboxed spike (2–3 days) in a throwaway Symfony 8.1 app: register, exercise routes/commands/Twig/AssetMapper, confirm each can be turned off.
3. Read composer.json and the source; answer the key questions above.
4. Pin exactly 2.0.1, commit composer.lock, and record the fork decision.
5. Only then decide whether one production-grade pilot service uses it — never the flagship.

Operational Impact

Maintenance Ongoing cost is ownership, not subscription. With zero stars and a single maintainer, plan for the realistic case where upstream goes quiet: someone on our side must be able to read the compiler passes and patch them. Convention bundles also break quietly on Symfony minor upgrades — a new default in FrameworkBundle or a renamed directory convention can silently change what gets registered. Budget a per-upgrade smoke test of route list, Twig namespace list, and AssetMapper manifest as a standing checklist.

Support Community-only, no SLA, no security disclosure process visible. For anything regulated or customer-facing, that fails a standard third-party risk review. The pragmatic answer is to scope it to internal tools where the blast radius of an unpatched bug is contained.

Scaling Runtime performance impact is negligible — the work is compile-time (container build, cache warmup), so it affects deploy duration and cold-start, not throughput. The scaling concern is organisational: if it becomes the house base layer, every future Symfony major upgrade becomes gated on this bundle's compatibility, and the constraint propagates fleet-wide.

Failure modes

• Silent convention collision: auto-registered routes or Twig namespaces shadow app-defined ones; pages render wrong templates with no error. Highest-severity, hardest to spot.
• Abandonment: upstream stops releasing; the bundle blocks the next Symfony major with no local remedy except a fork you did not budget for.
• LTS exclusion: the bundle forces non-LTS Symfony on services that policy requires to stay on LTS — a governance conflict discovered late.
• Recipe drift: no Flex recipe means every consumer hand-maintains registration and config; consumers diverge.
• Constraint trap: a transitive symfony/* conflict surfaces as a Composer resolution failure during an unrelated upgrade, stalling someone else's work.

Ramp-up Engineers need real Symfony bundle fluency — DI extension classes, compiler passes, autoconfiguration, tag conventions — not Laravel familiarity. A mid-level Symfony developer is productive in a day on the happy path and needs a week to debug a registration collision. For the TPM the ramp-up is mostly record hygiene: correct the framework misidentification in the existing assessments, re-scope the decision, and set a standing rule that convention-layer bundles are evaluated as "do we adopt these conventions," never as "do we install this package."