Azure DevOps

XAML build controllers cannot exist on an Azure DevOps Services organization, but Controllers_List is still published at 7.1 and 7.2 and declares a BuildController[] 200, so the truthful answer is Azure DevOps' empty collection envelope rather than a 404 that would deny the operation exists (founder ruling 2026-09-03, coverage/reviews/2026-09-03-ado-badges-and-controllers.md)

SERVED 2026-09-09: reader.artifactContent, addressed through the timeline record that produced it — {recordId} is the same timeline job id /build/builds/{id}/timeline publishes. FLIPPED from `generate` on 2026-09-09: the ArtifactContent entity has existed since hello-15

no project, build, definition or pull request in this organization carries a property - Azure DevOps entity properties are written by extensions and pipeline tasks through the API and olympus-labs installs none, and this universe accepts no writes; ADO's own answer for an entity with none is {"count": 0, "value": []} at 200. RULED by the founder 2026-09-12 (round 19, the hello-17 coverage audit), as proposed.

SERVED 2026-09-12: YamlBuild is {yaml} and the bytes are ci_config_document.source, the document as its author wrote it - byte-identical to the blob at its own path, which conformance asserts against /_apis/git/repositories/{id}/items

the repository build badge is a pure function of the most recent build for the repo and branch, which this universe has. SERVED 2026-09-03 from the badge markup captured on its two SIBLING operations - this one alone needs a token, so it is the badge row whose body is inferred from the family rather than captured directly, and the review doc says so (coverage/reviews/2026-09-03-ado-badges-and-controllers.md)

refuse — XAML build controllers were removed from Azure DevOps Services; mirroring them would advertise a surface no current client can reach (the ruled GitLab vendor-removed precedent, coverage/reviews/2026-09-01-gitlab-modes.md, certificate-based clusters)

generate — new canon entity ActionsPolicy

generate — new canon entity ActionsPolicy

derive

generate — new canon entity ActionsPolicy

generate — new canon entity RetentionLease

generate — new canon entity RetentionLease

generate — new canon entity ActionsPolicy

SERVED 2026-09-09: reader.artifactContent(artifact) — hello-15's features.ciConfig gave the artifact row its bytes and both digests, and compile.ts throws if any CI artifact lacks them, so the file read hands back exactly what canon holds. FLIPPED from `generate` ("new canon entity ArtifactContent") on 2026-09-09: that entity has existed since hello-15. Pre-hello-15 pins answer the named generation gap

SERVED 2026-09-09: reader.listRuns(repo) filtered to the workflow and taken newest-first; {definition} accepts the definition id or its name, and branchName resolves against the repository's default branch, which is the branch every canonical run builds

the log content itself - reader.jobLogText(job) as text/plain, sliced by the operation's own startLine/endLine

SERVED 2026-09-09: reader.pullsForCommit over the build's own commits, then the issues those pulls closed — the SAME closed_by_pull seam GitPullRequest.workItemRefs reads, so the CI side and the git side name one set of work items

no build and no build definition in olympus-labs is tagged - a build tag is applied by hand or by a pipeline task and this universe accepts no writes; ADO's own answer for a build with none is [] at 200 and for the project-wide list {"count": 0, "value": []} (canon's tag/tag_assignment rows are PagerDuty tags over escalation policies, teams and users). RULED by the founder 2026-09-12 (round 19, the hello-17 coverage audit), as proposed.

no build and no build definition in olympus-labs is tagged - a build tag is applied by hand or by a pipeline task and this universe accepts no writes; ADO's own answer for a build with none is [] at 200 and for the project-wide list {"count": 0, "value": []} (canon's tag/tag_assignment rows are PagerDuty tags over escalation policies, teams and users). RULED by the founder 2026-09-12 (round 19, the hello-17 coverage audit), as proposed.

SERVED 2026-09-09: reader.listBranches over the project's repositories. This organization has exactly one source provider — every repository is a project Git repository, which Azure DevOps calls TfsGit — so any other provider name is the ordinary 404

generate — new canon entity RetentionLease

refuse — nothing in this universe aggregates build metrics, so there is no BuildMetric resource for a definition to name. The COUNTS would derive trivially from reader.listRuns; what cannot be sourced is the vocabulary — BuildMetric.name and scope are provider strings the vendored build.json declares no enum and no example for, and the WORK_ITEM_ICONS precedent is allowed precisely because it cites Microsoft's published sample verbatim. A capture would settle it, on the model of packages/conformance/specs/ado/captures/build-badge.json. RULED by the founder 2026-09-09

