EPAR extensions preserve the existing user flow and controller design.
The start wrapper family is EPAR's universal operator entry point for first-run configuration, normal controller operation, manual launch, and machine autorun. Use ./start on every supported shell, including native Windows PowerShell. PowerShell resolves that path to the internal Windows wrapper; bare start is not the EPAR command because PowerShell reserves it as the Start-Process alias. Operator documentation and startup automation must invoke ./start rather than naming an internal platform script or locally built controller binary.
With no arguments, a wrapper invokes the controller's start command. When the first argument is a global flag, the wrapper inserts start before forwarding the complete argument array. When the first argument is an explicit command, the wrapper forwards that command and every argument exactly. The wrapper-only first argument --use-old explicitly selects the validated recovery slot and is never forwarded to the controller. Local-Go and Docker-toolchain builds must have the same command, argument, configuration, trust, reconciliation, receipt, and remediation behavior. Both paths build under .local/bin/<os>-<arch>/ and execute that project-local controller directly; go run is not an operator or fallback path.
Every current or old controller slot is an exact-owned directory containing one host-native executable, its versioned offline receipt, and only recognized runtime leases. The receipt separates source content, build identity, and executable SHA-256. Git metadata is diagnostic rather than part of source identity, so a source archive or a locally patched checkout can be validated without Git. A source or build mismatch produces a fully validated staging slot before the existing old slot is removed and current is rotated to old. Build failure leaves both installed slots unchanged, active or ambiguous leases block rotation, promotion failure restores current, and EPAR never executes old automatically. No wrapper may claim upstream freshness; it can prove only local source/build matching and binary integrity.
The receipt schema reserves a future distribution=prebuilt form whose source status is not applicable. Source-free package execution is not implemented until EPAR publishes such artifacts; future support must validate target, receipt, embedded build identity, and executable digest without misclassifying an incomplete source tree as a prebuilt distribution.
The wrapper opens the missing-configuration wizard when needed. A no-Go bootstrap TLS failure must preserve the native build transcript and report the requested host and presented certificate metadata without disabling verification or retrying insecurely. Four provider identities remain accepted by runtime and configuration, while three are onboarding-capable: Docker Sandboxes is option 1 and the recommended default, C. Show compatibility providers reveals Docker Container (2) and WSL2 (3), and Tart remains a retired runtime identity with no onboarding option. Selecting an unavailable Docker Sandboxes default must show remediation and reprompt rather than renumbering, reordering, or silently selecting another provider. A selectable provider must show its tooling and daemon prerequisite status; storage estimates never make provider selection unavailable or prevent configuration creation. Docker Sandboxes presents verified prebuilt Full (default), verified prebuilt Act, local Catthehacker Full, and local Catthehacker Act in that order; Docker Container and WSL retain their local Full/Act choices and custom-tag choice. Docker Sandboxes admits only the Full and Act profiles because its reusable template requires the private Docker daemon and runtime closure. The wizard generates empty custom-install scripts, weekly updates at 07:00 local time, and host-trust overlay for providers that support runner trust inheritance; operators may edit those advanced settings after creation. The wizard keeps later answers in a navigable draft, shows provider-specific estimates only when applicable, and writes only after one provider-neutral final review. An embedded ./start then continues through the ordinary artifact provisioning and storage-admission path. Local artifact inputs always apply immediately; provider-neutral scheduling may defer only remote mutable source, package alias, and Actions runner observations. Reject an unavailable platform or invalid image clearly and never silently switch a configured provider or artifact. Builder operational trust and runner trust inheritance remain separate contracts: system roots always support the owned builder, while image.hostTrustMode controls runner inheritance.
The wizard defaults pool.namePrefix to <sanitized-machine-name>-<six-random-hex>, capped at 40 characters. The machine name shows where a runner belongs, the random suffix reduces collisions, and the cap leaves room for the GitHub runner suffix. Every provider must use the shared internal/pool.RunnerName function and keep the configured prefix literal.
Keep the flow CLI -> pool manager -> provider -> guest/GitHub. Provider-specific host operations belong in internal/provider/<provider>; the pool manager owns shared registration, readiness, replacement, status, and cleanup flow. Extend the shared interfaces instead of creating a second control path.