repomatic 7.16.2__tar.gz → 7.16.3__tar.gz

{repomatic-7.16.2 → repomatic-7.16.3}/.claude/.claude-plugin/plugin.json

@@ -20,5 +20,5 @@
 	"license": "GPL-2.0-or-later",
 	"name": "repomatic",
 	"repository": "https://github.com/kdeldycke/repomatic",
-	"version": "7.16.2"
+	"version": "7.16.3"
 }

{repomatic-7.16.2 → repomatic-7.16.3}/.claude/agents/qa-engineer.md

@@ -42,6 +42,7 @@ Question overly verbose prose in `CLAUDE.md` and `.claude/agents/*.md`:
 - Redundant examples or restated rules — cut them
 - **Discoverable content** — cut it. Structural inventories, code examples copied from source files, and general programming knowledge do not belong in `CLAUDE.md`.
 - **Misplaced knowledge** — move it to the audience that owns it. Lengthy "why" explanations in YAML workflows belong in Python docstrings; YAML gets a brief "what" + pointer. End-user setup details belong in `setup-guide.md`, not `readme.md`.
+- **Code-anchored rules** — move them beside the code. A rule in `CLAUDE.md` whose subject is one function, test, workflow, setting or page belongs in that docstring or comment, where it cannot drift unseen. Compare the two first: delete the rule when the code already states it, and read the code when they disagree. `CLAUDE.md` keeps a one-line pointer.
 
 Prefer mechanical enforcement over prose. If a rule can be a test, autofix job, or lint check — implement it instead of writing it down.
 

{repomatic-7.16.2 → repomatic-7.16.3}/.claude/agents/sphinx-docs.md

@@ -267,6 +267,7 @@ Cross-references that survive renames:
 
 - Always cross-reference external projects through `intersphinx_mapping` and a `{role}` ref, not a bare URL. A renamed function in click-extra surfaces as a Sphinx build error; a bare URL silently 404s in the rendered HTML.
 - For headings, prefer the auto-generated docutils anchor (e.g., `### option.name` → `option-name`). Add an explicit `(my-anchor)=` only when the natural anchor isn't unique or the target isn't a heading.
+- **Qualify a reference that sits in a base-class docstring.** autodoc repeats the docstring of a base-class attribute on each subclass that overrides the attribute. A short `` {attr}`name` `` then resolves against the subclass, and fails for a member the subclass does not define itself. Write the full dotted target.
 
 ## Inline syntax highlighting in prose
 
@@ -590,7 +591,7 @@ Agent tooling toctree, in this order. Drop the whole block when the project ship
 
 Maintainer-facing pages, and when a project carries one:
 
-01. `contributing` — Setup, dev loop, code-style pointers (or `{include} ../contributing.md` if the root file already exists).
+01. `contributing` — Setup, dev loop, code-style pointers (or `{include} ../contributing.md` if the root file already exists). The one home of developer setup: `readme.md` and `claude.md` link to it.
 02. `commit-messages` — Only when automation reads or writes the project's commit subjects, which makes the subject a shared namespace rather than free text: the reserved-prefix rules, who else parses a message, and how to write a subject and body.
 03. `upstream-development` — Project-internal release process. Mark `(upstream maintainers only)` in the page heading so readers know this is not for consumers.
 04. `operation-contracts` — Optional, for projects with formal automated-operation contracts.
@@ -762,6 +763,8 @@ Default-pruning rule:
 - If you keep a setting that *looks* default for documentation purposes, add a one-line comment explaining why ("explicit so future readers see we considered it").
 - On every Sphinx or extension upgrade, run `sphinx-build -W -b html docs docs/_build/html`. Treat every `RemovedInSphinxX.YWarning`, `DeprecationWarning`, and `application.ExtensionError` as cleanup work, not noise. Fix them in the same PR as the upgrade.
 - **Match the deployed builder, which is not always `html`.** `[tool.repomatic] sphinx.builder` is what the Docs workflow passes to `sphinx-build -b`, and a project serving extension-less URLs sets it to `dirhtml` (`page/index.html` instead of `page.html`). Read it before assuming a local `-b html` reproduces CI. The builder is chosen on the command line, so it is the one Sphinx setting `conf.py` cannot carry: never "fix" its absence there.
+- **A warning count only covers the pages that build re-read.** Sphinx reuses cached doctrees, so an incremental rebuild reports the warnings of the changed pages alone, and reading that number against a cold build's count shows a drop nothing caused. A `conf.py` edit invalidates the whole cache, which is why the build right after one reports many more. Build into a clean `_build/` before comparing two counts.
+- **Compare two builds only when both hold the same dependency groups.** autodoc imports each module it documents. A build that lacks one group fails those imports, like the test group for a `tests` API page, and each reference into such a module then reports as unresolved. Build the baseline from an export of `HEAD` and the candidate from the working tree, both with `uv run --isolated --frozen --all-extras --all-groups`: neither touches the shared virtual environment.
 - Periodically diff against a fresh `sphinx-quickstart` output in a tmpdir to spot defaults that have shifted under you.
 - Drop conditional import shims once the project's minimum Python no longer needs them. The `try: import tomllib / except: import tomli` pattern is dead code on `requires-python = ">=3.11"`. Same for any `if sys.version_info < (3, X):` branch where `X` is now below the floor. The deps group should lose the corresponding fallback dependency in the same PR.
 - Always pass `encoding="utf-8"` to `Path.read_text()` calls in `conf.py`. Bare `read_text()` picks up the locale, which on minimal CI runners has bitten many projects.
@@ -856,7 +859,7 @@ When you receive a new "rule" about how to write or maintain docs, ask where it
 - A pattern only the upstream package itself uses (e.g., `docs/docs_update.py` internals, release-only artifacts) → `docs/upstream-development.md`.
 - A pattern downstream Sphinx repos benefit from → this agent definition.
 
-Don't restate `claude.md` rules here. Reference the section instead.
+State a rule that belongs here inline, never as a pointer to a `claude.md` section. This file ships to repositories that do not receive repomatic's `claude.md`.
 
 When a user-driven instruction explicitly conflicts with a `claude.md` or global tropes rule (e.g., the install.md compatibility-matrix range labels use a `→` arrow, which conflicts with the global `Unicode Decoration` anti-pattern), the explicit instruction takes precedence. Note the conflict in your reply so the user can confirm or override, but apply the instruction.
 
