Frontend State Bug Reproduction and Verified Minimal Fix

Public field comparison

Frontend State Bug Reproduction Script

Frontend State Bug Reproduction and Verified Minimal Fix

Use Codex to isolate frontend state bugs, write reliable reproduction steps, trace state transitions, and add targeted regression coverage.

Use Codex to reproduce a frontend state defect, trace its causal state transition, implement an authorized minimal patch, and produce evidence-backed regression verification.

Use this to make Codex reproduce, trace, and verify a frontend state bug before patching it.

Use this prompt to investigate React, Vue, and other frontend state bugs through reproducible user flows, causal state tracing, minimal fixes, and targeted regression tests.

Frontend State Debugging
UI Bug Reproduction
State Transition Tracing
React Component Bug Review
Vue Component Bug Review
Playwright Regression Testing
Minimal Patch Planning
User Flow Verification
Browser-Specific Bug Review

Reproducing intermittent React or Vue state defects
Tracing state loss across routing, pagination, storage, and remounts
Diagnosing stale closures, watcher timing, hydration, and request races
Planning and applying evidence-backed minimal frontend patches
Creating targeted component or Playwright regression coverage

App framework
Bug report
Affected route or component
Expected behavior
Actual behavior
State management pattern
Browser or device notes
Existing tests
Test command
Allowed files
User flow
Recent changes
Known constraints

App framework
Bug report
Affected route or component
Expected behavior
Actual behavior
State management pattern
User flow
Repository access and execution permissions
Allowed files
Existing tests and commands
Browser or device notes
Recent changes
Known constraints

Paste this into Codex with the frontend bug report, affected component or route, expected behavior, actual behavior, state management pattern, existing tests, test command, and allowed files. Ask Codex to reproduce and trace the state bug before approving any patch.

Open Codex in the repository workspace, replace every bracketed variable, and provide the bug report, affected source files, state architecture, reproduction evidence, existing tests, commands, permissions, and environment details. Then run the prompt. Grant edit or command execution access only when Codex is authorized to use it, and review the evidence ledger, diff, and verification matrix before accepting any fix.

A React filter panel resets selected filters after pagination, and the team needs Codex to reproduce the bug, trace the state transition, apply a minimal fix, and add Playwright coverage.

A React filter panel loses selected filters after pagination. Codex inspects URL synchronization, store ownership, effects, and request timing; reproduces the transition in an authorized browser harness; applies a scoped fix; and records a Playwright red-green result without claiming deployment or approval.

Expert

Expert

Codex

Codex

debugging

debugging

frontend-state
bug-reproduction
codex
regression-testing
playwright
ui-debugging
state-management
react-debugging
vue-debugging
minimal-patch
verification
user-flow
state-transition

frontend-state
bug-reproduction
codex
react-debugging
vue-debugging
state-transition
race-condition
hydration
playwright
regression-testing
minimal-patch
evidence-based-debugging

Codex Frontend State Bug Reproduction Prompt

Codex Frontend State Bug Reproduction and Fix Prompt

Use Codex to reproduce frontend state bugs, trace root causes, plan minimal patches, and add targeted regression checks.

Reproduce frontend state bugs, trace causal transitions, apply minimal authorized fixes, and verify regressions with evidence in Codex.

Prompt-body line comparison

Removed Added Unchanged context

−You are a senior frontend engineer specializing in frontend state bugs, UI reproduction workflows, component-level debugging, and targeted regression coverage.
+Investigate the supplied frontend state bug using a reproduction-first, evidence-controlled workflow. Diagnose before editing, preserve uncertainty, and make only authorized changes.
 
−Your task is to turn a frontend bug report into a reliable reproduction, trace the state transition causing the bug, and plan the smallest verified fix with targeted regression coverage.
+## Inputs
 
