[RSI Baseline] Close the GitHub Issue-to-Release automation loop #789

Parent Epic: #784

Why

The baseline must demonstrate a real, end-to-end software delivery loop rather than stop after generating a PR.

Scope

• Connect GitHub Issues, branches/PRs, review verdicts, required checks, merge queue, tags and Releases.
• Bind verification/review evidence to the current head SHA; invalidate a verdict when the PR head changes.
• Reuse GitHub Actions, branch protection and merge queue; never bypass repository rules.
• Enforce risk-tier-specific merge/release policy and explicit human approval for configured sensitive actions.
• Generate/validate changelog fragments and release notes; verify published artifacts and report release status.
• Handle failed CI, review changes, merge conflicts, missing workflow runs and partial release failures.
• Keep actions idempotent and reconcile against GitHub live state before retrying.

Acceptance criteria

• A low-risk pilot progresses from Issue through PR, current-SHA verification, required CI, merge queue and a test release.
• Release artifacts and tag/commit association are verified.
• Failures have actionable reasons; retries do not create duplicate PRs/releases.
• No admin merge, gate bypass or implicit production deployment.

Related

• Release cadence: at least one tag per day, small and stable #351 release pipeline
• [RFC] 跨运行时 Agent 对话与协作：以 OpenCode 为首个试点的目标、需求与两种方案 #198 cross-runtime collaboration
• [Team] Persist a minimal collaboration task lifecycle #54 task lifecycle

Bot identity and review separation

The pilot must use a dedicated, least-privilege GitHub automation identity rather than a maintainer's personal token for routine writes.

• Create/update the PR and post automation status using the configured GitHub App or dedicated bot identity.
• Keep the Developer and Reviewer execution contexts separate. A Developer must not be able to manufacture or edit a valid Reviewer verdict merely by writing PR text.
• Bind the review verdict to the exact head SHA and verify it against GitHub's current PR state before enqueueing.
• Continue to rely on required CI checks, repository rules and the merge queue; never bypass them. Verify whether the chosen App identity and repository rules can perform each required operation before enabling live automation.
• Record the actor, operation, target SHA and outcome for each automated write. Keep maintainer-only operations (App installation, permission changes, policy changes and explicitly sensitive releases) behind human authorization.

Acceptance criteria additions

• A low-risk pilot can create and update its PR without a maintainer's personal GitHub credential.
• Reviewer evidence is produced by a separately controlled execution path and cannot be forged by the Developer role.
• App permissions and any operation that still requires a human are documented; no unsupported GitHub permission is assumed.