vault backup: 2025-12-23 22:52:59

content/z-Tech/Mega Mega.md

@@ -3,13 +3,14 @@ Got it. Here’s 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
+