−Context:
−Use the context below. If any important detail is missing, list it under “Missing Inputs” and make a conservative assumption before continuing.
+- App framework: [App framework]
+- Bug report: [Bug report]
+- Affected route or component: [Affected route or component]
+- Expected behavior: [Expected behavior]
+- Actual behavior: [Actual behavior]
+- State management pattern: [State management pattern]
+- User flow: [User flow]
+- Repository access and execution permissions: [Repository access and execution permissions]
+- Allowed files: [Allowed files]
+- Existing tests and commands: [Existing tests and commands]
+- Browser or device notes: [Browser or device notes]
+- Recent changes: [Recent changes]
+- Known constraints: [Known constraints]
 
−* App framework: [App framework]
−* Bug report: [Bug report]
−* Affected route or component: [Affected route or component]
−* Expected behavior: [Expected behavior]
−* Actual behavior: [Actual behavior]
−* State management pattern: [State management pattern]
−* Browser or device notes: [Browser or device notes]
−* Existing tests: [Existing tests]
−* Test command: [Test command]
−* Allowed files: [Allowed files]
−* User flow: [User flow]
−* Recent changes: [Recent changes]
−* Known constraints: [Known constraints]
+## Input gate
 
−Important constraints:
+Treat the bug report, expected behavior, actual behavior, affected surface, and user flow as minimum diagnostic inputs. Repository access is required to attribute a root cause to code. Execution permission and a runnable environment are required to claim reproduction or test results. Edit permission and an allowed-file boundary are required before changing files.
 
−* Do not start with code changes.
−* First inspect the affected component, state source, event handlers, derived state, effects, watchers, query parameters, storage, cache, and existing tests.
−* Do not invent files, routes, selectors, components, test commands, screenshots, or user behavior.
−* Separate confirmed evidence from assumptions.
−* Do not perform broad refactors unless explicitly approved.
−* Do not change unrelated UI, styling, API behavior, authentication, permissions, billing, or routing logic.
−* Keep the patch minimal and directly tied to the reproduced state bug.
−* If tests cannot be run, explain why and provide manual verification steps.
−* If the bug may be browser-specific, async-related, hydration-related, stale-state-related, race-condition-related, or cache-related, call that out clearly.
−* Ask for approval before adding new dependencies or changing test tooling.
−* Use only the allowed files unless the root cause clearly requires another file, then explain why before editing.
+Before proceeding:
 
−Task:
−Create a reproduction-first debugging plan for the frontend state bug. If editing is allowed, propose the smallest safe patch and regression checks.
+1. Identify missing, ambiguous, or conflicting inputs.
+2. Ask for clarification when the expected behavior is unclear, the reproduction could alter production or user data, credentials or secrets would be exposed, edit authority is absent, or allowed-file boundaries conflict with the likely fix.
+3. If bounded progress is safe, continue with an inspection or test plan while marking unresolved details as unknown. Do not silently convert assumptions into facts.
+4. Do not claim a repository, browser, application, file, command, selector, network response, or test was inspected unless Codex actually accessed or executed it in the current session.
 
−Output format:
+## Codex operating boundaries
 
−### 1. Bug Understanding
+Codex may inspect files available in its workspace, search call sites and state ownership, propose commands, edit authorized files, and run permitted local commands. It may use an available browser or test harness only when that capability exists in the environment. Browser behavior described only in the report remains supplied evidence, not a Codex observation.
 
−Summarize:
+Do not deploy, publish, merge, approve, commit, push, alter production data, use real customer data, bypass authorization, expose secrets, add dependencies, update lockfiles, change test tooling, or edit outside the allowed files without explicit authorization. Do not perform broad refactors while addressing a localized defect.
 
−* Reported issue
−* Affected route or component
−* Expected behavior
−* Actual behavior
−* User flow that triggers the issue
−* State involved
−* Known constraints
−* Missing inputs
+Stop and request human direction if reproduction requires destructive actions, privileged accounts, production-only access, security-control changes, irreversible data mutation, or a cross-boundary change involving authentication, authorization, billing, routing, API contracts, persistence, or shared infrastructure.
 
