Config Bundle Laravel Package

Product Decisions This Supports

• Where configuration lives: code vs. content. This bundle moves site settings (contact details, social links, footer copy, feature toggles, per-locale strings) out of config/*.yml and into Doctrine entities editable from the Kunstmaan CMS admin. That's a real product decision: who owns a setting — the engineer who deploys, or the editor who publishes.
• Time-to-change as a roadmap input. If your roadmap includes frequent marketing/ops-driven changes (promo banners, legal copy, regional contact info), storing them as CMS-managed config removes a deploy from the critical path. Quantify it: if you ship 2–4 config deploys per week at ~30 min each, the payback case is straightforward.
• Multi-site / multi-brand architecture. CMS-managed config is most defensible when you run several sites or locales that need the same shape of settings with different values — a schema-plus-admin approach beats N divergent YAML files.
• Build vs. buy (build, probably). The surface area is small: a handful of entities, a form type, an admin list/edit view. For a team already on Kunstmaan, this is roughly 1–3 days of work; for anyone else it's a port. The "buy" argument rests entirely on zero-effort adoption inside an existing Kunstmaan install, not on the package's depth.
• Stack-fit decision, flagged up front. Despite the brief describing this as a Laravel/PHP package, kunstmaan/config-bundle is a Symfony bundle tightly coupled to KunstmaanCMS. For a Laravel codebase this is not a candidate at all — the equivalent decision there is spatie/laravel-settings plus a Filament/Nova admin form. Do not let the "PHP package" framing pull it onto a Laravel shortlist.
• What it does not decide. It is not a secrets manager, not a feature-flag service, and not a substitute for env vars. Keep credentials, API keys, and anything requiring audit/rollback in proper config management.

When to Consider This Package

Adopt only when all of these hold:

• You are already running KunstmaanCMS on Symfony with the admin bundle wired up — the bundle's value is the admin integration, not the entity model.
• The settings you need are editor-owned, non-secret, low-cardinality (dozens, not thousands) and tolerate CMS-grade audit trails.
• Your team accepts vendor-style ownership of a 1-star package: 0 dependents, essentially no community, no security response process. Budget for pinning the version and being able to fork or replace it.
• The alternative — hand-rolling two entities and a CRUD screen — genuinely costs more than adopting this, which for a Kunstmaan shop it may well not.

Look elsewhere when:

• You're on Laravel. Wrong framework; use spatie/laravel-settings or a simple JSON-backed settings table plus your admin panel.
• You're on plain Symfony. Use Symfony's native config, or a maintained settings bundle, rather than pulling in a CMS-specific dependency.
• You need runtime safety guarantees — typed config, validation, caching/invalidation, rollback, per-environment overrides, or audit compliance. A DB-backed config table has real failure modes (a bad editor value breaking production with no deploy gate) that this bundle does not solve for you.
• You need secrets or infrastructure config. Env vars / a secrets manager, always.
• Supply-chain risk is a blocker. 1 star and 0 dependents is a legitimate flag in any dependency review; expect security or platform engineering to push back, and have a fork-and-own answer ready.

How to Pitch It (Stakeholders)

To executives (30 seconds): This is a small, MIT-licensed add-on for KunstmaanCMS that lets non-technical staff edit site settings — contact info, footer copy, regional details — directly in the CMS instead of filing engineering tickets. It is low-risk from a licensing standpoint and cheap to adopt if we're already on Kunstmaan. It is not a strategic bet: it has effectively no community (1 star, no downstream users), so we should treat it as code we may end up owning. Recommendation: adopt only inside an existing Kunstmaan property, and only after confirming that hand-building the same screen isn't a two-day job.

To engineering: The bundle supplies Doctrine-backed configuration entities exposed through the Kunstmaan admin. Integration cost is low on Kunstmaan, high anywhere else — it is a Symfony bundle, not framework-agnostic, and it is not a fit for our Laravel services. Expect to pin the version, vendor the source, and accept maintenance. It also needs guardrails before we rely on it: validation on write, a caching layer, environment-aware overrides, and an explicit rule that secrets never live here.

The one-line ask: Approve a short spike (1–2 days) to confirm the CMS-managed settings flow works in our Kunstmaan install and that the build-it-ourselves alternative isn't cheaper — then decide, with a fork-or-replace plan on file either way.