​
Project Model

Scritorio projects are local folders. Markdown is the source of truth, and app indexes are rebuildable. The default project shape is one book. A series is optional shared context layered above multiple books only when the author needs it.

​
Source Of Truth

Primary content should live in author-readable files:
  • manuscript drafts
  • book overview files and outlines
  • optional series bibles
  • flexible manuscript units, such as acts, chapters, sections, prologues, dedications, quotations, custom pages, and manuscript notes
  • beat sheets and other planning documents linked to manuscript units
  • research notes and source notes
  • citation records, bibliography notes, footnotes, and endnotes
  • fiction canon and worldbuilding
  • character and location dossiers
  • character soul.md files for in-character chat and voice grounding
  • timelines
  • book-level Editorial Board customizations
  • editorial reports
  • coaching assignments, submissions, reviews, and writer-profile notes
  • curriculum progress and module state
  • visual prompts, cover concepts, illustration notes, and asset notes

​
Book-First Shape

A standalone book project should be understandable even outside Scritorio: 
MyBookProject/
  book.md
  story.yml
  scritorio.project.json
  manuscript/
    act-a552eb2e.md
    act-a552eb2e/
      chapter-c3960842.md
      chapter-c3960842.notes.md
      chapter-c3960842.beat-sheet.md
  codex/
    characters/
    locations/
    organizations/
    items/
    concepts/
    events/
    style/
  notes/
  assets/
  exports/
  .scritorio/
See Book Filesystem Layout for the concrete v1 path contract, sidecar naming rules, and metadata examples. Scritorio should not require every folder on day one. Authors should be able to start with a manuscript, a character note, a source note, a cover concept, or any other useful file. The scaffolded folders are defaults for navigation and discovery, not gates. The left sidebar should be built from the indexed Markdown structure. For a fiction book, labels may emphasize Characters, Places, World Knowledge, Canon, Acts, Scenes, and Assignments. For a nonfiction book, the same underlying model may surface People, Subject Knowledge, Claims & Arguments, Sections, Sources, Bibliography, Notes, Assignments, and Index work. Assignments are saved coaching work, not transient chat messages. The default assignment area may group files by status: 
coaching/
  profile.md
  curriculum-progress.md
  assignments/
    active/
    submitted/
    reviewed/
    completed/
An assignment should remain readable outside Scritorio as Markdown. Front matter may store status, craft focus, linked manuscript unit, and review state, while the body stores the prompt, constraints, author submission, coach feedback, and revision notes. Curriculum packs may be app-managed or account-managed content, especially if they are paid modules. The author’s local project should store progress, assignments, submissions, revisions, and feedback, not a required copy of the full curriculum product. Major Codex entries should have product-defined fields for common workflows and optional author-defined custom fields for book-specific metadata. See Codex Schema And Character Souls.

​
Flexible Manuscript Units

Scritorio should support acts without requiring them. The core manuscript model is a flexible manuscript_unit, not a fixed act/chapter/scene hierarchy. Current author-facing v1 unit types should include:
  • act
  • chapter
  • section
  • note
  • prologue
  • dedication
  • page
  • quotation
Older or imported unit types such as part, appendix, front_matter, and back_matter may still be recognized for compatibility, but they are not the preferred v1 creation surface. Units may be represented by Markdown files, folders with Markdown files inside them, or front matter relationships. A fiction author might organize a book as acts containing stable-id chapter files. A nonfiction author might use chapters and sections. Another author might begin with one long manuscript file. All of these should remain valid as import shapes, while app-created units should follow the current filesystem layout. Chapters are first-class manuscript units. A chapter may live at the manuscript root or inside an act folder. Act and chapter filenames are stable storage ids such as act-a552eb2e.md and chapter-c3960842.md; they are not act or chapter numbers. The displayed chapter number is derived by sorting included manuscript units by order and counting only unit_type: chapter files. The YAML title property is reserved for a real author-supplied chapter title, not generic labels such as Chapter 1.

​
Beat Sheets And Planning Documents

