✨🧑‍💻 - feat select reusable runner profiles in setup and reconcile source workflow parity #556

Is there an existing issue or feature request for this?

• I have searched the existing issues and feature requests.

What area does this improvement affect?

New Feature

What actions does this improvement affect?

Issue, Pull Request, Commit

Description of the idea or improvement

Add an intuitive runner-selection step to single-repository and multi-repository setup, plus an audit and reconciliation path for differences between Copilot's own installation and clean consumer installations.

Proposed journey:
Confirm target(s) → reuse compatible configuration → choose an execution profile → review job routing and missing prerequisites → review repository diffs → create installation PR(s) → merge and verify.

1. Offer GitHub-hosted defaults, reuse of an existing organization profile, and selection/manual definition of an existing self-hosted profile. For vypdev, support reusing the profile already used by copilot: group vypdev with self-hosted/codex/Linux labels for agent jobs. Show a plain-language explanation and the effective YAML before Apply.
2. Reuse one organization profile across explicitly selected repositories, with visible repository exceptions. Use typed, bounded configuration and documented precedence. Reusing a profile must preserve existing shared Variables, Secret bindings, runner-group access and unrelated repository memberships.
3. Separate execution needs: agent jobs, ordinary validation, trusted approval observers, and release/publication jobs. Do not apply one runs-on value blindly to every job. Preserve isolated observers and hosted OIDC publication requirements. Explain which jobs require a pre-authenticated agent runner.
4. Discover eligible runner groups/labels where read access is available. Keep basic setup usable with an exact manual profile when optional organization inventory permission is unavailable. Distinguish an unavailable runner, a busy/offline runner and unknown repository/group access. Never silently fall back to a different execution environment or grant new access.
5. Audit the capability/asset inventory of source and consumer installations: workflows, health/provisioning checks, Issue Forms, repository profiles, agent guidance and relevant configuration. Show each item as shared/generated, an intentional source-only extension, missing, customized or incompatible with the installed generator version.
6. Define a shared schema/rendering contract with explicit source exceptions. Copilot's root-local Action checks, deployment coordination, release/npm jobs and native CI must remain reviewable. Reconciliation must not replace them with generic consumer templates or regenerate version-incompatible guidance silently.
7. Provide a reviewed migration and drift-repair path: inspect the complete diff, retain backups and human customizations, use a compatible generator/version, and prove repeated setup is idempotent. Document intentional source-only differences rather than treating every difference as missing functionality.

Acceptance:

• One guided session can reuse the copilot runner profile for platform and other selected organization repositories, while showing per-repository readiness and exceptions.
• The same planning decisions and blocked/pending states are shared by CLI and web.
• Profiles do not read/copy Secret values, overwrite shared configuration, broaden group access or weaken approval/publication protections.
• A busy/offline runner is reported as pending capacity; unsupported or unverifiable routing has a specific recovery action.
• Source parity checks identify missing assets and intentional extensions, and detect loss of shells, branch observers, source Action references, release jobs or incompatible profile metadata before Apply.
• Numeric initial test floor: 48 distinct cases, distributed across profile validation/precedence (10), job routing and isolation (10), discovery/access failure (8), source/consumer parity and version compatibility (8), CLI/web UX (6), and migration/idempotency/partial recovery (6). New pure decisions need full branch coverage; retain existing repository budgets.
• Controlled live acceptance covers a clean consumer, organization-profile reuse across selected repositories, and an existing source installation. Include docs, accessible UI/content examples and executable acceptance criteria in the Action-managed SDD before implementation.

Current limitations or challenges

Setup currently installs ubuntu-latest templates and expects operators to adapt runner routing manually. Reusing Variables and Secrets alone does not select the runner on which Codex is authenticated. A generated workflow can therefore reach an authentication failure even when its existing credentials were correctly retained.

Copilot's source workflows contain root-local ./ Action execution, native validation, coordinated release/npm jobs and other customizations that differ from clean consumer templates. A full audit is needed to identify genuinely missing YAML/configuration and record intentional exceptions.

