API Documentation Completeness
Status
Active.
Scope
Bring the generated API reference for every published ViewCompose artifact to the quality contract defined by the Source Documentation and API Comment Standard. The work covers KDoc/Javadoc content, compiled samples, Dokka warnings, immutable source links, package/module overviews, and staged enforcement.
Non-goals
- changing public behavior while documenting it;
- adding comments that merely restate names or signatures;
- translating the generated symbol tree;
- enabling a repository-wide warning gate before existing debt is repaired;
- treating internal, demo, or test declarations as published API.
Current baseline
- Dokka 2.2 generates HTML for all 25 independently published artifacts.
- normal documentation builds retain deprecated APIs and suppress generated files and obvious synthetic members;
- public and protected declarations are included in the documentable surface;
auditViewComposeApiDocsexposes missing KDoc/Javadoc without blocking the build;- strict
reportUndocumented + failOnWarningchecking is available per selected module; viewcompose-runtimehas a reviewed Q2/Q3 baseline, compiled Q3 samples, a module manual, and an always-on strict Dokka warning gate;viewcompose-ui-contracthas a reviewed Q2/Q3 baseline covering node specifications, modifier phases, environment, interaction connectors, lazy/pager state, compiled samples, and an always-on strict Dokka warning gate;- comment language, depth, tags, and lifecycle/failure detail remain inconsistent across modules;
- generated source links are not yet pinned to release tags.
The warning count is an inventory, not a quality score. A declaration with a comment can still fail Q2 or Q3 manual review.
Completion criteria
- every published module has a reviewed Q-level baseline;
- all normal public and protected APIs meet Q2, with documented low-risk Q1 exceptions;
- high-risk APIs meet Q3 and link to compiled samples;
- KDoc/Javadoc symbol links resolve without warnings;
- generated source links target the matching release tag or immutable revision;
- strict Dokka checking blocks regression for every repaired module;
- module and package overviews lead readers from concepts to symbols;
- the complete versioned API catalog and documentation site build successfully.
Ordered work
- Quality foundation — complete
- define Q0–Q3 and the contract matrix;
- include public and protected APIs;
- add non-blocking audit and opt-in strict mode;
- record the initial runtime baseline.
- Runtime foundation — complete
- classify all runtime warnings and existing comments;
- repair
viewcompose-runtimeto Q2/Q3; - add focused compiled samples;
- enable strict checking for the module.
- Core UI chain — active
viewcompose-ui-contractbaseline and strict gate are complete;- repair
viewcompose-widget-core,viewcompose-renderer, andviewcompose-host-androidin dependency order; - add module/package overviews and cross-links.
- Remaining families
- text, navigation, lifecycle, ViewModel, overlay, animation, gesture, graphics, shadows, constraint layout, image loading, and preview tooling;
- enable strict checking after each module baseline is clean.
- Immutable source and release integration
- derive source-link revisions from the published version/tag contract;
- verify
current, stablelatest, and immutable version routes; - activate the complete-catalog regression gate.
Validation
./gradlew auditViewComposeApiDocs -PviewComposeDocsModules=<artifact>- strict selected-module Dokka generation
- compiled sample tasks for the owning module
./gradlew verifyDocumentationStructure./gradlew assembleViewComposeApiDocs- Docusaurus type check and production build
Last verified
2026-08-02: viewcompose-ui-contract was repaired from 1,036 initially undocumented declarations
to a zero-warning strict baseline. All node specifications, modifiers, renderer-connected state,
environment, input, graphics, and interaction contracts were reviewed; compiled Q3 samples and a
bilingual module manual were added.
Next action
Audit and repair viewcompose-widget-core, add its module manual and focused samples, then enable
its module-level strict warning gate without changing API behavior.