[aui]: add new port

.github/dependabot.yml

@@ -0,0 +1,11 @@
+version: 2
+updates:
+  - package-ecosystem: "github-actions"
+    directory: "/"
+    groups:
+      github-actions:
+        patterns: ["*"]
+    schedule:
+      interval: "weekly"
+    cooldown:
+      default-days: 7

.github/skills/analyze-ci-failures/SKILL.md

@@ -1,29 +1,28 @@
 ---
 name: analyze-ci-failures
 metadata:
-   version: 2025-05-07
+   version: 2026-08-14
 description: >
-  Analyze vcpkg Azure DevOps CI failures. Downloads logs, identifies regression root causes,
-  generates a report by package and triplet.
+  Analyze collected vcpkg CI failure evidence, classify regressions and known failures, identify root
+  causes, recommend actions, and generate a report by package and triplet.
 
-  USE FOR: CI failure analysis, regression triage, log diagnosis.
+  USE FOR: explicit requests for CI regression triage, a failure inventory, baseline classification,
+  action recommendations, or a formal CI failure report.
 
-  DO NOT USE FOR: general coding, creating ports, modifying portfiles.
+  DO NOT USE FOR: fetching logs as the final output, targeted debugging of one failure, answering a one-off
+  question about logs the user pasted or pointed at, general coding, creating ports, or modifying portfiles.
+  When requested analysis lacks local evidence, run fetch-vcpkg-ci-logs as the acquisition stage first.
 
-  **UTILITY SKILL** INVOKES: Azure DevOps REST API, PowerShell.
+  **ANALYSIS SKILL** USES: locally collected CI logs, vcpkg baselines, Azure DevOps metadata.
 ---
 
 # vcpkg CI Failures Analyzer
 
-## When to Use
-
-- Investigating CI failures on Azure DevOps
-- Identifying regressions in a PR or scheduled build
-- Triaging root causes before assigning bugs
-
 ## Overview
 
-Fetches build metadata and failure logs via Azure DevOps REST API, cross-references with baselines, produces a regression report.
+Consumes already-collected CI evidence, cross-references it with baselines, and produces a regression
+report. If evidence has not yet been collected, invoke `fetch-vcpkg-ci-logs` first, then return to this
+workflow. Do not duplicate its acquisition steps here.
 
 ## MCP Tools
 
@@ -33,59 +32,56 @@ Fetches build metadata and failure logs via Azure DevOps REST API, cross-referen
 
 ## Prerequisites
 
-- **GitHub MCP server** — needed for PR URL input
+- Local failed step logs and relevant extracted failure-log artifacts.
+- Build metadata and full Azure build URL.
+- For PR builds, PR metadata and full PR URL.
+
+## Evidence Acquisition
+
+When the required evidence is not already local, delegate acquisition to a subagent using
+`fetch-vcpkg-ci-logs`. Prefer a fast, low-cost model for this mechanical work. Ask
+the subagent to return only the evidence inventory and local paths; keep regression analysis and report
+generation in the main agent.
+
+When the evidence is already available locally, proceed directly to analysis.
 
 ## Workflow
 
-> **OUTPUT RULE**: Write `report.md` as SOON as step-log analysis (Phase 1) completes. Do not wait for artifact downloads. You can update the file later. Your response MUST also contain the complete report content — not a summary.
+> **OUTPUT RULE**: This skill applies only when the user asked for triage or report output, so a `report.md`
+> is always required once it is selected. Write it as soon as step-log analysis completes, then enhance it
+> from artifacts. Your response MUST also contain the complete report content — not a summary.
 
 > **URL RULE**: Your response text (not just the report file) MUST include:
 > - For scheduled/manual builds: the full Azure DevOps URL `https://dev.azure.com/vcpkg/public/_build/results?buildId={buildId}`
 > - For PR builds: both the full PR URL `https://github.com/microsoft/vcpkg/pull/{prNumber}` AND the Azure DevOps build URL
 
