ci: propose patch release pull requests

[mldangelo-oai]

Summary

Automate the repeated work of opening patch-release PRs while keeping human review, CI, and protected npm publication in the existing release process. The repository already has tagging, provenance checks, and generated release notes; this adds the missing PR-creation step without introducing another release system or runtime dependency.

Changes

• Add node-release-pr, triggered after successful main-branch node-ci, after a successful node-github-release, or by manual dispatch. It checks that the current main commit passed CI and that its current version has finished publishing before proposing another release.
• Compare package and build inputs against the current npm-vX.Y.Z release tag. When releasable changes exist, increment only the patch version and open a full PR that changes only sdk/typescript/package.json.
• Preserve existing release PRs, including manual minor and major releases. Never force-push, rewrite a PR description, or reopen a closed bot PR. Recheck moving main and competing PRs, and recover an interrupted branch or PR creation only when the branch still contains the expected version-only change.
• Render the repository's full PR template with static, public-safe text; leave disclosure attestations for the maintainer; add skip-release-notes; and request Codex review once for each exact managed head.
• Add a write-free dry run, optional repository-scoped GitHub App authentication, maintainer instructions, and deterministic reconciliation tests. Reuse the existing stable-version helpers and leave tagging, npm publishing, provenance, and GitHub-release generation unchanged.

Testing

• Randomized focused release suite: 286 tests passed.
• Full SDK suite: 1,388 passed, 11 skipped, and 0 failed. The initial run hit the outer macOS sandbox's nested-sandbox restriction; the approved rerun outside that outer sandbox passed.
• Full randomized SDK suite (bun test --randomize --seed 12345 --timeout 30000 ./tests-ts): 1,388 passed, 11 skipped, and 0 failed.
• pnpm run types, pnpm run format, and git diff --check passed.
• GitHub's official workflow parser accepted the complete YAML, and its expression evaluator passed all 25 trusted/untrusted trigger fixtures.
• An isolated black-box CLI/HTTP smoke passed 11 scenarios, including a real local Git commit with a one-line manifest diff, full PR creation, exact-head review requests, read-only dry runs, idempotent reruns, and denied API responses. It used synthetic GitHub responses and credentials, with network access blocked.
• actionlint 1.7.12 passed with only its outdated queue syntax warning filtered. GitHub documents queue: max, and the existing release workflows already use it.
• A live, read-only dry run preserved the existing release PR without creating a branch, PR, label, or comment.
• Independent PR review and deslop review found no actionable issues. The code simplification pass removed a redundant PR scan, duplicate version checks, and a redundant credential check.

Risk and rollout

• The workflow becomes eligible to run after merge. It creates release proposals only; it does not merge, tag, publish, or dispatch a release workflow. The protected npm approval and existing release verification remain separate gates.
• The default GITHUB_TOKEN requires a maintainer to approve generated PR workflows. An optional GitHub App enables unattended PR CI; setup and least-privilege permissions are documented in CONTRIBUTING.md. This PR does not configure App credentials or change repository protection settings.
• Maintainers must review each generated public PR, complete its disclosure checklist, and satisfy the normal approval and CI requirements before merging. The first naturally eligible bot PR remains the live rollout check for token permissions and downstream CI.

Public disclosure review

• No customer, partner, prospect, or user identities, data, or identifying details are included.
• No credentials, personal data, private source, scan findings, or nonpublic links or tickets are included.
• I reviewed the branch name, title, description, commits, changes, comments, logs, screenshots, attachments, and links for public disclosure.

[mldangelo-oai]

@codex review

Please review commit 839827c8ac63a26bd0016d378f90c2eacc376f12.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 839827c8ac

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Use a token that can trigger PR checks

When RELEASE_APP_CLIENT_ID is unset—the documented default—the pull request is created using the repository’s GITHUB_TOKEN. GitHub suppresses new workflow runs for events generated by that token, so opening the PR will not start the pull_request-triggered node-ci workflow (or node-release-labels), and there is no queued run for a maintainer to approve as described in CONTRIBUTING.md. The generated release PR therefore cannot satisfy its required CI in the default configuration without an additional manual event; use an App/PAT token or explicitly trigger the checks after creation.

Useful? React with 👍 / 👎.

[chatgpt-codex-connector]

Security review completed. No security issues were found in this pull request.

Reviewed commit: 839827c8ac

View security finding report

Only the user who started this review can view the report in Codex.

ℹ️ About Codex security reviews in GitHub

This is an experimental Codex feature. Security reviews are triggered when:

• You comment "@codex security review"
• A regular code review gets triggered (for example, "@codex review" or when a PR is opened), and you’re opted in so security review runs alongside code review

Once complete, Codex will leave suggestions, or a comment if no findings are found.

[zcrab-oai]

The proposed release automation needs a stronger justification and a much smaller design.

[zcrab-oai]

[P2] Drop or substantially shrink the patch-release orchestrator

What recurring operational problem justifies a new 572-line reconciler, roughly 1,400 lines of mocked tests, and an additional write-capable workflow to generate a one-line package-version change? The existing reviewed release path already handles tagging and publication, and the proposed default token cannot start the required PR checks. I would drop this automation unless release volume demonstrates a real need; if it is needed, start with a small App-authenticated version-bump workflow and add reconciliation only for observed failures.