Initiative: unify Discussion-triggered ideation into a feature-ideation mode, deprecate idea-enhancer, and roll out fleet-wide via canary rings

[don-petry]

Summary

Make the Discussion-triggered ideation/enhancement capability a single, canonical
mode of feature-ideation, deprecate the standalone idea-enhancer.yml, and roll the
unified capability to all 8 org repos using the canary / concentric-ring release process
already established for dev-lead and pr-review
(versioning,
agentic-release-strategy).

One idea, one enhancer, one release channel per repo — no double-enhancement, blast radius
bounded to one ring at a time, rollback = a single channel-tag move.

---

Background

Two automations currently fire on discussion: { types: [created] } against the Ideas
category and both enhance a freshly-opened human idea:

1. feature-ideation.yml — enhancement mode (the standardized one). A thin caller stub →
   petry-projects/.github/.github/workflows/feature-ideation-reusable.yml@<sha> # v1. Its
   weekly cron generates new Ideas (BMAD Analyst "Mary", Opus 4.6); on discussion: created
   it passes target_discussion to the reusable, which runs single-idea mode to research
   and refine that one human idea. Guard: category.slug == 'ideas' && user.type != 'Bot'.
2. idea-enhancer.yml — dedicated enhancer (org-private, not standardized). Tooling in
   scripts/idea-enhancer/{gather-candidates,post-enhancement}.sh, tested in
   tests/test_idea_enhancer.bats. On discussion: created (+ a Wednesday safety-net cron) it
   finds open, human-authored, not-yet-enhanced Ideas and posts one structured comment
   (sharpened problem / context / impact-effort / acceptance criteria, Sonnet 4.6), idempotent
   via the hidden marker <!-- idea-enhancer:enhanced -->.

Why this overlap exists (git archaeology)

• idea-enhancer.yml was added in PR feat: implement issue #638 — Feature Ideation doesn't enhance human ideas #644 / issue Feature Ideation doesn't enhance human ideas #638 ("Feature Ideation doesn't enhance
  human ideas") — at that time feature-ideation only generated ideas.
• PR feat: implement issue #629 — Compliance: non-stub-feature-ideation.yml #805 / issue Compliance: non-stub-feature-ideation.yml #629 later added the discussion: created enhancement mode to
  feature-ideation itself.

Net effect: in .github-private both fire on the same event and both enhance the same
new human idea — one via Opus single-idea mode, one via a Sonnet comment. They do not dedupe
against each other (different markers). This redundancy must be resolved before the capability
is propagated, or the rest of the fleet inherits double-enhancement.

---

Current fleet state (verified via GitHub API, 2026-06-21)

Repo	BMAD	feature-ideation	disc-trigger enhance	reusable pin	idea-enhancer	rest of pipeline
.github-private	infra	✓	✓	897e4de	✓	triage + planner + driver
.github	infra	✓	✓	0011a11	✗	planner only
markets	yes	✓	✓	897e4de	✗	✗
broodly	yes	✓	✓	897e4de	✗	✗
TalkTerm	yes	✓	✗ stale stub	ce8a8c3	✗	✗
google-app-scripts	yes	✓	✗ stale stub	ce8a8c3	✗	✗
bmad-bgreat-suite	no marker	✗	—	—	✗	✗
ContentTwin	no	✗	—	—	✗	✗

Findings:

• Discussion-triggered enhancement is live in 4/8 repos.
• TalkTerm + google-app-scripts are BMAD repos on stale stubs (pinned ce8a8c3, no
  discussion: block) — they generate weekly but never enhance new human ideas.
• bmad-bgreat-suite + ContentTwin lack the workflow entirely (no _bmad/ marker → excluded
  by current ci-standards §9, which is BMAD-only). This initiative widens scope to all 8.
• No repo ships a customized .github/feature-ideation-sources.md (all fall back to open web
  search — acceptable, out of scope here).
• idea-enhancer + idea-triage + initiative-planner + initiative-driver are
  .github-private-only and not standardized.

---

Goals

1. Consolidate to one canonical enhancer. Make Discussion-triggered enhancement an explicit
   mode of feature-ideation (the standardized stub + reusable). Fold idea-enhancer's
   "post one structured, idempotent comment on a new human idea" behavior into the reusable.