SERVED 2026-09-09: the single iteration pullIterations() derives from reader.pullCommits(pull) — canon records a pull request's commits, not the pushes that delivered them, so this universe has exactly one iteration and {iterationId} resolves against that list

SERVED 2026-09-09: reader.pullCommits(pull) — one iteration per pull request, so the iteration's commits ARE the pull request's commits and conformance asserts the two sets are equal

SERVED 2026-09-09: reader.pullLabels(pull), addressed by either half of {labelIdOrName} — the deterministic label guid or the canonical label name

SERVED 2026-09-09: reader.listReviews + reader.pullRequestedReviewers, addressed by the identity guid the reviewers list publishes in each row's reviewerUrl

SERVED 2026-09-09: the single read off the same reader.checksForCommit list /statuses serves; the status context is a canonical check context, asserted in conformance

SERVED 2026-09-09: the single read off that same thread document

SERVED 2026-09-09: reader.checksForCommit over reader.pullCommits(pull), filtered by the iterationId each status already carries, so the pull-request-level list and the iteration-level list cannot disagree

a GitSuggestion is offered to the CALLER — Azure DevOps' "you pushed branch X, open a pull request?" — and this host's caller is the synthetic connection identity connectionDataPayload mints, not a canonical person, so it has pushed nothing and has nothing suggested to it. The same fact `/_apis/teams?$mine=true` and `isCurrentUserEngaged: false` already state. Suggestions_List declares a GitSuggestion[] 200, so Azure DevOps' empty collection envelope is the truthful answer rather than a 404 that would deny the operation exists (invariant #4). RULED by the founder 2026-09-09

SERVED 2026-09-09: the relation types this host emits on a work item (ArtifactLink today), so a work item's `rel` resolves here. `attributes` is omitted rather than guessed — the vendored description declares no values for usage/editable/enabled

SERVED 2026-09-09: the next state after each work item's current one, per the six-state canonical workflow stateOf() already publishes as System.State. A terminal item is reported with `message` and NO errorCode — Azure DevOps sends a code there and the vendored description declares none of its values, so a client cannot be handed one to switch on

SERVED 2026-09-09: the single read off that same list, by deterministic tag guid or by name

SERVED 2026-09-09: the single read off that same table

SERVED 2026-09-09: the single read off that same view — a field the PROJECT has but this TYPE does not is a 404 here while /wit/fields answers it

SERVED 2026-09-09: the 41-icon catalogue render-boards.ts already carries for the single-icon row, which is what makes the icon URL every work-item type prints resolve

SERVED 2026-09-09: reader.listCommits filtered by searchCriteria — author/user, fromDate/toDate, fromCommitId/toCommitId, ids, itemVersion and itemPath (over reader.resolveGitPath, the same trees /items serves). The members that would attach data this host does not hold (includeWorkItems, includeUserImageUrl, compareVersion, the non-default historyMode) answer the coverage error rather than being ignored

SERVED 2026-09-09: the commit's tree against its first parent's, over reader.commitTreeSha/gitTreeEntries/getGitBlob — the same set difference that now produces the changeCounts renderCommitRef publishes, so a commit's counts and its change list cannot drift

SERVED 2026-09-09: renderBranchStats over reader.getBranchByName + reader.listPulls/pullCommits — the single-branch form of the stats operation the Swagger describes as its own path entry

no repository in this universe is a fork and none has been forked: the project owns every repository and there is no collection outside it to fork into — the same fact /repositories/{id}?includeParent=true already reports by omitting parentRepository

refuse — a fork-sync, an import, a cherry-pick, a revert and a merge operation each exist only because a write started one; this universe accepts no writes, so Azure DevOps answers 404 for the operation that was never queued (the ruled GitHub migrations/source-imports precedent, coverage/reviews/2026-09-01-github-modes.md row 4)

SERVED 2026-09-09: the single read off the same renderComments() document, found by the id that list published

SERVED 2026-09-09: exactly one version, and that is a fact rather than a truncation — canon records no comment edit, which is why renderComments has published version 1 since Phase 20

SERVED 2026-09-09: the column names renderBoard() really puts on this project's boards, as BoardSuggestedValue

