chore: sync 4 org-standard workflow stub(s) from petry-projects/.github

[don-petry]

User description

Syncs the following org-standard workflow stub(s) from petry-projects/.github (standards/workflows/), deployed verbatim:

• add-to-project.yml
• initiative-driver.yml
• pr-auto-review.yml
• feature-ideation.yml

Opened by scripts/deploy-standard-workflows.sh. Stubs are thin callers; all behaviour lives in the reusables. See standards/ci-standards.md. Labeled standards-sync and left for the normal review/auto-merge pipeline — the deploy script never merges directly.

---

CodeAnt-AI Description

Sync org workflow stubs to the new stable release channels

What Changed

• Updated the project, initiative, PR review, and feature ideation workflow stubs to use the new v1-stable release channels
• PR auto-review now uses the repo’s main CI workflow name and is set up to keep working when the canonical token is available first
• Initiative dispatch now shows a clearer error when the required workflow token is missing

Impact

✅ More reliable org workflow updates
✅ Fewer PR review setup failures
✅ Clearer workflow token errors

💡 Usage Guide

Checking Your Pull Request

Every time you make a pull request, our system automatically looks through it. We check for security issues, mistakes in how you're setting up your infrastructure, and common code problems. We do this to make sure your changes are solid and won't cause any trouble later.

Talking to CodeAnt AI

Got a question or need a hand with something in your pull request? You can easily get in touch with CodeAnt AI right here. Just type the following in a comment on your pull request, and replace "Your question here" with whatever you want to ask:

@codeant-ai ask: Your question here

This lets you have a chat with CodeAnt AI about your pull request, making it easier to understand and improve your code.

Example

@codeant-ai ask: Can you suggest a safer alternative to storing this secret?

Preserve Org Learnings with CodeAnt

You can record team preferences so CodeAnt AI applies them in future reviews. Reply directly to the specific CodeAnt AI suggestion (in the same thread) and replace "Your feedback here" with your input:

@codeant-ai: Your feedback here

This helps CodeAnt AI learn and adapt to your team's coding style and standards.

Example

@codeant-ai: Do not flag unused imports.

Retrigger review

Ask CodeAnt AI to review the PR again, by typing:

@codeant-ai: review

Check Your Repository Health

To analyze the health of your code repository, visit our dashboard at https://app.codeant.ai. This tool helps you identify potential issues and areas for improvement in your codebase, ensuring your repository maintains high standards of code health.

[codeant-ai]

🤖 CodeAnt AI — Review Status

Status	Commit	Started (UTC)	Finished (UTC)
✅ Reviewed your PR	d51fcd4	Jul 22, 2026 · 11:44	11:44

_{Updated in place by CodeAnt AI · last 5 reviews}

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

[gemini-code-assist]

Note

Gemini is unable to generate a review for this pull request due to the file types involved not being currently supported.

[coderabbitai]

Warning

Review limit reached

@don-petry, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 52 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 37e96924-8025-4373-bfe9-e256c61d89b0

📥 Commits

Reviewing files that changed from the base of the PR and between 9973619 and d51fcd4.

📒 Files selected for processing (4)

• .github/workflows/add-to-project.yml
• .github/workflows/feature-ideation.yml
• .github/workflows/initiative-driver.yml
• .github/workflows/pr-auto-review.yml

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch standards-sync/workflows-20260722

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[don-petry]

Dev-Lead — review-changes (no-changes)

No changes were needed for this PR.

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[qodo-code-review]

PR Summary by Qodo

Sync org-standard GitHub Actions workflow stubs to v1-stable channels

⚙️ Configuration changes 🕐 10-20 Minutes

AI Description

• Update org-standard workflow stubs to use the new */v1-stable moving-channel tags.
• Align PR Auto-Review stub guidance, triggers, and PAT secret fallback behavior.
• Tighten Initiative Driver PAT guard messaging to match current secret expectations.

Diagram

graph TD
  gh["GitHub events"] --> add["add-to-project.yml"] --> reus{{"petry-projects/.github reusables"}}
  gh --> idea["feature-ideation.yml"] --> reus
  gh --> review["pr-auto-review.yml"] --> reus
  gh --> init["initiative-driver.yml"] --> central{{"petry-projects/.github-private driver"}}

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Pin reusables to immutable tags (e.g., @v1) or SHAs

• ➕ Fully reproducible behavior per repo; avoids surprise changes when the central tag moves
• ➕ Easier incident forensics because exact revision is embedded in the caller
• ➖ Conflicts with the stated org compliance model (moving-channel rollout/rollback)
• ➖ Requires fan-out PRs to upgrade every repo for fixes/rollbacks

2. Vendor/copy reusable logic into each repo (no cross-repo `uses:`)

