Nightly Release

Use for Tideclaw/OpenClaw alpha/nightly release automation, manual alpha triggers, beta prep, release-branch repair, and post-release forward-port. Load $release-private if it exists before using Tideclaw host paths, cron ids, or Discord routing ids.

Policy

• Alpha/nightly runs every 12h or by manual trigger.
• Beta is human-triggered from Discord from a proven alpha/release branch.
• Stable/latest always needs explicit human confirmation.
• Never publish from a dirty checkout or directly from main.
• Main can be busy or broken; alpha work must be isolated so transient main failures do not block a usable nightly.
• Publish only after release-branch proof is green.
• After a successful alpha, forward-port release-branch commits back to main and prove main CI green.
• Forward-port PRs contain only reusable fixes needed to make nightly/release checks pass. They must not contain alpha version bumps, release notes, changelog release entries, tags, generated artifacts, or state-file updates.
• Keep only alpha/nightly branches from the last 3 days, plus any branch with an active run, open PR, or release tag.
• Never run broad env/token dumps. For GitHub writes on the Tideclaw host, use the Tideclaw gh write wrapper below.

Identity

Tideclaw should commit under its own machine identity on release branches and forward-port branches:

git config user.name "Tideclaw"
git config user.email "[email protected]"

This is good for auditability if commits are clearly machine-authored and gated by CI. Avoid direct pushes to protected main; forward-port via PR/automerge unless the repo policy explicitly allows the bot to push after green checks. Include human Co-authored-by only when a human supplied the patch or explicit commit text.

Branch Shape

• Branch prefix: tideclaw/alpha/
• Branch name: tideclaw/alpha/YYYY-MM-DD-HHMMZ
• Base: current origin/main SHA at trigger time.
• State file: resolve from $release-private on the Tideclaw host.
• Release tag: vYYYY.M.D-alpha.N
• npm dist-tag: alpha

Do not reuse old alpha branches for a new run. If rerunning the same base SHA, create a new timestamped branch and record why.

Start

1. Work in the Tideclaw host checkout from $release-private.
2. Fetch first:

git fetch origin main --tags --prune
git switch main
git merge --ff-only origin/main
BASE_SHA="$(git rev-parse origin/main)"
BRANCH="tideclaw/alpha/$(date -u +%Y-%m-%d-%H%MZ)"
git switch -c "$BRANCH" "$BASE_SHA"

1. Read repo release docs/scripts before changing anything:
   • AGENTS.md
   • release docs under docs/
   • release scripts under scripts/
   • .github/workflows/*release*
2. Compare $BASE_SHA with the last successful alpha state and current git/npm/GitHub alpha tags. If already released, report skip and do not publish.

Manual trigger:

CRON_ID="<from release-private>"
OPENCLAW_ALLOW_ROOT=1 openclaw cron run "$CRON_ID" --expect-final --timeout 21600000

Discord Alpha Trigger

Tideclaw may run alpha immediately from Discord when a maintainer mentions Tideclaw in #releases or #maintainers.

Accepted shapes:

@Tideclaw run alpha now
@Tideclaw alpha release from main now
@Tideclaw trigger alpha

Rules:

1. Treat this as a manual alpha trigger equivalent to the alpha cron job.
2. Start from current origin/main and create a fresh tideclaw/alpha/YYYY-MM-DD-HHMMZ branch.
3. Follow the normal alpha workflow: reuse prior fixes, run local checks, fix on the alpha branch, run release CI, publish alpha after green gates, then forward-port reusable fixes via fixes-only PR.
4. If another alpha/beta/stable release run is already active, report the active branch/run and stop.
5. #maintainers trigger requires an explicit Tideclaw mention; do not react to unmentioned release chatter there.
6. Resolve Discord role/user ids and live host hotfix notes from $release-private.

Discord Beta Trigger

…