Make the Rich Text lens discoverable as a guided 'Rich Document' workflow

[accesswatch]

Source

Jarte comparison research (docs/planning/jarte.md, §3 "Direct rich-document editing as the default experience"): Jarte sits directly on Windows' RTF engine, so fonts, color, paragraph formatting, pictures, and Word/WordPad compatibility are the default experience, not an opt-in layer. QUILL's main path is plain text/Markdown with formatting carried through invisible codes or the optional Rich Text lens — elegant for screen-reader-first authoring, but less of a direct WordPad replacement for someone who doesn't want to learn Markdown or export semantics.

Current state in QUILL

The Rich Text lens already exists as a real, gated feature: core.rich_text_lens in quill/core/feature_catalog.py (~line 149), wired to the view.switch_editing_lens command (quill/core/feature_command_map.py), and referenced in quill/core/settings.py (~line 595, noting it's "locked_off" under at least one profile). This is not a build-from-scratch feature — it's a discoverability and onboarding gap on top of something that already works.

Proposed approach

• Surface "Rich Document" as an explicit, named onboarding choice (in the first-run wizard and/or a profile-adjacent setting) for users who want WordPad-like editing without learning Markdown, Illuminations, or conversion semantics — framed in plain language, not as "enable the Rich Text lens feature flag."
• Audit which profiles currently lock core.rich_text_lens off and confirm that's still the right default now that it's being promoted as a first-class path for some users.
• Add a clear, in-context "Switch to Rich Document view" affordance (menu + command palette) for users already in a plain-text session who want to convert to this workflow, not just a first-run choice.

Non-goals

• Not changing the underlying Markdown-with-invisible-codes architecture or making Rich Text the new default for everyone — this is about discoverability and framing for the subset of users who want it, not a wholesale philosophy change.

Priority rationale

Medium impact (helps a specific onboarding segment) with high confidence — the hard part (the lens itself) already exists and is production code; this is UX/discoverability work on a known-working feature.

[accesswatch]

Adding an honest caveat on priority, prompted by a broader re-check of this whole batch against "QUILL is screen-reader-first, does it already meet people where they are."

The Rich Text lens itself checks out as real (core.rich_text_lens in quill/core/feature_catalog.py, wired to view.switch_editing_lens) — that part of my research holds. But I want to be direct about who this actually serves: QUILL's plain-text/Markdown-with-invisible-codes default is the screen-reader-optimized design, not a compromise on the way to a "real" rich-text mode. Promoting a "Rich Document" workflow mainly serves a secondary audience — low-vision users, sighted co-authors, or people who came from Word/WordPad and want familiar visual editing — not the core blind/keyboard-first user QUILL is built around first.

Not closing this — that audience is real and worth serving, and the underlying feature already exists and works, so the cost of improving its discoverability is low. But I'm downgrading my own confidence that this deserves its current mid-table priority; it's a reasonable "nice to have for a real secondary audience," not a core-mission gap the way Print Studio or the alt-text work (#899) are. Leaving final call to whoever picks up the backlog.