• ➕ No dependency on external repos/tags at runtime
• ➕ Repo-local changes can be reviewed/rolled back independently
• ➖ Destroys the ‘single source of truth’ benefit; high maintenance and drift risk
• ➖ Harder to apply security fixes consistently across all repos

Recommendation: Keep the moving-channel */v1-stable approach as in this PR; it matches the org’s rollout/rollback and compliance constraints and preserves centralized maintenance. Do, however, verify the pr-auto-review.yml workflow_run.workflows list matches this repo’s actual CI workflow names (currently the repo has e.g. "CI Pipeline" / "Node.js Tests"), otherwise readiness checks may stop re-triggering on CI completion.

Files changed (4) +21 / -24

Other (4) +21 / -24

add-to-project.ymlMove add-to-project reusable reference to 'add-to-project/v1-stable' +2/-2

Move add-to-project reusable reference to 'add-to-project/v1-stable'

• Updates the stub’s documentation and 'uses:' ref to the new 'add-to-project/v1-stable' moving-channel tag. Keeps the caller as a thin wrapper around the org reusable while aligning 'agent_ref' with the channel.

.github/workflows/add-to-project.yml

feature-ideation.ymlMove feature-ideation reusable reference to 'feature-ideation/v1-stable' +1/-1

Move feature-ideation reusable reference to 'feature-ideation/v1-stable'

• Updates the 'uses:' ref for the feature ideation reusable to the new 'feature-ideation/v1-stable' channel. No functional changes beyond the tag/channel alignment.

.github/workflows/feature-ideation.yml

initiative-driver.ymlTighten PAT guard error messaging for initiative-driver dispatcher +1/-1

Tighten PAT guard error messaging for initiative-driver dispatcher

• Simplifies the guard step error message to state 'GH_PAT_WORKFLOWS' is required when the PAT is missing. Dispatcher logic and secret fallback usage remain unchanged.

.github/workflows/initiative-driver.yml

pr-auto-review.ymlAlign PR Auto-Review stub with v1-stable channel, triggers, and PAT fallback +17/-20

Align PR Auto-Review stub with v1-stable channel, triggers, and PAT fallback

• Rewrites guidance comments to enforce the moving-channel model and updates 'uses:' to 'pr-auto-review/v1-stable'. Changes 'workflow_run.workflows' to a placeholder '["CI"]' with a TODO, and adjusts secrets to prefer 'GH_PAT_DON_PETRY' with fallback to 'GH_PAT_WORKFLOWS' while keeping the passed secret key name stable.

.github/workflows/pr-auto-review.yml

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (3) 📘 Rule violations (0) 📜 Skill insights (0)

Context used

✅ Compliance rules (platform): 20 rules

1. Wrong CI workflow name 🐞 Bug ≡ Correctness

Description

pr-auto-review listens for workflow_run on a workflow named "CI", but this repo’s CI workflow is
named "CI Pipeline", so the ready-check won’t run when CI completes. This breaks the intended
readiness re-evaluation path after GitHub Actions CI turns green.

Code

.github/workflows/pr-auto-review.yml[R31-34]

+  # TODO: replace "CI" with your repository's CI workflow name(s).
  workflow_run:
-    workflows: ['Node.js Tests', 'CI Pipeline']
+    workflows: ["CI"]
    types: [completed]

Relevance

⭐⭐⭐ High

