01 / 15 · Solution Intent
Why this workspace exists
Use existing cloud files of several GB in notes, add annotations and write regular Markdown notes without uploading files twice.
Problem and target user
Primary user: Ernst.
I, Ernst, want to use files of several GB that are already in my cloud storage directly in notes and add annotations to them. I also want to write regular notes in Markdown. My files and notes must stay in the cloud, so I do not have to upload the same file separately to a note app and a cloud service.
Architecture and infrastructure
The first diagram shows the components that make up FileLoveNote. The second shows where they run and how they connect. The diagrams show the intended setup for Ernst, with Drive storage active.
1 · Solution architecture
2 · Infrastructure architecture
Legend: solid connections are part of the core setup. Dashed connections and boxes are optional. Arrows show the direction of data exchange; two arrowheads indicate traffic in both directions.
Readable notes are stored in the browser and, when you use Drive, in your own Google Drive. The server processes text only temporarily. It may temporarily hold an encrypted packet for transfer; a receipt ticket does not yet confirm that the text is in Drive. Media, canvas and technical metadata have their own storage contract.
The technical storage and sync rules are described in the Solution Design.
Desired outcomes
| Goal | What the user experiences | Evidence |
|---|---|---|
| SI-01 · Annotate files | Use existing cloud files of several GB directly in notes and add annotations to them. | US-01, US-03, US-09, US-11; V02, V03, V16 |
| SI-02 · Continue immediately | An existing browser copy opens without waiting for Drive. | US-02, US-05; V02, V08 |
| SI-03 · Keep your writing | Local work survives outages and conflicts. | US-05, US-06, US-07; V07–V10 |
| SI-04 · One cloud service | Files and Markdown notes remain in your own cloud storage; an existing source file does not need to be uploaded again to a note app. | US-05; V07 |
| SI-05 · Rebuild independently | Another person can build and verify the chosen scope using this package. | P00–P05 and P07; the included verification scenarios where applicable |
Core journey: one existing source, one note
Connect Drive → choose an existing GB-sized file with /drive → insert one reference at the saved cursor → write annotations in the note → save locally and sync → reopen the same note and original source. Insertion does not upload or copy the source bytes. This flow is mandatory for FR-17 in P03/P04; V16/A01 verifies it. Missing Drive configuration permits local writing but leaves the live source-flow criterion open.
See the complete core flow and measurable acceptance targets.
Scope
The browser cache supports quick opening, offline editing and keeping pending changes. In the intended setup, files and notes are stored in the user’s own Google Drive after synchronization. Google Drive is the only external file storage provider.
- Web core: secure sign-in, personal notes, ProseMirror editor, Markdown, folders, local storage, search, file library, inserting existing Drive sources at the cursor, annotating them in notes and automatic two-way sync with Google Drive.
- Full web app: spatial canvas, AI on request, YouTube, transcripts and advanced account reset/deletion. Core settings, source references and the Drive picker are already mandatory.
Boundaries and deliberate choices
- No productivity system with deadlines, progress scores, streaks or motivational messages. A task list in the editor is text, not a workflow.
- No social network, public document library or collaborative real-time editor.
- No readable note archive on the app server. Media, sessions, accounts and technical metadata have a different storage contract.
- No absolute promise that text can never be lost. Cleared browser data, lost devices and unconfirmed writes have real limits.
- No mandatory AI or cloud connection for local writing. Without active Drive storage, notes do not sync between devices.
- No automatic production release. The product is offered as a proof of concept, without an SLA or backup promise.
Product and language principles
Use clear, plain English. For example, write New note, Move, Saved locally and Try again. Show the storage status honestly. Technical terms such as an etag do not belong in everyday error messages.
Use calm typography, generous spacing and little visual clutter. Use 1:1.618 as a guide for proportions and whitespace. A desktop layout can use a 38.2% / 61.8% split; on mobile, readability takes priority over a fixed ratio. Touch targets are at least 44 × 44 pixels. Support light and dark themes, keyboard use, visible focus and restoring focus after a dialog.