Frontend State Bug Reproduction and Verified Minimal Fix

Investigate the supplied frontend state bug using a reproduction-first, evidence-controlled workflow. Diagnose before editing, preserve uncertainty, and make only authorized changes.

## Inputs

- 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]

## Input gate

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.

Before proceeding:

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.

## Codex operating boundaries

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.

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.

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.

## Investigation workflow

### 1. Establish evidence and reproduction status

Classify each relevant statement as one of:

- 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.

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.

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.

### 2. Map state ownership and synchronization

Inspect the smallest relevant path from the triggering interaction to the rendered symptom. Depending on the framework and implementation, examine:

- 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.

Construct a causal trace for each relevant variable:

user action → handler → write or dispatch → asynchronous boundary → derived selector or computed value → persistence or URL synchronization → render branch → visible symptom.

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.

### 3. Rank and test hypotheses

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.

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.

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.

### 4. Decide whether to patch

Before editing, state the proposed file set, causal mechanism, intended invariant, likely side effects, and why the change is smaller and safer than alternatives.

Patch only if all of the following hold:

- 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.

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.

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.

### 5. Build regression coverage

Choose the narrowest test level that proves the broken state invariant while retaining fidelity:

- 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.

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.

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.