⚡ Bolt: Optimize any() evaluation with tuple in markdown generation

[madara88645]

💡 What: Replaced any() evaluation over a tuple with direct boolean or conditions.

🎯 Why: In Python, evaluating any() with a tuple like any((a, b, c)) forces the evaluation of all elements in the tuple before any() is called, thus bypassing the short-circuiting benefits. Replacing this with direct boolean or operations ensures that the evaluation is short-circuited properly, improving performance.

📊 Impact: Reduces evaluation overhead and improves evaluation speed by allowing short-circuiting during boolean checks.

🔬 Measurement: Verify short-circuiting and test correct functioning via the test-backend suite.

---

PR created automatically by Jules for task 17669795558722915426 started by @madara88645

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
compiler	Ready	Preview	Aug 3, 2026 8:34am

[google-labs-jules]

👋 Jules, reporting for duty! I'm here to lend a hand with this pull request.

When you start a review, I'll add a 👀 emoji to each comment to let you know I've read it. I'll focus on feedback directed at me and will do my best to stay out of conversations between you and other bots or reviewers to keep the noise down.

I'll push a commit with your requested changes shortly after. Please note there might be a delay between these steps, but rest assured I'm on the job!

For more direct control, you can switch me to Reactive Mode. When this mode is on, I will only act on comments where you specifically mention me with @jules. You can find this option in the Pull Request section of your global Jules UI settings. You can always switch back!

New to Jules? Learn more at jules.google/docs.

---

For security, I will only act on instructions from the user who triggered this task.

[cursor]

PR risk assessment (automation)

Risk level: Very Low

Code review required: No

Decision: Approved

Evidence (from diff only)

• Scope: One file (app/pr_safety/markdown.py), ~10 lines in report_to_markdown.
• Change: Replaces any((…)) over five repo_signals fields with an equivalent or chain inside the same if not (…) guard that adds the “No repository-specific signals detected” bullet.
• Blast radius: Offline PR Safety markdown rendering only (advisory output, not merge-blocking per file footer). No auth, billing, infra, schema, or shared API surface.
• Behavior: Truthiness of the combined condition is unchanged; evaluation may short-circuit on the first truthy field (tuple construction previously evaluated all operands).

Reviewers

• None assigned (not required at this risk level).
• No CODEOWNERS file in the repository.
• Existing review requests: none; no prior approvals on this PR.

Slack

Slack delivery is not configured for this automation run (no Slack MCP action available); summary is recorded on this review.

  

_{Sent by Cursor Automation: Assign PR reviewers}

[madara88645]

Closing as part of a duplicate cluster. #1184, #1180, #1169 and #1165 all rewrite the same short-circuit check in app/pr_safety/markdown.py — four open PRs, one change.

Per #905, a performance PR needs a benchmark demonstrating a measurable improvement on a real workload. None is attached here, and the code path does not sit in a hot loop.

Closing the whole cluster rather than keeping one: this check runs once per PR-safety markdown render, not per token or per row.

[google-labs-jules]

Closing as part of a duplicate cluster. #1184, #1180, #1169 and #1165 all rewrite the same short-circuit check in app/pr_safety/markdown.py — four open PRs, one change.

Per #905, a performance PR needs a benchmark demonstrating a measurable improvement on a real workload. None is attached here, and the code path does not sit in a hot loop.

Closing the whole cluster rather than keeping one: this check runs once per PR-safety markdown render, not per token or per row.

Understood. Acknowledging that this work is now obsolete and stopping work on this task.