Sf Doctor Laravel Package

Product Decisions This Supports

• Symfony upgrade / roadmap sequencing. A read-only audit gives a first-pass inventory of deprecated APIs, outdated bundle wiring, and configuration smells — the raw input for deciding whether a framework upgrade epic gets funded this quarter or next, and roughly how large it is.
• Build vs. buy vs. reuse for internal tooling. If engineering has proposed writing an in-house "project health" script, this is the cheap baseline to beat. Evaluate it before approving internal build time.
• Technical debt triage and capacity allocation. When several PHP services compete for maintenance budget, a consistent scoring output lets you rank them by debt severity instead of by whoever complains loudest.
• Legacy / acquisition intake. When inheriting a codebase or doing technical due diligence on a partner's Symfony app, this produces a fast, defensible snapshot to anchor the conversation.
• Release-over-release trend signal. Because reports are diffable, you can track whether deprecation debt is shrinking after each upgrade sprint — a real outcome metric for a "modernization" initiative, not just a vanity one.
• CI advisory gate (candidate only). Potential non-blocking check that makes debt visible on every PR without halting delivery.

When to Consider This Package

Evaluate it when: you have one or more Symfony (not Laravel) codebases; the team is small enough that a quick heuristic beats a two-week analysis spike; you need directional signal, not certification; and you can run it as an isolated dev-time tool with a pinned version.

Look elsewhere when:

• Your stack is Laravel. This is the most important fit criterion. The package is built for Symfony conventions — bundles, services.yaml, kernel/DI structure, Symfony deprecation patterns. It will not meaningfully understand Laravel's container, Artisan, Eloquent, or package discovery. If the portfolio is Laravel-first, this is out of scope and should not be trialed.
• You need depth. PHPStan/Psalm at high levels, Rector for automated remediation, or PHP-CS-Fixer for style are the right tools; this is complementary, not a substitute.
• You need security or compliance evidence. composer audit, Dependabot/Snyk, and SBOM tooling cover CVEs; this does not.
• You need org-wide dashboards and historical trending across many repos. SonarQube/Qodana-class platforms are the correct purchase.
• Vendor risk tolerance is low. 11 stars, 0 dependents, and a single maintainer means bus factor of one and no ecosystem validation. Treat it as a dev-only, disposable or forkable tool — never a runtime or production dependency. If it becomes load-bearing, vendor it or fork it.

How to Pitch It (Stakeholders)

For executives (one paragraph): "This is a free, read-only diagnostic that tells us how much Symfony upgrade debt we're carrying — in an afternoon rather than a two-week spike. It carries no production risk: it's a developer tool that reads code and produces a report. I'm asking for a one-day evaluation on our largest Symfony service. Success looks like: a report in under an hour, and at least three findings our current tooling doesn't already surface. If it doesn't clear that bar, we drop it with essentially zero sunk cost. Caveat worth stating plainly: this is an early-stage community project with a single maintainer, so we're buying a one-off insight, not a platform commitment."

For engineering (the operating model):

• Run it as a CLI one-off against a branch, or in a containerized CI step. Do not add it to require for production code paths.
• Pin the version and keep the generated report committed or as a CI artifact so you can diff across releases.
• Position it explicitly as signal generation, upstream of PHPStan/Rector: it tells you where to look, they tell you exactly what to fix.
• Run it in CI as non-blocking first. Promote to blocking only if the false-positive rate stays low enough that developers trust it; a noisy audit tool gets ignored within two sprints.

Decision ask: approve a 1-day spike, with a written go/no-go against the success criteria above. Default answer if criteria aren't met is "no," and that's a good outcome too.