# Classics Reader — Greek readings Context for Claude when preparing a reading for the Classics Reader. Adapted from the CLAUDE.md of the GRK30 course site this reader grew out of. That site organized everything around the **quiz** it would be tested on. This one does not: **the unit is a reading — one chapter, one file.** A reading is complete on its own, stands on its own, and is added without reference to anything else. ## What this is An interactive reader for whole Greek texts. Greek on the left, a literal English translation on the right, aligned clause by clause; every word is a clickable token carrying lemma, part of speech, parse, gloss and a syntax note. From that same token data the reader derives a parse trainer, form drills, practice questions and Anki vocabulary decks. Readings are addressed as `work / book / chapter`. A short standalone passage is simply chapter *n* of book 1 of its work; a real text uses its own book and chapter numbers. ## The task — when the user uploads Greek Two things happen for every new reading. Do both. 1. **Write the chapter file** — one JSON object at `public/data///.json` (schema below). 2. **File it in the manifest** — one entry appended to that work's `chapters` array in `public/data/manifest.json`, in reading order, and bump the book's chapter count. That is the whole job. There is no quiz to assign it to, no deck to build and no question bank to write — see "What you do not write" below. ## Chapter object schema ```js { work: "grk30", // work id; matches the folder under data/ book: 1, chapter: 1, // position in the book; the URL is // /read/// slug: "ody5-55-94", // unique, no spaces — stable id for the reading title: "Odyssey 5.55–94", // " ." citation: "Homer, Odyssey 5.55–94 — Hermes comes to Calypso's island", defaultSrc: "human-verified", // provenance of the analysis; see below segments: [ // each segment = one aligned Greek↔English row { lines: "56–57", // verse line/range, or a prose locus ("230b", // "1.1.1"). Verse: label EVERY segment. Prose: // label the first segment of each block; the // engine carries the label forward. translation: "literal English for this chunk", greek: [ // one token per word, in order { w:"μῆνιν", // the Greek word as it appears lemma:"μῆνις, -ιος, ἡ", pos:"noun", parse:"acc. sg. fem.", gloss:"wrath, anger", note:"direct object of ἄειδε" }, { w:".", punct:true } // punctuation: renders but is NOT clickable ] } ] } ``` ## Manifest entry `public/data/manifest.json` is what the contents page reads. Each work carries its own `chapters` array: ```js { book: 1, chapter: 1, slug: "ody5-55-94", title: "Odyssey 5.55–94", segments: 34, // segments in the file tokens: 274, // non-punctuation tokens bytes: 52441 } // the file's own size ``` The three numbers are just the file's own figures; they drive the word counts on the contents page. A new work needs an object of its own with `id`, `title`, `author`, an optional one-line `note`, `defaultSrc`, and a `books` array. ## Provenance — say where the analysis came from `defaultSrc` records the provenance of a chapter's analysis, and any single token may override it with its own `src`. It shows in the word panel as a badge. - `treebank` — from a gold-standard dependency treebank - `morpheus+model` — an analyser licensed the parse; a model chose among the options - `model-only` — no analyser coverage (crasis, proper nouns, corruption) - `human-verified` — a person checked it Be honest with this field. The whole point of carrying it is that generated analysis must never quietly present itself as checked analysis. If you parsed a reading and nobody has read it back against the text, it is not `human-verified`. ## Conventions - **Layout:** Greek on the LEFT, literal English on the RIGHT, aligned per segment. - **Segment size:** clause/sentence-sized. This matters more than it looks: the segment is the unit the practice window is cut out of, and the unit a citation points at. Aim for ~8–15 Greek words. Never one giant segment per chapter. - **Translation style:** **as literal as possible while still reading sensibly** — faithful to case, tense, and word force, but not so wooden it stops making sense. Not smooth idiomatic paraphrase. (Practice uses these as its model translation answers, so they must be defensible word by word.) - **Parsing style:** spell it out in full — "aorist active indicative, 3rd singular", not "aor. act. ind. 3 sg." (lemma/pos can stay conventional). - **Every Greek word** is its own clickable token with lemma / pos / parse / gloss, plus a syntax `note` where useful. The `note` is not decoration: practice reuses it as the explanation for auto-generated parsing questions, so write it as a reason, not a label. - **Line weight:** the engine scores a verse segment by its line range and a prose segment at ~8 Greek words to the line, so a "20-line window" means the same amount of reading in Homer and in Plato. Label `lines` honestly and this takes care of itself. ## What you do not write The reader derives these from the token data. Do not hand-write them. - **Practice questions** — translation, parsing and vocabulary questions are generated, and the answer key *is* the token's lemma/parse/gloss and the segment's translation. They cannot drift out of sync with the text, and they come free with a well-parsed reading. - **Vocabulary decks** — the Anki deck is built from the tokens. General vocabulary is included; the article, particles, prepositions, pronouns, conjunctions and interjections are skipped. The deck nests under its book, so a whole book can be drilled at once. The GRK30 site also had hand-written "what construction is this, and why" questions. Those are dropped here: 327 of them covered 16 short readings, which does not scale to a whole text. If you want that kind of explanation, put it in a token's `note`, where it is attached to the word it is about and costs nothing to maintain. ## Checking your work Two checks catch nearly everything that matters. 1. **The tokens must reconstruct the text.** Concatenate every `w` in order and compare against the source. This catches dropped words, invented words, reordering and skipped lines — the failures that would poison every drill, question and deck built on top of the reading. 2. **The morphology must be bounded.** A model asked to parse freely produces confident wrong answers a student has no way to catch. Constrain it to the analyses the surface form actually licenses and let it choose among them. A parse outside that set is a bug, not a judgement call. Then open `/read///` and read it.