Semantic Azure DevOps deep links for BUILDS row columns

[Unthred]

Current behaviour

Historically these BUILDS columns all use PrimaryRun.RunUrl (build results):

• Status
• Branch
• Run #
• Build No.
• PR #

That is technically functional but semantically poor.

Desired principle: "Click the thing you want to investigate."

Desired navigation

Status

Navigate according to the current run state:

State	Destination
Succeeded	Summary/results for that exact Azure run
Building / Queued / active	Live results/progress for that exact Azure run
Failed	Most useful Azure DevOps ERRORS/FAILURE surface for that exact failed run
Partially succeeded	Errors/issues/failure surface for that exact run
Cancelled	Summary/results for that exact run

IMPORTANT: Do not invent an Azure DevOps URL format for errors.

During implementation, investigate the real Azure DevOps navigation model and determine the most reliable supported deep link for a failed build.

• If Azure exposes a stable build-level error/results tab, use that.
• If reaching the useful failure surface requires knowing the failed stage/job, investigate whether existing data is sufficient or whether a small additional API lookup would be required.
• Do NOT automatically turn this into full stage/job timeline monitoring.
• If there is no reliable distinct error URL without substantially increasing scope, document that and propose the best supported fallback.

Run

Example: #491 → build/results page for Azure Build.id 491.

Run # remains Azure Build.id and must never be confused with buildNumber.

Build No.

Example: 20260828.3 → build/results page for the same exact run.

It is fine for Run # and Build No. to navigate to the same build-results page because they identify the same run/build.

PR

Example: #185 → the actual Azure DevOps Pull Request page for PR 185 — NOT the build-results page.

Only make it clickable when reliable PR metadata exists. Never fabricate a PR number or URL.

Branch

Example: master, feature/foo → corresponding branch/repository view in Azure DevOps.

Investigate correct handling of:

• refs/heads/*
• PR merge refs such as refs/pull/*/merge
• source branch metadata on PR builds

For a PR build, if the actual source branch is known, Branch should represent/navigate to that branch.

Do not send a synthetic PR merge ref to a nonsensical branch URL.

Authority

Continue using the authoritative PrimaryRun selected by BuildMonitor.

Attention/previous runs must never replace navigation for the primary row.

Preserve:

• RunId = Azure Build.id
• BuildNumber = Azure buildNumber
• PullRequestNumber = PR identifier
• PrimaryRun authority

Architecture

Do not overload one DeepLinkUrl indefinitely if the row now has multiple semantic destinations.

Investigate an explicit navigation model, e.g. conceptually:

• StatusUrl
• RunUrl
• BuildUrl
• PullRequestUrl
• BranchUrl

Names/design are implementation decisions.

Keep URL construction centralized/testable rather than embedding Azure URL composition in WPF.

Tests when implemented

At minimum:

• Failed Status → verified failure/error destination or documented supported fallback
• Succeeded Status → exact current run
• Active Status → exact current run
• Run # → exact Build.id
• Build No. → same exact run while remaining distinct display identity
• PR # → actual PR URL
• non-PR → no fake PR link
• Branch → actual source branch where reliable
• PR merge ref does not create bogus branch navigation
• attention run cannot replace PrimaryRun navigation
• URLs contain no PAT/secrets

Non-goals

• No full timeline UI
• No log scraping
• No Azure writes
• No redesign of BUILDS
• No implementation on #90: Soft apply remount without rebuild #93 — historical all-columns → RunUrl remains until this issue

Related

• Complements Configurable status-window visibility during active builds #94 (status-window visibility during builds) and hyperlink-stability work on #90: Soft apply remount without rebuild #93 (AgeDisplay urgent-rebuild fix only)