A whitelist or priority entry was a role name and nothing else, so a run could not ask for "this variant, on swarm, behind the onion". It either covered everything the role offers or waited for the rotation to come around to the combination that broke. An entry is now a token that may carry the axes, either as web-app-x#0,2@swarm+tor or as the job label pasted straight back out of the run that failed. What a token leaves open still belongs to the line it stands in: priority covers every remaining combination in one sweep, whitelist keeps the rotation and its position in the matrix. A pin the row cannot take aborts the matrix rather than dropping the row, because a dropped row reports a green run for a combination that never ran. The onion state spells out as +clearnet, not as a -tor suffix: svc-net-tor would otherwise read as role svc-net on the clearnet. Chunk membership still follows the discovery ranking, which is what decides who makes the budget cut, but the rows inside a chunk are sorted by display name, variant, mode and onion state, so a chunk's job list reads like the plan table instead of like the sweep's rotation. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Workflow Input Resolution 🔎
Shell helpers that derive structured inputs and outputs for GitHub Actions jobs from repository state.
Scope 📋
This directory contains pure resolvers that read repository state (git history, role metadata, version tags, input environment variables) and emit resolved values either via $GITHUB_OUTPUT or stdout. Resolvers MUST be idempotent and MUST NOT mutate repository or registry state beyond writing to $GITHUB_OUTPUT. The covered concerns are distro selection for push CI, diff-driven app whitelist resolution, the 🧩 Subset label dispatch (pr_affected_roles.sh, which picks between the PR-body subset and the diff resolver), release-tag parsing, app discovery for the deploy matrix, and change detection that gates the update pipeline.
For the workflow catalog that consumes these outputs see workflows.md. For the diff-driven whitelist contract see the "Diff-driven app selection" section in pipeline.md.