Forem: Vadym Arnaut

I wrote 'these fields are translatable' in five different files. Then I stopped.

Vadym Arnaut — Sun, 10 May 2026 15:33:29 +0000

The same fact, written in five places

I'm building an LMS where teachers write courses in one language and students read them in another. So content i18n. Standard problem.

What surprised me was how many places "this field gets translated" had to live.

1. supabase/migrations/...sql        CHECK (entity_type IN (...))
2. backend/app/schemas/...py          Literal["course", "module", ...]
3. backend/app/models/...py           Mapped[Literal[...]]
4. backend/app/services/.../walker.py if entity_type == "course": ...
5. backend/app/api/v1/announcements   call reconcile_entity(...)

Each of these is its own commit, its own PR, its own author. They drift independently. You add a new translatable entity in March, you forget one of the five, and a Russian student reads English in their dashboard until somebody reports it.

I shipped that bug twice in two months before I got tired of it.

What the bug looks like in practice

Concretely: I added an Announcement table that has translatable title and body. Things I had to update:

The Postgres CHECK constraint to add 'announcement' to the allowed entity_type values. Forgot this one. All inserts started failing with IntegrityError. Took two days to notice because the route swallowed the exception and just logged.
The Pydantic EntityType = Literal[...] so the API contract types match.
The SQLAlchemy Mapped[Literal[...]] on the ContentTranslation row.
The tree walker that, when a course is published, decides what to translate. Had to add a new branch for announcements.
The per-entity hook on the announcement-create route. Every other write route already called reconcile_entity() after commit. This one didn't, so edits silently never propagated.

Five places. Each one is a single line or a single function call. None of them is hard. The problem is that the knowledge of "this entity is translatable" is duplicated. Every duplicate is a chance to drift.

One registry, five readers

Collapse the duplication into a declarative registry. Every layer reads from it. Adding a new entity is one entry plus one migration, end of story.

# backend/app/services/translation/registry.py

@dataclass(frozen=True, slots=True)
class FieldSpec:
    name: str                     # logical name in our API
    column: str                   # column in DB
    model_attr: str | None = None # ORM attr if it differs

@dataclass(frozen=True, slots=True)
class EntityRegistration:
    entity_type: str
    fields: tuple[FieldSpec, ...]
    resolve_course: Callable[[Session, Any], Course | None]
    build_context: Callable[[Any, Course], str]

_REGISTRATIONS: tuple[EntityRegistration, ...] = (
    EntityRegistration(
        entity_type="course",
        fields=(FieldSpec("title", "title"), FieldSpec("description", "description")),
        resolve_course=lambda _db, c: c,
        build_context=lambda _co, c: f"Course title for «{c.title}»",
    ),
    EntityRegistration(
        entity_type="announcement",
        fields=(FieldSpec("title", "title"), FieldSpec("body", "body")),
        resolve_course=_resolve_course_via_attr("course_id"),
        build_context=lambda ann, c: f"Announcement on course «{c.title}»",
    ),
    # ... seven more entries
)

def all_entity_types() -> frozenset[str]:
    return frozenset(r.entity_type for r in _REGISTRATIONS)

The same five layers now read from this:

Pydantic schema declares the Literal once, by hand, in the module that other layers import from:

# backend/app/schemas/protocol.py
EntityType = Literal[
    "course", "module", "chapter", "chapter_block",
    "quiz", "quiz_question", "quiz_option",
    "assignment", "announcement", "course_event", "cohort",
]

That's the only manual list. A static test asserts it stays in lockstep with the registry:

def test_pydantic_literal_matches_registry():
    declared = set(get_args(EntityType))
    assert declared == all_entity_types()

SQLAlchemy model imports the same EntityType.

Walker:

def collect_translatable_fields(course, db):
    for reg in _REGISTRATIONS:
        for entity in reg.entities_for_course(db, course):
            for field in reg.fields:
                yield (reg.entity_type, entity, field)

Per-entity hook:

def reconcile_entity_if_course_published(db, entity_type, entity):
    reg = next((r for r in _REGISTRATIONS if r.entity_type == entity_type), None)
    if reg is None:
        return
    course = reg.resolve_course(db, entity)
    if course and course.status == "published":
        run_translation(db, reg, entity, course)

Migration: still by hand, but it's the only place that doesn't auto-update. So we test it.