Beat sheets should be first-class linked planning documents. A common shape is: 
manuscript/
  act-a552eb2e/
    chapter-c3960842.md
    chapter-c3960842.notes.md
    chapter-c3960842.beat-sheet.md
chapter-c3960842.md is manuscript content. chapter-c3960842.beat-sheet.md and chapter-c3960842.notes.md are planning sidecars. Beat sheets and chapter notes should be indexed, searchable, previewable, repairable, and available to coaching or editorial context, but excluded from assembled manuscript prose unless the author explicitly includes them as manuscript units. Chapter notes may have a sibling collection directory such as chapter-c3960842.notes/ for captured Editorial Board notes and related note cards. The index sidecar and collection directory should move together. Front matter may make these relationships explicit: 
---
type: manuscript_unit
unit_type: chapter
pov: Adrian
order: 2000
include_in_manuscript: true
---

---
type: beat_sheet
for: manuscript/act-a552eb2e/chapter-c3960842.md
beat_model: custom
---
Future workflows may generate, critique, compare, or revise beat sheets before prose drafting, but the author remains in control of whether planning material becomes manuscript text.

​
Optional Series Shape

Series support should be available without making every author start inside a series container: 
MySeriesProject/
  series.md
  shared/
    characters/
    places/
    organizations/
    timeline/
    concepts/
    knowledge/
    style/
  books/
    book-1/
    book-2/
For series projects, Scritorio should distinguish series-level material from book-level material. Shared series canon, timelines, and style rules may apply across books, while each book retains its own manuscript, reports, metadata, Editorial Board customizations, and export settings.

​
Wastebasket

Removing a book or series from the library should move the folder into a Scritorio Wastebasket first, not permanently delete it. Emptying the Wastebasket is a separate destructive action that should require explicit confirmation. The Wastebasket should preserve enough metadata to support future restore flows:
  • original path
  • project kind
  • title
  • trashed timestamp

​
Markdown And Front Matter

Markdown files should be portable and readable in other tools. YAML front matter can identify file type, title, point of view, chapter, topic, tags, sources, canon dependencies, or visual relationships. Scritorio should support Markdown footnotes where the chosen Markdown parser/export path allows them. Footnotes, endnotes, source notes, and bibliography entries should remain readable local content, not opaque database-only records.

​
Indexes, Footnotes, And Bibliographies

Nonfiction authors need book-production support for scholarly and reader-navigation material. Scritorio should eventually support:
  • author-curated index entries
  • suggested index terms extracted from manuscript text
  • generated draft indexes with page or section targets once an export format exists
  • bibliography records and source-note files
  • footnotes and endnotes in Markdown-compatible form
  • citation/source coverage checks
  • links between claims, notes, citations, bibliography entries, and manuscript passages
The first goal is not final print layout. The first goal is to preserve the author’s source trail and make index/bibliography work visible, reviewable, and portable.

​
SQLite As Cache

SQLite should be an index and cache, not the canonical manuscript store. It can store:
  • file paths
  • file types
  • titles
  • content hashes
  • modified times
  • parsed front matter
  • product-defined and author-defined Codex fields
  • character soul file paths and derived voice metadata
  • object records derived from Markdown files
  • manuscript unit records derived from Markdown files and front matter
  • parent-child manuscript relationships and ordering
  • linked planning documents, including beat sheets
  • series and book relationships
  • search indexes
  • generated navigation state
  • backlinks and explicit cross-file links
  • report references
  • extracted mentions
  • unresolved issue references
  • source and citation references
  • index term candidates
  • footnote, endnote, and bibliography references
  • visual asset metadata
  • cover, illustration, page, spread, and chapter-art relationships
  • embeddings or semantic search metadata later
If .scritorio/index.sqlite is deleted, it should be rebuildable from the local project folder. Core author content must never exist only in SQLite.

​
Example Vault

The repo includes examples/the-long-silence/ as a real sample project. It should help test fiction workflows, canon checks, style checks, and continuity checks. It should not define the only supported project shape.