[Enhancement] mobieusKnow: Long-form editor has no draft state or autosave — work is lost on accidental navigation

Area: mobieusKnow (audit p6) · Surface: /know/new, /know/{slug}/edit · Dimension: ui-ux · Severity: major

Notion, Confluence, Slab, and LearnWorlds/Teachable lesson editors autosave continuously and keep drafts, so long-form authoring never loses work. mobieusKnow's editor encourages long articles (full markdown toolbar, image upload, 500px+ body) but has no safety net: any accidental back-navigation, tab close, or session expiry discards everything. This is a data-loss-grade UX gap that directly suppresses contribution — the exact opposite of what a community-built KB needs. At minimum a localStorage draft restore, ideally a server-side draft revision state with periodic autosave.

Evidence

Editing is single-shot: store()/update() write straight to a pending or approved revision (KnowledgeController.php:160-179, 228-244); the revision status enum is only pending/approved/rejected/rolled_back (schema.sql:3457) — there is no 'draft'. The editor JS (editor.php:221-509) handles word count, image upload, Ctrl+Enter submit, and AI tools but never persists in-progress content; there is no localStorage cache and no autosave POST. A reader who navigates away, refreshes, or whose session times out mid-edit loses the entire body, which for a wiki editor (min-height 500px textarea, editor.php:20) can be a lot of work.

Suggested fix. Add localStorage autosave/restore keyed by slug as a quick win (warn-and-restore on reopen), and a 'draft' status on knowledge_revisions for true server-side drafts that don't enter the moderation queue until explicitly submitted. Add a beforeunload guard when the body is dirty.

Filed by the automated tenant-app audit and adversarially evidence-verified. Status: verified. Open — not yet actioned.