[WEB-03] Integrate developer entry points, package status, trust, security, and release information

[jaavid]

Background

CoreLink is managed as one product across multiple implementation boundaries. This work is owned by website under EPIC-05.

Problem

The public website must expose developer entry points, package/tool maturity, trust/security policy and release information without advertising scaffold or prerelease capability as supported. The previous backlog dependency Supported docs and package releases was too coarse to distinguish work that can ship now from claims that require accepted releases.

Goal

Make the website an authoritative developer-entry and product-maturity surface that links to source-of-truth documentation, package/tool status, security/trust information and release evidence.

Parent

• Primary Product Epic: EPIC-05
• Backlog ID: WEB-03

Scope

• Link developer documentation, API contracts and supported tooling from the public product surface.
• Present package/tool maturity using explicit Scaffold, Experimental, Alpha, Beta, Stable, Deprecated or equivalent supported vocabulary.
• Surface security, support, license/privacy and release/provenance information from authoritative sources.
• Ensure repository and package links resolve to maintained sources of truth instead of copied status text.
• Retain website/deployment evidence suitable for the Beta gate.

Out of Scope

• Runtime feature implementation in this Issue.
• Duplicating the product roadmap in website content.
• Presenting scaffold, planned or prerelease capability as a supported release.
• Blocking basic developer navigation until every tool reaches stable maturity.

Acceptance Criteria

• Developer entry points link to authoritative API/docs/tool sources.
• Every surfaced package/tool has an explicit maturity/version statement.
• Stable/supported claims map to accepted, version-identifiable releases; prerelease/scaffold tools are clearly classified.
• Security, support, license/privacy and release/provenance links are authoritative and current.
• Broken links, stale maturity claims and duplicated status text are rejected by review or validation.
• The accepted website revision is deployed and retained evidence is linked.
• EPIC-05 exit criteria are measurably advanced.

Dependencies and acceptance state

• Execution inputs: current API/documentation/tool maturity can be integrated incrementally; unsupported tools may be listed only with explicit non-supported maturity.
• Product-gate prerequisites for supported claims: relevant DOCS-02..05 content and the specific SDK/CLI/mock/MCP release gate being advertised must be accepted and version-identifiable.
• Governance inputs: [WEB-03] Integrate developer entry points, package status, trust, security, and release information #3 license/support policy and [WEB-04] Add accessibility, performance, SEO, analytics privacy, and release checks #4 release/provenance policy where applicable.
• Blocks: coherent Developer Platform discovery, public Beta/release-readiness claims, and EPIC-05 website exit criteria.
• Current dependency state: See the CoreLink Product organization Project.

Planning Metadata

• Type: Feature
• Priority snapshot: P1
• Product milestone snapshot: Beta
• Domain snapshots: website, devex
• Area snapshot: frontend
• Complexity: L
• Created in status: Triage
• Current status and DRI: See the CoreLink Product organization Project.
• Intended repository labels: type:feature

Definition of Done

• Acceptance criteria demonstrated.
• Supported claims map to accepted/version-identifiable sources.
• Website checks and deployment evidence pass on the accepted revision.
• Security/policy/release links are reviewed.
• Documentation/package maturity is reconciled.
• Parent Epic is updated with retained evidence.
• Pull request(s) and accepted deployment revision are linked.