Content Maintenance
This guide is complete when users can finish work and handle failure, not merely when every public API appears. The current baseline is v0.5.0 plus the later master development snapshot; pending features are not stable-release commitments.
CURRENT BASELINE
v0.5.0 + master development snapshot
Recheck the responsible area whenever a stable tag, public API behavior, or tutorial example changes.
How content stays trustworthy
Tutorial code executes
Core snippets originate in examples/tutorial/ and are continuously compiled and smoke-tested by CMake.
Behavior returns to facts
Signatures and semantics come from public headers, tests, and API documentation; the site explains user decisions rather than duplicating a reference manual.
Recheck at release
Version, build, migration, performance, and platform differences are synchronized with release review rather than carried forward untested.
Responsibility and facts
| Area | Pages | Primary fact source | Recheck when |
|---|---|---|---|
| Quick Start and ordinary work | Home, zh/quick-start/, zh/tutorial/ | include/executor/executor.hpp, tutorials 01–06 | Facade, future, waiting, or lifecycle changes |
| Reliability | zh/reliability/ | Failure/status types, relevant tests, tutorial 06 | Event type, counter, or monitoring semantics change |
| Real-time and communication | zh/realtime-and-communication/ | Realtime and blocking-I/O Facades, include/executor/comm/, tutorials 07–08, 12 | Period, worker lifecycle, backpressure, drop, or platform behavior changes |
| GPU | zh/gpu/ | Public GPU API, tutorial 09, hardware report | Backend, fallback, device, or performance conclusion changes |
| Advanced and reference | zh/advanced/, zh/reference/ | Public headers, docs/API.md, design, tests | Stability boundary, execution path, migration policy changes |
| Site delivery | Theme, navigation, 404, deployment | website/, docs workflow, site checker | Route, base URL, dependency, or Pages flow changes |
Definition of done for a content change
- Start from a user problem and state why to choose it, when not to choose it, and how failure is observed.
- Source code from a compiled example or provide an independent snippet-verification path.
- Do not overpromise priority, timeout, realtime behavior, or performance.
- Make a new entry reachable from its sidebar, parent page, and site search.
- Run the site build/link check; run relevant CTest when examples change.
- Update version scope and use the release documentation checklist when applicable.
Content maturity
The site has full topic coverage and a buildable framework, but page presence does not prove deep user mastery. Future work prioritizes requirement judgment, end-to-end evolution, failure cases, capacity and stop strategy, reproducible performance conclusions, and platform/hardware differences.
Include the page URL, version, minimal reproduction, actual behavior, and expected behavior. For an integration scenario, also include task scale, thread model, and stop sequence.