foolish-bandit/gary: frontend drafting shell with 8 document types
Commit `7c520d4f` adds a `/draft` page that mirrors the `/review` shell: a guided two-step UI for drafting legal documents entirely on the frontend, with no backend changes. The home "Draft Something" card is rewired from `/workflows` to `/draft`.
The flow presents eight document type cards -- Email, Letter, Memo, Clause, Summary, Demand letter, Client update, Custom draft -- each with a plain-English description and a type-specific opening line. Selecting one advances to a details step: a description textarea, optional Audience and Tone fields, and an optional document attachment via uploadStandaloneDocument. Clicking "Start Drafting" assembles a prompt and routes to /assistant/chat/{id}.
The assembled prompt follows a fixed structure: the type's opening line, then the user's description under "What I need:", then any audience/tone metadata, then a hardcoded tail instruction that tells the model to be practical, not invent facts, and flag missing information. That tail is defined as DEFAULT_INSTRUCTION in the page file -- it lives in the frontend, not in any backend config.
The page is 562 lines and the only other change is a single line in InitialView.tsx. No new backend routes, no new API surface, no changes to streaming or citations -- all of that falls out from the existing useAssistantChat hook. Each draft ends up as an ordinary chat thread in Assistant History.
One detail worth noting: the error path when handleNewChat returns no chat ID surfaces a generic "Could not start the draft. Try again." message (later swapped to a backend-unavailable string in the next PR). If you're adopting this without a connected backend you'll hit that path immediately.
Spotted something wrong? Or know the PR text has fresher detail than the writeup above?