-Before doing Azure-specific work, read `.\.github\skills\shared\azure-vcpkg-ci-notes.md` and follow its shared API and log-handling rules.
-
-When you use the shared helper script, execute the `.ps1` file directly by path. Do **not** open the script and inline its contents into a large PowerShell block.
-
-### Phase 1: Extract failures from step logs (REQUIRED — do first)
-
-1. **Parse input** — Extract `buildId` from Azure DevOps URL. For PR URLs:
-   ```powershell
-   $prNumber = 51515
-   $builds = (Invoke-RestMethod "https://dev.azure.com/vcpkg/public/_apis/build/builds?reasonFilter=pullRequest&repositoryType=GitHub&repositoryId=microsoft/vcpkg&branchName=refs/pull/$prNumber/merge&api-version=7.0").value
-   $buildId = ($builds | Sort-Object -Property id -Descending | Select-Object -First 1).id
-   ```
-   See [references/azure-devops-api.md](references/azure-devops-api.md).
-   For PR inputs where you want the failed step logs immediately, you may instead use the shared helper script:
-   ```powershell
-   & '.\.github\skills\shared\Get-VcpkgAzureFailureLogs.ps1' -PrNumber <pr>
-   ```
-2. **Fetch metadata** — Build info, timeline, and artifacts list (parallelize these API calls).
-3. **Scan step logs** — For each failed job, find `"*** Test Modified Ports"` task and fetch its log:
-   ```powershell
-   $logText = Invoke-RestMethod "$($task.log.url)?api-version=7.0"
-   $regressions = $logText -split "`n" | Where-Object { $_ -match 'REGRESSION:' }
-   ```
-   You may also use the shared helper script directly from a build id:
-   ```powershell
-   & '.\.github\skills\shared\Get-VcpkgAzureFailureLogs.ps1' -BuildId <buildId>
-   ```
-   Captures all types: `BUILD_FAILED`, `FILE_CONFLICTS`, `POST_BUILD_CHECKS_FAILED`, `CASCADED_DUE_TO_MISSING_DEPENDENCIES`. **Report every REGRESSION line using the EXACT failure type keyword from the log — never paraphrase.** Also capture 2-3 lines around each error for root cause context. **Extract the triplet name from each failed job** (e.g., from job names like `x64-windows Build` or from log paths) — ensure ALL triplets with failures are listed in your report.
-4. **PR feature-test logs** — PR builds may NOT have `REGRESSION:` lines. Instead scan for `FAIL:` or `failed with` lines showing per-feature failures. Capture and quote verbatim:
+Before analysis, read `.\.github\skills\shared\azure-vcpkg-ci-notes.md`.
+
+### Phase 1: Analyze failed step logs
+
+1. **Inventory evidence** — Confirm the build metadata, failed step-log paths, artifact paths, and triplets
+   available from the acquisition step.
+2. **Scan step logs** — Extract every `REGRESSION:` line and retain exact failure type keywords:
+   `BUILD_FAILED`, `FILE_CONFLICTS`, `POST_BUILD_CHECKS_FAILED`, and
+   `CASCADED_DUE_TO_MISSING_DEPENDENCIES`. Capture 2-3 surrounding lines for context.
+3. **PR feature-test logs** — PR builds may not have `REGRESSION:` lines. Instead scan for `FAIL:`,
+   `failed with`, and feature-test `error:` lines. Capture verbatim:
    - Compiler errors (missing headers, undefined symbols)
    - Post-build check failures (file path issues, misplaced files)
    - Version validation errors
    - Platform-specific feature guard messages
 
    Report each feature failure individually. Dependency ports that fail get their own entry.
-5. **Version validation** — Check `"Validate version files"` task. If failed, scan for version database errors and quote them verbatim. Fix: `vcpkg x-add-version`.
-6. **Write report immediately** — Generate and save `report.md` using all step-log data. This ensures output exists even if later steps time out.
+4. **Version validation** — Inspect the `"Validate version files"` evidence for version database errors.
+5. **Write report immediately** — Generate and save `report.md` using the step-log evidence.
 
-### Phase 2: Download logs and enhance (time permitting)
+### Phase 2: Analyze artifacts and enhance
 
-7. **Download logs** — `Invoke-WebRequest` or curl shell commands for artifact ZIPs (not `web_fetch`). Only download `"failure logs for {triplet}"` — skip `"file lists"`. Extract into `ci-failure-analysis/{scope}/logs/{triplet}/`. If download fails, still create the directory with a placeholder noting the URL.
-8. **Analyze** — Read `stdout-{triplet}.log` last lines. Classify per [references/vcpkg-failure-patterns.md](references/vcpkg-failure-patterns.md). Update report with additional root cause detail.
-9. **Baselines** — Check both `ci.baseline.txt` and `ci.feature.baseline.txt`.
+6. **Analyze artifacts** — Read relevant `stdout-{triplet}.log` tails and supporting logs. Classify per
+   [references/vcpkg-failure-patterns.md](references/vcpkg-failure-patterns.md).
+7. **Baselines** — Check both `ci.baseline.txt` and `ci.feature.baseline.txt`.
+8. **Enhance report** — Add root causes, downstream impact, and actionable recommendations supported by
+   the evidence.
 
 ### Report Requirements
 
@@ -100,23 +96,24 @@ Format per [references/report-template.md](references/report-template.md):
 
 ## Output Structure
 
-```
-ci-failure-analysis/
+Write reports under the session folder from the environment context, alongside the raw evidence, never
+into the repository working tree:
+
+```text
+{session-folder}/files/ci-failure-analysis/
 ├── ci-129315/         ← scheduled build
-│   ├── report.md
-│   └── logs/
-│       ├── x64-windows/
-│       └── arm64-linux/
+│   └── report.md
 └── pr-51202/          ← PR build
-    ├── report.md
-    └── logs/
+    └── report.md
 ```
 
