Parent epic: #3588

Goal

Migrate the platform-remote E2E coverage area into the layered scenario framework without porting legacy scripts line-for-line. Add the missing primitive layer first, then move assertions into scenario plans/suites with stable IDs.

This issue is also the input for /vd_spec: create an implementation spec and a validation spec for platform/remote scenario coverage. The spec should make it unambiguous which checks are expected to pass, which are intentionally deferred/skipped, and what evidence the implementation PR must show.

Scope definition: platform-remote

This domain covers E2E behaviors tied to platform-specific or remote execution paths, including:

• GPU/local Ollama host flows
• Brev CPU/GPU remote branch validation and launchable install flows
• DGX Spark / DGX Station style local-model hosts
• macOS and Windows/WSL workflow/platform execution paths
• OpenShell Docker-driver gateway/network topology where it differs by platform
• platform-specific install/onboard preflight and recovery behavior

Out of scope unless explicitly pulled in by the spec: messaging-provider behavior, general policy presets, generic negative-path onboarding, and non-platform-specific CLI parsing.

Legacy / current E2E coverage to absorb

Migrate the highest-value assertions from these existing E2E assets into scenario-suite coverage. Do not port scripts line-for-line; extract the stable behaviors and classify the rest as covered, deferred, or retired.

Existing E2E assets and expected migrated assertions

New merged/platform-remote work to evaluate for scenario coverage

These are not necessarily already covered by existing E2E. The spec should decide whether each becomes a scenario assertion, onboarding assertion, workflow metadata item, or deferred item.

Architecture contract

• Add or extend the domain primitive library: test/e2e/validation_suites/lib/platform_remote.sh.
• Helpers must consume $E2E_CONTEXT_DIR/context.env; suites must not reinstall, onboard, or rediscover setup state.
• Add/extend suite family entries in test/e2e/validation_suites/suites.yaml.
• Add onboarding profiles/test plans/onboarding assertions only when the behavior belongs before expected-state validation.
• Emit stable assertion IDs using <layer>.<domain>.<behavior>.
• Preserve compatibility with existing run-scenario.sh <id> --plan-only behavior.
• If parity-map metadata still exists in the target branch, update test/e2e/docs/parity-map.yaml with layer, gap_domain, owner, and runner/secret requirements where applicable. If the parity workflow/map has been removed, capture the same metadata in the current scenario coverage/reporting mechanism instead.

Spec requirements for /vd_spec

The generated spec should include:

1. A coverage inventory mapping every item above to one of: covered, new assertion, deferred, or retired.
2. A scenario/test-plan design for each covered or new assertion item.
3. Stable assertion IDs for each migrated/new check.
4. Runner/secret/platform requirements for each scenario, including GPU, Brev, DGX Spark, macOS, WSL, and NVIDIA API key requirements where applicable.
5. A validation spec that states which commands/workflows must pass, which scenario IDs are expected to be runnable, and which are intentionally skipped/deferred due to unavailable platform/secrets.
6. Clear pass/fail expectations for the implementation PR: what should pass on the PR branch, what should fail on main or remain unimplemented if the PR is only adding coverage, and what evidence should be attached.

Validation expectations for the implementation PR

The PR opened from this work should include evidence that:

• Scenario framework/unit validation passes locally for resolver/schema/suite/coverage-report behavior.
• run-scenario.sh <id> --plan-only works for each new or changed platform/remote scenario.
• The GitHub E2E scenario workflow runs on the PR branch and shows the relevant scenario jobs/checks passing, failing, skipped, or deferred according to the validation spec.
• Any expected failures are intentional and documented in the PR body or validation artifact, with clear follow-up items if they cannot be made green in the same PR.
• Platform-specific scenarios that cannot run on the default PR infrastructure are still represented with metadata and plan-only validation, and are marked as deferred/manual with the exact runner/secret requirement.

Acceptance criteria

• Domain primitive helpers exist and are used by migrated suite steps.
• At least the highest-value assertions from the listed legacy coverage are mapped to stable scenario assertion IDs.
• New merged platform/remote bugs/features listed above are explicitly accepted into scope, deferred, or rejected with rationale.
• Remaining legacy assertions are explicitly classified as deferred or retired with layer/domain metadata.
• Scenario framework tests pass for resolver/schema/suite/coverage-report validation.
• The coverage report makes this domain visible as covered, deferred, or retired.
• The implementation PR includes the validation evidence described above, including E2E scenario workflow results on the PR branch.