Make fresh Codespaces fast and complete for every supported workflow path

[rmcdaniel]

Problem

Creating a GitHub Codespace from main currently spends more than 400 seconds constructing the development environment before the sample application is usable. The current path starts from a general operating-system image and performs operating-system repository setup, PHP and extension installation, Node and Composer installation, database-client setup, and a Playwright browser/dependency download inside each new Codespace. This is the first interaction many evaluators have with the Sample App, and it is too slow and fragile.

Product outcome

A fresh Codespace should pull a prepared, public development image and reserve per-Codespace startup for repository-specific dependency/bootstrap work. The image must remain reproducible, regularly refreshed, usable on common local development hosts, and safe for untrusted pull requests.

Acceptance criteria

• The main Codespace path consumes a prebuilt public development image. Codespace creation does not run an operating-system package manager, add third-party package repositories, install PHP/Node/Composer, or download Playwright browsers.
• The prepared image contains the supported PHP 8.4 runtime and required extensions, Composer 2, Node 22, the Playwright-compatible Chromium runtime and system dependencies, FFmpeg, Git, Curl, and the database/Redis client support actually exercised by the Sample App.
• The same build publishes public images to ghcr.io/durable-workflow/sample-app-devcontainer and durableworkflow/sample-app-devcontainer, with coherent immutable revision tags plus a documented moving channel for main. AMD64 and ARM64 consumers are supported, or an evidence-backed architecture limitation is surfaced before completion.
• Image publication runs only from protected repository state. Pull requests can build and validate the image without registry credentials, package-write permission, deployment secrets, or a cache that can later influence a privileged publication job. Third-party Actions are pinned to reviewed immutable revisions.
• Published images carry source/revision metadata and verifiable provenance/SBOM output. Relevant image inputs trigger a rebuild, and a scheduled protected-main rebuild keeps operating-system and browser layers current.
• A clean qualification pulls the published image, starts the Codespace Compose topology without an image build, installs only repository dependencies, and reaches the application health endpoint with PHP, Composer, Node, Playwright/Chromium, and editable mounted files verified as the non-root development user.
• Qualification records phase timings for image pull, container readiness, dependency bootstrap, and application readiness. Fresh startup is materially below the observed 400+ second path, and a warm rebuild does not repeat immutable environment setup.
• Failure to pull or qualify the published image fails clearly; the configuration does not silently fall back to rebuilding the old slow environment.

Completion condition

Close when both registries serve the qualified image from the protected main revision, the repository's default Codespace path consumes it without an environment build, public CI is green, and retained timing evidence demonstrates the improved fresh and warm startup paths.

Consolidated scope

The following formerly separate findings are required parts of this root. Completion requires the prepared-image performance contract, symmetric embedded/service-mode and PHP/Python/Rust playgrounds, and their executed CI evidence.

#53: Make service mode a first-class Sample App onboarding path

The Sample App has a polished embedded-Laravel quickstart and a comprehensive standalone PHP/Python/Rust stack under polyglot/, but the service-mode implementation reads as a conformance harness rather than an evaluator-facing product path. A Laravel user exploring polyglot execution should not have to discover test infrastructure or downgrade to a bare protocol example.

Keep embedded mode simple and add an equally direct service-mode journey built from the existing published Server and SDK artifacts.

Acceptance criteria

• The top-level onboarding presents two clear runnable paths: embedded Laravel and service mode. Neither is described as the lesser or legacy option.
• Service mode starts from the Codespace with one memorable command and reuses the prepared development image; it does not rebuild SDK/runtime toolchains.
• The first service-mode example uses the framework-neutral PHP SDK with its Laravel bridge, dependency injection, logging, worker command, and test fake rather than a bare standalone script.
• The path starts a workflow, executes a PHP activity, executes one cross-language activity through a Python or Rust worker, waits for a result, and links to the matching Waterline run.
• Beginner-facing output explains what started and where to inspect it without exposing conformance-matrix terminology.
• Embedded and service-mode examples use distinct isolated Compose state and can be run repeatedly without workflow-ID collisions or manual cleanup.
• All package and image versions resolve from the current supported 2.0 train; no stale RC number is copied into the onboarding instructions.
• A clean Codespace browser/terminal smoke proves both paths from documented commands and retains startup/result timing evidence.

Close only after a first-time-user smoke has completed both documented paths from a fresh Codespace.

#55: Make every first-party SDK runnable from a fresh Codespace

