CLP-1093 Fix the dogfood Slack failure notification

[frederic-tingaud-sonarsource]

Part of CLP-910.

The "Notify failures on Slack" step in dogfood.yml does not work, and has not
for a long time. It runs if: failure(), so it only fires when a dogfood build
is already broken — which is exactly when nobody is watching the step itself.

Two independent defects, both fixed here.

1. The action is called with inputs it does not have

The action is pinned at v4.0.0, but is passed channel-id and
slack-message. Those are the v1.x inputs; v2 replaced them with
method / token / payload. Neither is declared in v4, so the action
receives no instruction at all and aborts:

SlackError: Missing input! Either a method or webhook is required to take action.

That is from the real run on 2026-09-09 (34345432458) — the dogfood build failed
and the alert about it failed too.

This came from Renovate: #5744 bumped v1.27.1 → v3.0.3 on 2026-07-09 and
left the inputs untouched, crossing the v2 breaking change. #5800/#5798/#5826
carried it on to v4.

2. The token it reads is never fetched

Independently of the version bump, the step read
fromJSON(steps.secrets.outputs.vault).SLACK_BOT_TOKEN, but the get secrets
step only ever requested:

development/kv/data/slack webhook | SLACK_WEBHOOK;

There is no SLACK_BOT_TOKEN in that payload, so the expression resolved to an
empty string. Conversely SLACK_WEBHOOK was fetched and never referenced. This
mismatch predates the version bumps — it is present as far back as v1.26.0 —
so the notification never worked under v1 either. The one pre-bump failure run
I can still inspect (2026-06-24) also shows this step failing; its log has since
expired, so I cannot show the v1 error text.

Fixing only the inputs would have left the step broken, just failing later and
for a different reason.

The fix

Switched to the v4 API and to a credential that is actually retrieved. The
Slack bot token lives at development/kv/data/slack token, which is the
convention used everywhere else in the estate — including ToggleLockBranch.yml
in this repository, and release-github-actions/notify-slack. The unused
webhook line is replaced rather than added to.

The explicit channel in the payload preserves the intended destination
(squad-corelang-notifs, set by CLP-85 in #5693). A webhook would have posted
wherever the shared webhook is configured, which is not necessarily that channel.

About errors: true

Worth calling out, because it is the difference between this working and only
appearing to work. In v4, config errors are thrown before the request, but
Slack API errors are swallowed by default (errors defaults to false):

try { await post(config); }
catch (error) { if (config.inputs.errors) { core.setFailed(error); throw ... } }

So with the default, a wrong channel or a bad token produces a green step and no
message — the exact silent failure this PR is fixing. errors: true makes those
surface. The step only runs when the job has already failed, so it cannot turn a
passing build red.

Verification

• Confirmed method / token / payload are the declared inputs at the pinned
  SHA, and that payload is parsed as YAML (load(input, {schema: JSON_SCHEMA}))
  in the bundled action, so the inline block is valid.
• Confirmed the v4 env fallback is SLACK_TOKEN, not SLACK_BOT_TOKEN
  (token: core.getInput("token") || process.env.SLACK_TOKEN || null), which is
  why the old env: block could never have worked even with correct inputs. The
  token is now passed as an input, so no env var is involved.
• Parsed the new payload exactly as the action will, and confirmed it yields
  channel: squad-corelang-notifs and the expected text.

What I cannot verify from CI: this path only executes when a dogfood build
fails, so a green build here proves nothing about it. The remaining unknown is
whether the bot is a member of squad-corelang-notifs; if it is not,
chat.postMessage returns not_in_channel — which, thanks to errors: true,
will now be visible instead of silent. Worth a deliberate test if you want
certainty before the next real failure.

🤖 Generated with Claude Code

[hashicorp-vault-sonar-prod]

CLP-1093

[gitar-bot]

Code Review ✅ Approved

🟡 Medium risk · Switches dogfood failure alerts to Slack's API using a retrieved bot token.

Fixes two independent defects in the dogfood Slack failure notification step: updates the action from v1 inputs (channel-id, slack-message) to the v4 API (method, token, payload), and corrects the secret retrieval to fetch SLACK_BOT_TOKEN from development/kv/data/slack token instead of the nonexistent token in the webhook payload. Adds errors: true to surface Slack API errors instead of silently failing. No issues found.

Review coverage

🧪 Functional validation No results

📋 Rules No rules evaluated

🤖 Auto-approval Not enabled · Set up

Options

Auto-apply is off → Gitar will not commit updates to this branch.
Display: compact → Counting what did not apply, without listing it.

Comment with these commands to change the behavior for this request:

Auto-apply	Compact
gitar auto-apply:on	gitar display:verbose

_{Was this helpful? React with 👍 / 👎 | Gitar}

[sonarqube-next]

Quality Gate passed

Issues
0 New issues
0 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
0 Dependency risks
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarQube

[mary-georgiou]

LGTM