Contribute to Pulsar documentation
The site owns tutorials and explanations; the package owns executable behavior and package facts. A contribution must preserve that boundary, use the required page mode, and carry review evidence.
Review checklist
| Check | Requirement |
|---|---|
| Authority | Trace package facts to the synchronized manifest or an inspected core source; do not infer them. |
| Page mode | Use the authoring template, answer first, meet its prose budget, and link only to built routes. |
| Terminology | Use the glossary canonical casing and link first definitions where required. |
| Code and diagrams | Import checked code or execute it; give figures their accessibility contract and interpretation. |
| Versioning | Update current-root release material only; do not add historical routes before a supported second breaking line. |
| Evidence | Run the relevant checks and identify source revision, route, and reviewer result in the pull request. |
Ownership and decisions
The documentation maintainers own public copy, navigation, generated reference projections, and review evidence. Core maintainers own package behavior, manifest generation, the issue intake, and the release-impact required check. Record a durable documentation design decision as an ADR in the repository that owns the decision; include context, decision, consequences, and review date.
Update generated reference data
Run pnpm run docs:check-core against the declared read-only core checkout. When the manifest changes, a core maintainer generates it and a documentation maintainer synchronizes the projection before reviewing source drift. A site-only workflow cannot make a package release require documentation review.