[DOCS-04] Publish SDK, CLI, mock, MCP, sandbox, and migration guides

[jaavid]

Background

CoreLink is managed as one product across multiple implementation repositories. This work is the executable feature owned by developer-docs under EPIC-05.

Problem

The SDK/CLI/mock/MCP/sandbox/migration guide backlog previously used the non-actionable blocker Supported releases of referenced tools, which did not distinguish work that can be drafted now from claims that require accepted releases.

Goal

Publish versioned SDK, CLI, mock, MCP, sandbox and migration guides that accurately distinguish scaffold/prerelease/supported tooling and retain runnable evidence for supported journeys.

Parent

• Primary Product Epic: EPIC-05
• Backlog ID: DOCS-04

Scope

• Publish install/setup/use guides for supported SDKs and developer tools.
• Clearly classify scaffold, prerelease, experimental and supported tooling.
• Publish migration/upgrade guidance where version transitions are supported.
• Validate runnable examples against declared tool/API versions.
• Retain documentation evidence suitable for Developer Platform/Beta gates.

Out of Scope

• Presenting planned/scaffold tools as supported releases.
• Blocking all drafting until every referenced tool is stable.
• Treating documentation CI alone as product/tool acceptance.

Acceptance Criteria

• Every referenced SDK/tool has an explicit maturity and version statement.
• Supported-tool installation and happy-path examples are runnable against the declared version.
• Planned/scaffold/prerelease tools are clearly labeled and do not imply support guarantees.
• Migration/upgrade guidance exists for supported compatibility transitions where applicable.
• Security-sensitive setup and credential handling are accurate.
• Links, examples and version claims pass documentation validation.
• Retained evidence is linked and EPIC-05 exit criteria are measurably advanced.

Dependencies and acceptance state

• Execution inputs: current maturity/release state of the TypeScript, Python and Java SDKs, CLI, mock server, MCP tooling and supported sandbox/developer environment.
• Product-gate rule: a guide may be drafted for prerelease/scaffold tooling, but may only make supported claims when the referenced release/tool gate is accepted and version-identifiable.
• Blocks: Developer Platform onboarding completeness, DOCS-05 cross-doc quality/version checks, and Beta/release-readiness claims depending on these tools.
• Current dependency state: See the CoreLink Product organization Project.

Planning Metadata

• Type: Feature
• Priority snapshot: P1
• Product milestone snapshot: Beta
• Domain snapshots: docs, devex
• Area snapshot: documentation
• 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 tool releases.
• Runnable examples pass for supported tools; non-supported examples are explicitly classified.
• Security-sensitive guidance is reviewed.
• Required documentation checks pass on the accepted revision.
• Documentation/release maturity notes are reconciled.
• Pull request(s) and retained evidence are linked.