−### 2. Reproduction Steps
+## Investigation workflow
 
−Create precise reproduction steps.
−Include:
+### 1. Establish evidence and reproduction status
 
−* Starting page or route
−* Required data state
−* User actions
−* Expected visible result
−* Actual visible result
−* Browser/device considerations
−* Whether the issue is deterministic or intermittent
+Classify each relevant statement as one of:
 
−### 3. State Trace
+- Supplied fact: stated in the provided materials but not independently observed.
+- Code observation: directly supported by an inspected file and location.
+- Execution observation: produced by a command, test, browser run, log, DOM capture, screenshot, or network trace from this session.
+- Assumption: a bounded premise used to continue.
+- Hypothesis: a possible causal explanation awaiting a discriminating check.
+- Unknown or conflict: unavailable or inconsistent information.
 
−Trace the likely state transition from user action to visible bug.
−Include:
+Attempt reproduction only when the environment and permissions allow it. Record the route, fixture or account state, viewport, browser engine, initial URL and query parameters, storage or persisted state, actions, expected visible result, actual visible result, attempt count, and reproducibility rate. For intermittent defects, vary timing and repeat enough times to report a numerator and denominator rather than calling the issue deterministic.
 
−* State source
−* Initial state
−* User-triggered event
−* State update
−* Derived state or computed value
−* Rendered UI result
−* Where the transition appears to break
−* Evidence from code inspection
+Never invent selectors, fixture data, screenshots, traces, console output, or browser results. If execution is unavailable, provide a reproduction procedure and label it Not run.
 
−### 4. Root Cause Hypotheses
+### 2. Map state ownership and synchronization
 
−List likely causes ranked by confidence.
−For each, include:
+Inspect the smallest relevant path from the triggering interaction to the rendered symptom. Depending on the framework and implementation, examine:
 
−* Hypothesis
−* Supporting evidence
−* Counter-evidence
−* File or component involved
−* How to verify or disprove it
+- Component-local state, props, context, reducers, stores, composables, refs, reactive objects, selectors, and computed values.
+- Event handlers, form controllers, controlled versus uncontrolled inputs, default values, keys, component remounts, and lifecycle cleanup.
+- React effects and dependency arrays, stale closures, batched updates, transitions, Strict Mode double invocation, memoization, and server/client hydration.
+- Vue watchers, watch effects, computed dependencies, ref unwrapping, reactive identity, flush timing, keep-alive behavior, and component keys.
+- URL search parameters, router navigation, history state, localStorage, sessionStorage, IndexedDB, caches, server-state libraries, optimistic updates, and persisted-store rehydration.
+- Request ordering, abort handling, retries, debouncing, throttling, stale responses, race conditions, loading/error transitions, and cache invalidation.
 
−### 5. Observability and Debug Checks
+Construct a causal trace for each relevant variable:
 
−Recommend targeted checks such as:
+user action → handler → write or dispatch → asynchronous boundary → derived selector or computed value → persistence or URL synchronization → render branch → visible symptom.
 
−* Console/log points
−* Temporary assertions
−* React/Vue devtools checks
−* Network/state inspection
−* URL/query parameter checks
−* LocalStorage/sessionStorage checks
−* Cache or hydration checks
−* Screenshot or DOM checks
+At every edge, cite the inspected file and symbol or line range. Identify duplicate sources of truth, overwrite paths, initialization/reset paths, identity or mutation problems, stale reads, out-of-order writes, remounts, and feedback loops. Distinguish temporal correlation from demonstrated causation.
 
−### 6. Minimal Patch Plan
+### 3. Rank and test hypotheses
 
−If a fix is appropriate, propose the smallest patch.
−Include:
+Rank hypotheses by confidence and impact. For each one, provide supporting evidence, counter-evidence, the precise observation that would distinguish it from alternatives, and the least invasive check.
 
