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

[don-petry]

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

• initiative-driver.yml
• pr-auto-review.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.

Summary by CodeRabbit

• Improvements
  • Automated initiative processing now checks agent rate-limit availability before dispatching work. When capacity is unavailable, processing is deferred; if the check cannot complete, dispatch continues.
  • Automated review workflows now handle default-branch events with per-pull-request deduplication, while direct pull request events run independently without cancelling one another.

[chatgpt-codex-connector]

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

[qodo-code-review]

ⓘ Qodo reviews are paused because your trial has ended. Ask your workspace admin to add credits to resume reviews. Manage billing

[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]

Understand this PR’s impact

Explore downstream dependencies and potential security impact with Blast Radius.

View blast radius →

Warning

Review limit reached

Next included review available in 59 minutes.

Check out review usage here.

View limit details

Limit details: You’ve used the included review currently available.

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

Learn how review limits work.

Review configuration:

⚙️ Run configuration

Configuration used: Repository: petry-projects/markets/.coderabbit.yaml

Review profile: CHILL

Plan: Advanced

Run ID: ed53dbc7-4ffc-40d6-a2ed-40cd1aba3ec4

📥 Commits

Reviewing files that changed from the base of the PR and between ee2a1f1 and 93bcfe3.

📒 Files selected for processing (2)

• .github/workflows/initiative-driver.yml
• .github/workflows/pr-auto-review.yml

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Repository: petry-projects/markets/.coderabbit.yaml

Review profile: CHILL

Plan: Advanced

Run ID: 828a411b-71ce-46ce-8d9d-2912aa42959f

📥 Commits

Reviewing files that changed from the base of the PR and between 86455a1 and ee2a1f1.

📒 Files selected for processing (2)

• .github/workflows/initiative-driver.yml
• .github/workflows/pr-auto-review.yml

Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review.

---

📝 Walkthrough

Walkthrough

Two workflows changed. initiative-driver now evaluates an enforcing rate-limit gate before dispatch. pr-auto-review changes concurrency grouping so default-branch triggers cancel per-PR runs, while direct pull request triggers use unique, non-cancellable groups.

Changes

Workflow controls

Layer / File(s)	Summary
Initiative dispatch admission gate .github/workflows/initiative-driver.yml	The workflow fetches rate-limit tooling, runs the gate with the configured tracking values, and emits allow or defer. Dispatch is skipped only for defer; missing or failed decisions remain fail-open.
Pull request review concurrency policy .github/workflows/pr-auto-review.yml	check_suite and workflow_run use cancellable per-PR groups. pull_request and pull_request_review use unique per-run groups without cancellation. The CI workflow comment is now a TODO placeholder.

Priority: ⬇️ Low

Estimated code review effort: 3 (Moderate) | ~20 minutes

Change: Other

Sequence Diagram(s)

sequenceDiagram
  participant Workflow as initiative-driver workflow
  participant Tooling as rate-limit gate tooling
  participant Gate as agent-rate-limit-gate.sh
  participant Dispatch as central initiative-driver
  Workflow->>Tooling: Checkout tooling at v1
  Workflow->>Gate: Run enforcing admission check
  Gate-->>Workflow: Return allow or defer
  Workflow->>Dispatch: Dispatch unless decision is defer

Loading

Suggested reviewers: donpetry-bot

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly describes the main change: syncing two organization-standard workflow stubs from petry-projects/.github.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 0…
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Commit to this branch
• Create a new PR

---

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 — waiting on PR blockers (intent: review-changes)

PR: #494
No changes were committed, but the PR still can't be marked done: required check SonarCloud is still pending. The retry cron will re-attempt automatically. Next attempt after: 2026-09-21T15:36:31Z

[don-petry]

Note

@don-petry I reviewed this PR and no code changes were needed, but I can't mark it done yet: required check SonarCloud is still pending. I'll re-check automatically.
Next attempt after: 2026-09-21T15:36:31Z

[don-petry]

No description provided.

[codeant-ai]

CodeAnt Nitpicks

1 code suggestion

