release: v0.8.3-beta.1

[openab-app]

Merge this PR to tag v0.8.3-beta.1 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.1
• Source: release: v0.8.3-beta.1 #702
• Status: moved to PR-Screening
• Generated at: 2026-05-02T11:05:10.695Z
• Discord thread: https://discord.com/channels/1488041051187974246/1500090656662491226

Screening report

## Intent

PR #702 is a release operation for v0.8.3-beta.1. It updates release metadata in Cargo.toml and charts/openab/Chart.yaml, then expects merge to main to create/tag the beta release and trigger the build pipeline.

The operator-visible problem is getting a consistent beta artifact and Helm chart published through the normal release path.

Feat

This is a release operation, not a feature or fix. Behaviorally, it advances OpenAB’s packaged version to v0.8.3-beta.1 and initiates release automation after merge.

Who It Serves

Primary beneficiaries are maintainers, deployers, and release operators who need a tagged beta build and matching chart metadata.

Rewritten Prompt

Review release PR #702 for v0.8.3-beta.1. Confirm that Cargo.toml and charts/openab/Chart.yaml consistently declare the intended beta version, that the branch targets main, and that CI/release checks are green. If valid, merge the PR to trigger tagging and the build pipeline. Do not introduce functional code changes in this PR; any release-process improvements should be split into follow-up work.

Merge Pitch

This PR is worth advancing because it is the expected release vehicle for producing v0.8.3-beta.1 artifacts. The change surface is small and should be low risk if version metadata and CI are correct.

Likely reviewer concern: release PRs have operational blast radius despite tiny diffs. A mistaken version, chart mismatch, or failed post-merge pipeline can create confusing or unusable release artifacts.

Best-Practice Comparison

OpenClaw’s scheduling and execution model is mostly not directly relevant because this PR is a release trigger, not a scheduled runtime job. Relevant principles are durable run logs, explicit delivery routing, retry/backoff, and isolated executions as they apply to release pipeline observability and artifact publishing.

Hermes Agent’s daemon tick model and scheduled prompt design are also mostly out of scope. Relevant principles are atomic persisted state and file locking by analogy: release state should be updated consistently, and concurrent release attempts for the same version should be prevented. A fresh isolated session per run maps well to clean release builds.

Implementation Options

1. Conservative: merge the generated release PR after checking version consistency and CI status.
   This preserves the current release process and keeps the scope limited to shipping v0.8.3-beta.1.

2. Balanced: merge the release PR, then add a follow-up release validation task.
   The follow-up would verify Cargo.toml, Helm chart version/appVersion, tag name, branch name, and release pipeline trigger conditions before future release PRs are mergeable.

3. Ambitious: build a more complete release orchestrator.
   Add durable release records, explicit artifact routing, idempotent tag creation, pipeline retry/backoff, run logs, and guards against overlapping releases.

Comparison Table

Option	Speed to ship	Complexity	Reliability	Maintainability	User impact	Fit for OpenAB right now
Conservative merge	High	Low	Medium	Medium	High for release consumers	Strong
Merge plus validation follow-up	Medium	Medium	High	High	High, with fewer future release mistakes	Strongest
Release orchestrator	Low	High	Very high	Medium to high	High long-term	Premature unless release failures are frequent

Recommendation

Use the balanced path: treat PR #702 as a narrow release PR and move it forward if CI and version consistency are clean, then split release-process hardening into a follow-up item.

That keeps v0.8.3-beta.1 unblocked while giving Masami or Pahud a concrete next step: add automated validation around release metadata, tag naming, and pipeline triggering before investing in a larger release orchestration system.