​
Technical Architecture

Scritorio should be local-first and portable.

​
Initial Stack

  • Tauri desktop app
  • Svelte
  • TypeScript
  • CodeMirror 6 for Markdown editing
  • Rust/Tauri commands for local file access
  • SQLite with FTS5 for local indexing
  • Markdown files with YAML front matter
  • product-defined and author-defined Codex fields
  • character soul.md files for voice-grounded character chat
  • Markdown-compatible footnotes and endnotes
  • AI provider abstraction
  • Image-generation provider abstraction
  • Audio-generation provider abstraction
  • Supabase-backed account, authorization, entitlement, plan, and usage state
  • Cloudflare Worker managed AI gateway
  • Agent-friendly CLI installed with the app
  • Export and layout pipeline later
  • Optional Git integration later

​
Stack Diagram

​
Local-First Architecture

The app opens a local project folder and works from files on disk. Markdown files store the book and project knowledge. SQLite stores searchable indexes and rebuildable metadata. Reports and visual asset notes are saved back into the project. The project model should default to a standalone book. Series workspaces should be optional and explicit, with series and book relationships stored in local project files and indexed for fast navigation and scoped context retrieval. The concrete book filesystem contract is documented in Book Filesystem Layout. At a high level, a book root contains book.md, story.yml, scritorio.project.json, manuscript/, codex/, supporting folders such as notes/, assets/, and exports/, and app-owned .scritorio/ state. SQLite should be treated as a sidecar under .scritorio/index.sqlite. It may cache file paths, file kinds, titles, content hashes, modified times, parsed front matter, derived objects, manuscript units, beat-sheet links, chapter-note links, planning documents, links, mentions, report references, and generated navigation state. It should be safe to delete and rebuild from Markdown.

​
Live Manuscript Context

Time-aware character chat uses author-owned source files directly. Scritorio resolves the selected story moment from manuscript order, gathers bounded manuscript prose through that boundary, and combines it with the selected character dossier and soul. There are no generated chapter-state or character-snapshot files to refresh. The desktop app uses this basic data flow: When an older Scritorio project is opened, generated story-state artifacts may be removed from state/chapters/, state/characters/, generated state/README.md, and generated timeline/events.yml. Author-owned manuscript, codex, notes, assets, exports, manifests, sidecars, and .scritorio metadata are preserved. SQLite FTS5 should support fast literal search:
  • names
  • terms
  • claims
  • source references
  • citations, footnotes, bibliography entries, and index term candidates
  • project concepts
  • scene or chapter mentions
  • beat sheets and linked planning documents
Semantic search and embeddings can come later.

​
AI Provider Layer

AI features should call through provider interfaces rather than direct UI calls. Initial provider areas:
  • text review and coaching
  • source-aware retrieval and summarization
  • image generation
  • audio generation and narration assembly
  • optional embeddings later
Provider configuration should handle model names, credentials, cost display, and capability differences. Audio providers should be treated as interchangeable integrations. Provider profiles should capture capabilities such as voice IDs, narrator and character voice support, pronunciation controls, streaming or batch generation, output formats, costs, and limits. ElevenLabs may be an important provider for polished narration, but the core model should not depend on one vendor.

​
Account And Managed AI Backend

Scritorio uses Supabase as the backend database and account system. Supabase owns account creation, login, authorization identity, profiles, subscription and entitlement records, managed AI plan rows, and the managed AI usage ledger. The desktop app uses only public Supabase configuration and a public managed AI gateway URL. It never receives the Supabase service role key or Scritorio’s OpenAI API key. Managed AI text calls go through a Cloudflare Worker: 
desktop Supabase session
  -> Cloudflare Worker /v1/ai/responses
  -> Supabase JWT verification through JWKS
  -> Supabase plan and usage tables
  -> OpenAI Responses API
  -> Supabase usage ledger
  -> normalized Scritorio response
The Worker exposes POST /v1/ai/responses and GET /v1/ai/usage/me. The app sends a Scritorio feature id such as chapter_summary or act_summary, local project/document identifiers, and feature-specific input. The Worker owns model selection, prompt construction, validation, quota checks, cost estimation, usage logging, and normalized error responses. Cloudflare AI Gateway may be configured between the Worker and OpenAI for provider observability and routing, but Scritorio’s Worker remains the product gateway because it owns authentication, quotas, and feature policy. See Managed AI Gateway.

​
Publishing And Export Architecture

Publishing workflows should be built as transformations from local project files, not as a separate source of truth. Long-term export areas:
  • assembled manuscript generation
  • manuscript assembly that excludes beat sheets and planning documents by default
  • print-ready PDF generation
  • EPUB generation
  • ebook validation and packaging
  • audio-version planning, voice assignment, clip generation, review, and assembly
  • layout templates and style profiles
  • vendor-specific export profiles
  • preflight validation
  • export logs and reports
IngramSpark should be treated as an important self-publishing target, but the architecture should support multiple export profiles rather than baking one vendor into the core model.

​
CLI Architecture

Scritorio should include a first-class CLI that shares core project logic with the desktop app. The CLI should cover the same underlying capabilities as the UI over time:
  • project inspection
  • book inspection
  • optional series inspection
  • indexing
  • search
  • context preview
  • editorial reports
  • reader reactions
  • writing coach workflows
  • visual prompt and asset workflows
  • bibliography, citation, and index support
The CLI should support --json for structured stdout, send logs and progress to stderr, and provide dry-run or preview modes for actions that write files or send content to AI providers.

​
File Watch And Indexing

Scritorio should eventually watch project files for changes and update its local index. The index should be rebuildable from disk whenever needed.

​
Current Scaffold

This repository currently contains product documentation, an example project, and the first runnable scaffold:
  • apps/desktop for the Tauri, Svelte, TypeScript desktop app
  • packages/cli for the Bun-powered CLI
  • packages/core for shared TypeScript project conventions
  • packages/schema for shared SQLite migrations
The scaffold proves the architecture without implementing full editing, AI review, publishing, or visual-generation workflows yet.