Reading guide

In simple terms

This documentation is written so that a beginner and a developer can read the same pages and each get what they need. Every important topic is layered: it starts with a plain-language explanation and gets more technical as you scroll. Stop wherever it stops being useful to you.

The four layers

Most pages follow this progression:

1. In simple terms — what it does and why you’d care, no coding knowledge assumed.
2. System explanation — which major parts talk to each other and what information moves between them.
3. Developer explanation — the actual files, functions, components, and API contracts.
4. Deep detail — edge cases, failure modes, performance, security, and how to extend it safely.

Collapsible “Technical details” sections hide the deepest material until you ask for it.

Where to start

If you’re new to the project:

1. Application overview — what the app is.
2. Glossary — the domain and technical terms.
3. System architecture — how the pieces fit.
4. Then browse the Features section for whatever you’re curious about.

If you’re a developer about to make a change:

1. System architecture and the Repository map.
2. The Frontend or Backend section for the area you’re touching.
3. The relevant Feature page.
4. docs/05-development/ for setup, commands, and the “adding a feature” guide.

If you just want to understand one feature: go straight to its page in the Features section — each is self-contained and links to what it depends on.

Status badges

Each page carries a status badge so you know how much to trust it:

• Verified — confirmed directly against the code.
• Partial — partly confirmed; some parts inferred.
• Inferred — a reasonable reading of the code, not yet confirmed end-to-end.
• Incomplete — a stub or work in progress.
• Outdated — known to lag the code; fix on sight.

If a page and the code disagree, the code is the current behaviour — treat the doc as the bug and fix it.

Related topics

• Application overview
• Glossary
• What’s new