def test_postgres_check_constraint_matches_registry():
    declared = _declared_entity_types_from_migration()
    actual = all_entity_types()
    assert declared == actual, (
        "Migration CHECK constraint and registry are out of sync. "
        f"Missing in migration: {actual - declared}. "
        f"Stale in migration: {declared - actual}."
    )

Now adding a new translatable entity is one new EntityRegistration plus one migration that adds the value to the CHECK. Both visible side by side in the same PR. The other three layers fix themselves at import time.

The CI guard that makes drift impossible

Even with the registry, one vulnerability remains. A new write route that mutates a registered entity but never calls the reconcile hook. Routes are individual files. There's nothing structural to stop the omission.

The fix is a static test that introspects every FastAPI route at import time:

TRANSLATION_HOOK_NAMES = (
    "reconcile_entity",
    "reconcile_entity_if_course_published",
    "run_course_translation_pipeline_if_published",
)

def test_writes_on_translatable_entity_call_a_hook():
    """Every POST/PUT/PATCH whose path or body schema mentions a
    translatable entity must reference one of the canonical reconcile
    hooks somewhere in its source file."""

    failures: list[str] = []
    for route in app.routes:
        if not isinstance(route, APIRoute):
            continue
        if not (route.methods & {"POST", "PUT", "PATCH"}):
            continue
        if not _route_touches_translatable_entity(route):
            continue
        source = inspect.getsource(inspect.getmodule(route.endpoint))
        if not any(hook in source for hook in TRANSLATION_HOOK_NAMES):
            failures.append(f"{route.methods} {route.path} ({route.endpoint.__name__})")

    assert not failures, (
        "These write endpoints touch a translatable entity but never call "
        "a reconcile hook:\n  " + "\n  ".join(failures)
    )

Inverse rule for read endpoints:

def test_reads_returning_translatable_schemas_accept_language():
    """Every GET that returns a translatable response schema must
    declare an Accept-Language parameter so the locale overlay applies."""

Both are plain pytest. No real database, no live HTTP, no test client. They use FastAPI's app.routes plus inspect.getsource. They fail the build in under one second.

The first time I ran them they immediately surfaced two real holes: the announcement-create route and the course-event-create route. Both had been merged for weeks. No user had hit them yet because both routes were teacher-only and had low traffic, but they would have failed the moment a teacher published an announcement on an EN-locale course with RU students enrolled.

I added a KNOWN_VIOLATIONS set to the test (cite the follow-up PR or issue, no silent skipping), fixed both routes the same hour, and emptied the set. The set has stayed empty since.

What the pattern actually buys

Adding a translatable entity is now a five-line PR. One registry entry, one migration line. CI catches anything you forgot.

Failures are loud, not silent. The CI guard names the offending route. There is no "huh, why doesn't translation work for this endpoint" debugging session anymore.

The registry doubles as documentation. Want to know what gets translated? Read one file. There is no git grep archaeology.

The pattern generalizes. Anywhere a single fact about your domain has to be repeated across multiple layers, the same shape applies. Audit logging. RLS. Soft delete. Encryption. Each one is a registry plus a static test that introspects routes or models and demands they reference the canonical hook.

That last bit is what made me write this post. The translation pipeline was the prompt, but the pattern is not about translation. It is about rejecting the idea that drift between layers is something you live with. You don't have to. Static introspection of your own code is dirt cheap and almost nobody does it.

Where it lives

The full implementation is in a small open-source LMS at github.com/ArVaViT/biblie-school. Registry is backend/app/services/translation/registry.py. CI guard is backend/tests/test_translation_coverage.py. MIT-licensed, contributors welcome if any of this resonates.

Thanks for reading.

Don't trust the LLM with scripture: a canonical-text substitution layer for Bible quotes

Vadym Arnaut — Sun, 10 May 2026 15:12:31 +0000

The problem

I'm building biblie-school, an open-source LMS for Bible schools. The product is bilingual (Russian and English) and most teacher-authored content goes through a Gemini-backed translation pipeline.

For 95% of the content this is fine. Course titles, chapter prose, quiz questions, announcements, the LLM does an honest job and the worst that happens is a slightly clumsy turn of phrase.

For Bible quotes it isn't fine. At all.

