Glossary

Archetypes are configured at four levels: the site, each collection, optional URL patterns, and single documents. The developer seeds them from the seo section of krantho.config.ts, and editors refine them in the admin. Krantho fills the properties it can derive from the content and leaves judgment to the author.

cache.cdn.provider names the CDN — Vercel, CloudFront or Cloud CDN — and krantho purges by cache tag under the cdn strategy. Behind CloudFront or Cloud CDN with next-isr, it purges the whole site (/*) on every published change instead. A purge that fails is logged and never fails the write that caused it.

You define a collection in code with defineCollection() from @krantho/schema: a name, where its seed files live, and a Zod schema for its fields. The schema is also the form editors fill in the admin. Collections group content by type — a list of documents that each get a page, or site-wide data read by the layout.

A content template describes what a kind of content contains, not how it looks. Editors fill it in the admin; developers define it in code. The same content template can be rendered by more than one page template.

Enrichment runs as a background job started from the admin, the API or the CLI, or as a build-time tool that previews its changes before applying them. It uses the provider and model configured under llm. Authors review what it drafts; values they have set are left alone.

In a Markdown file, fields are written as frontmatter; inside the CMS — the API, the admin and persistence — they are called fields. The API returns them as fields.title, fields.description and so on. status and locale are system fields that move into the document's metadata.

Frontmatter is how fields are written in content files. When krantho imports a file, the frontmatter becomes the document's fields and the rest of the file becomes its body. The same data is edited as a form in the admin.

Globals are read by the layout rather than shown as pages of their own, so they are left out of the sitemap and have no page to preview. Editors change them in the admin like any other document. A published change to a global marks every cached page that reads it as stale, and each renders again when it is next visited.

Krantho builds one @graph per page from the site's and the document's archetypes with composeFromConfig() in @krantho/seo. A page renders it with <SeoJsonLd> from @krantho/ui-react, reading the published version of the document. The markup is what makes a page eligible for rich results.

The build-time SEO pipeline in @krantho/tools generates llms.txt from your business data and content. Its link descriptions can be written by enrichment and reviewed before they are applied. Your app serves the generated file from a route.

The site names its locales in site.supportedLocales and its default in site.defaultLocale. Each document carries a locale, which defaults to en, and the API takes a locale parameter to read one language. With more than one locale, the admin shows translation coverage.

The file bytes go to the media store, while the metadata — alt text, tags, folder, crop and hotspot — is versioned in your database. Media needs SQLite or Postgres persistence, and it is off while media.provider is unset. Each store is a package of its own, so a site installs only the one it uses.

Pages read content through krantho's loader, which tags every read. When an editor publishes, krantho revalidates the tags that change touched, and the pages that read what changed render again on their next request. @krantho/server-next is the one package that talks to Next.js's cache.

With none, every request renders the page. With next-isr, Next.js keeps each page until a content change invalidates it; with cdn, a CDN in front of a SvelteKit or Express site keeps each page until a change purges it. Every committed write announces what it changed, and krantho maps that change to the pages that read it.

In Next.js a page template is a server component under app/; in SvelteKit it is a route with a server load; in Express it is a handler that renders HTML. It reads the published version of a document and decides the layout. Krantho has no page builder: layout is your code, content is the editor's.

Every read and write goes through one interface, IPersistenceAdapter from @krantho/persistence, so the rest of krantho does not know which database it runs on. You pick the backend with persistence.provider. Markdown files in your content directory are imported into the database on first boot.

Visitors always see the published version; an editor in preview sees the draft in the site's own layout. Next.js sites use draft mode, and SvelteKit and Express sites use a signed link that is valid for ten minutes and for one path only. Preview is offered when the site enables it.

Runtime fields are additive: they extend a collection, but a field its code defines cannot be changed or removed at runtime. The admin shows them in the same form as the code-defined fields. When a field proves permanent, move it into the collection's schema in code.

Krantho splits a Markdown body at its ## headings and renders each part on its own. A page template can place each section where its design wants it, and give some sections a designed treatment while the rest render as prose. Sections keep long-form content editable as one body.

With SQLite or Postgres, each save appends a new version; nothing is overwritten in place. Restoring an old version creates a new version from it, so the history stays complete. Purging keeps the latest versions of each document, as many as content.versions.keep says.