Docstrings & Documentation Comments code review rules

Every package must have a package comment, and each exported identifier must have a comment starting with the identifier name and a full-sentence summary.

All public modules, classes, and functions must include a docstring immediately after the definition, using PEP 257 conventions (one-line summary + optional sections like Args, Returns, Raises).

When a function is unsafe, may panic, or returns Result, include sections # Safety, # Panics, and/or error conditions in the docs.

All public classes, interfaces, and methods must include Javadoc with a summary sentence, @param for each parameter, @return when not void, and @throws where applicable.

All exported JS/TS functions, classes, and public members must include JSDoc with a summary and @param/@returns; include @throws when applicable.

Docstrings must match parameter names, optional defaults, return type, and raised exceptions; update the docstring in the same PR as any signature change.

All public types and members must have XML documentation comments with <summary>, <param>, <returns> (if non-void), and <exception> when thrown.

For async functions or functions returning Promise, document resolve value, rejection conditions, and usage with await; include @throws or @returns {Promise<Type>}.

The first sentence should be a standalone summary used by godoc. For functions returning error, state error conditions succinctly.

When introducing or deprecating public APIs, include @since for introductions and @deprecated with migration notes and links for removals.

Use <inheritdoc/> to inherit docs for overrides/implementations, but explicitly add <exception> and behavior differences when applicable.

Document public items with /// and modules/crates with //!; include minimal runnable examples that pass doctests where applicable.