@@ -881,7 +884,7 @@ Watch for these every pass:
 - A `{toctree}` that outgrew the ~12-entry threshold and is still flat, or a captioned section left holding a single entry after pages moved around it. See § Grouping pages into sidebar sections.
 - An `automodule` block on a narrative page, repeating what the module's own API page already documents. Every such pair costs a duplicate object description per member and buries the guide's message; see § Guide pages carry the prose, API pages carry the API.
 - Stale `.rst` files in `docs/` left over from package renames or earlier `sphinx-apidoc` runs that reference modules or packages no longer in the source tree. They build silently (autodoc skips missing modules with a warning, not an error) but pollute search results and the modindex. Sweep with `git status` after `update-docs`; delete orphans in the same PR.
-- A `## Development` section in `readme.md` that should have been removed when the project added a `claude.md`. Once `claude.md` exists, the developer-facing setup goes there; keeping a duplicated section in the readme creates two places to update.
+- Developer setup held in `readme.md` (a `## Development` section) or in `claude.md`. Setup, dev loop and test commands belong on the `contributing` page of the roster, where a contributor looks for them. `claude.md` loads into every agent session, so it keeps conventions and links to that page. A second copy creates two places to update.
 - A `dependencies.md` page whose embedded Mermaid graph hasn't been regenerated since the last `uv lock` change. The graph stays in sync only if `repomatic update-dep-graph` is wired into a workflow job; manual regeneration drifts. Upstream that job lives in `_release-engine.yaml` and fires on release commits only, so a graph lagging `pyproject.toml` mid-cycle is expected rather than drift.
 - `pyproject.toml` declaring a docs dependency that's no longer imported by `conf.py` (or vice-versa: importing one not declared). The mismatch passes Sphinx but trips a fresh `uv sync --group docs` run on a CI runner.
 - `click_extra.sphinx.myst_docstrings` listed in `extensions` without `click-extra[sphinx]` declared in `[dependency-groups] docs`. Builds work on the maintainer's machine if the package is installed globally, then break in CI.

{repomatic-7.16.2 → repomatic-7.16.3}/.claude/skills/awesome-triage/SKILL.md

@@ -151,7 +151,7 @@ When drafting a rejection or request-for-changes comment:
 
 For issues reporting broken links (typically automated by the lychee link checker):
 
-- **403 from Medium/Substack**: Bot-blocking responses, not genuine dead links. Ignore unless the content is confirmed gone.
+- **403 from a crawler-blocked domain** (Medium, Substack): not a dead link when a browser still gets the full article. Keep the URL and add the domain to `[tool.lychee] exclude` in `pyproject.toml`, per `contributing.md` § URL. The `[tool.lychee]` template that repomatic syncs already excludes `medium.com`.
 - **404 confirmed dead**: Replace with archive.org/archive.ph/sci-hub.st per `contributing.md` § URL. Replacing a broken URL is maintenance; removing the entry is a curation decision.
 - **Archived GitHub repos**: Check for forks or reboots. If none exist and the section has other entries covering the same ground, the entry can be removed. Leave the door open for re-inclusion if the project revives.
 

{repomatic-7.16.2/repomatic/data → repomatic-7.16.3/.claude}/skills/babysit-ci/SKILL.md

@@ -102,6 +102,8 @@ After fixing (step 5-7), the loop restarts from the top: push, run all three cha
 
    It reads every workflow a push can start (derived from `.github/workflows/`, so its list is wider than the five above), reports each one's latest run, and names the failing jobs that actually gate a merge. Three traps it settles, so no hand-rolled `jq` has to: a run's own `status` lags its jobs (every monitored workflow can read `queued` while a dozen jobs have already finished, which is indistinguishable from the runner-cap saturation a busy account genuinely hits); a `continue-on-error` probe that crashed hides inside a `success` run conclusion; and a run whose `conclusion` is `failure` with *no* failed job is a workflow-level error (an invalid `strategy.matrix` expression, malformed YAML, a missing secret) with no job log to read, which the command flags rather than letting you write off a persistently-red workflow as a known artifact.
 
+   `ci-status` reads the same endpoints as the `gh api` calls above, and it has printed a stale table the same way: re-read a surprising red or green once before acting on it.
+
    Run state *does* gate the run-scoped log read (step 4): `gh run view --log-failed` refuses to answer until the parent run reaches a terminal state. A completed job's own log is readable at once.
 
    **A queue is not a hang, and elapsed time alone cannot tell them apart.** A long stall invites the theory that some run is stuck and that cancelling it would free the pool, which is a conclusion worth reaching only on evidence, because acting on it destroys work that was progressing fine. Two readings settle it, and neither is the elapsed clock. Get a **baseline** from that workflow's recent successful runs (`gh run list --workflow <wf> --repo <owner/repo> --status success --json createdAt,updatedAt`): a suite whose normal duration is two hours is not hung at ninety minutes. Then read **per-job `completedAt` timestamps** (`gh run view <id> --json jobs`) rather than an aggregate: a flat count of `in_progress` jobs is not evidence of a stall, since jobs finish and others start into the freed slots, holding the count steady while real progress continues. Watch for the self-contradiction that exposes the mistake, a report that the count "dropped from 11 to 9" *and* that nothing has changed. Two smaller traps live here too: `gh` reports a pending job's `conclusion` as `""`, not `null`, so a `select(.conclusion == null)` filter silently matches nothing and reads as "no pending jobs"; and jobs queue against the runner pool their `runs-on` names, so a stall confined to macOS cells says nothing about Linux capacity. **Never cancel another repository's run to free slots without the maintainer's explicit go-ahead**, and never ask for that go-ahead on a diagnosis you have not backed with a baseline and timestamps.
@@ -284,6 +286,8 @@ Not all CI failures are code bugs:
 
 For infrastructure, re-run the failed jobs (`gh run rerun <RUN_ID> --failed`) and continue polling; never modify code to work around transient infra. **A release run is the exception**: when an orchestrator like `/repomatic-ship` spawned this loop, a flake surfaced here is debt owed under that skill's genuinely-green goal, so a red whose defect lives in the repository (the wall-clock budget above, a tolerated-exit set that needs widening) gets fixed at the source instead. "Transient infra" then names the trigger, not the remedy. A red with no repo-side defect at all, like a runner OOM or a PyPI 503, is still a re-run.
 
+**`--failed` also re-runs the jobs skipped behind a failure.** Each failed or cancelled job re-runs with every job that `needs:` it, skipped ones included. So one rerun restores the whole chain: never re-run the whole workflow to reach a skipped dependent.
+
 <a id="github-api-rate-limit-exhaustion"></a>
 
 ### GitHub API rate-limit exhaustion

