Documentation Style Guide

Write for readers first: introduce the task or concept before implementation detail, use runnable commands only when they are supported, and link to the authoritative contract rather than duplicating it.

• Use clear, specific headings; avoid generic titles such as “Overview”.

• Keep user guidance separate from contributor governance and research notes.

• State qualification limits next to any qualified claim.

• Describe annotation as generation and annotation, not numbered product phases.

• Mark hosted-model output as non-deterministic; describe structural validation and provenance without claiming deterministic semantic verification.

• Run strict Sphinx and API-coverage checks before review.

Code-span Linking Rule

Link a public API name to its authoritative reference page when that link helps the reader verify the stated contract. Do not create links to removed APIs or historical design-spec anchors.