+Raw evidence stays where `fetch-vcpkg-ci-logs` placed it, in
+`{session-folder}/files/ci-failure-logs/`; reference those paths from the report instead of copying them.
+
 ## Critical Rules
 
-- Use `Invoke-WebRequest` or curl shell commands for ZIPs — `web_fetch` can't download binaries
-- Artifact type is `PipelineArtifact` — Container API won't work
-- Scan step logs first — `FILE_CONFLICTS` only appear there
+- Do not fetch or download logs as part of this skill; use the acquisition skill first.
+- Scan step logs first because `FILE_CONFLICTS` may appear only there.
 - Check **both** baseline files
 - Never suggest `<=` version constraints or `VCPKG_BUILD_TYPE release`
-- If artifact download fails, still create `logs/{triplet}/` directory with a placeholder noting the download URL
+- Clearly distinguish proven root causes from hypotheses and requests for additional diagnostics.

.github/skills/fetch-vcpkg-ci-logs/SKILL.md

@@ -0,0 +1,73 @@
+---
+name: fetch-vcpkg-ci-logs
+metadata:
+   version: 2026-08-14
+description: >
+  Fetch vcpkg Azure DevOps metadata, failed-step logs, and selected artifacts.
+  Use for acquiring CI evidence, not diagnosing or reporting regressions; use
+  analyze-ci-failures for those tasks. Skip when supplied logs are sufficient.
+---
+
+# Fetch vcpkg CI Logs
+
+First read and follow `.\.github\skills\shared\azure-vcpkg-ci-notes.md`. For endpoint shapes, artifact
+naming, and ZIP layout, see [references/azure-devops-api.md](references/azure-devops-api.md).
+
+## Prerequisites
+
+- PowerShell with network access. The `vcpkg/public` Azure DevOps project is anonymously readable, so
+  no Azure credentials are needed.
+- GitHub access (`gh` CLI or the GitHub MCP server) — required only to resolve a PR number to its head
+  SHA and check runs.
+
+## Inputs
+
+An Azure build URL/ID or microsoft/vcpkg PR URL/number, optionally narrowed by job ID, triplet,
+port, or artifact.
+
+## Workflow
+
+1. Resolve the build ID from the Azure URL or the PR head SHA's check runs. Preserve `jobId` or `j`.
+2. Fetch metadata, timeline, and artifacts in parallel.
+3. Fetch failed-step logs first by directly invoking:
+
+   ```powershell
+   & '.\.github\skills\shared\Get-VcpkgAzureFailureLogs.ps1' -BuildId <id>
+   & '.\.github\skills\shared\Get-VcpkgAzureFailureLogs.ps1' -PrNumber <pr> [-JobId <job>]
+   ```
+
+   Save its raw output as `failed-step-logs.txt`. Ensure every failed `Validate version files` timeline
+   record is included; if the helper omits one, fetch its exact `log.url` and append the raw body.
+4. Unless only step logs were requested, download relevant `failure logs for {triplet}` ZIPs from each
+   artifact's `resource.downloadUrl`. Narrow by the requested job, triplet, or port; fetch other
+   artifacts only when requested. Skip `file lists for {triplet}` unless asked.
+5. Extract each ZIP into `artifacts/{triplet}/`. Keep only the ZIPs that were requested, and record any
+   download or extraction failure with the artifact name and URL instead of retrying indefinitely.
+6. Return the save location, build ID/status, Azure and PR URLs, PR title/author for PR builds,
+   failed jobs/triplets, and errors.
+
+## Downloading Rules
+
+- Download ZIPs with `Invoke-WebRequest -UseBasicParsing` or curl. `web_fetch` **cannot** download
+  binary content.
+- Artifacts are `PipelineArtifact`, not `Container`; use `resource.downloadUrl` directly. The Container
+  API does not work for them.
+- Each ZIP contains one top-level folder named exactly `failure logs for {triplet}`, with one
+  subdirectory per failing port.
+
+## Storage
+
+Store evidence under the session folder provided in the environment context, never relative to the
+repository working directory:
+
+```text
+{session-folder}/files/ci-failure-logs/build-{buildId}/
+├── metadata.json
+├── timeline.json
+├── artifacts.json
+├── failed-step-logs.txt
+└── artifacts/{triplet}/
+```
+
+Prefer the narrowest sufficient scope. Record artifact names and download errors. Do not diagnose
+failures.

