Design the WSL-to-Windows Azure DevOps authentication Slice and contracts

[hcoona]

Goal

Complete the detailed design and contracts for one authentication Slice: a WSL caller directly invokes the Windows CLI to acquire an Azure DevOps access token for an explicitly requested personal Microsoft account or work account. The motivating scenarios are a personal Azure DevOps Git repository and cloning a company Azure DevOps Git repository. Azure Artifacts token acquisition and compatible-state reuse are included because its MSAL resource/scope is the same; its inclusion is settled, not a research decision left open.

This Issue coordinates design work. Only an accepted Delivery Wave entry authorizes advancement; this Issue does not authorize implementation or experiments.

Required outcomes

• Select the concrete Windows runtime/dependency and host integration needed by the Slice, grounded in the accepted high-level architecture and public mechanism evidence.
• Define the versioned CLI request/result/process contract and minimum Client Profile configuration contract, including explicit selection, Windows path/configuration ownership, tenant mapping, and typed failures. Keep account-kind heuristics and consumer service discovery outside the engine.
• Define the cohesive Windows request design: strict account resolution, silent reuse, permitted interaction, provider-result validation, deadline/cancellation, owned UI/completion, caller disconnection, and persistence observations. Use C4 deployment and UML sequence/state views where they resolve a concrete design question.
• Define the concrete candidate Profile and its external-dependency, consent/audit/branding, partitioning, and failure boundaries. Separate design acceptance from Profile activation/distribution and real-platform support evidence.
• Update security analysis and the checked-in TMT model when actual flows or boundaries change; native-model edits require native open/analysis validation.
• Specify scenario and contract validation for both account journeys and Git/Artifacts reuse. Reserve unit tests for core matching, scope, outcome, and lifetime logic. State unsupported combinations and the evidence needed before implementation or support acceptance.
• Activate existing scheduled design/contract record routing only through its required reviewed governance changes, without creating parallel canonical specifications.

Boundaries

One Windows engine process per request; the WSL caller selects the Windows executable. No Linux CLI forwarding/detection, native Linux broker, network bridge, daemon, browser/device-code support expansion, confidential client, service identity, Git credential protocol, repository/organization discovery, package-manager plugin, or service credential lifecycle implementation.

Artifacts is included at the engine's existing access-token boundary. Feed authorization, any NuGet session-token exchange, and package-manager protocols stay in downstream consumers, just as Git repository discovery and credential protocols do. Exact resource tenants and distinct account/Profile/security contexts remain separate even when the Azure DevOps scope matches.

Design and public desk research only. No product code/import, executable experiment, dependency restore/build for a probe, installation, authentication/cache access, company/private repository access, feed access, Profile activation/distribution, packaging, or release. Existing exhausted probe limits are retained. Any later necessary experiment needs separate accepted authorization and an exact protocol before execution.

Acceptance

The Slice has accepted requirements, concrete architecture/design and contracts, scenario validation basis, and explicit unsupported cases with no unresolved material review findings. A choice that lacks a necessary premise remains unselected and cannot be treated as ready for implementation. Complete the design gate before proposing an implementation grant; do not enter implementation automatically.

[hcoona]

PR #58 is accepted on main-v2 and authorizes this Issue's bounded detailed-design and contract outcome. PR #57 is the accepted direct-WSL-to-Windows deployment and Artifacts evidence prerequisite. The high-level architecture grant and #35 are complete.

The next work is concrete Windows request design and CLI/result/Profile contracts, with security analysis, scenario validation for requested personal/work accounts, and explicit unsupported cases. Artifacts acquisition/reuse is already included; package credential exchange and consumer protocols remain downstream. Existing scheduled design/contract record routing will receive its required review before activation. No product implementation, Profile activation, or live authentication/resource experiment is authorized by this design Wave.

[hcoona]

PR #59 is accepted. The Artifacts intermediate conclusions are now consolidated in the existing public-research baseline, with matching architecture and validation updates:

• Direct MSAL access-token return is an opt-in official NuGet provider path; exchange is the upstream default, not a plugin requirement.
• SelfDescribing is an ADO-issued JWT; Compact is a PAT. Upstream default exchange can select Compact after interactive acquisition, so it is not a PAT-free fallback.
• The selected Slice returns the provider access token and excludes PAT acquisition/fallback. Session-token exchange stays outside the engine.
• MSA passthrough and transfer-tenant support are pinned source findings. The accepted personal-account Git result is actual bounded evidence; personal-account NuGet Basic authentication and feed operations remain unobserved.
• The shared Azure DevOps acquisition capability and Artifacts inclusion remain settled. This update adds no experiment, Profile activation, or downstream implementation.

The PR records independent triage, independent research/consistency reviews, and successful repository checks. Subsequent design should consume the current research, architecture, and validation authorities rather than reconstructing this discussion.

[hcoona]

PR #60 merged the owner-requested PAT prohibition as V2-REQ-005. PAT credentials, including Azure DevOps Compact tokens, cannot be a prerequisite, input, acquired/exchanged credential, persisted or returned result, or fallback. Provider-operation semantics enforce the boundary while access tokens remain opaque and permitted delegated acquisition retains its existing policy.

Architecture, user-story routing, research authority links, and scenario validation now reference the requirement. Independent record-system, research-evidence, and contextual reviews found no material issues; local hk and GitHub Repository Controls passed. No implementation, authentication, cache/resource access, or new experiment occurred. The Slice detailed-design and contract work remains open under this Issue.

[hcoona]

The design-only outcome is complete. PR #62 accepted the concrete Windows request design, C4 deployment and UML sequence/state views, protocol 1 request/result contracts, Profile configuration and candidate definition, scenario validation, explicit unsupported cases, and updated native TMT analysis. PRs #59–61 supplied the supporting Artifacts evidence clarification, formal PAT prohibition, and design-record activation prerequisite.

PR #63 closes the completed Delivery Wave grant. Required independent reviews reported no material findings, local hk and PR repository controls passed, and the actual merged-Wave recheck/governance fallback is recorded in PR #63. Native TMT analysis and synthetic contract checks are recorded in PR #62.

No production implementation, Profile activation/distribution, or broader support claim follows from this design acceptance. Further advancement requires a separately accepted Delivery Wave entry.