← Back to workflows
Live Operations Advanced External bundle v1.2.2

OpenClaw Beta Canary Testing

Test beta builds with evidence, not vibes.

A release-gate and issue-intelligence workflow for testing OpenClaw beta builds on one non-primary agent before expanding across a fleet. It creates a Mission Control task, runs a focused canary, schedules checkbacks, files useful issues, tracks maintainer responses, and turns every accepted, rejected, or narrowed report into a better next test.

Availability
Classification
External bundle
Install mode
Manual install
Review status
Manual review
Verification mode
Concept review

This is published as a public GitHub workflow bundle. It is manually installable today; adapt the phases to your own OpenClaw fleet, Mission Control equivalent, and issue tracker.

Install source
GitHub workflow bundle
Workflow record
Bundle id
superada.workflow.openclaw-beta-canary-testing
Entrypoint
SKILL.md
Bundle root
skills/openclaw-beta-testing
Artifact count
11 described items

A disciplined beta-testing workflow that starts with Mission Control intake, runs one controlled canary, schedules checkbacks, classifies the result, submits high-quality issues when failures are found, and follows each issue until it produces a retest, an external evidence comment, or an internal lesson.

Install contract
Installability
Truly installable now
Method
Manual operator install
Review the workflow, create an MC task for the target beta and agent, run Phase 1 on one canary, then expand only after the canary decision is pass-expand.
Agent step 1
Create a task before changing any target agent.
Agent step 2
Choose one non-primary canary host.
Agent step 3
Snapshot current state before updating.
Agent step 4
Run Phase 1 and record one explicit decision.
Agent step 5
Schedule a checkback if observation is needed.
Agent step 6
If a failure is reportable, search duplicates, file the issue with evidence, and register it.
Agent step 7
Re-check submitted issues on a schedule and choose an action outcome each time.
Agent step 8
Only run Phase 2 when the canary is clean or maintainers need deeper evidence.
Current limits
  • Requires access to target agent logs and OpenClaw CLI.
  • Requires a task board or equivalent evidence trail to avoid forgotten checkbacks.
  • Exact commands and host routing should be adapted to the operator's fleet.
Step 1
Create intake task
Record version, target agent, rollback path, risk, intended mode, evidence requirements, and reviewer before touching the target.
Step 2
Snapshot the target
Capture version, status, doctor output, gateway health, active channels, cron scheduler state, plugin state, and rollback notes.
Step 3
Update one canary
Update only one non-primary target unless the test explicitly needs a broader surface.
openclaw update --channel beta
Step 4
Run P0 smoke
Verify gateway restart, CLI/gateway version match, visible channel reply, model route, forced cron run, plugin list, session list, and logs.
Step 5
Classify the result
Choose pass-expand, mixed-hold, fail-rollback, or blocked. Do not expand on a mixed or failed canary.
Step 6
Schedule checkback
If observation is needed, create a checkpoint and scheduled checkback instead of relying on memory.
Step 7
Report and track issues
File upstream issues only when evidence is strong enough, then track maintainer responses until resolved or intentionally abandoned.
Step 8
Register the issue
Store repo, issue number, URL, source canary, target version, MC task, labels, comment count, ClawSweeper verdict, and next action in the issue registry.
Step 9
Run issue intelligence
Re-check open beta issues for labels, maintainer comments, bot verdicts, linked PRs, closure reasons, duplicate markings, and evidence requests.
Step 10
Act on the issue state
Submit a follow-up comment, queue a retest, update the internal lesson, or record no-action-with-reason. Do not leave the issue as passive monitoring.

If you hand an agent this workflow URL, this install contract is the source of truth for whether it can really install the bundle now, what source to use, and what still needs a human.

What you get

  • One-agent beta canary before fleet expansion
  • Explicit pass-expand, mixed-hold, fail-rollback, or blocked decision
  • Scheduled checkback for observation windows
  • Evidence-backed upstream issue reports
  • Recursive issue intelligence with concrete next actions
  • Retests when fixes land or evidence requests arrive
  • Reporting lessons promoted back into the workflow
  • Peer-reviewed MC closure

Workflow includes

  • Phase 0 intake
  • Phase 1 canary run
  • Phase 2 deep beta run
  • Phase 3 issue submission
  • Phase 4 issue intelligence
  • Phase 5 scheduled issue follow-up
  • Report template
  • Self-healing checkpoint
  • Issue registry
  • Action outcome contract

Described artifacts

