Richter Laravel Package

Technical Evaluation

• Architecture fit: Richter is a dev-time static analysis package for Laravel applications. It builds an application graph and reports risk/hazard findings across entry points, middleware, jobs/dispatches, models, and task slices. It is not a runtime dependency and does not alter application behavior. The v0.70.0 release is primarily an accuracy and correctness release: it improves how hazards are propagated, how middleware groups and bootstrap/app.php are interpreted, how dispatch sites are resolved, and how task-slice risk is graded. For a TPM, the package fits as an architecture-governance and CI reporting tool rather than a product-runtime component.
• Integration feasibility: Feasible for a Laravel/PHP team with Composer and CI. Integration is a dev dependency plus a CLI/report generation step. The main operational change is the graph cache format bump to 28, which forces a one-time cache rebuild. No migration of application code is required. Report outputs include HTML, text, and markdown, which supports both engineering review and stakeholder summaries.
• Technical risk: The primary risk is report drift, not runtime instability. Several v0.70.0 changes can alter findings and risk levels: removed members' hazards can now inherit surviving class reach, changed ShouldQueue/Dispatchable classes outside \Jobs\ can read as unresolved, dispatched-array spreads are now unresolved sites, and middleware group handling now follows Laravel 11+ behavior when withMiddleware is used. If the team gates CI on risk thresholds, these changes can cause unexpected failures or baseline movement. Cache entries with missing/mis-typed unparseable-files flags or no node metadata are now refused, which is safer but can surface previously silent cache inconsistencies.
• Key questions: Which Laravel versions are officially supported, especially around Laravel 11+ middleware semantics? Are risk thresholds, baselines, and waivers configurable for CI gating? How deterministic are findings after a cache rebuild? What is the intended cadence and support policy for 0.x releases? Can reports be retained as CI artifacts for trend comparison? How should unresolved dispatch findings be triaged without blocking delivery?

Integration Approach

• Stack fit: Strong fit for Laravel/PHP monoliths and modular Laravel applications where architecture risk, entry-point exposure, middleware hazards, job dispatch resolution, and model mass-assignment hazards matter. It is less relevant for non-Laravel PHP services or teams without CI-based static analysis.
• Migration path: Add Richter as a Composer dev dependency in a non-blocking CI job first. Generate a baseline HTML/text/markdown report, triage findings with tech leads, then introduce threshold-based gating only after two to three stable runs. Treat v0.70.0 as a baseline-reset release because the cache format and multiple scoring paths changed.
• Compatibility: Confirm the application's Laravel version and middleware bootstrapping style before enabling CI gating. Applications using withMiddleware should expect the new Laravel 11+ interpretation to hide Kernel groups, which may change findings. The cache format bump to 28 should self-heal via rebuild, but CI pipelines should allow a longer first run.
• Sequencing: 1) Pin the package version and review the v0.70.0 changelog with the engineering owner. 2) Run a full rebuild in a branch and archive the report as the new baseline. 3) Compare pre/post findings for removed-member hazards, unresolved dispatches, middleware groups, and task-slice grading. 4) Add a non-blocking CI report job. 5) Define thresholds and waiver rules. 6) Enable blocking checks only after the baseline is accepted. 7) Schedule monthly dependency/report review.

Operational Impact

• Maintenance: Low runtime maintenance, but moderate baseline maintenance. The package is pre-1.0, so changelog review should be mandatory for each upgrade. Pin the version, rebuild caches intentionally, and retain reports as CI artifacts for trend comparison.
• Support: Open-source support with a 0.x release cadence. TPM should assign an internal owner for upgrades, threshold policy, and triage of changed findings. Vendor risk is manageable for dev-only usage but should be documented.
• Scaling: Analysis time grows with application graph size. The cache helps repeat runs, but cache format changes force full rebuilds. In large mono-repos, consider scoping analysis or schedule runs outside peak CI windows. Report artifacts should have retention limits.
• Failure modes: Expected failure modes are CI gate failures from changed risk levels, unresolved dispatch findings after v0.70.0 semantics changes, middleware-group findings shifting for Laravel 11+ apps, and cache refusal/rebuild causing slower first runs. These are visibility failures, not production outages. The main delivery risk is alert fatigue if gating is enabled before the new baseline is accepted.
• Ramp-up: Low for Laravel engineers familiar with Composer and CI. TPM ramp-up is mainly in governance: understanding report semantics, defining thresholds, communicating baseline changes, and distinguishing true architecture risk from analyzer sensitivity. A short enablement session plus a documented triage workflow is sufficient.