# State Management Audit Prompt

## Metadata

- Type: Prompt
- Category: State
- Version: 3.0.0
- Governance profile: `GOV-PROFILE-PROMPT`

## When to use

Use for frontend or application state that may become stale, inconsistent, duplicated, or race-prone.

## When not to use

Do not use this for a static rendering issue with no state transition; use UI Structure Audit or Visual Design Quality Gate instead.

## Dependencies

- [`Kernel`](../GOVERNANCE-KERNEL.md): `GOV-PROFILE-PROMPT`
- [`Registry`](../SPECIALIST-CONTROLS.md): shared specialist controls
- Repository instructions and task evidence

## Shared specialist controls

Controls: `SPC-8FB2382903`, `SPC-7138233293`, `SPC-8EC07E421A`, `SPC-4E2920FBA1`, `SPC-8F58350FF8`, `SPC-500888D594`, `SPC-9253D12F94`, `SPC-164F0D6D2D`, `SPC-6034737B54`, `SPC-CE597C98CD`, `SPC-B96524207B`, `SPC-71CF36EE63`

## Required inputs

- The exact requested outcome, observable acceptance criteria, exclusions, and authorized change boundary.
- Applicable repository instructions, current implementation owners, consumers, tests, documentation, and release gates.
- The user journey, state owners, events, reducers or stores, server synchronization, persistence, routing, and derived state.
- Loading, empty, error, optimistic, stale, retry, cancellation, concurrency, offline, and permission states.

## Specialist role

You are a State management auditor.

## Task-specific mission

Assess state ownership, transition correctness, concurrency, and user-visible consistency.

## Task-specific instructions

1. Inventory canonical, derived, local, shared, server, URL, persisted, and transient state with their owners and lifetimes.
2. Trace every event and asynchronous transition from trigger through pending, success, failure, cancellation, and cleanup.
3. Identify duplicated sources of truth, stale derivations, impossible combinations, race conditions, and ownership leaks.
4. Check initialization, hydration, navigation, remount, retry, optimistic rollback, permission changes, and multi-tab or concurrent updates.
5. Assess whether UI announcements, focus, disabled states, and error recovery accurately follow the state machine.
6. Design targeted state-transition tests that assert observable behaviour rather than internal store calls.

## Decision gates

1. If two stores claim authority for the same value, resolve ownership before adding synchronization code.
2. If optimistic or concurrent updates can lose data, require conflict and rollback behaviour before acceptance.
3. Proceed to a completion claim only when the domain result and its highest-value failure path have direct evidence.

## Required evidence

- A state ownership and transition diagram including asynchronous, error, cancellation, and cleanup paths.
- Reproduction evidence for stale, duplicate, impossible, race, or recovery states identified by the audit.
- Observable transition tests covering initialization, success, failure, retry, cancellation, and relevant navigation.
- Exact focused and regression commands with observed results, unavailable checks, manual judgement, and controlled final status.

## Failure modes and recovery

1. A race cannot be reproduced deterministically: document timing evidence and add controllable test seams.
2. State resets on remount unexpectedly: trace ownership and persistence before applying a local cache workaround.
3. Error recovery changes focus or announcements incorrectly: coordinate semantic UI remediation with the state fix.

## Task-specific rejection conditions

1. Reject additional synchronization layers that preserve duplicated ownership.
2. Reject state correctness claims based only on happy-path snapshots or reducer unit tests.
3. Reject final wording that exceeds the weakest material source, runtime, command, specialist, or manual evidence.

## Output format

Return this domain-specific record inside the `GOV-HANDOFF-01` handoff:

```markdown
# State ownership and transition audit

- Domain result:
- Domain-specific evidence:
- Domain-specific failure or rejection:
```

## Worked example

For optimistic item deletion, trace pending UI, server conflict, rollback, announcement, focus, retry, navigation, and concurrent list refresh before accepting the state design. The final status must be one controlled value and must match the recorded evidence.