A fresh Sample App Codespace is not yet a truthful playground for all first-party SDKs. PHP embedded examples are immediately available, while framework-neutral PHP, Python, and Rust authoring are hidden behind containerized onboarding or the conformance matrix. The default environment lacks Python and Rust authoring toolchains, Docker Compose access, and the Durable Workflow CLI. An evaluator can read the SDK references and ask an agent to create a workflow and activity from scratch, yet the agent cannot execute a valid path from inside the repository.

Make Sample App an easy, symmetric PHP, Python, and Rust playground without regressing Codespaces startup performance.

Acceptance criteria

• After a fresh Codespace reports setup complete, PHP and Composer, Python 3.10 or newer with isolated package support, Rust 1.86 or newer with Cargo, Docker Compose, and dw are directly executable by the non-root Codespaces user.
• Tooling is supplied by the published development image or a bounded checksum-verified cache/bootstrap. The post-create path does not run apt, rustup, compile the CLI, or rebuild language toolchains.
• Docker access works from inside the development container and is permission-safe for the non-root user; every documented service-mode command passes its Docker preflight in Codespaces.
• Expose one memorable playground interface with symmetric php, python, and rust choices. Each choice can scaffold or run caller-owned source against an isolated published Server and prints the completed result plus the exact Waterline run URL.
• Each proof creates new workflow and activity source outside the repository's canonical matrix workers, registers a worker, starts the workflow, executes the activity, and receives the result. Replaying a prewritten conformance cell is insufficient.
• The PHP path covers the framework-neutral SDK with an ergonomic Laravel integration option; moving from embedded Laravel to service mode must not discard dependency injection, configuration, logging, or testability.
• Python and Rust dependencies for the supported SDK floors are pre-fetched or otherwise cached so first use is not dominated by rebuilding the SDK dependency graph.
• The top-level README and repository agent guidance make the three paths discoverable from a natural-language request to create and run a workflow. Users do not need to infer conformance commands.
• CI runs the same authored-from-scratch journey for PHP, Python, and Rust using published artifacts and verifies each result, worker registration, workflow history, and Waterline selection.
• A fresh standard two-core Codespace records creation timing and executes all three journeys as the normal user. Setup remains under five minutes, the repository stays clean except for intentionally created playground source, and no recovery container or manual package installation is used.

Close only after exact fresh-Codespace transcripts and timing evidence for all three SDKs are attached.

#70: Run service-dialog adapter regression tests in CI

Problem

Commit df2e3386c19237ba484b2c2a988c2d83e1f657ab adds tests/Node/ServiceModeDialogVisualTest.mjs to protect the service-mode Waterline adapter’s stable-open wait, rejected-geometry retention, and fail-closed handling of an unsupported installed audit. No package script or GitHub Actions step invokes the Node test suite. The end-to-end service-mode smoke proves the current all-passing dialog matrix, but it does not exercise the failed-geometry path, so the diagnostic regression can return without failing CI until another responsive defect occurs.

Acceptance criteria

• Run the service-dialog Node regression test on pull requests and pushes to main after the installed Waterline package is available.
• Keep the test fail-closed when the installed audit source no longer matches the supported adapter contract.
• Prove the executed test covers the stable-open wait and retains measured geometry before rejecting a failed geometry audit.
• Preserve the existing fresh-and-repeat eight-case browser qualification.

Delete when

Delete this item when protected-branch CI visibly executes the Node regression test and fails if either stable-layout waiting or failed-geometry retention is removed.

[rmcdaniel]

Fresh-main qualification update: the observed Codespace remained in the GitHub Provisioning state more than 18 minutes after creation on a 2-core machine, and creation logs were still unavailable. This confirms the P0 is the immutable environment build path itself, not a small post-create delay. Completion evidence must measure a fresh image pull and application readiness separately and demonstrate that new Codespaces no longer build the development image.

[rmcdaniel]

Fresh Codespace timing evidence after the prebuilt-image landing confirms that the old in-Codespace image build is gone, but the completion condition is not yet met:

• devcontainer image pull: 199.9s
• MariaDB image pull: 99.3s
• Redis image pull: 69.4s
• database healthy / application containers started: approximately 106.7s after Compose startup

The published image was pulled successfully and no fallback build occurred. Keep this P0 open until one qualification records end-to-end Codespace creation through application health, separates overlapping pull/readiness phases, proves the non-root toolchain/browser checks, and demonstrates the warm path. The current image-pull size is still a material first-run cost even though it is better than rebuilding the environment.