Standard Bundle Laravel Package

Product Decisions This Supports

• Platform/DX investment: v1.8.2 shows this package is maturing from "install some config" into a governed quality standard — it now documents the rule catalogue (PHPStan baseline/extensions/disallowed-calls, Psalm taint analysis, php-cs-fixer, Symfony lints, composer checks, MySQL version pinning) and reads production versions from .env. That is the artifact you point at when deciding whether to fund a central "engineering standards" workstream versus letting each squad assemble its own toolchain.
• Build vs buy: the package encodes an opinionated default (PHPStan level 10 in phpstan.neon, Make targets, rule docs). Adopting it is a buy decision for ~a few hundred lines of config you would otherwise maintain per repo; the decision to fork/override it locally is the build decision that should be made explicitly, not by accident.
• Roadmap sequencing for quality debt: the new info status is significant for planning. It converts baseline entries and disabled php-cs-fixer rules into a tracked number rather than invisible debt — a prerequisite for putting "reduce static-analysis debt by X%" on a roadmap with a defensible baseline.
• Onboarding and service bootstrap: the composer recipes:install flow is the reusable "new PHP service" checklist. This directly supports time-to-first-deploy metrics for new repos and reduces the review burden on platform engineers.
• Standardization across a portfolio: the rules describe what CI reads (gitlab-ci.yml plus the Make targets it calls) without executing anything, which makes the standard auditable — useful for tech due diligence, acquisition integration, or an internal compliance review where you must evidence "we enforce X" without running a scan.
• Upgrade policy decisions: v1.8.2 moves the PHPStan level from the CLI (--level=10) into phpstan.neon. That is a governance change, not just a refactor: the effective level is now a reviewable file in the repo instead of being buried in a Makefile. It also means central changes to the level become explicit diffs — a good thing to standardize on before you have dozens of repos.

When to Consider This Package

Consider adoption when:

• You operate multiple PHP services (or expect to) and are paying real cost for tooling drift — different PHPStan levels, different linters, per-repo Makefile archaeology.
• You already rely on, or are willing to adopt, the PHPStan + Psalm + php-cs-fixer + Make + GitLab CI stack. The package is opinionated about this shape; fighting it is more expensive than not adopting it.
• You want a measurable quality baseline and are prepared to fund the follow-through: the new info status is only valuable if someone owns reducing that figure.
• You have a platform/DevOps owner who can own upgrades. Releases like this one come with an action item that must be applied per project.
• You are standardizing after growth (merger, team split, re-platform) and need a defensible "this is our standard" reference plus written rules.

Look elsewhere when:

• You have one or two small applications — the ceremony (recipes, Make targets, rule catalogue) exceeds the value; a single phpstan.neon and a CI job is enough.
• Your CI is GitHub Actions / Bitbucket / Jenkins and you have no appetite for maintaining a parallel Make layer; the CI-facing rules assume GitLab conventions.
• Your teams treat static analysis config as product-specific craft (custom baselines, bespoke extensions). A shared standard will be overridden continuously and the standard becomes fiction.
• You need runtime/framework capability. This is a standards-and-tooling bundle; it delivers no user-facing features and should never appear on a feature roadmap.
• You cannot accept a --reset --force upgrade path. If projects hold local edits to the copied files, every adoption of a release like this one carries a merge cost you must budget for.

How to Pitch It (Stakeholders)

For executives: This package is how we make "code quality" an operational standard instead of a slogan. It installs a consistent, documented set of checks across our PHP services and gives us a single number for accumulated quality debt. The business case is reduced onboarding time for new services, fewer defect-escapes caught late, and a defensible answer when a customer or acquirer asks how we assure code quality. Cost is low — it is configuration, not a platform build — but it needs one named owner and a modest per-project upgrade budget each release.

For engineering leadership: v1.8.2 is a low-risk, action-required release. The headline is that PHPStan's level now lives in phpstan.neon and is read from there; the Make targets no longer pass --level, and a level supplied on the command line is not seen by the phpstan.level rule. Any project overriding the level must move that override into phpstan.neon. Upgrading requires running the recipe install with --reset --force, so projects with local edits to phpstan.neon or make/qualimetry.mk should diff before applying. In exchange we get a documented rule catalogue, the new info severity (a tracked figure for baseline and disabled-rule debt, not a failure), and the first rules covering runtime dependencies (infra.mysql-version, read from .env).

For the adopting team: treat the release notes' "TODO When updating" section as a definition of done for the upgrade, and pin the version in each repo so the level change is a reviewable diff rather than a surprise. Budget the info-status figure into your next planning cycle — a metric nobody is assigned to move is just noise.