Update Docs

Update User-Facing Docs

The docs/content/ tree is hand-written and easy to drift from the code. This skill reconciles it section by section against the actual source of truth. Always finish by re-reading both sides and confirming they agree — do not assume the docs already match.

Scope

The user-facing docs live in docs/content/. Each section has exactly one source of truth in the codebase:

The four bullets in the typical request — config schema, CLI, MiniBF list, MiniKupo list — map to the first four rows. Always include them. Add other rows when the change touches them.

Workflow

For each area you intend to update, do these three things in order:

1. Read the source of truth fully. Do not eyeball it — list out the actual fields/routes/args.
2. Read the current doc fully and build the same list from it.
3. Diff the two lists. For each delta:
   • Item present in code, missing from docs → add it.
   • Item present in docs, missing from code → remove it (it was renamed or deleted).
   • Item present in both with different name/type/default/description → update the doc.

Edit the docs surgically with Edit. Do not rewrite a section just to "tidy" it — keep diffs reviewable.

Section: Configuration schema

Source: crates/core/src/config.rs.

The schema doc must reflect:

• Every field of RootConfig (top-level TOML sections).
• For each top-level section struct (e.g. MinibfConfig, StorageConfig, SyncConfig, LoggingConfig, TelemetryConfig, etc.), every public field plus its type and any default returned by an accessor like fn permissive_cors(&self) -> bool { self.permissive_cors.unwrap_or(true) }.
• Option<T> fields are documented as optional. Fields with #[serde(default)] use the Default impl.
• Nested structs under storage.* (storage.wal, storage.state, storage.archive, storage.mempool) each have their own subsection.
• The example TOML at the top of schema.mdx should remain a valid, representative sample — if you add a section, add it here too in alphabetical-ish order matching the rest of the doc.

Common drift patterns to look for:

• A new field added to a config struct but never appearing in the table or bullet list.
• A field renamed in code (e.g. cache_mb → cache) while the doc still uses the old name.
• A default changed in the accessor (unwrap_or(...)) while the doc still cites the old default.
• A #[serde(rename = "...")] that means the TOML key differs from the Rust field name.

Section: CLI subcommands & operation modes

Source: src/bin/dolos/main.rs enum Command plus the corresponding mod (daemon.rs, sync.rs, serve.rs, data/, eval.rs, doctor/, bootstrap/, init.rs, minibf.rs, minikupo.rs).

Steps:

1. List every variant of Command. Note any #[cfg(feature = "...")] gates — Init, Data, Bootstrap, Minibf, Minikupo are all feature-gated, so the docs should describe them as available "when built with the corresponding feature" if the gate is non-default. (As of this writing, all five features are on by default in Cargo.toml.)
2. For each subcommand, open its module's Args struct (or sub-Subcommand enum, e.g. data::Args, doctor::Args) and confirm the doc reflects the actual flags/args.
3. Update docs/content/operations/modes.mdx to keep the "Summary of Modes" table aligned with what Command actually exposes.

Note that modes.mdx today only documents daemon, sync, and serve. If a new top-level subcommand appears that an end user needs to know about (not internal helpers), add it. Internal/utility subcommands like data and doctor are typically documented elsewhere or via --help; do not add them to modes.mdx unless that's the intent of the change.