Recommended next

Typical signals

the repo is Windows-heavy and .NET is part of the real operating model
native compiler activation should be part of the contract instead of a hidden shell precondition
task meaning stays stable even when the Windows and Unix launchers differ

Why it matters

it turns a repo pattern into something humans, CI, and agents can read the same way
it makes the next command obvious instead of implied by README drift
it keeps readiness, setup, and execution explainable in receipts and diagnostics

Example contract

Use this when the repo is Windows-first, PowerShell is part of the real release path, and you still want one contract that humans, CI, and agents can trust across platforms.

The example keeps the Windows-native compiler activation explicit through native_prerequisites and visual_studio_dev_shell instead of treating MSVC setup as tribal knowledge.

ota.yamlyaml

version: 1project:  name: WindowsAdoptionFlow  description: Windows-first Ota adoption starter for an existing .NET repotoolchains:  dotnet:    version: "8.0.203"native_prerequisites:  msvc-shell:    platforms:      windows:        visual_studio:          components:            - Microsoft.VisualStudio.Component.VC.Tools.x86.x64        requires:          runtimes:            python: ">=3.10"        activation:          kind: visual_studio_dev_shell          arch: x64tasks:  setup:    prepare:      kind: dependency_hydration      medium: package_dependencies      source:        kind: dotnet_restore        cwd: .    requirements:      native:        - msvc-shell      toolchains:        - dotnet    effects:      writes:        - obj      network: true      network_kind: dependency_hydration  build:    run: dotnet build    depends_on:      - setup    requirements:      native:        - msvc-shell  test:    run: dotnet test    depends_on:      - build    safe_for_agent: true    requirements:      native:        - msvc-shell  docs:check:    run: test -f docs/windows-first.md && test -f docs/release-checklist.md    variants:      - when:          os: windows        run: powershell -NoProfile -Command "if (!(Test-Path 'docs/windows-first.md')) { exit 1 }; if (!(Test-Path 'docs/release-checklist.md')) { exit 1 }"  release:    run: ./scripts/release.sh    variants:      - when:          os: windows        run: powershell -NoProfile -ExecutionPolicy Bypass -File scripts/release.ps1    depends_on:      - test      - docs:checkworkflows:  default: app  app:    setup:      task: setup    run:      task: test

Task notes

Use ota doctor ., ota up --dry-run ., and ota proof runtime --workflow app . in that order. This is the flagship example for the Windows-native trust path, not a Unix contract with a Windows footnote.

The important boundary is that Ota owns the activation truth. Users should not need to remember to open the right developer shell before the selected path can work.