release: gateway-v0.4.0

[openab-app]

Merge this PR to tag gateway-v0.4.0 and trigger the gateway 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: gateway-v0.4.0
• Source: release: gateway-v0.4.0 #750
• Status: moved to PR-Screening
• Generated at: 2026-05-05T22:31:20.861Z
• Discord thread: https://discord.com/channels/1488041051187974246/1501350445053116637

Screening report

## Intent

This PR is a release operation for gateway-v0.4.0. It appears to update gateway/Cargo.toml by one line, likely bumping the gateway crate/version so merging to main can create or enable the gateway-v0.4.0 tag and trigger the gateway build pipeline.

The operator-visible problem being solved is release coordination: getting the gateway package into the expected versioned state so automation can build and publish the release artifact.

Feat

Type: release operation.

Behavioral change: merge a version bump for the gateway component and allow the release automation to tag/build gateway-v0.4.0.

This is not a feature or runtime behavior change by itself unless the version bump also carries unreleased gateway code already present on main.

Who It Serves

Primary beneficiaries: maintainers and deployers.

Secondary beneficiaries: agent runtime operators who depend on versioned gateway artifacts for deployment, rollback, and environment pinning.

Rewritten Prompt

Review PR openabdev/openab#750 as a gateway release PR for gateway-v0.4.0.

Confirm that gateway/Cargo.toml updates only the intended gateway version, that the target version matches the release branch and PR title, and that no unrelated changes are included. Verify the expected release pipeline behavior: merging this PR should create or enable tag gateway-v0.4.0 and trigger the gateway build workflow. If repository release conventions require changelog, lockfile, workspace version, or tag checks, identify any missing release metadata before merge.

Return a merge recommendation with any required pre-merge checks.

Merge Pitch

This is worth advancing because release PRs are low-code-change, high-operational-value items: they make a known gateway version buildable and traceable. The change surface is very small, limited to gateway/Cargo.toml.

Risk profile is low if the version bump is correct and the release automation is already established. The main reviewer concern should be process correctness: whether the tag, version string, release branch, changelog expectations, and build pipeline trigger all align.

Best-Practice Comparison

Relevant OpenClaw principles:

• Durable job persistence: relevant indirectly. The gateway release should produce durable, traceable artifacts and tags.
• Explicit delivery routing: relevant if the release pipeline publishes to specific registries, environments, or artifact channels.
• Retry/backoff and run logs: relevant to the release workflow, especially build failures or publish retries.
• Gateway-owned scheduling and isolated executions: not directly relevant to this PR unless gateway-v0.4.0 contains scheduler/runtime changes outside this release bump.

Relevant Hermes Agent principles:

• Atomic writes for persisted state: relevant by analogy to release state. Version/tag changes should be atomic and easy to audit.
• Fresh session per scheduled run and self-contained prompts: not directly relevant to this release PR.
• Gateway daemon tick model and file locking to prevent overlap: not directly relevant unless this version release includes those runtime changes already merged elsewhere.

The best-practice lens here is mostly release hygiene: small scoped change, deterministic automation, clear logs, and unambiguous artifact routing.

Implementation Options

Conservative option: merge the release PR after verifying the version bump and CI status.

This keeps the release path simple. A reviewer checks that gateway/Cargo.toml says 0.4.0, the branch/title/tag naming match, and CI passes.

Balanced option: add a lightweight release checklist before merge.

Require confirmation of version, tag name, changelog or release notes expectation, pipeline trigger, artifact destination, and rollback path. This can be a PR comment or reusable release template.

Ambitious option: formalize gateway release automation.

Add or improve a release workflow that validates version consistency, generates or verifies the tag, builds the gateway artifact, records release logs, and publishes to the intended destination with explicit routing and retry behavior.

Comparison Table

Option	Speed to ship	Complexity	Reliability	Maintainability	User impact	Fit for OpenAB right now
Conservative merge after checks	High	Low	Medium	Medium	Medium	Strong if release automation already works
Lightweight release checklist	Medium	Low-Medium	Medium-High	High	Medium	Strong; improves review confidence without blocking release work
Formalized release automation	Low	High	High	High	High	Good future direction, likely too large for this PR

Recommendation

Use the balanced option for this PR: keep #750 as a narrow release operation, but require a concise release checklist before merge.

That gives Masami or Pahud a clear review path without expanding the PR beyond its purpose. If any release automation gaps are found, split them into follow-up issues rather than blocking gateway-v0.4.0 unless the current pipeline cannot reliably tag, build, or publish the gateway artifact.

[chaodu-agent]

Found one release-blocking consistency issue: gateway/Cargo.lock is tracked and still records openab-gateway as version 0.1.0, while this PR bumps gateway/Cargo.toml to 0.4.0. Please regenerate/update gateway/Cargo.lock so the package metadata matches the release version; otherwise --locked Cargo builds/checks will require a lockfile update and fail.

[chaodu-agent]

CHANGES REQUESTED 🔴 — gateway/Cargo.lock not updated alongside Cargo.toml version bump.

Review Details (超渡法師 — updated per 擺渡法師 finding)

Issue

🔴 SUGGESTED CHANGES — gateway/Cargo.lock still records version = "0.1.0" for openab-gateway, while gateway/Cargo.toml bumps to 0.4.0. This causes:

1. Release metadata inconsistency between manifest and lockfile
2. cargo build --locked / cargo check --locked will fail (lockfile out of date)

Fix

Run cargo update -p openab-gateway (or simply cargo check) inside gateway/ to regenerate the lockfile entry, then commit the updated Cargo.lock.

Original Assessment

The version bump itself (0.1.0 → 0.4.0) is well-justified given the feature surface added. Only the lockfile sync is missing.