Preserve the snapshot while review is pending
Select a work record only with its accepted revision and summary. When a new request arrives, require its own ID and requested revision, then show reopen-pending-review while retaining the accepted snapshot. React's useReducer reference describes an explicit state-transition boundary.
Run the local tests:
node --test sites/reactjsx.com/evidence/P153/reopened-request-state.test.mjs
They cover a preserved record, matching and stale results, a rejection that keeps the accepted revision, a second request while review is pending, and an unknown outcome. Correlation in this reducer does not establish trust; the service must decide whether reopening is allowed.
Announce status, not a presumed decision
W3C's ARIA22 status-message technique describes role="status" for updated status information. The illustrative component can announce that a baseline remains recorded, a request awaits review, a request was rejected, or the outcome is unknown. It does not announce approval before the trusted service says so.
The JSX is illustrative and still needs browser and assistive-technology review. A trusted backend must enforce authority, record retention, scope, and every transition.
Keep an unknown result actionable
If a matching result does not arrive, retain reopen-unknown and point the operator to reconciliation. Do not silently submit another request or substitute a new accepted revision.
For permission updates during an edit, see Handle Permission Changes During a React Form Edit. For preserving a draft through conflict, see Preserve a React Draft After a Save Conflict. For another review boundary, see Show a Missed-Appointment Recovery State in React.
Does this component protect the accepted record or authorize reopening?
No. It is a client-side state model. A trusted service must verify identity, authorization, history, scope, and the resulting transition.