chore: add reusable triage-discussions workflow for GitHub Discussions review

[bpamiri]

Adds a permanent, reusable Claude Code workflow at .claude/workflows/triage-discussions.js — maintainer tooling for periodically sweeping community GitHub Discussions to surface genuinely actionable items.

What it does

Three-phase pipeline, run with Workflow({name:"triage-discussions"}) (also appears in /workflows):

1. Fetch — one agent pulls the 100 most-recently-updated discussions, drops Announcements (maintainer marketing/release posts) and github-actions (monthly metrics bot), keeps everything updated since a cutoff, returns a structured candidate list.
2. Triage — a Sonnet agent per discussion reads the full thread, classifies it (bug / doc-gap / feature / answered-question / noise / …), and proposes an action.
3. Verify — for anything proposing a code fix, new issue, or doc change, a skeptical agent checks it against current code + git history + existing issues before it's allowed into the report. Answered questions and pure social replies skip this stage.

Read-only — it produces a verified findings report and posts nothing to GitHub.

Configurable via args (all optional)

{repo:"owner/name", since:"YYYY-MM-DD", max:40}, a JSON string, or a bare date string (treated as since). Defaults: wheels-dev/wheels, 2025-01-01, 40.

Provenance

The first run of this workflow (26 discussions) produced doc PR #3250 and issues #3251 / #3252, and its verify stage overturned 5 stale triage proposals (e.g. a "file an issue" for something already fixed with a regression test). Sibling maintainer workflow triage-and-fix-open-issues.js is intentionally not included here.

Tooling only — not part of the framework build or CI.

🤖 Generated with Claude Code

[wheels-bot]

Wheels Bot — Reviewer

TL;DR — This PR adds a single read-only Claude Code Workflow orchestration script (.claude/workflows/triage-discussions.js, +179) that sweeps recent GitHub Discussions, triages each thread, and adversarially verifies proposed actions before reporting. It is maintainer tooling, explicitly outside the framework build/CI, and touches no CFML — so the cross-engine invariants and ORM anti-patterns do not apply here. The script conforms to the documented Workflow-engine contract and the commit is well-formed. Verdict: approve.

Correctness

The script adheres to the Workflow engine semantics on every point I checked:

• The exported meta object is a pure literal (no variables, calls, or spreads), with the required name/description and a phases array whose titles (Fetch / Triage / Verify) match the phase() calls.
• No use of Date.now(), Math.random(), or argless new Date() — the globals that throw inside workflow scripts.
• The pipeline() second stage uses the documented (prevResult, originalItem, index) signature (here (t, c)) and correctly references c.number / c.title from the original item rather than threading them through stage 1.
• agent() null returns are handled both at the fetch boundary ((fetched && fetched.candidates) || []) and inside the pipeline (the if (!t) guard returning an early result).
• Agents inside the pipeline pass explicit per-call phase opts of Triage and Verify — the documented way to avoid racing the global phase() state across concurrent pipeline stages.
• The skip-path verdict object adds a non-schema skippedVerify field, but it is constructed manually (not validated against VERDICT_SCHEMA) and downstream only reads verdict.verdict, so this is harmless.

Two trivial, non-blocking observations (no change required):

• const MAX = opts.max || 40 coerces an explicit max of 0 to 40. Edge case only.
• reviewed: candidates.length reports candidate count rather than surviving findings count; if any triage agent returns null those diverge. Cosmetic.

Commits

chore: add reusable triage-discussions workflow — valid conventional-commit type, header well under 100 chars, not ALL-CAPS, and carries a Signed-off-by: trailer matching the author. The body explains the why (periodic actionable sweep without filing duplicates). Conforms to commitlint.config.js.

Docs

No changelog fragment, .ai/wheels/, or CLAUDE.md update is warranted: this is chore tooling, not a user-facing fix/feat, and it changes no model/controller/view/migration conventions. The PR body documents the args contract and provenance well.

Nice, well-structured use of the verify-after-triage pattern with a skeptical default. LGTM.