bug(initiative-planner): claude-code-action rejects `discussion` events — the `idea:approved` auto-trigger never plans

[don-petry]

Summary

initiative-planner.yml is wired to fire on on: discussion [labeled] when a maintainer adds idea:approved to an Ideas Discussion (the documented primary path). That path is broken end-to-end: the "Plan the initiative" step uses anthropics/claude-code-action@787c5a0ce96a9a6cfb050ea0c8f4c05f2447c251 # v1.0.133, which aborts with:

##[error]Action failed with error: Unsupported event type: discussion

The action only recognizes issues / pull_request / issue_comment / workflow_dispatch event contexts; discussion is not in its allowlist, so it bails before Bob runs. The label gate works, gather-context.sh succeeds, then the action immediately fails.

Repro

1. Add idea:approved to any Ideas Discussion → planner fires on the discussion event.
2. Job reaches Plan the initiative (BMAD Scrum Master) and fails with Unsupported event type: discussion.

Observed on Discussion #572 (run 27381411218). The workflow_dispatch path is not affected and works — discussion #572 was successfully planned into Epic #581 via:

gh workflow run initiative-planner.yml -f discussion=572 -f dry_run=false

Impact

The documented two-gate flow (idea:approved → planner → initiative:auto) cannot complete automatically. Today the only working path is a manual workflow_dispatch, so a human must hand-dispatch every approved idea — defeating the label-driven automation.

Fix options

1. Re-dispatch pattern (no upstream dependency, recommended): keep on: discussion [labeled], but in that event the job only resolves the discussion number and re-invokes the workflow via workflow_dispatch (gh workflow run … -f discussion=<n> -f dry_run=false). The action then runs under a supported event. Cleanest decoupling; the label stays the human gate.
2. Bump claude-code-action to a SHA that supports discussion events (or fully skips event-context parsing when an explicit prompt: is supplied). Needs verification that such a release exists; SHA must be looked up via the GitHub API per CLAUDE.md.

Option 1 is self-contained in this repo and provider-version-independent.

Notes

