API documentation

Reference documentation is not read; it is searched. Someone arrives mid-task with a specific question — what does this return, what happens when it fails, is this required, and leaves as soon as they have the answer.

Optimise for that. Completeness beats narrative, and the questions people actually have are rarely the ones the happy-path example answers.

1. Generate the mechanical parts

Signatures, types, parameter lists, and status codes should come from the code — OpenAPI from annotations, docstrings extracted, CLI help generated. Anything hand-maintained drifts, and wrong reference documentation is worse than none because it is believed.

Hand-write only what cannot be derived: why, when, what happens on failure, and the constraints the type system does not express.

Done when: no fact appears in both the code and the docs, maintained separately.