Symfony Precognition Laravel Package

Product Decisions This Supports

• Form UX strategy: server-authoritative validation without side effects. Precognition lets the client ask "would this pass?" before submitting, so the backend stays the single source of truth for validation rules while the UI still feels instant. This is a direct enabler for decisions like "do we accept a full-page reload on validation failure, or do we invest in inline/real-time validation?" The 1.0.0 release makes this route-scoped and opt-in, which turns the UX decision into a per-surface decision rather than an all-or-nothing platform bet — you can turn it on for checkout and leave admin tooling untouched.
• Build vs. buy on validation plumbing. Without precognition, teams either duplicate rules in the frontend (drift, security gaps) or build a bespoke "validate-only" endpoint per form (N endpoints, inconsistent behavior, controller side effects leaking into dry runs). At 1.0.0 this is now a credible buy option for Symfony shops: it ships the full set of primitives (request/header detection, a short-circuit listener that skips controllers, a validate-only listener that filters violations, and status normalization), rather than being a sketch of the idea. The previously reasonable "10-line custom listener" counter-argument has weakened — the package now handles the fiddly parts (subrequests, query-string mapping, per-field violation paths) that a hand-rolled listener gets wrong.
• Roadmap input for multi-step and high-stakes forms. Checkout, onboarding, KYC, donation/payment flows, and application forms are where failed-submit round trips cost conversion. Precognition moves error discovery earlier in the funnel, which is a measurable roadmap bet (completion rate, error-per-submission, time-to-complete). The violation path filter is what makes this usable for wizards: errors can be attributed to specific fields/steps, so "validate step 2 before advancing" becomes an implementation detail rather than a custom backend feature.
• Scope decisions on controller design. Because validation runs without executing controller code, it creates a clean separation: #[MapRequestPayload]/#[MapQueryString]/constraint metadata is the contract, controllers are the effects. That supports a decision to standardize request DTOs and Symfony Forms across the codebase rather than ad-hoc $request->validate()-style calls scattered in actions.
• Form-layer standardization (new in 1.0.0). The PrecognitiveForm attribute plus Symfony Form support changes the calculus for teams whose forms are built with FormType rather than DTOs. Previously the honest assessment was "this covers payload-mapped controllers"; now it covers the Symfony Forms world too. If our roadmap includes consolidating on Symfony Forms, this package reinforces that direction instead of arguing against it.
• API contract decisions for SPA/Inertia/hybrid frontends. Status normalization means the dry-run response has a predictable shape, which lets us decide whether to document precognition as a first-class capability (documented header, stable error envelope) or treat it as an internal detail. A stable, versioned envelope is the difference between "frontend team can rely on it" and "frontend team reverse-engineers it."
• Security/governance posture for dry-run endpoints. Route opt-in is a genuine product-level control: precognitive behavior is allowlisted per route, so we can reason about exactly which endpoints accept dry runs. That converts "does this expose anything?" from an audit question into a configuration review.
• Deprecation/reuse decision vs. Laravel. If the org runs both Laravel and Symfony services, this is the parity argument: Laravel has Precognition natively, so Symfony can match the pattern rather than invent its own. A 1.0.0 with declared supported Symfony component versions makes that parity claim presentable to architecture review rather than a science project.
• Dependency governance decision. 1.0.0, MIT license, CI/static-analysis hygiene (PHPStan, pre-commit hooks), and explicit Symfony version support declarations move this from "evaluate an experiment" to "accept a small dependency with semver expectations." The remaining decision is ownership, not viability.

When to Consider This Package

Adopt-consideration criteria:

