A populated bug report survives a page change

Fixkamo-internal
Shipped
September 5, 2026 at 10:35 PM UTC
Author
Kamo
Commit
c45b385

Reported again: a fully filled-in bug/improvement window came back empty after switching to /hr, and again from the analytics nav icon. The window was never lost — it lives in the module-level store and is replayed from the per-tab snapshot — it came back BLANK, which from the member's side is the same bug being reintroduced for the third time. What a tool window comes back WITH is only its props. MessageTool has mirrored its draft into them since the compose window lost its first draft, and ChatTool, AiChatTool and SupportTicketWindow do the same. SystemBugReportWindow was added after those fixes and never opted in: every field was component-local React state, so any remount (an ancestor provider swapping element type) or document load (the allowlisted /logout, /validate and OAuth jumps, the /kb and DNS reloads, a failed chunk fetch, a deploy-skew MPA fallback, bfcache eviction) emptied it while the compose window beside it survived. Carry the report across a page change: - useToolWindowDraft mirrors a window's member-typed content into its props, debounced, and compares by value — patching props re-renders the window and rebuilds the draft object, so an identity check would dispatch forever. - The report window rides it with type, title, description, sites, the Publish switch and its staged files. Files survive a remount and cannot survive a document load, so their names travel too and the window says which ones to attach again rather than dropping them silently. - The edit fetch no longer lands the server's copy on top of an unsaved correction, and stays silent until it HAS the report — otherwise a remount during that fetch would restore a blank form and then refuse the real wording. - SEND TO AI is deliberately not carried, and its god default is not re-applied to a restored window. It starts a session on a machine holding cluster credentials; a switch that came back armed, or re-armed over a deliberate off, is exactly "sending something nobody meant to send". Keep it from happening a fourth time — every previous fix was correct and the next tool window shipped without it anyway, because nothing made the question unavoidable: - **************** fails the Docker build unless every tool in registry/tools.ts records one of three answers: it persists (detected in source, never merely claimed), it has nothing to lose (verified — a text field in its folder revokes it, unless marked `tool-window-draft: transient` beside the control with a reason), or it is a known gap naming what is at risk. A new tool window matches none of them and fails. - It still names four: softphone (dial number, call note), sms, social and the calculator's text converter. Those are real, smaller instances of the same defect, left for their own change because the state lives outside the dock. - 15 tests: the draft round trip through sanitizeProps, restore across a remount, the two switches' opposite treatment, the edit-window races, and the hook's no-feedback-loop property, which nothing else would notice breaking.

All changes

Like what you see shipping?

Every one of these updates lands in your workspace automatically. Start free and watch it grow week after week.

Start Free ForeverView Pricing