Validation Laravel Package

Product Decisions This Supports

• Build vs. buy for request validation. Every Webman service we ship eventually grows ad-hoc if (empty($post['email'])) checks scattered across controllers. This package answers the "do we write our own validation layer?" question with a cheap "no" — one Composer dependency instead of an internal mini-framework we'd own forever.
• Feature scoping: input hardening as a first-class layer. Adopting it forces the decision of where validation lives (controller attributes vs. a dedicated request/DTO layer) rather than leaving it as an afterthought in the sprint before a public API launch.
• Roadmap sequencing. If validation is declarative and attribute-driven, "add a new field to the signup endpoint" becomes a one-line change. That's a real lever on how fast we can iterate on forms, onboarding flows, and partner-facing API payloads — worth weighing when we plan API v2 or open up endpoints to third parties.
• Standardization across PHP services. If we have more than one Webman app, a shared validation convention reduces the code-review overhead and the "everyone validates differently" tax. It also gives QA a predictable surface to test against.
• Risk containment decision. With 1 star and 0 dependents, this is a low-signal package. The decision it forces is whether we wrap it behind our own Validator interface so we can swap it later — a small architectural bet we should make explicitly rather than by accident.
• Not a differentiator. This is table-stakes plumbing. It should be evaluated on cost-of-ownership, not on product value; don't let it consume roadmap attention beyond a spike.

When to Consider This Package

Adopt when:

• You are already committed to Webman as the runtime. This is a Webman plugin — it has zero value on Laravel, Symfony, Slim, or plain PHP-FPM.
• Your team has Laravel/ThinkPHP muscle memory and wants familiar rule syntax and error messages without dragging in a full framework.
• You want declarative, attribute-based validation (#[Validate]-style) so controllers stay thin and rules live next to the handler.
• You have a small-to-medium API surface, a handful of engineers, and no appetite for maintaining a homegrown validator.
• You value that it's published under the webman-php organization — i.e., the same maintainers as the core framework — over raw community metrics.
• You need scene/group-based rule sets (create vs. update vs. admin), which is a common pain point that hand-rolled validators handle badly.

Look elsewhere when:

• You're not on Webman. Use illuminate/validation standalone, symfony/validator, or respect/validation.
• You need contract-first / OpenAPI-driven validation — go to JSON Schema (justinrainbow/json-schema, league/openapi-psr7-validator) so the spec is the source of truth.
• You require vendor SLA, security disclosure process, or long-term support. One star and zero dependents means no community backstop; bus factor is effectively "whoever maintains the webman org this quarter."
• You need a rich rule ecosystem: DB-uniqueness rules, file/image dimension rules, locale-aware messages at scale, nested/array wildcard validation with deep error paths. Verify these explicitly before committing — don't assume Laravel parity.
• You're on a latency-critical hot path and can't afford reflection/attribute parsing. Webman's resident-memory model caches this well, but benchmark before you assume.
• You need client-facing, framework-agnostic error payloads. You'll likely still write a response formatter on top.

Adoption guardrails I'd insist on: pin the exact version in composer.json, wrap it behind an internal interface, and add a contract test suite so a swap is a day's work, not a quarter's.

How to Pitch It (Stakeholders)

To executives: "We can harden every endpoint against malformed input for roughly one dependency and a day of integration work, instead of a multi-sprint internal project. It's published by the Webman core team, so it's aligned with the framework we're already betting on. The tradeoff is that it's a young, low-adoption package — so we're capping the risk by wrapping it behind our own interface and pinning the version. Worst case, swapping it out is a contained engineering task."

To engineering: "Attribute-driven validation for Webman — declarative rules on the controller, scene support for create/update/admin variants, Laravel-ish rule syntax so onboarding is trivial. It removes the boilerplate and the 'where does validation live?' argument. Caveats: 1 star, 0 dependents, no community backstop — treat it as a small, replaceable dependency, not infrastructure. We'll put it behind a Validator interface, pin the version, and cover it with contract tests."

To security/QA: "This gives us a consistent, enumerable list of what every endpoint accepts and rejects, which is a meaningful improvement over ad-hoc empty() checks and makes input-validation review a matter of reading attributes rather than tracing control flow."

Bottom line for the decision meeting: Low cost, moderate payoff, contained risk — worth a one-week spike on a single service; not worth standardizing across the org until it has survived a quarter in production with us.