Docs

One page per part of Solid Memo. New to the app? Read user-guide.md. Working on the code? Start with architecture.md and testing.md. A term you don't know is in glossary.md.

The pages are listed in docs.ttl: each page's group, its place in the reading order, and a line on what it covers. The site's list of the docs is built from it, and so is every page's "All pages" (markdown.md).

Using the app

• User guide — a walk through Solid Memo for a learner: the browsers it supports, signing in or trying it as a guest, adding a deck, studying, courses, statistics, and the settings.
• Glossary — the terms and abbreviations the docs use, each explained in plain words with a link.
• Privacy — where your data is stored, what stays in the browser, what the host and other servers see, no analytics, and the email address published in deck metadata.
• Accessibility — what the app aims for (WCAG 2.2 AA), what is checked automatically and by hand, the gaps known, and how to report a barrier.

The code

• Architecture — the hexagonal layers, one npm workspace package each, and the Turbo tasks that check them.
• Boundaries — the import rules between packages, and the vendor libraries each may use, as npm run check:boundaries enforces them.
• Vendor-specific and vendor-independent code — which third-party technology the app depends on, where each is confined, and what replacing one would cost.
• Testing — unit tests at 100% coverage per package, the end-to-end tests against Solid servers in Docker, the user journeys in a browser (and how to debug and add one), the checks on the docs (style, spelling, links), and the commands.
• Deployment — the static build, deployed to GitHub Pages by CI for each released version, or published by hand to any web space.
• Configuration — the VITE_ settings a build reads (the app's name, the repository the footer and the page link to, the Pod providers, the deck library), their defaults, how to set them, and what they do not reach.
• Running your own instance — running your own instance: fork, configure, build, host anywhere, make the deck library your own, the files to edit by hand, and the names that must stay because they are part of the data.
• Style — how the code, Turtle, docs and commit messages are written: formatting and linting with Biome, TypeScript, naming, the Turtle house style, comments, plain English with American spelling, and English as the authoritative language.
• Releasing — how the app's versions are chosen (SemVer, from 1.0.0, by semantic-release from the commits' Conventional Commits types), what counts as breaking for data in pods, what a release does and the deploy key it pushes with, what to do when one fails, and how the app's version differs from those of the vocabulary, shapes and decks.

The data

• Data model in the pod — where Solid Memo stores data in a user's pod and how it finds it again.
• Vocabulary — Solid Memo's own RDF terms, how they are versioned, and the constants generated from them.
• Shapes — the SHACL shapes of every subject, version by version, and how they drive the code.
• Validation — checking data against the shapes and DCAT-AP in the browser, and the pySHACL cross-check in CI.
• Format versions and migrations — format versions, and how the app brings a pod up to the format it writes.
• Deck library — the ready-made decks in decks/, described with DCAT, how to add a version, and their checks; a release outside the library, and adding one from a link.
• Markdown — text written in Markdown: the dialect, which texts may be in it, how each place shows it, why showing it is safe whatever the data holds, and writing it in the card editor; and the docs themselves, read in the same dialect, their diagrams drawn and their pages rendered.
• Courses — a library deck with chapters and steps, whose multiple-choice questions join the learner's deck as they are answered.

The app

• Authentication — login, session restore and logout against a Solid identity provider with Solid-OIDC.
• Onboarding — how a signed-out visitor ends up with a connected Pod.
• Guest mode — trying the app before logging in, in a pod kept in the browser.
• Spaced repetition (SM-2) — how cards are scheduled (SM-2), as pure functions in the domain.
• Routing — the URL as the view the user is looking at: bookmarkable, shareable, Back and Forward.
• Languages — English, Swedish, Korean, German, Spanish and French: how the language is picked, and text in the user's languages.
• Statistics — the learner's own figures: the day's summary above the deck list, the statistics page and its charts, and a deck's figures, all worked out from the review log.
• Browsing and editing cards — making a deck, looking through and editing its cards in the Browser, the card creators, and previewing a library deck before importing it.
• Theme — light, dark, or as the browser says, and where the choice is kept.
• Studio — Solid Memo Studio, the second app, in Solid Memo's page at #/studio: managing an instance's decks and cards in bulk, and writing decks and courses as drafts, checking, trying, comparing and publishing them, and listing the releases published; what it shares with Solid Memo, its workspace (layout, keys, palette, what the device keeps), its routes, and how it is built and served.

The project

• Objectives — what Solid Memo is for and who it is for, what it is not for, and each principle with the check that enforces it.
• Policy — no public policy applies; the outside rules the code follows (SM-2, CLDR plural rules, BCP 47, NFC, DCAT-AP) and the project's own rules, with the tests that check each.
• Standards — every standard and specification used, with version, status, link and where it is used, and why the drafts and de facto ones do not get in the way of reuse.
• The Standard for Public Code — how well Solid Memo meets the Standard for Public Code, criterion by criterion: the scorecard, the decisions made, the GitHub settings and actions that remain, and the gaps still open.