ADR-0006: VitePress for Both Internal Wiki and External API Docs

Status: ACCEPTED Date: 2026-03-27 Scope: workspace Supersedes: N/A Superseded by: N/A

Context

The platform needs two documentation sites: an internal wiki (all portals, all chains, operational knowledge) and an external API documentation site (consumer-facing, API chain only). These sites have different audiences and access controls but share common content (error codes, response format, secure channel protocol).

Source: DevPortal design spec (2026-03-27-devportal-design.md, AD-6)

Decision

Both documentation sites use VitePress as the static site generator. The internal wiki (docs-wiki) serves all portal documentation and operational guides. The external API docs (docs-api) serve only the public API reference, SDK guides, and security documentation. Content is generated by the slaunchx-api-toolkit and committed to separate repos, with VitePress rebuilding automatically on commit.

Consequences

• Unified toolchain: one Markdown-based system for all documentation, reducing the learning curve.
• Shared content (error codes, response format) is generated once and placed into both repos by the CI pipeline.
• Different access controls are enforced at the deployment layer (internal wiki behind VPN, external docs public).
• VitePress provides built-in search, theming, and i18n support.
• Both sites rebuild independently; a change to the internal wiki does not trigger an external docs rebuild.

Alternatives Considered

• Swagger UI for API docs + Confluence for wiki: Rejected because Swagger UI lacks customization for the portal/chain matrix layout, and Confluence adds a SaaS dependency with no Git-based version control.
• Docusaurus: Rejected because VitePress has better Vue.js ecosystem integration and faster build times for Markdown-heavy sites.
• Single combined site with access-controlled sections: Rejected because the external site must be independently deployable and auditable without internal content leakage risk.