Sf Doctor Laravel Package

Technical Evaluation

Architecture fit — low for direct adoption on a Laravel stack. The critical finding is a scope mismatch: pierre-arthur/sf-doctor is described as an automated audit tool for Symfony projects. It is a Symfony-ecosystem diagnostic CLI, not a Laravel package. Laravel does sit on Symfony components, but a Symfony-oriented auditor will typically assume Symfony bundles, DI container conventions, and framework config layout that a Laravel application does not have. Direct composer require into a Laravel app is unlikely to yield useful output without adaptation.

Where the fit is real:

• Any Symfony service in our portfolio (legacy apps, internal tools, acquired codebases) is an immediate candidate.
• Even with zero Symfony footprint, the package is useful as a reference design for an internal Laravel "doctor"/health-audit capability — a rule-based, read-only CLI that reports project hygiene issues.

Integration feasibility. Presumed shape is a Composer package exposing a console command — a low-ceremony integration (install, invoke, read report). Feasibility is high if the target project is Symfony and the package's PHP/Symfony constraints match. Actual constraints, command name, and output format are unverified and must be confirmed before committing.

Technical risk — moderate-to-high, driven by adoption signals rather than code quality:

• 11 stars, 0 dependents. Effectively no third-party production usage. We would be among the first real consumers, absorbing undiscovered edge cases.
• Bus factor of one. Single-author project; no evidence of a co-maintainer or governance.
• Unverified stability contract. No indication of semver discipline, deprecation policy, or test coverage in the supplied data.
• Data hygiene flag. The listed last release (2026-05-01) should be reconciled against Packagist tags and changelog; an anomalous date is a signal to verify metadata before relying on "actively maintained."
• Read-only expectation. An audit tool should not mutate config or dependencies — confirm, because a tool that writes to a project is a categorically different risk tier.

Key questions to resolve before any pilot:

1. What checks does it actually perform, and how are they scored/prioritized?
2. Does it emit machine-readable output (JSON) suitable for CI gating, or only human-readable console text?
3. Which PHP and Symfony versions are supported? What is the declared stability (dev/alpha/stable)?
4. License — compatible with our distribution and forking needs?
5. Is it read-only, or does it modify files/dependencies?
6. Does it have a test suite and CI we can inspect?

Integration Approach

Stack fit. Not a Laravel package; treat it as a Symfony-only tool with secondary value as a design template. Do not plan a Laravel adoption around it as a dependency.

Decision framing — three viable paths, in order of preference:

1. Adopt narrowly (only if we run Symfony). Composer-require into one low-criticality Symfony service, run in CI in report-only mode, evaluate signal quality over 2–3 sprints.
2. Mine for requirements. Use the rule set and report structure as a spec input for a first-party php artisan doctor command. This is the highest-leverage outcome for a Laravel-centric org: we get the ideas without the single-maintainer dependency.
3. Defer. If we have no Symfony surface and no appetite to build an internal auditor this quarter, close this out and revisit only if a Symfony codebase lands.

Migration path. There is no migration — this is greenfield adoption or nothing. Avoid framing it as replacing existing linting/static-analysis (PHPStan, Psalm, Rector); it is complementary if it fills a hygiene-audit gap, redundant if it overlaps them.

Compatibility. Build a small version matrix before piloting: our PHP versions × our Symfony versions × the package's declared constraints. If it supports only the newest Symfony major, our legacy services are out of scope immediately.

Sequencing (suggested):

1. Evaluation spike (1–2 days): install in a throwaway Symfony skeleton, run it, capture the report, inspect the rule list and license.
2. Go/no-go on adoption: does the output surface issues our existing tooling misses? If no, stop.
3. Pilot (2–3 sprints): one Symfony service, CI report-only, no gating.
4. Pin and vendor: exact version constraint; record a fork contingency.
5. Parallel track (optional): draft the internal Laravel audit command spec derived from the rule set — one sprint of engineering, no external dependency.

Operational Impact

Maintenance. Expect to own it. With a single maintainer and zero dependents, upstream fixes for our specific issues are unlikely on our timeline. Budget for forking or vendoring the package if it becomes load-bearing, and treat that fork as a maintained internal asset from day one.

Support. GitHub issues only — no SLA, no commercial backing, no security advisory process evident. For a read-only audit tool the security surface is small (it is not a runtime dependency and ships nothing to production), which materially lowers this concern. Confirm it is dev-only and never installed in production images.

Scaling. Negligible concern. It is a per-project CLI run in CI, not a runtime service. Cost scales with pipeline minutes, not traffic. No concurrency, state, or data-store implications.

Failure modes to plan for:

• False confidence. An audit that reports "clean" while missing framework-specific problems is worse than no audit. Validate against a project with known issues before trusting a green result.
• Silent drift. As our Symfony versions advance, an unmaintained auditor's rules go stale without any error — output looks fine but coverage degrades. Mitigate with a scheduled review and a pinned version.
• Breaking changes without semver discipline. Pin exactly; no floating constraints.
• CI gating misuse. Do not convert audit output into a blocking gate until the rule set has been validated for false positives over multiple runs.
• Abandonment. Detect via stalled issue response; have the fork path pre-scoped.

Ramp-up. Low to run (install, invoke, read). Moderate to trust (rule validation takes real projects and a few cycles). Moderate-to-high to extend or fork (unfamiliar single-author codebase, likely thin test coverage). Near-zero transfer cost if we instead take the requirements-only path and build internally.

Bottom line for a TPM. The composite score (10.8, opportunity 11.75) is not corroborated by adoption evidence — 11 stars and 0 dependents is a thin signal, and the score should be weighted accordingly. The package is a low-risk evaluation and a high-risk dependency, and it is aimed at a framework we are not primarily on. Recommend a 1–2 day spike only if we have an active Symfony codebase; otherwise harvest it as a design input for a first-party Laravel audit command and do not add it to the dependency graph.