feature-ideation template: the Discussion bridge stays green when the dispatched ideate run fails (move the fix out of the .github-private stub) #1322

Problem

In standards/workflows/feature-ideation.yml, the redispatch job bridges a new Ideas Discussion to a workflow_dispatch run and then exits green. If the dispatched ideate run fails, the Discussion shows nothing: the bridge succeeded, so the Idea looks handed off when no ideation ran.

This already cost three weeks. petry-projects/.github-private#1733 records every feature-ideation run failing at "Install Python jsonschema" from 2026-08-14, unnoticed because the bridge stayed green. That install failure is fixed (run 38099789205, 2026-10-11: the install step and the BMAD Analyst step both succeed). The silent-failure mode, criterion 4 of that issue, is still open.

Why this is filed here

petry-projects/.github-private#1796 implemented criterion 4 by editing that repo's own .github/workflows/feature-ideation.yml. That file is a thin caller stub synced from this repo's template. Its header says the job-level permissions: block must not change, and the next standards sync would revert the edit. The change belongs in the template. PR #1796 is on hold (needs-human-review) until this lands.

What PR #1796 did (reference, not a spec)

In the redispatch job:

• permissions: {} became discussions: write.
• After gh workflow run, it polls gh run list --workflow feature-ideation.yml --event workflow_dispatch for the newest run created at or after a timestamp taken just before the dispatch (six tries, five seconds apart), and falls back to the workflow's runs page.
• It posts that run link on the Discussion with addDiscussionComment, best effort.
• tests/test_feature_ideation.bats gained 58 lines covering it.

Diff: git fetch origin refs/pull/1796/head in .github-private, then git diff origin/main...FETCH_HEAD -- .github/workflows/feature-ideation.yml tests/test_feature_ideation.bats.

Open review finding to settle in the design

CodeRabbit on PR #1796 (thread on feature-ideation.yml:174): the timestamp lookup can pick another workflow_dispatch run created in the same window, so the Discussion can get the wrong run's link. dev-lead's reply: exact correlation needs something on the dispatch that identifies it, which the stub may not add but the template can. The dispatch already passes target_discussion=<number>; a run-name: that includes it is one way to match the run exactly. Decide this here rather than carrying the best-effort lookup over.

A posted link also only helps a person who opens it. Criterion 4 allows the other route: an alert the fleet monitor can see when the dispatched run fails.

Acceptance criteria

1. A failing ideate run that was bridged from a Discussion is visible from that Discussion, or raises an alert the fleet monitor reports. A green bridge over a failed run is no longer possible to miss.
2. If a run link is posted, it is the run this dispatch started, not merely the newest one. A concurrent manual dispatch does not change which link is posted.
3. The change is made in standards/workflows/feature-ideation.yml (and the reusable, if needed), with any new permission stated and justified in the template. No consumer repo edits its own stub.
4. Tests in this repo cover the bridge step: link posted on success, the fallback when the run cannot be found, and a posting failure not failing the bridge.
5. After the standards sync reaches .github-private, PR #1796 there is closed as superseded and .github-private#1733 is closed with the run link its criterion 3 asks for.

Related

• petry-projects/.github-private#1733 (the original failure and criterion 4).
• petry-projects/.github-private#1796 (the stub-level implementation, on hold).
• petry-projects/.github-private#2047 (deferred review findings, where the correlation finding is tracked).

Filed from a Claude Code session, at the maintainer's request, 2026-10-11.