[isaacroldan]

Description

Dev Experience gardener cleanup: this removes one workflow that has never run and fixes one that fails every day. Evidence comes from a read-only inventory of the Dev Experience repos' automation taken on 2026-10-27.

It also retires the gardener Slack notifications and auto-labelling. On 2026-10-30 Isaac decided to remove them. These workflows labelled every new issue and PR devtools-gardener and posted each one to #devtools-gardener-backlog. Each post was a bare linked title, and together they made up most of the channel's noise. From now on, the Torrent gardener-triage routine (GARDTRI) will surface new issues and Dependabot PRs.

Remove gardener-investigate-issue.yml. It has 0 runs since it was added on 2026-04-20, and the devtools-investigate-for-gardener label has never been used in this repo. The investigating-github-issues skill in .claude/skills/ stays because it works locally without the workflow. No docs mention the workflow or the label.

Fix the waiting-for-response closer. close-waiting-for-response-issues.yml has failed every day since 2026-09-25 (latest failure, 2026-10-27, first failure, 2026-09-25, last success, 2026-09-24). Each run stops at "Getting action download info" with Repository access blocked: GitHub has blocked actions-cool/issues-helper itself. gh api repos/actions-cool/issues-helper returns 403 with block reason tos, created 2026-09-24T23:51:05Z.

This PR switches to the setup the remix template has used since 2026-07-13 (file, green run on 2026-10-27). That is actions/stale@1e223db275d687790206a7acac4d1a11bd6fe629 # v10.4.0 with days-before-stale: -1 and days-before-close: -1, so it only closes issues that already carry the "Waiting for Response" label. The label match is case-insensitive.

• The workflow name, the schedule and the closing message stay the same.
• The 14-day window stays the same: the old inactive-day value is now days-before-issue-close.
• actions/stale needs actions: write to save its state cache, so the file now has a permissions block.
• remove-issue-stale-when-updated: false leaves label removal to remove-labels-on-activity.yml. That workflow is unchanged and still drops the label when someone comments.

No open issue has the label today, so merging this won't close anything right away.

Remove the gardener Slack notifications and auto-labelling. This deletes both notification workflows, so new issues and PRs are no longer labelled devtools-gardener automatically:

• gardener-notify-event.yml: stashed the event payload when an issue or PR was opened or labelled devtools-gardener.
• gardener-notify-slack.yml: ran on workflow_run, added devtools-gardener to newly opened issues and PRs, and posted a linked title to Slack.

Nothing else in the repo depends only on these two workflows. I grepped for gardener-notify, GARDENER_SLACK, SLACK_GARDENER and devtools-gardener and checked helper scripts, label/config files and docs. This PR doesn't touch the devtools-gardener label, the other workflows or the Torrent gardener-triage routine (GARDTRI).

Secrets and variables the removed workflows used (none are deleted here; removing them is left to the maintainers):

• secrets.SLACK_GARDENER_BOT_TOKEN and vars.GARDENER_SLACK_CHANNEL_ID: used only by gardener-investigate-issue.yml and gardener-notify-slack.yml, which are both removed here. Once this PR merges, nothing in the repo uses them.

How has this been tested?

Parsed every workflow in .github/workflows/ with PyYAML (actionlint isn't installed locally). The closer hasn't been run end to end. After merge, workflow_dispatch can trigger it once. After merge, opening an issue or PR should no longer add devtools-gardener or post to Slack.

Checklist:

• My commit message follow the pattern described in here
• I have performed a self-review of my own code.
• I have added tests that prove my fix is effective or that my feature works: n/a, workflow-only
• I have updated the project documentation: n/a (no docs reference these workflows)
• I have added a changelog line: not added, because this is CI-only, the gem doesn't change, and earlier workflow-only changes here had no entry