OpenClaw EnterpriseDOCSGitHub

ClawSweeper dispatch flow

Overview

Repository issue, pull request, and comment events can hand off review requests to ClawSweeper. This trace ends when the repository dispatch request is sent; it does not establish that a review ran or completed.

Entry Points

Flow

graph TD
  Event["Repository event"] --> Admission["Check hosted eligibility and public visibility"]
  Admission -->|not public or unknown| Stop["Report admission outcome"]
  Admission -->|public| Token["Create dispatch token"]
  Token -->|failure| NoDispatch["Stop without dispatch"]
  Token -->|comment command| Filter["Ignore proof nudges"]
  Token -->|issue or pull request| Item["Build item request"]
  Filter -->|proof nudge| NoDispatch
  Filter -->|other command| Ack["Attempt target acknowledgement"]
  Ack -->|with or without acknowledgement| Comment["Build comment request"]
  Item --> Gate{"Dispatch token available?"}
  Comment --> Gate
  Gate -->|no| NoDispatch
  Gate -->|yes| Dispatch["Send repository dispatch"]

Execution Trace

1. Admit the target

.github/workflows/clawsweeper-dispatch.yml:19

The called admission workflow checks the target against its eligibility registry, then checks current GitHub repository identity and public visibility. The executable workflow is pinned; its separate registry input defaults to main, so eligibility can change independently. A terminal or unverifiable result prevents dispatch and produces a notice or warning.

2. Prepare credentials and acknowledgements

.github/workflows/clawsweeper-dispatch.yml:44

The job creates a central dispatch token and filters comments for commands. A command's target token and its optional reaction or status comment are best effort: target-token failure does not prevent the command handoff. The target status comment is attempted for owner, member, or collaborator comments; this acknowledgement is not an authorization decision for downstream work. Pull request acknowledgement is also best effort. A missing dispatch token causes the dispatch step to exit without a request; a failed central token step can fail the job before that step.

3. Hand off the event

.github/workflows/clawsweeper-dispatch.yml:202, .github/workflows/clawsweeper-dispatch.yml:339

For issues and pull requests, the workflow builds a request with the item identity and available source commit information. For command comments it sends the repository, item, comment, and event identity; it includes a status comment ID only if one was created. Proof-nudge comments are ignored. ClawSweeper owns subsequent command interpretation and review; the dispatch response is not proof of either result.

For openclaw/openclaw-enterprise, recognized command comments still reach the canonical ClawSweeper router. The Enterprise repository profile keeps read-only and review commands such as status, help or explain, re-review, proof, ask, and visualize available. It rejects repair, implementation, autofix, automerge, and merge-approval commands before job creation or target mutation. The dispatcher hands comments to that policy boundary; it does not authorize their effects. See the merged policy owner.

Setup and first-run verification

Use this repository's checked-in dispatcher as the installation source of truth. Upstream synchronization is merged; follow its GitHub App setup instructions, but do not copy the upstream workflow template. Keep one dispatcher.

Install the ClawSweeper App on this repository and openclaw/clawsweeper. Set repository secret CLAWSWEEPER_APP_PRIVATE_KEY. Dispatch tokens need contents write on ClawSweeper; acknowledgement tokens need issues write and pull-request read here.

After the first eligible issue, pull request, or command event following merge, inspect ClawSweeper Dispatch for admission, token creation, and successful dispatch. Check the matching ClawSweeper receiver run and final outcome. An acknowledgement alone does not prove delivery or completion.

Debugging and Verification

Search documentation