release: v0.8.3-beta.5

[openab-app]

Merge this PR to tag v0.8.3-beta.5 and trigger the build pipeline.

[shaun-agent]

OpenAB PR Screening

This is auto-generated by the OpenAB project-screening flow for context collection and reviewer handoff.
Click 👍 if you find this useful. Human review will be done within 24 hours. We appreciate your support and contribution 🙏

• Title: release: v0.8.3-beta.5
• Source: release: v0.8.3-beta.5 #778
• Status: moved to PR-Screening
• Generated at: 2026-05-09T14:31:24.071Z
• Discord thread: https://discord.com/channels/1488041051187974246/1502679197980557494

Screening report

## Intent

Release PR #778 is trying to publish OpenAB v0.8.3-beta.5.

The operator-visible goal is to merge a generated release branch into main so the repository can tag v0.8.3-beta.5 and trigger the build pipeline. The only listed code change is a version update in charts/openab/Chart.yaml, so this appears to be a release operation rather than a functional change.

Feat

Release operation.

Behaviorally, this PR advances the Helm chart metadata/version for the v0.8.3-beta.5 beta release and relies on the existing merge/tag/build automation to produce release artifacts.

Who It Serves

Primary beneficiaries:

• Deployers who consume OpenAB Helm charts or release artifacts
• Maintainers managing the beta release train
• CI/release operators who need a clean release trigger

Secondary beneficiaries:

• Reviewers, because the release PR appears narrowly scoped and generated
• Downstream testers validating v0.8.3-beta.5

Rewritten Prompt

Review and merge release PR openabdev/openab#778 for v0.8.3-beta.5.

Confirm that the PR only updates release metadata in charts/openab/Chart.yaml, that the chart version/app version values are correct for v0.8.3-beta.5, and that the branch release/v0.8.3-beta.5 targets main. If valid, merge the PR to trigger the repository’s tag and build pipeline. Do not include unrelated code changes. After merge, verify that the expected tag/build workflow starts successfully.

Merge Pitch

This is a low-risk, narrow release PR generated by app/openab-app. It is worth advancing because it unblocks the v0.8.3-beta.5 build pipeline and keeps the beta release cadence moving.

Likely reviewer concern: whether the chart metadata exactly matches the intended release version and whether merging this PR will trigger the correct downstream automation. The PR should be checked for version correctness and CI/release workflow readiness, but it does not appear to require deeper feature review.

Best-Practice Comparison

OpenClaw principles relevant here:

• Explicit delivery routing is relevant: the PR should clearly target main and trigger the intended release/build workflow.
• Durable job persistence is indirectly relevant if the build pipeline records release runs and artifacts.
• Retry/backoff and run logs are relevant to the downstream pipeline, not the PR contents.
• Gateway-owned scheduling and isolated executions are not directly relevant unless OpenAB’s release automation is implemented through scheduled agent jobs.

Hermes Agent principles relevant here:

• Atomic writes for persisted state maps well to generated release metadata: Chart.yaml should be updated cleanly and reviewed as a small, deterministic diff.
• Self-contained prompts are relevant for the follow-up agent: the merge task should include version, PR number, target branch, and expected pipeline behavior.
• Fresh session per scheduled run and daemon tick model are not directly relevant to this release PR.
• File locking to prevent overlap is only relevant if multiple release PRs can be generated concurrently.

Overall, the best-practice comparison supports keeping this PR small, deterministic, explicitly routed, and easy to audit.

Implementation Options

Conservative option: manual release PR validation and merge
A maintainer or agent checks charts/openab/Chart.yaml, confirms the version bump, verifies CI status, merges the PR, and watches the build pipeline.

Balanced option: add a release PR checklist or lightweight validation workflow
Keep the generated PR model, but add automated checks that validate chart version, branch naming, tag naming, and absence of unrelated files before merge.

Ambitious option: formalize release orchestration
Move toward a durable release job model that records intended version, generated files, tag status, artifact build status, retry state, and run logs. Release PRs become one step in a tracked release workflow rather than the primary source of state.

Comparison Table

Option	Speed to ship	Complexity	Reliability	Maintainability	User impact	Fit for OpenAB right now
Manual validation and merge	High	Low	Medium	Medium	Medium	High
Release PR validation workflow	Medium	Medium	High	High	Medium	High
Durable release orchestration	Low	High	Very high	Medium	High	Medium

Recommendation

Use the conservative path for PR #778: validate that charts/openab/Chart.yaml correctly reflects v0.8.3-beta.5, confirm CI/release automation expectations, then merge to trigger the build pipeline.

For follow-up, split out a separate improvement to add automated release PR validation. That gives reviewers a practical next step without blocking this beta release on larger release-orchestration work.