Keep public onboarding versions, channels, and freshness authoritative

[rmcdaniel]

Problem

Durable Workflow's prerelease version is repeated by hand across READMEs, SDK portals, installation examples, compatibility prose, generated LLM documents, and release qualification surfaces. These copies drift independently, so users can see several different releases described as current at the same time. Updating a release also creates avoidable cross-repository documentation work.

Product contract

Exact versions remain authoritative where machines need an immutable artifact identity: package metadata, release manifests, compatibility evidence, lockfiles, image tags, and reproducible retained evidence. User-facing onboarding should describe the supported channel and resolve the current compatible artifact without maintaining an RC sequence number in prose.

Acceptance criteria

• Replace hand-maintained exact prerelease numbers in installation instructions, SDK landing pages, READMEs, tutorials, compatibility examples, Sample App guidance, and generated LLM prose with tested versionless or prerelease-channel commands.
• Keep exact versions in package metadata, release manifests, immutable compatibility/conformance evidence, and generated reproducibility records.
• Where an exact user-visible pin is genuinely required, generate it from one machine-readable authority and label it as a qualified/reproducible tuple rather than a separately maintained current-version claim.
• Ensure the default installer, Composer, pip, Cargo, and CLI paths each resolve the currently supported prerelease in a clean environment without requiring users to discover an RC sequence number.
• Generate any derived install snippets and LLM surfaces from the same source instead of copying values between repositories.
• Add focused checks that detect hand-authored exact prerelease pins in onboarding surfaces without requiring arbitrary documentation sentences to be duplicated in tests.
• Remove or consolidate stale artifact-refresh work that exists only to chase copied prose versions.

Completion

A fresh PHP, Python, Rust, CLI, and Sample App onboarding pass reaches one compatible current product train while no public onboarding surface independently claims a different exact release is current.

Required source targets

durable-workflow/cli@main
durable-workflow/durable-workflow.github.io@main
durable-workflow/sample-app@main
durable-workflow/sdk-php@main
durable-workflow/sdk-python@main
durable-workflow/sdk-rust@main
durable-workflow/server@main
durable-workflow/workflow@v2

Consolidated scope

Versionless onboarding, cross-platform supported-channel installers, accurate crawl freshness, and task-oriented Rust Cloud onboarding are one public-version and first-run authority contract.

durable-workflow.github.io/issues/94: Publish accurate sitemap modification dates for changing documentation

Problem

Prerelease documentation and qualified artifact pins change frequently, but the generated sitemap currently publishes only generic frequency and priority hints. Crawlers can retain obsolete quickstart versions and product-status wording after the live page has changed, creating a misleading first impression for evaluators.

Acceptance

• Emit a valid <lastmod> value for documentation and blog routes based on the route's actual source modification, not a blanket build timestamp.
• Leave unchanged routes stable across unrelated deploys so the signal remains trustworthy.
• Include the same accurate freshness signal for generated public discovery artifacts whose contents change independently.
• Preserve the complete canonical route inventory, redirects, robots policy, and existing release-audit outputs.
• Add structural tests for changed-route updates, unchanged-route stability, valid W3C date formatting, and the generated discovery entries.
• Verify the deployed sitemap contains current modification dates for the 2.0 introduction and quickstart and that both live pages serve the current published-artifact wording.

Completion

The production sitemap and live pages expose accurate, current freshness metadata, and the repository's docs build and public-boundary checks pass.

durable-workflow.github.io/issues/105: Make the Windows CLI installer follow the supported release channel

Problem

The public Unix CLI installer now defaults to the release-phase-neutral supported channel, but the public Windows PowerShell installer still defaults to prerelease and accepts only alpha, beta, or RC versions from the qualified artifact authority. The two one-line installers therefore have different channel contracts. While the qualified tuple is an RC they select the same release, but after an authorized stable qualification the Unix installer can follow the authority and the Windows default will reject it.

The hosted installers and the installers bundled with CLI releases should expose one cross-platform channel contract without relying on the GitHub stable-only Latest pointer.

Acceptance criteria