SERVED 2026-09-09: the same four columns renderBoard() embeds in the board document, so the board and this list cannot describe different columns

SERVED 2026-09-09: the team's tracker issues in that sprint, as the target-only WorkItemLink rows a flat listing uses

generate — new canon entity BoardConfig

SERVED 2026-09-09: the reverse half of that round trip — the key /graph/storagekeys handed back returns the descriptor /graph/users published

SERVED 2026-09-09: reader.listTeams() matched on the one-way vssgp. descriptor renderGraphGroup publishes

SERVED 2026-09-09: reader.teamMembers(team) — the edge exists when canon puts that person on that team, and Azure DevOps' own 404 (the one error response in the whole vendored ADO description) answers when it does not

SERVED 2026-09-09: every subject reader.listPeople/listTeams holds is active — the same fact renderIdentity has published as isActive since Wave D — and a descriptor naming nobody 404s

SERVED 2026-09-09: reader.listPeople() matched on the one-way aad. descriptor renderGraphUser publishes, so the single read and the list describe one subject

generate — new canon entity BoardConfig

derive

derive — an iterations burndown is a pure function of the team sprints and the work item state history this universe already serves; only the image encoding is missing, so the row is derive and deferred rather than a refusal Azure DevOps would never send. STILL DEFERRED after the 2026-09-03 capture wave: the chart-image operations are NOT anonymously reachable - an anonymous request is redirected to the sign-in page, recorded with its 302 in packages/conformance/specs/ado/captures/build-badge.json (`notAnonymouslyReachable`) - so the image format is still unobserved and authoring one would be the invented body the badge rows were held back from (coverage/reviews/2026-09-03-ado-badges-and-controllers.md)

SERVED 2026-09-09: reader.runArtifacts(run) — the Pipelines API's view of the same canonical artifact the Build API serves, one entity over two surfaces. $expand=signedContent stays the explicit refusal: this universe mints no signed URLs

the pipelines-surface Log metadata for one canonical job log; signedContent is refused rather than invented, this universe runs no signed blob store

SERVED 2026-09-09: the project-scoped form of the same reader.listTeams() list, guarded on the project

SERVED 2026-09-10 (hello-16): the team roster as TeamMember — reader.listMemberships("team", team) filtered to state=active, with isTeamAdmin being the maintainer rung of that membership. It reads `membership` rather than `team_member` because `isTeamAdmin` IS a role and the v1 roster table has none; the two agree row for row, which conformance asserts. A pre-hello-16 pin answers the named access generation gap (NO_MEMBERSHIPS), never an empty roster

no repository in this universe has ever been deleted, so the deleted-repository list is truthfully empty — RULED EMPTY by the founder 2026-09-09 (the 2026-09-01 deletion question, coverage/reviews/2026-09-01-ado-modes.md). The WORK-ITEM recycle bin went the other way and was GENERATED in hello-13: work items were deleted in this story, repositories never were

no repository in this universe has ever been deleted, so the repository recycle bin is truthfully empty — RULED EMPTY by the founder 2026-09-09 (the same deletion question, coverage/reviews/2026-09-01-ado-modes.md). Deliberately unlike wit/recyclebin, whose DeletedWorkItem canon hello-13 generated

refuse — a fork-sync, an import, a cherry-pick, a revert and a merge operation each exist only because a write started one; this universe accepts no writes, so Azure DevOps answers 404 for the operation that was never queued (the ruled GitHub migrations/source-imports precedent, coverage/reviews/2026-09-01-github-modes.md row 4)

SERVED 2026-09-09: reader.teamMembers over the team that owns the iteration, at the same 6h/day default the per-team capacity list serves, so the roll-up and the list cannot disagree

refuse — a fork-sync, an import, a cherry-pick, a revert and a merge operation each exist only because a write started one; this universe accepts no writes, so Azure DevOps answers 404 for the operation that was never queued (the ruled GitHub migrations/source-imports precedent, coverage/reviews/2026-09-01-github-modes.md row 4)

refuse — a fork-sync, an import, a cherry-pick, a revert and a merge operation each exist only because a write started one; this universe accepts no writes, so Azure DevOps answers 404 for the operation that was never queued (the ruled GitHub migrations/source-imports precedent, coverage/reviews/2026-09-01-github-modes.md row 4)

