Close Run
What the Screen Is For
The run page lets staff inspect execution and the evidence of a successful close. Failed requests expose recovery controls, although their actual eligibility is decided by the service.
What It Shows and Lets People Do
The header describes the request’s current outcome. Ordered steps show attempts, timing, errors and produced-record links, and an expandable event log shows available history. Successful closes load the retained record and can link the current following month or offer an authorized reopen. Reopen success and cancellation have their own panels. The run response includes binding readiness, but the page does not render a separate checklist from it.
States and Errors
The hook polls every two seconds only while the run is queued or running. Polling stops at close finalization even if calendar maintenance continues. A failed panel renders Retry and Cancel without action-permission or structured recovery-eligibility gating; the service can refuse either. The panel’s retained-state statement and cancellation’s reversal promise are inaccurate for some outcomes. A missing run shows Try Again and navigation back.
Patterns It Must Respect
The page uses PageLayout and PageHeader, the inherited read-permission guard, task status icons, outcome panels, Collapsible event history, an AlertDialog for cancellation and the shared reopen dialog. Existing component patterns are the implementation evidence.