ci(renovate): leave generated tend workflows to tend

[dormouse-bot]

Summary

• make tend the sole dependency-pin owner for .github/workflows/tend-*.yaml
• replace Renovate's package-only max-sixty/tend exclusion with a file-scoped github-actions exclusion covering every generated dependency
• reconcile the two Renovate-edited workflows with tend 0.2.7 so the ownership boundary is true at merge
• record the ownership boundary in the CI security spec and rationale
• remove the temporary nightly workaround guidance

Why

Tend regeneration replaces these workflows byte-for-byte from its released templates. Letting Renovate edit dependencies inside the generated output creates two authorities: Renovate advances a pin, nightly regeneration restores tend's released pin, and the next Renovate run advances it again. #636 and #656 exposed the loop through astral-sh/setup-uv and uv, but the same problem applies to checkout, runner versions, and any future dependency emitted by tend.

The permanent boundary is file ownership: tend releases carry dependency updates for generated workflows; Renovate continues managing every hand-owned workflow. This PR also runs the pinned tend 0.2.7 generator once, returning setup-uv and uv to the versions its released templates own instead of leaving a one-time reconciliation PR for the next nightly.

Verification

• pnpm test
• uvx --no-config --no-env-file tend@0.2.7 init produces no additional workflow changes after the committed reconciliation
• pnpm exec npx --yes --package renovate -- renovate-config-validator .github/renovate.json
• authenticated Renovate GitHub dry run: all seven dependencies extracted from tend-mention.yaml report skipReason: disabled
• complementary dry run: actions/checkout and astral-sh/setup-uv in hand-owned workflow-audit.yaml remain enabled and receive normal lookups

[cloudflare-workers-and-pages]

Deploying mouseterm with    Cloudflare Pages

Latest commit:	1d6244f
Status:	✅  Deploy successful!
Preview URL:	https://2479f84a.mouseterm.pages.dev
Branch Preview URL:	https://skills-tend-workflow-pin-dow.mouseterm.pages.dev

View logs

[dormouse-bot]

Feedback on work in progress, not a merge verdict — mark it ready when you want the full review. (Self-authored, so no approval is possible either way.)

The diagnosis checks out: enabledManagers includes github-actions, the two files sit at v10.1.0 / 0.12.13 from #636, the generator stamp is tend 0.2.7, and Renovate's schedule is Mondays. Three things about the rule as written.

The rule is scoped to uv, but the collision is not. actions/checkout@v7 appears in all eight generated tend-*.yaml files under the same github-actions manager, and renovate.json's only enabled: false entries for that manager are max-sixty/tend and node — nothing file-scopes the generated workflows. The moment Renovate takes checkout to v8 ahead of a tend release, the identical downgrade appears in eight files, and a nightly matching against a uv-specific note won't recognize it. Naming the mechanism rather than the package also makes the heading findable on the next instance.

"Restore the pins" and "skip the PR" are coupled, and only one of them generalizes. Today the downgrade is the entire diff, so skipping is right. On the next tend release the regeneration carries real changes plus the trailing pins, and a nightly holding this note either drops a legitimate upgrade PR or lets the downgrade ride inside one. Restoring the pins is unconditional; skipping the PR is conditional on nothing else remaining.

The manual cleanup step isn't needed. _prepare() in nightly_workflow_update.py unlinks the state, body, and sha files and runs git worktree remove --force before it does anything else, on every invocation — so an abandoned preparation is already cleaned up by the next run, and in CI the runner is fresh regardless. "The script has no abort command" is true but doesn't imply the session has to clean up by hand; hand-removing the worktree with anything other than git worktree remove would leave a stale admin entry for the next worktree add.

On the durable fix you left open: the Renovate-rule option has precedent in this file — the max-sixty/tend and node entries already disable that manager for specific pins — so a matchFileNames disable on .github/workflows/tend-*.yaml would be the same shape, at the cost you already name.

[dormouse-bot]

Feedback on work in progress, not a merge verdict — mark it ready when you want the full review. (Self-authored, so no approval is possible either way.)

The file-scoped exclusion holds up: all eight max-sixty/tend/claude references live in tend-*.yaml, so dropping matchPackageNames costs no coverage, and no later packageRule re-enables github-actions for those paths. is_renovate_pin_bump in workflow-audit.yaml still has hand-owned workflows to classify, so nothing is left dead. One consequence the change doesn't account for.

The tree is still on Renovate's side of the boundary, so merging this schedules one downgrade PR with the note explaining it deleted. tend-mention.yaml and tend-notifications.yaml carry astral-sh/setup-uv@v10.1.0 / uv 0.12.13 from #636, merged yesterday; tend 0.2.7 emits v10.0.1 / 0.12.10 (the values 49fb1f7 regenerated). The nightly's prepare runs uv tool run tend@latest init, so the next regeneration after this merges reports changed: true on a diff that is exactly that revert. Under the new ownership rule that revert is correct — but it arrives as a bare pin downgrade of a Renovate bump from the day before, and this PR removes the only text in the repo that would tell its reviewer what it is.

Reconciling the tree here is the cleaner form: revert those four lines in this PR and the ownership boundary is true at merge rather than one nightly later. If you'd rather let the regeneration do it, the rationale paragraph is the place to say that one reconciling regen is expected — otherwise the first reader of that PR has nothing to go on. Happy to push either, though I've left the branch alone since it's a draft.

[dormouse-bot]

#656 is open against the same two lines in the opposite direction: Renovate proposes astral-sh/uv 0.12.13 → 0.12.15 in tend-mention.yaml and tend-notifications.yaml, while 1d6244f1 here takes them to the 0.12.10 that tend 0.2.7 emits. Whichever lands second conflicts, and merging #656 after this one re-opens exactly the alternation the ownership boundary closes. The new rule stops Renovate proposing it again, but not until Renovate's next Monday window — so #656 sits open and mergeable in the meantime and is worth closing along with this merge.

No other concerns: the matchFileNames scope loses no coverage (every max-sixty/tend reference in the repo is inside a tend-*.yaml, and no later packageRule re-enables github-actions for those paths), and the reconciled pins reproduce byte-for-byte from the 0.2.7 generator. Self-authored, so this carries no approval either way.