• The Unix and Windows one-line installers default to supported.
• supported resolves a passing schema-v2 qualified artifact authority and accepts either an authorized prerelease or stable SemVer.
• Explicit prerelease remains available and rejects a stable-qualified authority; explicit pinned tags and stable/latest keep their documented behavior.
• Hosted and release-bundled installer copies stay behaviorally identical for channel selection.
• Cross-platform regression coverage exercises both prerelease-qualified and stable-qualified authorities and fails closed on malformed or non-passing authority data.
• Deployment/release verification proves the public installer bytes and observed channel behavior, not only source-string presence.

Delete when

Delete when the hosted and release-bundled Unix and Windows installers pass the same supported-channel contract for both prerelease and authorized stable qualification.

Required source targets

durable-workflow/cli@main
durable-workflow/durable-workflow.github.io@main

.github/issues/87: Make the Rust Cloud first-run path current and task-oriented

Problem

The Rust worker API is usable, but a first-time Cloud evaluator still has to assemble the path from generated API reference, broad protocol documentation, and sample-app conformance code. The Rust documentation landing page redirects directly to generated reference material, the Sample App pins an older Rust SDK than the current published release, and the direct HTTP fallback does not prominently show the required control-plane version header.

The supported journey should be obvious: use separate client and worker credentials, connect both to one namespace runtime URL, start a workflow, execute an activity, and inspect the completed result.

Acceptance criteria

• The Rust documentation site has a task-oriented landing page and a minimal Cloud quickstart before the generated API reference.
• The quickstart shows separate client and worker credentials, one namespace-scoped runtime URL, one task queue, workflow start, activity execution, result retrieval, and clean worker shutdown.
• The Sample App provides a memorable runnable Rust Cloud path from a fresh Codespace without requiring source inspection or a custom release build command.
• Sample App Rust dependencies and displayed version evidence come from the current supported product train; a stale checked-in prerelease cannot silently remain the evaluator default.
• Canonical CLI examples use the supported Cloud-aware CLI path. Raw HTTP examples include every required version header and explain that they are protocol examples, not the normal onboarding path.
• A clean-machine test follows only the published instructions and completes a Rust workflow and activity against Cloud.
• The resulting run is visible through the managed operator surface, and the validation records the exact SDK, CLI, and runtime versions used.

Required source targets

durable-workflow/durable-workflow.github.io@main
durable-workflow/sample-app@main
durable-workflow/sdk-rust@main

[rmcdaniel]

Cross-repository landing evidence (generated from trusted implementation pull requests or authenticated protected-branch completion records):

Target	Latest attempt	Bound provenance	Landing	Required qualification	State
durable-workflow/cli@main	Not linked	Pending	Pending	Pending: Target branch qualification; required: Target branch qualification	pending:no-linked-pull-request
durable-workflow/durable-workflow.github.io@main	Not linked	Pending	Pending	Pending: Executable documentation contracts; required: Executable documentation contracts	pending:no-linked-pull-request
durable-workflow/sample-app@main	Not linked	Pending	Pending	Pending: Target branch qualification, docker compose sample workflows, polyglot smoke (PHP/Python/Rust); required: Target branch qualification, docker compose sample workflows, polyglot smoke (PHP/Python/Rust)	pending:no-linked-pull-request
durable-workflow/sdk-php@main	Not linked	Pending	Pending	Pending: Target branch qualification; required: Target branch qualification	pending:no-linked-pull-request
durable-workflow/sdk-python@main	Not linked	Pending	Pending	Pending: Target branch qualification; required: Target branch qualification	pending:no-linked-pull-request
durable-workflow/sdk-rust@main	Not linked	Pending	Pending	Pending: Target branch qualification; required: Target branch qualification	pending:no-linked-pull-request
durable-workflow/server@main	Not linked	Pending	Pending	Pending: PHPUnit feature suite; required: PHPUnit feature suite	pending:no-linked-pull-request
durable-workflow/workflow@v2	Not linked	Pending	Pending	Pending: build; required: build	pending:no-linked-pull-request

The parent remains open until every declared target is complete.

[rmcdaniel]

The synchronized Avro train is now published: current Server and PHP/Python SDK releases are installable, and the previously named dependency items are complete. Resume the blocked execution mirrors from current target branches and reconcile the versionless onboarding contract against current machine-owned authority.