Configuration

Vault behaviour is configured in .cuaderno/config.toml, written for you by cdno init. The defaults are sensible — you can run for a long time without touching it. This page explains what is configurable and why; the Configuration reference lists every key.

What you can configure

• The method version. [vault] method_version records which version of the Research Logbook Method the vault follows: the method’s version, not cdno’s. cdno init writes it; you change it only with cdno migrate, never by hand. A vault without it is read as RLM 1.0.
• The active-project cap. Change the default of five via [vault] max_active_projects. It counts the projects that are active and name no one else as their holder.
• The holder deny-list. [projects] holder_sentinels lists the held_by: values that name you or nobody (me, tbd, someone, …), so a map carrying one stays yours and counts. Replace the list to add your own name or words in your language, or set [] to accept any name. The tool cannot know your own name: add it if you want it read as yours.
• Ignore globs. Patterns for files the index should skip — CLAUDE.md, README.md, scratch notes — so they don’t appear in search, lint, or link checks. Patterns are additive (no negation), matched against vault-relative paths, and never delete anything on disk — they only scope what the index considers.
• Templates. Override any built-in note template by adding a file under .cuaderno/templates/.
• Custom note types. Declare your own types under [note_types.<name>]. cdno init declares the bundled concept type for you; a vault created before it existed gets it with cdno config note-type install --name concept (see Custom note types).
• Schema extensions. Add vault-specific required frontmatter fields per note type (e.g. require collaborators on every project), enforced by cdno lint.

The hands-on walkthrough is Customising templates and frontmatter.

Templates

When cdno scaffolds a note, it fills a template. Templates are pure variable substitution — no conditionals, no logic. cdno init writes two starter templates (.cuaderno/templates/daily.md, and concept.md for the concept type it declares); every other built-in type uses its built-in default until you add a file for it. cdno picks the most specific template that exists:

1. a custom variant template (for tracking, e.g. tracking-gym.md), then
2. a custom type template (e.g. project.md), then
3. the built-in variant default, then
4. the built-in type default.

Because templates also define the canonical order of frontmatter keys, cdno normalise uses them to reorder hand-authored or migrated notes into a consistent shape.

Variables

Templates use {{placeholder}} markers that cdno fills from the values each note’s creation command supplies — {{title}}, {{context}}, {{created}}, and so on. The exact set available per note type, and how to use them in a custom template, is covered in Customising templates and frontmatter. An unknown placeholder is left verbatim, so use only the ones a type provides.

Custom templates can also reference static vault variables you set under [variables] in config.toml (e.g. {{author}}); these resolve on every note type, with per-type values taking precedence over a config variable of the same name.

For values that change per note, prompted variables under [variables.prompt] are gathered at creation — from a --var name=value flag, an interactive prompt, or (failing both) a clear error. The tutorial covers them in full.

Example

[vault]
name = "My Research Vault"
method_version = "1.2"             # written by `cdno init`, changed only by `cdno migrate`
max_active_projects = 5            # the active-project cap

# Skip these from the index entirely (search/lint/links). Never deletes files.
ignore = ["CLAUDE.md", "README.md"]

# Require an extra field on every project note — enforced by `cdno lint`:
[schemas.project]
extra_required = ["collaborators"]

# Names that mean "me" or "nobody" in a project's `held_by:` (replaces the default list):
[projects]
holder_sentinels = ["me", "tbd", "someone", "A. Researcher"]

# Static template variables — resolve in any custom template (e.g. {{author}}):
[variables]
author = "A. Researcher"

# Prompted variables — gathered at note creation (--var, prompt, or error):
[variables.prompt]
collaborators = "Who are the collaborators?"

For the complete key-by-key reference, see Configuration reference.

That’s the concepts tour — next, put it to work in the Tutorials.