Skip to main content

External Publication Readiness implemented

External publication is a product release. Do not expose the internal portal by changing the hosting target. Prepare explicit publication tracks, visibility review, sanitized entry pages, and filtered builds.

The concrete filtering rules live in Publication Filtering. Treat that page as the operating model for internal, customer, partner, and public builds.

Publication Tracks​

TrackAudienceSafe contentExclude by default
PublicProspects, public users, external developersProduct overview, high-level getting started, public API/App SDK conceptsInternal gaps, environment names, runbook commands, evidence artifacts
CustomerCustomers, tenant admins, customer security reviewersUser/admin workflows, billing/storage, customer-safe controls, support modelPrivate infrastructure, break-glass procedures, internal agent workflow
PartnerPartner app and integration teamsApp SDK, manifests, auth/access, promotion, API/event contractsInternal product gaps, unrelated operations runbooks
InternalGPUaaS team, operators, product, security, agentsComplete operating view, evidence, roadmap, internal runbooksNothing by default; still mark stale/superseded docs

Readiness Checklist​

  • Every page has visibility, audience, status, and valid source_docs.
  • Public/customer/partner candidate pages have content review.
  • Security-sensitive pages have security review.
  • Architecture diagrams have architecture review.
  • Product claims have product review.
  • External paths avoid internal hostnames, private environment names, raw evidence artifacts, break-glass details, and agent-only execution mechanics.
  • API and SDK pages link generated or synced artifacts, not hand-written endpoint payloads.
  • Static images have useful alt text and a clear source.
  • Static deployment preflight evidence exists before upload.
  • No external publication points at a dev host, local Docusaurus server, or dev-control endpoint.
  • make docs-portal-check passes.

First Landing Paths​

The first external-ready shape should expose these curated paths:

These pages remain internal until the visibility guard and filtered builds are implemented.

Current Baseline​

The current baseline is still the internal static Cloudflare Pages portal. Do not confuse that release with an external-ready launch. External tracks remain an explicit next phase after content curation, filtered-build enforcement, and track-specific review.

What already exists:

  • internal publication-track metadata on portal pages;
  • publication-sensitive content checks in check-source-docs.mjs;
  • source-doc inventory and synced-contract artifacts;
  • build and publish metadata in the portal itself;
  • Cloudflare static deploy preflight and publish wrapper.

Build Direction​

The first implementation can keep a single internal build. The next publication slice should add report-only visibility inventory before filtered builds:

docs-portal-visibility-report
docs-portal-build-public
docs-portal-build-customer
docs-portal-build-partner
docs-portal-build-internal

The report should fail only after the team agrees on blocking publication rules.

Canonical sources