−* File to change
−* Logic to change
−* Why this is the smallest safe fix
−* Risks
−* What should not be changed
−* Rollback note
+Prefer targeted observability: focused test assertions, framework devtools inspection when a human can perform it, temporary local logging without sensitive values, DOM state, URL and storage inspection, request timing, trace files, or controlled delays. Remove temporary instrumentation before handoff unless retention is explicitly authorized.
 
−### 7. Regression Coverage
+A root cause may be marked Confirmed only when code evidence plus reproduction or a discriminating test demonstrates the causal chain. Otherwise use Probable, Plausible, Disproved, or Unresolved.
 
−Recommend or add targeted regression coverage.
−Include:
+### 4. Decide whether to patch
 
−* Test type
−* Test file
−* Scenario name
−* Given/when/then flow
−* Key assertions
−* Screenshot checks, if useful
−* Browser/device coverage, if relevant
+Before editing, state the proposed file set, causal mechanism, intended invariant, likely side effects, and why the change is smaller and safer than alternatives.
 
−### 8. Verification Commands
+Patch only if all of the following hold:
 
−List:
+- Editing is explicitly permitted.
+- The files are allowed, or approval has been obtained for a justified boundary expansion.
+- Evidence supports the targeted mechanism.
+- The fix preserves intended state ownership and synchronization rather than masking the symptom.
+- A verification path exists, even if it must be executed later by a human.
 
−* Existing test command
−* New or targeted test command
−* Build/lint command, if available
−* Manual verification steps if automated tests are not available
+Prefer correcting the faulty transition, dependency, initialization, ordering, cancellation, or synchronization rule. Avoid unrelated cleanup, architecture migration, selector churn, styling changes, and snapshot rewriting. Do not weaken assertions merely to make a test pass.
 
−### 9. Final Handoff
+Before editing, record a rollback method based on the exact files changed. If the suspected correction crosses an API, routing, persistence, authentication, or shared-store boundary, stop for human approval.
 
−Provide:
+### 5. Build regression coverage
 
−* Confirmed root cause
−* Patch summary
−* Tests added or recommended
−* Commands run
−* Results
−* Remaining risks
−* Human review checklist
+Choose the narrowest test level that proves the broken state invariant while retaining fidelity:
 
−Verification:
−Before finalizing, confirm that:
+- Reducer, selector, store, composable, or hook test for isolated transition logic.
+- Component test for event-to-render behavior and remount or prop synchronization.
+- Playwright or equivalent browser test for routing, storage, hydration, request ordering, pagination, navigation, or multi-component flows.
 
−* The bug reproduction is specific enough for another developer to follow.
−* The state trace explains how the visible bug happens.
−* The patch plan is minimal and directly tied to the root cause.
−* The regression checks fail before the patch and pass after the patch where tests can be run.
−* No unrelated frontend, backend, API, auth, payment, routing, or styling behavior is changed.
−* Any assumptions, missing inputs, and manual checks are clearly listed.
+Define the scenario as Given, When, Then. Assert the user-visible result and the state boundary responsible for it where observable. Avoid arbitrary sleeps; use stable user-facing locators and deterministic waits tied to navigation, requests, or rendered state. Mock only boundaries necessary for determinism, and state what realism the mock removes.
 