refuse — a fork-sync, an import, a cherry-pick, a revert and a merge operation each exist only because a write started one; this universe accepts no writes, so Azure DevOps answers 404 for the operation that was never queued (the ruled GitHub migrations/source-imports precedent, coverage/reviews/2026-09-01-github-modes.md row 4)

no service principal exists in this organization - olympus-labs registers no Entra application and every graph subject is a person or a group (person 17, identity_group 4, and the "service-accounts" group idgroup-004 holds people rather than applications); ADO's own answer for an organization with none is {"count": 0, "value": []} at 200. RULED by the founder 2026-09-12 (round 19, the hello-17 coverage audit), as proposed.

PersonAvatar is canon as of hello-13 (features.avatars): one identicon a person, compiled into the person_avatar table and rasterised by identiconPng. The generate ruling of 2026-09-03 is satisfied, and the same row is what GitHub, GitLab and Jira now serve - byte-identical, asserted in conformance/src/parity/avatar-parity.test.ts

refuse — no service principal exists in this organization, so no service-principal descriptor resolves; ADO's own answer is its 404 for the subject. RULED by the founder 2026-09-12 (round 19, the hello-17 coverage audit), as proposed.

hello-13's DeletedWorkItem canon: two work items were filed and then deleted, so the bin lists their shallow references

the single deleted work item, resource and all, from the same canon row; an id nobody deleted is an ordinary 404

refuse — no team in this project defines a work item template, so no template id resolves; ADO's own answer is its 404 for the template. RULED by the founder 2026-09-12 (round 19, the hello-17 coverage audit), as proposed.

SERVED 2026-09-09: the two levels TYPE_DEFS supports plus the field mapping the backlog is ordered and estimated by; workItemTypeMappedStates comes off the SAME TYPE_DEFS table /wit/workitemtypes publishes

SERVED 2026-09-09: the team's tracker issues filtered to the level's own work-item types; rel/source are OMITTED rather than nulled, because this host renders no portfolio type and canon carries no work-item-to-work-item parent, so a backlog entry has nothing above it to name

SERVED 2026-09-09: reader.getGitBlob(sha) — the objectId IS the sha1 the compiler hashed the bytes to, so a blob id read off /items or /trees fetches here and matches the same file's sha on the GitHub and Bitbucket renderings

SERVED 2026-09-09: reader.resolveGitPath(rootTree, path) + reader.getGitBlob for includeContent; $format=text/octetstream and download=true serve the blob's own bytes, $format=zip answers the coverage error (this host has no archive encoder on the ADO surface)

SERVED 2026-09-12 (hello-18 wave W-b): the Attachment widening landed with features.attachmentParents (decisions/2026-09-12-1148-hello-18-attachment-parents.md) — six ALTERs appending issue/issue_comment/pull/alert/namespace/person to the hello-15 attachment table, so a file now hangs off the engineering records this host publishes. attachmentsForPull() — a BARE ARRAY, which is the git document's own choice here rather than this host's {count, value} envelope. contentHash is a real sha1 over the bytes served (Azure DevOps declares SHA1 where canon measures sha256, so it is computed with the same sha1Raw the git object model uses — a measurement, not a value invented to fill a field), and the url resolves to those same bytes. A pull request that carries no file answers [] rather than a gap

no project, build, definition or pull request in this organization carries a property - Azure DevOps entity properties are written by extensions and pipeline tasks through the API and olympus-labs installs none, and this universe accepts no writes; ADO's own answer for an entity with none is {"count": 0, "value": []} at 200. RULED by the founder 2026-09-12 (round 19, the hello-17 coverage audit), as proposed.

no delivery plan exists in this project - a delivery plan is a view an administrator creates by hand and this universe accepts no writes; ADO creates none with a project and its own answer for a project with none is {"count": 0, "value": []} at 200. RULED by the founder 2026-09-12 (round 19, the hello-17 coverage audit), as proposed.

refuse — no delivery plan exists in this project, so no plan id resolves; ADO's own answer is its 404 for the plan, and the delivery timeline never reaches a plan to render. RULED by the founder 2026-09-12 (round 19, the hello-17 coverage audit), as proposed.

