fix: merge latest dev updates into main

[node9ai]

Auto-generated PR

Merge latest dev changes into main to trigger a release.

⚠️ Important: When you click Squash and Merge, ensure the commit message starts with:

• fix: to publish a Patch release (0.0.X)
• feat: to publish a Minor release (0.X.0)
  If it starts with chore:, no PyPI package will be published!

[node9ai]

🤖 Claude Code Review

Code Review: Node9 Python SDK PR

Changes Reviewed

This PR contains a single change to .github/workflows/auto-pr.yml — an early-exit guard that skips PR creation when there are no commits between dev and main.

---

Assessment: ✅ Looks Good

The change is minimal, correct, and addresses a real problem (spurious PRs being created when dev is already in sync with main).

---

Minor Observations

Logic is sound. git log origin/main..origin/dev --oneline | wc -l correctly counts commits reachable from dev but not from main. The git fetch origin main beforehand ensures the comparison uses up-to-date remote refs, not stale local tracking branches.

Exit code is appropriate. Using exit 0 rather than exit 1 correctly marks the job as successful — failing the job here would be misleading since "nothing to do" is not an error condition.

One edge case worth considering: wc -l output can have leading whitespace on some systems (e.g., macOS). The -eq integer comparison in bash handles this fine, so it's not a bug, but worth knowing it's implicitly relying on that behavior.

Consider also fetching dev if this job runs on a trigger that doesn't guarantee origin/dev is current:

git fetch origin main dev

Currently only main is explicitly fetched. If origin/dev is stale in the runner's context, the commit count could be incorrect. Depending on what triggers this workflow (e.g., workflow_dispatch, schedule), this could silently skip a valid release. Check your trigger — if this runs on push to dev, the ref will be current; if it runs on a schedule or manual trigger, it may not be.

---

Nothing Security-Sensitive Here

This is a CI workflow change with no impact on the @protect decorator, daemon HTTP communication, or any SDK API surface. No security concerns.

---

Summary

The guard is a reasonable, low-risk quality-of-life improvement for the release workflow. The one actionable item: verify whether origin/dev needs an explicit fetch given your workflow trigger conditions. If the workflow only fires on push to dev, you're fine. If it can fire independently of that, add dev to the fetch command.

---

Automated review by Claude Sonnet