Chaos Laravel Package

Product Decisions This Supports

• Whether to fund resilience testing as a practice, or keep discovering gaps in postmortems. The package's value proposition is converting assumed resilience — that a failed job retries, that a flaky third-party call degrades gracefully, that alerts actually fire — into evidence. That is a recurring quality investment decision, not a one-off tooling pick, and framing it that way is what gets it budget.
• Prioritising which failure paths to harden first. Fault injection is a cheap, empirical input to a reliability roadmap: run a handful of experiments against checkout, payments, and notifications, rank the surfaces that broke badly, and let that ranked list — not seniority or anecdote — drive the next two sprints of reliability work.
• Build vs. buy vs. platform for fault injection. The real options are (a) a hand-rolled middleware/decorator that randomly throws, (b) this package, or (c) an infrastructure-level chaos platform (Gremlin, AWS FIS, Toxiproxy). This package only competes with (a). If our gaps are network-, host-, or dependency-level, this is the wrong layer entirely — decide that before spending a spike.
• Risk-gating policy for "deliberately break things" tooling. The most consequential product decision here is governance, not engineering: does anything like this ever run outside local/CI/staging, who is allowed to flip it on, and what is the kill switch? Settling that policy once pays for any future chaos tooling, regardless of vendor.
• Roadmap confidence signal. Latest release 3.0.7 is maintenance only — CI action bumps, housekeeping, a new Pest suite. No features, no API movement. Combined with 3 stars and 0 dependents, the honest read is: fine for a time-boxed reliability spike, not defensible on a critical path.
• A decision not to adopt, which is also a result. A 1–2 day spike that concludes "our error handling is fine, our gaps are infrastructure-level" is a genuinely useful, cheap outcome. Price the spike as a research spend, not as an integration commitment.

When to Consider This Package

Consider it when:

• You are on a conventional Laravel + Composer stack and the target is application-level failure handling: job retries, exception paths, fallback values, user-facing error states, alert firing, idempotency on second attempt.
• The target environment is local, CI, or a dedicated staging environment, with "never in production" treated as default policy rather than a suggestion.
• You want the lowest-ceremony way to make resilience testing a habit. A composer package plus a config file is an easier sell than standing up a SaaS chaos platform, and easier to abandon if it does not stick.
• You can absorb a short engineer spike — install, read the tagged source (the public description is thin and, in circulation, contradictory), write a few experiments against scenarios we actually care about, and verify the environment safeguards behave as claimed.
• You are prepared to pin the version, keep it in require-dev or behind a feature flag, and wrap it in our own thin seam so it cannot leak into production code paths.

Look elsewhere when:

• The need is network-, host-, or dependency-level chaos — latency injection, packet loss, partial dependency outage. An application-layer package cannot model those faithfully; use infrastructure tooling.
• You require a support contract, SLA, or named maintainer commitment. This is single-maintainer, MIT, 3 stars, 0 dependents, GitHub Issues as the only channel. The realistic escalation path is "fork it" — confirm that is acceptable before it touches anything critical.
• The diagnosis is already done and the constraint is remediation capacity. Chaos testing tells you what breaks; it fixes nothing. Buying diagnosis when you already know the answer is motion without progress.
• You cannot guarantee environment isolation — a shared config repo, or a pipeline where one copied .env could enable chaos in production. The risk asymmetry (causing a real outage while "testing") is bad enough to disqualify.
• You are evaluating it as a general test framework. It complements a suite; it does not replace one. Probabilistic failures in CI produce flaky tests unless you can force deterministic rules.
• The package's own identity is unresolved. Public materials describe it both as a probabilistic chaos-injection tool and as low-ceremony prototyping scaffolding for the Lara Zeus/Filament family. Those are different products with different integration costs. Resolve that in the spike — ten minutes of reading the tagged source and config file — before any roadmap conversation cites it.

How to Pitch It (Stakeholders)

For executives — one paragraph: We have error-handling and recovery logic across our Laravel services that has never actually been executed under failure, because failures are rare and we find the gaps in postmortems. This is a small MIT-licensed library that lets us make our own app fail on purpose in staging and CI — controlled, configurable, environment-gated — so we find those gaps on a Tuesday afternoon instead of during an incident. Cost is roughly a two-day engineer spike with no architectural commitment; the output is a ranked, evidence-based list of which failure paths are broken, which directly feeds the reliability roadmap.

For engineering leadership: the ask is not "adopt this package." It is "fund a two-day spike that either proves our retry/fallback/alerting paths work or produces a prioritised defect list." Adoption, if it happens, is require-dev only, version-pinned, behind a feature flag, wrapped in a one-file seam so we can swap or drop it without touching call sites, and barred from production by a boot-time assertion. Exit criteria are explicit: N experiments run, N findings, go/no-go recommendation.

For engineering (the honest caveats, stated up front): three stars, zero dependents, one maintainer, no SLA. Latest release is maintenance only. The public description is inconsistent about what the package even does, so nobody should write a line of code before reading the tagged source and config. We pin ^3.0, upgrade Lara Zeus packages together, and accept that a blocking bug means forking. That is a reasonable trade for a staging-only diagnostic tool and an unreasonable one for anything on the critical path — pitch it as the former only.