• Separate, related robustness bug in gather-context.sh (hard-fails on Discussion-number #NNN refs via REST issues/NNN) is being handled in another session — not this issue.
• Workflow: .github/workflows/initiative-planner.yml; action pin at the Plan the initiative step.
• Pipeline context: PR feat(initiatives): idea-triage + BMAD Scrum Master initiative-planner #567 (first real exercise was Idea 💡 SkillOpt-Style Self-Improving Skills: Eval-Gated, Human-Reviewed Agent Skill Evolution #572 → Epic Initiative: Eval-gated, human-reviewed self-improving skills (SkillOpt-style) #581).

[don-petry]

Review & analysis

Verdict: confirmed bug; root cause and repro are accurate. The idea:approved → planner auto-trigger cannot work with the current design because claude-code-action doesn't accept a discussion event context. The label gate + gather-context.sh run fine, then the action aborts in the "Plan the initiative" step.

Fix Option 2 (bump claude-code-action) — not viable today ❌

I checked the action's event allowlist in the latest release, v1.0.144 (src/github/context.ts). The supported event types are exactly:

issues, issue_comment, pull_request, pull_request_review, pull_request_review_comment, workflow_dispatch, repository_dispatch, schedule, workflow_run

discussion is not among them — it falls through to default: throw new Error("Unsupported event type: …"). So no released version (incl. latest) fixes this; Option 2 would require an upstream feature request to anthropics/claude-code-action. Rule it out.

Fix Option 1 (re-dispatch) — correct, with one critical detail ✅

The action already supports repository_dispatch and workflow_dispatch, so re-entering the planner under one of those is the fix. But the re-dispatch must be fired with a PAT (GH_PAT_WORKFLOWS), not GITHUB_TOKEN — GitHub does not start new workflow runs from events created by the default GITHUB_TOKEN (loop prevention). This is the same class of bug already documented in this repo in scripts/initiative-driver.sh (applies the dev-lead label with a PAT) and pr-review-mention.yml. Using GITHUB_TOKEN here would silently no-op.

Recommended variant — repository_dispatch (mirrors the existing gh-aw-cross-org.yml / pr-review-mention.yml pattern):

1. Add on: repository_dispatch: types: [initiative-plan] to the planner.
2. In the existing discussion: [labeled] path, the job does only one thing — fire the dispatch with the discussion number, using the PAT:

   gh api repos/${{ github.repository }}/dispatches -X POST \
     -f event_type=initiative-plan \
     -F client_payload[discussion]=${{ github.event.discussion.number }}
   # GH_TOKEN=${{ secrets.GH_PAT_WORKFLOWS }}

3. The planner job reads github.event.client_payload.discussion and runs under the (supported) repository_dispatch event. The idea:approved label stays the human gate.

A workflow_dispatch re-invoke (gh workflow run … -f discussion=<n>) also works and is slightly simpler, but still requires the PAT for the same reason; repository_dispatch is preferred only because it matches the org's established cross-trigger convention and carries a typed payload.

Either way: update DISCUSSION_NUMBER / the job if: to read the new event, and keep DRY_RUN=0 (live) on this path so an approved idea plans for real.

Notes / related work

• The related gather-context.sh robustness bug (hard-fails on Discussion-number #NNN refs) is fixed in fix(initiative-planner): skip non-issue references in gather-context #579 (in flight) — complementary, not overlapping.
• The pipeline itself is proven: the workflow_dispatch path planned Discussion 💡 SkillOpt-Style Self-Improving Skills: Eval-Gated, Human-Reviewed Agent Skill Evolution #572 → Epic Initiative: Eval-gated, human-reviewed self-improving skills (SkillOpt-style) #581 with a valid Phase-1/2 DAG ([Phase 1] Define held-out eval-case format + seed prompts/triage.md case set #582–[Phase 2] Strict-improvement gate + manual propose->validate->PR runbook with regression-rejection proof #586). This bug is the last gap to make the documented label-driven flow fully automatic.
• Scope: single-file change to .github/workflows/initiative-planner.yml; uses the existing org secret GH_PAT_WORKFLOWS. Good candidate for a dev-lead pickup.

Recommendation: implement Option 1 (repository_dispatch + GH_PAT_WORKFLOWS); close Option 2 as not-feasible.

[don-petry]

Dev-Lead Implementation Plan

Issue: #591 — bug(initiative-planner): claude-code-action rejects discussion events — the idea:approved auto-trigger never plans

Scope

Adopt Fix Option 1 (re-dispatch): keep on: discussion [labeled], but on that event a lightweight job resolves the discussion number and re-invokes the same workflow via workflow_dispatch, so the BMAD planner step runs under an event claude-code-action supports.

Implementation Checklist

• scripts/initiative-planner/redispatch.sh (new) — validate DISCUSSION_NUMBER is a positive int, then gh workflow run initiative-planner.yml -f discussion=<n> -f dry_run=false. Documents that the dispatch MUST use a PAT (GH_PAT_WORKFLOWS), since a workflow_dispatch created with GITHUB_TOKEN will not start a run (loop prevention — same constraint as initiative-driver.yml).
• .github/workflows/initiative-planner.yml — split the single plan job: add a redispatch job gated on github.event_name == 'discussion' && github.event.label.name == 'idea:approved' (checkout + PAT guard + run redispatch.sh); narrow the existing plan job's if to github.event_name == 'workflow_dispatch'.
• .github/workflows/lint.yml — register the new bats test file in the bats job list (per AGENTS.md repo-specific test-list exception).

Tests to Write

• tests/test_initiative_planner_redispatch.bats (new), mocking gh:
  • re-dispatches with workflow run initiative-planner.yml, -f discussion=<n>, -f dry_run=false
  • threads the actual discussion number through
  • fails when DISCUSSION_NUMBER is missing
  • fails when DISCUSSION_NUMBER is non-numeric (no gh call made)
  • honors a WORKFLOW_FILE override

Test Command

bats tests/test_initiative_planner_redispatch.bats tests/test_initiative_planner.bats (full suite: the bats list in .github/workflows/lint.yml), plus bash .dev-lead/scripts/dev-lead-lint.sh

[don-petry]

Dev-Lead: Implementation Complete

Implemented Fix Option 1 (re-dispatch) — the self-contained, provider-version-independent fix.

Plan Execution

• Added scripts/initiative-planner/redispatch.sh — validates DISCUSSION_NUMBER is a positive integer, then gh workflow run initiative-planner.yml -f discussion=<n> -f dry_run=false.
• Split initiative-planner.yml into two jobs:
  • new redispatch job — gated on github.event_name == 'discussion' && github.event.label.name == 'idea:approved'; checks out, guards the PAT, runs redispatch.sh.
  • existing plan job — narrowed to if: github.event_name == 'workflow_dispatch'; the BMAD/claude-code-action step now only ever runs under a supported event.
• Registered tests/test_initiative_planner_redispatch.bats in the lint.yml bats list (per the AGENTS.md repo-specific test-list exception).
• Updated scripts/initiative-planner/README.md (file table + tests line).

Key design note — why a PAT, not GITHUB_TOKEN

A workflow_dispatch fired with the default GITHUB_TOKEN is accepted by the API but never starts a run (GitHub loop-prevention) — the planner would silently no-op. So the re-dispatch uses GH_PAT_WORKFLOWS, the same constraint already documented in initiative-driver.yml/initiative-driver.sh. The redispatch job hard-fails fast if that secret is absent.

The non-numeric DISCUSSION_NUMBER guard also keeps the value from reaching the gh command line unsanitized.

Test Results

TDD: wrote tests/test_initiative_planner_redispatch.bats first (red — exit 127, script absent), then implemented to green. Full suite (the lint.yml bats list) + dev-lead-lint.sh + shellcheck all pass.

1..7
ok 1 re-dispatches the planner workflow via workflow_dispatch
ok 2 threads the discussion number and forces dry_run=false
ok 3 targets the correct repo
ok 4 fails when DISCUSSION_NUMBER is unset
ok 5 rejects a non-numeric DISCUSSION_NUMBER without dispatching
ok 6 fails when REPO is unset
ok 7 honors a WORKFLOW_FILE override

Full bats suite: 203/203 passing. dev-lead-lint.sh: all checks passed (shellcheck on 46 files + agent-profile frontmatter).

Files Changed

• scripts/initiative-planner/redispatch.sh (new): discussion → workflow_dispatch bridge.
• .github/workflows/initiative-planner.yml: new redispatch job; plan job restricted to workflow_dispatch; dead discussion-event fallbacks removed from the plan env block.
• .github/workflows/lint.yml: registered the new bats test file.
• tests/test_initiative_planner_redispatch.bats (new): 7 cases, mocked gh.
• scripts/initiative-planner/README.md: doc sync.

Notes

• The idea:approved label remains the human gate; the re-dispatch is invisible to maintainers.
• Concurrency group is unchanged and keyed on the discussion number for both event paths, so the brief redispatch run and the dispatched plan run serialize (no overlap).
• Requires the GH_PAT_WORKFLOWS secret to be present for the discussion-triggered path (already used by initiative-driver.yml).
• The related gather-context.sh #NNN robustness bug is explicitly out of scope (handled in another session) and was not touched.