ViewCompose Documentation

This directory is the canonical documentation entrance for ViewCompose. It is organized for both human readers and AI-assisted maintenance, and it is also the content boundary for the future GitHub-hosted documentation site.

The repository state and active documents below are authoritative. Files under archive/ are historical evidence only.

Choose a reading path

Goal	Start here
Understand the framework	Architecture overview → Modifier model → NodeSpec model
Choose or maintain a published artifact	Published module catalog → the owning module manual when available
Build with a feature	Select the relevant document under Guides
Work on previews or performance	Preview → Diagnostics → Performance
Contribute a change	Development workflow → Documentation governance
Prepare a release	Publishing → Capability verification
Restore project context	Roadmap and the active document for the affected area; do not start from archived plans

Architecture

Long-lived contracts, boundaries, and runtime semantics:

• Architecture overview
• Architecture decisions
• Modifier model
• NodeSpec model
• State snapshots
• Lifecycle and SavedState
• Render failures
• Session containers

Guides

Feature behavior and platform integration:

• Theming
• Text input
• Lazy collections
• Focus and input
• Nested scrolling
• Navigation
• Overlays
• Shadows

Published modules

The published module catalog is kept in lockstep with Maven publication metadata. Dedicated module manuals will live below docs/modules/<artifact-id>/ and will be able to evolve with each artifact independently.

Tooling

Development-time tooling, inspection, and performance:

• Preview
• Diagnostics
• Performance

Project maintenance

Current process, release, and planning information:

• Development workflow
• Documentation governance
• Localization workflow
• Source documentation and API comments
• Documentation site operations
• Publishing
• Roadmap
• Capability verification
• Active execution plans

Documentation rules

1. Keep the repository root limited to landing pages and community governance files.
2. Separate cross-module concepts from artifact-specific installation, compatibility, and API contracts.
3. Update KDoc/Javadoc and the owning module manual with public API changes.
4. Apply the documentation change impact matrix in every code pull request; No documentation impact requires a rationale.
5. Put cross-session execution plans under docs/project/plans/; move completed plans to docs/archive/.
6. Use repository-relative links. Never commit a local absolute path.
7. Make every active document reachable from this index through a section index.
8. Do not use archived documents as current requirements.
9. Run ./gradlew verifyDocumentationStructure before committing documentation changes. The same check is included in qaQuick.
10. Follow the canonical-first localization workflow when changing translated public content; never refresh a translation fingerprint without reviewing meaning.

The complete contract, naming rules, lifecycle, and review checklist are defined in Documentation governance.