A teacher writes a Russian course quoting Acts 1:8 from the Synodal translation, the canonical Russian-language text since 1876. An English-locale student reads it. The expected behaviour is that they see Acts 1:8 in the King James Version, the canonical English-language text since 1769. Not Gemini's interpretation of the Synodal text.

This isn't a stylistic preference. KJV and Synodal are the texts these communities cite, memorize, and study from. A model paraphrase, even a "good" one, breaks the contract: students need to read the same wording their pastor will quote on Sunday. And every LLM, including the strongest ones, paraphrases scripture. Sometimes subtly, sometimes egregiously.

The naive fix is a prompt rule: "Bible verses must be preserved verbatim." It does not work. The model still paraphrases, especially across languages where there is no direct passthrough. So we built something else.

The constraint

Every quote we care about is one of two public-domain corpora:

King James Version (1769) for English. ~31,103 verses, ~4.5 MB as flat JSON.
Synodal (1876) for Russian. ~30,111 verses, ~6.1 MB as flat JSON.

Both bundle into the backend. They never change. They are the source of truth for any rendered Bible quote in either locale.

The only problem is figuring out, for any given chunk of teacher-authored HTML, which substrings are quotes that need this canonical-text treatment, and what verse exactly each one is.

The architecture

The pipeline runs in three steps around each Gemini call:

HTML in source locale
        |
        v
  pre_substitute(html, source_locale)
   - find <blockquote> + reference pairs
   - confirm canonical via similarity match
   - swap verse text for VERSE_<hex> marker
        |
        v
   markered HTML  ----->  Gemini translate  ----->  translated HTML
                                                            |
                                                            v
                                              post_substitute(html, subs, target_locale)
                                               - replace each marker with
                                                 the canonical target-locale verse
                                               - localize the (Acts 1:8) reference too
                                                            |
                                                            v
                                                  HTML in target locale

1. Detect

We walk every <blockquote> in the HTML. Two layouts in real-world content:

<!-- A: reference inside the blockquote (most Synodal-style citations) -->
<blockquote>...verse text... (Деян. 20:28).</blockquote>

<!-- B: reference outside, immediately after </blockquote> -->
<blockquote>...verse text...</blockquote> (Acts 1:8).

We try the inside layout first, fall back to a 120-character lookahead window after the closing tag. The reference parser is a regex built from a 66-book canonical alias list (Matthew / Matt. / Mt. / Матфей / Мф. / Матф. / etc.) so a sloppy book pattern doesn't accidentally swallow surrounding prose like "See Acts" as a book name.

2. Confirm

Detection alone isn't enough. The author might have paraphrased the verse themselves, or written commentary, or quoted only part of the verse. We don't want to "correct" intentional paraphrases.

So for every detected blockquote+reference pair, we look up the canonical text in the source locale (Synodal for ru, KJV for en) and compare it to the author's text using difflib.SequenceMatcher. If similarity is at least 0.80, this is a real canonical quote and gets the substitution treatment. Below 0.80, we leave it alone and the LLM handles it under the existing "leave verses untouched" prompt rule (a fallback, not the main mechanism).

We tested the threshold empirically on real course content. Author copy-pastes of Synodal hit 0.95 and above. Paraphrases land below 0.6. The 0.80 threshold tolerates minor punctuation differences (em-dashes, smart quotes, ё vs е normalization) without false-matching a paraphrase.

3. Substitute

When we accept a quote, we replace the verse text with a marker:

VERSE_a1b2c3d4e5f6g7h8

Constraints this marker satisfies:

Plain ASCII. An earlier version used Unicode Private-Use Area characters as fences. They were invisible in the editor and silently broke ASCII assertions in tests.
Postgres-TEXT-safe. The first prototype used NUL-byte fences (\x00...\x00). Postgres TEXT rejects NUL. The translated marker came back stripped, leaving raw VERSE_<hex> substrings visible to students. Took an embarrassing prod inspection to catch.
Identifier-shaped. This matters because Gemini's "preserve placeholders verbatim" prompt rule applies to identifier-shaped tokens. VERSE_a1b2c3d4e5f6g7h8 reads as a placeholder. ≪V≫ does not.
Random hex suffix. Multiple verses in one document each get a unique marker so substitutions round-trip independently.

We also extend the marker leftwards through the opening parenthesis of the reference if there is one, so we don't leave a stray ( inside the marker-replaced verse text. The reference notation itself, (Деян. 20:28)., is preserved as-is in the markered HTML and survives translation untouched (parens-with-digits looks like data to the model).

