Luria documentation

Luria keeps a record of what a project knows — decisions, principles, a changelog, a devlog, or whatever families the project declares. Every entry has a name something can cite, a standing that says whether it still holds, and rules the lint enforces; every view is generated from those entries.

This page is the map. (luria lint checks that every page in docs/ is listed here, so the map cannot silently rot.)

Using Luria

  • Quickstart — install, scaffold, file, lint: the whole loop in ten minutes.
  • Concepts — the shortest complete account: entries, citations, the status field everything hangs off, and what a finding is. Read after the quickstart.
  • Designing a record — what belongs in a record, which family fits which material, when two kinds of entry are two schemes, and what the schema can be made to refuse. Start here if the scaffolded decisions-and-principles shape is not what your project needs.
  • Project memory — sources and views; the four families (schemes, journals, fragments, remotes); statuses; constraints; how references are found, linked, and kept honest.
  • CLI reference — every command, flag by flag.
  • Comment directives — acknowledging a lint finding where it happens, with the reason attached; also the fixture-code convention.
  • Adopting Luria — bringing the record to an existing project, the CI wiring, and the published site.
  • Importing an existing corpus — turning material that already exists as data into a record, and what that surfaces.

Generated references

Built by luria index — read them, don’t edit them.

  • Configuration — the full luria.toml schema, generated from the dataclasses that parse it: every key, type, and default.
  • The record — the shape this project gave the machinery, generated from its luria.toml: what families exist, where entries are filed, and what to type to add one.

This project’s record

Luria’s own memory, kept with the tool it ships: