AI Action Review Queue with Decision Receipts

Build Gatehouse, a responsive AI action review desk for an operations lead who must understand a proposed change before recording a decision. Return one complete standalone HTML document with internal CSS and JavaScript, no framework, external assets or network requests. Implement the working interface, not another brief. All records are fictional and all decisions stay in page memory; no action executes, no agent is contacted and nothing is saved to a server.

Inputs and customization: expose BRAND, REVIEWER and REQUESTS as clearly named constants. Defaults are Gatehouse and Mira Chen. Each request has id, title, agent, risk, exposureUSD, before, after, evidence, guardLabel, guardRequired and blockedReason. Use exactly these five fictional records, initially Needs review, with blank notes and unchecked guards:
- AP-4829: Reroute 38 frozen orders; HarborPilot; High; 72460; before “FrostPeak Logistics · Dock 12 · 15:40”; after “Northline Refrigerated · Dock 4B · 14:25”; evidence “Lane audit attached; trailer pre-cool confirmation missing”; guard “Require temperature telemetry”; required true; no block.
- AP-4830: Review short-pay notice; PayablesGuard; Medium; 18240; before “Invoice INV-220 held for review”; after “Prepare a short-pay notice for invoice INV-220”; evidence “Invoice and delivery receipt attached”; guard “Request finance countersign”; required false; no block.
- AP-4831: Accept substitute lane bid; LaneBuyer; Medium; 31100; before “ORD to DEN · primary carrier unavailable”; after “ORD to DEN · reserve carrier bid”; evidence “Bid sheet attached; capacity confirmation pending”; guard “Verify carrier capacity”; required true; no block.
- AP-4832: Review customer credit batch; CXClose; Low; 6920; before “16 service cases awaiting resolution”; after “Prepare credits for 16 fictional accounts”; evidence “Case summary attached”; guard “Require supervisor review”; required false; no block.
- AP-4833: Correct customs classification; BorderOps; High; 112300; before “214 line items awaiting classification review”; after “Proposed corrected classification for 214 line items”; evidence “Broker countersign missing”; guard “Require broker countersign”; required true; blockedReason “Broker countersign is missing. Approval is unavailable.”
Amounts describe fictional affected value, never savings or revenue. To adapt the prompt, replace the records and evidence, reviewer name, labels and palette; preserve the data-to-detail/decision mapping and distinguish a review condition from verified evidence. No invented trust scores, testimonials, live sync, countdowns, immutable logs or signed records.

Art direction: a calm, dense but readable editorial desk. Warm ivory #f5f3ed, near-black ink #172629, white panels, deep teal #08685e and rust #a13d25 for warnings. Use system sans, mono only for IDs/amounts, a 36–44px main title and 14–16px body. A narrow brand bar says “Local simulation”. Below a strong “Review before release.” heading, a restrained summary strip shows computed Pending count and Pending exposure. Use a two-column queue and detailed review sheet on desktop, with fine rules and clear alignment instead of decorative dashboards or repeated metric cards. The signature visual is the explicit Before / Proposed change comparison and a decision receipt tied to that request. No gradients, avatars, decorative charts, pseudo-technical filler or motion delays.

The queue starts with AP-4829 selected. Search requests by ID, title or agent, case-insensitively and trimmed. Combine search with a labeled native status select: All requests (default), Needs review, Approved, Rejected, Amendment requested. Each queue item is a real button with visible id, title, risk, dollar exposure and status; communicate selection accessibly. Counts and pending exposure always derive from records, not filtered rows. Initial pending count is 5 and exposure $241,020. Show “N of 5 requests”. Search with no matches presents a useful empty state and “Clear filters”, removes stale detail/actions, and restores a matching selection when filters clear. If the selected request disappears, choose the first visible request. On deliberate row selection at mobile, scroll/focus the detail heading; typing search must not steal focus. Never hide risk, value or status on mobile.

The detail heading and all content must match the selected ID. Display agent, fictional exposure, risk, before/proposed change, evidence text, and any block reason. No evidence-link controls unless they work. For each pending request, show its unchecked native guard checkbox and a labeled Review note textarea. Preserve each request's unsaved note and checkbox when switching rows. Require a trimmed 10–280-character note for Approve, Reject and Request amendment; show an associated specific error and focus the note while preserving invalid input. Approval additionally requires the guard when guardRequired is true; its checked state means a requested condition, not evidence already verified. Show the missing-guard error clearly and focus its checkbox. AP-4833 approval stays disabled with its block reason; rejection and amendment remain available with valid notes. Optional guards may remain unchecked, and their exact Yes/No state must be recorded.

A valid decision begins a deterministic 500ms “Recording local decision…” state. Disable decision actions and selection/filter controls during it to avoid target races. Success changes only that request's status, updates computed pending totals, and creates exactly one visible receipt with request ID, decision, reviewer, trimmed note, the guard label and Yes/No value. Clearly say “Recorded in this page only. No action executed.” Show a compact session decision list whose entries can reopen their request. Resolved requests are read-only; selecting them displays their own receipt and never allows a second decision. If a Needs review filter removes a resolved request, keep its just-recorded receipt visible in the session list and select the next visible request; all resolved under this filter yields a truthful empty state.

Provide quiet expandable Demo controls: “Fail next decision” and “Reset demo”. A simulated failure consumes that toggle once, changes no record/count/receipt and retains the note/guard. Show “Could not record this local decision. Your review is still here.” and a “Try again” button that repeats the same decision with the same draft. Reset is usable during loading, cancels pending callbacks, clears all receipts/drafts/filters/errors and restores the five exact initial records. Reload also restores defaults. Clearly state that decisions are lost on reload. Use no persistence or identity capture.

Accessibility and responsive constraints: native labels and controls, one h1 with ordered h2s, persistent polite live region for meaningful status changes, clear keyboard focus, at least 44px action targets and textual state cues. Below 850px, stack queue then detail in DOM order without a fixed footer or horizontal scrolling. At 1440×900 show useful queue and decision controls without tiny text. At 1024, 768, 390 and 320px preserve complete readable rows, wrapping copy and reachable actions. Reduced motion and Save-Data keep every interaction; no animation is needed. Mark the settled document data-preview-ready. Include a quiet “View source prompt” link to /prompts/app-dashboards-ai-agent-approval-queue-ui-prompt-20260731-free/.

Acceptance checklist: (1) each row presents its own exact change/evidence; search plus status filtering and clear recovery work; (2) per-request drafts survive selection, whitespace/short/long notes fail without loss, and required guards block approval; (3) approve AP-4829 with a note and guard produces exactly one matching receipt, pending 4 and $168,560; (4) reject and amendment produce distinct states/receipts, optional unchecked guards record No, blocked approval never succeeds; (5) failure/retry records once with the original intended action, reset during loading cannot create a late receipt, and reload resets everything; (6) every state remains keyboard usable at all five widths with no clipping, runtime errors or external requests. Use honest local-demo language throughout.