Laravel Blade UI Fix Prompt

Fix the specified Laravel Blade UI defect without changing application behavior outside the authorized scope.

## Inputs
- Goal and acceptance criteria: [Goal and acceptance criteria]
- Current behavior and reproduction: [Current behavior and reproduction]
- Relevant files and evidence: [Relevant files and evidence]
- Stack and commands: [Stack and commands]
- Constraints and authorization: [Constraints and authorization]

## Input gate
Before proposing or editing code, confirm that the supplied material identifies the affected page or component, the observed defect, the intended result, and the relevant Blade render path. Useful evidence includes Blade views and components, parent layouts, CSS or JavaScript entry points, screenshots at named viewport sizes, browser-console output, failed requests, framework versions, and reproducible test or build commands.

Ask concise clarification questions only when a missing fact blocks a safe diagnosis, such as an unidentified view, ambiguous intended behavior, unavailable component state, or conflicting acceptance criteria. If useful work can continue, state the limitation and proceed with a bounded inspection. Never invent file contents, framework versions, browser observations, command results, or design requirements.

## Codex operating boundaries
Use Codex to inspect only the files and evidence available in the current workspace or supplied context. Trace references across Blade layouts, includes, components, slots, stacks, asset entry points, and directly related frontend code when access exists.

Default to inspection and a proposed patch. Modify files or run commands only when the supplied authorization permits it and the operation is available in the environment. Do not deploy, publish, merge, push, alter production data, modify environment secrets, install dependencies, clear shared caches, or make unrelated backend changes. Require explicit human approval before destructive commands, dependency changes, broad refactors, generated-file replacement, or any production-facing action.

Stop and report the blocker if credentials or secrets appear in output, the required fix would weaken authorization or validation, the repository state is unexpectedly dirty in affected files, the defect depends on unavailable runtime state, or the requested visual change conflicts with security, accessibility, or preserved application behavior.

## Evidence rules
Maintain these distinctions throughout the work:
- Supplied fact: information directly present in the inputs.
- Inspected observation: content directly observed in an accessible file or tool result.
- Execution evidence: an actual command, test, build, browser check, or screenshot comparison produced during this run.
- Assumption: a low-risk premise used to make bounded progress.
- Hypothesis: a possible cause that still requires confirmation.
- Unknown or conflict: missing or contradictory information that remains unresolved.

A screenshot may demonstrate appearance but not prove route, form, authorization, or server-side behavior. Static code inspection may identify a likely fix but does not prove runtime rendering. Do not describe work as fixed, tested, responsive, accessible, approved, or deployed unless the corresponding action occurred and evidence is reported.

## Blade UI repair workflow
1. Establish the change contract
   - Convert the requested result into observable acceptance conditions, including affected routes or states, target viewport widths, supported themes, interaction states, and elements that must remain unchanged.
   - Record the authorized files, permitted commands, and prohibited actions.

2. Map the render and asset chain
   - Identify the route-facing view and its parent layout, Blade components, includes, slots, sections, stacks, and conditional directives.
   - Identify the styling and behavior source actually used by the page, such as Tailwind CSS, Bootstrap, custom CSS, Vite entry points, Alpine.js, Livewire, or plain JavaScript. Do not assume a package is active merely because it exists in the repository.
   - Note responsive breakpoints, container rules, display utilities, specificity, asset loading order, and component state that could explain the defect.

3. Protect Laravel behavior
   - Preserve route targets, HTTP methods, CSRF directives, form field names, old-input handling, validation-error rendering, authorization and authentication directives, localization keys, escaped output, component props, Livewire bindings, Alpine directives, and JavaScript hooks unless the requested change explicitly requires an authorized modification.
   - Flag any proposed change that could alter server-side branching, request payloads, permissions, or persistence rather than silently treating it as a visual edit.

4. Diagnose the root cause
   - Reproduce the defect when an authorized runtime and reliable steps are available. Otherwise perform a static diagnosis and mark runtime behavior unverified.
   - Compare the computed render structure implied by Blade with the relevant CSS and JavaScript behavior. Check malformed HTML, invalid nesting, missing asset imports, conflicting utility classes, specificity, overflow, fixed dimensions, stacking context, focus state, conditional rendering, hydration or initialization order, and stale compiled assets where relevant.
   - Rank competing hypotheses by evidence and select the smallest defensible correction.

5. Design and apply the minimal change
   - Prefer a localized, convention-compatible fix over duplicated markup, global overrides, broad `!important` rules, or unrelated refactoring.
   - Reuse the project's existing component, utility, naming, and breakpoint conventions. Explain any trade-off involving maintainability, browser support, visual fidelity, accessibility, or bundle impact.
   - If edits are authorized, inspect the current repository state, change only scoped files, and retain a reviewable diff. If edits are not authorized or unavailable, provide a proposed patch without claiming it was applied.

6. Verify proportionately
   - Blade and asset integrity: run only authorized project commands that can detect template compilation, syntax, lint, type, test, or asset-build failures. Record the exact command, exit status, and relevant output.
   - Functional preservation: check affected routes, links, form action and method, CSRF handling, field names, validation errors, conditional states, component props, Livewire or Alpine behavior, and browser-console or network errors where applicable.
   - Responsive behavior: evaluate the named viewport widths and critical content states for overflow, clipping, overlap, wrapping, alignment, readable spacing, and touch-target usability. Include expected and actual observations for each tested viewport.
   - Accessibility: check semantic structure, labels, keyboard operation, visible focus, error association, alternative text where relevant, contrast implications, reduced-motion behavior, and ARIA state consistency. Do not claim standards conformance from an incomplete check.
   - Regression scope: inspect shared layouts and components for other consumers. Run the narrowest relevant automated tests first, then broader authorized checks when risk justifies them.
   - Reconcile every acceptance condition as passed with evidence, failed, blocked, or not run. A proposed or unexecuted check cannot be marked passed.

7. Prepare the handoff
   - Identify changed or proposed files, residual risks, unresolved questions, manual review needs, and the smallest safe next action.
   - Provide a rollback method limited to the scoped changes. Do not recommend deleting unrelated work or resetting a repository with uncommitted changes.

## Required output
### Scope and status
Provide the affected page or component, observed defect, intended behavior, authorized mode, inspected materials, and overall state chosen from proposed, partially executed, executed but unverified, verified, or blocked.

### Render-chain diagnosis
List the relevant route-facing view, layout, components or includes, asset entry points, frontend framework features, confirmed root cause, and rejected or unresolved hypotheses. Attach an evidence classification to each material conclusion.

### Change set
For each changed or proposed file, report its purpose, precise modification, reason, application state, behavior intentionally preserved, and regression exposure. Include a concise unified diff or exact replacement snippets when the environment did not apply edits.

### Verification matrix
Use columns for acceptance condition, check or command, expected observation, actual observation, evidence, and status. Cover template or build integrity, target visual states, responsive viewports, interaction behavior, Laravel form or directive preservation, accessibility, and shared-component regression as applicable.

### Risk, recovery, and approvals
Report residual risks, stop conditions encountered, rollback steps, commands or checks not run, unavailable evidence, and any human approval required before further edits, dependency changes, merge, deployment, or production action.

### Next safe action
End with one concrete action that advances the repair without overstating completion.