# cc-release-watch — workflow_dispatch re-registration fix

Why a one-line YAML change unblocks the smoke-test path.

## Symptom

`POST repos/{owner}/{repo}/actions/workflows/259675442/dispatches`

    HTTP 422: Workflow does not have 'workflow_dispatch' trigger

Returned even though the file on `main` clearly has `workflow_dispatch:` in its `on:` block.

## Root cause

2026-04-12
`cc-release-watch.yml` first added with `name: CC Release Watch` and `workflow_dispatch: {}` (explicit empty-inputs). GHA registers workflow ID `259675442` but, for unknown reasons, fails to capture the friendly name — registers it as `.github/workflows/cc-release-watch.yml` (file path) instead.
2026-05-02
M130 PR #1589 replaces the file content. New `name: cc-release-watch`, new schedule, new triggers — and switches to the implicit form `workflow_dispatch:`. GHA does NOT re-parse metadata for this workflow ID; the cached "no friendly name + no dispatch trigger" state persists.
2026-05-02
Hotfix PR #1591 lands without touching the trigger syntax. Dispatch attempts return 422.
GitHub Actions caches workflow metadata at registration time and doesn't always invalidate on file content changes. The implicit `workflow_dispatch:` form (valid YAML, equivalent to `workflow_dispatch: {}`) appears to be a trigger for this cache-coherency edge case.

## Fix

`.github/workflows/cc-release-watch.yml`

    on:
      schedule:
        - cron: '0 14 * * *'
      workflow_dispatch:

    on:
      schedule:
        - cron: '0 14 * * *'
      workflow_dispatch: {}

Explicit empty-inputs form. Forces GHA to re-parse the file's trigger block, which re-registers `workflow_dispatch` as available. No semantic change — both forms accept zero inputs.

## Verification path

1. This PR merges to main.
2. The merge commit forces GHA to re-index `cc-release-watch.yml`.
3. `gh workflow run cc-release-watch.yml` succeeds (returns a run URL).
4. The dispatched run executes end-to-end with `CLAUDE_CODE_OAUTH_TOKEN` configured: snapshot → triage (LLM) → issue creation, no fallback issue filed.

If step 3 still 422s, the next mitigation is to rename the workflow file (e.g., `cc-watch.yml`) to force a brand-new workflow ID with fresh metadata. Documented as a follow-up in the PR body.

## Why not just wait for the daily cron?

14:00 UTC daily would fire on the registered `schedule` trigger. But if GHA's metadata cache is broken on this workflow, scheduled triggers may also be silently degraded — the `schedule` entries are parsed from the same `on:` block as `workflow_dispatch`. Re-registering via the explicit form covers both.