1. These groups use only pull_requests[0]. A check suite or workflow run covering multiple PRs makes every event share the first PR's group, so one PR can cancel another's readiness check.

Logic error · .github/workflows/pr-auto-review.yml:62-65

[don-petry]

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

No changes were needed for this PR.

[don-petry]

dev-lead is withholding action on this item.

It is labeled needs-human-review (flagged for human review — this label is applied by automation as well as by people, so an item can become held without anyone noticing), so dev-lead will not pick it up while that label is present. This notice is posted once so the withhold is visible rather than looking like a stalled run.

To re-enable automated pickup: remove the needs-human-review label.

[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

[donpetry-bot]

Advisory bots were rate-limited; auto-approval is withheld until they recover. pr-review-sweep will re-review this PR after 2026-09-28T20:04:58Z.

[donpetry-bot]

Superseded by automated re-review at 93bcfe3e7bf63d88ac96a2e6a8f2c55c68bc1df8 — click to expand prior review.

Review — fix requested (cycle 1/3)

The automated review identified the following issues. Please address each one:

Findings to fix

Automated review — NEEDS HUMAN REVIEW

Risk: MEDIUM
Reviewed commit: 93bcfe3e7bf63d88ac96a2e6a8f2c55c68bc1df8
Cascade: triage → audit (triage: haiku 4.5 [sonnet 5] → deep: opus 5.5 [opus 4.8, sonnet 5] + duck: o4-mini → audit: opus 5.5 [opus 4.8, opus 4.7])

Summary

Both files match the current petry-projects/.github standards/workflows copies byte for byte, and I found no exploitable security flaw: no expression injection, secrets and actor values reach the steps through env, and the checkout sets persist-credentials: false. The new 'enforcing' rate-limit gate does nothing in this repo. The stub checks out petry-projects/.github at the v1 tag, but v1 points to a 2026-05-13 commit and scripts/agent-rate-limit-gate.sh only exists on main (added 2026-09-23). So the bash call exits 127, || true and continue-on-error hide the failure, no decision is written, and the dispatch always runs. Escalating for human sign-off: the continue-on-error hard-stop rule applies, the review check was CANCELLED, and the merge is BLOCKED, with the fix belonging upstream in the standard or the v1 tag.

Findings

• major: The admission gate runs bash .arl-gate-tooling/scripts/agent-rate-limit-gate.sh from petry-projects/.github@v1. The v1 tag (d3d768d, 2026-05-13) predates the script, which exists only on main (first commit 2026-09-23). Every run therefore fails with 'No such file'; || true plus continue-on-error hide it, steps.arl_gate.outputs.decision is empty, and the dispatch step's != 'defer' check always passes. The 'ENFORCES' canary described in the header comment has no effect, and nothing in the run signals that. Fix upstream: move or publish v1 with the gate, or point to a ref that has it. Also have the gate step emit a ::warning:: when no decision is produced so a fail-open is visible.
• major: The PR adds two continue-on-error: true steps, which trips the deterministic CI-weakening hard stop. This does not weaken an existing CI or test gate: it adds a rate-limit gate that fails open, so in the worst case behavior matches the pre-PR 'always dispatch'. The fail-open choice is documented (ADR §7). Still, the org rule needs a human to sign off on it, and combined with || true it currently hides a broken gate (see previous finding).
• minor: Code checked out from the mutable first-party tag ref: v1 is executed with the cross-repo PAT in its env. This is the same trust model the org already accepts for channel-pinned reusable workflows (ci-standards.md: first-party channel tags, tag-protection ruleset), so it is not a new class of risk. The difference is that this is a raw script checkout rather than a uses: ref, so it bypasses the NOSONAR/check_action_pinning conventions. Also, because v1 does not contain the script yet, behavior will change across every enrolled repo with no caller-side PR once v1 moves.
• minor: check_suite and workflow_run events are grouped on pull_requests[0].number with cancel-in-progress: true. When several same-repo PRs share a head SHA, the grouping is arbitrary, so one PR's readiness check can cancel another's. The removed #1126 comment warned about exactly this. The impact is liveness only: these runs execute in default-branch context, so no cancelled check lands on the PR head, and the next CI/review event re-triggers. It is not a security issue and should be fixed in the upstream standard.
• minor: No linked issue, the required description sections are missing (this is an auto-generated standards-sync PR), 'review / review' is CANCELLED, reviewDecision is REVIEW_REQUIRED, mergeStateStatus is BLOCKED, and the PR already carries the needs-human-review label.
• info: Checked and clean: no pull_request_target; untrusted-ish values (github.actor, issue number, vars) reach the script through env rather than inline interpolation; the -f target_repo=${{ github.repository }} interpolation is pre-existing and not attacker-controlled; actions/checkout is SHA-pinned (v7.0.1) with persist-credentials: false; the permissions: blocks are unchanged (contents: read and {}). Adding the gate also reduces the dispatch-amplification exposure from issue close events, once it actually runs.
• info: The repo-specific comment about the CI workflow name was replaced with the generic TODO placeholder. It is harmless because the trigger still reads workflows: ["CI"].

---

Reviewed by the PR-review cascade (triage: haiku 4.5 [sonnet 5] → deep: opus 5.5 [opus 4.8, sonnet 5] + duck: o4-mini → audit: opus 5.5 [opus 4.8, opus 4.7]). Reply if you need a human review.

Additional tasks

1. Resolve all unresolved review thread comments from other reviewers
2. Ensure all CI checks pass after your changes
3. Rebase on the target branch if behind
4. Do NOT modify files unrelated to the findings above

The review cascade will automatically re-review after new commits are pushed.

[donpetry-bot]

Superseded by automated re-review at 93bcfe3e7bf63d88ac96a2e6a8f2c55c68bc1df8 — click to expand prior review.

Review — fix requested (cycle 2/3)

The automated review identified the following issues. Please address each one:

Findings to fix

Automated review — NEEDS HUMAN REVIEW

Risk: MEDIUM
Reviewed commit: 93bcfe3e7bf63d88ac96a2e6a8f2c55c68bc1df8
Cascade: triage → audit (triage: haiku 4.5 [sonnet 5] → deep: opus 5.5 [opus 4.8, sonnet 5] + duck: gemini-3.8-flash [sonnet 4.6] → audit: opus 5.5 [opus 4.8, opus 4.7])

Summary

I found no exploitable security defect: there is no pull_request_target, no expression injection (runtime values go through env), third-party actions are SHA-pinned, persist-credentials is false, and no secrets are echoed. I still cannot approve because the new 'enforcing' rate-limit gate never runs. I confirmed that scripts/agent-rate-limit-gate.sh returns 404 at the pinned petry-projects/.github ref v1 (d3d768d). The two continue-on-error steps plus '|| true' hide that failure, so dispatch always proceeds, and that suppression pattern trips the org's CI-weakening hard stop. Both files match the upstream standards/workflows templates exactly, so the gate and the pull_requests[0] concurrency problems must be fixed upstream in petry-projects/.github, not edited in this repo.

Findings

• major: The gate script is missing at the pinned ref. gh api repos/petry-projects/.github/contents/scripts/agent-rate-limit-gate.sh?ref=v1 returns 404, and v1 points to d3d768d. On every run the gate step fails with 'No such file', || true and continue-on-error hide it, steps.arl_gate.outputs.decision stays empty, and the != 'defer' guard dispatches anyway. The throttling control the header says 'ENFORCES' is not in effect. (.github/workflows/initiative-driver.yml:132)
• major: Two new continue-on-error: true steps plus || true on the gate call trip the org's deterministic CI-weakening hard stop. The fail-open choice is documented, but with no ::warning:: annotation a broken or missing gate looks like a green run. (.github/workflows/initiative-driver.yml:102)
• major: The check_suite/workflow_run concurrency group keys on pull_requests[0].number with cancel-in-progress: true. This brings back the cross-PR cancellation that issue #1126 removed: when PRs share a commit, one PR's event can cancel another PR's readiness check. The new comment says these events always have head_branch=main, but PR CI workflow_run events carry the PR branch. This is an availability problem, not a security one. (.github/workflows/pr-auto-review.yml:61)
• minor: markets is a public repo. ARL_TRACKING_ISSUE takes github.event.issue.number for any issues: closed event, and anyone can open and close their own issue. Once the gate is live, a breaker trip on such a run would make the PAT-authenticated bot post the breaker marker and apply needs-human-review to an arbitrary outsider's issue instead of the operations or epic issue. The impact is low (noise and misdirected escalation), but the tracking issue should come only from the repo variable. (.github/workflows/initiative-driver.yml:129)
• minor: The step checks out the mutable first-party tag v1 and runs a bash script from it with the GH_PAT_DON_PETRY personal token. Org standards (ci-standards.md, the AGENTS.md mutable-ref exception) explicitly allow first-party @v1 refs, so this is not a policy violation. Note, though, that moving v1 to pick up the gate script will start running new PAT-scoped code across every enrolled repo with no caller-side review. The gate script should get security review in petry-projects/.github before v1 moves. (.github/workflows/initiative-driver.yml:106)
• minor: Both changed files match petry-projects/.github standards/workflows/{initiative-driver,pr-auto-review}.yml exactly. Remediation (pin a ref that contains the gate script or publish it to v1, add a ::warning:: when the gate is absent, restore unique-per-run groups for multi-PR events) has to land upstream and be re-synced. Editing these stubs locally would cause standards drift.
• minor: The review / review check concluded CANCELLED on head 93bcfe3. The merge state is BLOCKED/REVIEW_REQUIRED and needs-human-review is applied.
• info: Verified clean: no pull_request_target; ARL_ACTOR, ARL_TRACKING_REPO and ARL_TRACKING_ISSUE are passed via env and quoted in the shell; the new ${{ }} values are not interpolated into run scripts; actions/checkout is SHA-pinned (v7.0.1) with persist-credentials: false; the permissions block is unchanged (contents: read for the stub, {} for pr-auto-review); no secrets are logged.

---

Reviewed by the PR-review cascade (triage: haiku 4.5 [sonnet 5] → deep: opus 5.5 [opus 4.8, sonnet 5] + duck: gemini-3.8-flash [sonnet 4.6] → audit: opus 5.5 [opus 4.8, opus 4.7]). Reply if you need a human review.

Additional tasks

1. Resolve all unresolved review thread comments from other reviewers
2. Ensure all CI checks pass after your changes
3. Rebase on the target branch if behind
4. Do NOT modify files unrelated to the findings above

The review cascade will automatically re-review after new commits are pushed.

[donpetry-bot]

Review — fix requested (cycle 3/3)

The automated review identified the following issues. Please address each one:

Findings to fix

Automated review — NEEDS HUMAN REVIEW

Risk: MEDIUM
Reviewed commit: 93bcfe3e7bf63d88ac96a2e6a8f2c55c68bc1df8
Cascade: triage → audit (triage: haiku 4.5 [sonnet 5.5, sonnet 5] → deep: opus 5.5 [opus 4.8, sonnet 5.5] + duck: gemini-3.8-flash [sonnet 5.5] → audit: opus 5.5 [opus 4.8, opus 4.7])

Summary

Both stubs match petry-projects/.github standards/workflows/ byte-for-byte. Triggers are issues/schedule/workflow_dispatch only (no pull_request_target), and the change adds no expression injection or new token permissions. The continue-on-error hard-stop is a false positive on the merits because it guards a fail-open admission gate, not a test or scanner. However, the new rate-limit gate cannot work: the pinned ref v1 of petry-projects/.github (commit d3d768d, 2026-05-13) does not contain scripts/agent-rate-limit-gate.sh, and the tag ruleset blocks moving the tag, so the 'enforcing' canary silently always dispatches. A human should fix the ref upstream before this rolls out fleet-wide.

Findings

• major: The gate is dead on arrival. ref: v1 resolves to petry-projects/.github@d3d768dabb7f (2026-05-13, 'fix(dev-lead): restore @dev-lead/stable pin (revert broken #265 ref) #266 rename mention trigger'), and scripts/agent-rate-limit-gate.sh does not exist at that ref (contents API returns 404 at ref=v1; the file exists only on the default branch). The checkout succeeds and bash .arl-gate-tooling/scripts/agent-rate-limit-gate.sh then exits non-zero. || true and continue-on-error swallow that, no decision output is written, and the dispatch step always runs. Contrary to the header comment and AC chore: add AGPL-3.0 + commercial dual licensing and CLA #5, initiative-driver never enforces. The org's release-channel-tags ruleset (refs/tags/**, rules: update + deletion) prevents advancing v1, so the upstream standard needs a new ref (e.g. a dedicated channel tag that includes the script), not a tag move. The failure is silent: it does not fail the job and gives no ::warning:: when the script is missing. (.github/workflows/initiative-driver.yml:106)
• minor: Adjudication of the CI_WEAKENING_DETECTED hard-stop: continue-on-error: true at lines 102 and 118 is applied only to the tooling checkout and the admission-gate step. These are an intentionally fail-open rate limiter (ADR §7 fail-safe direction). No test, lint or security check is suppressed, so this is a false positive on the merits. The gate step's continue-on-error is redundant with || true. Combined with the dead-ref issue above, though, fail-open means the gate's outage is invisible: there is no warning annotation when the decision output is empty. (.github/workflows/initiative-driver.yml:102)
• minor: A script checked out from petry-projects/.github@v1 runs with the cross-repo write PAT (GH_PAT_DON_PETRY / GH_PAT_WORKFLOWS) in env. Mitigations: the source is first-party; tag update and deletion are blocked by the active release-channel-tags ruleset on refs/tags/**; persist-credentials is false; and the checkout action is SHA-pinned. Residual risk: the ruleset's bypass actors are not visible to this token, and executing a checked-out script with a PAT is a broader trust surface than a secrets: forward to a reusable workflow. The pattern is consistent with the org's existing first-party channel-ref convention, so it is acceptable, but a human should note it. (.github/workflows/initiative-driver.yml:121)
• minor: Concurrency change: check_suite and workflow_run now collapse onto pr-auto-review-ready-check-pr-<pull_requests[0].number> with cancel-in-progress. When several PRs share a head SHA, the PR[0] choice is indeterminate, and a run for one PR can supersede another's readiness evaluation. This reintroduces the race the prior repo stub documented. Impact is low: these runs are in default-branch context, so no cancelled check lands on the PR head, and the next event re-evaluates. The expression is well-formed, and a null pull_requests[0] falls through to the unique group. This matches upstream verbatim, so any fix belongs in petry-projects/.github. (.github/workflows/pr-auto-review.yml:62)
• info: No injection surface: github.actor and the issue number go through env vars and are quoted in the shell. ${{ github.repository }} is interpolated directly into run: in the existing dispatch step, but it is not attacker-controlled. Workflow permissions: contents: read is unchanged, and there is no pull_request_target and no checkout of PR head code. (.github/workflows/initiative-driver.yml:129)
• info: The header claims the gate serializes bursts 'AHEAD of the cancel-in-progress concurrency group'. But the gate runs inside a job that has already been admitted to the workflow-level group with cancel-in-progress: true, so it cannot prevent cancellation. The comment overstates the guarantee. (.github/workflows/initiative-driver.yml:37)
• minor: The PR body lacks risk, test-plan, rollback and monitoring sections, and no issue is linked (upstream #640 is referenced only in file comments). As an automated standards sync this is normally tolerated, but given the functional defect above a human needs to sign off.

---

Reviewed by the PR-review cascade (triage: haiku 4.5 [sonnet 5.5, sonnet 5] → deep: opus 5.5 [opus 4.8, sonnet 5.5] + duck: gemini-3.8-flash [sonnet 5.5] → audit: opus 5.5 [opus 4.8, opus 4.7]). Reply if you need a human review.

Additional tasks

1. Resolve all unresolved review thread comments from other reviewers
2. Ensure all CI checks pass after your changes
3. Rebase on the target branch if behind
4. Do NOT modify files unrelated to the findings above

The review cascade will automatically re-review after new commits are pushed.