Real dogfooding in #538/#546 demonstrated the risk. The first installation previews (#550 and vypdev/platform#170, closed without merge) replaced installed runner routing and source workflows. The corrected operation produced #555 and vypdev/platform#175 and proved runner retention, exact receipts and unchanged resource namespaces. Source-installation CI also exposed overly broad push-filter changes, loss of an explicit bash shell in merge-queue rendering, and profile/generator-version mismatch. These findings should become compatibility fixtures in the parity audit, alongside the immediate regression fixes in #546.

This issue is the follow-up for explicit runner selection and systematic source/consumer reconciliation. It does not replace #538/#546 or authorize a release, automatic merge, access expansion or vulnerability remediation.

Expected impact

Developers can extend a working organization installation without guessing runner labels or editing each generated YAML by hand. The preview makes execution location, authentication prerequisites and pending capacity understandable before installation.

Maintainers gain an explicit inventory of why copilot differs from consumer repositories. Shared behavior can evolve consistently while preserving source-only validation and release safeguards. Repeated setup becomes a controlled drift check instead of a source of accidental workflow regressions.

Alternatives considered

A single global runs-on replacement is insufficient: agent, observer, CI and publication jobs have different trust and runtime requirements.

Copying all of copilot's own workflows into consumers would also copy repository-specific release/validation behavior. Prefer reusable execution profiles and a shared configuration/rendering contract with explicit source extensions.

Keep manual YAML editing as a supported advanced escape hatch, with clear ownership and drift reporting. Do not require broad organization-admin permissions merely to enter an exact known profile.

Version of copilot

v3.5.6; organization-reuse/batch dogfooding in #538 / #546

Additional context or comments

Requested by the maintainer during live setup dogfooding on 2026-10-17. Primary references: #538, #546, #555 and vypdev/platform#175. Proposed default: retain reviewed existing routing when available, otherwise show the hosted default explicitly; self-hosted selection remains an explicit choice. Preserve the current Action-owned issue/branch lifecycle and require normal SDD admission before implementation.

Controlled setup evidence

Copilot installation preview #559 passes all 631 source code suites and retains native Branch Sync, merge-queue shell, release jobs, matching runners and generator-owned guidance. Its Ubuntu smoke then fails workflow validation because newly generated agent-cli-provisioning.yml and copilot_credential_health.yml use ubuntu-latest, while the source validator requires self-hosted, codex. Neither optional workflow exists in the current source checkout/master. This is concrete parity debt for this issue: the chosen profile and role routing must be visible in the preview, with compatible source definitions and validators, before enabling missing workflows. The main #538 acceptance will retain current installed source capabilities instead of silently selecting infrastructure for these new jobs.

Specification boundary and resolved implementation decisions

For SDD recovery after run 39080887942, use a compact companion specification under the existing setup-and-doctor capability (proposed path specs/setup-runner-profiles-and-installation-parity.md). Reference the existing setup, batch/reuse and approval specifications instead of restating them. Retain the complete scope and 48-case minimum above; target about 10,000 characters with the canonical template sections. This is an additive setup capability with its own job-routing and source-parity contract, so a companion is preferable to appending a full new design to the already extensive batch SDD.

Resolved defaults: preserve installed routing unless the operator explicitly selects a replacement; otherwise show the hosted template default. Organization profiles are reusable non-secret configuration, snapshotted into each reviewed installation, with explicit repository exceptions. No runner registration, group membership changes or Secret-value copying is included. Discovery is read-only and optional; unavailable organization inventory remains unknown, and an exact manually entered profile remains supported with an explicit unverified-access notice. Group restrictions by workflow/ref must not be mistaken for confirmed access. The agent profile may select group vypdev with labels self-hosted, codex, Linux; neither labels nor runner authentication establish group access. The independent trusted observer and hosted publication jobs retain their own routes.

The source/consumer inventory found two optional source omissions: agent-cli-provisioning.yml and copilot_credential_health.yml. Native CI, RepoWise, runner diagnostics, hosted platform smoke, root-local Action execution and npm publication are intentional source extensions. Reconciliation must show these classifications, preserve source extensions and compatible customizations, and use reviewed backups/diffs. Validation must retain the fork/merge-group hosted isolation, trusted-default observer checkout, explicit Bash where needed, Branch Sync all-branch coverage and installer exclusions. Vulnerability remediation and release/merge remain outside this issue.