4. Restore

After Gemini returns the translated HTML, post_substitute walks the substitution list and:

Replaces each marker with the canonical target-locale verse (canonical_target = lookup(ref, target_locale)).
Falls back to the original source-locale text when the target lookup misses (e.g. a verse the bundled JSON happens to lack), better than leaving a marker visible.
Rewrites the surviving reference notation to the target locale's conventional short form. (Acts 1:8) becomes (Деян. 1:8). (Матф. 28:19) becomes (Matt. 28:19). The book-name display table is keyed by the same canonical slug as the alias parser, so adding a new book is one row in two places.

What it looks like in production

Russian-locale teacher writes:

<p>Завершающее повеление Иисуса ученикам:</p>
<blockquote>«Итак идите, научите все народы, крестя их во имя
Отца и Сына и Святаго Духа» (Матф. 28:19).</blockquote>

English-locale student reads:

<p>The final command of Jesus to His disciples:</p>
<blockquote>Go ye therefore, and teach all nations, baptizing them in the
name of the Father, and of the Son, and of the Holy Ghost: (Matt. 28:19).</blockquote>

Note three things:

The blockquote's verse text is the canonical KJV verbatim, not Gemini's interpretation of the Synodal.
The reference is (Matt. 28:19), not (Матф. 28:19). Gemini didn't translate the book name. Our display table did.
The surrounding prose ("The final command of Jesus to His disciples:") is the LLM doing its job on the parts the LLM should be doing.

Edge cases that bit us

