Privileged webhook-triggered automations should use
`.github/automations-dispatch.json` instead of `pull_request_target`.
Document that `dangerous-triggers` must not be suppressed and that
unsupported events require a separate dispatcher change.

Co-authored-by: Zanie Blue <[email protected]>

## Summary

Like #20972 but for the new version.

## Test Plan

NFC.

Signed-off-by: William Woodruff <[email protected]>

Applying `bot:rebase` to an open, same-repository pull request
dispatches the existing trusted rebase workflow with the current head
SHA. Remove the label after dispatch succeeds so another rebase can be
requested later.

---------

Co-authored-by: Zanie Blue <[email protected]>

…python) (#20876)

The `--bare` opt-in example in `docs/concepts/projects/init.md` passes
`--python-pin`:

```
uv init example-bare --bare --description "Hello world" --author-from git --vcs git --python-pin
```

But `--python-pin` is not a valid flag. The argument is `--pin-python`
(`pin_python` in `crates/uv-cli/src/lib.rs`, with its `--no-pin-python`
counterpart); `--python-pin` appears nowhere in the CLI definition, so
`clap` rejects it with `unexpected argument --python-pin found`.

In context, every other flag on that line re-enables a feature `--bare`
disables (`--description`, `--author-from`, `--vcs`); the flag that
re-enables the pinned `.python-version` file is `--pin-python`. This
corrects the transposed token.

Docs-only, no functional change.

Signed-off-by: William Woodruff <[email protected]>

Issue context currently starts from a mechanically generated README,
which prevents triage agents from presenting their findings as a
coherent document. Initialize each linked issue branch with a
header-only template, let the triage agent author the complete README,
and preserve the structured result while keeping privileged branch
creation separate from the agent.

---------

Co-authored-by: Zanie Blue <[email protected]>

Issue triage currently identifies related reports and classifies each
issue, but maintainers still have to write a response from scratch. Add
a required `draft_response` to the triage output, instruct the agent to
write concise, evidence-backed replies in an open-source maintainer
voice, and include the draft in the issue-context `README.md` for
maintainer review without posting it automatically.

---------

Co-authored-by: Zanie Blue <[email protected]>

…agnose-workflow-failure (#20974)

## Summary

The `fast-build` test profile sets `opt-level = 1`, which implicitly
enables local ThinLTO across each crate's codegen units. Explicitly
disable local ThinLTO so this profile prioritizes faster compilation.
The `fast-build-nightly` profile used by Linux, macOS, and Windows CI
inherits the change; ordinary development, profiling, and release builds
are unchanged.

Also include the root `Cargo.toml` in each test job's Rust cache key.
`rust-cache` hashes workspace package manifests by default, but our
virtual workspace root contains the profile settings and is omitted from
that hash. Without the explicit root-manifest hash, CI can restore an
exact cache hit containing artifacts from the previous profile and skip
saving updated artifacts. Windows partitions continue sharing their
cache.

## Benchmarks

Medians from six recent warm-cache `main` runs and five warm-cache PR
runs, matched by platform and Windows partition. All 55 jobs had exact
cache hits and ran the same tests; the initial cache-population run is
excluded. CI sets `CARGO_INCREMENTAL=0` throughout. Compilation is
Cargo's reported build time, test execution is Nextest's reported
runtime, and total is the GitHub `Cargo test` step. Percentages use
unrounded medians.

| Job | Compilation | Test execution | Total |
| ----------- | ----------------------: | ----------------------: |
---------------------: |
| Linux | 56.5 → 42.8 s (-24.3%) | 92.6 → 92.5 s (-0.1%) | 149.5 → 136 s
(-9.0%) |
| macOS | 64.0 → 45.1 s (-29.5%) | 251.0 → 250.7 s (-0.1%) | 318.5 → 298
s (-6.4%) |
| Windows 1/3 | 102.5 → 74.0 s (-27.8%) | 89.4 → 93.5 s (+4.6%) | 195.5
→ 171 s (-12.5%) |
| Windows 2/3 | 111.0 → 92.0 s (-17.1%) | 60.6 → 63.8 s (+5.2%) | 183.0
→ 161 s (-12.0%) |
| Windows 3/3 | 112.5 → 72.0 s (-36.0%) | 73.1 → 80.4 s (+10.1%) | 192.5
→ 165 s (-14.3%) |

The Windows partitions run concurrently; their median critical path
decreases from 205.5 s to 186 s (-9.5%). Test execution is effectively
unchanged on Linux and macOS and somewhat slower on Windows, but every
job is faster overall. Runner speed varies between jobs, so the
comparison uses per-platform medians instead of individual runs.

Signed-off-by: William Woodruff <[email protected]>

Interpreter cache-key construction reads `/proc/sys/kernel/ostype` for
every Python lookup, which becomes unexpectedly expensive when procfs is
backed by FUSE. On an affected devbox, each read takes approximately 27
ms, compared with approximately 3 µs for `uname`; commands that discover
interpreters twice avoid roughly 54 ms of overhead. Use `uname` to
obtain the same Linux OS type directly while preserving existing
interpreter-cache keys.

Co-authored-by: Zanie Blue <[email protected]>

Issue context currently captures triage and reproduction findings but
does not incorporate useful information added later in issue comments.
Resume the existing Codex investigation for each new comment and update
the context only when the new information materially improves the
maintainer handoff; leave unrelated or repetitive comments untouched.

---------

Co-authored-by: Zanie Blue <[email protected]>

Linux users can encounter tens of milliseconds of avoidable startup
latency when `uv` initializes `WorkspaceCache` after spawning its
`main2` thread, even when dependency caches are warm.

`WorkspaceCache::default()` constructs an
[`uv_once_map::OnceMap`](https://github.com/astral-sh/uv/blob/f60ba1f0c5dd216f7517170f7fe2543b3e512fcd/crates/uv-once-map/src/lib.rs#L147-L153),
which builds a
[`papaya::HashMap`](https://github.com/ibraheemdev/papaya/blob/v0.2.4/src/map.rs#L224-L233)
and initializes a
[`seize::Collector`](https://github.com/ibraheemdev/seize/blob/v0.5.1/src/collector.rs#L29-L37).
On Linux, the collector [registers
`MEMBARRIER_CMD_REGISTER_PRIVATE_EXPEDITED`](https://github.com/ibraheemdev/seize/blob/v0.5.1/src/raw/membarrier.rs#L183-L198)
so concurrent readers can use lighter-weight memory barriers.

[RCU (read-copy-update)](https://docs.kernel.org/RCU/whatisRCU.html) is
a Linux kernel synchronization mechanism that lets existing readers
finish before shared state is safely updated or reclaimed; the time
spent waiting for those readers is an RCU grace period. The kernel's
[`membarrier` registration
code](https://github.com/torvalds/linux/blob/v7.0/kernel/sched/membarrier.c#L438-L466)
has an inexpensive fast path when the process has only one address-space
user (`mm_users == 1`). Once `main2` exists, it instead calls
`synchronize_rcu()` and waits for a grace period before updating
scheduler state. [The kernel documentation
explains](https://docs.kernel.org/RCU/Design/Requirements/Requirements.html)
that these waits favor throughput over latency and can add several
milliseconds.

Construct `WorkspaceCache` before spawning `main2`, while the process
can still use the kernel's single-threaded fast path, and pass the same
cache into command execution. This preserves the existing `uv::run`
entry point and `papaya`'s concurrent behavior.

On Namespace runners, warm, offline `uv workspace metadata --sync
--script` invocations of the original Prefect scripts improved as
follows. Each result is the median of 15 interleaved samples, reported
as before → after:

| Runner | `all_links_should_be_ok.py` | `wait-for-server.py` |
| -------------- | --------------------------- |
------------------------ |
| Linux, 1 CPU¹ | 49.6 → 30.9 ms (−37.6%) | 344.8 → 329.6 ms (−4.4%) |
| Linux, 2 CPUs¹ | 44.4 → 28.5 ms (−35.7%) | 279.7 → 262.2 ms (−6.3%) |
| Linux, 4 CPUs | 40.9 → 27.3 ms (−33.2%) | 252.0 → 236.4 ms (−6.2%) |
| Linux, 8 CPUs | 47.8 → 24.6 ms (−48.5%) | 247.2 → 225.1 ms (−8.9%) |
| Linux, 16 CPUs | 48.5 → 24.2 ms (−50.1%) | 249.2 → 231.9 ms (−7.0%) |
| macOS, 12 CPUs | 19.9 → 19.9 ms (+0.4%) | 215.2 → 218.1 ms (+1.4%) |

¹ CPU affinity on the four-core Namespace runner. [Benchmark workflow
run](https://github.com/astral-sh/uv-dev/actions/runs/31107699452).

---------

Co-authored-by: zaniebot <[email protected]>
Co-authored-by: Zanie Blue <[email protected]>

`uv workspace metadata` currently serializes the entire pretty-printed
response into a `String` before writing it, adding a full-response
allocation for large workspaces. Serialize directly into a buffered,
locked standard-output stream instead, while preserving the existing
JSON formatting and output suppression behavior.

On Namespace, I measured `uv workspace metadata --offline --frozen` with
optimized `profiling` builds and stdout redirected to `/dev/null`. Each
version was measured in 41 interleaved rounds after warmups. Values are
means; changes are relative to `main`, with paired-bootstrap 95%
confidence intervals from 20,000 resamples.

Wall time (ms):

| Workspace | Packages | JSON | `main` | This change | Change (95% CI) |
| --- | ---: | ---: | ---: | ---: | ---: |
| Small: uv | 77 | 0.46 MB | 30.82 | 29.02 | −5.8% [−15.7%, +4.6%] |
| Medium: Prefect | 363 | 2.01 MB | 40.05 | 38.87 | −3.0% [−11.5%,
+6.5%] |
| Large: synthetic | 6,346 | 20.53 MB | 313.10 | 300.21 | −4.1% [−7.2%,
+0.5%] |
| Large: synthetic + environment | 6,346 | 26.80 MB | 425.68 | 403.18 |
−5.3% [−6.3%, −4.2%] |

Peak RSS (MiB):

| Workspace | `main` | This change | Change (95% CI) |
| --- | ---: | ---: | ---: |
| Small: uv | 34.67 | 34.50 | −0.5% [−1.4%, +0.4%] |
| Medium: Prefect | 43.55 | 41.66 | −4.3% [−5.2%, −3.6%] |
| Large: synthetic | 150.64 | 115.38 | −23.4% [−23.8%, −23.0%] |
| Large: synthetic + environment | 164.83 | 132.34 | −19.7% [−19.9%,
−19.5%] |

The small and medium cases use real public uv and Prefect lockfiles. The
synthetic workspace has 4,864 members, 10,242 resolution nodes, and
79,264 dependency edges.

Co-authored-by: Zanie Blue <[email protected]>

Workspace discovery normalized, escaped, and recompiled every exclusion
glob for every candidate member, multiplying work in large workspaces
with long exclusion lists.

Centralize exclusion matching, initialize it only when a candidate needs
checking, and reuse patterns already compiled while parsing
`pyproject.toml`. Patterns that require normalization or absolute
matching retain their existing behavior, including parent-directory
exclusions and workspace roots containing glob characters.

Optimized microbenchmark with 512 members and nonmatching exclusions:

| Exclusions |   Before |  After | Improvement |
| ---------: | -------: | -----: | ----------: |
|         64 |   168 ms |  35 ms |        4.8× |
|        128 |   311 ms | 126 ms |        2.5× |
|        256 |   934 ms | 267 ms |        3.5× |
|        512 | 2,497 ms | 683 ms |        3.7× |

---------

Co-authored-by: Zanie Blue <[email protected]>

`uv workspace metadata --quiet` currently suppresses the JSON response
along with diagnostic output, making the command unusable for callers
that want machine-readable metadata without progress messages. Treat the
metadata response as important stdout so a single `--quiet` preserves
it, while repeated `--quiet` continues to suppress all output.

Co-authored-by: Zanie Blue <[email protected]>

Co-authored-by: Hugo van Kemenade <[email protected]>
Signed-off-by: William Woodruff <[email protected]>

More performance updates from nab, and the uv side of
astral-sh/pubgrub#77. This forwards `difference` through uv's `Range`
wrapper for both the encoded and canonical representations, and uses it
in the batch prefetcher in place of intersecting with complements.

The second commit temporarily pins the pubgrub crates to that branch so
the change builds end to end, and is dropped once the crates release.

On my machine I observed some small speed ups in conflict heavy
scenarios:

| resolve | wall time |
|---|---|
| `pip compile` boto3+awscli, `--python-version 3.6` | -3.5 to -3.9% |
| `lock` boto3+awscli | -2.8 to -3.6% |
| `pip compile` airflow[all], `--python-version 3.8` | no change |
| small warm resolves | no change |

---------

Co-authored-by: konstin <[email protected]>

Automated update for Python releases.

Co-authored-by: astral-automations-bot[bot] <305554984+astral-automations-bot[bot]@users.noreply.github.com>

Co-authored-by: astral-automations-bot[bot] <305554984+astral-automations-bot[bot]@users.noreply.github.com>