Bake-off 2B: Reproduce the target in Tauri and CodeMirror

[danielmrdev]

Parent

Part of #49.

What to build

Reproduce the approved Editorial Paper target in a disposable Tauri 2, SolidJS, and CodeMirror 6 prototype. A writer can interact with the same representative surfaces through the actual Linux system webview so visual fidelity, native behavior, process-tree cost, and development effort can be judged rather than inferred from a browser mock-up.

Acceptance criteria

• A real Tauri 2 host launches the prototype through the system WebKitGTK webview; the frontend uses strict TypeScript and a real CodeMirror Writing surface.
• The prototype matches the approved content, dimensions, tokens, Themes, and states used by the Floem lane.
• Paper and Ink, normal and narrow sizes, Document selector search/results/empty states, and General/Appearance Settings states are directly demoable.
• The integrated themed titlebar supports drag, double-click maximize/restore, minimize, maximize, close, focus, inactive, scaled, keyboard, and accessible-name states.
• CodeMirror verifies selection, clipboard, undo/redo, IME composition, soft wrap, scrolling, expected shortcuts, native context menu, Spellcheck suggestions without automatic mutation, App scale, and 1/10 MiB Documents.
• Frontend filesystem, shell, network, remote-content, and undeclared window capabilities remain denied.
• Simulated data is isolated from production Documents, Files, autosave, Preferences, and Typeface delivery.
• Implementation and debugging stop at the two-day candidate budget.
• Time, framework-specific code, dependencies, workarounds, edit-preview cycle, webview defects, and known platform limitations are recorded as evidence.
• The prototype remains disposable and does not remove or disable Floem.

Blocked by

• Bake-off 1: Approve Editorial Paper golden screens #50

Workspace

• Mode: parallel lane
• Branch: feat/49-ui-stack-bakeoff-52
• Worktree: /home/daniel/Projects/lettera/.worktrees/feat-49-ui-stack-bakeoff-52
• Integrates into: feat/49-ui-stack-bakeoff
• Remote policy: local only — never push
• Completion: when unblocked, create the lane from the latest integration commit; validate it, merge it locally into integration with approval, validate integration, remove the lane worktree, and delete the local lane branch

[danielmrdev]

Delivered: disposable Tauri 2 prototype merged into feat/49-ui-stack-bakeoff at 774217a. Lane worktree and local branch removed.

Artifacts

• prototypes/tauri/ — Vite + SolidJS + TypeScript + CSS Modules, src-tauri/ Tauri 2 host, README.
• Run: pnpm install && pnpm tauri dev (webkit2gtk-4.1 required; this machine 2.52.5).

What it reproduces (golden screens)

• Integrated themed titlebar: data-tauri-drag-region, double-click maximize, minimize/maximize/close through the Tauri window API.
• Writing surface: CodeMirror 6 (history + default keymap + highlightActiveLine + lineWrapping) themed with the Paper/Ink tokens — active line, caret, selection, first-line emphasis (visual only), Comfortable column, scrollbar on demand.
• Document selector: Kobalte Dialog (focus trap + Escape), search over the 8-card catalog, hover/selected cards, active File mark, loading/empty/no-results/error states, New Draft.
• Settings: Kobalte Dialog, Appearance category, Theme/Writing width/Letter spacing applying live, Typeface rows (Downloading spinner, Failed + Retry), Font size stepper, weights, disabled title-weight + persistence-error states.
• Empty Draft (Untitled), Paper/Ink via CSS variables.

Security posture

• capabilities/default.json grants only core:window controls (minimize, toggle-maximize, close, start-dragging, is-maximized). No fs, shell, http, or dialog plugins; no custom commands; bundle.active: false.
• The frontend no-ops outside the Tauri host so the same build renders in a browser for evidence (window controls become inert).

Verified

• Host builds and opens the undecorated 1280×800 window; the webview loads the app from the dev server (real WebKitGTK).
• Frontend verified in Chromium (same code): selector 720×560 with 8 cards, settings 860×600, F1–F4 / Shift+F1–F4 state cycling, theme toggle, search focus — all states confirmed via DOM checks.
• TypeScript strict + tsc --noEmit and vite build clean; Rust host cargo build clean.

Real finding for #53 (measurement)

• grim (Wayland capture) cannot read this WebKitGTK webview's composited GL surface on this machine — it hangs on the capture. The window renders fine, but compositor capture of the webview needs a different path (WebKit remote inspector, XWayland + X capture, or the webview's own snapshot API). This is a measurement-infrastructure finding, not an app defect, and must be resolved before Bake-off 3: Measure behavior, resources, and maintenance cost #53's screenshot protocol.
• App scale / display scaling and 1/10 MiB Document behavior are pending Bake-off 3: Measure behavior, resources, and maintenance cost #53 measurement, not claimed here.
• Implementation time this session ≈ 3 h including toolchain setup (pnpm 11 build-script policy, tauri-cli absent — host built with plain cargo).