stable-release-watch

name	stable-release-watch
description	Assess a newer OpenClaw STABLE release and recommend land-or-hold to Robert. Distinct from upstream-check (which watches OUR PR activity); this watches OpenClaw's stable release tags.
version	1.0.0
author	repo-man
tags	["github","openclaw","updates","releases","monitoring"]

stable-release-watch

Purpose

You (Repo-Man) own watching for newer stable releases of OpenClaw and telling Robert whether to land one. A zero-cost cron (openclaw-stable-watch.sh) does the detection and alerts on a new stable; your job is to assess and recommend — you do NOT run the update yourself (it is a host operation and is confirm-gated).

Context you need: OpenClaw is the fastest-growing repo in GitHub history, ~535 commits/day, mostly AI-authored by design (creator: Peter Steinberger / steipete). We track STABLE releases, not bleeding-edge main. Read once: cat /root/.openclaw/update/UNDERSTANDING-OPENCLAW-UPDATES.md.

When to use

• The openclaw-stable-watch cron alerted that a newer stable is out.
• Robert asks "should we update?" / "any new OpenClaw release?"
• kv key openclaw_update_status shows newer_available=true.

Steps

1. Read current status (no new call needed — the cron wrote it)

kv: openclaw_update_status   (running vs newest_stable vs newer_available)
file: /root/.openclaw/openclaw-stable-watch-state.json

2. Re-verify if you want a fresh comparison

Request a host check (you can't run host Docker). Queue a task with meta = {"host_op":"openclaw-update","op":"check"}; the executor runs update.sh --dry-run host-side and returns the running-vs-stable delta + the no-downgrade decision. (op=check is always safe.)

3. Review what changed — with the AI-blindspot lens

The new stable's commits are mostly AI-authored, so review them like AI code, not human code. Pull the release notes / changelog for the new tag (you have GitHub access) and look hard for the risky classes: config/migration changes, security (auth, injection, secrets — OpenClaw has full system access), removed fallbacks, breaking API/flag changes. Chart-search the lessons first: ref-openclaw-update-understanding, reading-ai-code-blindspots, reading-update-build-oom, ref-update-test-suite.

4. Recommend to Robert (via Captain) — land or hold

Report: current version, the new stable version, the notable changes, your risk read, and a clear land / hold recommendation. Remember the update is fully gated (hash-gated before/after test, auto-rollback) so "land" is low-risk if it passes — but a holiday/low-attention window is a reason to hold.

5. If Robert says land

The update runs host-side via the gated openclaw-update handler with meta.confirm=true (Robert or Reactor confirms — you do not run it). It stops the gateway, builds, recreates, runs the post-test, and auto-rolls-back on regression.

Hard rules

• Detect/assess/recommend only — never run the update (needs confirm + host Docker).
• Never recommend a downgrade. If running version >= newest stable, there is nothing to do.
• Report to Captain, never directly to Robert.