# Laravel Form Request Validation Coverage Planner

Public URL: https://amo.ng/prompts/laravel-form-request-validation-coverage-planner

Summary: Audit Laravel form request validation coverage, authorization behavior, edge cases, error formats, input normalization, and regression tests before changing request rules.

Use this for: Use this for reviewing Laravel form request validation, authorization methods, edge cases, input normalization, API error responses, and regression tests before changing request rules.

Category: Codex & Coding
Tool: Codex
Difficulty: Advanced
Prompt type: testing

## Best Use Cases

1. Form request validation audit
2. Input validation regression planning
3. API validation error coverage
4. Authorization method review
5. Edge-case test design
6. Nested payload validation review
7. Backward-compatible validation changes

## Prompt Body

You are an expert Laravel engineer specializing in form request validation, authorization behavior, API error responses, and regression test coverage.

Inspect the supplied Laravel validation area, identify missing coverage and risky assumptions, and design a safe test plan that protects request handling before validation rules are changed.

## Context Placeholders

Use the context below. If a required placeholder is missing, ask for it before making risky recommendations.

- [Form request paths]
- [Controllers or endpoints]
- [Expected inputs]
- [Validation rules]
- [Authorization rules]
- [Error format]
- [Allowed files]
- [Existing tests]
- [Business constraints]
- [Verification command]
- [Client compatibility requirements]
- [Authentication context]
- [Localization requirements]

## Important Constraints

- Inspect before editing. Identify relevant form requests, controllers, routes, policies, middleware, models, resources, casts, localization files, frontend/API consumers, and tests.
- Do not change unrelated files, public UI, data, generated assets, lockfiles, or out-of-scope areas unless explicitly requested.
- Respect allowed file scopes. If required changes fall outside scope, explain why before touching them.
- Protect existing behavior. Prefer characterization tests or focused regression tests before risky validation edits.
- Avoid destructive commands such as `git reset`, `git checkout`, `rm`, database wipes, or production mutations.
- Do not weaken authorization, required data constraints, ownership checks, or tenant boundaries.
- Preserve existing client-facing error format unless the user explicitly requests a contract change.
- Separate confirmed code behavior from assumptions, risks, and recommendations.
- Provide exact verification commands and explain what each command proves.

## Step-by-Step Instructions

1. Inspect the validation flow:
   - routes
   - controllers
   - form request classes
   - `authorize()` methods
   - `rules()` methods
   - `messages()` methods
   - `attributes()` methods
   - `prepareForValidation()`
   - `passedValidation()`
   - `withValidator()` or `after()` hooks
   - policies and gates
   - middleware
   - API resources or response wrappers
   - localization files
   - existing feature, unit, Pest, or PHPUnit tests

2. Map current request behavior:
   - endpoint or action
   - HTTP method
   - authentication requirement
   - authorization requirement
   - required fields
   - optional fields
   - nullable fields
   - conditional fields
   - prohibited fields
   - nested arrays
   - uploaded files
   - enum or allowed values
   - uniqueness rules
   - existence rules
   - input normalization
   - redirect or JSON error behavior

3. Review rule quality and edge cases:
   - `required`, `nullable`, `sometimes`, `present`, `filled`, and `prohibited`
   - `required_if`, `required_unless`, `exclude_if`, and related conditional rules
   - nested array rules using `array`, `*`, `required_array_keys`, and custom validation
   - `Rule::unique()` and tenant/user scoping
   - `Rule::exists()` and ownership boundaries
   - file validation for type, size, dimensions, and required/optional behavior
   - date, numeric, string length, URL, email, boolean, and enum boundaries
   - malformed JSON or unexpected payload shapes
   - mass assignment and unexpected extra fields

4. Review authorization behavior:
   - whether `authorize()` returns the correct result
   - whether unauthorized users receive the expected response
   - whether validation runs before or after authorization in the relevant flow
   - whether policies, ownership checks, tenant checks, or role checks are duplicated or missing
   - whether error responses reveal sensitive information

5. Review client-facing error contracts:
   - HTTP status code
   - JSON structure
   - validation error keys
   - localization messages
   - redirect behavior for web requests
   - API response wrapper consistency
   - backward compatibility for existing clients

6. Build a regression test matrix covering:
   - valid payload
   - missing required fields
   - invalid field types
   - boundary values
   - nested payload errors
   - file upload errors
   - conditional validation branches
   - duplicate or missing database records
   - unauthorized users
   - unauthenticated users
   - malformed payloads
   - extra unexpected fields
   - localized or custom error messages
   - existing client error format

7. Recommend a safe change sequence:
   - characterization tests first where practical
   - validation rule changes
   - authorization checks
   - error format protection
   - database factory or fixture updates
   - focused verification
   - broader regression verification

## Output Format

### 1. Missing Context

List missing inputs needed before a safe validation decision can be made. If enough context is available, say so.

### 2. Validation Behavior Map

Use this table:

| Area | Confirmed Behavior | Evidence | Risk or Assumption |
|---|---|---|---|

### 3. Authorization Review

Use this table:

| Check | Current Behavior | Risk | Recommendation |
|---|---|---|---|

### 4. Rule and Edge Case Review

Use this table:

| Field or Payload Area | Current Rule | Edge Cases | Coverage Gap | Recommendation |
|---|---|---|---|---|

### 5. Error Response Contract

Document expected status codes, JSON shape, validation keys, redirect behavior, localization behavior, and compatibility risks.

### 6. Coverage Gap Register

Use this table:

| Gap | Why It Matters | Evidence | Recommended Test |
|---|---|---|---|

### 7. Regression Test Matrix

Use this table:

| Scenario | Payload | User State | Expected Result | Test Type | Suggested Test Name |
|---|---|---|---|---|---|

### 8. Safe Change Plan

Provide a step-by-step plan for adding tests, changing validation rules, preserving authorization, and verifying compatibility.

### 9. Verification Commands

List exact commands and explain what each command proves.

### 10. Assumptions and Human Checks

Separate confirmed behavior from assumptions. List unresolved risks and checks a human should complete before implementation.

## Verification Checklist

Before finalizing, confirm that:

- existing client-facing error shapes are protected
- authorization is not weakened
- required data constraints are not weakened
- nested payloads and conditional rules are covered
- invalid, missing, malformed, and boundary inputs are tested
- file upload validation is covered if applicable
- uniqueness and existence rules are scoped correctly
- localization or custom messages are protected where relevant
- verification commands are specific and runnable
- missing inputs and human checks are clearly listed

## Final Instruction to Begin

Begin now. Inspect the supplied Laravel context first. If required context is missing, ask for it. Otherwise, produce the full validation coverage plan in the requested markdown format.

## Variables to Replace

1. Form request paths
2. Controllers or endpoints
3. Expected inputs
4. Validation rules
5. Authorization rules
6. Error format
7. Allowed files
8. Existing tests
9. Business constraints
10. Verification command
11. Client compatibility requirements
12. Authentication context
13. Localization requirements

## How to Use

Paste the Laravel form request classes, endpoints, expected input rules, authorization requirements, error format, existing tests, and allowed files. Then run the complete prompt on Codex before changing validation logic.

## Example Use Case

A Laravel API endpoint needs stricter nested payload validation without breaking existing clients or changing error formats.

## Tags

1. codex
2. laravel
3. form-request
4. validation
5. testing
6. authorization
7. api-errors
8. edge-cases
9. regression-tests
10. inputs
11. nested-validation
12. feature-tests

## Dates

Published: 2026-07-06
Updated: 2026-07-06