Public GitHub workflow bundle
bundle
https://github.com/h-mascot/Enterprise-Crew-skills/tree/main/openclaw-beta-testing
Public source for the reusable OpenClaw beta-testing workflow.
Beta testing skill
skill
https://github.com/h-mascot/Enterprise-Crew-skills/blob/main/openclaw-beta-testing/SKILL.md
Defines intake, canary, deep run, report, and issue-intelligence behavior.
GitHub issue filing template
template
https://github.com/h-mascot/Enterprise-Crew-skills/blob/main/openclaw-beta-testing/references/github-issue-template.md
Shareable issue-writing format for converting beta findings into crisp upstream reports.
Upstream OpenClaw bug template
template
https://github.com/openclaw/openclaw/blob/main/.github/ISSUE_TEMPLATE/bug_report.yml
Current upstream GitHub bug-report form to check before filing against OpenClaw.
Mission Control task
concept
MC task: OpenClaw beta canary
Tracks target version, target agent, risk, rollback, evidence, checkback, and reviewer.
Canary report
template
output/openclaw-beta/<date>-<agent>-canary-report.md
Compact pass/fail report with version, checks, logs, decision, and recommendation.
Self-healing checkpoint
template
/tmp/self-heal-oc-beta-<agent>-<version>.json
Resume state for long observation windows so the canary does not depend on memory.
Issue registry
doc
https://github.com/h-mascot/Enterprise-Crew-skills/blob/main/openclaw-beta-testing/state/issues.example.json
Example schema for tracking submitted beta issues, maintainer responses, and next actions.
Issue-intelligence report
template
output/openclaw-beta/issue-intelligence/<date>-issue-followup.md
Records issue state changes, maintainer requests, retest results, comments submitted, and lessons learned.
Upstream issue example
doc
https://github.com/openclaw/openclaw/issues/83456
Example of turning a canary regression into a public issue with scoped evidence and follow-up.
Follow-up comment example
doc
https://github.com/openclaw/openclaw/issues/83456#issuecomment-4476535287
Example of narrowing a beta issue after a live retry, adding expected-vs-actual behavior, diagnostics, and updated event-loop health evidence.
Issue action contract
template
external-comment-submitted | internal-lesson-updated | retest-queued | no-action-with-reason
Every issue-intelligence pass must end in one of these concrete outcomes so issue watching stays operational rather than passive.

Requirements

OpenClaw CLI and gateway access
runtime
The operator must be able to run version, status, doctor, update, cron, plugin, and log commands on the target.
Non-primary canary agent
dependency
Use an expendable or lower-risk target before touching the primary orchestrator.
Task board with evidence
runtime
A durable MC-style task keeps the checkback, reviewer, and final decision visible.
Peer review
review
Completion should be reviewed by another agent or operator before the task is closed.
Issue tracker access
access
The operator needs read/write access to the upstream issue tracker if failures will be submitted or followed up.

Declared structure

  • https://github.com/h-mascot/Enterprise-Crew-skills/tree/main/openclaw-beta-testing
  • skills/openclaw-beta-testing/SKILL.md
  • skills/openclaw-beta-testing/references/github-issue-template.md
  • skills/openclaw-beta-testing/state/issues.example.json
  • output/openclaw-beta/<date>-<agent>-canary-report.md
  • output/openclaw-beta/issue-intelligence/
  • docs/plans/<date>-openclaw-beta-<agent>-canary-plan.md
  • Mission Control task with peer review metadata

Verification

Verification language now matches reality. Installable bundles can be tested after install, external bundles should be source-reviewed first, and conceptual entries are reviewed as designs until real artifacts exist.

Intake completeness
Confirm the task has version, target, rollback, risk, evidence, checkback, and reviewer fields.
Expected: No beta update begins without a task and rollback note.
Canary decision
Confirm Phase 1 ends with pass-expand, mixed-hold, fail-rollback, or blocked.
Expected: The decision is written to the task and report.
Checkback present
Confirm any observation window has a scheduled checkback and checkpoint.
Expected: A later inspection is scheduled or the canary is explicitly closed.
Issue action
Confirm reportable failures become issue comments, lessons, retest tasks, or no-action reasons.
Expected: No submitted issue is left as passive monitoring.
Registry update
Confirm every submitted issue has current labels, state, comment count, last checked timestamp, and next action.
Expected: The registry can answer what happens next without re-reading the whole thread.
Maintainer follow-up
Confirm requests for diagnostics, expected-vs-actual behavior, screenshots, or reproduction are turned into action when safe.
Expected: Evidence is collected and commented, or a no-action reason is recorded.
Retest trigger
Confirm fixed, in-progress, or evidence-requested issues create a retest task or run.
Expected: The affected canary lane is rerun instead of guessed from stale evidence.
  • Treat this as an operating pattern. Adapt host names, channels, and commands to the target fleet.
  • The workflow is designed to avoid overexpansion when the first canary finds runtime instability.
  • Upstream reports should be scoped and updated when later retries narrow the diagnosis.
  • Issue intelligence is recursive: every maintainer/bot response should change either the public issue, the internal workflow, or the retest queue.

Best used for

  • Test the latest OpenClaw beta on Scotty, Spock, or Zora
  • Decide whether a beta is safe to expand beyond one canary
  • Convert a canary regression into a tight upstream report
  • Track ClawSweeper or maintainer asks without letting issues rot
  • Queue retests when an issue is fixed, narrowed, or needs stronger evidence
  • Update internal reporting guidance when a report is rejected or corrected
  • Keep a repro host available while maintainers ask for evidence
  • Avoid using the primary orchestrator as the first beta target

Operator notes

  • Keep the primary orchestrator stable unless the beta specifically needs main-gateway coverage.
  • Do not run the full deep matrix when the Phase 1 canary already found a P0 stability problem.
  • Every issue-intelligence pass must choose an action: external comment, internal lesson, retest queued, or no-action with reason.
  • Public examples intentionally omit private hostnames, tokens, and internal file paths.