Team previously accepted replacing workflow_run.workflows placeholder with actual CI workflow names
(PR #355).

PR-#355

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The pr-auto-review workflow is configured to trigger on completion of a workflow named "CI", but the
repository’s CI workflow declares its name as "CI Pipeline", so the workflow_run trigger will not
match.

.github/workflows/pr-auto-review.yml[27-34]
.github/workflows/ci.yml[1-5]
PR-#355

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`workflow_run.workflows` must match the *workflow `name:`* exactly. The current stub is configured for `"CI"`, but this repository’s CI workflow is named `"CI Pipeline"`, so the pr-auto-review workflow will not fire on CI completion.

### Issue Context
- Current pr-auto-review config uses `workflows: ["CI"]`.
- The repo’s CI workflow declares `name: CI Pipeline`.

### Fix Focus Areas
- .github/workflows/pr-auto-review.yml[27-35]
- .github/workflows/ci.yml[1-5]

### Expected fix
Update `.github/workflows/pr-auto-review.yml` so `on.workflow_run.workflows` includes the actual workflow name(s) used in this repo (at minimum `CI Pipeline`; optionally also include other CI workflows such as `Node.js Tests` if desired).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. Missing fork PR guard 🐞 Bug ☼ Reliability

Description

The pr-auto-review job no longer skips fork PRs for pull_request/pull_request_review events,
yet it still requires a PAT secret passed into the reusable workflow. This will cause failures/noise
on fork PR events when org/repo secrets aren’t available in that context.

Code

.github/workflows/pr-auto-review.yml[R47-58]

jobs:
  pr-auto-review:
-    # Skip fork PRs on pull_request and pull_request_review events — forks don't
-    # receive org secrets, so GH_PAT_WORKFLOWS would be empty and the reusable's
-    # gh api calls would fail. Other triggers (workflow_run, check_suite) always
-    # run in the base-repo context and have full secret access.
-    if: >
-      (github.event_name != 'pull_request' && github.event_name != 'pull_request_review') ||
-      github.event.pull_request.head.repo.fork == false
    permissions:
      pull-requests: read
      checks: read
      actions: read
-    uses: petry-projects/.github/.github/workflows/pr-auto-review-reusable.yml@pr-auto-review/stable # NOSONAR(githubactions:S7637) first-party channel ref
+    uses: petry-projects/.github/.github/workflows/pr-auto-review-reusable.yml@pr-auto-review/v1-stable  # NOSONAR(githubactions:S7637) first-party channel ref
    secrets:
-      GH_PAT_WORKFLOWS: ${{ secrets.GH_PAT_WORKFLOWS }}
+      # Canonical-first fallback (.github-private#1326). The reusable resolves this
+      # secret BY NAME, so only the VALUE changes — the passed key stays named
+      # GH_PAT_WORKFLOWS.
+      GH_PAT_WORKFLOWS: ${{ secrets.GH_PAT_DON_PETRY || secrets.GH_PAT_WORKFLOWS }}

Relevance

⭐⭐⭐ High

Fork PR skip guard for secret-dependent pr-auto-review was accepted previously (PR #355).

PR-#355

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The workflow is configured to run on pull_request and pull_request_review and passes a PAT
secret into the reusable; the prior accepted fix pattern was to guard against fork PR events to
avoid missing-secret failures, but the guard is now absent.

.github/workflows/pr-auto-review.yml[38-44]
.github/workflows/pr-auto-review.yml[47-58]
PR-#355

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The PR removed the job-level `if:` guard that prevented running the PAT-dependent reusable on fork PR events. The workflow still triggers on `pull_request` and `pull_request_review` and still passes `GH_PAT_WORKFLOWS` into the reusable, so fork PRs will invoke the job without the required secret and typically fail.

### Issue Context
- The workflow triggers on `pull_request` and `pull_request_review`.
- The job calls the reusable and passes `GH_PAT_WORKFLOWS`.

### Fix Focus Areas
- .github/workflows/pr-auto-review.yml[38-58]

### Expected fix
Re-introduce a job-level `if:` that skips forked PRs specifically for `pull_request` and `pull_request_review` events, while still allowing `workflow_run` / `check_suite` events to run in the base repo context (per the previously accepted pattern).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

3. Misleading PAT guard message 🐞 Bug ◔ Observability

Description

initiative-driver sets GH_TOKEN from secrets.GH_PAT_DON_PETRY || secrets.GH_PAT_WORKFLOWS, but
the guard error message claims only GH_PAT_WORKFLOWS is required. This makes diagnosing
missing-token failures misleading and regresses previously accepted guidance.

Code

.github/workflows/initiative-driver.yml[R76-81]

          GH_TOKEN: ${{ secrets.GH_PAT_DON_PETRY || secrets.GH_PAT_WORKFLOWS }}
        run: |
          if [ -z "${GH_TOKEN}" ]; then
-            echo "::error::Either GH_PAT_DON_PETRY or GH_PAT_WORKFLOWS is required — a workflow_dispatch fired with GITHUB_TOKEN never starts a run."
+            echo "::error::GH_PAT_WORKFLOWS is required — a workflow_dispatch fired with GITHUB_TOKEN never starts a run."
            exit 1
          fi

Relevance

⭐⭐⭐ High

Same guard-message mismatch fix was accepted in PRs #468 and #474 for initiative-driver.yml.

PR-#468
PR-#474

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The workflow’s guard checks an env var populated via a two-secret fallback, but the emitted
::error:: message only names one of the two accepted secrets, which is inconsistent with the code
and matches a previously accepted bug pattern.

.github/workflows/initiative-driver.yml[73-81]
PR-#474
PR-#468

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The PAT guard error message does not match how `GH_TOKEN` is actually sourced. `GH_TOKEN` uses a two-secret fallback, but the message claims only one secret is required.

### Issue Context
- `GH_TOKEN` is set to `secrets.GH_PAT_DON_PETRY || secrets.GH_PAT_WORKFLOWS`.
- The guard error message says `GH_PAT_WORKFLOWS is required`.

### Fix Focus Areas
- .github/workflows/initiative-driver.yml[73-81]

### Expected fix
Update the error string to state that either `GH_PAT_DON_PETRY` or `GH_PAT_WORKFLOWS` is required (or adjust the token logic to match the message, but keep it consistent).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---