.github/skills/analyze-ci-failures/references/azure-devops-api.md → .github/skills/fetch-vcpkg-ci-logs/references/azure-devops-api.md

@@ -10,7 +10,11 @@ All endpoints below are appended to this base. The `vcpkg/public` project is **p
 
 ## API Version
 
-Always append `?api-version=7.0` (or include it in query strings).
+Append `?api-version=7.0` to build, timeline, and artifact endpoints.
+
+> ⚠️ Do **not** force `?api-version=7.0` onto raw **log body** URLs. That can return HTTP 500 even when
+> the log is anonymously readable. Use the exact `record.log.url` from the timeline as-is, or
+> `?api-version=7.1`.
 
 ---
 
@@ -106,11 +110,15 @@ GET https://dev.azure.com/{org}/{project}/_apis/build/builds/{buildId}/logs/{log
 
 Returns plain text of the log. Use this to read the "*** Test Modified Ports" task log, which contains `REGRESSION:` lines for **all** failures including those without artifact logs (e.g., `FILE_CONFLICTS`).
 
+> ⚠️ Prefer the timeline's `record.log.url` unmodified. Appending `?api-version=7.0` to a log body URL
+> can return HTTP 500; use `?api-version=7.1` if you must specify one.
+
 **Finding the right log ID:** Look up the task record in the timeline response — the `log.id` field on the `"*** Test Modified Ports"` task record gives the log ID. Alternatively, use `log.url` directly.
 
 **Scanning for REGRESSION lines:**
 ```powershell
-$logText = Invoke-RestMethod "https://dev.azure.com/{org}/{project}/_apis/build/builds/{buildId}/logs/{logId}?api-version=7.0"
+# Prefer the timeline record's log.url as-is
+$logText = Invoke-RestMethod $task.log.url
 $logText -split "`n" | Where-Object { $_ -match '^REGRESSION:' }
 ```
 

.github/skills/shared/review-vcpkg-pr-guide.md

@@ -28,7 +28,7 @@ The report considers the following in particular:
 2. New ports contain a `"description"` field written in English.
 3. No unnecessary comments.
 4. Downloaded archives are versioned if available.
-5. New ports pass CI checks for triplets that the library officially supports. Determine which triplets are officially supported from the upstream source and build system and, where applicable, upstream documentation found online.
+5. New ports pass CI checks for triplets that the library officially supports. Determine which triplets are officially supported from the upstream source and build system and, where applicable, upstream documentation found online. The `"supports"` field excludes known-incompatible configurations; it need not mirror upstream's documented support matrix.
 6. Patches fix issues that are vcpkg-specific or are submitted upstream (see also "## Patching" in the maintainer-guide).
 7. Sources are downloaded from official sources if available.
 8. New ports package mature projects ready for broad use by meeting one of:
@@ -50,11 +50,11 @@ The report considers the following in particular:
 11. No vendored third-party code is used during the build. List any well-known third-party libraries found in extracted sources.
 12. The versioning scheme in vcpkg.json matches the packaged content.
 13. The license declaration in vcpkg.json matches the content installed by installing a port. Note that content in sources may be skipped in settings in portfile.cmake. If a feature in vcpkg.json installs additional content under a different license, then the feature should have a separate license declared. Treat `"license": null` as an intentional declaration that no SPDX expression is available; inspect the copyright file and installed content instead. When the only available license or copyright notice for a library appears in its header files, patches pass one representative header containing the notice directly to `vcpkg_install_copyright(FILE_LIST ...)`. Do not create a separate text file that copies or extracts the notice from the header.
-14. The generated "usage text" is brief and accurate.
+14. The generated "usage text" is brief and accurate. Custom usage files are only used if not substantially identical to generated usage, which can be checked with `vcpkg print-usage <port> [--generated]`.
 15. Ports do not use system-modifying applications such as sudo, apt, or brew.
 16. Changes in shared build helpers or `scripts/cmake` that affect many ports need explicit justification for why a global change is necessary. Do not edit frozen `scripts/cmake` helpers when a corresponding `vcpkg-*` helper port exists; require ports to adopt the helper port instead.
 17. Ports use `vcpkg_check_linkage` over mutating `VCPKG_LIBRARY_LINKAGE` directly.
-18. Files in the port directory have LF line endings.
+18. Non-patch files in the port directory have LF line endings. Patch files are normally LF-only; CRLF is acceptable in hunk lines that patch CRLF content, as produced by `git diff --output` (ignoring differences in the `index` extended header).
 19. Anything else in the changeset that conflicts with the maintainer guide.
 
 Read the PR description and conversation. Treat them as explanations, motivation, and questions to answer.

.github/workflows/check_issues.yml

@@ -11,7 +11,7 @@ jobs:
     permissions:
       issues: write
     steps:
-      - uses: actions/github-script@v8
+      - uses: actions/github-script@3a2844b7e9c422d3c10d287c895573f7108da1b3 # v9.0.0
         with:
           script: |
             let issue_query = {

.github/workflows/check_tools_sha.yml

@@ -14,7 +14,7 @@ jobs:
 
     steps:
       - name: Checkout repository
-        uses: actions/checkout@v6
+        uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
 
       - name: Bootstrap vcpkg
         run: ./bootstrap-vcpkg.sh

.github/workflows/codeql.yml

@@ -30,9 +30,9 @@ jobs:
           build-mode: none
     steps:
     - name: Checkout repository
-      uses: actions/checkout@v6
+      uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
     - name: Initialize CodeQL
-      uses: github/codeql-action/init@v4
+      uses: github/codeql-action/init@5595ccaf912efad79be6eef63a5619ff05969be3 # v4.37.6
       with:
         languages: ${{ matrix.language }}
         build-mode: ${{ matrix.build-mode }}
@@ -46,6 +46,6 @@ jobs:
         ./vcpkg install alac-decoder breakpad[tools] gettimeofday modp-base64
 
     - name: Perform CodeQL Analysis
-      uses: github/codeql-action/analyze@v4
+      uses: github/codeql-action/analyze@5595ccaf912efad79be6eef63a5619ff05969be3 # v4.37.6
       with:
         category: "/language:${{matrix.language}}"