React · Learning application · Automation
Literatura Quiz V2
An adaptive literature-learning application built around verified content, targeted practice and automated quality control.
Literatura Quiz V2 is a static React application designed to help Bulgarian high-school students prepare for their final literature exam.
Instead of offering only random tests, the application tracks performance locally, identifies weaker areas, revisits incorrect answers and builds targeted daily practice around the student’s previous results.
Behind the application is a separate content pipeline that generates new questions from verified structured data and checks their integrity before publication.
- Role
- Web & Product Developer
- Period
- May 2026
- Status
- Completed
- Hosting
- Vercel
Overview
The Problem
Traditional notes and textbooks contain the information students need, but they do not show whether that information has actually been learned.
A student can repeatedly reread material without knowing which authors, works or question types are causing the most difficulty.
Printed practice books provide testing, but the number of questions is limited and repeated questions become familiar quickly. Creating hundreds of accurate new questions manually is also slow and error-prone.
The project therefore had two related problems to solve:
How can practice become more targeted?
How can the question set grow without introducing unreliable or invented content?
The Solution
Adaptive Practice
The application uses previous answers to identify weaker categories and difficulties and prioritise them in future practice.
Structured Content Generation
Four Node.js scripts generate additional questions from verified author and literary-work data rather than unrestricted text generation.
Automated Quality Control
Three QA scripts validate data structure, source consistency and semantic quality before changes are accepted.
The result is a fully static application that requires no paid backend or server infrastructure.
Architecture
System Architecture
Build-time content pipeline
source
.json
.json
4 scripts
static hosting
Runtime (browser only)
progress stays in the browser
no backend · no runtime API · no accounts
- Data
- Tooling / build
- Delivery
- Frontend
There is no backend and no runtime API.
The full content set is bundled into the application during the Vite build. Student progress stays inside the browser through localStorage, which keeps the application fast, private and free to host.
The trade-off is that progress does not automatically move between devices.
Engineering
Engineering Highlights
Prioritising weak areas from learning history
The “Weak Spots” mode scores questions using several signals.
| Signal | Score |
|---|---|
| Currently in review list | +4 |
| Each previous incorrect answer | +3 |
| Weak category | +2 |
| Weak difficulty | +1 |
| Each previous correct answer | −1 |
A category or difficulty is only considered weak after at least 10 answers and accuracy below 70%, reducing noisy conclusions from small samples. Questions are ranked by score before the exercise is generated.
Deterministic content generation
Automatically generating educational questions creates a different engineering problem: every question still needs to remain factual and unambiguous.
One generator searches for combinations of themes or motifs that identify exactly one literary work. A question is only generated when the clue is unique across all 27 works. If the condition cannot be satisfied, the item is skipped.
Distractors and other generated choices use deterministic logic, including a djb2 hash, so repeated generation produces reproducible output.
QA as part of the content pipeline
Because the application has no database enforcing relationships at runtime, validation happens before publication. Checks include:
- required fields and data types
- valid author and work references
- duplicate identifiers
- valid categories
- valid difficulty levels
- valid question types
- consistency with original source notes
- duplicate or weak educational content
structural error → exit 1 → change rejected
Debugging deep dive
When “previously wrong” became “still weak”
- 01
Problem
Questions that had been answered incorrectly in the past could return to Weak Spots even after they had been mastered.
In some cases restarting the mode could also create a test containing zero questions.
- 02
Cause
Historical attempts are permanent, while the active review list changes when a question is mastered.
The original selection logic treated any historical mistake as a qualification condition, so a question answered incorrectly once could remain eligible forever.
- 03
Fix
Historical mistakes now affect priority rather than eligibility. A question qualifies only if it is still in the active review list or belongs to a statistically weak category or difficulty.
The minimum sample size for a weak area was increased from 3 to 10 answers. An explicit guard also prevents an empty test from starting.
- 04
Result
Mastered questions stay mastered, Weak Spots reflects the student’s current state and the empty-test edge case is prevented.
Decisions
Key Product & Engineering Decisions
Static instead of client-server
The educational content is identical for all users and changes infrequently, so a server and database would add operational complexity without improving the core experience.
- Benefit
- Fast static delivery, no authentication, no server maintenance and no hosting cost.
- Trade-off
- Progress stays on the current browser and does not automatically sync between devices.
Verified generation instead of LLM generation
New questions are generated only from structured, verified data. I deliberately avoided unrestricted LLM generation for educational facts because factual correctness was more important than generating a larger amount of content.
Two correct answers to master a question
A previously incorrect question is marked as mastered after two consecutive correct answers inside targeted review modes. This is intentionally simpler than a full spaced-repetition algorithm while being more reliable than removing an item after one correct answer.
Stack
Technology
Frontend
- React 19
- JavaScript
- JSX
- Vite 8
Data
- JSON
- localStorage
- Markdown
Automation
- Node.js scripts
- npm
Quality
- Custom QA scripts
- ESLint
- Manual browser testing
Delivery
- Git
- GitHub
- Pull Requests
- Vercel
Outcome
Results
The final dataset contains questions across five types.
41% of the final question set is produced from structured data.
Duplicate and incorrectly categorised content was identified and cleaned.
The final application includes targeted review, daily practice, Weak Spots, statistics and additional study modes.
No server, database or paid backend runtime service is required.
Validation
Testing & Validation
The project does not currently include automated unit, integration or end-to-end tests.
Validation is instead handled through three automated content-QA scripts, generator-level checks, ESLint, production builds and manual browser testing across desktop/mobile layouts and multiple UI states.
Adding unit tests for the core learning logic and automated GitHub Actions checks would be one of my next engineering improvements.
Interface
Screenshots
Try the application
The application is publicly available, and the full source code and development history can be inspected on GitHub.