Updating develop.

[CTLalit]

Merge commits and CICD

[coderabbitai]

Warning

Review limit reached

@CTLalit, we couldn't start this review because you've reached your PR review rate limit.

More reviews will be available in 16 minutes and 9 seconds. Learn how PR review limits work.

Your organization has run out of usage credits. Purchase more in the billing tab.

⌛ How to resolve this issue?

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.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available.

Please see our Fair Usage Limits Policy for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: 1d9177f2-ccea-4a9a-a1df-3fc0f67ed93c

📥 Commits

Reviewing files that changed from the base of the PR and between 989f636 and 0e6bd20.

📒 Files selected for processing (1)

• .github/workflows/vision-ai-review.yml

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch master

---

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 and usage tips.}

[francispereira]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues
✅	Code Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[clevertap-vision]

Code Review

Summary

This PR ("Updating develop.") syncs master into develop; the only net change is the addition of .github/workflows/vision-ai-review.yml, the Vision AI Review GitHub Actions workflow (already introduced on master via #1014/#1015). The workflow auto-triggers reviews on PR open/ready/synchronize and on a /vision-review-deep comment, calling an external review-notifier endpoint with Cloudflare Access credentials.

Security hygiene is solid: top-level permissions: {} (least privilege), explicit fork gating on both the pull_request and issue_comment paths, author-association gating on the comment trigger, and untrusted values passed through env: rather than interpolated into shell (avoiding the classic GHA script-injection pitfall).

📊 Visual Overview

flowchart TD
    A[pull_request: opened / ready_for_review / synchronize] --> B{same-repo AND not draft?}
    B -- no --> X[skip]
    B -- yes --> T[POST review-notifier]
    C[issue_comment: created] --> D{body == /vision-review-deep AND OWNER/MEMBER/COLLABORATOR?}
    D -- no --> X
    D -- yes --> E[fetch PR head repo via API]
    E --> F{head.repo == this repo?}
    F -- yes --> T
    F -- no --> Y[Skipped fork PR]

Loading

Verdict

APPROVE

The workflow is well-constructed and security-conscious, with no blocking issues. The two inline notes are non-blocking suggestions: adding a concurrency group (consistent with the repo's other workflows) to avoid redundant concurrent triggers on rapid pushes, and keeping the env-var discipline consistent in the final echo step. Since this PR merely forward-ports an already-reviewed workflow file onto develop, it is safe to merge.

---

To retrigger this review, comment /vision-review-deep on the PR.

Reviewed by Vision AI

[clevertap-vision]

💡 Suggestion: Consider adding a concurrency group so rapid pushes don't fan out into multiple in-flight reviews for the same PR. synchronize fires on every push, and the file's own comments note a desire to avoid paying twice — a concurrency group is the standard way to enforce that. This is also consistent with the repo's other workflows (on_pr_from_task_to_develop.yml, on_pr_from_develop_to_master.yml, on_pr_merged_in_master.yml all use concurrency).

Suggested change

	jobs:
	concurrency:
	group: vision-ai-review-${{ github.event.pull_request.number || github.event.issue.number }}
	cancel-in-progress: true
	jobs:

[clevertap-vision]

🧹 Code Quality: This is the one spot that interpolates ${{ ... }} directly into a run: script instead of routing through env:, which the rest of the workflow does consistently to avoid GHA script injection. The value here (steps.pr.outputs.head, derived from the GitHub API head.repo.full_name) is constrained to valid repo-name characters and is not attacker-controllable, so this is not exploitable — purely a consistency note. Optionally pass it via env: like the other steps:

        env:
          HEAD: ${{ steps.pr.outputs.head }}
          REPO: ${{ github.repository }}
        run: |
          echo "PR head '$HEAD' is not '$REPO'; skipping fork PR."