@gurupanguji

Summary

Keep the social publisher’s posting behavior unchanged and fix only the metadata PR merge tail.

Problem

The Publish Social Snippets workflow can successfully:

• post the day’s unpublished snippets
• mark those snippets as published in the automation branch
• open or update the metadata PR

but still fail in the final step when it always runs gh pr merge --auto --squash.

That command is correct when branch protection is still blocking merge, but it fails when the PR is already in a clean, directly mergeable state. The result is a false-negative workflow run after real side effects have already happened.

Decision

Move the merge decision into a small helper script that inspects PR state and chooses one of two modes:

• direct when the PR is already clean and mergeable
• auto when the PR still needs branch protection requirements to complete

The workflow will:

1. create or update the metadata PR
2. ask the helper which merge mode to use
3. run gh pr merge --squash for direct
4. run gh pr merge --auto --squash for auto

Expected Outcome

• successful posting still records metadata in the automation branch
• metadata PRs merge immediately when possible
• metadata PRs still use auto-merge when branch protection requires waiting
• the workflow stops failing on already-clean PRs

Risks

• GitHub CLI field behavior could drift if the helper relies on the wrong PR JSON fields
• an unexpected PR state could choose the wrong mode if the helper is too permissive

Mitigation

Keep the helper narrow, cover the clean-vs-blocked cases with unit tests, and fail closed on unknown states so the workflow does not silently do the wrong thing.