{repomatic-7.16.2/repomatic/data → repomatic-7.16.3/.claude}/skills/file-bug-report/SKILL.md

@@ -157,6 +157,8 @@ Search with multiple keyword variations (error messages, function names, symptom
 
 If a matching open issue exists, report it to the user and stop. If a matching closed issue exists, mention it in the report with a link and explain why this is a new occurrence (different version, different context, regression).
 
+A matching issue closed for lack of a reproducer is not a dead end: cite it, because that closure is part of the record, and supply what it lacked.
+
 ### 3. Gather evidence
 
 Collect the actual error output, environment details, and reproduction steps from the current conversation context, CI logs, or local files. Always include:
@@ -178,6 +180,29 @@ Maintainers can diagnose faster when they can see the original context themselve
 
 Ask yourself: "Can the maintainer click a link and immediately see what I'm describing?" If yes, include the link. If the context is private, quote the relevant snippet inline instead.
 
+#### Observations, not conclusions
+
+The maintainer of the code is the authority on it. Hand over observations they can verify in one click, and leave the diagnosis to them:
+
+- **Link every factual claim to the exact line that proves it.** A claim drawn from a CI log links the log line (see § GitHub Actions log anchors below); a claim that exists only in an uploaded artifact links the artifact, since no log line proves it.
+- **Check a claim about the upstream tool against its source or manual before writing it.** Memory is not a source. Where a code comment in the tool says it better, quote the comment verbatim and link it.
+- **Date a behavior by the commit that added it, not by the release note that announced it.** Release notes list what is worth reading about now, not what shipped now: `git tag --contains {sha} | sort -V | head -1` names the first release that carried the commit.
+- **Report what varied, where, and the link to it, then stop.** Leave the diagnosis, its implications for CI or users, and the next step to the maintainer, who reaches them faster from the facts than from a summary of them.
+- **Give every failing reproducer a passing control beside it.** Without a near-identical case that passes, red cannot be told apart from a broken harness, a missing dependency or a mistake in the reproducer. Assert the control too, and have the job report the test as void when the control breaks.
+- **Freeze the reproducer's vocabulary once the prose quotes it.** Renaming a log line, an artifact or a path that the report quotes forces a rerun, then a repoint of every link and quoted phrase.
+- **Re-read the draft before handing anyone steps to reproduce.** Give only the steps the draft records as reproducible, and flag a symptom seen only once as a one-off.
+
+#### GitHub Actions log anchors
+
+A `…/actions/runs/{run}/job/{job}#step:{N}:{line}` link follows non-obvious numbering, verified against live runs:
+
+- **Fetch the raw log** with `gh api repos/{owner}/{repo}/actions/jobs/{id}/logs --allow-escape-sequences`. Without the flag, `gh` refuses the escape sequences and writes an empty file. The job's numeric ID is `id` in `gh api repos/{owner}/{repo}/actions/runs/{run}/jobs`, and `databaseId` in `gh run view {run} --json jobs`, which has no `id` field: reading `.id` there returns `null`.
+- **The step number counts "Set up job" as 1**, so a workflow's sixth step is `step:7`.
+- **Read that number from the API, never by counting log sections.** The raw log omits a skipped step while the fragment still counts it, so one `if:`-guarded step shifts every anchor below it by one, and only on the runs where it was skipped. `gh api repos/{owner}/{repo}/actions/jobs/{id}` returns `steps[].number` and `steps[].conclusion`: line the non-skipped steps up against the log's `##[group]Run ` markers in order, then take the number off the step. Its `name` is also the cheapest check that an anchor landed where intended.
+- **The line number starts at the step's `##[group]Run …` marker**, which is line 1, and includes the echoed script plus the `shell:`/`env:` preamble before any output.
+- **Strip the leading timestamp** (`^\S+Z `) from each raw line before counting or matching.
+- **Anchors rot on every rerun.** Any change in a job's output shifts every line below it, and a tool printing one extra banner line moves anchors nobody touched. After a rerun, repoint every anchor programmatically and re-resolve each one against the new logs to confirm it still lands on the intended line; never trust the arithmetic.
+
 ### 4. Select the right template
 
 Based on step 1d, pick the correct template:
@@ -227,6 +252,7 @@ What happens instead, with exact error output in code blocks.
 - Use first-person singular ("I", "my") per user conventions.
 - Include exact error messages in code blocks, not paraphrases.
 - If multiple distinct failures exist, group them under numbered sub-sections but keep them in one report if they share a root cause. File separate issues if root causes differ.
+- File a second finding as its own issue, cross-referenced, never by broadening the first one's title. The title must still name the fix that closes it.
 - Keep reproduction steps minimal: strip everything not needed to trigger the bug.
 - Link to CI runs or logs when available.
 - Do not speculate about fixes unless the root cause is clear from the evidence.

{repomatic-7.16.2/repomatic/data → repomatic-7.16.3/.claude}/skills/repomatic-audit/SKILL.md

@@ -26,7 +26,7 @@ Before flagging an issue, verify that the gap isn't **deliberate** or covered by
 
 - **`[tool.repomatic] exclude` is authoritative.** Files listed there (like `workflows/changelog.yaml` or `labels`) are intentionally absent on disk. Do **not** report them as MISSING.
 - **Bundled defaults applied at runtime.** Some config is materialized from the bundled template at runtime when the file is absent, so no on-disk copy is needed. **Absence of these files is not a problem**: it is the intended state when the user is happy with the bundled policy. Only flag DRIFT if the user wants to deviate from it. Exactly five tools carry such a fallback, the ones whose `ToolSpec` sets `default_config` in `repomatic/tooling/tool_registry.py`: `actionlint`, `mdformat`, `ruff`, `yamllint` and `zizmor`.
-- **A `[tool.X]` section is never a candidate for deletion.** The inverse of the rule above, and the more expensive mistake. Every other tool has no `default_config`, so its resolution chain has no level 3 to fall back on: `lychee`, `typos`, `mypy`, `pytest`, `coverage`, `bumpversion` and `uv` are *deployed* into `pyproject.toml` by `repomatic init`, and that section is the only config the tool will ever see. Deleting it does not restore inheritance from a bundled default, it drops the tool to level 4 and runs it bare, silently discarding every rule the section held. Read the tool's `default_config` before proposing a section be dropped "to inherit upstream updates". A deployed section that has gone stale is fixed by re-running `repomatic init`, which resyncs the components marked `SyncMode.ONGOING` in `repomatic/registry.py`.
+- **A `[tool.X]` section is never a candidate for deletion.** The inverse of the rule above, and the more expensive mistake. Every other tool has no `default_config`, so its resolution chain has no level 3 to fall back on: `lychee`, `typos`, `mypy`, `pytest`, `coverage`, `bumpversion` and `uv` are *deployed* into `pyproject.toml` by `repomatic init`, and that section is the only config the tool will ever see. Deleting it does not restore inheritance from a bundled default, it drops the tool to level 4 and runs it bare, silently discarding every rule the section held. Read the tool's `default_config` before proposing a section be dropped "to inherit upstream updates". Re-running `repomatic init` fixes a stale section only for the components marked `SyncMode.ONGOING` in `repomatic/registry.py` (`lychee`, `typos`, `bumpversion`, `uv`). It never revisits a `mypy`, `pytest` or `coverage` section after the first write: `lint-repo` warns on each bundled template entry such a section lacks, to copy by hand or decline on purpose.
 - **Generator artifacts vs user error.** When local thin-callers diverge from upstream (e.g., extra `workflow_dispatch:`, missing `paths:`), the cause may be the **upstream generator**, not downstream tampering. Inspect `repomatic/github/workflow_sync.py` (`generate_thin_caller`, `_adapt_trigger_paths`, `generate_workflow_header`) before recommending the user re-run `repomatic init` to "fix" something `init` itself produced.
 - **Project-level `claude.md` may live under a sub-directory.** `[tool.repomatic] subagents.location` and `skills.location` indicate a project where `.claude/` is not at the root (e.g., dotfiles repos with `dotfiles/.claude/CLAUDE.md`). Search the configured location, not just `./CLAUDE.md`.
 

{repomatic-7.16.2/repomatic/data → repomatic-7.16.3/.claude}/skills/repomatic-ship/SKILL.md

@@ -36,7 +36,7 @@ The sweep agents (step 1) and the babysitter (step 6) all follow these rules. Re
 - **Expand `<cmd>` before it reaches a spawn prompt.** `<cmd>` is this document's placeholder, not a shell command, and a prompt that carries it verbatim (or half-expanded) hands the agent something that cannot run. The trap is `run <tool>`: the tool registry supplies most of them, so dropping the `repomatic run` prefix does not merely drift from the pinned version, it fails outright — a spawn brief that expands `<cmd> run mypy --` into `uv run --frozen -- mypy --` dies on `Failed to spawn: mypy`, since mypy is not a project dependency. Write the invocation out in full (`uv run repomatic run mypy --`) and let the agent report back if it does not resolve.
 - **Trust the tree, not the report.** A mid-run message to a busy agent is delivery without receipt: it can land after the agent composed its final report and be silently dropped. After tasking a running agent, confirm the tree reflects the request (`git diff` the target file) before moving on. Read fresh every time rather than reusing an earlier capture — an edit can land in the gap between two checks, and a stale capture then reports a live fix as still missing. Grep for the *absence* of the old text (`grep -c '<old phrase>' <file>` returning `0`) instead of eyeballing a diff: an empty match is unambiguous where a diff read mid-scroll is not.
 - **Never let one lane wait on another lane's edit.** Messages cross: an agent can ask a sibling for a change while you reassign that file, then wait on an edit nobody will make. Name one owner per file in the same message to both agents, and when an agent reports it is blocked on another lane, make the edit yourself and tell it the edit landed. The archetype: one agent armed a watcher for a docs fix that the other had been told to leave alone, and the release sat idle until the orchestrator applied it.
-- **Never revert the shared working tree.** The agents share one tree, so disjoint lanes do not make them race-free: no agent may run a working-tree-reverting git command (`checkout`, `restore`, `stash`, `reset`, `clean`), which silently discards the *other* agents' uncommitted edits. For full isolation instead, spawn with `isolation: "worktree"` and merge on join: disjoint files won't conflict.
+- **Never revert the shared working tree.** The agents share one tree, so disjoint lanes do not make them race-free: no agent may run a working-tree-reverting git command (`checkout`, `restore`, `stash`, `reset`, `clean`), which silently discards the *other* agents' uncommitted edits. The rule binds investigation as much as correction, and investigation is where it gets broken: an agent comparing its file against the committed state reaches for `git stash`, which takes the whole tree rather than the one path it had in mind. Say so in the spawn prompt, and name the read-only alternative beside it, `git show HEAD:<path>`. For full isolation instead, spawn with `isolation: "worktree"` and merge on join: disjoint files won't conflict.
 - **Fix commits stage narrowly** (`git commit <path>`, never `-a`). Uncommitted files an agent did not create are the maintainer's in-progress work: never revert them and never sweep them into a commit.
 - **Degrade gracefully.** A cross-referenced skill excluded from this repo is a fallback path, not a blocker: apply its principle via an `Agent` or inline. When an `Agent` spawn itself fails (a terminal API error), do the work in the main thread.
 
@@ -67,7 +67,7 @@ The three substance passes own disjoint lanes (code owns Python including docstr
    - Failures the pass believes pre-existing get *reported*, not silently scoped out: that verdict belongs to step 2's CI check.
    - Adopting features from upgraded dependencies stays in `/repomatic-deps modernize`.
    - On the canonical repo, workflow invocations reading `uv --no-progress run --frozen -- repomatic` are the intended unfrozen state (the freeze commit rewrites them to a `uvx 'repomatic=={version}'` PyPI pin at release): never flag the local form as a pin regression or downstream breakage. The invariant to check instead is that every `uv`-invoking job provisions `setup-uv` in its own steps. Do not "restore" an isolated `uvx --from .` here: the lockfile path is deliberate, since an index resolution can be made unsatisfiable by the install cooldown while a lockfile cannot.
-   - Docstring rendering belongs to this pass: build the docs and fix any broken cross-reference role a docstring introduced (the docs pass can surface but not fix them). Build in a separate environment, with `{scratch}` a directory outside the repository: `UV_PROJECT_ENVIRONMENT={scratch}/docs-venv uv run --frozen --all-extras --group docs -- sphinx-build -b html docs docs/_build/html`. The shared `.venv` then keeps the CI-matching groups, which the `docs` group would perturb (see step 2's `--all-groups` warning). A checked-in `:mirror:` block whose cells embed source-line anchors is invalidated by every edit that moves a line in the anchored modules, docstring rewraps included: expect the `update-docs` autofix PR to refresh it after the push, and take that PR's file (`gh api 'repos/<owner>/<repo>/contents/<path>?ref=update-docs' -H 'Accept: application/vnd.github.raw'`) when a local regeneration would differ from CI's, as a terminal-dependent width does, or when `gh pr merge` is permission-walled. Build only into the gitignored `docs/_build`, never an ad-hoc path: a stray build tree pollutes `git status` and trips tool scans like `run typos`.
+   - Docstring rendering belongs to this pass: build the docs and fix any broken cross-reference role a docstring introduced (the docs pass can surface but not fix them). Build in a separate environment, with `{scratch}` a directory outside the repository: `UV_PROJECT_ENVIRONMENT={scratch}/docs-venv uv run --frozen --all-extras --group docs -- sphinx-build --fresh-env -b html docs docs/_build/html`. The shared `.venv` then keeps the CI-matching groups, which the `docs` group would perturb (see step 2's `--all-groups` warning). `--fresh-env` re-reads every page: an incremental build reports warnings only from the pages it re-read, so it misses a reference that a rename broke in another page. A checked-in `:mirror:` block whose cells embed source-line anchors is invalidated by every edit that moves a line in the anchored modules, docstring rewraps included: expect the `update-docs` autofix PR to refresh it after the push, and take that PR's file (`gh api 'repos/<owner>/<repo>/contents/<path>?ref=update-docs' -H 'Accept: application/vnd.github.raw'`) when a local regeneration would differ from CI's, as a terminal-dependent width does, or when `gh pr merge` is permission-walled. Build only into the gitignored `docs/_build`, never an ad-hoc path: a stray build tree pollutes `git status` and trips tool scans like `run typos`.
    - Shortening an over-long workflow line to satisfy yamllint's 120-char limit must not lift `hashFiles(...)` (or any `runner.*`) into a workflow-level `env:` var: that context exposes only `github`/`secrets`/`inputs`/`vars`, so the expression resolves to empty at run-init before checkout and silently breaks the value — a cache `key:` shortened this way ships a broken key to every downstream repo. Shorten the literal itself instead (trim a shared key prefix, say).
    - The red inventory from the pre-spawn capture is part of its brief: root-cause each repo-fixable red (a chronic platform break, a flaky live-registry install, a crashing `⁉️` probe) and fix it at the source per step 6's taxonomy, even when the failing file saw no change this cycle.
    - Pending work the cycle introduced belongs in a ```` ```{todo} ```` admonition where Sphinx renders it, not in a bare `# TODO`/`XXX` comment: a comment never reaches the published todo list, which is the project's inventory of what it owes. This applies to **committed** cycle-diff lines only, and does not loosen the unstaged-scratch guard above: a `# TODO` present only in the unstaged set is the maintainer's draft and stays untouched.
@@ -82,6 +82,7 @@ The three substance passes own disjoint lanes (code owns Python including docstr
    - **On a cycle that migrated the release tooling itself, the historical freeze under-predicts the new one.** A pre-repomatic freeze touching only `changelog.md` says nothing about the repomatic freeze, which also rewrites `citation.cff`, `__init__.py`, and `pyproject.toml`: treat every version sample as hand-maintained until the regenerated release PR's diff shows the new freeze's actual scope.
    - The mirror of the hand-maintained rule: a freeze-managed field legitimately shows the *dev* version between releases, so never flag one as stale against the released tag or as a dead link. `pyproject.toml`'s `urls.Download` reading `.../releases/tag/vX.Y.Z.devN` (a tag that has no GitHub release yet) is the expected post-bump state that the freeze rewrites to the release tag at cut. Hand-maintained samples track the *released* tag while freeze-managed fields track the *dev* version, so classify a version string by which mechanism owns it before judging it stale.
    - A third owner sits beside hand-maintained and freeze-managed: artifacts regenerated by `_release-engine.yaml`'s `update-dep-graph` job, whose `if:` gates on `release_commits_matrix`, so it fires **only on release commits** (never on ordinary pushes, to avoid noise from transitive dependency churn). It sits in the release engine rather than `autofix.yaml` because a release push is its only firing moment, and that is exactly the push `autofix.yaml` now skips wholesale, so do not go looking for it there. `docs/assets/dependencies.mmd` therefore lags `pyproject.toml` for the whole cycle: a runtime dependency added since the last release is *expected* to be missing from it, and the graph catches up through its own PR once the release lands. Never hand-forge the file, and never run `<cmd> update-dep-graph` to "fix" it mid-sweep: a local run uses whatever repomatic version the sweep resolved rather than the version the job pins, so it produces churn the next regeneration reverts. Classify a stale-looking generated artifact by the job that owns it before reporting it as drift.
+   - **A fourth owner is a version derived from a sibling checked-in file, and it is the only one that breaks something when bumped.** A build recipe in prose stages an artifact and then invokes a spec, manifest or lockfile the repository tracks, so its version must equal what that file declares rather than the released tag. Bumping the prose alone leaves the recipe unrunnable: `docs/packaging.md`'s openSUSE walkthrough downloads `{pkg}-{X.Y.Z}.tar.gz` into `~/rpmbuild/SOURCES`, then runs `rpmbuild -ba {pkg}.spec`, which resolves `Source0` through the spec's own `%{version}` and fails on the tarball the reader was just told to fetch. The tell is that the literal sits inside a procedure invoking a file in the repository: read that file's declared version before touching it. `git log -S '<the literal>'` settles the owner, since a derived value is written once by the commit that added the recipe and no sweep ever bumps it.
    - **A hand-maintained block enumerating a registry population is a drift class the version rules above do not reach.** A readme that pastes a console transcript of a whole collection (a `members` mapping, a `member_ids` set, a name list) or carries a `mirror-src` diagram lags the moment an entry is added, and nothing reports it: the version-string grep never looks at membership, no build reads those blocks back, and a mirror block stays stale until someone runs its refresher. Check every such block against the live collection, and derive the file set the change owes from the previous commit of the same kind rather than reasoning about it, since `git log -S '<a sibling entry>'` finds the commit that added the last one and its diff names each file that change had to touch. The archetype: a cycle adding one `Platform` refreshed the four generated `docs/` tables and left `readme.md` short in four places, three hand-pasted transcripts plus a mindmap `click-extra refresh-directives` regenerates, while every other platform including the previous release's two appeared in all four.
    - Executable doc blocks fail open: a `{click:run}` invocation that no longer parses renders the usage error into the published page instead of failing the build (`docs.yaml` stayed green while a stale option printed `No such option`; only `click:tree` and `click:config` hard-error). Verify each `{click:run}` invocation against the current CLI, or grep the built HTML for `Error: No such option`-class output.
    - Correcting one description of a convention means correcting *every* description of it in the same pass: a rule restated in more than one place (an overview line and its worked example, two docs pages) drifts as a set, so grep for the sibling statements and align them together — fixing one in isolation leaves the others contradicting the fix (a freeze-cutoff overview still said "the day after" while its worked example had been corrected to "the second day after", reconciled only on a second pass).
@@ -153,7 +154,7 @@ The checks:
 - **Binary self-test plan**, against the source build: `uv run -- click-extra test-suite --command <source-entrypoint> --jobs max`, the same engine `tests.yaml` (`--command`) and `release.yaml` (`--binary`) drive. It catches the two failures otherwise hidden until the ~90-minute matrix: a case assertion drifted from current CLI output (colors stripped by the piped harness, a moved string), and a plan that cannot *load* under the binary runner's stdlib-only base deps.
   - **Keep the plan TOML or JSON.** A YAML or json5 plan raises "format support disabled" and silently falls back to a trivial suite. Confirm a non-TOML plan parses under stdlib `tomllib`, since the full-venv source run has the format extras and hides the gap.
   - **It cannot catch a case whose expected output depends on the target platform's identity.** The source run is single-OS, so an assertion keyed on the release runner's distro (a `manylinux` container correctly detected as its RHEL/AlmaLinux base) or a manager present only there passes locally and still reds the binary matrix. A cycle that bumps a platform-detection dependency (`extra-platforms`) can silently shift such attributions: expect test-plan breakage in the binary matrix and check it there, not just in the source self-test.
-- **Fresh resolution**: `uvx --no-progress --from . <cmd-bare> --version`. A fresh isolated env resolves `[project.dependencies]` from scratch, surfacing transitive conflicts the already-synced venv hides; CI's `🧬 Project metadata` job runs exactly this on every workflow, and end users installing via `uvx` hit the same resolution, so a failure is **release-blocking**. Fix at the dependency level (drop, swap, or wait on upstream), never with environment-scoped overrides: `uvx --from .` does not read `[tool.uv] override-dependencies`.
+- **Fresh resolution**: `uvx --no-progress --from . <cmd-bare> --version`. A fresh isolated env resolves `[project.dependencies]` from scratch, surfacing transitive conflicts the already-synced venv hides; CI's test matrix installs from `uv.lock` and hides them too, while end users installing via `uvx` hit exactly this resolution, so a failure is **release-blocking**. Fix at the dependency level (drop, swap, or wait on upstream), never with environment-scoped overrides: `uvx --from .` does not read `[tool.uv] override-dependencies`.
   - **A cooldown filter is not a resolution failure — check for it before declaring one.** `uvx` reads the *user-level* `~/.config/uv/uv.toml`, which on a maintainer's machine typically carries a supply-chain `exclude-newer` (repomatic recommends one). A release that raises a dependency floor to a version published inside that window then fails to resolve **on the maintainer's machine only**, for a reason no end user shares and no dependency conflict caused. The tell is in uv's own output: a `hint: <pkg> was filtered by exclude-newer to only include packages uploaded before <date>. The latest version satisfying the requirement is vX, published at <later date>` — that is environment, not a conflict. Note this is self-clearing: the same command passes untouched once the dependency ages past the window.
   - **Re-run with the cutoff lifted wholesale, and judge the gate on that result.** Use `uvx --no-progress --exclude-newer 2100-01-01 --from . <cmd-bare> --version`. Lifting it per-package (`--exclude-newer-package <pkg>=0d`) just surfaces the next floor in the chain, one round-trip at a time.
   - **A cooled run that resolves and then crashes is a floor bug, not the cooldown.** The two look alike and mean opposite things. A cooldown artifact fails *during* resolution, and says so with the `hint:` above. A floor bug installs cleanly, then dies at runtime on the older version the cooldown fell back to: typically a `TypeError` naming an argument a newer release introduced. Lifting the cutoff hides it, so judging the lifted run alone passes the gate on a release that every cooled install will break. Downstream repos run the frozen `uvx 'repomatic==X.Y.Z'` under a workflow-level `UV_EXCLUDE_NEWER`, and `uvx` reads neither `uv.lock` nor `[tool.uv]`. Read the traceback before crediting the cutoff. When the older version is at fault, raise the floor to what the code needs, and let `lint-deps` say whether the release waits.
@@ -191,6 +192,8 @@ Commit the reconciled tree with a message describing the net reconciliation (plu
 
 **Re-read `git status` immediately before staging, and never reach for `git add -A`.** A sweep agent that has gone quiet is not necessarily finished: it can resume editing minutes later, after the step-2 gate has already run and while you are drafting the commit. `git add -A` then sweeps in files you never reviewed and whose changes the gate never covered. Diff every path that was not in the tree when you ran the gate, and re-run the gate before committing if any appeared: an edit landing after the gate is an ungated edit, whoever made it. This is not hypothetical bookkeeping — one such late edit dropped an explicit `name=` from a Click command, which would have silently renamed a CLI command the changelog advertises had the framework not happened to derive the same name from the function. The narrow-staging rule the sub-agent rules impose (`git commit <path>`, never `-a`) applies to the orchestrator's own reconciliation commit for exactly this reason.
 
+**A gate command you ran yourself re-creates the mutations you already reverted.** The step-2 revert is not final, and a sweep agent is not the only thing that writes to the tree. Any later step that builds the documentation regenerates the committed artifacts that build owns, and a test selection can build them without announcing it. In one run a docs build restamped 121 capture SVGs and the orchestrator discarded them; a `pytest` selection over a single Sphinx test module then brought 23 of them back, after every gate had passed. So re-read `git status` after the *last* command that touched the tree, not after the sweep agents joined, and stage by explicit path so a resurrected artifact cannot enter the commit.
+
 **Signed commits need the sandbox off.** With SSH signing (`gpg.format = ssh`), the harness sandbox blocks the key or socket under `~/.ssh/*` (`Operation not permitted`): disable the sandbox for the `git commit` and `git push` calls only.
 
 **A hardware key is not a retry loop.** A hardware-backed key (Secretive, YubiKey, TPM) prompts the maintainer per signature, and one unanswered prompt wears three faces, sometimes in sequence across retries: `agent refused operation?`, `Couldn't sign message (signer): communication with agent failed?` (exit 128, then `failed to write commit object`), or no output whatsoever until something kills the command. The first two look like a real failure; the third is the expensive one, because a signing command silent for minutes is a prompt nobody answered rather than a slow command, so bound it with a timeout and hand off instead of waiting it out. Stop after one or two retries and ask the maintainer rather than burning prompts they may not be watching.
@@ -233,7 +236,7 @@ Its prompt restates the sub-agent rules (the trailer and narrow staging especial
 - **Poll at the job level** (`gh run view <run> --json jobs`), per the tight fix-loop above, never the run's `conclusion` alone: a run-level read hides an already-failed fast job for as long as the slowest cell runs (a failed `once-tests` job once hid for half an hour behind a 40-minute macOS cell that ultimately passed). Break the instant any required job turns `conclusion == "failure"` — required meaning any name *without* `⁉️` in it, which covers the glyph-less non-matrix jobs (`🛡️ Lint types`, `1️⃣ Run-once tests`, `📦 Package install`) as well as the `✅` cells.
 - **Log fetches may need the sandbox off**: `gh run view --log-failed` caches under `~/.cache/gh`, which the sandbox denies; the `creating cache entry ... operation not permitted` failure masquerades as a `gh` bug.
 - **Foreground `sleep` is blocked in the orchestrator's shell**, so you cannot run the in-turn `while … sleep` poll loop the spawned babysitter uses. Drive the wait with the `Monitor` tool (an until-loop command that emits each workflow's terminal state and exits) or a bounded `gh run watch <run-id>`, acting on each landing. The babysitter's "never detach a monitor" rule governs the *sub-agent* polling in-turn; the orchestrator taking over must reach for `Monitor`/`gh run watch` precisely because its own `sleep` is disallowed.
-- **Write that watcher in Python, and never trust a green it reports without confirming against `gh`.** The failure that matters here is not a watcher that crashes, it is one that exits silently declaring success: its "all workflows terminal" line is indistinguishable from the real thing, and it arrives *early*, which reads as good news. A shell watcher is the easy way to get one, because macOS ships bash 3.2: `declare -A` is a hard error there, so the obvious "have I already reported this workflow?" map fails on the first iteration, every workflow falls through as already-seen, and the loop announces completion while the whole matrix is still queued. A stderr line scrolling past in the monitor's output file is the only hint. Python has no such trap and gives you a `set()` that works on any machine. Whatever you write, the confirmation is the same: re-read `gh api 'repos/<owner>/<repo>/actions/runs?head_sha=<full-sha>'` yourself before acting on a terminal claim, exactly as you do for the babysitter's own return.
+- **Write that watcher in Python, and never trust a green it reports without confirming against `gh`.** The failure that matters here is not a watcher that crashes, it is one that exits silently declaring success: its "all workflows terminal" line is indistinguishable from the real thing, and it arrives *early*, which reads as good news. A shell watcher is the easy way to get one, because macOS ships bash 3.2: `declare -A` is a hard error there, so the obvious "have I already reported this workflow?" map fails on the first iteration, every workflow falls through as already-seen, and the loop announces completion while the whole matrix is still queued. A stderr line scrolling past in the monitor's output file is the only hint. Python has no such trap and gives you a `set()` that works on any machine. The same early exit arrives with no shell involved: that `head_sha` endpoint answers eventually-consistently, and it has returned an empty page for a commit that listed eight runs a minute earlier, so a `terminal == len(runs)` test reads `0 == 0` and passes. Guard the exit on the run list being non-empty if it ever was, and poll through a later empty page as a blip rather than reading it as a finished suite. Whatever you write, the confirmation is the same: re-read `gh api 'repos/<owner>/<repo>/actions/runs?head_sha=<full-sha>'` yourself before acting on a terminal claim, exactly as you do for the babysitter's own return.
 
 **Verify the Nuitka run yourself, starting with whether the project builds binaries at all:**
 

{repomatic-7.16.2/repomatic/data → repomatic-7.16.3/.claude}/skills/sphinx-docs-sync/SKILL.md

@@ -47,7 +47,7 @@ For each project, collect (parallelize with sub-Agents when possible). For each
 - **Theme assets** (agent § `conf.py` hygiene › Theme assets and OpenGraph). Confirm the sidebar logo is Furo's `light_logo`/`dark_logo` **pair** in `html_theme_options`, each name also listed in `html_static_path`, with `html_logo` **unset** — Furo prefers `html_logo` and skips the pair when it is present, so a lingering `html_logo` is drift to report, never the thing to confirm. Confirm `html_favicon = "assets/favicon.svg"`, and that `ogp_image` is `_static/banner-social-<variant>.png` with that PNG also listed in `html_static_path`, never a bare `assets/...` path (`docs/assets/` is not copied into the built site, so that value 404s for social crawlers). An absolute `raw.githubusercontent.com` URL was the earlier rule: it still resolves, so report it as alignment, not as a bug. Flag projects with `sphinxext.opengraph` enabled but no `ogp_image` set. Suggest the user run `/brand-assets` on flagged projects to regenerate or backfill the asset set in one pass.
 - **`sphinx_issues` migration** (agent § Migrating off `sphinx_issues`). Grep each project for `{issue}` `/`{pr}` ` / `{user}` `/`{commit}` ` (MyST) and `:issue:` `/`:pr:` ` / `:user:` `/`:commit:` ` (reST) across `*.md`, `*.rst`, `*.py`. Flag every occurrence and offer to apply the migration recipe in one pass per repo. After replacement, drop `"sphinx_issues"` from `extensions` in `conf.py`, `"sphinx-issues>=…"` from `[dependency-groups] docs`, and any `issues_github_path` setting unused by other extensions.
 - **`pyproject.toml` docs dependency group**. Compare against what `conf.py` actually imports — flag undeclared imports and declared-but-unimported deps. Don't change version pins unless provably stale (a conditional dep on a Python version below the project's floor; a transitively-constrained loose pin held by a meta-extra like `click-extra[sphinx]`).
-- **`readme.md`**. Compare badge sets and section structure. Flag a `## Development` section when `claude.md` exists in the same repo (per agent § High-frequency lapses).
+- **`readme.md`**. Compare badge sets and section structure. Flag developer setup held in a `## Development` section or in `claude.md`: it belongs on the `contributing` page (per agent § High-frequency lapses).
 - **Sphinx tests** (agent § Sphinx tests). Look for `tests/sphinx/`, `tests/test_sphinx_*.py`, or `test_sphinx_crossrefs.py`. Note which projects have render-tests and which don't; suggest adopting cross-reference render tests where the docs surface complex `{role}` cross-refs.
 - **Static assets and auto-generated files**. Compare `docs/_static/`, `docs/assets/`, `.rst` files, `docs_update.py`. Hunt for stale `.rst` orphans from past package renames.
 

{repomatic-7.16.2 → repomatic-7.16.3}/.claude-plugin/marketplace.json

@@ -14,7 +14,7 @@
 			"name": "repomatic",
 			"source": {
 				"path": ".claude",
-				"ref": "v7.16.2",
+				"ref": "v7.16.3",
 				"source": "git-subdir",
 				"url": "https://github.com/kdeldycke/repomatic"
 			},
@@ -25,7 +25,7 @@
 				"github-actions",
 				"release-automation"
 			],
-			"version": "7.16.2"
+			"version": "7.16.3"
 		}
 	]
 }

{repomatic-7.16.2 → repomatic-7.16.3}/.github/actions/publish-pypi/action.yaml

@@ -27,14 +27,14 @@ inputs:
 runs:
   using: composite
   steps:
-    - uses: astral-sh/setup-uv@bec219d24cd3e171d82865faccec33120bb574f4 # v10.1.0
+    - uses: astral-sh/setup-uv@c18668ad3cf93ea998bef934396af7bb5c839dc7 # v10.2.0
       with:
         enable-cache: false
         # Downstream callers invoke this action without a checkout (the codegen drops it: see
         # _render_publish_pypi_job in repomatic/github/workflow_sync.py), so the empty workdir
         # is by design and setup-uv's warning about it is noise.
         ignore-empty-workdir: true
-        version: "0.12.12"
+        version: "0.12.17"
 
     - name: Download build artifact
       id: download

{repomatic-7.16.2 → repomatic-7.16.3}/.github/workflows/_release-build.yaml

@@ -46,7 +46,7 @@ permissions: {}
 # minimum-release-age`. repomatic's own test suite enforces that upstream; a
 # synced copy is kept in step by hand. Deliberate bypasses are per-package CLI
 # flags (`--exclude-newer-package`, `--min-release-age-exclude`).
-# See claude.md for the rationale.
+# See https://repomatic.net/workflows#install-time-cooldown for the rationale.
 env:
   NPM_CONFIG_MIN_RELEASE_AGE: 7
   UV_EXCLUDE_NEWER: "1 week"
@@ -66,9 +66,9 @@ jobs:
       issues: write
     steps:
       - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
-      - uses: astral-sh/setup-uv@bec219d24cd3e171d82865faccec33120bb574f4 # v10.1.0
+      - uses: astral-sh/setup-uv@c18668ad3cf93ea998bef934396af7bb5c839dc7 # v10.2.0
         with:
-          version: "0.12.12"
+          version: "0.12.17"
       - name: Extract PR reference
         id: extract
         env:
@@ -81,7 +81,7 @@ jobs:
         env:
           PR_REF: ${{ steps.extract.outputs.pr_ref }}
         run: >
-          uvx --no-progress --exclude-newer-package repomatic=P0D 'repomatic==7.16.2'
+          uvx --no-progress --exclude-newer-package repomatic=P0D 'repomatic==7.16.3'
           pr-body --output-format github-actions
           --template detect-squash-merge
           --pr-ref "${PR_REF}"
@@ -124,13 +124,13 @@ jobs:
         run: git branch --all
       - name: List all commits
         run: git log --decorate=full --oneline
-      - uses: astral-sh/setup-uv@bec219d24cd3e171d82865faccec33120bb574f4 # v10.1.0
+      - uses: astral-sh/setup-uv@c18668ad3cf93ea998bef934396af7bb5c839dc7 # v10.2.0
         with:
-          version: "0.12.12"
+          version: "0.12.17"
       - name: Run repomatic show-metadata
         id: metadata
         run: >
-          uvx --no-progress --exclude-newer-package repomatic=P0D 'repomatic==7.16.2' show-metadata
+          uvx --no-progress --exclude-newer-package repomatic=P0D 'repomatic==7.16.3' show-metadata
           --format github-json --output "$GITHUB_OUTPUT"
           new_commits_matrix release_commits_matrix build_targets nuitka_matrix
           is_python_project cli_scripts package_name current_version released_version
@@ -161,12 +161,12 @@ jobs:
             ${{ fromJSON(needs.metadata.outputs.metadata).release_commits_matrix
             && fromJSON(needs.metadata.outputs.metadata).release_commits_matrix.commit[0]
             || github.sha }}
-      - uses: astral-sh/setup-uv@bec219d24cd3e171d82865faccec33120bb574f4 # v10.1.0
+      - uses: astral-sh/setup-uv@c18668ad3cf93ea998bef934396af7bb5c839dc7 # v10.2.0
         with:
-          version: "0.12.12"
+          version: "0.12.17"
       - name: Check dependency sources
         run: >
-          uvx --no-progress --exclude-newer-package repomatic=P0D 'repomatic==7.16.2' lint-deps
+          uvx --no-progress --exclude-newer-package repomatic=P0D 'repomatic==7.16.3' lint-deps
           ${{ fromJSON(needs.metadata.outputs.metadata).release_commits_matrix
           && '--fatal' || '--no-fatal' }}
 
@@ -193,9 +193,9 @@ jobs:
       - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
         with:
           ref: ${{ matrix.commit }}
-      - uses: astral-sh/setup-uv@bec219d24cd3e171d82865faccec33120bb574f4 # v10.1.0
+      - uses: astral-sh/setup-uv@c18668ad3cf93ea998bef934396af7bb5c839dc7 # v10.2.0
         with:
-          version: "0.12.12"
+          version: "0.12.17"
       # Bakes the tag SHA into the CLI module so a built artifact can report the
       # commit it came from. Gated on `cli_scripts` because click-extra locates that
       # module through `[project.scripts]`, and hard-errors with "No __init__.py
@@ -210,7 +210,7 @@ jobs:
         env:
           COMMIT: ${{ matrix.commit }}
         run: >
-          uvx --no-progress 'click-extra==9.1.0'
+          uvx --no-progress 'click-extra==9.3.3'
           prebake field git_tag_sha "${COMMIT}"
       - name: Build package
         run: uv --no-progress build