2. Deprecate idea-enhancer. Remove idea-enhancer.yml, scripts/idea-enhancer/**, and
   tests/test_idea_enhancer.bats from .github-private once the folded mode is proven in the
   next ring. Preserve the idempotency marker (or migrate it) so already-enhanced ideas are
   never re-enhanced across the cutover. Update the
   idea-to-initiative-pipeline
   doc to describe the single enhancer.
3. Standardize feature-ideation under the canary/ring release model. Introduce per-agent
   channel tags for it (feature-ideation/{next,ring0,ring1,stable}) on petry-projects/.github,
   exactly mirroring the dev-lead/pr-review scheme. Callers pin once to a channel; promotion
   is a central tag move; rollback is a single pointer flip. Extend scripts/cut-release.sh /
   docs/release/ to cover the feature-ideation agent.
4. Roll out to all 8 repos with the per-repo ring assignment below — including onboarding the
   two repos that lack the workflow. Widen ci-standards §9 from "BMAD-only" to "all repos with
   Discussions + an Ideas category."
5. No double-enhancement, idempotent, validated against real existing Discussions before any
   ring is promoted.

---

Ring assignment (canary → stable)

Channel	Repo(s)	Role
feature-ideation/next	.github-private	Candidate / dogfood-first. Newest code exercised here.
feature-ideation/ring0	.github	First promotion ring after next is healthy.
feature-ideation/ring1	TalkTerm	Second ring.
feature-ideation/stable	markets, broodly, google-app-scripts, bmad-bgreat-suite, ContentTwin	Production. Promoted last, only after ring1 is healthy.

Each repo's feature-ideation.yml stub is repinned once from its current @<sha> # v1 to its
assigned channel tag, then never edited again. Promotion walks next → ring0 → ring1 → stable by
moving the channel tag centrally, with a health check between rings.

---

Validation — test with existing un-enhanced Discussions

Before promoting each ring, prove the folded enhancement mode works on real, already-open,
not-yet-enhanced Ideas Discussions (no synthetic fixtures). Use dry_run first (logs intended
comments to an artifact), then a live run, and confirm: exactly one enhancement comment, the
idempotency marker is written, a second run is a no-op, and bot-authored ideas are skipped.

Concrete candidates that are open + human-authored + un-enhanced today:

• next (.github-private): Enhanced Prompting Frameworks #851 "Enhanced Prompting Frameworks".
• ring0 (.github): [Phase 1] Pin all callers off @main to the stable tag (consumer repos + self-review/dev duty) #497 "enable pull request limits", feat: pin actions/checkout to SHA in deploy-pr-review.yml #474 "enable GitHub code quality",
  📊 Token Cost Observatory — Weekly Report #464 "Implement Claude generic code review", Scorecard: Code-Review (6/10) #386 "Enable and adopt usage of GitHub Projects".
• ring1 (TalkTerm): Compliance: missing-pr-quality #59 "Windows 11 On-Device AI", Compliance: has_discussions #58 "3D Avatar Evolution",
  Compliance: delete_branch_on_merge #57 "Infinite Conversations via Client-Side Compaction", Compliance: allow_auto_merge #56 "Cloud Voice Provider Pipeline",
  Compliance: missing-dependencies-label #55 "Effort Modes".

Also verify the deprecation cutover in .github-private: after idea-enhancer.yml is removed
and the folded mode is active, opening a new human Idea produces one enhancement (not two).

---

Acceptance criteria

• feature-ideation-reusable.yml has an explicit enhancement mode that, on a single targeted
  human Idea, posts exactly one idempotent structured comment (problem / context /
  impact-effort / acceptance criteria); marker prevents re-enhancement; bots skipped.
• idea-enhancer.yml, scripts/idea-enhancer/**, tests/test_idea_enhancer.bats removed from
  .github-private; pipeline doc + ci-standards updated to a single enhancer.
• Marker continuity: ideas already carrying <!-- idea-enhancer:enhanced --> are not
  re-enhanced after cutover.
• Channel tags feature-ideation/{next,ring0,ring1,stable} exist on petry-projects/.github;
  cut-release.sh + docs/release/{versioning,runbook}.md cover the feature-ideation agent.
• All 8 repos have feature-ideation.yml, each pinned to its assigned channel; the two
  missing repos are onboarded with a tailored project_context.
• ci-standards §9 widened from BMAD-only to "Discussions + Ideas category."
• Validation runs (dry-run + live) recorded against the listed existing Discussions per ring;
  .github-private cutover shows single-enhancement; each ring health-checked before promotion.
• Documented rollback: revert a channel tag to its prior immutable feature-ideation/vX.Y.Z.

---

Out of scope

• Per-repo feature-ideation-sources.md customization.
• Changes to idea-triage / initiative-planner / initiative-driver beyond doc updates.
• The weekly generation pipeline's prompt/model (only the enhancement mode + delivery change).

---

Authored as the ripe Ideas Discussion for the idea→initiative pipeline. Add idea:approved to
hand this to initiative-planner (BMAD Scrum Master "Bob") for epic + story-DAG planning.

[github-actions[bot]]

📋 Initiative planned by the BMAD Scrum Master (Bob).

Epic #872 — Initiative: Consolidate Discussion-triggered ideation into feature-ideation, deprecate idea-enhancer, and ring-release fleet-wide

4 stories created (inert — labelled initiative, NOT initiative:auto):

• [Phase 1] Extend cut-release.sh + release docs to cover the feature-ideation agent #873 (M) — [Phase 1] Extend cut-release.sh + release docs to cover the feature-ideation agent
• [Phase 2] Repin .github-private's feature-ideation.yml stub to the feature-ideation/next channel + update its compliance test #874 (S) — [Phase 2] Repin .github-private's feature-ideation.yml stub to the feature-ideation/next channel + update its compliance test
• [Phase 2] Validate the folded feature-ideation enhancement mode on real .github-private Discussions (next ring) #875 (M) — [Phase 2] Validate the folded feature-ideation enhancement mode on real .github-private Discussions (next ring)
• [Phase 3] Deprecate idea-enhancer in .github-private: remove workflow + scripts + test, update the pipeline doc #876 (M) — [Phase 3] Deprecate idea-enhancer in .github-private: remove workflow + scripts + test, update the pipeline doc

Open questions for review:

• How is the cross-repo half of this initiative tracked and sequenced? The folded enhancement mode in feature-ideation-reusable.yml, the feature-ideation/{next,ring0,ring1,stable} channel tags + ruleset, the ci-standards §9 widening + compliance-audit update, and the repins/onboarding of the other 7 repos all live in petry-projects/.github and the fleet repos — outside this planner's repo and dev-lead's single-repo reach. Stories 2-4 here are hard-gated on those prerequisites (captured in the epic's Untracked prerequisites). Should a parallel epic be opened in petry-projects/.github to own that work, and should this repo's stories 2-4 be treated as blocked on its completion?
• Where do feature-ideation's release/channel tags physically live, and how should cut-release.sh push them? feature-ideation's reusable lives in petry-projects/.github (not this repo), so its tags belong on that repo, but cut-release.sh's main() pushes to this repo's origin. Confirm the intended mechanism: add a remote/--repo target so cut-release.sh pushes feature-ideation tags to petry-projects/.github, or move feature-ideation's release tooling into the public repo entirely?

---

Review the epic and its sub-issue DAG, adjust as needed, then add initiative:auto to epic #872 to hand it to initiative-driver for auto-implementation.

[github-actions[bot]]

Enhancement: Unify Discussion-triggered ideation (#866)

Sharpened problem & goal

Two workflows currently fire on discussion: { types: [created] } for the Ideas category: feature-ideation.yml (a thin stub calling the reusable multi-skill pipeline) and idea-enhancer.yml (org-private, posts a single enhancement comment). Both run Claude against the same new Discussion, potentially posting two comments within minutes of each other — confusing for the author and wasteful on tokens.

The proposal is to: (1) absorb the enhancement-comment logic into the reusable feature-ideation-reusable.yml as a single-idea "enhance" mode; (2) deprecate idea-enhancer.yml; (3) roll out the unified capability fleet-wide via canary rings.

Key ambiguity to resolve before implementation: does "enhance mode" replace the full 5-phase ideation pipeline for human-authored ideas, or does it run alongside it? The current idea-enhancer posts one concise comment (problem restatement + AC bullets); the reusable ideation pipeline generates new ideas. For a human-authored Discussion, you probably want enhancement-only — generating new ideas on the same thread would be noise.

Context

• idea-enhancer.yml is org-private automation (not a thin stub). Its gather/post scripts live in scripts/idea-enhancer/ with BATS tests (tests/test_idea_enhancer.bats). These would move into (or be called by) the reusable.
• feature-ideation.yml is the local thin stub (only project_context is repo-specific); the pipeline logic is in the central reusable.
• The canary/ring rollout process is already established (scripts/canary-rollout.sh, scripts/initiative_canary.sh, .github/workflows/canary-rollout.yml). The same pattern used for dev-lead and pr-review channel tags applies here.
• The triage pipeline (idea-triage.yml) and downstream planner are downstream of enhancement — the unified capability must preserve the idempotency marker so a re-run doesn't double-enhance.

Impact / Effort

Impact: HIGH — removes a confusing dual-comment race condition on every new human Idea; simplifies the fleet deployment footprint (one workflow to maintain instead of two).

Effort: L — requires changes to the central reusable (adding an "enhance-only mode" dispatch path), deprecating the org-private enhancer, creating a new thin-stub standard, and staging through canary rings across 8 repos. The BATS tests for scripts/idea-enhancer/ must transfer cleanly.

Suggested acceptance criteria

• The reusable feature-ideation-reusable.yml accepts a mode parameter (e.g. mode: enhance | ideate | auto) so callers can explicitly request enhancement-only for human ideas and full ideation for scheduled runs.
• When a human opens an Ideas Discussion, exactly one Claude comment appears (the enhancement comment) — the full ideation pipeline does not generate additional idea threads on that Discussion.
• idea-enhancer.yml is removed (or reduced to a tombstone stub that errors with a migration notice) after the unified capability reaches stable in the canary ring.
• The idempotency marker (<!-- idea-enhancer:enhanced -->) is preserved or superseded by a unified marker checked by scripts/idea-enhancer/gather-candidates.sh — no Discussion is enhanced twice across the transition.
• Fleet rollout follows existing ring conventions: .github-private (dogfood) → canary ring → stable ring, with a rollback path that is a single channel-tag move per the agentic-release-strategy doc.