Synodal short forms missing from the alias map. First version had матфей/мф/от матфея for Matthew but missed Матф., the most common abbreviation in actual Synodal-printed Bibles. Russian-authored content silently failed substitution and the verse leaked through Gemini paraphrased. Caught in production via Datadog RUM. Fixed by expanding aliases for every Gospel and Pauline epistle (мар, лук, иоан, фил, 1 фесс, 1 иоан, etc.) plus a contract test that asserts every canonical slug has an alias entry.
Reference outside the blockquote. Some content puts the citation after </blockquote> instead of inside it. The first version captured the verse correctly but didn't track the outside reference, so a Russian student saw a Synodal verse next to a stray English (Acts 1:8). Fixed by storing the outside ref text on the substitution record and running the same locale rewrite on it during post.
Marker spacing. The marker swallowed the trailing whitespace and closing curly quote of the blockquote, so the post-substituted output read …canonical text.(Matt. 28:19). with no space. Re-introduced a single ASCII space when the tail starts with (.
Verse range references. (Acts 1:8-10) localizes correctly to (Деян. 1:8-10) because the display formatter respects the verse_end field on the ref struct. The corresponding canonical lookup joins the verses with a single space and falls back to None if any verse in the range is missing.

What's interesting about this approach

The Bible substitution layer doesn't compete with the LLM. It uses the LLM for what it's good at (translating prose, preserving HTML structure, transliterating proper nouns) and replaces the LLM where the LLM is wrong (touching canonical text). Each layer has a clean job.

The same pattern applies anywhere you have:

A small, public-domain or licensed corpus of canonical text
A larger surface that needs LLM translation
A reliable way to detect quotes from the corpus inside the surface

Examples I can think of: legal contracts citing statute, scientific writing citing equations or named constants, classical literature quoting older works in their established translations. The shape is the same. Detect the canonical chunk, swap it for a placeholder, let the LLM handle the surrounding prose, restore the canonical chunk in the target locale.

Code

All of this lives in backend/app/services/bible/:

books.py: 66-book canon, alias map, per-locale display names
references.py: regex parser built from the alias list
store.py: bundled JSON loader (KJV / Synodal)
substitution.py: pre/post substitute, similarity threshold, marker tokens
data/: kjv-en.json (4.5 MB) + synodal-ru.json (6.1 MB), both public-domain

39 unit tests cover the alias map, the reference parser, the locale store, full round-trips for both directions, the verse-range case, and the spacing regression. The pipeline integrates into the broader translation registry which also handles non-Bible content.

Repo: github.com/ArVaViT/biblie-school (MIT)

How you can help

The pipeline above is one corner of a small open-source LMS for Bible schools and volunteer-run training programs. If you've worked on translation pipelines, LLM I/O hardening, or just like the idea of an LMS that respects scripture as a source of truth, the issues tab is open. Star the repo if you want to follow along.

Thanks for reading.

Two weeks of building Bible School LMS in public: first contributor, bilingual content, real production bug

Vadym Arnaut — Sun, 10 May 2026 02:13:11 +0000

Two weeks ago I posted "Open Source Bible School LMS, we need your help" and asked for contributors.

Today the first community PR landed. Plus a stack of changes shipped that I think are worth sharing, both because some of them are genuinely interesting, and because it gives a concrete picture of where help would land.

Repo: github.com/ArVaViT/biblie-school (MIT, looking for stars and PRs)
Live: biblie-school-frontend.vercel.app

The first community PR

Kushal picked up a good first issue (a floating scroll-to-top button), opened a PR, took a code review without taking it personally, pushed clean follow-up commits, and got merged the same day. That sounds small. For a tiny open-source repo it is the most important kind of small.

If you are reading this and have never opened a PR on someone else's project, this is exactly the type of issue we keep around for that reason. There are more on the board.

What shipped: bilingual content (RU and EN)

The biggest piece of work in these two weeks was the translation pipeline. Goal: a teacher writes a course in their own language, students read it in theirs, no UI dropdown, no "main language", no humans needed in the loop.

How it works:

Every teacher-authored field (course title, module, chapter, rich-text block, quiz, assignment, announcement, calendar event, cohort) is registered once in backend/app/services/translation/registry.py. The registry is the single source of truth for what gets translated and how. Adding a new translatable entity is one entry plus a Postgres CHECK constraint update.
On publish (and on per-entity edits to a published course) a hook walks the registry, hashes the source text, and calls Gemini for any field whose hash changed. Result is cached in public.content_translations keyed by (entity_type, entity_id, field, locale).
The student's Accept-Language header drives an overlay layer at read time. The catalog, the chapter view, the certificate, all of it returns the locale the user asked for, falling back to the source.
A static CI guard introspects every FastAPI route. If a GET that returns a translatable schema is missing Accept-Language, or a POST/PUT/PATCH on a translatable entity does not reference one of the canonical translation hooks, the build fails. That sounds aggressive but it caught two real regressions during development.

The interesting part: Bible quotes do not go through the LLM

Letting an LLM "translate" scripture is a bad idea. Even the best models paraphrase. KJV and Synodal are public-domain canonical texts and students need to read the canonical wording, not a model's interpretation.

So the pipeline pre-substitutes around the LLM:

The translator detects <blockquote> plus a parenthesised reference like (Acts 1:8) or (Деян. 20:28), in the inside-the-quote layout and the outside-the-quote layout.
It compares the author's quoted text to the bundled canonical source-locale verse using SequenceMatcher. If similarity is at least 0.80, it is a real canonical quote and gets replaced with an ASCII marker like VERSE_a1b2c3d4e5f6g7h8 before the request goes to Gemini.
After translation, the marker is replaced with the canonical target-locale verse from a 4.5 MB KJV (1769) JSON or a 6.1 MB Synodal (1876) JSON, both bundled.
The reference itself, (Acts 1:8), is also rewritten in the target locale's conventional short form, (Деян. 1:8).

Below the 0.80 similarity threshold the substitution skips and the LLM handles the quote with a "leave verses untouched" prompt rule as a fallback.

There are 66 books in the canonical Protestant canon, each with a list of recognised aliases (including Synodal abbreviations like Матф. and Деян. that the first version of the parser quietly missed). All 66 are in regression tests.

What observability caught the day we plugged it in

Datadog RUM had been wired into the frontend for a while but I was not actively looking at it. The day I finally hooked up the API, the read endpoint immediately surfaced something useful: 10 errors across 4 sessions in 24 hours, all the same:

TypeError: Failed to fetch dynamically imported module:
    .../assets/ChapterView-DYS-mrkM.js

This is the classic Vite SPA stale-chunk failure. After a deploy, every open tab is still holding the old index.html whose <script> tag references chunk hashes the new build no longer publishes. The next lazy-route navigation throws this error. The previous behaviour was to show a generic "Something went wrong" page with a manual "Refresh" button. Most users would close the tab and never come back.

Fix is a few lines in the ErrorBoundary: detect the chunk-load signature (Vite's, webpack's, and the named ChunkLoadError all have different messages), do a single window.location.reload(), guard against loops with a 60 second cooldown in sessionStorage. Reloading fetches the fresh index.html and the user is back where they were.

The point is not the bug. The point is that I would not have known about this without the telemetry. CI was green. Everything looked healthy. Real users were silently churning.

What else moved (compressed list)

Auth callback page is fully translated now. Russian users no longer see English during email confirmation or password reset.
Course detail page is fully translated, including the admin "manage course" flow that previously hid the enroll button.
OpenGraph and Twitter cards added so links to courses unfurl properly when pasted into Slack, Telegram, X, LinkedIn.
Backend favicon is now a real dark-variant of the brand glyph instead of an empty 204.
Internal cleanups: 30+ hardcoded English strings routed through i18n, repo stripped of editor-specific tooling references so it reads neutral about how a contributor authors code, security advisor warnings cleared.

Where contributors fit in

Same answer as two weeks ago, with sharper edges:

If you like...	Look at...
React + TypeScript + Tailwind	the issues tagged `frontend` and `good first issue`
Python + FastAPI + Pydantic	the issues tagged `backend`
Accessibility	`prefers-reduced-motion` is missing in a few animated bits, focus management in modals could be tighter
i18n	adding a third locale would mean one new entry in the registry, one new `_translation` JSON, one new bundled Bible (or none if the language can fall back to a sibling). The pipeline is built to scale here.
Docs	"I tried to set this up on macOS / Linux and these were the snags" stories help more than you would think
Testing	Playwright E2E for the student happy path is on the roadmap and unstarted

The bar to contribute is not "do not break anything". The bar is "open a draft PR with a question, talk it through, push some commits, get reviewed". Kushal did exactly that in a few hours.

One line again

Free LMS, small scale, real classrooms, with a translation pipeline that does not paraphrase scripture. Star the repo, pick an issue, ping me anywhere.

github.com/ArVaViT/biblie-school

Thanks for reading. See you in the issues tab.

Open Source Bible School LMS — we need your help (React, FastAPI, Supabase)

Vadym Arnaut — Sat, 25 Apr 2026 05:01:11 +0000

Why I’m writing this

Small Bible schools, home groups, and volunteer-run training programs still run classes on paper, messengers, and spreadsheets. Big LMS products are either too expensive or too heavy for a team that has no DevOps and no budget.

Bible School LMS is a free, open-source learning platform built for that reality: tens to low hundreds of users, not “enterprise 10k seats”.

We’re on GitHub (MIT) and we’d love contributors — code, UI, docs, accessibility, and ideas.

What it does today

Courses → modules → chapters with a TipTap rich editor (text, images, YouTube, callouts, audio).
Quizzes — multiple choice, true/false, short answer, essay; teacher grading and extra attempts when needed.
Assignments + gradebook, progress, certificates (with approval flow).
Teacher & admin tools: cohorts, calendar, announcements, analytics, soft-delete / restore, CSV export.
Auth via Supabase (email/password + Google).
Deploy: Vercel (static frontend + serverless FastAPI backend), Postgres on Supabase with RLS.

Live app: biblie-school-frontend

Roadmap: in the repo → ROADMAP.md

How to contribute: CONTRIBUTING.md

Stack (if you like concrete tech)

Layer	Tech
UI	React 18, TypeScript, Vite, Tailwind, shadcn/ui, TipTap, Radix
API	Python 3.12, FastAPI, SQLAlchemy 2, Pydantic 2
Data	PostgreSQL (Supabase), migrations in `supabase/migrations/*.sql`
CI	GitHub Actions — lint, typecheck, tests (backend + frontend)

We keep conventional commits, no Docker in the project by design, and we care about types (mypy + strict TypeScript) and a clean codebase.

How you can help (no need to be a “10×” developer)

Good first issues — filter by good first issue on GitHub.
UI/UX — especially accessibility and a calmer, “editorial” reading experience.
Docs — setup stories from real machines (Windows / macOS / Linux) help a lot.
i18n — the product UI is largely Russian today; if you care about internationalization, that’s a meaningful roadmap area.

Open a draft PR, ask in an issue, or fork and experiment — we’re building in public and want this to stay approachable for nonprofits and volunteers.

One line pitch

Free LMS, small scale, real classrooms — if that resonates, star the repo and pick an issue.

Thanks for reading — hope to see you in the issues tab 🤝