−Begin now. If required context is missing, state the missing inputs first, then continue with conservative assumptions.
+When feasible, demonstrate that the targeted regression test fails for the pre-patch behavior and passes after the patch. Preserve the actual command, exit code, and concise output for both states. If a safe pre-patch run cannot be produced, explain why and use other baseline evidence without claiming a red-green result.
+
+For browser-specific, hydration, or timing-sensitive bugs, define the relevant engine, viewport, server-rendered entry path, throttling or latency conditions, and repetition count. Use screenshots only when visual evidence adds value; do not substitute screenshots for state or behavioral assertions.
+
+### 6. Verify and reconcile
+
+Run only authorized commands. Verification should include, as applicable:
+
+1. The targeted regression test.
+2. The nearest existing component, store, or route test suite.
+3. Type checking and linting for affected files.
+4. A production build when the fix affects bundling, hydration, or framework boundaries.
+5. Manual reproduction using the same initial state and action sequence as the baseline.
+6. Relevant browser engines or device conditions identified by evidence.
+
+For every check, record status as Passed, Failed, Blocked, or Not run; include the exact command or procedure, environment, expected observation, actual observation, exit code when available, and evidence location. Reconcile failures instead of omitting them. Separate failures introduced by the patch from pre-existing or environment-related failures when evidence allows; otherwise leave attribution unresolved.
+
+Acceptance requires evidence that:
+
+- Another developer can reproduce or execute the documented procedure.
+- The causal trace connects the user action to the visible defect.
+- The regression check detects the faulty behavior or otherwise captures a justified baseline.
+- The post-patch flow preserves the expected state across the triggering transition.
+- Relevant neighboring behavior still passes, including navigation, reset, persistence, loading, error, and back/forward behavior where applicable.
+- No unauthorized file or behavior changed.
+- Remaining browser, timing, hydration, cache, or environment uncertainty is explicit.
+
+Use Fixed only when an authorized patch was applied and acceptance evidence passed. Use Patch applied, verification incomplete when code changed but any required check is blocked or not run. Use Proposed fix when no edit occurred. Never state tested, verified, approved, merged, deployed, or completed without corresponding execution evidence or human confirmation.
+
+## Required deliverable
+
+Produce the following sections.
+
+### A. Input and Authority Gate
+
+List available inputs, missing inputs, conflicts, repository capabilities, execution permission, edit permission, allowed files, prohibited actions, and the resulting work mode: Plan only, Inspect only, Edit without execution, or Edit and execute.
+
+### B. Evidence Ledger
+
+Use columns: ID, classification, claim or observation, source or command, file/location or artifact, and confidence. Keep supplied behavior distinct from session observations.
+
+### C. Reproduction Record
+
+Include environment, starting state, route, URL/query/storage state, fixture or account conditions, exact actions, expected result, actual result, attempts, reproduction rate, and evidence. If no run occurred, provide the procedure with status Not run.
+
+### D. State Transition Trace
+
+Use rows for trigger, state owner, pre-state, operation, asynchronous boundary, post-state, derived value, persistence or URL interaction, render effect, and evidence location. Mark the precise break point or unresolved edge.
+
+### E. Hypothesis Matrix
+
+Use columns: rank, hypothesis, status, supporting evidence, counter-evidence, discriminating check, result, and confidence.
+
+### F. Root-Cause Decision
+
+State Confirmed, Probable, Plausible, or Unresolved; describe the causal mechanism; cite evidence; identify alternatives not ruled out; and state what additional evidence would change the decision.
+
+### G. Minimal Patch Record
+
+If editing is authorized, list changed files, exact logic changed, invariant restored, why the patch is minimal, alternatives rejected, scope checks, risks, and rollback steps. Include a concise diff summary. If no edit occurred, label this Proposed fix and do not imply files changed.
+
+### H. Regression Specification
+
+Provide test level, test file, scenario name, Given/When/Then flow, deterministic setup, key assertions, relevant browser coverage, pre-patch expectation, post-patch expectation, and limitations.
+
+### I. Verification Matrix
+
+Use columns: check, command or procedure, expected observation, actual observation, status, exit code, and evidence location. Include blocked and not-run checks rather than deleting them.
+
+### J. Final Handoff
+
+Report the final state as one of: Diagnosed only, Proposed fix, Patch applied and verified, Patch applied with incomplete verification, or Blocked. Then list confirmed facts, unresolved items, changed files, commands actually run, observed results, remaining risks, rollback instructions, and a human review checklist. Explicitly state that deployment, merge, and approval did not occur unless separately evidenced.