• You are on Symfony (not Laravel). This is a Symfony bundle; Laravel already ships Precognition natively. In a Laravel codebase, this package is not the answer — use the framework feature. Practically, verify your Symfony version is among the declared supported component versions at install time; 1.0.0 includes explicit Symfony 6.4 compatibility work, so 6.4 LTS and adjacent versions are the expected baseline.
• You have form-heavy, conversion-sensitive surfaces (signup, checkout, payment, applications) where a failed submit after a full round trip is a real cost, and you already render errors from server responses.
• You want to avoid duplicating validation rules in JavaScript. If your team is maintaining parallel client-side rules and drifting from server rules, precognition removes that duplication.
• Your controllers have side effects (writes, emails, charges, audit logs) and you therefore cannot naively "just call the endpoint to test it." That is precisely the problem this solves, and the short-circuit listener is the mechanism.
• You use Symfony Forms, or are willing to. The PrecognitiveForm attribute makes FormType-based surfaces a first-class target. If your forms are Forms-based, this is now a much shorter path than it was pre-1.0.
• You need field- or step-level error attribution. The violation path filter is the feature that makes multi-step wizards and per-field inline errors feasible; without it, dry-run results are an undifferentiated error bag.
• Your routes are allowlistable. Opt-in is a feature, but it is also work: every enabled route needs a conscious decision and a test. Budget for that inventory, not just the composer require.
• You have platform ownership appetite for a small dependency. Still ~single-digit stars, no dependents, and a single-maintainer profile. 1.0.0 and a declared license reduce legal friction, but not bus-factor risk. Treat it as a vendored or forked dependency with a pinned version, a named owner, and a fallback plan.

Look elsewhere or defer when:

• Laravel shop — use native Precognition.
• Mostly API-only / machine-to-machine — there is no interactive form to pre-validate; the benefit collapses to near zero.
• Thin forms with trivial validation — the engineering and dependency cost outweighs a marginal UX gain.
• You need vendor SLAs, long-term support guarantees, or broad community validation — adoption signals are still weak. A 1.0.0 tag is a semver statement from one maintainer, not an ecosystem endorsement; keep the fallback (custom validate-only listener) documented even though building it is now less attractive.
• Your validation lives outside Symfony's validator/constraint metadata (heavy custom rules in services, DB-dependent checks) — precognition executes constraints, not your business logic, so the contract may not cover the checks that actually fail.
• You rely heavily on subrequest-rendered or edge-cached fragments — 1.0.0 specifically fixes validation exceptions leaking from subrequests, which is reassuring, but any embedded-controller/ESI form rendering still deserves an explicit test before rollout.

How to Pitch It (Stakeholders)

For executives (30 seconds): Our Symfony forms currently tell users they made a mistake only after a full submit-and-reload round trip. This bundle lets the browser ask "would this submit succeed?" before submitting, using the same validation rules the server already enforces — and critically, without running the controller, so nothing gets created, charged, or emailed. It has just reached a stable 1.0 with an MIT license, support for our Symfony Forms layer, per-route opt-in so we control exactly where it applies, and field-level error mapping that works for multi-step flows. Expected effect: fewer failed submissions on our highest-value forms, higher completion rates, and one set of validation rules instead of two.

For engineering: A thin Symfony bundle that hooks request validation to a dry-run path: constraints run and errors return with a normalized status, but controller code does not execute (short-circuit listener). It removes the need for per-form "validate-only" endpoints and removes frontend rule duplication. 1.0.0 adds the pieces that matter operationally — PrecognitiveForm/Symfony Form support, violation path filtering for per-field and per-step errors, route opt-in (no accidental dry-run exposure), subrequest isolation, query-string mapping support, declared Symfony component versions, PHPStan and pre-commit hygiene in CI. Cost: one composer dependency, a per-route opt-in inventory, wiring on the forms we choose, and tests. Risk: still low adoption (single maintainer, negligible dependents), so we pin the version, keep it behind our own thin adapter, and retain a documented fallback of a custom validate-only listener. Ask: a one-sprint spike on two forms (signup + checkout) with completion-rate and error-rate instrumentation, a written route allowlist, and a named dependency owner — then a go/no-go on wider adoption.