1
0

vault backup: 2025-12-23 22:52:59
All checks were successful
Deploy Quartz site to GitHub Pages / build (push) Successful in 3m10s

This commit is contained in:
2025-12-23 22:52:59 +01:00
parent 534d987d6d
commit 67c3507f3a
4 changed files with 214 additions and 34 deletions

View File

@@ -6,7 +6,6 @@
{
"id": "8dd584e60438200b",
"type": "tabs",
"dimension": 58.22050290135397,
"children": [
{
"id": "b6de1b6650c09ff3",
@@ -24,27 +23,6 @@
}
}
]
},
{
"id": "1ce7592fbb71e315",
"type": "tabs",
"dimension": 41.77949709864603,
"children": [
{
"id": "063c080eabc776aa",
"type": "leaf",
"pinned": true,
"state": {
"type": "pdf",
"state": {
"file": "Anatomi & Histologi 2/Gamla tentor/2024-01-10/!2024-01-10-0088-KOM.pdf"
},
"pinned": true,
"icon": "lucide-file-text",
"title": "!2024-01-10-0088-KOM"
}
}
]
}
],
"direction": "vertical"
@@ -215,12 +193,12 @@
},
"active": "b6de1b6650c09ff3",
"lastOpenFiles": [
"z-Tech/Lecture tracking.md",
"z-Tech/Mega Mega.md",
"z-Tech/Quiz-app.md",
"Anatomi & Histologi 2/Statistik.md",
"Anatomi & Histologi 2/Gamla tentor/2024-01-10/30.md",
"Anatomi & Histologi 2/Gamla tentor/2024-01-10/!2024-01-10-0088-KOM.pdf",
"z-Tech/Mega Mega.md",
"Anatomi & Histologi 2/Statistik.md",
"z-Tech/Lecture tracking.md",
"z-Tech/Quiz-app.md",
"Anatomi & Histologi 2/Gamla tentor/2024-01-10/30.md",
"Anatomi & Histologi 2/Gamla tentor/2024-01-10/29.md",
"Anatomi & Histologi 2/Gamla tentor/2024-01-10/28.md",
"Anatomi & Histologi 2/Gamla tentor/2024-01-10/27.md",
@@ -242,7 +220,6 @@
"Anatomi & Histologi 2/Gamla tentor/2024-01-10/11.md",
"Anatomi & Histologi 2/Gamla tentor/2024-01-10/10.md",
"attachments/image-48.png",
"Anatomi & Histologi 2/Gamla tentor/2024-01-10/9.md",
"Biokemi/Plasmidlabb/Articles/Report guidelines 2025.pdf",
"Biokemi/Plasmidlabb/Protokoll.pdf",
"Anatomi & Histologi 2/Gamla tentor/2023-05-31/!2023-05-31-0100-DKS.pdf",

View File

@@ -68,3 +68,5 @@ Taggar:
- [ ] TBL CNS 3h
Look at [[Mega Mega#^25f90e]]

View File

@@ -3,13 +3,14 @@ Got it. Heres the “project-level” design (still high-level, but with your
Project goals with your technical choices baked in
<!--ref:start-->
Guiding constraints
• Django + templates + HTMX as the primary UI model (no SPA).
• CodeMirror as an “editor island” for Markdown.
• CodeMirror as an “editor island” for Markdown.^codemirror
• Markdown is the internal format everywhere (notes, chunks, explanations, prompts) to keep import/export trivial.
• PostgreSQL from day 1 because search is a core feature, not a nice-to-have.
• Background work must exist early (OCR/transcripts/indexing/summarization).
• PostgreSQL from <s id=456>day 1</s> because search is a core feature, not a nice-to-have.
• Background work must exist early (OCR/transcripts/indexing/summarization). ^25f90e
<!--ref:stop-->
The four main product areas
@@ -27,7 +28,7 @@ What “done” looks like:
• Every processed/derived thing points back to origin (page number, timestamp, file).
Key UX goal:
• “I remember something was mentioned somewhere” → search finds it fast → open at the exact page/timestamp.
• “I remember something was mentioned somewhere” → search finds it fast → open at the exact page/timestamp. ^837f44
@@ -139,4 +140,5 @@ Success criteria (project-level)
If you want the next doc to be even more “project charter style”, I can produce:
• a phased roadmap (MVP → V1 → V2)
• success metrics per phase (e.g., “time-to-find”, “review load”, “exam delta”)
• and a list of “risky assumptions” (OCR quality, exam parsing variability, answer keys availability, etc.).
• and a list of “risky assumptions” (OCR quality, exam parsing variability, answer keys availability, etc.).^block

199
quiz/docs/overview.md Normal file
View File

@@ -0,0 +1,199 @@
# Technical App Structure (Backend-First)
This document summarizes the **final agreed app structure** and their **core models**, focusing on **conceptual correctness and storage**, not UX.
The system is a **modular monolith**. Apps are namespaces, not microservices.
---
## 1. `core`
**Purpose:** global structure and lightweight organization.
### Models
- `Course`
- code
- name
- term / year (optional)
- metadata (optional)
### Notes
- `Course` is a **scope/container**, not a source and not knowledge.
- It groups sources, notes, exercises, and exams.
- Keep this model dumb.
---
## 2. `sources` (a.k.a. *källor*)
**Purpose:** external, replaceable, evidence-based material.
Everything here is:
- not authored by you
- safe to delete and regenerate
- traceable to an origin
### Models
- `Source`
- type (slides, målbeskrivning, instudieringsfrågor, youtube, external_notes, web)
- title
- url / origin reference
- course (FK)
- metadata
- `Asset`
- file/blob reference (PDF, images, transcript file)
- kind (original, page_image, transcript, extracted_text)
- `TextUnit`
- extracted text segment
- locator (page number, timestamp, slide index)
- confidence / OCR quality (optional)
- `Summary`
- AI or human summary
- scope (whole source, section, page range)
- locator range
### Rules
- OCR output → `TextUnit`
- Video transcripts → `TextUnit`
- Other peoples notes → `Source` + `TextUnit`
- AI summaries stay here until rewritten by you
---
## 3. `notes`
**Purpose:** your authored understanding in Markdown (incremental writing).
Everything here is:
- written or rewritten by you
- mutable and refined over time
- stable across re-imports of sources
### Models
- `Note`
- title
- body_md
- course (FK)
- `Chunk`
- UUID anchor (explicit, stable)
- excerpt_md
- status (raw → rewritten → prompted → stable)
- `Concept`
- name
- description_md
- `ChunkSourceRef`
- chunk → source link
- locator (page/timestamp)
### Rules
- Nothing enters `notes` automatically.
- Promotion from `sources` is always explicit.
- Notes are the **driver of understanding**, not scheduling.
---
## 4. `exercises`
**Purpose:** quizable, gradable units (what gets tested).
Everything here:
- has a prompt
- expects an answer or rubric
- can be graded
- can be scheduled
### Models
- `Exercise`
- type (MCQ, cloze, short_answer, free_text)
- prompt_md
- expected_answer / rubric / answer_key
- `ExerciseChunkLink`
- exercise ↔ chunk (why this exists)
- `ExerciseSourceRef` (optional)
- exercise ↔ source locator
### Rules
- Exactly **one canonical place** for testable units.
- Exercises are created from notes, exams, or manually.
- Exercises do **not** track attempts or scheduling.
---
## 5. `exams`
**Purpose:** exam context and performance history.
Everything here is:
- session-based
- append-only
- about performance under constraints
### Models
- `Exam`
- course (FK)
- date
- metadata
- `ExamExercise`
- join table (exam ↔ exercise)
- order
- `Attempt`
- exam (FK)
- mode (timed / untimed)
- start / end timestamps
- `Response`
- attempt (FK)
- exercise (FK)
- answer
- correct
- time_spent
- confidence
### Rules
- Exams **select** exercises; they dont own them.
- Exam results produce signals for reviews.
---
## 6. `reviews`
**Purpose:** spaced repetition scheduling (FSRS).
Everything here is:
- content-agnostic
- stateful
- never auto-deleted
### Models
- `ReviewItem`
- uid (stable across imports)
- points to `Exercise`
- deck / flags
- `FsrsState`
- stability
- difficulty
- due date
- reps / lapses
- `ReviewLog`
- timestamp
- rating (Again / Hard / Good / Easy)
- elapsed / scheduled days
### Rules
- Scheduler never cares *why* an exercise exists.
- Logs are append-only and must be preserved.
---
## Core Invariant (memorize this)
Sources provide evidence.
Notes explain.
Exercises test.
Exams contextualize.
Reviews schedule.
If something does not fit this sentence, it is in the wrong app.
---
## MVP Guidance
- You can ship week 1 with:
- `core`, `sources`, `notes`, `exercises`, `reviews`
- `exams` can be layered on without schema breakage.
- Avoid premature generalization (collections, curricula, sharing).
End of document.