- What is heyosseus/sloppy and what problem does it solve?
- Sloppy is a deterministic static analysis tool aimed at the technical debt left behind by AI coding agents on PHP and Laravel projects. It ships 34 rules, architecture and module-boundary policies you define yourself, git-diff scoped review, coverage-aware reading order, PHPStan baseline-growth detection, and a Rector plus Pint fix pass. Everything runs locally with no LLM calls, so results are reproducible. It is installed as a require-dev package alongside an Artisan service provider and a standalone vendor/bin/sloppy binary.
- How do I install heyosseus/sloppy in a Laravel application?
- Installation is two composer require --dev commands, one for sloppy and one for the heyosseus/phpstan-sloppy extension, then publish config/sloppy.php. You add a single include line to your PHPStan neon config pointing at vendor/heyosseus/phpstan-sloppy/extension.neon. Nothing loads on production request paths, so adoption is reversible. Do a read-only scan --path=app pass before wiring anything into CI.
- How does sloppy integrate with PHPStan and does it support existing baselines?
- Sloppy runs inside PHPStan through the separate heyosseus/phpstan-sloppy extension, so findings appear as ordinary PHPStan errors using the squiggles, baselines and CI plumbing your team already has. This is the lowest-friction integration surface and the recommended default. It also detects PHPStan baseline growth, which is useful when AI-assisted pull requests quietly widen an existing baseline.
- What is the difference between the PHPStan extension and the vendor/bin/sloppy CLI?
- The PHPStan extension reuses your existing analysis pipeline and is the right default for day-to-day gating. The standalone binary covers what PHPStan does not: git-diff review (diff, ci), the Rector and Pint fix pass, Pest expectations, CI annotation formats, agent rulesets, hooks and an MCP server. Treat these as two separate adoption decisions, since the CLI surfaces are net-new and need their own review. Start with the extension and add the binary only for diff scoping and fixing.
- Can sloppy review only the files changed in a pull request?
- Yes, the diff and ci commands scope analysis to git changes, which turns an unbounded review problem into a configurable, diff-scoped gate. Output maps onto existing CI without a new dashboard via ci --format=github, --format=gitlab and --format=sarif. Paths are repository-root-relative, which matters for monorepos. This is the feature that makes AI-assisted pull requests practical to police.
- Can I define custom architecture rules and module boundaries?
- Yes, architecture policies and module boundaries are described in config/sloppy.php, including exclude patterns, fail_on thresholds, architecture declarations and the SL301 and SL303 layer suffixes. The published config file and the sloppy rules document are the two artifacts to read before configuring anything. Because rules are deterministic and config-driven, the same input always produces the same findings, which makes policy review straightforward.
- What changed in sloppy 1.6.0 and is it a breaking change?
- Version 1.6.0 presents itself as a correctness release but is effectively breaking. Config is now validated, so a wrong type or out-of-range value exits with code 2 and lists every problem, while unknown keys only warn. The standalone binary now merges user config over defaults, SL501 fingerprints dropped line numbers so a re-baseline is required, and more code is analyzed including top-level functions, closures and extended base models. Teams pinning loosely should expect a pipeline to stop after upgrading.
- What do sloppy's exit codes mean in CI?
- Exit code 2 means you supplied invalid configuration, not that sloppy found quality issues. Scripts that only test for a non-zero exit will conflate config errors with findings and produce confusing failures for developers. Handle the two cases separately in your CI wrappers so a misconfigured fail_on or exclude value fails fast and loudly. Pin the version and review exit-code handling before rolling out to multiple repositories.
- Do the Claude Code hooks and agent rulesets modify files in developer workspaces?
- Yes. Sloppy can write .claude/settings.json, .gemini/settings.json, .codex/hooks.json, and generate rulesets such as CLAUDE.md, GEMINI.md and AGENTS.md. Hooks hand findings back to an agent immediately after an edit and once more before it finishes, which is bounded behavior rather than a loop. This is the genuine differentiator, but file mutation inside every developer workspace is a policy question as much as a technical one. Decide the rollout policy before enabling it beyond a pilot repository.
- Does sloppy send my code to an LLM or external service?
- No. Sloppy is deterministic, fully local, and makes no LLM calls, so source code never leaves the machine or CI runner. That makes it suitable for repositories with strict data-handling requirements and gives reproducible results across environments. The trade-off is that findings are rule-based, so you should expect some false positives that need tuning through exclude and fail_on settings rather than model configuration.