Purpose of the change

Make Dependabot edit the right pyproject.toml when it bumps a workspace dependency. Today the uv ecosystem entry in
.github/dependabot.yml only lists directory: "/", so Dependabot updates the root manifest and uv.lock but leaves the workspace member manifests (packages/server/pyproject.toml etc.) untouched. The result is a stale specifier line that fails uv lock --check in CI — see PRs #1409 (sentence-transformers), #1410 (cohere), and #1411 (tzdata), all of which bumped only uv.lock.

Description

Switch from directory: (singular) to directories: (plural) and enumerate every uv workspace member declared in the root pyproject.toml's [tool.uv.workspace] members:

• / — root pyproject.toml (dev dependency-groups, [tool.uv] constraint-dependencies)
• /packages/client
• /packages/common
• /packages/server (where the failing PRs' specifiers actually live)

Also add a single uv-workspace group so the weekly run produces one consolidated PR instead of one per dependency, which keeps uv.lock churn in a single diff.

Why this should fix the failing PRs going forward: with each workspace dir explicitly listed, Dependabot's uv ecosystem can locate the matching [project.dependencies] line for a given package and update it alongside uv.lock, instead of bumping only the lockfile's requires-dist mirror.

Note: this does not retroactively repair open Dependabot PRs (#1407, #1408, #1409, #1410, #1411). After this merges, those can be regenerated under the new config by commenting @dependabot recreate on each one (or closed in favor of consolidated bump PRs like #1426).

Fixes/Closes

N/A — root-cause fix for the class of bug seen in #1409, #1410, #1411 rather than a single linked issue.

Type of change

• Project Maintenance (updates to build scripts, CI, etc., that do not affect the main project)

How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration.

• Manual verification (list step-by-step instructions)

Test Results: [Attach logs, screenshots, or relevant output]

YAML schema is validated automatically by GitHub's Dependabot service the moment the branch is pushed (the Dependabot status check on this PR, and the parsed config visible under Insights → Dependency graph → Dependabot). Behavioral verification must occur post-merge because Dependabot only reads its config from the default branch.

Post-merge verification plan:

1. Force an immediate run via Insights → Dependency graph → Dependabot → Check for updates (or wait for the next weekly schedule).
2. Comment @dependabot recreate on Build(deps): Bump tzdata from 2025.3 to 2026.2 #1411 (the simplest case — single dep, single workspace file, single specifier line at
   packages/server/pyproject.toml:36).
3. Confirm the recreated PR's file list now includes both packages/server/pyproject.toml and uv.lock, and that check-lock
   passes.
4. If verified, recreate or close the remaining failing Dependabot PRs accordingly.

Checklist

• I have signed the commit(s) within this pull request
• My code follows the style guidelines of this project (See STYLE_GUIDE.md)
• I have performed a self-review of my own code
• I have commented my code
• My changes generate no new warnings
• New and existing unit tests pass locally with my changes
• I have checked my code and corrected any misspellings

Maintainer Checklist

• Confirmed all checks passed
• Contributor has signed the commit(s)
• Reviewed the code
• Run, Tested, and Verified the change(s) work as expected

Screenshots/Gifs

N/A

Further comments

If this config change turns out not to fix the workspace gap (i.e. Dependabot still leaves packages/server/pyproject.toml stale after a @dependabot recreate on #1411), the fallback is to promote frequently-bumped workspace deps into the root [tool.uv] constraint-dependencies block, following the pattern in #1426. The directories: approach is the lower-friction first try.

Separately noted but not addressed here: .github/workflows/check-uvlockfile.yml checks out main instead of the PR head, so it currently passes regardless of the PR's actual lockfile state. That's a follow-up.