Polycast Laravel Package

Product Decisions This Supports

• Defensive data boundaries over features. Polycast isn't a product capability — it's a hardening decision for every point where raw external data enters the system (HTTP payloads, CSV imports, env vars, queue messages, third-party API responses). It fits a roadmap line like "input integrity" or "reduce data-integrity incidents," not a user-facing feature.
• Build vs. buy at micro scale. Strict casts are roughly 50 lines of code to replicate. The package's real value is the convention — throw instead of silently coerce — and a shared vocabulary across teams. Adopt when review time spent on inconsistent ad-hoc casting helpers exceeds the cost of one tiny dependency.
• Bug-class elimination instead of incident response. Native PHP casts silently truncate ("12abc" → 12), turn null into 0, and lose precision on float→int. Standardizing on strict casts converts a whole category of production data bugs into loud, catchable exceptions — measurable through reduced data-integrity tickets and faster root-cause analysis.
• Legacy cleanup as an enabler. A reasonable stepping stone when modernizing a loosely typed codebase toward strict_types and static analysis; engineers get a drop-in replacement for native casts without a rewrite.
• Explicitly not a roadmap driver. It should never change priorities. It's engineering hygiene that supports quality goals already on the plan.

When to Consider This Package

• You have PHP services with frequent deserialization boundaries and a history of coercion bugs — IDs collapsing to 0, scientific-notation strings parsing unexpectedly, decimals silently truncated.
• Your team already uses declare(strict_types=1) plus PHPStan/Psalm and wants one consistent, exception-based cast API rather than helpers invented per service.
• You want a zero-dependency, MIT-licensed utility that is trivial to vendor or fork, with minimal lock-in.
• Look elsewhere if you need validation with rules and user-facing messages (Symfony Validator, Respect/Validation), framework-native casting (Eloquent casts, ParamConverter), or precise decimal/money handling (brick/math, moneyphp) — floats remain the wrong tool for currency.
• Look elsewhere or simply copy it given the signal here: 50 stars, a score of 0.31, and an unverified repository. Treat it as a code snippet with a Composer wrapper, not a supported dependency. If your policy requires maintained libraries with security-response commitments, this fails the bar — vendor or reimplement.

How to Pitch It (Stakeholders)

This is not a feature; it's a low-cost, low-risk hygiene decision that eliminates a recurring class of data bugs by making invalid conversions fail loudly instead of silently corrupting values. The cost is one small, permissively licensed dependency — or an afternoon of internal code — with no vendor, no infrastructure change, and no lock-in. To engineering: it's a tiny, dependency-free functional API for strict int/float/string casting that complements strict_types and static analysis and replaces scattered native casts at system boundaries. Be honest about the diligence caveat: adoption is thin, so plan to vendor or fork it and own the code rather than relying on upstream support. Recommended path: scoped pilot on a single ingestion path, measure integrity incidents, then decide on broader rollout.