SERVED 2026-09-12 (hello-18 wave W-b): canon.SavedFilter landed with features.savedFilters (decisions/2026-09-12-1139-hello-18-saved-filters.md) — a query whose CLAUSES are canon's and whose TEXT the compiler bakes per host, so saved_filter.query is already JQL on a `jira` row and WIQL on an `ado` one. The project's query hierarchy: EXACTLY TWO ROOTS, which are Azure DevOps' own — every project is created with My Queries and Shared Queries and no others. The shared root holds this project's saved queries; My Queries is honestly EMPTY, and that is a fact about a PER-USER folder rather than about writes — it is scoped to the calling identity, this replica's caller is a synthetic connection identity with no saved state, and a fresh user's personal folder in real Azure DevOps is empty too. $depth fills children in; $expand=clauses is refused explicitly (the parsed clause tree is a re-parse of a text the COMPILER wrote)

SERVED 2026-09-12 (hello-18 wave W-b): canon.SavedFilter landed with features.savedFilters (decisions/2026-09-12-1139-hello-18-saved-filters.md) — a query whose CLAUSES are canon's and whose TEXT the compiler bakes per host, so saved_filter.query is already JQL on a `jira` row and WIQL on an `ado` one. One query hierarchy item by ID OR BY PATH — the document takes both ("ID or path of the query") and both roots are addressable as well as the queries under them. $expand=wiql carries the baked text verbatim, and the columns and sortColumns are READ OFF that same text so the hierarchy and /wit/wiql/{id} cannot disagree about what the query selects

SERVED 2026-09-12: the `new canon entity TeamSetting` ask was stale. Every field of TeamSetting already had a source this host publishes - backlogIteration is the project's root iteration node, defaultIteration is the team's active sprint (the same row /teamsettings/iterations?$timeframe=current returns), backlogVisibilities names the levels backlogLevels() serves and bugsBehavior is the shared BUGS_BEHAVIOR constant renderBacklogConfiguration already prints. workingDays is MEASURED off the canonical event log - the weekdays this team's members really act on, in each actor's own local time - and comes out as all seven on hello-17 rather than the Mon-Fri an Azure DevOps team is created with

SERVED 2026-09-09: the project-level view of the two backlog levels TYPE_DEFS supports, as work-item categories. portfolioBacklogs is empty because this host renders no portfolio work-item type — the same fact the backlog list states

the route is literally "my work": AccountRecentActivityWorkItemModelBase.identityId is "TeamFoundationId of the user this activity belongs to" and activityDate is "Date of the last Activity by the user". This host's caller is not a canonical person, so it has visited and edited nothing — serving the project's work items here would answer a different question from the one asked. The operation declares a model[] 200, so the empty envelope is the truthful answer. RULED by the founder 2026-09-09

ContentReaction is canon as of hello-15 (features.contentReactions); reactionsFor() answers it over issueComment targets, which is what a work-item comment IS here. CommentReactionType is a CLOSED SIX - no rocket, no eyes - so this host renders the six Azure DevOps has and its counts are over those six

SERVED 2026-09-09: the Task type's own states, in the order /wit/workitemtypes/Task declares them; isCustomized is false because nobody in this universe edited them

SERVED 2026-09-12 (hello-18 wave W-b): canon.SavedFilter landed with features.savedFilters (decisions/2026-09-12-1139-hello-18-saved-filters.md) — a query whose CLAUSES are canon's and whose TEXT the compiler bakes per host, so saved_filter.query is already JQL on a `jira` row and WIQL on an `ado` one. RUNS the saved query: the stored WIQL goes through runWiql — the same parser and evaluator POST /wit/wiql uses, not a second execution path — so a query this hierarchy publishes and a query a caller pastes take identical code. That is what closes the debt the saved-filter decision entry named: the compiler holds its own copy of the Agile process's state names beside render-workitems.ts's, a compiler cannot import a renderer, and only running the baked text on this host checks both. The conformance entry posts the same text and asserts the two runs return the same work items

SERVED 2026-09-12 (hello-18 wave W-b): the Attachment widening landed with features.attachmentParents (decisions/2026-09-12-1148-hello-18-attachment-parents.md) — six ALTERs appending issue/issue_comment/pull/alert/namespace/person to the hello-15 attachment table, so a file now hangs off the engineering records this host publishes. The WORK-ITEM stream: attachmentsForIssue() and attachmentsForIssueComment(), which is the same set the Jira host publishes off the same canonical issue (invariant #5 across providers). The declared fileName override and download switch are both honoured; the bytes are attachment.body, whose size and digest the compiler measured off exactly them. A pull-request file is NOT reachable here and a desk file is reachable from neither

generate — new canon entity BranchRestriction